Anatomie d’une crise data : 27 systèmes paralysés par un seul champ texte

Un exportateur européen de fruits et légumes nous a permis de cartographier son paysage de données avant un changement d’ERP planifié. Ce que nous avons découvert mérite d’être partagé - car la même architecture, avec les mêmes points de défaillance, se retrouve aujourd’hui dans la plupart des entreprises industrielles de taille moyenne.

Un objectif ambitieux, reposant sur des fondations fragiles

L’entreprise est un exportateur prospère de produits frais, des centaines de millions de chiffre d’affaires, approvisionné par un réseau de coopératives partenaires. La direction avait fixé un objectif clair - des données fiables et en temps réel pilotant l’activité d’ici 2030 - et un nouvel ERP était prévu dans le cadre de cette démarche.

Mais avant de changer le moindre système, la question la plus utile était : à quoi ressemble réellement le paysage aujourd’hui ? La réponse : environ 27 applications distinctes, reliées entre elles par une couche d’Excel sans cesse croissante. Et au centre, assurant une fonction pour laquelle il n’avait jamais été conçu, un système PLM faisant office de hub de données produit de facto - alimenté et vidé par des pipelines ETL bricolés à la main.

Point de défaillance n°1

Le référentiel articles : une base de données dans un champ de texte

Le problème le plus coûteux de tout le paysage était aussi le moins spectaculaire : les données de référence produit. Il n’existait aucun code article structuré. Tout ce qui définit un produit - variété, calibre, catégorie, origine, conditionnement - était concaténé dans un unique champ de désignation en texte libre, saisi par des humains, interprété par d’autres humains.

Les conséquences se propagent en cascade dans tout ce qui se trouve en aval. Vous ne pouvez pas calculer la marge par variété si « variété » n’existe pas en tant que champ. Vous ne pouvez pas rapprocher la ligne de livraison d’une coopérative de votre propre stock si les chaînes d’articles ne correspondent pas. Vous ne pouvez pas dédupliquer ce que vous ne pouvez pas analyser. Un seul champ non structuré au bas de la pile invalide discrètement chaque analyse à son sommet.

Un seul champ de texte libre au bas de la pile invalide chaque analyse à son sommet.

Point de défaillance n°2

Un PLM assurant le rôle d’un hub de données, avec l’ETL comme ciment

Faute de véritable colonne vertébrale des données, le système PLM avait glissé dans ce rôle : il détenait les données produit, et des pipelines ETL bricolés à la main en acheminaient des copies vers le système qui en avait besoin ensuite. Cette architecture échoue de trois manières prévisibles :

• Chaque copie commence à vieillir dès l’instant où elle est créée. L’ETL s’exécute par lots ; entre deux exécutions, les systèmes travaillent sur les données de la veille. Les écarts entre systèmes ne sont pas ici un accident - ils sont inscrits dans la conception.
• Chaque nouveau système implique de nouveaux pipelines. Chaque application se connecte de point à point à plusieurs autres - le classique problème n×m. Avec ~27 applications, le nombre de pipelines, et la facture de maintenance, croît plus vite que le paysage lui-même.
• Le hub devient irremplaçable. Le PLM ne peut être touché sans casser les pipelines qui en dépendent - précisément le verrouillage que les entreprises redoutent d’une plateforme, créé accidentellement faute d’en avoir une.

Et là où les pipelines n’allaient pas, Excel allait. De façon la plus critique à la frontière de l’entreprise : les coopératives partenaires livraient leurs données sous forme de fichiers Excel préparés manuellement - ressaisis, reformatés, sujets aux erreurs, en retard. Le côté approvisionnement d’une activité de plusieurs centaines de millions d’euros entrait dans ses systèmes par des pièces jointes.

Ce que cela coûte

La facture arrive sous forme de stock, de marges, de départs en retraite

Rien de tout cela ne reste un problème informatique. Cela se traduit en chiffres métier :

• La gestion des stocks reposait sur des processus manuels - et l’entreprise elle-même estimait les ruptures de stock et la logistique inefficace qui en résultaient à environ 3 millions d’euros par an.
• La direction ne pouvait pas obtenir d’indicateurs fiables - la marge par vente et les niveaux de stock ne pouvaient être produits de manière cohérente d’un système à l’autre, si bien que les décisions stratégiques se prenaient à l’intuition.
• Le savoir critique reposait dans quelques têtes. La logique non documentée qui faisait tenir l’ensemble du paysage - quelle chaîne désigne quel article, quel fichier va où - était détenue par une poignée d’employés de longue date approchant de la retraite.

Le problème en une image

Le problème en une image
Demandez à trois services le calibre de la même pomme et vous pouvez obtenir trois réponses différentes - les achats la classent pour acheter, la production la trie pour faire tourner la ligne, les ventes la décrivent pour vendre. Aucun n’a tort ; chacun mesure selon son propre objectif, dans son propre système. La pomme n’a jamais changé. La définition commune n’a jamais existé.

L’instinct, et pourquoi il échoue

« Le nouvel ERP va remettre tout cela en ordre »

Un changement d’ERP étant déjà prévu, la conclusion tentante est que la migration corrigera les données en chemin. Ce ne sera pas le cas - et ce paysage montre exactement pourquoi. Le nouvel ERP hériterait des mêmes chaînes d’articles inanalysables, des mêmes données de coopératives non rapprochées, de la même logique ETL orpheline. La migration devient plus difficile, car faire correspondre les incohérences de 27 systèmes à un nouveau noyau est précisément le travail que personne n’a encore fait. Et ensuite, le modèle de données de l’entreprise appartient au nouvel éditeur.

La bonne séquence est l’inverse. D’abord, construire le socle de données - au-dessus des systèmes, détenu par l’entreprise :

• Commencez par le référentiel articles. Définissez un code article structuré unique avec des attributs explicites - variété, calibre, catégorie, origine - et un flux de gouvernance pour créer et modifier les articles. C’est délibérément le premier geste : c’est la racine dont dérive tout autre chiffre.
• Remplacez le hub accidentel. Une seule couche d’intégration reprend le rôle que le PLM et les pipelines ETL peinaient à jouer : chaque système se connecte une fois, et les données sont liées à leur source, et non copiées - ainsi rien ne vieillit entre les exécutions par lots, et les écarts cessent d’être intégrés par conception.
• Intégrez les coopératives au modèle. Les données des partenaires se rattachent aux mêmes définitions structurées dès leur arrivée, au lieu d’être ressaisies depuis des tableurs.
• Codifiez le savoir tribal. La logique de correspondance qui vit dans la tête des gens devient partie intégrante du modèle - et survit aux départs en retraite.
• Migrez ensuite l’ERP - sereinement. Le nouveau système se branche sur un socle qui détient déjà la vérité. Les processus métier au-dessus ne bougent pas. Et la prochaine migration après celle-ci devient moins coûteuse, et non plus difficile.

Un nouvel ERP hérite de vos problèmes de données. Un socle de données rend l’ERP remplaçable.

La leçon est transposable

Recherchez ces quatre signes dans votre propre paysage

Les détails proviennent ici des produits frais, mais l’architecture est partout - dans la chimie, la pharmacie, la machinerie, l’énergie. Les quatre mêmes signes méritent d’être recherchés dans votre propre paysage : un attribut critique logé dans un champ de texte libre; un système faisant office de hub de données qui n’a jamais été conçu pour cela; Excel transportant des données au-delà d’une frontière organisationnelle ; et une migration planifiée censée « corriger les données en chemin ». Chacun d’eux est un avertissement. Les quatre ensemble forment cet article.

Les corriger n’est pas un achat d’outil, et cela n’a pas à attendre le prochain grand programme. Cela commence par une définition structurée d’un objet critique - et un socle au-dessus de vos systèmes qui rend chaque changement ultérieur moins coûteux. Ce socle est précisément ce que le boTec DataBridge est conçu pour être.