Glossaire · Comparaison
Les outils de gestion d'exigences, requirements management tools, couvrent bien une tranche de l'ingénierie. Un système d'exploitation pour ingénieurs couvre cette tranche et les cinq autres que les équipes traversent avant la certification. Cette page est la référence achats : la matrice de capacités, le modèle de progression par crise qui pousse la plupart des équipes à dépasser leur outil RM, et le playbook de fédération pour démarrer depuis un seat existant.
Comparer un système d'exploitation pour ingénieurs à un outil de gestion d'exigences n'est pas un duel feature-à-feature, c'est un duel de scope. La catégorie gestion d'exigences a été conçue autour d'un seul type d'entité. La catégorie Engineering OS est la couche d'exploitation qui porte chaque artefact d'ingénierie sur un seul graphe typé — la couche qui transforme l'ingénierie en excellence opérationnelle et l'infrastructure elle-même en avantage industriel. Les deux peuvent coexister ; la couture est structurelle.
Catégorie, Gestion d'exigences
Catégorie, Engineering Operating System
Un outil de gestion d'exigences continue son travail à l'intérieur d'un Engineering OS, fédéré comme la surface d'authoring de cette seule tranche. L'Engineering OS possède la structure qui relie les exigences à tout le reste que le programme doit livrer et certifier.
La plupart des équipes hardware atteignent les limites de la gestion d'exigences non pas en un événement, mais en une séquence prévisible. Chaque crise visse un nouvel outil. À la cinquième, l'organisation ingénierie paie pour six systèmes qui ne partagent pas un graphe.
Crise 1 · An 0-1
Les exigences gérées en tableur s'effondrent. La coverage matrix casse au-dessus de ~800 entrées.
Typical bolt-on
Adopter un outil de gestion d'exigences dédié.
Compounding cost
3-10 k€ / ingénieur / an. Résout la crise des exigences.
Crise 2 · An 1-2
La BOM en tableur ne parle toujours pas à l'outil RM. Les rollups masse / coût dérivent.
Typical bolt-on
Adopter un PDM / PLM pour la BOM. Ajouter un script de sync avec l'outil RM.
Compounding cost
8-18 k€ / ingénieur / an additionnels. Deux systèmes de record.
Crise 3 · An 2-3
Les baselines sont en désaccord. L'outil RM, le PLM et le partage rapportent chacun un état différent au même tag de révision.
Typical bolt-on
Ajouter une discipline config management + scripts custom pour synchroniser les baselines.
Compounding cost
1-2 ETP ingénieurs configuration. Les audits commencent à exposer la dérive.
Crise 4 · An 3-4
La reconstruction pré-audit prend 3-6 semaines par programme.
Typical bolt-on
Ajouter un outil de preuve d'audit + structure de dépôt documents.
Compounding cost
6+ ETP-semaines par audit × 2/an. La vélocité ingénieur chute.
Crise 5 · An 4-5
Les agents IA ne peuvent pas agir utilement parce que la donnée est fragmentée sur 5 systèmes.
Typical bolt-on
Construire un data lake / data warehouse custom + couche de retrieval pour l'IA.
Compounding cost
300 k€-1 M€ de build, 200 k€+/an de maintien. Ajoute une 6ème source de vérité.
Crise ∞
6 systèmes · 3 jobs de réconciliation · 8 ETP en maintenance d'outil · anxiété d'audit.
Typical bolt-on
Adopter un Engineering OS comme substrat. Fédérer, ne pas remplacer.
Compounding cost
La migration s'est payée elle-même en Y2. L'enveloppe licence + admin chute 5-10×.
Les équipes n'arrachent pas leur outil RM au jour 1. Elles le fédèrent comme une entrée d'un graphe plus large.
Connecter à l'API the RM tool (OSLC quand disponible, native sinon). Tirer les exigences, leur statut de vérification, et les liens bidirectionnels. Le graphe dans Koddex miroir l'outil RM, read-only pour l'instant.
BOM, tests, baselines, risk items, qualification fournisseur, entités typées que l'outil RM ne modélise pas. Chacune se lie aux exigences qu'elle touche. Le graphe d'ingénierie s'étend désormais au-delà de la tranche exigences.
Une fois que les ingénieurs travaillent quotidiennement avec le graphe étendu dans Koddex, ils commencent à y éditer les exigences. L'outil RM devient downstream, reçoit les updates, ne les édite plus. Les licences existantes gardent la vue historique, mais le nouveau travail circule via le graphe d'ingénierie.
Typiquement 12-18 mois plus tard, le rôle d'authoring de l'outil RM a migré. Le renouvellement de licence devient optionnel. L'archive historique the RM tool reste accessible (souvent via un seat read-only unique) mais le graphe d'ingénierie est le système opérationnel de record.