« La discipline n'est pas une contrainte, c'est l'infrastructure de la performance. » C'est sur cette phrase que Stéphane Dicostanzo, CEO et Valentin, co-fondateurs de Koddex, ont ouvert leur conférence au Tech For Industry Show, consacrée à un concept encore méconnu mais déjà pratiqué par les meilleures équipes d'ingénierie : l'Engineering Operating System. Un sujet au croisement du PLM, de la qualité des données et de l'IA agentique — et un enjeu direct de compétitivité pour l'industrie du futur.

Le monde de l'ingénierie hardware ne ressemble pas au reste du numérique : un produit industriel, c'est des dizaines de milliers de composants, des milliers de spécifications et des centaines d'exigences réglementaires, tous liés entre eux dans une infinité de dépendances. Modifier un seul élément impose une analyse d'impact sur toute la chaîne — et une erreur découverte après la production peut être critique.

Pour gérer cette complexité, les entreprises s'appuient sur de grands référentiels — PLM, ERP, QMS — entre lesquels s'est construit un maillage non structuré de fichiers Excel et d'outils collaboratifs. Résultat : des données dupliquées et dispersées, des efforts considérables de réconciliation, et un constat frappant partagé en séance : la moitié du coût d'un projet est absorbée par sa propre structure — vérifier les données, organiser le suivi des validations et traiter les non-conformités auto-générées.

L'Engineering OS repose sur trois couches trop souvent désolidarisées : les processus (qui fait quoi, pourquoi, comment — avec entrées, sorties et responsabilités formalisées) ; le modèle de données (chaque geste métier doit avoir son équivalent digital, pensé pour répondre au processus, et non hérité par défaut d'un outil) ; et la donnée opérationnelle, celle qui est réellement saisie sur le terrain.

Le constat des intervenants, forgé au fil de leurs expériences (notamment chez Google pour Valentin) : les équipes les plus performantes ont — sans toujours le théoriser — ancré ces trois couches ensemble. Impossible de modifier un processus sans faire évoluer son modèle de données ; impossible, surtout, de déformer la donnée opérationnelle en bout de chaîne sans en voir l'impact global. Les bénéfices : baisse du coût d'alignement (moins de réunions de synchronisation, moins de vérifications manuelles), réduction de la non-qualité, meilleur onboarding et traçabilité retrouvée.

La mise en œuvre suit quatre étapes : définir les processus métiers, modéliser les données qui s'y rapportent, les connecter entre elles — l'étape la plus souvent négligée — et forcer l'instanciation de la donnée sur la base des modèles définis.

Cas concret partagé en séance, issu d'un client de la robotique : définir ce qu'est « un composant » pour l'entreprise. La R&D, l'industrialisation, le déploiement et la maintenance ont chacun leurs attributs — parfois le même attribut avec deux significations différentes. L'Engineering OS met tout cela à plat, puis crée des liens sémantiques : un composant implémente une exigence, une exigence est vérifiée par un cas de test. De proche en proche se construit un knowledge graph de tous les objets de l'entreprise : le technicien intervenant chez un client accède à toute l'histoire du produit — fabrication, révision logicielle, spécifications — et l'ingénieur qui remplace une vis voit instantanément l'analyse d'impact sur tout le produit.

Deux approches dominent aujourd'hui : le template comme structure (catalogues de documents Word/Excel, gates et réunions de vérification — formalisme clair mais effort énorme) et la supervision a posteriori (BI et tour de contrôle — mais l'erreur est détectée trop tard pour être corrigée à la source). L'Engineering OS combine les deux, à la manière d'un compilateur informatique : la donnée est structurée à l'entrée et sa cohérence vérifiée en continu sur toute la chaîne. Et comme dans le software, le modèle est versionné : quand une nouvelle réglementation impose par exemple de renseigner l'empreinte carbone du produit, il suffit de créer une nouvelle version du modèle de données et des liens sémantiques — avec une « compilation en cascade » qui garantit que rien ne casse ailleurs.

Demain, ce ne sont plus seulement les humains qui saisiront la donnée, mais les agents IA. Or, brancher un agent sur des documents non structurés impose de parcourir des volumes énormes de données pour en extraire une information potentiellement fausse : plus le contexte est large, plus le risque d'hallucination statistique augmente — et plus on gaspille de tokens et d'énergie.

À l'inverse, une donnée déjà structurée en knowledge graph donne à l'agent la carte des liens : il cible un contexte étroit, hallucine moins et consomme moins. Les POC d'agents « extract + questions » montrent la valeur mais ne passent pas à l'échelle, ni dans l'entreprise ni dans le temps. L'Engineering Operating System, lui, force naturellement à composer, remplir et faire évoluer ce graphe — au bénéfice des opérationnels d'aujourd'hui comme de l'agentique de demain.

Les intervenants ont théorisé le concept, mais aussi créé Koddex, une plateforme dédiée : elle connaît la carte des données attendues, valide en temps réel l'impact des modifications, se connecte aux référentiels de l'entreprise (PLM, ERP) et trace nativement liens, historiques et révisions pour maintenir la cohérence dans le temps.

Retrouvez l'intégralité de cette conférence, ainsi que les autres replays du Tech For Industry Show, sur notre page dédiée.