RH-01 — Consolidation fichiers RH multi-entités

Fonction	Nature	Framework	Score	Statut
RH	Workflow	n8n + UI conflits légère	18*	🟠 Vague 2, harmonisation à cadrer

Source : atelier RH 27/08 (Alexandra Delcourt DRH, Anoukone Savatmoungkhoune, Maëva Saucerotte) — synthèse.

Contexte métier

Priorité n°1 de l’atelier RH : consolidation mensuelle multi-entités — validée en séance avec Alexandra Delcourt (DRH) et confirmée dans la restitution DG des vagues 1-2.
Périmètre : ~1000 collaborateurs Proxiad (référence entretiens Michaël Ohana), ~9 entités RH contributrices (Bordeaux, Grim, Isinéo, Lyon, Île-de-France… certaines reprises en direct par Maëva).
Aujourd’hui : chaque entité envoie son propre fichier Excel via Teams, Maëva consolide manuellement puis re-vérifie ligne à ligne.
Verbatim Maëva Saucerotte : “Comme dit Alexandra, on va se faire des fichiers, quoi. Et en fait, je perds un temps infini à retrouver des colonnes supprimées, retrouver des entités supprimées.”
Verbatim Maëva : “Tous les mois, j’ai un seul fichier” — cadence mensuelle unique confirmée. “Ça me prend facilement toutes les BU que je consolide moi-même. Ça prend du temps.”
Verbatim Maëva sur la qualité : “Sur la partie salariée, elle est fiable, mais sur la partie plus sous-traitante, c’est compliqué.” → fiabilité asymétrique salariés vs indépendants/sous-traitants.
Verbatim Michaël Ohana : “Il y a l’histoire de fichiers partagés. Et quand vous l’avez mis en partage, vous l’avez mis sur le SharePoint ou sur OneDrive ou sur Teams ?” → Réponse : Teams aujourd’hui, cible à arbitrer (SharePoint RH pressenti).
Type de fichier de référence : fichier XPY (fichier d’actualisation) — entrées, sorties, modifications de contrat, changements de client — envoyé via Teams, deadlines rarement respectées.
Données consolidées : salariés, indépendants, entité, client, mission, statut, entrées/sorties.
Qualité affectée par doublons, champs supprimés, données obsolètes — la partie sous-traitants est la plus touchée.
Sources potentielles côté systèmes : Nibelis (référence paie), Progessi (opérationnel), Boond Manager (CRM/ATS — dit “Boone” ou “Boon” dans les verbatims).
Nibelis = référence paie — les fichiers Excel remontés par les entités en sont dérivés et divergent souvent.
Fil rouge RH (restitution DG) : “un socle de données fiable d’abord — chaque automatisation en dépend”.
Restitution priorisation consolidée avec Alexandra fin août / début septembre.
Sonia Gantou = interlocutrice Nibelis (accès API demandé, en attente).
Référents par Business Unit à définir (action item Alexandra) pour gouvernance données sources.

Transcripts sources : RH audit Mekorai 27/08/2026 (synthèse + verbatim), restitution DG consolidée vagues 1-2.

Objectif du cas d’usage

Automatiser la collecte des fichiers Excel remontés par les 9 entités RH, la validation qualité (doublons, champs obsolètes, cohérence dates), la consolidation en un fichier maître mensuel, avec UI d’arbitrage des conflits pour Alexandra et Maëva. Objectif de charge : passer de “plusieurs jours de consolidation” à ~1h d’arbitrages par mois.

Ce que l’API Progessi READ apporte :

Cross-check référentiel consultants actifs : POST /profiles (34 champs — id, email, businessUnit, legalEntity, hireDate, statut, matricule Progessi).
Cross-check missions actives / anciennes : POST /projects.
Détection écarts entrées/sorties : croiser les hireDate/endDate Progessi avec les colonnes des Excel remontés par les BU.

Ce qui vient de sources externes :

Fichiers Excel mensuels de chaque BU (Teams / SharePoint) : Graph API GET /drive/items.
Nibelis (paye — référence de vérité pour matricule, statut contrat, dates réelles) : API demandée, non ouverte à date → fallback = export mensuel Nibelis en attendant.
Boond Manager (CRM/ATS) : disponible via API DSI-confirmée, marginalement utile pour ce cas (utilisation renforcée sur RH-04 / LAB).

Ce qui reste manuel :

Arbitrage des conflits par Alexandra / référents BU (décisions métier non déléguables).
Validation des “champs obsolètes” nécessitant contexte humain (ex : poste renommé mais collaborateur inchangé).
Enrichissement des exceptions (fusion doublons, exclusion, corrections).

Étapes fonctionnelles détaillées

Cron mensuel J+2 après réception fichiers.
Lister fichiers Excel sur /RH/Consolidation/<mois>/ (SharePoint).
Parseur robuste : matching header labels + dictionnaire synonymes RH.
Reconnaissance des 4 types : salariés / indépendants / missions / entrées-sorties.
Validation qualité :
- Détection doublons cross-entités (matricule Nibelis + nom + prénom + DDN)
- Détection champs obsolètes (poste vs référentiel, entité vs référentiel)
- Cohérence dates (entrée < sortie)
- Complétude (champs obligatoires)
Consolidation vers fichier maître :
- 1 onglet par type (salariés / indépendants / missions / entrées-sorties)
- 1 onglet “Conflits” avec doublons/incohérences
Interface web arbitrage conflits :
- Alexandra + équipe voient conflits
- Actions : merger doublons / corriger / exclure
- Décisions traçables
Publication : fichier maître sur SharePoint RH + notif équipes.
Historique : versions mensuelles archivées.

Flot d’appels API

flowchart TD
    Cron[Cron mensuel J+2] --> List[Graph API<br/>GET /sites/rh/drive/items<br/>/Consolidation/mois/children]
    List --> Download[Graph API<br/>GET /drive/items/id/content<br/>XLSX binaire par entite]
    Download --> Parse[Parseur Excel n8n<br/>Spreadsheet File<br/>dictionnaire synonymes RH]
    Parse --> Types{Reconnaissance type}
    Types --> Sal[Salaries]
    Types --> Ind[Independants]
    Types --> Miss[Missions]
    Types --> ES[Entrees/Sorties - fichier XPY]

    Sal --> Prog[Progessi<br/>POST /profiles<br/>FilterModel active=true<br/>fields: id,email,businessUnit,<br/>legalEntity,hireDate,endDate]
    Ind --> Prog
    Miss --> ProgProj[Progessi<br/>POST /projects<br/>FilterModel]
    ES --> Prog

    Prog --> Dedup[Detecteur doublons<br/>matricule Progessi + nom<br/>prenom + DDN + email]
    ProgProj --> Dedup
    Dedup --> Valid[Validation qualite<br/>champs obsoletes<br/>coherence hireDate/endDate<br/>completude obligatoires]
    Valid --> NibFallback{API Nibelis<br/>ouverte ?}
    NibFallback -->|Non v1| SkipNib[Fallback matching<br/>nom+prenom+DDN]
    NibFallback -->|Oui v2| NibCall[Nibelis API<br/>GET /employees<br/>verif matricule paie]
    SkipNib --> Conso[Consolidation<br/>1 onglet par type<br/>+ onglet Conflits]
    NibCall --> Conso
    Conso --> UI[UI web arbitrage<br/>Alexandra + referents BU<br/>merger/corriger/exclure]
    UI --> Publish[Graph API<br/>PUT /sites/rh/drive/root:<br/>/master-YYYY-MM.xlsx:/content]
    Publish --> Notif[Graph API<br/>POST /me/sendMail<br/>equipes RH + DRH]
    Publish --> Hist[Graph API<br/>PUT /drive/root:/Historique/<br/>YYYY-MM/master.xlsx]

Confrontation à l’API Progessi réelle

Base URL : https://proxiad.progessi.com/api/control/rest — BasicAuth — READ-ONLY. Une Write API est absente ; toute demande d’ouverture passe par clalanne@progessi.com.

Besoin RH-01	Endpoint Progessi	Faisabilité	Contournement
Extraire liste consultants actifs pour cross-check	`POST /profiles` (FilterModel `active=true`)	✅ 34 fields disponibles	—
Cross-check missions/clients	`POST /projects` (FilterModel)	✅	—
Détecter entrées/sorties (dates réelles paie)	`GET /profiles/{id}` (hireDate/endDate)	✅ mais donnée SIRH, pas paie	Nibelis reste référence — attente API
Mettre à jour un profil corrigé après arbitrage	❌ Aucun `PUT /profiles/{id}`	🔴 impossible	Correction manuelle côté Progessi par l’entité concernée après arbitrage
Trigger workflow RH (embauche, mutation, sortie)	❌ Pas de BPM exposé	🔴 impossible	Reste manuel côté Nibelis / Progessi UI

Sources externes à qualifier :

Fichiers Excel RH mensuels par entité — aujourd’hui via Teams, cible SharePoint RH dédié (site à créer/confirmer, chemin /RH/Consolidation/YYYY-MM/). Extension droits Graph API prérequise.
Fichier XPY d’actualisation (entrées/sorties/modifs) — même canal.
Nibelis (paye) — API en attente. Fallback v1 : export mensuel Nibelis manuel côté Sonia.

Bloquants n8n / règles métier :

Le champ matricule Nibelis n’existe pas directement sur Progessi /profiles → matching heuristique nom+prénom+DDN+email en fallback (règle à cadrer avec Alexandra).
La notion de “champ obsolète” (poste, entité) exige un référentiel Proxiad — à fournir en Livrables.
L’écriture du fichier maître se fait côté n8n dans SharePoint RH (Graph API PUT /content). Aucune écriture Progessi n’est déclenchée par ce workflow.

API map

#	Étape	Fonction / endpoint	Application	Existe ?	Accès dispo ?	Notes
1	Lister fichiers SharePoint	`GET /sites/{id}/drive/items/{path}/children`	Microsoft Graph	✅	⚠️ Extension droits	Site RH
2	Lire contenu Excel	`GET /sites/{id}/drive/items/{id}/content`	Microsoft Graph	✅	⚠️	Binaire XLSX
3	Cross-check matricules	`GET /employees`	Nibelis	❓	🔴 API demandée	Optionnel v1 (fallback matching nom+prénom+DDN)
4	Parseur Excel	Noeud n8n `Spreadsheet File`	n8n natif	✅	—	Mutualisé CDG-02
5	UI arbitrage conflits	Interface web légère	React ou plateforme Abra	À dev	—	~1j de dev
6	Upload fichier maître	`PUT /sites/{id}/drive/root:/master.xlsx:/content`	Microsoft Graph	✅	⚠️	—
7	Notif mail	`POST /me/sendMail`	Microsoft Graph	✅	⚠️	Équipes RH

Prérequis techniques

Extension droits M365 + SharePoint RH
Site SharePoint RH dédié (test + prod)
Fichiers RH actuels de chaque entité (calibrage parser)
Référentiels : postes, entités, statuts (CDI/CDD/indé/intérim/alternant/stagiaire)
API Nibelis (optionnel v1, requis v2 pour cross-check matricules)

Livrables Proxiad attendus

Liste entités RH couvertes (nombre + noms)
Exemplaires fichiers RH actuels par entité — calibrer parser
Format cible fichier maître (template)
Dictionnaire synonymes RH validé
Référentiels : postes valides / entités / statuts
Règles doublons : confirmer heuristiques (matricule > nom+prénom+DDN)
Politique conflits : qui tranche ? (Alexandra seule ? référents BU ?)
Atelier harmonisation avec entités — préalable métier essentiel
Référents par BU identifiés (gouvernance données sources)

Timeline estimative

Effort : 7 jours-n8n.

S+0 : atelier harmonisation entités (préalable métier)
S+0 : fichiers exemples + référentiels
S+1 J1-2 : parseur Excel (mutualise composant CDG-02)
S+1 J3 : détecteur doublons + validation qualité
S+1 J4 : handler orchestration
S+2 J1-2 : UI conflits (léger)
S+2 J3 : tests + démo Alexandra
S+3 : pilote 1 mois
Octobre : mise en production

Critères de recette

Fichiers d’un mois complet : 100% entités parsées sans erreur
Doublons cross-entités détectés (test avec 3 collabs volontairement dupliqués)
Champs obsolètes alertés
UI conflits accessible Alexandra + équipe
Arbitrages traçables (qui, quand, décision)
Fichier maître mensuel généré + archivé
Temps Alexandra : “1 jour consolidation” → “1h arbitrages”

Risques identifiés

Risque	Impact	Mitigation
Fichiers entités trop hétérogènes	Blocage parser	Harmonisation en amont — atelier prioritaire
Nb doublons énorme (data historique pas propre)	UI conflits inutilisable	Nettoyage initial avec Alexandra, seuils confiance élevés
API Nibelis non ouverte	Cross-check matricules manquant	Fallback matching nom+prénom+DDN uniquement
Sensibilité RGPD	Blocage juridique	Cadrage droits par rôle, environnement isolé, comm DRH
Adoption Alexandra (change habitudes)	Adoption faible	Co-dev 2 mois avec Alexandra, itérations UI

Questions ouvertes

Q1 : Nombre exact d’entités RH concernées ?
Q2 : Format fichier maître consolidé — existe déjà (template) ou à créer avec Alexandra ?
Q3 : Politique conflits — Alexandra seule décide ou déléguée aux référents BU ?
Q4 : Fichier maître — publication SharePoint uniquement ou aussi export vers autre outil (Nibelis ? Boond ?) ?
Q5 : Cadence — mensuelle confirmée ? Ou bi-mensuelle / trimestrielle ?
Q6 : Statut “obsolète” — comment détecte-t-on ? (dernière modif > 6 mois ? champ “actif=non” ?)
Q7 : Cross-check matricules Nibelis — attend API ou peut-on avoir un export mensuel Nibelis initialement ?
Q8 : Restitution priorisation 31 août — impact sur ordre de priorité de ce cas dans le portefeuille ?