Glossaire · Backbone

    Backbone ingénierie : la source unique de vérité pour les équipes hardware

    Un backbone ingénierie est la colonne d'entités typées et de relations autour de laquelle tous les autres outils se fédèrent. Cette page est la référence d'architecture, ce que le backbone possède vs ce qui se fédère, le registre coût-dérive quand il n'y a pas de backbone, et comment il se distingue d'un data warehouse ou d'un data lake malgré le vocabulaire marketing qui se recouvre.

    Ce que le backbone possède vs ce qui se fédère

    Un backbone n'est pas le système qui tient tout. C'est le système qui tient la structure : entités typées, identifiants, relations, états de lifecycle, baselines cryptographiques. Les payloads feuilles, fichiers CAO, bancs de test, données MES traveler, restent là où elles sont, possédées par les outils qui les produisent. Le backbone tient la colonne ; tout le reste se fédère autour de lui à travers quatre patterns prévisibles.

    01

    Possédé par le backbone

    Identifiants typés · relations · lifecycle · baselines · audit trail

    Requirement.id, Component.partNumber, l'arête bidirectionnelle verifiedBy entre les deux, l'état de lifecycle (Draft / Reviewed / Released / Obsolete), la baseline cryptographique qui les contient en v1.2.

    02

    Fédéré par référence

    Géométrie CAO · binaires firmware · gros datasets de test

    Le vault CAO garde le fichier .STEP. Le backbone tient Component.geometryUri → vault://creo/rev/B412. Quand une baseline gèle, l'URI est capturé immutablement ; le contenu fichier est fetché à la demande.

    03

    Matérialisé read-only

    Rollups calculés · matrices de couverture · audit packs

    Rollup masse, % de couverture d'exigences, conformité, recalculés live sur le graphe, exposés comme vues read-only matérialisées. Les ingénieurs et agents IA les interrogent ; personne ne les écrit à la main.

    04

    Sync event-driven

    MBOM ERP ↔ BOM ingénierie · MES asBuilt ↔ asDesigned

    Quand le backbone change une ligne EBOM, un event publie vers your MES ; le MBOM acknowledge. Les enregistrements AsBuilt qui remontent deviennent des events typés que le backbone enregistre comme transitions d'état.

    Le registre coût-dérive

    Modes de panne concrets de l'approche patchwork-d'outils, avec coût en ordre de grandeur. Chacun est structurellement impossible face à un backbone typé.

    Scénario
    Comment la dérive arrive
    Coût typique
    VLOOKUP cassé dans le mass budget
    BOM tableur maintenue manuellement. Insertion d'une ligne décale la cible VLOOKUP d'une cellule. Le total masse lit 7% faux pendant 3 semaines avant qu'on l'attrape en design review.
    20-60 k€ rework, 1 baseline réémise
    Exigence éditée, test plan non
    Le systems engineer révise le critère SR-128 dans l'outil RM. Le test plan dans l'ALM référence toujours l'ancien critère. Le test passe ; le produit échoue à l'acceptance client.
    50-250 k€ rework terrain
    Trois baselines en désaccord
    ‘Baseline v2.1’ dans le PLM = mécanique uniquement. ‘Baseline v2.1’ dans l'outil RM = exigences uniquement. ‘Baseline v2.1’ sur le partage = ce que quelqu'un a zippé ce jour-là.
    2-6 semaines reconstruction d'audit
    Qualification fournisseur orpheline
    Un composant passe du fournisseur A à B. Le système procurement met à jour. L'enregistrement de qualification ingénierie pointe toujours vers A. Six mois plus tard, un audit trouve B utilisé sans qualification.
    Non-conformité audit, rappel possible
    AsBuilt diverge d'AsDesigned
    Le MES autorise une déviation mineure en production. La déviation est flaggée dans MES mais jamais propagée à l'ingénierie. Une investigation terrain tombe sur une configuration qui ne matche aucune baseline design.
    Jours à semaines par investigation
    Problème d'intégration attrapé à la validation, pas au design
    La mécanique a choisi 80 mm. Le firmware a choisi 75 mm. Les deux corrects dans leur outil. Le problème ressort à l'intégration, 4 mois et 200 k€ après les décisions divergentes.
    10× le coût du fix design-time

    Backbone vs warehouse vs lake

    Trois architectures de données se vendent comme « source unique de vérité ». Ce ne sont pas la même catégorie. Une seule porte la structure d'ingénierie.

    Propriété
    Data warehouse
    Data lake
    Backbone ingénierie
    Objectif primaire
    Analytics, questions connues, schéma fixe.
    Stockage, payloads brutes, schema-on-read.
    Substrat opérationnel d'ingénierie, typé, requêtable, calculable.
    Discipline du schéma
    Stricte à l'écriture, mais business-analytique (fact tables, dimensions).
    Lâche. Chaque consommateur devine la structure.
    Sémantique ingénieur : Requirement, Component, Test, Baseline, RiskItem, contraintes validées à chaque écriture.
    Autorité d'écriture
    ETL périodique depuis les systèmes opérationnels.
    N'importe qui avec les creds dépose n'importe quoi.
    Ingénieurs et agents IA écrivent via APIs scoped et auditées. Le graphe rejette les écritures malformées.
    Modèle de versioning
    Slowly-changing dimensions ou snapshots.
    Le versioning dépend de la convention de nommage.
    Baselines cryptographiques (arbre Merkle). Rejouez n'importe quel état passé.
    Ce que l'audit obtient
    Exports analytiques. Pas les artefacts.
    Fichiers. Pas de garanties structurelles.
    Design History File, lifecycle data items, livraison CDE, générés depuis le graphe à la baseline demandée.
    Surface pour agents IA
    Vues SQL sur données dérivées.
    Payloads brutes, les agents doivent reconstruire la structure.
    API MCP-native sur entités typées, les agents agissent avec droits scoped et auditables sur le graphe live.

    Les cinq primitives d'ingénierie que le backbone rend porteuses

    01

    Identifiants typés

    Requirement.id, Component.partNumber, Test.testId, garantis uniques, jamais recyclés, jamais réassignés. L'audit trail peut résoudre n'importe quelle référence 20 ans plus tard.

    02

    Relations typées

    verifiedBy, derivesFrom, integratesInto, hasRiskControl, les relations sont first-class avec leurs propres contraintes. Le schéma peut valider ‘une Exigence doit avoir au moins une vérification’.

    03

    États de lifecycle avec règles de transition

    Draft → Reviewed → Released → Obsolete. Les transitions d'état exigent des approbateurs, laissent des enregistrements d'audit, propagent aux entités dépendantes. L'état n'est pas un label ; c'est un contrat.

    04

    Baselines cryptographiques

    Snapshot content-addressed du graphe typé au moment du freeze. Replay déterministe, anti-manipulation, fork-able. L'enregistrement historique de chaque décision ingénieur.

    05

    Vues calculables

    Matrices de couverture, rollups de masse, dashboards de risque, conformité, calculés sur le graphe live, matérialisés read-only. La vue est toujours cohérente avec la source.