IA en aviation : quelles preuves avant de l’utiliser ?

Avant d’essayer un outil d’intelligence artificielle (IA) en aviation, demandez ce que cet outil doit faire, dans quelles situations il a été évalué et comment votre équipe pourra contester ou arrêter sa proposition. Une démonstration réussie mérite un essai bien préparé ; elle ne suffit pas à décider de l’usage en service.

Le sujet arrive souvent par une promesse très concrète : retrouver plus vite une information, repérer un écart ou préparer une analyse. Pour l’équipe qui reçoit la démonstration, la difficulté est de transformer cet intérêt en questions auxquelles le fournisseur peut réellement répondre.

Le point de départ de l’EASA

Le programme publié pour les EASA AI Days, les 9 et 10 septembre 2026 à Cologne, portait notamment sur la manière de vérifier la fiabilité d’une intelligence artificielle (IA) et sur les conditions dans lesquelles les personnes l’utilisent. Ces questions restent utiles pour préparer un essai avec votre équipe.

Le document de réflexion de l’EASA, Proposed Issue 3, publié le 3 juin 2026, est présenté comme une proposition. Il ne constitue pas une autorisation générale d’employer un outil. L’article s’appuie sur ce cadre de discussion, sans attribuer de conclusions à la conférence.

La fiche qui suit est notre proposition pour préparer une discussion fournisseur. Elle ne remplace ni l’analyse du système concerné ni les exigences qui lui sont applicables.

Une démonstration qui donne envie d’aller plus loin

Prenons un cas fictif. Nora coordonne les essais d’outils numériques chez un exploitant. Un fournisseur lui présente un assistant qui regroupe des informations de maintenance et propose des pistes à examiner. La démonstration est fluide, les réponses sont lisibles et ses collègues voient immédiatement l’intérêt.

Puis un technicien pose une question simple : que se passe-t-il lorsqu’un document manque ? Le fournisseur répond que l’utilisateur garde la main. Nora n’écarte pas le projet, mais cette réponse ne lui permet pas encore d’organiser un essai.

Elle veut savoir ce que son collègue verra, ce qu’il pourra vérifier et comment il poursuivra son travail si la proposition semble plausible mais reste mal étayée. C’est là que commence l’évaluation utile.

Décrire une tâche, pas une promesse générale

Avant de parler de précision ou de gain de temps, écrivez la tâche que l’équipe envisage de confier à l’outil. « Aider la maintenance » est trop large pour préparer un essai. « Regrouper les informations disponibles avant l’examen d’un dossier par un technicien » donne déjà un périmètre plus clair.

Dans le cas fictif, Nora précise que l’assistant prépare des pistes. L’essai ne lui confie aucune décision opérationnelle et ne change pas les responsabilités existantes. Cette limite permet de discuter du produit sans supposer qu’une fonction montrée à l’écran est adaptée à tous les usages.

Demandez ensuite au fournisseur de reprendre la même tâche avec ses propres mots. S’il décrit une fonction différente, mieux vaut découvrir l’écart avant d’échanger des documents ou de mobiliser l’équipe.

Demander sur quoi reposent les résultats

Un résultat de démonstration répond rarement à toutes les questions d’un futur utilisateur. Quels documents étaient disponibles ? Quelles situations étaient absentes ? Les personnes qui ont évalué les réponses connaissaient-elles déjà les dossiers ?

Vous n’avez pas forcément besoin des données confidentielles d’un autre client. Vous avez besoin d’une description assez précise pour voir si l’évaluation ressemble à votre usage. Un chiffre global, même flatteur, est difficile à interpréter si les cas simples et les erreurs importantes sont mélangés.

Nora demande des exemples d’échec commentés, ainsi que la manière dont ils ont été détectés. Elle ne cherche pas un outil qui prétend ne jamais se tromper. Elle cherche un fournisseur capable de montrer où la proposition devient moins fiable et ce que l’utilisateur observe alors.

Pour approfondir la partie documentaire, notre article sur la recherche IA chez Korean Air examine le lien entre une réponse et les dossiers retrouvés. Ici, la question est plus en amont : avons-nous assez d’éléments pour engager un essai de cet outil ?

Faire essayer la supervision à la personne concernée

La formule « validation humaine » devient utile lorsqu’on peut la décrire à l’écran. La personne voit-elle les éléments nécessaires ? Peut-elle revenir au document concerné ? Comprend-elle ce qui reste incertain ? Peut-elle continuer sans utiliser la proposition ?

Dans notre exemple, Nora invite un technicien à rejouer un dossier fictif incomplet. Elle lui demande d’expliquer ce qu’il ferait ensuite. S’il doit deviner pourquoi l’assistant a proposé une piste, le problème ne se résout pas en ajoutant une case « j’ai vérifié ».

Cette séance sert aussi à observer la charge de travail. Un outil qui exige une enquête supplémentaire pour chaque réponse peut déplacer l’effort au lieu de le réduire. On ne le découvre pas toujours dans une présentation conduite par son concepteur.

Prévoir l’arrêt et la mise à jour avant le premier essai

Un essai rassurant n’est pas un essai sans condition d’arrêt. Définissez ce qui déclenche une pause : une proposition hors périmètre, une source essentielle inaccessible ou un comportement que l’équipe ne sait pas expliquer, par exemple.

Précisez également le travail qui reprend pendant cette pause. Dans le cas de Nora, l’équipe revient à sa méthode habituelle. Le fournisseur n’a pas à être joignable pour permettre ce retour.

Enfin, demandez comment les changements seront annoncés. Un nouvel outil, une nouvelle version de modèle ou une nouvelle collection de documents peuvent justifier de rejouer certains cas. Convenez de ce qui sera conservé pour comprendre le résultat de l’essai initial, même si le produit évolue ensuite.

Une fiche pour rendre la discussion concrète

Voici un support de préparation à adapter, pas une liste d’exigences EASA. Remplissez-le avec les personnes qui feront réellement l’essai.

• La tâche : ce que l’outil prépare et ce qu’il ne décide pas.
• Les situations : les documents et difficultés représentatifs de l’usage prévu, avec les cas encore non évalués.
• Les résultats : les éléments fournis par le fournisseur et les questions qu’ils laissent ouvertes.
• La personne : qui examine la proposition et ce dont elle dispose pour la contester.
• L’arrêt : le signal qui suspend l’essai et la méthode de travail qui reprend.
• La suite : ce qui sera revérifié après un changement, et qui décide de poursuivre.

Dans le dossier fictif de Nora, une ligne reste vide : le fournisseur n’a pas encore montré le comportement sur les pièces manquantes. L’équipe conserve donc ce point comme condition préalable à l’essai. Elle ne transforme ni l’absence de réponse en preuve de danger, ni une promesse commerciale en validation.

Sortir de l’échange avec une décision compréhensible

Vous n’êtes pas obligé de conclure immédiatement par un achat ou un refus. Un essai limité peut être une bonne suite, à condition que son objectif, ses limites et sa responsabilité soient clairs.

Le résultat utile tient dans une phrase que les collègues absents comprennent : nous poursuivons sur telle tâche, avec telles personnes, après réception de tel élément. Ou nous attendons, parce que cette question reste sans réponse.

C’est une préparation concrète aux échanges sur l’IA en aviation : arriver avec un usage précis et repartir avec des preuves à examiner, plutôt qu’avec une impression générale sur la qualité de la démonstration.