IA pour la maintenance aéronautique MRO en Occitanie : cas d'usage concrets

Un mécanicien avionique cherche la procédure de remplacement d'un servo-actuateur sur un ATR 72. L'AMM fait 6 000 pages. Le CMM du composant est en anglais. L'historique des pannes similaires est dans la GMAO. L'avion est en AOG depuis deux heures. Combien de temps lui faut-il pour trouver la bonne tâche, la bonne révision, et le bon torque de serrage ?

Ce scénario est quotidien dans les centres MRO d'Occitanie. La documentation existe. Elle est exhaustive, rigoureuse, constamment mise à jour. Mais elle est inexploitable à la vitesse qu'exige le terrain. Un AMM couvre plusieurs dizaines de milliers de pages pour un appareil moderne. Un technicien gère souvent plusieurs types d'aéronefs, chacun avec sa propre arborescence documentaire.

L'IA change cette équation sans modifier les exigences réglementaires. En indexant l'ensemble des manuels techniques dans une base interrogeable en langage naturel, en anticipant les défaillances avant qu'elles ne deviennent des AOG, et en automatisant la génération des work cards et des rapports de conformité, elle libère du temps technicien pour ce qui compte : le diagnostic et l'intervention.

Chez Tensoria, nous accompagnons des industriels de la région toulousaine dans des projets IA appliqués à des environnements documentaires denses et des contraintes réglementaires strictes. Cet article détaille six cas d'usage concrets pour le secteur MRO en Occitanie, avec les contraintes techniques, les gains mesurables et les conditions de réussite.

L'écosystème MRO en Occitanie et ses défis documentaires

L'Occitanie est la première région aéronautique française hors Île-de-France. Autour de Toulouse et de Tarbes, plusieurs centres MRO de premier plan coexistent avec un tissu dense de PME certifiées Part 145 :

• Air France Industries KLM Engineering & Maintenance à Tarbes : révision moteurs CFM56 et LEAP, l'un des sites moteurs les plus importants d'Europe.
• Sabena Technics à Toulouse : maintenance lourde sur flottes ATR, A320, A330, avec plusieurs centaines de techniciens.
• ATR Services : support technique et MRO dédié aux turbopropulseurs ATR 42 et ATR 72, avec une documentation technique propriétaire très dense.
• Daher Services : maintenance des aéronefs Kodiak et TBM, avec des PME partenaires en sous-traitance Part 145.
• Liebherr Aerospace Toulouse : composants de train d'atterrissage et systèmes climatisation, avec des CMM complexes par référence de composant.
• Latécoère Services : systèmes d'interconnexion, portes et fuselages, maintenance ligne et base.
• PME Part 145 indépendantes : plusieurs dizaines d'entreprises de 10 à 150 personnes en Occitanie, spécialisées sur des types d'appareils ou des familles de composants.

Ce que ces acteurs ont en commun, c'est un défi documentaire sans équivalent dans l'industrie. Un centre MRO Part 145 gérant plusieurs types d'aéronefs manipule facilement 200 000 à 500 000 pages de documentation technique. Les AMM, CMM, SRM et IPC sont mis à jour en continu par les constructeurs. Chaque révision doit être intégrée dans les processus de maintenance sous peine d'infraction EASA.

Le problème n'est pas l'absence de documentation. C'est son inaccessibilité opérationnelle : un technicien qui cherche une procédure peut passer 20 à 60 minutes à naviguer dans l'arborescence ATA d'un AMM, à croiser avec le CMM du composant concerné, puis à vérifier si une Service Bulletin applicable modifie la procédure standard.

Les conséquences sont directement mesurables sur le temps d'immobilisation des aéronefs et la productivité des centres MRO.

RAG sur AMM, CMM, SRM et IPC : l'accès instantané à la documentation

Le cas d'usage fondateur de l'IA dans le MRO, c'est le RAG (Retrieval-Augmented Generation) appliqué à la documentation technique. Le principe est simple : indexer l'intégralité des manuels dans une base vectorielle, puis permettre aux techniciens d'interroger cet ensemble en langage naturel, avec des réponses précises citant la tâche, la révision et le chapitre ATA de référence.

Quels documents intégrer dans le corpus ?

Pour un centre MRO Part 145, le corpus idéal comprend :

• AMM (Aircraft Maintenance Manual) : procédures de maintenance on-aircraft, organisées par chapitres ATA. C'est le document de référence pour toute intervention sur l'aéronef.
• CMM (Component Maintenance Manual) : instructions de maintenance off-aircraft pour chaque composant. Un centre MRO en gère souvent plusieurs centaines.
• SRM (Structural Repair Manual) : procédures de réparation des structures, avec les limites d'acceptabilité des dommages.
• IPC (Illustrated Parts Catalog) : catalogue illustré des pièces avec les références et les interchangeabilités.
• TSM (Troubleshooting Manual) et FIM (Fault Isolation Manual) : arbres de diagnostic pour isoler les défauts.
• Service Bulletins et Airworthiness Directives : modifications obligatoires ou recommandées émises par les constructeurs et les autorités.
• Historique des interventions depuis la GMAO : les pannes passées sur chaque aéronef ou numéro de série de composant.

Comment le RAG répond à une question terrain ?

Un technicien tape ou dicte : "Quelle est la procédure de remplacement du filtre hydraulique sur le chapitre ATA 29, ATR 72-600, révision actuelle, et quel est le torque de serrage du raccord d'entrée ?"

Le RAG effectue une recherche hybride (sémantique + lexicale sur les références ATA) dans l'AMM indexé, récupère les chunks pertinents, et génère une réponse structurée en quelques secondes, avec :

• La référence de la tâche (task number) dans l'AMM
• La révision du document utilisée
• Les outillages et consommables nécessaires
• Le torque de serrage demandé avec l'unité
• Le lien vers le chapitre source pour vérification

Ce qui prenait 20 minutes prend 30 secondes. Et la réponse est toujours ancrée dans la révision en vigueur, pas dans la mémoire d'un expert senior qui se souvient peut-être de la procédure de la révision précédente.

Ce type d'assistant RAG est directement dans la continuité de ce que nous avons déployé dans d'autres contextes industriels documentaires, comme décrit dans notre retour d'expérience chez Continental. La différence MRO tient à la structure ATA des documents et aux exigences de traçabilité EASA.

Assistant vocal pour mécaniciens sur tarmac et en hangar

Sur le tarmac ou en hangar, les mains du technicien sont occupées. Une tablette ou un ordinateur ne sont pas toujours accessibles. La reconnaissance vocale couplée au RAG documentaire ouvre un nouveau mode d'accès à l'information.

Architecture d'un assistant vocal MRO

Le dispositif repose sur trois composants :

• Casque antibruit avec microphone directionnel : adapté aux environnements hangar avec niveaux sonores élevés (80 à 100 dB). Le casque intègre un bouton push-to-talk pour éviter les faux déclenchements.
• Modèle de reconnaissance vocale fine-tuné sur le vocabulaire MRO : codes ATA, références de tâches, terminologie Part 145, noms de composants (actuateur, servo-valve, contacteur, relais de commande). Le taux de reconnaissance passe de 78% (modèle générique) à 92-94% après adaptation au vocabulaire métier.
• RAG documentaire avec mode offline : indispensable en zone rouge, en halle pressurisée ou dans les zones sans connectivité WiFi. Un cache local des documents les plus fréquemment consultés garantit la disponibilité même sans réseau.

Cas d'usage concret en hangar

Un mécanicien en visite périodique sur un A320 active son casque et demande : "Tâche de lubrification du mécanisme de trappe de train principal, ATA 32, quelle est la référence du lubrifiant Airbus et la fréquence ?"

L'assistant vocale la procédure concernée dans l'AMM A320, lit la référence du lubrifiant (avec la spécification Airbus Material), la quantité et la fréquence d'application. Le tout en 15 secondes, mains libres, sans quitter son poste de travail.

L'interface peut aussi être utilisée pour dicter les observations de l'inspection : le technicien décrit ce qu'il voit, l'IA transcrit et structure le compte-rendu d'observation dans le format de la work card. Gain estimé : 5 à 10 minutes par inspection pour la phase de documentation.

Analyse automatisée des rapports de panne et des Fault Isolation Procedures

Chaque intervention de maintenance génère un rapport : symptôme observé, action corrective réalisée, pièce remplacée, numéro de série. Ces rapports s'accumulent dans la GMAO et constituent une mine d'information sous-exploitée.

Ce que l'IA peut extraire de l'historique des pannes

En analysant plusieurs milliers de rapports d'intervention avec un LLM, on peut :

• Identifier les modes de défaillance récurrents sur un type d'appareil ou un numéro de série spécifique. Un composant qui revient en réparation trois fois en 18 mois sur le même numéro de série est un signal que l'article devrait être remplacé plutôt que réparé.
• Croiser avec les Service Bulletins applicables : l'IA vérifie automatiquement si un pattern de panne observé correspond à un SB en cours ou à venir du constructeur, et alerte les planificateurs.
• Accélérer le troubleshooting en cours : quand un mécanicien entre les symptômes d'une panne, le système recherche dans l'historique les interventions similaires passées, et propose la solution qui a fonctionné, avec la référence de la pièce remplacée et le technicien qui a réalisé l'intervention.
• Détecter les pannes récurrentes liées à une procédure : si les mêmes pannes apparaissent systématiquement après une visite spécifique, c'est peut-être la procédure elle-même qui pose problème.

Intégration avec les Fault Isolation Manuals

Les FIM et TSM contiennent des arbres de diagnostic structurés (si symptôme A alors vérifier B, si résultat négatif aller en tâche C). L'IA peut naviguer ces arbres de décision en dialogue avec le technicien, en posant les bonnes questions dans l'ordre et en affichant les mesures à effectuer à chaque étape. C'est une forme d'automatisation du troubleshooting qui réduit le risque d'erreur de diagnostic et accélère la résolution.

Ce type d'analyse de rapports techniques est directement lié aux travaux décrits dans notre article sur l'automatisation des rapports de maintenance industrielle par IA.

Prévision de stocks de pièces et réduction des AOG

Un AOG (Aircraft on Ground) coûte entre 10 000 et 150 000 euros par heure pour un opérateur commercial, selon le type d'appareil et le contrat de support. La première cause d'AOG prolongée n'est pas l'absence de technicien : c'est l'absence de la pièce de rechange.

Pourquoi la prévision de stocks classique ne suffit pas

Les approches de gestion de stock traditionnelles (point de commande, stock de sécurité fixe) fonctionnent mal dans le MRO pour plusieurs raisons :

• La demande en pièces n'est pas stationnaire : elle dépend des cycles de vol, de l'âge de la flotte, de la saison et des événements de maintenance planifiés.
• Certaines pièces ont des délais d'approvisionnement de 6 à 18 mois (composants à haut cycle de fabrication, pièces soumises à autorisation d'exportation).
• L'interchangeabilité des pièces (entre numéros de série ou entre variants d'un même type) crée des dépendances complexes que les outils ERP standard ne modélisent pas bien.

Ce que le modèle prédictif apporte

Un modèle de prévision de stocks entraîné sur l'historique de consommation des pièces, les données de programme de vol, les alertes de monitoring moteur et les dates de visites planifiées peut :

• Anticiper les besoins de remplacement à 3, 6 et 12 mois par référence de pièce, par type d'appareil et par numéro de série.
• Déclencher automatiquement les demandes d'approvisionnement avec la bonne quantité et le bon délai, avant que la rupture de stock ne devienne critique.
• Optimiser le niveau de stock AOG (pièces réservées aux urgences) en fonction de la probabilité réelle de défaillance, et non d'un stock de sécurité forfaitaire souvent surdimensionné.
• Intégrer les données de monitoring en vol (si disponibles via ACARS ou QAR) pour affiner les prévisions sur les composants ayant des paramètres de surveillance.

Ce sujet est directement lié aux problématiques de prévision de stocks en milieu industriel, que nous détaillons dans notre article sur la prévision de stocks par IA.

Automatisation de la génération des work cards

Une work card (ou job card) est le document qui matérialise une tâche de maintenance : référence de la tâche AMM, outillages nécessaires, pièces de rechange, étapes d'exécution, cases de signature pour chaque étape. Dans un centre MRO, des milliers de work cards sont générées chaque semaine.

Le processus actuel et ses limites

Dans la plupart des centres, la génération des work cards est encore semi-manuelle :

1. Le planning identifie les tâches à réaliser pour chaque visite (MPD, programme de maintenance approuvé).
2. Un préparateur consulte l'AMM pour chaque tâche et reporte les informations dans le système de gestion de maintenance (AMOS, OASES, TRAX).
3. Il vérifie si des Service Bulletins ou Airworthiness Directives modifient la procédure standard.
4. Il identifie les pièces nécessaires et réserve le stock.
5. Il imprime ou génère le PDF de la work card avec les étapes et les cases de signature.

Ce processus est long (30 à 90 minutes par visite complexe), source d'erreurs de report manuel, et mobilise des préparateurs qualifiés sur des tâches de compilation plutôt que sur la vérification et l'optimisation du plan de maintenance.

Ce que l'automatisation IA apporte

Un système IA couplé au RAG documentaire et à l'ERP de maintenance peut :

• Générer automatiquement les work cards à partir du programme de visite planifié, en récupérant les procédures actualisées dans l'AMM pour chaque tâche, et en intégrant les révisions récentes et les SB applicables.
• Vérifier la complétude du dossier : toutes les pièces nécessaires sont-elles en stock ou commandées ? Les outillages spéciaux sont-ils disponibles à la date prévue ?
• Générer les listes de pièces associées à chaque work card avec les quantités et les numéros de référence, prêtes pour le magasiniste.
• Adapter le format de sortie au système de gestion utilisé (AMOS, OASES, ou format papier réglementaire).

L'automatisation de la génération des work cards est un cas d'usage qui se déploie relativement vite car le bénéfice est immédiat et quantifiable en temps de préparation économisé. Le lien avec notre approche générale de l'automatisation de la génération de rapports par IA est direct.

Conformité EASA Part 145/M et préparation des audits ARP

La certification Part 145 exige une traçabilité documentaire exhaustive de chaque opération de maintenance : qui a réalisé la tâche, quelles qualifications, quelle révision de l'AMM utilisée, quelle pièce avec quel numéro de certificat. Un audit de renouvellement de certificat Part 145 mobilise souvent une équipe qualité à temps plein pendant plusieurs semaines.

Où l'IA intervient dans la conformité

• Vérification automatique de la conformité des dossiers : à la clôture de chaque visite, un agent IA vérifie que toutes les cases de signature sont renseignées, que les références de pièces dans la work card correspondent aux certificats reçus, et que les révisions de documents utilisées étaient bien en vigueur à la date de l'intervention.
• Surveillance continue des Airworthiness Directives : les AD émises par l'EASA et la FAA sont publiées en continu. Un agent surveille ces publications, identifie celles qui s'appliquent aux types d'appareils du centre, et alerte les planificateurs avec le délai de compliance et les actions requises.
• Préparation des audits ARP (Audit Readiness Package) : à J-30 d'un audit, un agent compile automatiquement les dossiers demandés (statistiques NCR, taux de clôture des actions correctives, historique des compétences du personnel), dans le format attendu par les auditeurs EASA ou DOA.
• Gestion des habilitations Part 66 : vérification automatique que les habilitations des techniciens qui signent les work cards correspondent aux catégories requises pour chaque tâche, avec alerte proactive avant expiration des habilitations.

Ce que l'IA ne peut pas faire en Part 145

Il est important d'être précis sur les limites. L'IA ne signe pas les certifications de remise en service. Elle ne remplace pas le jugement du technicien certifié Part 66. Elle ne délivre pas de certification de navigabilité. Ces actes restent sous la responsabilité exclusive du personnel habilité et ne peuvent pas être délégués à un système automatisé.

Ce que l'IA fait, c'est réduire la charge des tâches administratives et de vérification documentaire qui entourent ces actes, pour que les experts qualifiés passent plus de temps sur les décisions techniques et moins sur la compilation documentaire.

Contraintes d'architecture et souveraineté des données

Le déploiement d'IA dans un centre MRO Part 145 doit répondre à des contraintes spécifiques qui différencient ce secteur d'une PME industrielle classique.

Souveraineté et localisation des données

Les manuels AMM et CMM, les données de maintenance des aéronefs, et les historiques d'intervention sont des actifs sensibles. Certains relèvent des réglementations de contrôle des exportations (ITAR/EAR pour les données d'appareils à usage militaire ou à double usage). L'architecture doit garantir :

• Hébergement on-premise ou cloud souverain (SecNumCloud), sans transit par des serveurs hors du périmètre de sécurité de l'entreprise.
• Modèles d'IA déployés localement : les embeddings et le modèle de génération tournent sur l'infrastructure interne. Aucune requête documentaire n'est envoyée vers des API cloud extérieures.
• Journalisation complète des accès : qui a interrogé quelle documentation, quand, et quel résultat a été fourni. Cette traçabilité est à la fois une exigence de sécurité et un atout pour les audits.

Intégration avec les systèmes existants

Un centre MRO dispose déjà d'un écosystème applicatif : AMOS, OASES ou TRAX pour la gestion de maintenance, un ERP pour les stocks et achats, une GED pour les documents techniques, un système de gestion des compétences Part 66. L'IA doit s'intégrer à cet existant sans le remplacer.

Les intégrations typiques que nous mettons en place :

• Connecteur vers la GED documentaire pour synchronisation automatique des nouvelles révisions d'AMM et de CMM
• API vers AMOS/OASES pour récupérer le programme de visite et pousser les work cards générées
• Interface avec l'ERP stocks pour la prévision de consommation et le déclenchement des demandes d'achat
• Connecteur GMAO pour l'historique des pannes et des interventions

Mode offline et disponibilité en hangar

La connectivité n'est pas garantie dans toutes les zones d'un hangar de maintenance. Les zones pressurisées, les boxes moteurs et certaines aires de tarmac n'ont pas de couverture WiFi fiable. L'assistant RAG doit fonctionner en mode dégradé avec un cache local des documents les plus fréquemment utilisés, synchronisé automatiquement quand la connexion est disponible.

Notre approche de la sécurité des données IA et souveraineté s'applique intégralement dans le contexte MRO, avec des exigences encore plus strictes liées au cadre réglementaire sectoriel.

ROI concret : MTBUR, AOG, temps de troubleshooting

Dans le MRO, les gains se mesurent avec des indicateurs métier précis. Voici les effets observés sur des déploiements comparables en industrie et en maintenance technique documentaire dense.

Réduction du temps de troubleshooting

Le temps moyen de diagnostic d'une panne (Mean Time to Diagnose) est le premier indicateur qui bouge. Sur des contextes documentaires similaires (documentation technique volumineuse, recherche multi-source), le RAG réduit le temps de recherche de 40 à 70%. Pour un mécanicien avionique qui passe en moyenne 45 minutes à localiser la bonne procédure de fault isolation, l'assistant RAG ramène ce temps à 10 à 15 minutes.

Sur 10 troubleshootings par jour et 20 techniciens, cela représente entre 50 et 100 heures technicien économisées chaque jour dans un centre MRO de taille moyenne.

Impact sur le MTBUR

Le MTBUR (Mean Time Between Unscheduled Removals) est un indicateur clé de la fiabilité des composants. En croisant les historiques de pannes avec les patterns de détection précoce, un modèle prédictif peut identifier les composants qui présentent des signes de défaillance avant l'incident en service. Passer d'une maintenance réactive à une maintenance conditionnelle sur les composants les plus critiques réduit mécaniquement le MTBUR non planifié.

Réduction des AOG

La prévision de stocks réduit les ruptures de pièces critiques de 60 à 80% dans les configurations que nous observons. Sur les AOG liés à une rupture de pièce (qui représentent 30 à 40% des AOG selon les flottes), cela se traduit directement par une réduction du nombre d'AOG prolongés et de leur durée moyenne.

Pour un opérateur gérant une flotte de 20 à 30 appareils, un AOG évité par mois représente une économie de 50 000 à 300 000 euros selon le type d'appareil et la durée de l'immobilisation.

Productivité de préparation des visites

L'automatisation de la génération des work cards réduit le temps de préparation d'une visite complexe de 40 à 60%. Un préparateur qui passait 3 heures à préparer un dossier de visite de 48 heures (C-check léger) descend à 1 heure à 1h30. Sur l'ensemble d'un centre MRO actif, c'est une économie substantielle en ressources de planification.

Ce que Tensoria apporte sur ces projets

Tensoria est une agence IA basée à Toulouse. Nous travaillons dans un écosystème industriel et aéronautique que nous connaissons depuis sa création. Ce n'est pas un argument de proximité géographique : c'est une réalité de compréhension terrain.

Ce que nous apportons spécifiquement sur les projets MRO :

• Maîtrise de l'architecture RAG sur documentation technique dense : indexation de plusieurs dizaines de milliers de pages, gestion des structures ATA, hybrid search sur les références techniques, chunking adapté aux procédures de maintenance.
• Déploiement souverain : nos architectures tournent on-premise ou sur cloud privé certifié. Aucune donnée technique ne sort du périmètre de sécurité du client.
• Approche pilote puis industrialisation : un premier pilote fonctionnel sur un périmètre ciblé (un type d'appareil, un cas d'usage) en 6 à 10 semaines, avant déploiement progressif sur l'ensemble du corpus et des équipes.
• Intégration avec l'existant : nous nous connectons à vos systèmes AMOS, OASES, TRAX, ERP et GED, sans remplacer ce qui fonctionne.

Pour des projets IA en Occitanie, nous intervenons aussi bien à Toulouse, Tarbes, Montpellier, que sur des sites distants avec coordination à distance. Notre approche de l'audit IA à Toulouse permet de qualifier rapidement ce qui vaut le coup d'être automatisé dans votre contexte spécifique.

Questions fréquentes sur l'IA dans le MRO aéronautique

Pour aller plus loin

• RAG pour l'industrie : documentation, maintenance et formation : les fondamentaux du RAG sur documentation technique dense, avec le retour d'expérience Continental (15 000 documents, 2 000 utilisateurs).
• Automatisation n8n dans l'aéronautique à Toulouse : supply chain, conformité EN 9100, gestion des non-conformités pour sous-traitants et PME aéro.
• Prévision de stocks par IA : modèles et architecture pour anticiper les ruptures sur des pièces à longue durée d'approvisionnement.
• Automatiser les rapports de maintenance par IA : génération automatique de comptes-rendus d'intervention et de rapports de conformité.
• Optimiser un système RAG : hybrid search, chunking, embeddings et techniques avancées pour une précision maximale sur documentation technique.
• Sécurité des données et souveraineté IA : architecture pour un déploiement sans compromis sur la confidentialité des données techniques.
• Assistant IA industriel chez Continental : retour d'expérience complet sur un RAG déployé en conditions de production réelles.
• IA et documentation technique aéronautique : RAG sur AMM, CMM, IPC et structuration ATA.
• Contrôle qualité aéronautique par vision IA : complément visuel au RAG documentaire.
• IA et supply chain aéronautique pour PME : ramp-up Airbus, obsolescences et NCR fournisseurs.
• IA pour les sous-traitants aéronautiques de Toulouse : cas d'usage rang 1/rang 2 d'Airbus, ATR, Daher.