Tribunes

Panne logicielle sur les Airbus A320 : les rayonnements solaires nous ont-ils aveuglés ?

---

L'ingénieur Mark Underwood s'interroge sur la panne logicielle qui a cloué au sol 6 000 A320 fin novembre. Trouvant les explications d'Airbus un peu courte.

PublicitéLe 30 octobre dernier, un Airbus A320 de la compagnie JetBlue reliait l'aéroport international de Cancún (Mexique) à celui de Newark Liberty (New Jersey) lorsqu'une chute brutale d'altitude a contraint les pilotes à un atterrissage d'urgence, à Tampa (Floride). Une fois la manoeuvre de sauvetage réussie par les pilotes, une quinzaine de passagers ont prolongé leurs vacances à l'hôpital de cette ville. Les représentants de la compagnie aérienne ont déclaré que l'avion avait été immobilisé pour inspection.

Dans un article du 28 novembre 2025, le New York Times, sur la base d'un communiqué de presse d'Airbus, revenait sur les causes avancées par le constructeur pour expliquer cet incident, ce dernier mettant en cause « un rayonnement solaire intense » comme source de la corruption « des données essentielles au fonctionnement des commandes de vol ». Une corruption de données qui expliquerait le comportement du A320 de JetBlue. Au total, c'est l'ensemble de la flotte d'A320 qui a dû subir des modifications, soit 6000 appareils. « Dans la plupart des cas, le problème peut être résolu assez rapidement en revenant à une version antérieure du logiciel », soulignait encore l'article du quotidien.

Le prix Nobel Victor Hess a découvert l'existence des rayons cosmiques en mesurant les niveaux de radiation à haute altitude lors de vols en ballon. Et c'était avant la Première guerre mondiale. Dans les années 1960, du fait de ce phénomène physique, la santé des équipages du programme spatial était une préoccupation majeure. Un article de 1975 a identifié une anomalie sur un satellite comme étant associée à une 'perturbation par une particule isolée' (en anglais, Single event upset ou SEU), causée par les radiations, et dès 1979, on savait que les systèmes électroniques pouvaient être perturbés par ces radiations y compris au niveau de la mer.

Pourquoi une version antérieure du logiciel ?

Dès 1990, la FAA (Federal Aviation Administration, une agence gouvernementale chargée des réglementations et des contrôles concernant l'aviation civile aux États-Unis) a reconnu l'existence d'un risque pour les passagers aériens. L'Airbus A320, un avion à commandes de vol électriques (fly-by-wire) fortement dépendant des ordinateurs, a été conçu à une époque où ce phénomène était donc bien compris par la communauté des ingénieurs aéronautiques.

Comme les ingénieurs logiciels de l'époque le savaient pertinemment, la gestion des SEU nécessite des fonctionnalités matérielles et logicielles. La mémoire ECC, par exemple. Des contrôles de cohérence également, au cas où un bit inversé produirait des instructions totalement aberrantes. Dès lors, pourquoi revenir à une version antérieure du logiciel serait-il la solution pour l'A320 fin 2025 ? Les fonctionnalités permettant de gérer les SEU dues aux radiations dans la version actuelle n'étaient-elles pas également présentes dans les versions précédentes ? Ou bien existait-il une nouvelle méthode pour gérer les SEU, améliorant les approches utilisées dans les versions précédentes ?

PublicitéLe fondateur d'AirAsia s'interroge publiquement

Des questions qui ont réveillé l'ingénieur qualité logiciel en moi. D'une certaine manière, toute cette histoire de radiations semblait étrangement hors de propos. Je n'allais pas être le seul à me poser des questions. Tony Fernandez est le fondateur d'AirAsia Aviation Group. La flotte actuelle d'AirAsia comprend un nombre important d'Airbus, et la compagnie a passé commande de près de 400 appareils supplémentaires. Et Tony Fernandez a fait part de ses interrogations lors d'une récente interview : « c'est assez étrange ; Airbus doit se pencher sur la question, il est évident que le système n'a pas été testé », a-t-il déclaré au South China Morning Post. Le fondateur d'AirAsia a émis l'hypothèse qu'Airbus pourrait être soumis à des contraintes liées à son objectif de production de 820 avions par an en 2025 (la compagnie a depuis revu à la baisse cet objectif, le fixant désormais à 790)

Outre l'aspect inquiétant d'une corruption de données par les radiations solaires, la cause de l'incident a été décrite comme un problème logiciel sur un calculateur (ELAC 2) gérant le tangage et le roulis de l'appareil en transmettant les commandes du manche latéral du pilote aux gouvernes de profondeur situées à l'arrière. La restauration du logiciel, solution préconisée par Airbus pour remettre les A320 en vol, a consisté à rétablir la version « L103 », en remplacement de la version « L104 ». Thales, développeur du matériel ELAC, a indiqué à Reuters que le logiciel en question ne relevait pas de sa responsabilité.

4 points clefs dans le cycle de vie du développement

Au-delà des discours sur le rayonnement solaire ou les rayons cosmiques, une discussion sérieuse sur le cycle de vie du développement logiciel (SDLC) doit avoir lieu chez Airbus. Voici quatre points clés, tous bien connus :

- Ingénierie des tests. Un bon banc d'essai pourrait simuler la télémétrie Out-of-band censée déclencher les contrôles de portée de l'ELAC. Les bancs d'essai doivent être conçus et développés en même temps que le logiciel, et non séparément.

- Intégration continue/déploiement continu (CI/CD) et qualité du pipeline. On peut y ajouter la gestion des changements ou la gestion de la configuration. Qu'Airbus ait ou non utilisé l'intégration continue/déploiement continu (CI/CD) dans son cycle de vie de développement logiciel (SDLC) pour le L104, l'entreprise s'oriente dans cette direction. Un dysfonctionnement dans le SDLC a entraîné la régression d'une fonctionnalité fondamentale. Il est peu probable que ce soit un cas isolé.

- Observabilité. J'aborde ce point car je fais partie d'un petit groupe de travail de l'IEEE (Institute of Electrical and Electronics Engineers) qui travaille sur une nouvelle version de la norme DevOps intégrant les principes d'observabilité. L'événement SEU constitue un excellent cas d'utilisation pour l'observabilité, car un ingénieur de test ne peut pas attendre qu'un rayon cosmique frappe, mais doit s'assurer que l'échec d'une réponse appropriée à un événement SEU critique puisse être observée. Cela implique une ingénierie des exigences plus rigoureuse et une meilleure compréhension de la télémétrie nécessaire aux fonctionnalités critiques.

- Supply chain. Bien que Thales n'ait selon ses dires pas été impliqué dans la version L104, la plateforme Airbus comprend des logiciels et du matériel provenant de nombreux fournisseurs. L'intégration tout au long de la supply chain logicielle présente des défis amplifiés par les exigences de sécurité et la longévité souhaitée du produit. La réponse apparemment négative de Thales (« Ce n'est pas notre problème ») pourrait indiquer des difficultés de communication et de résolution de problèmes, voire une visibilité limitée pour l'équipe de gestion des risques tiers.

Remarquez que le « codage » lui-même ne figure pas parmi les points clés. Certes, le L104 a pu introduire une erreur de packaging, une erreur de développement (par exemple, un appel de service supprimé par inadvertance, des paramètres d'API mal configurés ou mal compris, voire une erreur de syntaxe dans le code source). Ces erreurs sont courantes ; un SDLC sain les prend en compte.

Je crains encore que deux autres risques inhérents au domaine ne restent peu ou mal atténués : la complexité et la spécialisation. Gérer l'ensemble des fonctionnalités de l'A320, ou même sa nomenclature logicielle (SBOM/API-BOM), représente un défi de taille. Il faut se rappeler qu'il s'agit d'un produit lancé en 1987, nécessitant la prise en charge de matériels et de logiciels anciens sur une large base installée. La complexité et la spécialisation ne cesseront de s'accroître, compliquant les efforts de traçabilité, de transparence et de gesti

Article rédigé par

Mark Underwood, CSO (adapté par Reynald Fléchaux)

Partager cet article