IA et documentation technique aéronautique : RAG sur manuels, ATA et EASA

Un mécanicien aéro sur tarmac cherche la procédure de remplacement d'un composant hydraulique sur un A320 CEO, MSN 3247. L'AMM fait 18 000 pages. Le FIM est dans un autre système. La CMM du fabricant est en anglais. Et l'avion doit être rendu en ligne dans deux heures.

Ce scénario se répète chaque jour dans les MRO, les compagnies et les centres de maintenance à travers le monde. La documentation aéronautique est parmi les plus volumineuses, les plus précises et les plus contraignantes qui existent. C'est aussi l'une des plus difficiles d'accès en conditions opérationnelles réelles.

Le RAG (Retrieval-Augmented Generation) appliqué à la documentation technique aéronautique change cette équation. En indexant l'ensemble de vos manuels selon la structure ATA, en gérant les effectivités par MSN et les révisions en vigueur, il transforme des heures de navigation documentaire en réponses précises, sourcées et traçables en quelques secondes.

Chez Tensoria, nous déployons cette approche en environnements industriels et réglementés. Cet article détaille pourquoi la doc tech aéro est un terrain d'or pour le RAG, les cinq cas d'usage les plus impactants, l'architecture technique à mettre en place et les contraintes non négociables liées à la réglementation EASA en matière de navigabilité.

Pourquoi la documentation aéronautique est un terrain d'or pour le RAG

Peu de secteurs réunissent autant de conditions favorables au RAG que l'aéronautique. Le problème documentaire y est structurellement difficile, l'enjeu opérationnel est maximal, et la structure ATA crée un cadre d'organisation qui facilite l'ingestion intelligente.

Un volume documentaire sans équivalent industriel

Un programme avion commercial comme l'A320 génère plusieurs centaines de milliers de pages de documentation technique. L'AMM seul peut dépasser 60 000 pages sur certains types. Ajoutez les CMM de chaque composant LRU, les IPC, les FIM, les TSM, les SRM, les bulletins de service et les directives de navigabilité : un mécanicien aéro doit naviguer dans un corpus documentaire qui n'a pas d'équivalent dans l'industrie conventionnelle.

Ce volume n'est pas un problème ponctuel. Il est permanent et croissant : chaque révision de manuel, chaque nouveau bulletin de service, chaque directive EASA ou FAA s'ajoute au corpus existant. Un MRO de taille moyenne gère simultanément plusieurs programmes avion, ce qui multiplie la complexité documentaire.

La structure ATA : un cadre naturellement favorable au RAG

La norme ATA 100, adoptée par toute l'aviation civile mondiale, divise la documentation en chapitres standardisés : ATA 24 pour le système électrique, ATA 29 pour l'hydraulique, ATA 32 pour le train d'atterrissage, ATA 71 pour la motorisation, etc. Cette structure est un cadeau pour le chunking sémantique : elle définit des unités documentaires naturelles, cohérentes et universellement comprises par les mécaniciens.

Contrairement à un manuel industriel générique sans structure formelle, un AMM peut être découpé intelligemment par numéro de tâche (ex. 29-10-00-400-001), par sous-système ATA et par type d'opération (entretien, dépose/pose, tests). Le RAG hérite de cette logique pour retrouver exactement la procédure applicable.

Une mise à jour permanente qui rend la recherche manuelle risquée

La documentation aéronautique est vivante. Les révisions d'AMM arrivent selon un rythme défini par le constructeur (souvent mensuel sur les programmes récents). Les bulletins de service modifient localement des procédures. Les directives de navigabilité EASA et FAA imposent des actions obligatoires dans des délais précis. Dans ce contexte, travailler sur une révision périmée n'est pas une erreur bénigne : c'est un risque de navigabilité.

Un système RAG avec gestion automatique des révisions garantit que la réponse est toujours ancrée dans la version en vigueur du document, et signale explicitement quand une section a été modifiée récemment. C'est un avantage direct sur la recherche PDF manuelle, où le mécanicien doit vérifier lui-même la date de révision de chaque document consulté.

Une criticité opérationnelle qui justifie l'investissement

En aéronautique, le coût d'une erreur documentaire est direct et mesurable. Un avion au sol (AOG) coûte entre 10 000 et 100 000 euros par heure selon le programme et le contexte commercial. Chaque minute gagnée sur la recherche d'une procédure de dépannage est une minute de moins avant la remise en ligne. Et chaque procédure mal appliquée faute d'avoir trouvé la bonne version peut engager la navigabilité de l'appareil.

Ce ratio coût/bénéfice du RAG est nettement plus favorable qu'en industrie conventionnelle, ce qui explique l'intérêt croissant des MRO et des départements technique de compagnies pour ces solutions.

Les 5 cas d'usage les plus impactants du RAG en documentation aéro

Cas d'usage 1 : l'assistant mécanicien sur tarmac (interface vocale)

Le tarmac est l'environnement le plus contraignant pour une interface documentaire. Le mécanicien a les mains occupées, porte des équipements de protection, travaille parfois dans des conditions de bruit ou de faible luminosité. Feuilleter un AMM sur tablette est déjà difficile. Saisir une requête textuelle l'est encore plus.

L'interface vocale couplée au RAG change radicalement l'expérience. Le mécanicien parle naturellement : "Quelle est la procédure de dépose de la vanne de pressurisation sur A320 MSN 3247 ?" Le système reconnaît le programme, filtre selon le MSN, identifie le chapitre ATA concerné (ATA 21 pour la pressurisation) et restitue la procédure avec le numéro de tâche AMM applicable, lu à voix haute ou affiché sur une tablette ou des lunettes connectées.

La réponse inclut systématiquement :

• Le numéro de tâche AMM (ex. 21-30-00-400-001)
• La révision applicable et sa date
• L'effectivity MSN confirmant que la procédure s'applique bien à l'appareil concerné
• Les précautions de sécurité associées (CAUTION, WARNING)
• Les références aux équipements de test ou aux consommables nécessaires

Le mécanicien peut alors vérifier la procédure avant d'agir. L'assistant ne remplace pas son jugement certifié : il lui évite 20 à 40 minutes de navigation documentaire dans des conditions opérationnelles difficiles.

Cas d'usage 2 : recherche par symptôme dans l'AMM et le FIM

Le Fault Isolation Manual (FIM) et la section Trouble Shooting Manual (TSM) sont des documents conçus pour le diagnostic. Mais leur navigation par arbre de décision est linéaire et exigeante : le mécanicien doit suivre une séquence de tests pas à pas, souvent sur plusieurs dizaines de pages, avant d'arriver à la cause probable.

Le RAG permet une entrée par symptôme en langage naturel. Un mécanicien décrit ce qu'il observe : "Message ECAM hydraulique, pression Green basse, pas de fuite visible, MLG sorti". Le système interroge simultanément le FIM ATA 29, le TSM et les bulletins de service applicables pour proposer :

• La séquence de diagnostic probable selon le symptôme décrit
• Les causes les plus fréquentes selon les retours d'expérience indexés
• Les références de pièces (IPC) associées aux composants suspects
• Les conditions MEL/MMEL si un report est envisageable pour libérer l'appareil

Ce cas d'usage est particulièrement puissant dans les situations AOG où la pression du temps est maximale. Il permet de consolider en quelques secondes une information qui demanderait normalement 30 à 60 minutes de navigation croisée entre plusieurs manuels.

Cas d'usage 3 : comparaison de versions de manuels et suivi des révisions

La gestion des révisions est l'un des points les plus chronophages pour les équipes documentation des MRO et des compagnies. Lorsqu'Airbus publie une révision d'AMM, identifier précisément quelles procédures ont changé, dans quel sens et avec quelles implications opérationnelles prend plusieurs jours pour un grand programme avion.

Un RAG avec gestion native du versionnement permet de :

• Comparer deux révisions d'une même tâche AMM et mettre en évidence les modifications
• Lister toutes les procédures modifiées entre deux dates de révision pour un chapitre ATA donné
• Identifier les impacts opérationnels d'un bulletin de service sur les procédures existantes
• Alerter automatiquement les équipes concernées quand une procédure qu'elles utilisent fréquemment a été modifiée

Dans un MRO gérant plusieurs flottes, ce cas d'usage peut faire économiser plusieurs dizaines d'heures par révision sur la phase d'analyse d'impact documentaire.

Cas d'usage 4 : assistance à la génération de work cards

Les work cards (ou travaux cards, fiches de travail) sont les documents de travail quotidiens des mécaniciens en maintenance planifiée. Elles transcrivent les tâches AMM en instructions opérationnelles adaptées aux équipements et aux procédures internes du MRO. Leur génération est un processus manuel, répétitif et chronophage.

Le RAG peut assister significativement cette génération :

• À partir d'un numéro de tâche AMM et du MSN de l'appareil, le système récupère la procédure applicable, les outillages référencés et les consommables listés.
• Il génère un brouillon de work card structuré selon le format interne du MRO, en adaptant la terminologie aux conventions internes.
• Il signale les éventuels bulletins de service applicables qui modifient ou complètent la procédure standard.
• Il propose les références croisées pertinentes (CMM du composant, SRM si applicable).

Le planificateur ou le responsable technique valide et complète le brouillon. Le temps de génération passe de 1 à 2 heures par work card complexe à 15 à 20 minutes de vérification et d'ajustement.

Cas d'usage 5 : formation continue et préparation aux examens Part 66

La licence Part 66 EASA est le sésame des mécaniciens certifiants en Europe. Son maintien et son extension requièrent une formation continue, des qualifications de type et une connaissance précise des réglementations en vigueur. La documentation de référence est volumineuse et souvent rébarbative à consulter.

Un assistant RAG dédié à la formation Part 66 permet :

• Des sessions de questions/réponses sur les procédures de n'importe quel chapitre ATA, avec vérification immédiate sur la documentation officielle
• Une préparation aux qualifications de type (type rating) sur un programme avion spécifique, avec accès aux particularités du système AMM concerné
• Une révision des modules réglementaires (EASA Part M, Part 145, Part 66) sous forme de Q/R pédagogiques
• Des simulations de cas pratiques basés sur des scénarios réels de maintenance, avec évaluation des réponses par rapport aux procédures AMM applicables

Ce cas d'usage est particulièrement pertinent pour les MRO qui forment régulièrement de nouveaux mécaniciens ou qui accompagnent des techniciens dans l'extension de leur licence vers de nouvelles catégories ou de nouveaux programmes avion.

Architecture technique : comment construire un RAG adapté à la documentation aéro

Un RAG générique ne suffit pas pour la documentation aéronautique. La criticité du contexte impose une architecture pensée dès le départ pour la précision, la traçabilité et la gestion des spécificités ATA.

Ingestion et pipeline de préparation des données

L'ingestion de la documentation aéro est la phase la plus critique et la plus spécifique. Plusieurs formats coexistent : PDF (souvent issus de systèmes SGML/S1000D ou ATA 2300), XML structuré, publications interactives (IETP). Chaque format nécessite un pipeline d'extraction adapté.

Pour les PDF classiques, l'extracteur doit préserver :

• La numérotation de tâche (ex. 29-10-00-400-001) comme identifiant primaire du chunk
• Les blocs CAUTION et WARNING, qui ne doivent jamais être séparés de la procédure associée
• Les tableaux de spécifications (tolérances, couples de serrage, références de pièces) sous forme structurée interrogeable
• Les figures et renvois de figure avec leurs légendes indexées
• Les références croisées entre tâches et entre documents (CMM, IPC, SRM)

Pour les publications XML ou S1000D, le pipeline peut exploiter la structure sémantique native des balises pour un chunking de bien meilleure qualité que sur PDF.

Chunking par section ATA : la stratégie centrale

Le chunking (découpage en unités indexables) est le facteur technique le plus déterminant pour la qualité du RAG en contexte aéro. Un découpage arbitraire toutes les 500 tokens est inadapté : il coupe les procédures en milieu d'étape, sépare les CAUTION de leurs procédures associées et fragmente les tableaux de tolérances.

La stratégie recommandée pour la documentation ATA :

• Un chunk = une tâche AMM complète (numérotée 29-10-00-400-001 par exemple), incluant toutes ses étapes, ses CAUTION/WARNING et ses références
• Chunks distincts pour les données de maintenance (inspection intervals, limits, lifed items) qui ont un pattern de requête différent
• Chunks dédiés pour les tableaux de spécifications (tolérances, couples, références de pièces), convertis en format structuré interrogeable
• Taille maximale de chunk adaptée à la longueur des tâches AMM (de 200 à 4 000 tokens selon le type de procédure)

Métadonnées critiques : effectivity, MSN, programme, révision

C'est le point d'architecture le plus spécifique à l'aéronautique et le plus souvent sous-estimé dans les premières implémentations. Chaque chunk doit porter des métadonnées de filtrage qui permettent de n'exposer que les informations applicables à l'appareil concerné.

Métadonnées minimales à indexer sur chaque chunk :

Métadonnée	Exemple	Usage au moment de la requête
Programme avion	A320, A320neo, B737NG	Filtrage primaire, sélectionne les manuels du bon programme
Effectivity / MSN range	MSN 1500 à 3500, ou ALL	Filtrage secondaire, exclut les variantes non applicables
Chapitre ATA	ATA 29, ATA 32, ATA 71	Orientation thématique de la recherche
Numéro de tâche	29-10-00-400-001	Identification précise et citation obligatoire
Type de document	AMM, CMM, FIM, IPC, MEL	Sélection de la source selon le cas d'usage
Révision et date	Rev. 148, mars 2026	Garantit que la version en vigueur est servie
Sous-type d'opération	Dépose, Repose, Inspection, Test	Affine le résultat selon le besoin du mécanicien

Ce filtrage par métadonnées s'applique avant la recherche sémantique, pas après. L'index vectoriel ne cherche que dans les chunks applicables au contexte MSN/programme défini en début de session. C'est une différence fondamentale avec un RAG industriel standard où toute la base est interrogée à chaque requête.

Citations obligatoires : la règle non négociable

En documentation aéronautique réglementée, chaque réponse de l'assistant doit inclure :

• Le numéro exact de la tâche AMM ou de la section du document source
• La révision applicable (numéro de révision et date)
• L'effectivity confirmée pour le MSN de l'appareil traité
• Un lien vers le document complet pour vérification avant toute action

Si le RAG ne trouve pas de chunk suffisamment pertinent pour répondre avec certitude, il doit explicitement indiquer qu'il ne dispose pas de l'information plutôt que de générer une réponse approximative. En contexte de navigabilité, une réponse absente vaut infiniment mieux qu'une réponse inventée.

C'est pourquoi nous recommandons de connecter le RAG aéro au mécanisme de score de confiance et de définir un seuil minimum en dessous duquel le système refuse de répondre et renvoie vers la consultation manuelle.

Contraintes réglementaires : zéro hallucination, traçabilité et Part 66

La documentation aéronautique n'est pas une documentation comme les autres. Elle engage directement la sécurité des vols et la navigabilité des appareils. Cela impose des contraintes techniques et organisationnelles que tout déploiement RAG en contexte aéro doit intégrer dès la conception.

L'exigence de zéro hallucination

Dans un contexte industriel standard, une réponse approximative d'un assistant RAG coûte du temps et potentiellement une mauvaise décision. En aéronautique, une procédure incorrecte peut engager la navigabilité d'un aéronef, impliquer la responsabilité du mécanicien certifiant et du MOE de l'organisation Part 145.

L'objectif n'est pas d'atteindre 100% de précision immédiatement, ce qui n'est pas réalisable. L'objectif est de concevoir le système pour que toute réponse incertaine soit signalée comme telle, et que la réponse soit toujours vérifiable par rapport au document source en un clic.

Les mécanismes techniques qui y contribuent :

• Ancrage strict sur les chunks récupérés : le prompt système interdit explicitement au modèle de compléter par ses connaissances générales quand les sources ne couvrent pas la question
• Score de pertinence affiché : chaque réponse porte un indicateur de confiance calculé sur les scores de similarité des chunks récupérés
• Mode refus explicite : en dessous d'un seuil de confiance paramétrable, le système affiche "Je ne dispose pas de l'information dans les documents indexés pour cette question. Consultez l'AMM directement."
• Évaluation continue : un jeu de cas de test métier mesure la précision du système à intervalles réguliers et déclenche une alerte si elle chute sous le seuil cible

Traçabilité et conformité Part 145

La réglementation EASA Part 145 exige que toute action de maintenance soit traçable : quelle procédure a été appliquée, selon quelle révision de manuel, par quelle personne habilitée. L'assistant RAG s'inscrit dans cette exigence en :

• Journalisant chaque requête et sa réponse associée avec les citations de source
• Permettant l'export des consultations documentaires pour intégration dans le dossier de travail (work order)
• Conservant l'historique des versions de documents interrogées au moment de chaque requête

L'assistant est un outil d'aide à la décision. La signature de la work card et la certification de l'action restent sous la responsabilité exclusive du mécanicien certifiant habilité Part 66. Ce point doit être documenté dans le MOE et les procédures internes de l'organisation Part 145 qui déploie la solution.

La question de la formation Part 66 : un outil pédagogique, pas un oracle réglementaire

Pour le cas d'usage formation, il est important de distinguer deux usages distincts. L'assistant peut parfaitement servir à réviser et s'entraîner sur des procédures, des modules réglementaires et des scénarios de maintenance. Il ne doit pas être présenté comme une source d'autorité réglementaire équivalente aux publications officielles EASA.

En pratique, cela signifie que les modules de formation pédagogique s'appuient sur les documents officiels indexés, mais les exercices de certification formelle continuent de référencer directement les publications EASA et les manuels d'examen agréés.

Cas terrain : assistant RAG sur flotte court-courrier en MRO

Un MRO basé en France gérant une flotte A320/A321 cherchait à réduire les temps de diagnostic sur les incidents hydrauliques et pneumatiques, responsables de la majorité de ses retards de remise en ligne. La documentation concernée couvrait plus de 200 000 pages entre l'AMM, le FIM, le TSM et les CMM des composants clés de ces systèmes.

Le périmètre pilote a été défini sur les chapitres ATA 21 (climatisation/pressurisation), 29 (hydraulique) et 36 (pneumatique) pour un programme avion unique. L'ingestion a duré 6 semaines, principalement occupées par la structuration des métadonnées d'effectivity et la résolution des références croisées entre les trois chapitres ATA.

Les résultats mesurés sur les trois premiers mois d'utilisation en conditions réelles :

• Temps de recherche documentaire sur incident ATA 29 : de 40 minutes en moyenne à moins de 6 minutes
• Taux de consultation correcte du bon numéro de tâche AMM dès la première recherche : 91% (contre estimation de 65% avant déploiement)
• Réduction des appels à l'ingénieur support pour localisation documentaire : 60%
• Satisfaction mécaniciens : 87% jugent l'assistant utile ou très utile après 8 semaines d'usage

Le facteur de succès le plus cité par les mécaniciens : la citation systématique du numéro de tâche AMM et de la révision applicable, qui leur permet de vérifier en un coup d'oeil que la procédure est bien à jour et applicable à leur MSN.

Ce qui différencie un RAG aéro d'un RAG industriel standard

Sur le plan de l'architecture générale, un RAG aéronautique repose sur les mêmes briques techniques qu'un assistant RAG en industrie manufacturière. Mais plusieurs éléments sont spécifiques au contexte aéro et doivent être anticipés dès la phase de conception.

Dimension	RAG industrie standard	RAG documentation aéro
Structure documentaire	Variable selon le constructeur	Structure ATA normalisée, exploitable pour le chunking
Gestion des versions	Importante mais non critique	Critique : la révision AMM engage la navigabilité
Filtrage par applicabilité	Rarement nécessaire	Obligatoire : effectivity par MSN/programme
Citation de source	Recommandée pour la traçabilité	Obligatoire : numéro de tâche, révision, effectivity
Tolérance à l'erreur	Modérée (coût opérationnel)	Quasi nulle (enjeu de navigabilité et de sécurité)
Cadre réglementaire	ISO, IATF, normes qualité	EASA Part 145, Part 66, Part M, FAA si applicable
Effort préparation données	40% de l'effort projet	50% de l'effort projet (effectivités, révisions)

La bonne nouvelle : la structure ATA, qui est une contrainte documentaire pour les équipes, devient un avantage architectural pour le RAG. Un système qui exploite correctement la numérotation ATA et les métadonnées d'effectivity atteint une précision de récupération nettement supérieure à un RAG générique appliqué à la même documentation.

Comment démarrer un projet RAG sur documentation aéronautique

La démarche recommandée repose sur une montée en charge progressive qui permet de valider la précision avant de déployer à grande échelle.

Phase 1 : cadrage et audit documentaire (3 à 4 semaines)

Inventoriez vos sources documentaires, évaluez leur qualité et leur format, et identifiez le cas d'usage prioritaire. Pour un premier déploiement, nous recommandons de cibler un chapitre ATA à fort volume de consultations (souvent ATA 29, 32 ou 71 selon la flotte) et un périmètre réduit d'effectivités (un seul MSN range ou un seul sous-programme).

Cette phase inclut aussi le cadrage réglementaire : comment l'outil s'inscrit dans le MOE de l'organisation Part 145, quelle est la procédure de validation des réponses avant action, et comment le système s'intègre dans les process documentaires existants.

Phase 2 : proof of concept sur périmètre ciblé (6 à 8 semaines)

Ingestion du périmètre documentaire sélectionné, structuration des métadonnées ATA, déploiement de l'assistant pour un groupe de testeurs (10 à 20 mécaniciens), et mesure de la précision sur un jeu de cas de test réels. C'est la phase critique pour valider que les scores de confiance, le mode refus et les citations sont correctement paramétrés.

Phase 3 : extension et industrialisation (3 à 6 mois)

Extension progressive à l'ensemble des chapitres ATA, aux autres types de documents (CMM, FIM, MEL/MMEL), à d'autres programmes avion si nécessaire, et déploiement à l'ensemble des utilisateurs. Mise en place du pipeline de synchronisation automatique avec le système documentaire source pour la gestion des nouvelles révisions.

Ce type de déploiement s'inscrit naturellement dans la continuité de notre approche des assistants IA internes sur documentation d'entreprise, avec les couches spécifiques liées au contexte aéro.

Questions fréquentes sur le RAG en documentation aéronautique

Pour aller plus loin

• RAG en industrie : documentation technique et maintenance : le même raisonnement appliqué à l'industrie manufacturière, avec le retour d'expérience Continental sur 2 000 utilisateurs.
• Comprendre le RAG : fonctionnement technique du Retrieval-Augmented Generation, de l'indexation vectorielle à la génération de réponses sourcées.
• Optimiser un système RAG : hybrid search, chunking intelligent, embeddings et techniques avancées pour atteindre 90%+ de précision.
• Erreurs courantes des projets RAG : les pièges à éviter, notamment sur la préparation des données et la gestion des métadonnées.
• Déployer un assistant IA interne sur vos documents : la méthode complète, de l'audit documentaire au déploiement en production.
• Automatisation IA en aéronautique et industrie à Toulouse : les cas d'usage d'automatisation complémentaires au RAG en contexte industriel aéro.
• Sécurité des données et souveraineté IA : hébergement, RGPD et architecture souveraine pour des données techniques sensibles.
• IA pour la maintenance aéronautique (MRO) : application opérationnelle de la doc technique chez les acteurs Part 145.
• IA pour les sous-traitants aéronautiques de Toulouse : cas d'usage rang 1/rang 2 d'Airbus avec contraintes ITAR et EN 9100.
• Contrôle qualité aéronautique par vision IA : couplage RAG documentaire et computer vision pour l'inspection.