L'automatisation devenue fatale : le MCAS et le 737 MAX

Comment une fonction de sécurité automatisée est devenue le rouage d'une catastrophe

Lorsque deux avions de ligne Boeing 737 MAX se sont écrasés à quelques mois d'intervalle en 2018-2019, les enquêteurs ont identifié un fil conducteur lié au logiciel de commande de vol de l'appareil. Un système conçu pour aider l'avion à gérer des moteurs de forme différente — le Maneuvering Characteristics Augmentation System, ou MCAS — a été remanié tardivement lors du développement de manière à rendre son comportement plus directif et, surtout, dépendant d'un seul capteur d'incidence. Ces modifications ont supprimé des couches de protection et ont exposé les équipages à un mode de défaillance rapide et déroutant qu'ils n'avaient pas été formés à reconnaître ou à contrer.

MCAS : ce qu'il était censé faire

Le MCAS a été introduit pour que le MAX se comporte comme les modèles de 737 précédents, après que des moteurs plus grands et montés plus en avant ont modifié l'aérodynamisme de l'avion. Sa fonction nominale était modeste : lorsque certaines conditions suggéraient que le nez de l'avion risquait de trop se cabrer, le MCAS ajustait légèrement le stabilisateur horizontal vers le bas (piqué) pour maintenir une maniabilité constante pour les pilotes. Dans sa conception initiale, il devait être subtil et n'intervenir que rarement.

Comment le système a évolué — et pourquoi cela a compté

Au cours du développement, Boeing a élargi le rôle du MCAS. La version finale pouvait s'activer plus fréquemment et appliquer des corrections de stabilisateur plus importantes que les versions précédentes, et elle était configurée pour réagir aux données d'un seul capteur d'incidence plutôt que de recouper plusieurs sources. Dans les accidents de Lion Air et d'Ethiopian Airlines, des données d'incidence erronées ont déclenché des commandes de piqué répétées que les pilotes ont combattues sans parvenir à les surmonter à temps. Le passage d'une conception conservatrice et redondante à une mise en œuvre plus agressive à capteur unique a été un facteur décisif dans ces défaillances.

Pourquoi qualifier le MCAS d'« I.A. » est trompeur — et pourquoi l'étiquette importe malgré tout

Dans les médias et le débat public, les crashs sont parfois présentés comme une défaillance de l'« I.A. ». Ce raccourci est tentant mais imprécis. Le MCAS n'était pas un modèle d'apprentissage automatique (machine learning) s'auto-formant à partir de données ; il s'agissait d'une logique de commande de vol déterministe : des règles codées pour agir en fonction d'entrées de capteurs spécifiques. Le danger, cependant, est le même que celui qui inquiète les gens avec les systèmes d'IA opaques : un comportement automatisé caché aux utilisateurs finaux et aux régulateurs, interagissant avec des signaux du monde réel de manière complexe que ses concepteurs n'avaient pas pleinement anticipée.

Qualifier le MCAS de simple « automatisation » peut minimiser la manière dont les choix de conception — en particulier autour de la transparence, de la redondance et de l'interaction homme-machine — ont transformé une fonction protectrice en un danger. Ces vols révèlent que même les algorithmes sans apprentissage exigent une ingénierie de sécurité rigoureuse, le même type d'exigences traçables et de tests indépendants que nous demandons désormais aux systèmes d'IA dans d'autres domaines.

Des défaillances organisationnelles et réglementaires ont amplifié les défauts techniques

Les choix techniques ne se sont pas produits dans le vide. De nombreux examens et auditions ont révélé que des problèmes de surveillance, de communication et de culture d'entreprise ont amplifié les risques. Les régulateurs n'ont pas toujours reçu tous les détails du MCAS au fur et à mesure de son évolution ; les manuels de vol omettaient initialement la fonction ; et l'hypothèse selon laquelle le MCAS s'activerait rarement a réduit la formation des pilotes sur la manière de réagir en cas d'activation. Ces défaillances institutionnelles ont transformé une erreur d'ingénierie en une crise de sécurité publique.

Les correctifs mis en œuvre par Boeing et les régulateurs

Après l'immobilisation au sol de la flotte de MAX, Boeing et les autorités aéronautiques ont imposé des modifications logicielles et opérationnelles. La conception révisée limite le MCAS de sorte qu'il n'agisse que si les deux capteurs d'incidence sont d'accord, le restreint à une seule activation par événement et modère l'ampleur des commandes de compensation. Les régulateurs ont également durci les exigences en matière de documentation, de formation des pilotes et de vérification indépendante avant que le modèle ne soit autorisé à reprendre du service. Ces changements ont corrigé les modes de défaillance immédiats mais n'effacent pas les questions de gouvernance plus larges soulevées par la crise.

Leçons pour le débat plus large sur l'IA et l'automatisation

L'histoire du MAX est un avertissement pour quiconque déploie l'automatisation à grande échelle. Quatre leçons se dégagent :

Ce sont des refrains familiers dans les cercles d'éthique et de sécurité de l'IA, mais le 737 MAX montre qu'ils ne sont pas abstraits. Dans les systèmes critiques pour la sécurité, les coûts d'une erreur sont immédiats et définitifs.

Vers où le débat doit s'orienter

Des corrections techniques ont permis au MAX de reprendre du service sous des conditions plus strictes, mais cet épisode reste une référence sur la manière de ne pas gérer l'automatisation dans les industries réglementées. Pour les décideurs et les ingénieurs, l'impératif est de traduire les leçons apprises en normes applicables : des processus de certification plus clairs pour les systèmes de décision automatisés, une notification obligatoire des changements de conception substantiels et des structures institutionnelles qui réduisent les conflits d'intérêts entre les fabricants et les certificateurs.

Pour les journalistes et le public, c'est aussi un rappel à la précision des termes. L'« IA » fait les gros titres, mais le problème de fond dans le cas du MAX n'était pas l'intelligence artificielle au sens de l'apprentissage automatique — c'était une combinaison d'automatisation agressive, d'un manque de transparence et de pratiques de sécurité affaiblies. Traiter cette combinaison comme un défi d'ingénierie et de gouvernance nous offre une voie plus productive pour éviter une répétition.

Conclusion

Les catastrophes du 737 MAX n'étaient pas inévitables. Elles ont été le résultat de décisions de conception spécifiques, d'hypothèses non vérifiées et de défaillances institutionnelles. Alors que l'automatisation et l'IA s'étendent à de nouveaux domaines, le cas du MAX doit rester un exemple frappant : des systèmes plus sûrs ne naissent pas de la confiance en un morceau de code, mais d'une conception conservatrice, d'une communication claire avec les utilisateurs, d'un examen indépendant et d'une surveillance réglementaire robuste. Ce ne sont pas des finesses techniques, ce sont des conditions préalables à la sécurité publique.