Gestion de parc informatique avec GLPI · Étape 17

Configure notifications et collecte des courriels sans boucle

Sépare réception, routage, modèles, destinataires et file d'envoi afin d'éviter spam, auto-réponses et duplications.

Durée indicative · ~1 h 40Niveau intermédiairePrérequis conseillé · Leçon 16 — règles d'affectation testablesPratique · TP
L’idée reçue

« Une seule boîte support suffit : GLPI saura automatiquement où créer le ticket. »

Sans règle d’affectation d’entité, politique d’expéditeur et contrôle des auto-réponses, le collecteur devient une source de tickets mal routés ou de boucles.

01Sépare les deux flux

Flux entrant
boîte mail → collecteur → mailgate → règle → ticket ou suivi

Flux sortant
événement GLPI → notification → modèle → destinataires → file → SMTP

Diagnostique chaque sens séparément. Une notification envoyée ne prouve pas que le collecteur fonctionne.

02Associe explicitement collecteur et entité

collector_code,mailbox,entity_code
COL_ORL,support-orleans@soria.example,ORLEANS
COL_TOU,support-tours@soria.example,TOURS

Une règle de collecteur doit au minimum identifier le collecteur et définir l’entité cible.

03Définis les rejets avant l’ouverture

REJECT_AUTOREPLY
- en-tête Auto-Submitted
- réponse automatique fournisseur

REJECT_UNKNOWN_DOMAIN
- domaine externe non autorisé
- absence de règle de qualification

ADD_FOLLOWUP
- message avec In-Reply-To lié à un ticket existant

Ne transforme pas silencieusement un rejet en suppression. Conserve un journal exploitable.

04Évite les boucles

- ne pas utiliser la même adresse comme expéditeur automatique et collecteur ;
- filtrer auto-reply et auto-submitted ;
- ne pas répondre automatiquement aux notifications automatiques ;
- contrôler les alias et listes de diffusion ;
- limiter la création automatique d'utilisateurs ;
- tester les réponses sur un ticket pilote.

05Gouverne la notification

notification_code,event,template,recipient_role,queue_delay_minutes
NOTIF_NEW_TICKET,new_ticket,ticket-created,assigned_group,0
NOTIF_FOLLOWUP,new_followup,ticket-followup,requester,15
NOTIF_APPROVAL,new_approval,approval-request,approver,10

Chaque notification doit justifier : événement, destinataire, modèle, délai, donnée exposée et propriétaire.

06Comprends la file

Tous les e-mails sortants passent par une file. Selon le type de modification, l’envoi peut être immédiat ou différé. Le délai d’entité permet de regrouper plusieurs changements rapides, mais il doit rester compatible avec les engagements de service.

created_minute + queue_delay = expected_send_minute
110 + 15 = 125

07Exécute les scénarios

bash module4-glpi-automation-reporting.sh run "$lab"
column -s, -t "$lab/output/mail-routing-results.csv"
column -s, -t "$lab/output/notification-queue-results.csv"

Le lab crée deux tickets simulés, ajoute un suivi, rejette une auto-réponse et refuse un domaine inconnu. Il n’accède à aucune boîte mail.

08Construis les preuves réelles

Collecteur
- test de connexion
- message récupéré
- règle gagnante
- ticket ou suivi créé

Notification
- événement déclencheur
- destinataire calculé
- entrée dans la file
- action queuedmail
- livraison ou erreur SMTP
Mission

Teste une chaîne e-mail complète

Sur une instance de laboratoire, prépare un message entrant, vérifie sa règle, puis ajoute un suivi et observe la notification sortante sans créer de boucle.

À retenir

La messagerie du service desk est une chaîne bidirectionnelle. Le collecteur, les règles, les notifications, la file et SMTP doivent chacun fournir une preuve distincte.

Ta progression

Chargement de l’état… Se connecter pour synchroniser.