Les agents IA dans les systèmes d'ingénierie complexes : pourquoi la structure des données décide de tout
Les grands modèles de langage passent de l'atelier au backbone d'ingénierie. La première vague d'IA industrielle portait sur les données capteurs : maintenance prédictive, vision par ordinateur, optimisation énergétique. La deuxième vague vise quelque chose de plus difficile et de plus précieux : les données d'ingénierie elles-mêmes. Exigences, nomenclatures multi-niveaux, matrices de traçabilité, dossiers de conformité. C'est là que réside réellement la connaissance produit, et c'est là que les LLM peuvent soit faire gagner des milliers d'heures aux équipes d'ingénierie, soit corrompre discrètement le référentiel technique d'un produit réglementé.
Cet article examine les deux issues d'un point de vue technique. Il couvre les cas où l'IA aide réellement en ingénierie industrielle, les raisons pour lesquelles les agents IA échouent dans les systèmes complexes, pourquoi l'hallucination est un problème de données avant d'être un problème de modèle, et comment un Système d'Exploitation d'Ingénierie comme Koddex, à travers son serveur MCP, son modèle de gouvernance et ses mécanismes de verrouillage, de révision et d'audit, rend l'IA agentique utilisable dans des environnements où chaque décision de conception doit résister à un audit.
Où les LLM apportent réellement de la valeur en ingénierie
Passons sur les promesses génériques du type "l'IA va transformer l'industrie". Voici ce que les LLM savent démontrablement bien faire lorsqu'on les applique aux données d'ingénierie :
Lire et recouper de grands volumes de texte semi-structuré. Un dossier de certification pour un sous-système aérospatial ou un dossier technique medtech contient des milliers d'exigences, de procédures de test et de justifications. En vérifier la cohérence est exactement le type de travail exhaustif et peu créatif que les humains font mal et lentement.
Traduire d'un niveau d'abstraction à un autre. Décomposer une exigence système en exigences de sous-système, rédiger des critères de vérification à partir d'un énoncé d'exigence, mapper une clause d'une norme européenne aux éléments de conception qu'elle contraint. Ce sont des tâches d'appariement de motifs sur des relations structurées, et les LLM les gèrent bien quand les relations sont explicites.
Répondre à des requêtes en langage naturel sur des données structurées. "Quelles exigences de cette version n'ont aucun test associé ?" "Quels composants de ce BOM sont affectés par la nouvelle révision de cette norme ?" Aujourd'hui, répondre à ces questions signifie qu'une des trois personnes compétentes de l'entreprise ouvre quatre outils et construit un tableur. Un LLM disposant d'un accès approprié aux données répond en quelques secondes, et n'importe qui peut poser la question.
Construction en masse de données structurées. Bâtir un BOM multi-niveaux, instancier un jeu d'exigences à partir d'une norme, créer des liens de traçabilité à grande échelle. C'est de la saisie de données structurée, et les agents la réalisent plusieurs ordres de grandeur plus vite que les humains.
Le fil conducteur : rien de tout cela n'exige que le modèle invente quoi que ce soit. Cela exige qu'il lise, parcoure et écrive des données structurées de façon fiable. Ce qui nous amène aux modes de défaillance.
Pourquoi les agents IA échouent dans les systèmes complexes
L'hallucination est un problème de contexte
Le mode de défaillance des LLM le plus commenté est l'hallucination : le modèle produit une réponse plausible, assurée et fausse. Il vaut la peine d'en comprendre précisément le mécanisme, car il dicte la solution.
Un LLM ne récupère pas des faits. Il génère la continuation la plus probable étant donné son contexte. Quand le contexte détermine entièrement la réponse, le modèle est exact. Quand le contexte est incomplet, ambigu ou contradictoire, le modèle interpole. Il comble les lacunes avec un contenu statistiquement plausible. Ce n'est pas un bug à corriger ; c'est le principe de fonctionnement de l'architecture.
Considérons maintenant le paysage typique des données d'ingénierie dans une entreprise hardware : des exigences dans Word et Excel, des BOM dans l'ERP et dans trois tableurs divergents, des résultats de tests dans un outil projet, des mappings de conformité dans le dossier local de quelqu'un, et du savoir tribal dans des fils d'e-mails. Donnez cela à un LLM et vous avez fabriqué les conditions exactes qui garantissent l'hallucination. Le modèle doit deviner quelle version de document fait foi, inférer les relations implicites entre artefacts et réconcilier des contradictions qu'il n'a aucun moyen de résoudre. Il fera les trois, avec assurance.
Défaillance concrète : vous demandez à un agent si l'exigence de sécurité REQ-SYS-0142 est couverte par un test de validation. L'agent trouve une procédure de test référençant REQ-SYS-0142 dans un document datant de huit mois. Il répond oui. L'exigence a été révisée depuis ; le test couvre la version obsolète. Personne ne le remarque avant l'audit de certification, ou avant le terrain.
La conclusion que les ingénieurs devraient en tirer : dans les contextes industriels, l'hallucination est avant tout un problème de qualité et de structure des données. Un meilleur modèle sur des données fragmentées hallucine quand même. Un modèle de milieu de gamme sur une source de vérité unique, propre et typée n'hallucine pratiquement pas, parce qu'il n'y a aucune lacune à combler.
Un accès en écriture non gouverné
La lecture est la moitié facile. Les gains de productivité de l'IA agentique viennent de l'écriture : créer des éléments, définir des attributs, restructurer des arbres. Et l'accès en écriture sans gouvernance, c'est ainsi qu'on corrompt un référentiel.
Dans un système complexe, les modifications se propagent. Changez un composant dans un BOM et vous invalidez potentiellement des budgets de masse, des analyses de sécurité, des dossiers de qualification fournisseur et chaque exigence allouée à ce composant. Les ingénieurs expérimentés portent en tête un modèle mental de ces chemins de propagation. Un agent opérant via une API n'a aucun modèle de ce genre, à moins que le système n'expose explicitement le graphe de dépendances et n'applique les règles au niveau de la donnée.
Les garde-fous au niveau du prompt ("ne pas modifier les éléments gelés") ne sont pas des garde-fous. Ce sont des suggestions adressées à un système probabiliste. Quiconque a fait tourner des agents en production sait que les instructions présentes dans le contexte finissent ignorées sous l'effet des contextes longs, des chaînes d'appels d'outils et des cas limites. L'application des règles doit vivre dans la plateforme, pas dans le prompt.
Une redevabilité rompue
Les industries réglementées reposent sur des décisions attribuables. Qui a modifié cette exigence, quand, pourquoi, et qui l'a approuvée. Si les agents écrivent dans les données d'ingénierie sans que leurs actions soient versionnées et journalisées avec la même rigueur que les actions humaines, la chaîne de traçabilité se rompt. Un auditeur qui trouve des modifications non attribuées dans un dossier d'historique de conception se moque qu'une IA les ait faites. Le constat est le même : perte de maîtrise de la configuration.
Une exposition incontrôlée des données
Connecter un LLM aux données d'ingénierie soulève aussi des questions de périmètre : données soumises au contrôle des exportations dans les programmes de défense, données de conception confidentielles, tarifs fournisseurs. Un agent capable de tout lire est un canal d'exfiltration. Le contrôle d'accès doit s'appliquer aux agents exactement comme il s'applique aux utilisateurs.
La réponse architecturale : structurer d'abord, connecter ensuite, gouverner enfin
Il y a deux réponses à ces risques. Interdire l'IA sur les données d'ingénierie et accepter un écart de productivité grandissant face aux concurrents qui ne l'ont pas fait. Ou bâtir les conditions dans lesquelles l'IA agentique est sûre. La seconde exige trois couches, dans cet ordre.
Couche 1 : une source de vérité unique et typée
Koddex est un Système d'Exploitation d'Ingénierie : il unifie les exigences, les composants, la traçabilité et les données de conformité en un seul backbone doté d'un modèle de données explicite. Chaque élément est un objet typé avec des attributs définis et des relations explicites. Une exigence sait quels tests la vérifient. Un composant sait quels assemblages le contiennent. Une clause de norme sait quelles exigences l'implémentent. Les révisions sont de première classe : chaque élément porte son arbre de révisions, et une seule version fait foi.
C'est la couche anti-hallucination, et il vaut la peine d'être précis sur le pourquoi. Un LLM connecté à ce graphe n'infère pas les relations ; il les parcourt. Il ne devine pas quelle version est courante ; le modèle de référence le dit. Il ne réconcilie pas des tableurs contradictoires ; il n'y en a aucun. Les lacunes qui forcent l'interpolation ont disparu, si bien que la sortie du modèle se réduit, au meilleur sens du terme, à de la lecture. La réponse de l'agent à "REQ-SYS-0142 est-elle couverte" devient le résultat d'une requête sur le graphe, pas une reconstruction probabiliste à partir de documents périmés.
Dit autrement : structurer les données, c'est ce qui permet à l'IA de comprendre le système. La compréhension, pour un LLM, ce n'est pas de l'intelligence dans le modèle. C'est de la complétude et de l'explicitude dans le contexte. Le modèle de données de Koddex est ce contexte.
Couche 2 : le serveur MCP
Pour connecter les modèles à cette source de vérité, Koddex expose un serveur MCP. MCP (Model Context Protocol) est le standard ouvert émergent pour relier les assistants IA à des systèmes externes, et il compte ici pour une raison pratique : il rend le backbone d'ingénierie accessible depuis l'assistant que l'organisation utilise déjà, avec des outils typés plutôt qu'avec du grattage d'écran ou des intégrations sur mesure fragiles.
À travers le serveur MCP de Koddex, un agent peut rechercher des éléments dans tout l'arbre de l'organisation, récupérer les détails complets d'un élément avec ses valeurs et ses relations, parcourir un arbre d'éléments sur plusieurs niveaux, créer des éléments sous un parent, définir des valeurs d'attributs, ajouter ou déplacer des enfants dans une structure de BOM, et lier des exigences réglementaires issues de normes européennes directement aux éléments de conception qu'elles contraignent.
À quoi cela ressemble en pratique :
Un ingénieur décrit une architecture produit en langage naturel et l'agent construit le BOM multi-niveaux : il crée les éléments, les type, définit les attributs, établit les relations parent-enfant. Des jours de saisie de données structurées deviennent des minutes, et le résultat atterrit dans le modèle gouverné, pas dans un énième tableur orphelin.
Un ingénieur conformité demande à l'agent de rattacher les exigences applicables d'une norme aux sous-systèmes concernés. L'agent crée les éléments d'exigence et les liens de traçabilité en une seule passe.
Un chef de programme pose des questions de couverture en langage courant et obtient des réponses calculées à partir du modèle vivant. Aucun export, aucune expertise outil requise.
Ce dernier point est le plus sous-estimé. Le goulot d'étranglement dans la plupart des organisations d'ingénierie n'est pas que la donnée n'existe pas ; c'est que seule une poignée de personnes sait l'extraire. Un LLM au-dessus d'une source de vérité unique supprime la barrière du langage de requête. L'accès aux données cesse d'être une compétence de spécialiste et devient disponible pour tous : conception, qualité, achats, gestion de programme, tous interrogeant le même modèle qui fait foi.
Couche 3 : une gouvernance qui lie agents et humains à parité
L'accès en écriture pour les agents n'est acceptable que si la plateforme applique les règles, indépendamment des prompts. Koddex applique trois mécanismes de façon uniforme aux acteurs humains et IA.
Les verrous. Les éléments validés peuvent être verrouillés. Un élément verrouillé rejette toute modification au niveau de la plateforme, quel que soit l'auteur ou l'origine de la demande. Une exigence gelée pour un jalon de certification reste gelée. Il n'est pas nécessaire de dire à l'agent de ne pas y toucher ; il ne le peut pas. C'est toute la différence entre un garde-fou et un vœu pieux.
Les révisions. Les changements substantiels n'écrasent pas ; ils créent une nouvelle révision dans l'arbre de révisions de l'élément, les versions antérieures étant conservées et comparables. Quand un agent rédige une exigence remaniée, le brouillon entre dans le même flux de révision qu'une modification humaine : relisible, comparable, réversible, approuvé par les personnes qui en répondent. L'agent accélère la production ; la décision reste humaine.
L'historique d'activité complet. Chaque action sur chaque élément, création, changement de valeur, lien ajouté ou retiré, est journalisée avec auteur et horodatage. Les actions des agents sont enregistrées de façon identique aux actions humaines. La chaîne de redevabilité qu'exigent les auditeurs reste intacte, et revoir ce qu'un agent a fait pendant une opération en masse relève d'une requête, pas d'une enquête.
Livrer pour l'audit
Ces mécanismes convergent vers le principe de fonctionnement que Koddex appelle livrer pour l'audit. Dans le hardware réglementé, la vitesse sans preuve ne vaut rien. Un dossier de certification doit démontrer, à tout instant, qui a fait quoi, sur quelle révision, sous quelle justification. En combinant la source de vérité unique avec les verrous, les révisions et l'historique d'activité complet, la plateforme permet aux équipes d'utiliser des agents pour bâtir des modèles et des données à la vitesse de l'IA tout en produisant en continu les preuves d'audit que les autorités exigent. Vélocité et maîtrise de la configuration cessent d'être un arbitrage.
Ce qu'il faut retenir
Trois points, pour les ingénieurs qui évaluent l'IA agentique sur leurs données d'ingénierie :
L'hallucination est une propriété du contexte que vous fournissez, pas seulement du modèle que vous choisissez. Des données fragmentées et contradictoires garantissent des réponses fausses et assurées. Une source de vérité unique et typée supprime les lacunes qui forcent le modèle à interpoler. Corrigez les données avant d'accuser le modèle.
Ne comptez jamais sur les prompts pour la gouvernance. L'application des règles appartient à la couche de données : des verrous qui rejettent structurellement les écritures, des révisions qui rendent chaque changement réversible et relisible, des journaux d'activité qui traitent les agents comme des acteurs redevables.
Le bénéfice de réussir les deux n'est pas marginal. Ce sont des BOM construits en quelques minutes, des normes mappées aux conceptions en une seule passe, et des données d'ingénierie interrogeables en langage courant par toute l'organisation, le tout pendant que la piste d'audit s'écrit d'elle-même.
C'est là le rôle d'un Système d'Exploitation d'Ingénierie : donner à l'IA ce qui lui manque par construction, un modèle complet du système et des règles appliquées pour y toucher. Pour les équipes de l'aérospatial, de la défense, de la medtech, du nucléaire et de la robotique, c'est la différence entre l'IA comme risque et l'IA comme levier.
Découvrez le Système d'Exploitation d'Ingénierie ou réservez une démo.
