MG-01 — Formulaire structuré déplacements

Fonction	Nature	Framework	Score	Statut
Moyens généraux	Workflow	n8n + Microsoft Forms/SharePoint	21	🟢 En développement (Piste A)

Source : atelier MG 29/07/2026 (Sasha Kostadinoff, Esther Hesschentier, Sonia Gantou) — synthèse + transcript.

Contexte métier

Aujourd’hui : demandes par mail libre — Esther (verbatim 12:17) : « on a beaucoup de mails à traiter et les demandes se font par mail donc il faut vraiment pas louper le mail qui passe, sachant que ça peut être un déplacement prévu dans la semaine ou la semaine d’après ». Résultat : allers-retours, infos manquantes, oublis.
Volume : « au moins une fois par semaine » par zone (Sacha, 07:42) — probablement sous-estimé, périmètre en croissance avec Swipe Travel en test sur ProxiadUp.
Zones distinctes : Paris (Sacha Kostadinoff) / Nord (Esther Hesschentier) — hôtels préférentiels, tarifs négociés, grille tarifaire différenciée. Esther (16:13) : « Sacha et moi on ne gère pas forcément les mêmes collaborateurs, donc que ce ne soit pas mélangé, mais qu’on ait une base pour le Nord, une base pour Paris ».
Preuve validation client obligatoire — Esther (13:06) : « nous par exemple dans le Nord on demande forcément une validation client, donc un mail client pour prouver que le collaborateur a été demandé pour un déplacement ». Actuellement re-sollicité par mail au client, à remplacer par upload de capture d’écran dans le formulaire.
Preuve validation manager N+1 — obligatoire en amont pour éviter les retours arrière. Le collaborateur téléverse la copie du mail du N+1 dans le formulaire (Gabriel, 40:41 : « Il téléverse la validation. Très simple, très basique »).
Contrainte VPN BPCE / Auroch : collaborateurs en mission chez ces clients ont un PC bancaire avec URL whitelist stricte → un formulaire web sera vraisemblablement bloqué. Fallback : envoi du Excel type par mail depuis le PC bancaire (Sacha, 27:50). Cas également identifié chez Auroch.
Outils déplacements existants : Swipe Travel (test, 6e étage / ProxiadUp), Navan (groupe, en sortie de contrat), iTravel — pas de dev sur ces plateformes. Préférence pour un formulaire léger avec base Excel/SharePoint pour la double visibilité interne (Esther, 22:15 : « au cas où soit elle plante, au moins on a une base de données en interne »).

Transcripts sources : MG atelier 29/07/2026 (synthèse + verbatim), restitution consolidée DG vagues 1-2.

Objectif du cas d’usage

Remplacer les mails libres par un formulaire structuré cloud (avec fallback mail-Excel pour VPN bancaire), garantir la complétude AVANT transmission MG (validation client + validation N+1 attachées à la demande), tracer chronologiquement les demandes par zone (Paris / Nord) dans une base cloud partagée. Les données consultant (nom, DDN, préférences) sont pré-remplies via SSO M365 et via le profil Swipe Travel lorsque le collaborateur y est déjà onboardé (Sacha, 21:23 : « au niveau prénom, tout ce qui est perso, date de naissance, normalement ce sera dans Swipe »).

Étapes fonctionnelles détaillées

Le collaborateur ouvre le formulaire (Microsoft Forms sur SharePoint) via lien intranet.
Choisit sa zone (Paris / Nord) → le formulaire adapte les champs (hôtels préférentiels, prestataires locaux, tarifs).
Remplit les champs obligatoires : nom (préfilé SSO), DDN, client, mission, dates aller-retour, ville départ/destination, transport, hôtel (oui/non + nb nuitées), upload capture d’écran validation manager N+1 (mail direct du N+1), upload capture d’écran validation client (mail client), justification si < 7 j.
Soumet → la donnée arrive dans une SharePoint List “Demandes de déplacement” (base cloud partagée).
Notification : Esther/Sacha (selon zone) reçoivent un message Teams + mail.
Le demandeur reçoit un accusé avec numéro de demande + statut initial “Reçu”.
Fallback VPN BPCE / Auroch : si le formulaire est bloqué par le VPN client, le collaborateur envoie un mail (Excel type joint) à deplacement-paris@ ou deplacement-nord@ (traité par MG-02 — agent IA de tri/relance qui alimente la même base).
Le demandeur suit le statut via une vue SharePoint “Mes demandes” : Reçu → En cours → Réservé → Refusé.
Historique consultable filtrable (client, consultant, mois).

Flot d’appels API

flowchart TD
    User[Collaborateur<br/>ouvre formulaire M365] --> Zone{Zone ?}
    Zone -->|Paris| FormP[Microsoft Forms<br/>segment Paris]
    Zone -->|Nord| FormN[Microsoft Forms<br/>segment Nord]
    FormP --> Upload[Upload preuve N+1<br/>+ preuve client<br/>mail screenshot]
    FormN --> Upload
    Upload --> Submit[POST submit form]
    Submit --> Flow[n8n webhook<br/>OU Power Automate]
    Flow --> Check[Validate champs<br/>+ pieces jointes]
    Check --> SPList[SharePoint List<br/>POST /lists/demandes/items]
    SPList --> NotifRoute{Zone ?}
    NotifRoute -->|Paris| Sacha[Teams + mail Sacha<br/>Graph POST /me/sendMail]
    NotifRoute -->|Nord| Esther[Teams + mail Esther<br/>Graph POST /me/sendMail]
    SPList --> Ack[Mail accusé au demandeur<br/>Graph POST /me/sendMail]

    VPN[Collab sous VPN BPCE / Auroch] -.-> MailAlias[Envoi Excel type par mail<br/>deplacement-paris@ / -nord@]
    MailAlias -.-> MG02[Handler MG-02<br/>agent IA parse + relance<br/>si champ manquant]
    MG02 -.-> SPList

Confrontation à l’API Progessi réelle

Progessi n’est pas utilisé dans MG-01 — dépendance nulle.

La question a été explicitement posée par Gabriel en atelier (34:08) : « je cherche au sein du logiciel que vous avez, où il y a des workflows de validation par le N+1 d’une demande de dépense. Généralement ça peut être Progessi ». Sacha a tranché (35:14) : « avec Déo, je n’ai pas de gestion de workflow. Le workflow, il est à postérieurie de la dépense ». Autrement dit, Progessi couvre la note de frais après engagement (le collaborateur a déjà dépensé, il justifie), pas l’autorisation préalable d’un déplacement.

Conséquences concrètes pour MG-01 :

Pas d’appel à GET /profiles/{id} — les données consultant (nom, DDN, préférences) viennent du SSO M365 puis du profil Swipe Travel (lorsque le collaborateur y est onboardé). Progessi ne pourrait pas les servir de toute façon : l’API est côté ERP financier, pas RH.
Pas d’appel à POST /projects filter pour retrouver la mission active — l’information « client / mission » est saisie par le collaborateur dans le formulaire (elle est de toute façon connue de lui puisqu’il joint le mail client de demande de déplacement).
Pas d’appel à POST /expenses — cet endpoint est READ-only en pratique et couvre les notes de frais, pas les demandes de réservation. La création d’une note de frais éventuelle post-déplacement reste dans le circuit Progessi standard, hors périmètre MG-01.

La validation N+1 est portée par le formulaire lui-même : le collaborateur téléverse la capture du mail d’accord du manager (Gabriel, 40:41). Pas de doublon avec Progessi puisque Progessi ne gère pas ce workflow amont. Une piste évoquée mais non retenue en séance : « sur Progesty je peux peut-être voir qu’on fait un workflow, une demande spécifique avec un formulaire » (Sacha, 35:35) — abandonnée au profit d’un formulaire dédié pour éviter de dépendre du planning d’un éditeur externe.

API map — fonctions requises

#	Étape	Fonction / endpoint	Application	Existe ?	Accès dispo ?	Notes
1	Formulaire structuré	Microsoft Forms (interface native)	M365	✅	⚠️ Extension droits demandée	Config sans code
2	Trigger sur submit	Power Automate trigger “When new form response”	Power Automate	✅	⚠️ Idem	Ou webhook n8n
3	Insert dans SharePoint	`POST /sites/{id}/lists/{id}/items`	Microsoft Graph	✅	⚠️ Idem	Site SharePoint MG à créer
4	Notif Teams	`POST /teams/{id}/channels/{id}/messages`	Microsoft Graph	✅	⚠️ Idem	Canal Teams MG
5	Notif mail	`POST /me/sendMail`	Microsoft Graph	✅	⚠️ Idem	Accusé demandeur
6	Vue “Mes demandes”	Filtered SharePoint List	M365	✅	⚠️ Idem	Vue native SharePoint

Prérequis techniques

M365 tenant Proxiad avec droits SharePoint + Forms + Power Automate étendus
Boîte mail dédiée deplacement-paris@proxiad.com + deplacement-nord@proxiad.com (pour fallback + MG-02)
Site SharePoint MG dédié (test + prod)

Livrables Proxiad attendus

Test formulaire avec Esther (session 1h partage écran) — définir champs obligatoires vs optionnels
Liste hôtels préférentiels Paris + Nord (dropdown)
Liste prestataires transport agréés
Règles segmentation Paris/Nord (ville départ ? entité juridique ?)
Liste utilisateurs sous VPN BPCE
Nomenclature statuts (Reçu / En cours / Réservé / Refusé)
Comm interne co-construite avec DRH

Timeline estimative

Effort : 2 jours (essentiellement config M365).

S+0 : session Esther
S+1 J1 : formulaire + logique segmentation
S+1 J2 : SharePoint list + notifications
S+2 : pilote 5 volontaires
S+3 : production

Livraison couplée à MG-02 — même cycle.

Critères de recette

Collaborateur soumet demande complète en < 3 min
Segmentation Paris/Nord affiche les bons champs
Collaborateur VPN peut envoyer mail → MG-02 alimente la même base
Notification Esther/Sasha à chaque demande
Statut visible dans “Mes demandes”
Historique filtrable

Risques identifiés

Risque	Impact	Mitigation
Adoption faible (habitude mail libre)	ROI nul	Comm DRH, obligation via note service, sensibilisation (Sacha 20:48)
VPN BPCE / Auroch bloque même Outlook	Fallback inopérant	Test avec cobaye BPCE en pré-prod ; alternative mobile/PC perso
Demandes remontées par Teams (message direct)	Contournement du process	Comm interne : rediriger explicitement vers alias/formulaire (Esther 37:44)
Preuve N+1 sous forme d’upload image	Difficile à auditer	Nomenclature stricte, moderation par MG à la réception

Questions ouvertes

Q1 : Règle segmentation Paris/Nord — sur ville départ (VilleDépart == “Paris” → segment Paris) ou sur entité juridique du collaborateur ?
Q2 : Champs obligatoires exacts — la DDN est-elle vraiment obligatoire (ou juste pour certains transports) ?
Q3 : Preuve validation manager — capture d’écran du mail N+1 suffit (position atelier), ou faut-il un accusé structuré via Teams Approvals ? Progessi écarté (workflow a posteriori uniquement).
Q4 : Formulaire Microsoft Forms vs SharePoint List custom vs Power Apps — quel niveau de personnalisation nécessaire ?
Q5 : Statut “Refusé” — motif obligatoire ? Notification demandeur ?
Q6 : Sacha/Esther partagent visibilité globale ou stricte par zone ?