Le cockpit comme interface : ce que l’aéronautique peut enseigner aux designers

L’aviation a passé un siècle à apprendre, souvent au prix fort, comment faire cohabiter des humains avec des systèmes complexes. Le résultat est sans appel : l’aviation civile est aujourd’hui l’un des modes de transport les plus sûrs au monde. Non pas parce qu’il n’y a plus d’erreurs de pilotage, mais parce que l’industrie conçoit en intégrant l’erreur humaine plutôt qu’en comptant sur son absence.

Ce secteur est une véritable mine d’or pour nous, designers : le cockpit peut être perçu comme une interface, utilisée par le pilote (l’utilisateur) pour effectuer son vol (le parcours utilisateur), où la moindre friction peut devenir… critique.

En effet, de nombreux concepts que l’on croit issus du monde numérique ou industriel ont en réalité été initiés dans l’aéronautique : check-list, dégradation progressive, standardisation, débriefing, culture du retour d’expérience, et j’en passe.

À travers cet article, je vais vous en partager quelques-uns, particulièrement utiles pour nous, designers.

Concevoir contre l’erreur, prévoir la panne

Dans les années 1940, le psychologue Paul Fitts observait que des pilotes confondaient régulièrement la commande des volets et celle du train d’atterrissage ; deux leviers identiques, côte à côte. Sa conclusion, à l’origine de l’ergonomie cognitive moderne : mieux vaut rendre l’erreur physiquement impossible (des leviers de forme différente) que de former des pilotes à ne jamais se tromper.

Mais aucune prévention n’est jamais totale. Les systèmes avioniques critiques partent donc d’un second principe, complémentaire : la dégradation progressive. En cas de panne d’un capteur ou d’un calculateur, l’appareil ne s’arrête pas net ; il bascule sur un mode dégradé mais pilotable, avec une information claire sur ce qui manque. La redondance n’y est pas un luxe, c’est prévu dès le cahier des charges.

Pour nous, designers :
Il s’agit de concevoir en prenant en compte les erreurs d’usage, en partant du principe que les utilisateurs se tromperont et qu’il y aura des erreurs techniques. Une API peut être lente, voire devenir indisponible ; une image peut ne jamais se charger ; une donnée peut être obsolète ou manquante ; une session peut expirer ; la connexion se perdre, etc. Notre rôle n’est donc pas seulement de définir ce qui se passe quand tout va bien, mais d’anticiper : « Que se passe-t-il si telle erreur se produit ? ».

En pratique :

  • Un pilote perd son écran principal à la suite d’une panne électrique, mais un instrument de secours analogique lui permet de continuer à voler en sécurité jusqu’à l’atterrissage.
  • Un utilisateur remplit un formulaire de commande depuis dix minutes quand l’API de paiement tombe : plutôt que de perdre sa saisie et de tout recommencer, il retrouve son panier intact et peut réessayer ou choisir un autre moyen de paiement.

Parler doit être plus facile que se taire

Le 27 mars 1977, à l’aéroport de Tenerife, deux Boeing 747 (KLM et Pan Am) sont entrés en collision sur la piste : l’accident le plus meurtrier de l’histoire de l’aviation civile.

Parmi les causes identifiées : quelques secondes avant la collision, l’ingénieur de bord du vol KLM a exprimé un doute sur l’autorisation de décoller. Un signalement avait également été formulé par le copilote au moment de la mise des gaz : « Wait a minute, we don’t have an ATC clearance ». Mais, face à la réponse assurée du commandant de bord, ces doutes ne se sont pas transformés en objections suffisamment fermes pour interrompre le décollage.

Cet accident a joué un rôle majeur (exemple emblématique des dangers d’une mauvaise communication) dans la création du Crew Resource Management (CRM) à la fin des années 70. Cette méthode apprend aux équipages à mieux communiquer, coopérer et prendre des décisions collectivement afin de faire remonter doutes et informations critiques, quel que soit le rang de la personne qui les exprime, et d’éviter les erreurs humaines.

Pour nous, designers :
Bien que des vies ne soient pas en jeu, il est intéressant de s’inspirer de cette mécanique. Si un membre de l’équipe perçoit une erreur ou un problème critique, il ne doit pas avoir à choisir entre se taire et contredire sa hiérarchie. Si la prise de parole devient coûteuse, les problèmes resteront sous le radar. Créer des espaces/moments où la critique est attendue, où le doute peut être exprimé sans risque et où chacun peut challenger une décision n’est pas du confort : c’est une condition de qualité.

En pratique :

  • Un copilote junior remarque une vitesse d’approche anormale et l’annonce fermement au commandant, qui décide d’interrompre l’atterrissage et de remettre les gaz.
  • Un designer junior repère un problème d’accessibilité bloquant sur une fonctionnalité que le lead veut livrer le jour même, et ose le signaler en revue plutôt que de se taire par crainte de le contredire.

La standardisation comme économie cognitive, pas comme uniformisation forcée

Airbus a fait un choix radical dès les années 1980 : harmoniser au maximum les commandes, l’agencement et la logique des cockpits sur l’ensemble de ses modèles, du monocouloir A320 au gros-porteur A350.

Le résultat : Airbus estime que sa stratégie de « commonalité » peut réduire, en moyenne, jusqu’à deux tiers les coûts de requalification lors d’un changement d’appareil, tout en diminuant le risque d’erreur lié au changement de contexte. Boeing, à l’inverse, a longtemps privilégié l’optimisation technique modèle par modèle, au prix d’une transition plus lourde entre appareils.

Pour nous, designers :
C’est exactement l’argument de fond d’un design system. Quand les éléments constitutifs d’un système se comportent de la même façon d’un outil à l’autre, dans tout l’écosystème, c’est du temps de réapprentissage économisé pour les utilisateurs, et du temps de conception gagné pour les équipes à la création de chaque nouvel outil.

En pratique :

  • Un pilote qualifié sur A320 est affecté sur un vol A350 et retrouve une disposition de commandes et une logique de pilotage immédiatement familières, sans requalification lourde.
  • Un designer change d’équipe produit en interne et retrouve les mêmes composants et tokens que sur son projet précédent : il est opérationnel en quelques jours plutôt qu’en plusieurs semaines.

Se méfier de sa propre automatisation

En 1997, le commandant de bord et instructeur Warren Vanderburgh a inventé l’expression « Children of the Magenta » ( « enfants de la ligne magenta » ) pour décrire des pilotes tellement habitués à suivre la trajectoire automatique affichée à l’écran qu’ils en perdaient leurs réflexes de pilotage manuel.

Son propos n’était pas de ne pas utiliser l’automatisation, mais de savoir choisir le niveau d’automatisation approprié et, lorsque la situation l’exige, de « descendre d’un niveau », jusqu’à repasser au pilotage manuel si nécessaire. Le pilote ne doit pas seulement surveiller ce que fait l’avion : il doit comprendre ce que fait l’automatisation, pourquoi elle le fait, et quand reprendre le contrôle.

Un exemple concret de ce phénomène est l’accident du vol Air France 447 en 2009. Les sondes Pitot de l’A330 ont givré, provoquant des indications de vitesse incohérentes. Le pilotage automatique s’est alors déconnecté et l’équipage s’est retrouvé dans une situation inhabituelle, qui nécessitait une compréhension rapide de ce qui se passait et un pilotage manuel. Le pilote et son équipage n’ont pas été en capacité de revenir rapidement à une compréhension de l’avion et à son pilotage.

Pour nous, designers :
A l’heure de l’usage massif des LLM pour produire des maquettes, du contenu ou du code en quelques secondes, le risque n’est pas d’utiliser ces outils, mais de ne plus savoir quoi faire lorsqu’ils commettent des erreurs. Nous devons être capables de garder un regard critique et de préserver des compétences fondamentales, afin d’analyser, de comprendre et d’expliquer pourquoi une solution est bonne ou mauvaise, voire de reprendre la main via un travail manuel.

En pratique :

  • Un pilote traverse une couche nuageuse quand l’autopilote se déconnecte brutalement : il doit avoir gardé les réflexes nécessaires pour reprendre l’avion en pilotage manuel, sans hésitation.
  • Un designer a délégué une grande partie de son travail à un LLM ; le soir où il doit livrer et que l’outil devient indisponible ou produit une erreur, il doit être capable de reprendre la main et de finir le travail lui-même.

La compétence à une date de péremption

Dans l’aéronautique, on distingue la qualification de la currency : être certifié signifie avoir démontré que l’on possède les compétences requises, mais ne garantit pas qu’elles resteront parfaitement maîtrisées dans le temps. Certaines activités exigent donc une pratique récente et des renouvellements réguliers. Un pilote peut toujours détenir sa licence tout en n’étant plus autorisé et des renouvellements réguliers faute d’avoir suffisamment pratiqué.

Cette distinction repose sur une idée assez simple : une compétence n’est pas quelque chose que l’on possède définitivement, mais une capacité devant être entretenue. Elle s’entretient, se vérifie et peut s’éroder si elle n’est plus utilisée. Dans un environnement où les procédures, les outils et les situations évoluent, le risque n’est pas seulement de ne jamais avoir appris quelque chose, mais de croire que l’on le maîtrise encore, car on l’a appris un jour.

Un pilote peut connaître parfaitement les procédures, avoir réussi ses examens, conserver ses qualifications, tout en ayant perdu une partie de ses automatismes après une longue période sans pratiquer.

Pour nous, designers :
Le même phénomène existe aussi. Lorsque que nous formons nos équipes à de nouvelles compétences, capacités ou outils, cela ne garantit pas que les pratiques seront encore maîtrisées six mois plus tard. Seule la pratique régulière la maintient. Néanmoins, l’objectif n’est pas de vérifier indéfiniment qu’un designer a déjà appris quelque chose, mais de créer des conditions pour que cette compétence reste disponible, partagée et fiable lorsqu’elle sera nécessaire. De plus avec l’usage massive des LLMs dans nos métiers, il est plus qu’important de toujours s’assurer que nos compétences restent maîtrisées.

En pratique :

  • Un pilote qualifié aux instruments n’a pas volé en conditions IFR depuis huit mois ; le jour où il traverse une couche nuageuse imprévue, ses réflexes ne sont plus aussi sûrs que sur le papier.
  • Un designer formé à la conduite d’ateliers de recherche utilisateur il y a un an, mais qui n’en a plus animé depuis, se retrouve en difficulté le jour où on lui demande d’en mener un en urgence sur un sujet critique.

Conclusion

Rien de tout cela ne prétend faire du design une discipline aussi rigoureuse, ni aussi mortelle, que l’aéronautique. Un logiciel mal conçu ne fait ni morts, ni blessés.

Alors, pourquoi ce détour par l’aviation ?
Parce qu’en creusant ces exemples, un même mot revient souvent, sous une forme différente : anticiper. Fitts anticipe l’erreur dans la conception du cockpit plutôt que de compter sur l’attention seule du pilote. Le CRM anticipe le moment où un doute doit devenir une objection, avant qu’il ne soit trop tard. La dégradation progressive anticipe la panne plutôt que de la découvrir en vol. La currency anticipe l’érosion d’une compétence, en imposant une pratique régulière plutôt qu’une confiance aveugle dans un diplôme passé.

Faire du design, à mon sens, c’est imaginer, anticiper, prévoir, et surtout faire. Faire au sens le plus concret du terme, avec ses mains, sa tête, ses erreurs, sa pratique répétée. Un designer qui ne dessine plus lui-même, qui ne structure plus, qui n’arbitre plus, perd la même chose qu’un pilote qui ne vole plus en manuel. Pas seulement un savoir-faire. La capacité à réagir le jour où quelque chose se dérègle.

Or, c’est précisément ce qui est en train de disparaître, par deux voies différentes. D’un côté, une course effrénée à la production, où il faut livrer toujours plus et plus vite. De l’autre, l’usage massif des LLMs, qui peut nous faire déléguer, non seulement l’exécution, mais la réflexion elle-même, au point de ne plus savoir refaire, seuls, ce que l’outil vient de faire à notre place.

Pour conclure, je terminais sur le fait qu’aujourd’hui un designer doit donc savoir couper son « pilote automatique », avant que ce ne soit lui qui décide de le faire à sa place.

Annexes

Documents m’ayant été utiles à la rédaction de cet écrit (liste non exhaustive) :

Pour en savoir plus sur les images utilisées :

Published: 09/22/2026

Using human-centered design to transform complex systems into clear, effective and engaging tools. My goal? Create value by merging both design and technology.

Let's work together!

Contact