Un groupe européen de construction navale a mené sa modernisation IT dans les règles de l’art - un ERP cloud maintenu proche du standard, un PLM comme référentiel des données produit, une véritable organisation IT centrale. Et il s’est quand même heurté à un mur. Parce que les problèmes de données les plus difficiles ne se trouvent à l’intérieur d’aucun système. Ils se trouvent entre eux.
Une entreprise qui mène bien sa modernisation
Ce n’est pas l’histoire d’une entreprise qui a négligé son informatique. Le groupe - environ 800 personnes réparties sur plus de huit sites, en croissance rapide par acquisitions - avait passé trois ans à bâtir ce qui manque encore à la plupart de ses pairs : une véritable organisation IT centrale, une sécurité renforcée, une infrastructure moderne et un programme de transformation à l’échelle de l’entreprise.
L’architecture cible était, elle aussi, exemplaire : SAP S/4HANA Public Cloud comme ERP central, délibérément maintenu proche du standard; un PLM de premier plan positionné en amont comme référentiel des données produit ; un principe clair de continuité numérique - la donnée est créée une seule fois, vit dans son système de référence et y est consommée sans duplication. Environ 600 utilisateurs, jusqu’à l’atelier de production, travaillent quotidiennement dans l’ERP.
Et pourtant, le déploiement n’a cessé de buter. Pas sur les systèmes - sur ce que les acquisitions avaient laissé derrière elles, et sur tout ce qui doit circuler entre les systèmes.
Point de rupture n° 1
Chaque acquisition apportait sa propre vérité
La croissance par acquisition est un événement de données, pas seulement financier. Chaque entreprise rachetée arrivait avec ses propres systèmes, ses propres codes articles, ses propres fiches fournisseurs - et personne ne fusionne les données de référence dans le feu de l’action d’une transaction. Le résultat, des années plus tard : un référentiel articles d’environ 25 000 références truffé de doublons, et un référentiel fournisseurs dans le même état. La même pièce physique existe en plusieurs exemplaires, sous des codes différents, sur des sites différents.
Une pièce physique - telle que les systèmes du groupe la connaissent
| Site A (ERP hérité) | « WIN-2240 , winch handle 10″ alu » |
| Site B (outil local) | « 100-4471 , Winschkurbel 250mm » |
| Site C (tableur) | « MANIVELLE WINCH ALU 10P » |
| fiches fournisseurs | 3 - même fournisseur, trois orthographes |
Trois codes, trois descriptions, une seule pièce. Le volume d’achats consolidé, le stock réel et tout KPI à l’échelle du groupe se dissolvent exactement à ce point.
Les dégâts sont silencieux mais cumulatifs : les achats ne voient pas leur volume réel par fournisseur, du stock existe sur un site pendant qu’un autre recommande la même pièce, et tout chiffre au niveau du groupe est l’agrégation de données qui n’ont jamais été réconciliées. Migrer cela dans un nouvel ERP propre ne le corrige pas - cela l’importe.
Point de rupture n° 2
Une pièce, deux vérités légitimes
Même là où les doublons sont résolus, un problème plus subtil demeure - et celui-ci ne peut pas être nettoyé, parce que personne n’a tort.
Le problème en une image
Prenons un panneau de pont en composite. Le bureau d’études le classe selon ce qu’il est : un composant structurel en composite, dans une famille technique aux côtés des coques et des cloisons. Les achats le classent selon la façon dont il est acheté : il se retrouve sous l’accastillage de pont, avec la logique fournisseur et catégorie d’achat qu’implique cette catégorie. Les deux classifications sont correctes - pour leur usage. Forcer un service à adopter la logique de l’autre en casse une. Alors une seconde hiérarchie parallèle est construite et maintenue à la main, indéfiniment.
C’est le piège de la standardisation : vouloir s’accorder sur la seule bonne classification, alors que le vrai besoin est que plusieurs vues correctes du même objet coexistent - reliées entre elles, et non aplaties les unes dans les autres. L’harmonisation plutôt que la standardisation. La plupart des projets de données de référence échouent précisément parce qu’ils tentent cet aplatissement.
Le bureau d’études et les achats ont tous deux raison. L’architecture doit le permettre.
Point de rupture n° 3
Un connecteur unique et limité - et un plafond que la personnalisation ne peut franchir
Entre le PLM et l’ERP se trouvait exactement une intégration : un connecteur figé transportant les articles, les nomenclatures et les gammes, dans un seul sens. Nécessaire - et loin d’être suffisant. L’entreprise avait besoin de flux que le connecteur ne couvre tout simplement pas :
- Des données qui reviennent. Les prix d’achat réels et les niveaux de stock en temps réel ont leur place devant les ingénieurs dans le PLM - les décisions d’ingénierie se prennent sur la base de prix cibles que la réalité des achats a depuis longtemps dépassés. Le connecteur ne permet le flux de données que dans l’autre sens.
- Chaque domaine adjacent, sa propre interface. Gestion des temps et présences, maintenance, retours de production, état des entrepôts - chacun nécessite sa propre liaison point à point, chacune avec sa propre logique, chacune retestée à chaque mise à niveau. Une prolifération de connecteurs, une interface bien intentionnée à la fois.
- Un atelier qui contourne ses propres outils. Les interfaces de reporting de production construites par l’intégrateur étaient si lourdes que les personnes censées les utiliser les évitaient - et la qualité des données s’en ressentait.
La voie de secours classique est fermée, par conception : un ERP en cloud public limite délibérément la personnalisation profonde. C’est le bon choix - c’est ce qui sécurise les mises à niveau - mais cela signifie que les lacunes ne peuvent pas être comblées à l’intérieur de l’ERP. Elles ont donc été comblées au seul endroit restant : Excel. Les KPI étaient assemblés par extraction manuelle et macros - lents, fragiles, non documentés et dépendants de la poignée de personnes qui savent comment fonctionnent les macros. Le reporting du groupe reposait sur une infrastructure critique logée dans des tableurs.
Le paysage au connecteur unique : un seul flux gouverné, et tout le reste improvisé autour.
Un cœur moderne maintenu propre - et la complexité n’a pas disparu. Elle s’est déplacée dans les interstices entre les systèmes.
La sortie de crise
Pas un connecteur plus gros. Une couche entre tout.
Aucun de ces problèmes ne se résout à l’intérieur de l’ERP ou du PLM - ils se situent tous entre les systèmes. C’est pourquoi la réponse n’est pas un connecteur plus large, davantage d’interfaces ou un data lake rempli de copies. C’est une seule couche d’intégration au-dessus des systèmes, qui accomplit cinq tâches à la fois :
- Résoudre les doublons - progressivement, dans la couche. Les 25 000 articles sont rapprochés d’une référence harmonisée unique : la majeure partie automatiquement, le reste par revue guidée. Les sites conservent leurs codes locaux ; le groupe gagne une identité unique par pièce et par fournisseur - sans nettoyage big-bang, sans recodage forcé.
- Laisser les deux vérités coexister. Les familles techniques du bureau d’études et la logique catégorie des achats deviennent deux vues gouvernées reliées aux mêmes objets - maintenues une seule fois, en un seul endroit, au lieu d’être des hiérarchies parallèles maintenues à la main.
- Rendre les flux bidirectionnels et gouvernés. Les nomenclatures circulent vers l’ERP ; les prix réels et les stocks reviennent vers le bureau d’études. Le sens, la propriété et les règles de conflit sont explicites - la donnée reste dans son système de référence, exactement comme l’exige le principe de continuité numérique du groupe lui-même.
- Sortir la logique des tableurs - sans la mettre dans l’ERP. La logique de KPI et d’intégration logée dans les macros Excel passe dans la couche : documentée, reproductible, plus liée au cycle de versions de l’ERP ni aux trois personnes qui comprennent les macros. L’ERP cloud reste standard - ce qui était le but.
- Donner à l’atelier des interfaces que les gens utilisent vraiment. Des applications orientées tâches sur tablette, téléphone ou terminal reposent sur la couche et écrivent en retour dans le bon système central sous-jacent - l’UX découplée des systèmes de référence.
Et la prochaine acquisition - il y en aura une - cesse d’être une crise de données : les systèmes de la nouvelle entreprise se connectent une fois à la couche et se rattachent à la même référence harmonisée, au lieu d’ajouter un nouveau millier de doublons à la pile.
La leçon se transpose
Le paradoxe du cœur propre
Voici la partie qui se généralise bien au-delà de la construction navale : plus vous êtes rigoureux dans le maintien de vos systèmes centraux dans leur configuration standard, plus vous avez besoin d’un endroit dédié pour tout ce qui n’y entre pas. Identités inter-systèmes, classifications coexistantes, flux bidirectionnels, KPI à l’échelle du groupe, UX d’atelier - rien de tout cela n’a sa place dans un ERP standard, et l’y forcer est précisément ainsi que se construit la dette technique.
Les signaux d’alerte à repérer dans votre propre paysage : un référentiel articles ou fournisseurs gonflé par les acquisitions; des hiérarchies de classification parallèles maintenues à la main; un connecteur figé transportant une fraction de ce qui doit réellement circuler; et des macros Excel devenues discrètement une infrastructure critique. Chacun est une lacune entre les systèmes - et une couche entre les systèmes est ce qui les comble. C’est précisément ce que la boTec DataBridge permet de mettre en place.