Le problème des 30 ans
Un programme aéronautique dure entre 20 et 50 ans. L'A320 a été certifié en 1988. Le Rafale en service depuis 2001. Des systèmes d'arme dont les premières lignes de code remontent aux années 1980.
Sur ces programmes, une question hante les Directions Techniques depuis deux décennies : qui se souvient des choix d'ingénierie de la phase 1 ?
La réponse honnête : souvent, personne.
Les ingénieurs qui ont conçu les architectures initiales sont partis — en retraite, en reconversion, parfois décédés. Le savoir de leurs décisions — pourquoi cette architecture plutôt qu'une autre, pourquoi ce compromis, pourquoi cet écart à la norme à cette époque — ne figure dans aucun document lisible par un être humain en un temps raisonnable.
Il y a bien 12, 15, 20 millions de pages de documentation programme. Mais elles ne sont accessibles que par mots-clés. Pas interrogeables. Pas compréhensibles dans leur globalité.
Conséquence mesurable : chaque modification matérielle déclenche 6 à 18 mois d'analyse d'impact, dont une part significative consiste à redécouvrir des décisions prises et documentées il y a 15 ans.
Pourquoi l'IA générative standard est disqualifiée d'office
Quand les équipes aérospatiales et défense s'intéressent à l'IA pour résoudre ce problème, elles rencontrent rapidement un obstacle rédhibitoire : les solutions disponibles supposent l'envoi de données vers des API cloud.
Ce n'est pas possible.
ITAR et EAR : les données techniques relatives aux systèmes militaires, à certains composants aéronautiques, aux logiciels embarqués sont soumises aux réglementations ITAR et EAR. Leur envoi vers des serveurs hors du territoire américain — ou vers des entités non habilitées — constitue une violation réglementaire passible de sanctions pénales. Pour les industriels français et européens travaillant sur des programmes de défense, envoyer de la documentation programme vers une API OpenAI ou Anthropic n'est tout simplement pas une option.
Habilitation et secret-défense : une part des données programme relève de classifications qui rendent impossible tout transit vers un prestataire tiers non habilité. Les architectures cloud ne peuvent pas être habilitées dans les délais et selon les procédures requises.
DO-178C et S1000D : même hors des questions de sécurité nationale, les normes de certification aéronautique posent des exigences de traçabilité que les RAG génériques ne peuvent structurellement pas satisfaire. Un LLM probabiliste ne peut pas garantir qu'une réponse sur une exigence DO-178C provient bien du document de référence — et non d'une "interpolation" entre plusieurs sources.
Le témoignage qui résume le problème
Un responsable Configuration sur un programme aéronautique a partagé récemment un incident révélateur :
Ce n'est pas un bug à corriger. C'est une conséquence inévitable de l'architecture RAG sur des corpus de certification.
Ce que l'architecture Knowledge Graph change pour l'aérospatiale
Principe fondateur : la structure prime sur le texte
Dans une architecture Knowledge Graph, la documentation programme n'est pas stockée comme du texte découpé. Elle est structurée comme un réseau de faits typés et reliés.
Un Data Module S1000D devient un nœud dans le graphe, relié à son Data Module Requirements List parent, aux exigences DO-178C qu'il satisfait, au DAL (Design Assurance Level) applicable, aux tests associés, aux précédents de modification sur la même interface.
Le LLM comme traducteur, pas comme oracle
Quand un ingénieur pose une question — "Quelles exigences DO-178C de niveau DAL-A ont été modifiées sur la baseline 3.2 de ce sous-système, et quels tests en attestent ?" — le LLM ne cherche pas à répondre directement. Il traduit cette question en requête formelle sur le graphe.
Le moteur sémantique exécute la requête. La réponse est extraite depuis les nœuds et relations du graphe — avec provenance complète : Data Module, version, date, signataire de la révision.
Aucune extrapolation. Aucune "complétion créative". Du factuel, du traçable, de l'opposable.
Déploiement sur infrastructure habilitée
L'ensemble de l'architecture — LLM d'inférence (modèles open-weights), graphe de connaissance, moteur sémantique — fonctionne sur votre infrastructure on-premise. Compatible avec les exigences d'habilitation.
Sur la question des délais de mise en œuvre
Une objection légitime : "Un graphe de connaissance sur un corpus programme de 30 ans, c'est un chantier de 3 à 5 ans."
Vrai, si l'objectif est de modéliser l'intégralité du corpus dès le départ. Mais ce n'est pas notre approche.
Nous commençons par un périmètre circonscrit : un type de document (par exemple les seules fiches d'anomalie programme), un sous-système, une période temporelle. Sur ce périmètre, un graphe opérationnel peut être construit en 12 à 20 semaines. La valeur est prouvée sur ce périmètre restreint. L'extension se fait ensuite par couches successives.
Les cas d'usage qui justifient l'investissement
- Analyse d'impact de modification — Quand une modification matérielle est envisagée, l'analyse d'impact doit parcourir l'ensemble des relations entre l'interface modifiée et les exigences, tests, certifications qui en dépendent. Avec le graphe, cette analyse est automatisée : la requête "Quels composants, exigences et tests sont impactés par une modification de l'interface IF-047 ?" retourne une carte d'impact complète. Ce qui prenait 3 à 6 semaines devient une aide à la décision disponible en quelques secondes.
- Capitalisation avant départ des ingénieurs senior — L'ingestion dans le graphe peut intégrer le résultat de sessions d'entretien avec des experts en fin de carrière — leurs justifications de décision, les chemins qui n'ont pas fonctionné, les contextes normatifs d'une époque. Ce savoir tacite, une fois structuré dans le graphe, reste interrogeable après le départ de l'expert.
- Réutilisation cross-programme — Sur un programme long, des problèmes similaires ont souvent été rencontrés et résolus sur des variantes antérieures. La requête "Y a-t-il eu une anomalie similaire sur ce type d'interface dans les programmes P1 ou P2 ?" peut éviter de réinventer une solution déjà documentée.
- Préparation des revues de certification — Les dossiers de revue (PDR, CDR, TRR) nécessitent une consolidation de nombreux éléments documentaires. Le graphe peut pré-remplir l'ossature d'un dossier de revue à partir des requêtes sur le corpus programme — en citant systématiquement les sources.
Les discussions se font sous NDA dès le premier contact. Nous pouvons démontrer l'architecture sur des corpus publics de référence (documentation DO-178C publique, données ouvertes EASA) avant tout accès à des données propriétaires.