EIB qui écrase la table org : qui est responsable dans la chaîne ?

L'EIB (Enterprise Interface Builder) est l'outil d'intégration en masse de Workday. Il permet de charger ou d'extraire des milliers d'enregistrements en un seul fichier. C'est un instrument puissant — et c'est précisément ce qui le rend dangereux. Un EIB ne se contente pas de modifier une fiche : il agit sur des tables structurantes comme la supervisory organization, la hiérarchie qui détermine qui reporte à qui, quels approbateurs sont sollicités et comment les données circulent.

Lorsqu'un mapping est erroné — une colonne décalée, un reference ID mal résolu, un mode « replace » au lieu de « add » — l'EIB n'écrase pas une donnée isolée. Il peut réaffecter des centaines de salariés à la mauvaise organisation, casser les lignes hiérarchiques et invalider les Business Process en cours. Pire : l'erreur se propage immédiatement aux systèmes avals via les intégrations sortantes (Core Connectors, Studio) qui poussent ces données corrompues vers la paie externe, le contrôle d'accès ou l'annuaire.

Un EIB mal maîtrisé transforme donc une erreur de fichier en incident SIRH global. C'est l'un des risques majeurs identifiés pour le métier : un EIB qui corrompt la base employés ou désynchronise les SIRH.

La sévérité tient à un facteur souvent sous-estimé : la temporalité de la propagation. Une fois la table organisationnelle modifiée, les intégrations sortantes planifiées s'exécutent à leur cadence habituelle — parfois quelques minutes plus tard, parfois la nuit suivante. Quand l'équipe découvre l'anomalie dans Workday au matin, les données erronées ont déjà été poussées vers l'annuaire d'entreprise, l'outil de gestion des accès et la paie externalisée. Remédier dans Workday ne suffit alors plus : il faut orchestrer une re-synchronisation coordonnée de tous les systèmes avals, chacun avec ses propres délais et ses propres responsables. Ce qui aurait pu être un simple rollback devient une opération de remédiation multi-systèmes.

Une idée fausse circule : « si l'EIB a planté, c'est Workday qui a un bug ». Dans la quasi-totalité des cas, c'est faux. Workday exécute fidèlement le fichier que le consultant lui fournit. Si le mapping désigne la colonne 7 comme « supervisory organization » alors que la donnée s'y trouve en colonne 9, le système applique consciencieusement la valeur de la colonne 7.

Cette logique a une conséquence juridique directe : la responsabilité de la conception de l'intégration retombe sur celui qui l'a construite. Le consultant ne peut pas invoquer un défaut de l'éditeur pour une erreur de mapping. L'éditeur n'est responsable que d'un dysfonctionnement avéré de la plateforme elle-même — situation rare et difficile à démontrer.

La défense « c'est l'outil qui a mal fait » ne tient pas pour un EIB. L'outil a fait exactement ce qu'on lui a demandé. C'est la demande qui était fausse.

D'où l'importance de tracer chaque exécution : Workday journalise les EIB Process Monitor avec l'auteur, l'horodatage et le détail des enregistrements impactés. Cette traçabilité sert autant à diagnostiquer qu'à établir les responsabilités.

Reste à savoir qui, in fine, supporte le coût. La réponse dépend de la structure de la mission :

• Le consultant freelance en direct : s'il a conçu, testé et lancé l'EIB en Production, sa responsabilité technique est pleine et entière. Il répond du préjudice de désorganisation et de remédiation.
• Le consultant sous-traitant d'un intégrateur : l'intégrateur est contractuellement face au client. Il assume d'abord, puis exerce un recours contre le sous-traitant fautif. Le freelance reste exposé, mais en second rang.
• Le client : sa part augmente s'il a donné l'ordre de lancer l'EIB en Production sans recette validée, ou s'il a fourni un fichier source erroné que le consultant a chargé de bonne foi.

La question des droits d'accès au tenant de Production est centrale. Un consultant qui dispose d'un Security Group lui permettant de lancer des EIB en Production sans validation porte une responsabilité accrue. À l'inverse, un workflow où le run final est déclenché par le client après recette dilue cette exposition.

Un dernier acteur intervient parfois dans l'équation : le fournisseur de la donnée source. Beaucoup d'EIB sont alimentés par un fichier extrait d'un autre système — un ancien SIRH en cours de migration, un fichier RH consolidé, un export d'un éditeur tiers. Si ce fichier source contient lui-même des reference ID erronés ou des colonnes décalées, et que le consultant l'a chargé sans contrôle d'intégrité préalable, la responsabilité se partage encore davantage. D'où l'intérêt de formaliser, dans le contrat de mission, le périmètre exact de votre prestation : concevez-vous l'intégration de bout en bout, ou exécutez-vous un fichier fourni et validé par le client ? Cette frontière contractuelle détermine en grande partie l'étendue de votre exposition.

Un EIB qui réaffecte des organisations relève de la RC Pro : c'est un dommage immatériel causé par une faute professionnelle. Mais certains incidents EIB franchissent une ligne supplémentaire et appellent une couverture cyber :

• Quand la corruption touche l'intégrité de données RH à grande échelle et nécessite une cellule de crise pour reconstruire la base.
• Quand un EIB mal sécurisé expose ou exfiltre des données personnelles via une intégration sortante mal cloisonnée.
• Quand l'incident déclenche une obligation de notification auprès de l'autorité de contrôle ou des personnes concernées.

La RC Pro indemnise le préjudice subi par le client ; la garantie cyber finance la gestion de crise, l'expertise technique d'urgence, les frais de notification et l'accompagnement juridique RGPD. Pour un consultant qui manipule régulièrement des intégrations massives, les deux volets sont complémentaires.

La meilleure assurance contre un EIB destructeur reste la discipline d'exécution. Ce protocole en cinq étapes structure une intervention à risque :

1. Tester sur un tenant Sandbox à jour (refreshé depuis la Production) avec un échantillon représentatif avant tout chargement réel.
2. Lancer en mode « Validate Only » d'abord, pour identifier les erreurs sans écrire dans la base.
3. Prévoir un point de restauration : extraire l'état des tables impactées avant le run, pour pouvoir reconstruire en cas d'écrasement.
4. Limiter le périmètre du premier run à un sous-ensemble, vérifier le résultat, puis étendre.
5. Faire déclencher le run final par le client après recette signée, pour matérialiser sa validation.

Aucune de ces étapes n'est facultative sur un tenant de Production de plusieurs milliers de salariés. Elles ne suppriment pas le risque d'erreur humaine, mais elles le contiennent et nourrissent votre dossier de défense.

Le consultant Workday spécialisé en intégrations porte un profil de risque particulier : il agit sur des systèmes structurants, à fort effet de levier, avec une propagation immédiate vers des tiers. Une simple RC Pro couvre la faute et ses conséquences immatérielles ; un volet cyber prend le relais quand l'incident touche l'intégrité et la confidentialité des données à grande échelle.

Avant d'accepter une mission d'intégration sur un tenant de Production, vérifiez que votre contrat couvre explicitement les missions EIB, Core Connectors et Studio, et que le plafond est cohérent avec la taille des clients que vous servez. La fiche du métier de consultant Workday détaille les garanties à prioriser selon votre spécialité.