Le paradoxe de la voiture connectée
L'automobile est devenue l'un des secteurs industriels les plus complexes à documenter.
Un véhicule moderne contient entre 100 et 150 millions de lignes de code. Les systèmes embarqués critiques — freinage, direction assistée, ADAS — sont soumis à ISO 26262 avec des niveaux d'intégrité de sécurité ASIL pouvant atteindre ASIL D, le plus contraignant. Les processus de développement logiciel sont audités selon Automotive SPICE (ASPICE). Les émissions et performances sont encadrées par EURO 7, entrant en vigueur progressivement à partir de 2025-2026.
Et par-dessus tout ça : les cycles de développement se raccourcissent. Moins de temps. Plus d'exigences. Plus de traçabilité requise. Des équipes qui ne grandissent pas au même rythme que la complexité.
La question que tout directeur de programme se pose
Dans les directions R&D et les directions programmes des équipementiers automobile, une question revient constamment.
"On a développé une solution similaire sur le programme X en 2019. Est-ce qu'on peut la réutiliser sur le programme Y ? Est-ce que les exigences ISO 26262 s'appliquent de la même façon ?"
La réponse honnête, dans la majorité des organisations : "on va vérifier". Et vérifier signifie retrouver la documentation du programme X, identifier les Safety Goals concernés, remonter la chaîne de traçabilité exigences → architecture → conception → tests → validation, et croiser avec les exigences du programme Y.
Ce travail prend entre 2 et 6 semaines. Il est fait par des ingénieurs safety expérimentés — dont le temps est précieux et limité. Et il est refait, en entier ou en partie, à chaque nouveau programme. Parce que la connaissance est dans les documents, pas dans un système interrogeable.
Le problème spécifique de la traçabilité ISO 26262
ISO 26262 impose une traçabilité complète sur toute la chaîne de développement des systèmes de sécurité fonctionnelle. Du HARA (Hazard Analysis and Risk Assessment) au test de validation en passant par les Safety Goals, les Technical Safety Requirements (TSR) et les Software Safety Requirements (SSR).
Les outils ALM (IBM DOORS, PTC Codebeamer, Polarion) gèrent bien les exigences au sein d'un programme. Ils répondent mal à deux questions cruciales :
Réutilisation cross-programme. "Est-ce que l'argument de sûreté qu'on a construit pour la fonction X sur le programme A peut être réutilisé pour la même fonction sur le programme B ?" Les outils ALM répondent programme par programme. Ils ne font pas de recherche transverse.
Analyse d'impact d'une modification. "Si on modifie le TSR-047, quelles Software Safety Requirements en dépendent ? Quels tests de validation sont potentiellement invalidés ?" La chaîne de dépendances dans un système ISO 26262 mature peut comporter des centaines de relations. Les analyser manuellement pour chaque modification est une source d'erreur et de délai.
Ce que le RAG produit sur un corpus safety critique
Les expériences de déploiement RAG sur des corpus ISO 26262 conduisent au même résultat : des réponses plausibles, mais non traçables — et donc inutilisables dans un contexte de sûreté fonctionnelle.
ISO 26262 exige que chaque affirmation de l'argument de sûreté soit étayée par une référence documentaire précise. "Le niveau ASIL de cette fonction est ASIL C parce que..." doit renvoyer à un HARA précis, à une décision de décomposition documentée, à une version de Safety Plan.
Un LLM probabiliste ne peut pas fournir cette traçabilité. Il peut produire une réponse cohérente avec le niveau ASIL probable — mais il ne peut pas garantir que cette réponse est extraite du bon HARA, à la bonne version, pour le bon programme.
La réponse Knowledge Graph pour l'automobile
Le Knowledge Graph ontologique pour l'automobile modélise explicitement les relations de la chaîne de développement safety :
Programme → Safety Plan → HARA → Hazard → Safety Goal → ASIL → TSR → SSR → Test de validation
Quand un ingénieur interroge le graphe — "Quels Safety Goals de niveau ASIL C avons-nous définis pour des fonctions de freinage sur les 5 derniers programmes ?" — le LLM génère une requête qui traverse ces relations et retourne les nœuds correspondants avec leurs sources (programme, document HARA, version, date de validation).
La réponse n'est pas "probablement ASIL C parce que c'est une fonction de freinage". Elle est "ASIL C, selon HARA-Prog-2021-v3.2, section 4.2, validé par [nom], le [date]."
Pour l'analyse d'impact d'une modification : le graphe trace automatiquement l'ensemble des nœuds connectés à un TSR modifié. L'ingénieur voit en quelques secondes l'ensemble des SSR, tests, FMEA et documents de validation potentiellement impactés. Ce qui prenait 2 semaines d'analyse manuelle se réduit à une heure de vérification ciblée.
L'enjeu ASPICE et EURO 7
ASPICE — Chaque évaluation ASPICE produit un rapport : points forts, points faibles, niveaux atteints, recommandations. Ces rapports s'accumulent dans les GED, rarement croisés entre eux, rarement comparés avec les évaluations précédentes. Le graphe change ça : les évaluations passées sont structurées par process, par programme, par évaluateur. Une équipe qui prépare une nouvelle évaluation peut interroger : "Quels sont les process évalués à niveau 1 ou 2 sur les 3 dernières évaluations, et quelles étaient les recommandations ?"
EURO 7 — Pour les équipementiers concernés (freinage, pneumatiques, systèmes de dépollution), EURO 7 implique une analyse d'impact sur l'ensemble du portefeuille de produits : quelles références sont concernées, quelles modifications techniques sont nécessaires, quels tests sont à refaire. Cette analyse transversale est exactement le type de problème que le graphe résout en quelques secondes.
Intégration sans perturber le SI existant
Le graphe se connecte sans remplacer les systèmes existants :
- PLM (Teamcenter, ENOVIA) — connecteur lecture seule sur les métadonnées de configuration et de révision
- ALM (DOORS, Codebeamer, Polarion) — export structuré des exigences et de leurs liens de traçabilité
- QMS IATF — ingestion des non-conformités et des CAPA
- GED interne — parseur documentaire pour les rapports FMEA, HARA, Safety Case
100 % on-premise. Les données de spécification, les données fournisseurs sous NDA, les données de validation restent dans le périmètre de l'organisation.
Périmètres POC typiques : analyse d'impact d'une modification ISO 26262 sur un système de freinage ; consolidation des Safety Goals ASIL C/D réutilisables sur un nouveau programme ; capitalisation des rapports ASPICE des 5 dernières évaluations ; analyse d'impact EURO 7 sur le portefeuille d'un segment produit.
L'automobile est entrée dans une ère où la complexité réglementaire et technique dépasse ce que des équipes humaines peuvent gérer sans infrastructure de connaissance. Le Knowledge Graph ontologique est l'infrastructure qui comble ce manque — sans remplacer les outils existants et sans exposer les données techniques à l'extérieur.