Software & Tools
La stack PLM moderne, couche par couche, et la place de Koddex
Un industriel ne travaille pas avec un seul outil d'ingénierie. Il travaille avec une stack : du modèle CAO de l'ingénieur jusqu'à l'ordre de fabrication à l'atelier, chaque couche a son rôle, ses éditeurs et ses données.
Le modèle en couches ci-dessous a été popularisé par Anup Karumanchi, de PLM Coach. Nous l'avons redessiné, et nous y avons ajouté la couche qu'occupe Koddex.
KoddexConcevoir le produit : CAO, simulation, PDM
La conception (CAO) est l'endroit où les ingénieurs créent modèles 3D et plans : SOLIDWORKS, CATIA, Siemens NX, Creo, Inventor, Onshape. Elle possède la géométrie, et rien d'autre.
La simulation (CAE) teste les conceptions virtuellement, avant de fabriquer : Ansys, Abaqus, Simcenter, COMSOL. Optionnelle pour certains produits, indispensable pour d'autres, des structures à la thermique et à l'électromagnétisme.
La gestion de données (PDM) met les fichiers CAO au coffre, gère les entrées et sorties et conserve les versions : Autodesk Vault, SOLIDWORKS PDM, Windchill PDMLink. Elle vit souvent à l'intérieur du PLM.
Gérer le produit : la plateforme PLM
Le PLM gère la définition du produit sur son cycle de vie : nomenclatures, gestion des changements, workflows. Les grandes plateformes sont Teamcenter, Windchill et 3DEXPERIENCE ; Aras Innovator est l'option à architecture ouverte ; Arena et Propel sont des PLM cloud, appréciés des jeunes entreprises hardware.
Le PLM est le référentiel de la définition fabricable : ce qu'est la pièce, quelle révision est libérée, quel ECO l'a modifiée.
Faire circuler la donnée et fabriquer : intégration, ERP, MES
La couche d'intégration fait circuler articles, nomenclatures et changements entre les systèmes : MuleSoft, Boomi, Apache Kafka, ou des API REST et OSLC directes.
L'ERP pilote planification, stocks, achats et coûts : SAP S/4HANA, Oracle ERP, Dynamics 365, Infor, Epicor.
Le MES exécute les ordres de fabrication à l'atelier et enregistre le tel-que-construit : Siemens Opcenter, DELMIA Apriso, Plex, AVEVA MES.
L'infrastructure est l'endroit où tout tourne : AWS, Microsoft Azure, Google Cloud, ou sur site.
Ce que la stack laisse encore ouvert
Chaque couche est construite autour de son propre objet : la géométrie, le fichier, la pièce, l'ordre de fabrication. Chacune fait bien son travail. Mais les questions que les équipes d'ingénierie posent chaque semaine traversent les couches.
Quelle exigence cette pièce satisfait-elle, et quel essai le prouve ? Que touche ce changement dans la CAO, la nomenclature, les essais et les unités déjà livrées ? Le produit est-il conforme aujourd'hui, et où sont les preuves ? Quels robots ou quelles portes portent le lot défectueux qu'un fournisseur vient de signaler ?
Aucune couche n'y répond seule. Les exigences vivent souvent dans des documents et des tableurs hors de la stack ; les résultats d'essais dans un autre outil ; les preuves de conformité dans des dossiers partagés. Les liens entre eux se reconstruisent à la main, en réunion et dans des tableurs, souvent par la seule personne qui sait où tout se trouve.
Ce travail manuel a un coût mesurable. Dans une étude par échantillonnage du travail de 78 ingénieurs de conception, chercher, recevoir et transmettre de l'information occupait environ 56 % du temps de travail.
Et plus un lien rompu est découvert tard, plus il coûte cher. L'étude de la NASA sur l'escalade du coût des erreurs évalue le coût de correction d'une erreur d'exigence à 21 à 78 fois son coût initial lorsqu'elle atteint l'intégration et les essais.
Coût relatif de correction d'une erreur d'exigence
La couche d'intégration fait circuler la donnée entre les systèmes. Elle ne porte pas le raisonnement : pourquoi une valeur est ce qu'elle est, ce qui en dépend, et ce qu'un changement va casser.
La place de Koddex
Koddex ajoute la couche manquante : une couche de connaissance d'ingénierie qui traverse toutes les couches, de la CAO à l'intégration, et alimente l'ERP et le MES en dessous.
Il porte exigences, nomenclature, essais, décisions et documents comme des données reliées, dans un modèle que vous définissez avec votre vocabulaire, et il calcule dessus : consolidations de masse et de coût, couverture des exigences et des essais, impact d'un changement avant sa validation.
Il ne remplace pas les couches qui l'entourent. La CAO reste dans la CAO, la pièce libérée dans le PLM, les achats dans l'ERP, le tel-que-construit dans le MES. Koddex lit ce que chacune sait du produit, et ajoute ce qu'aucune ne porte : les liens.
Prenons un changement. Un fournisseur passe une équerre à un nouvel alliage. Le modèle CAO reçoit une nouvelle révision, le PLM un ECO, l'ERP une nouvelle référence fournisseur. Dans Koddex, le même changement montre d'un coup l'exigence de masse que sert l'équerre, l'essai de fatigue qui ne la prouve plus, les deux variantes du produit qui l'utilisent et les unités déjà livrées. L'ingénieur voit l'impact avant de valider, au lieu de le découvrir à l'intégration.
| Couche | Koddex lit | Koddex apporte |
|---|---|---|
| CAO et PDM | Pièces, plans et modèles rattachés aux articles qu'ils définissent | Exigences et impacts sur chaque pièce |
| PLM | Articles, révisions, ECO | Couverture exigences et essais, impact avant validation |
| ERP | Identifiants partagés, fournisseurs, coûts, numéros de série | La définition d'ingénierie selon laquelle chaque unité est construite |
| MES | Tel-que-construit par numéro de série | Les unités qu'un changement ou un lot défectueux atteint |
| Git, Jira, documents | Releases firmware, tickets, spécifications | Liens vers le hardware et les exigences concernés |
Koddex se connecte par son API REST et GraphQL, et expose un serveur MCP pour que des agents IA, ceux de Koddex ou les vôtres, lisent et écrivent dans le graphe dans les droits qu'on leur donne. Ils travaillent sur des branches ; un ingénieur valide chaque résultat avant qu'il n'entre dans la référence.
Côté infrastructure, Koddex est hébergé dans l'Union européenne, dans la région AWS Europe (Irlande).
À travers la pyramide, pas seulement à travers les outils
La stack est horizontale : des outils côte à côte, chacun couvrant une étape de la vie du produit. Une entreprise est aussi verticale. La norme ISA-95 sépare déjà la gestion de l'entreprise (ERP, niveau 4) des opérations de fabrication (MES, niveau 3), parce que chaque niveau pose des questions différentes. La donnée d'ingénierie doit les atteindre tous.
La direction veut savoir où en est le programme et si le produit est conforme. Les responsables ingénierie veulent toutes les équipes sur le même process, avec responsables et livrables. Les ingénieurs veulent l'impact d'un changement avant de le valider. La production et la qualité ont besoin de la bonne révision pour chaque fabrication, et des preuves pour chaque audit. Fournisseurs et partenaires ont besoin d'une vue limitée à ce sur quoi ils travaillent.
Dans la plupart des entreprises, chaque niveau reçoit son propre extrait : une présentation pour la direction, un tableur pour le manager, un export CSV pour le fournisseur. Les extraits divergent le jour même où ils sont produits.
Koddex est une seule donnée lue à chaque niveau, avec des droits d'accès posés sur chaque élément. Personne ne reconstruit de reporting, et personne ne travaille sur une copie périmée.
Koddex- Direction et programmesÉtat du programme et conformité calculés, pas rapportés
- Responsables ingénierieModèles, un process de A à Z, responsables et tableaux de bord
- IngénieursExigences, BOM, essais et impact de chaque changement
- Production et qualitéTel-que-construit par numéro de série, FAI et preuves d'audit
- Partenaires et fournisseursAccès limité aux éléments sur lesquels ils travaillent
Pourquoi les agents IA ont besoin de cette couche
L'IA arrive dans chaque couche de la stack : des copilotes dans la CAO, des assistants dans le PLM, des bots dans l'ERP. Chacun ne voit que sa couche. Demandez-lui ce qu'un changement va casser : il ne peut répondre que si les liens entre exigence, pièce, essai et unité existent quelque part où il peut les lire.
Le Model Context Protocol est le standard ouvert qui donne aux agents un contexte structuré. Koddex expose son graphe via un serveur MCP, avec des comptes de service et des tags d'accès : Claude, ChatGPT ou vos propres agents lisent le même contexte relié que vos ingénieurs, et rien en dehors de leur périmètre.
Les agents travaillent comme les développeurs avec le code. Un déclencheur, une révision CAO, une release logicielle, un document fournisseur ou une tâche que vous assignez, lance le travail. L'agent lit ce dont il a besoin, calcule les consolidations en Python isolé et prépare le changement sur une branche. Un ingénieur le relit comme une pull request. Seul un changement validé entre dans la référence, et chaque action reste dans l'activité de l'élément.
- 1DéclencheurUne révision CAO, une release logicielle, un PDF fournisseur, ou une tâche assignée
- 2ContexteL'agent lit les éléments reliés dont il a besoin via MCP, dans son périmètre d'accès
- 3Travail sur une brancheIl calcule les consolidations en Python isolé, met à jour les éléments et prépare le changement
- 4Revue de l'ingénieurUn ingénieur relit le résultat comme une pull request, valide ou demande des modifications
- 5Référence et journalLe changement validé entre dans la référence ; chaque action reste dans l'activité de l'élément
L'enjeu n'est pas de laisser l'IA modifier seule le produit. C'est de lui faire préparer le travail, extraire les exigences d'une spécification, rédiger une analyse d'impact, compiler les preuves d'un audit, pour que les ingénieurs consacrent leur temps aux décisions.
Ce que cela vaut
Chez notre client de référence, Exotec, qui utilise Koddex avec plus de 1 000 licences et 20 organisations partenaires, une analyse d'impact de changement est passée de deux semaines de réunions et de tableurs à une journée, et la recherche de la bonne information de 45 minutes à 10 secondes, après un an d'utilisation.
Sur des déploiements accompagnés, des équipes ont réduit leur time to market jusqu'à 30 % et le temps passé sur les tâches d'ingénierie répétitives jusqu'à 50 %, et réuni leurs preuves d'audit en moins d'une heure au lieu de trois semaines. Ce sont des fourchettes observées sur des déploiements, pas une moyenne auditée.
La réglementation va dans le même sens. La Digital Engineering Strategy du département américain de la Défense demande une source de vérité faisant autorité sur tout le cycle de vie d'un système. En Europe, le règlement Machines 2023/1230 s'applique dès le 20 janvier 2027 et demande aux fabricants un dossier technique montrant comment chaque exigence de sécurité est satisfaite. Les deux supposent des liens que la plupart des stacks gardent encore dans des tableurs.
Deux configurations types
Une entreprise qui passe du projet au produit. Elle a une CAO, parfois un PDM, un ERP léger et beaucoup de tableurs. Un PLM lourd se profile, sans être encore justifié. Ici, Koddex est la colonne vertébrale : un seul modèle pour exigences, nomenclature, essais et changements, connecté à la CAO et à l'ERP, en quelques semaines plutôt qu'en mois. Si un PLM arrive plus tard, Koddex s'y connecte.
Un grand groupe équipé de Teamcenter, Windchill ou 3DEXPERIENCE. Le PLM reste le référentiel. Koddex se place à côté et relie les articles du PLM aux exigences, essais et preuves de conformité qui vivent ailleurs, pour que l'analyse d'impact et les audits ne dépendent plus de tableurs. Rien n'est remplacé.
Choisir sa stack
Trois questions aident à placer chaque outil. Quel objet possède-t-il ? Où vit la vérité de cet objet ? Et quelles questions transverses votre équipe traite-t-elle encore à la main ?
C'est la dernière qui coûte des heures. C'est aussi là que les agents IA ont besoin d'un contexte structuré et relié pour aider, au lieu de deviner.
La stack décrite ici ne va pas disparaître. Ce qui change, c'est la couche qui la relie.
