Glossaire · Méthodologie
PLM agile : pourquoi la vraie réponse est un Engineering OS
Les équipes qui cherchent un « PLM agile » veulent en général une chose : un substrat qui bouge à la vitesse ingénieur sans perdre la rigueur exigée par la certification. Koddex n'est pas un PLM agile, c'est un système d'exploitation pour ingénieurs qui possède le graphe typé des exigences, BOM, tests et baselines sur un seul substrat. La cadence agile ci-dessous découle de cette architecture ; cette page est la référence opérationnelle de ce que ça donne en pratique.
L'agilité + la rigueur, c'est une face d'un Engineering OS
Les équipes qui cherchent « PLM agile » essaient en général de corriger un symptôme : le PLM lourd bouge trop lentement face à la façon dont l'équipe travaille réellement. Corriger ce symptôme avec un autre PLM n'en règle qu'une partie. Koddex n'est pas un PLM agile, c'est un système d'exploitation pour ingénieurs qui possède tout le graphe d'ingénierie et le transforme en excellence opérationnelle. La cadence agile ci-dessous découle de cette architecture, pas d'un toggle de feature sur un PLM plus léger — et c'est ce qui fait de l'infrastructure d'ingénierie un avantage industriel.
La différence de cadence, sur un scénario ingénieur
Un change request, « remplacer le moteur BLDC par une variante haut-couple », touche exigences, BOM, routage harnais, analyse thermique, deux plans de test, un enregistrement de qualification fournisseur. Mêmes checkboxes dans les deux cas. C'est dans la cadence quotidienne que les catégories divergent.
Création du change request
Stack PLM-centrée
Formulaire ECR ouvert dans le PLM, rempli manuellement avec les pièces affectées cherchées dans une BOM tableur séparée. L'initiateur estime l'impact de mémoire. L'ECR attend dans la inbox jusqu'au prochain CCB.
Engineering OS (Koddex)
L'initiateur sélectionne l'entité moteur dans le graphe. Le système calcule l'impact set automatiquement : 12 composants dépendants, 4 exigences, 2 plans de test, 1 fournisseur. Le CR s'ouvre avec l'impact pré-attaché.
Review d'impact
Stack PLM-centrée
Le CCB se réunit chaque semaine. 30 min par item. Les reviewers demandent 'attendez, ça touche X ?' Les ingénieurs sortent vérifier. Décision reportée à la semaine suivante.
Engineering OS (Koddex)
Les reviewers voient le graphe d'impact dans le CR lui-même. Les reviewers cross-disciplines commentent en thread sur l'entité spécifique. L'approbation est asynchrone ; un deadlock demande un call 15 min, pas un slot CCB.
Propagation après approbation
Stack PLM-centrée
L'ingénieur met à jour manuellement la BOM dans le PLM, l'exigence dans l'outil RM, le test plan dans l'ALM, le modèle thermique en CAE. Trois jours d'édits cross-outils. Un outil est oublié 40% du temps.
Engineering OS (Koddex)
L'approbation mute le graphe typé de façon atomique. Les entités dépendantes sont flaggées stale automatiquement ; les propriétaires affectés sont notifiés. Le modèle thermique est le seul step manuel parce qu'il vit dans un outil CAE, flaggé en to-do pour l'analyste.
Mise à jour de la baseline
Stack PLM-centrée
À la prochaine baseline (mensuelle), quelqu'un réconcilie quels changements approuvés ont atterri. Le PDF de Bill of Material est régénéré. Trois discrépances sont trouvées et mailées.
Engineering OS (Koddex)
La baseline est un snapshot cryptographique pris à la demande. Le diff pre/post est calculable : chaque entité changée depuis la baseline précédente, avec son approbateur et son rationale. La réconciliation EST l'export, pas une réunion.
À quoi ressemble un onboarding de 5 semaines
Pas une « phase de discovery » de six mois. Des livrables concrets par semaine, scopés pour faire atterrir un programme ingénieur actif sur la plateforme.
Semaine 1
Choisir le métamodèle.
Deliverable
Template chargé (MedTech / Robotique / Aéro / Nucléaire / Manufacturing / Infrastructure). Entités standard vivantes. Premières exigences importées.
Semaine 2
Apporter la BOM.
Deliverable
BOM tableur existante importée comme composants typés avec rollups. Champs coût, masse, fournisseur câblés. Premier impact analysis tourne end-to-end.
Semaine 3
Brancher deux intégrations.
Deliverable
Source CAO (your CAD authoring tool) connectée. Source ALM (the RM tool) fédérée. Changements round-trip vérifiés.
Semaine 4
Couper la première baseline.
Deliverable
Baseline cryptographique signée du graphe d'ingénierie. Replay vérifié pour une date passée arbitraire. Export d'audit testé contre la certification cible.
Semaine 5
Handoff à l'équipe.
Deliverable
Trois ingénieurs + program manager formés. Permissions d'agents IA configurées. Audit trail en train de se compiler. L'équipe travaille sur la plateforme full-time.
Empreinte d'intégration : ce qui reste, ce qui se connecte, ce qui disparaît
Le PLM agile est fédération-first. Vous ne migrez pas des décennies de bibliothèques CAO ; vous leur donnez un backbone partagé.
Où passe le coût-temps
Pour un programme hardware de 50 ingénieurs. Chiffres ordres de grandeur, mais c'est la magnitude qui compte.