MG-02 — Agent tri + contrôle déplacements

Fonction	Nature	Framework	Score	Statut
MG	Agent IA + Automatisation (hybride)	n8n + noeud LLM (parser mails)	21	🟢 En développement

Source : atelier MG 29/07/2026.

---

Contexte métier

Complément de MG-01. Trois besoins combinés :

• Parser les mails structurés (fallback VPN BPCE + collaborateurs qui n’utiliseront pas le formulaire) → normaliser vers même base SharePoint
• Vérifier la complétude de chaque demande (formulaire OU mail) avant transmission Esther/Sacha
• Relancer le demandeur pour compléter, AVANT que ça arrive sur le bureau MG
• Alias dédiés par zone : deplacement-paris@, deplacement-nord@

Objectif du cas d’usage

Filtrer les demandes entrantes (mails + formulaire) pour ne laisser passer sur le bureau d’Esther/Sacha que les demandes complètes et validées. Réduire les allers-retours “il manque X” → “voici X” → “il manque aussi Y”.

Étapes fonctionnelles détaillées

1. Polling toutes les 5 min sur les boîtes deplacement-paris@ et deplacement-nord@.
2. Pour chaque nouveau mail : agent LLM parse le contenu → extrait JSON structuré (client, mission, dates, ville, hôtel, options, validation manager, urgence).
3. Vérifier la complétude : moteur de règles n8n valide (champs obligatoires présents ? dates cohérentes ? hôtel spécifié si nuitée ? validation manager référencée ?).
4. Si complet → normaliser vers SharePoint List MG-01 + notif Esther/Sacha.
5. Si incomplet → composer mail personnalisé au demandeur avec la liste précise des infos manquantes.
6. Si silence 48h → escalade Esther/Sacha (mail avec contexte + brouillon de relance).
7. Détecter anomalies : demande urgente (<7j) sans justification, hôtel hors liste préférentielle, doublon avec demande précédente du même consultant.
8. Tracer intégralement : chaque mail parsé + décision + timestamp.

Flot d’appels API

flowchart TD
    Cron[⏰ Cron n8n toutes les 5 min] --> Poll[Microsoft Graph<br/>GET /me/messages?filter=unread<br/>sur deplacement-@]
    Poll --> Loop{Nouveau mail ?}
    Loop -->|Non| End[End]
    Loop -->|Oui| LLM[🤖 Noeud LLM n8n<br/>Prompt : extract JSON<br/>client, dates, hôtel, ...]
    LLM --> Rules[Moteur règles n8n<br/>vérif complétude]
    Rules --> Check{Complet ?}
    Check -->|Oui| Insert[POST SharePoint List<br/>/sites/mg/lists/demandes]
    Check -->|Non| Relance[POST /me/sendMail<br/>→ demandeur<br/>+ liste champs manquants]
    Insert --> Notif[Notif Teams + mail<br/>→ Esther/Sacha zone]
    Relance --> Wait[Wait 48h scheduled node]
    Wait --> Recheck{Réponse<br/>reçue ?}
    Recheck -->|Oui| LLM
    Recheck -->|Non| Escal[Mail escalade<br/>→ Esther + contexte]
    Insert --> Trace[(SharePoint tracking log)]
    Escal --> Trace

API map — fonctions requises

#	Étape	Fonction / endpoint	Application	Existe ?	Accès dispo ?	Notes
1	Lister mails alias	GET /users/{alias}/messages?$filter=isRead eq false	Microsoft Graph	✅	⚠️ Extension droits	2 alias à créer
2	Parser LLM	Noeud HTTP Request n8n → provider LLM (Anthropic / OpenAI / local)	Provider LLM	✅	⚠️ Compte + budget à valider	Prompt strict, ~500 tokens contexte
3	Marquer mail comme lu	PATCH /me/messages/{id}	Microsoft Graph	✅	⚠️ Idem	Post-traitement
4	Insert SharePoint	POST /sites/{id}/lists/{id}/items	Microsoft Graph	✅	⚠️ Idem	Même base MG-01
5	Envoyer relance	POST /me/sendMail	Microsoft Graph	✅	⚠️ Idem	Depuis alias dédié
6	Wait 48h	Noeud Wait n8n	n8n natif	✅	—	Schedulé

Prérequis techniques

• Alias mails deplacement-paris@ + deplacement-nord@ créés + droits lecture MekorAI
• Provider LLM configuré (choix modèle à valider — Claude Haiku pour parsing léger + éco ?)
• Base SharePoint MG-01 en place (dépendance)
• n8n déployé chez Proxiad ou accessible

Livrables Proxiad attendus

• Règles de complétude exhaustives (quels champs bloquants ?)
• Templates de relance validés (ton neutre non-stigmatisant)
• Règles routage Paris/Nord définitives
• Seuil urgence (< 7 j confirmé ?)
• Liste hôtels préférentiels (détection hors-liste)
• Politique doublons (silencieux alerte Sacha ? refus auto ?)
• 10 mails historiques pour calibrer parser LLM

Timeline estimative

Effort : 3 jours-n8n (dont 1 jour calibrage LLM sur mails historiques).

• S+1 J1 : test parser LLM sur 10 mails historiques + tuning prompt
• S+1 J2 : workflow polling + parsing + complétude
• S+1 J3 : workflow relance + escalade + trace
• S+2 : pilote couplé MG-01
• S+3 : production

Critères de recette

• Parser correct sur 8/10 mails historiques (precision par champ)
• Mails incomplets → relance envoyée dans les 5 min
• Relance contient précisément les champs manquants (pas générique)
• Escalade Sacha après 48h fonctionne
• Zéro doublon dans SharePoint (déduplication par expéditeur + date demande)
• Journalisation complète

Risques identifiés

Risque	Impact	Mitigation
Parser LLM confond champs	Demandes mal remontées	Confidence score : si LLM incertain, tag “à vérifier manuel”
Mails spam / phishing sur alias	Bruit ou faille	Filtre anti-spam M365 amont + whitelist expéditeurs internes
User vexé par relance	Adoption faible	Ton amical, personnalisé, jamais stigmatisant
Coût LLM élevé si volume grand	Coût opérationnel	Modèle éco (Haiku / gpt-oss local via NVIDIA NIM)

Questions ouvertes

• Q1 : Choix provider LLM — Anthropic (Claude Haiku) ? OpenAI (gpt-4o-mini) ? Modèle local (NVIDIA NIM gpt-oss) ? Décision Proxiad + budget mensuel accepté
• Q2 : Confidence threshold — à partir de quel score de confiance LLM on marque “à vérifier manuel” ?
• Q3 : Alias tenant : -paris@proxiad.com ou -paris@proxiad.fr ? Nommage à valider
• Q4 : Cas des demandes du week-end / hors heures — relance immédiate ou attendre lundi matin ?
• Q5 : Historique — combien de temps garde-t-on les mails traités dans la boîte alias (30j ? 90j ?) pour audit ?
• Q6 : Les demandes urgentes doivent-elles court-circuiter le check complétude (accept + alerte Sacha immédiate) ?