Pour le grand public, la caractéristique clé de l’autoproclamée cinquième génération est sa faible observabilité radar. Pourtant, et à l’heure où le glaive va rattraper le bouclier, une autre révolution se joue dans les avions d’armes ; non pas furtive, mais invisible aux yeux des non-avertis. C’est l’informatique embarquée. Comment va-t-elle évoluer à l’horizon 2030 ? Nous vous proposons de nous pencher sur deux avions que tout semble opposer, le F-35 et le Rafale. Nous étudierons premièrement leur genèse respective avant de faire un exercice de projection de ces capacités.
La numérisation de notre monde (« digitalisation » en franglais) nous touche tous, et impacte absolument tout. Dans l’aviation, il n’existe plus une fonction, essentielle ou non, qui ne soit pas gérée par de l’informatique embarquée.
Il n’y a plus aujourd’hui de salut pour un avion sans une capacité de calcul embarquée phénoménale, quand elle est comparée à ses prédécesseurs ; ou même seulement comparée à la précédente itération du standard d’un même appareil.
Dans les années 1980, la généralisation des microprocesseurs a permis un bond sans précédent dans les capacités embarquées des avions de combat. Les radars sont devenus plus performants, mais également les contre – mesures. Une anecdote illustre bien ce fait. Dans les premiers E‑3 Sentry reçus par l’armée de l’Air, les fameux AWACS, la capacité de calcul était insuffisante pour assurer la surveillance du ciel français, le plus densément survolé au monde. Bien que les calculateurs embarqués fussent aussi encombrants que plusieurs armoires normandes (en volume et en masse), ils peinaient à suivre autant de pistes. Les opérateurs devaient alors mettre plusieurs secteurs en sommeil. Cette limitation a disparu lors de la première mise à jour au standard Block 40/45. Actuellement, la puissance de l’informatique embarquée dans les avions de combat moderne est à des années – lumière de la modernisation précédemment citée. La première question que vous pourriez poser est : pourquoi ce besoin de puissance ?
La réponse est relativement simple : la multiplication exponentielle des données à traiter, et la croissance non moins exponentielle de la complexité des logiciels embarqués. Une caractéristique essentielle des avions de nouvelle génération est la fusion de données des capteurs. Auparavant, le pilote gérait des données provenant des affichages de ses différents capteurs. Ici le radar, ici le RWR (Radar warning receiver), là l’IRST (Infrared search and track), puis les pistes provenant de la Liaison‑16, ou des informations provenant d’un contrôleur, via la radio. La charge mentale du pilote était extrême, car la création de l’image de la situation tactique provenait directement du traitement fait par son propre cerveau. Remplacer le cerveau humain afin de réaliser l’ensemble de ces tâches automatiquement, et surtout de façon fiable, n’est pas une mince affaire. Cela requiert des logiciels performants, complexes et critiques, qui doivent reposer sur des architectures de calculateurs qui le sont tout autant.
Le F-35 et la difficile articulation des Blocks
L’avènement des radars à antenne active (AESA), où chacun des centaines de modules émetteurs qui les composent devient lui – même un miniradar, nécessite un pilotage fin. Mais les possibilités fournies, si elles semblent infinies (accroissement de la portée, sauts de fréquences, multitâches, etc.), nécessitent également une débauche de puissance de calcul. Sur un F‑35, il est difficile d’appréhender la quantité de données récoltées de façon passive par l’AN/AAQ‑37 DAS, une suite de capteurs infrarouges disposés tout autour de l’avion afin d’obtenir une vision sphérique complète. Chaque rayonnement infrarouge doit être analysé, et si possible croisé avec d’autres sources, que ce soit en provenance du radar, de la suite de guerre électronique AN/ASQ‑239, ou depuis des sources externes, partagées par d’autres avions d’une même patrouille, ou depuis un centre de commandement C2. Tout cela afin de fournir au pilote une vision la plus claire possible de la situation tactique. Sachant que le système peut capter des rayonnements infrarouges provenant d’un missile balistique tiré à plusieurs centaines de kilomètres de distance, on ne peut qu’imaginer la puissance nécessaire au traitement d’un tel volume de données, tant les signaux arrivant sur ce système passif sont nombreux, d’autant plus lors du survol d’une zone de guerre.
De même, la suite de guerre électronique, à laquelle le radar est fortement intégré, est capable d’analyser tous les signaux électromagnétiques sur toutes les fréquences possibles utilisées dans le combat aérien, et ce, dans toutes les directions. Si ces tâches étaient auparavant dévolues à des avions spécifiques, voire à des nacelles qui collectaient ce renseignement d’origine électromagnétique grâce à des avions à mission spécialisés, le F‑35 est désormais capable de collecter, d’analyser et de réagir en temps réel à toute menace lui étant opposée. Encore une fois, ce que voient le radar, le système de guerre électronique et le DAS, sont fusionnés et offerts au pilote sous une représentation visuelle unique.
Là sont combinées toute la force et toute la faiblesse du F‑35. Force, car cette capacité le place théoriquement en avance sur son temps. Faiblesse, car le développement de ces capacités a mis les équipes de développement à rude épreuve. Celle-ci est principalement due à une gestion de programme n’ayant pas pris en compte l’extrême complexité du développement de ces capacités, pourtant mise en lumière dès le début du programme par le DOT&E (Department of operational tests and evaluation, organisme du Pentagone chargé de suivre et d’évaluer les programmes d’armement majeurs).
Une mauvaise estimation des besoins de calculs a été identifiée dès le début du programme de développement, lors du début de l’intégration des systèmes dans l’avion, alors que la conception du Block 2 n’en était qu’à ses débuts. À partir de ce constat, le programme a dû intégrer ce qui a été sobrement appelé le TR2, pour Technological refresh 2 : un nouveau calculateur central, multipliant la puissance brute par quarante, et apportant suffisamment de marge de manœuvre pour le futur. Il n’en sera rien. Mal estimé, le nombre de lignes de code nécessaire a conduit à une insuffisance en cascade d’autres éléments. Sur ce point comme tant d’autres, le programme a failli. On peut citer également la mauvaise estimation du nombre de calories émises, qui a nécessité une profonde revue du système de refroidissement, elle – même dépendant d’un moteur capable de fournir un surcroît de puissance à l’échangeur thermique. Cela n’est pas lié qu’à l’accroissement de la puissance de calcul, mais démontre la mauvaise gestion des premiers travaux qui sont censés définir l’architecture globale de l’avion.
L’intégration du TR2 a nécessité la réécriture quasi complète des interfaces du logiciel, afin de le rendre compatible avec le nouveau calculateur. Alors que les retards s’accumulaient déjà, et que le Block 3, le standard auquel l’avion aurait eu ses capacités de combat complètes, aurait déjà dû être livré, Lockheed Martin joua un tour de passe – passe d’ordre politique en nommant ce nouveau standard intermédiaire Block 3I. Or, le Block 3I ne possédait aucune capacité initialement prévue au Block 3, et n’était qu’un portage des codes logiciels du Block 2 sur le matériel TR2, ni plus ni moins.
Pourtant quarante fois plus puissant, le TR2 équipant les avions livrés à partir de 2015 s’est lui aussi rapidement montré insuffisant. La fuite en avant en termes de besoin de puissance, toujours liée aux mauvaises estimations initiales, n’a pas été corrigée. Les recommandations du DOT&E ne furent toujours pas suivies d’effets, et le programme n’a pas été remis sur les rails. Ce n’est qu’en 2019 que la critical design review valide les éléments d’un TR3, fourni par l’entreprise américaine L3Harris Technologies.
Les difficultés du fournisseur à monter en cadence ont eu pour conséquence des délais sur la chaîne de production. Mais cela n’est rien à côté d’une autre décision, incompréhensible, de Lockheed Martin : porter les codes logiciels du Block 3F, pourtant déjà instables, directement (sans réécriture donc) sur le nouveau matériel. La dégradation de l’instabilité des systèmes du F‑35 a été telle que le Pentagone a pris une décision d’une gravité sans précédent, en refusant la livraison de centaines d’appareils, engorgeant la production à tous niveaux.
Pour les industriels, une solution temporaire a été négociée avec l’armée américaine. En l’espèce, elle accepta de prendre livraison d’avions dont les logiciels embarqués ont été castrés de tout ce qui en faisait un avion de combat. Plus d’un an a été nécessaire pour que la livraison des avions reprenne, mais des avions seulement dévolus à l’entraînement ; qui plus est, un entraînement limité puisqu’aucune mission de combat n’était possiblement réalisable du fait de l’indisponibilité quasi totale de l’ensemble des logiciels de mission. Un rapport de la Cour des comptes américaine daté du 3 septembre 2025 indique que les avions équipés du TR3, soit tous ceux livrés depuis juillet 2024, ne posséderont aucune capacité de combat avant mi-2026, au mieux. Cela inclut donc les quatre F‑35 tout juste livrés à la Belgique, qui font la fierté de son ministre de la Défense.
Au chapitre des bonnes nouvelles, il faut mentionner que le système livré par L3 Harris possède enfin une architecture ouverte, intégrant la virtualisation, et qu’il devrait être facilement évolutif. Sous réserve de réussir à stabiliser la complexe intégration des logiciels, dans un programme où tout est développé sans utiliser aucune des bonnes pratiques d’une gestion de projet, les systèmes du F‑35 seront alors ouverts à une évolutivité sans accroc.
Le cas du Rafale
Du côté français, et en mettant de côté le standard particulier que fut le F1, le développement des capacités de combat du Rafale a réellement démarré avec le standard F2. Très rapidement identifié comme insuffisant, le calculateur intégré au standard F1 fut remplacé par l’EMTI (Ensemble modulaire de traitement de l’information) de Thales. Dans ce système, des cartes embarquant des calculateurs et de la mémoire sont insérées dans un fond de panier pouvant en accueillir 18. Jusqu’à son remplacement par un modèle plus récent, l’EMTI a pu accueillir différentes générations de cartes. Les processeurs, équivalents au POWER PC, en architecture RISC, intègrent nativement une capacité de virtualisation des systèmes (voir encadré), et plusieurs générations de processeurs se sont succédé dans l’EMTI, augmentant graduellement la puissance embarquée en fonction des évolutions des logiciels.
Moins marquées sur le Rafale par rapport au F‑35, les évolutions furent néanmoins progressives et continues. Ainsi, tout en gardant la même architecture globale, et sans avoir à redéfinir la partie logicielle, les éléments de l’EMTI continuent à être mis à jour, supportant l’accroissement des besoins en termes de puissance de calcul. En effet, l’arrivée de la version AESA du radar RBE2 et du DDM‑NG (Détecteur de départ missile de nouvelle génération) et le développement de nouveaux standards comme le F4 et ses trois sous – itérations ont accru les besoins, et ceux-ci continueront d’augmenter.
Le standard F4 va intégrer nombre de caractéristiques propres aux avions de nouvelle génération (certaines le sont déjà), dont une forte propension à la communication via l’intégration dans des réseaux de communication tactiques à haut débit. La véritable modernisation, qui impliquera certainement une refonte du cœur informatique du Rafale, débarquera avec le standard F5. Mais, basé sur une architecture ouverte et grâce à la virtualisation, le développement de ce nouveau standard devrait logiquement s’appuyer sur l’existant. Il est ainsi plus simple d’apporter des améliorations itératives au niveau logiciel lorsque l’infrastructure matérielle, basée sur la modularité, mais également l’architecture logicielle sont conçues dès l’origine pour pouvoir être améliorées de façon continue. D’une certaine façon, il s’agit ici de l’application de la philosophie dite « des petits pas » chère à feu Marcel Dassault, qui visait à ne jamais intégrer trop d’éléments de rupture technologique dans un même projet, afin de ne pas accroître le risque.
De façon intentionnelle ou non, cette philosophie est démontrée par la relative simplicité avec laquelle les standards successifs du Rafale sont développés, intégrant des évolutions majeures par incrément. Cela contraste fortement avec le programme F‑35 qui a voulu intégrer dès le départ nombre de caractéristiques nouvelles et de rupture par rapport aux avions en service au moment de son lancement. À l’horizon 2030, nous aurons donc deux programmes avec deux inconnues. Deux inconnues certes, mais avec des paramètres complètement différents. Concernant le Rafale, nous ne savons pas exactement quelles seront les évolutions embarquées dans ses systèmes. Dassault ayant embrassé et maîtrisé l’architecture ouverte dès le départ, on peut raisonnablement gager que les systèmes évolueront de façon pragmatique, offrant aux utilisateurs du Rafale une base saine pour agrémenter « facilement » les futurs standards avec des fonctionnalités nouvelles.
Du côté du F‑35, gageons que l’adoption de technologies similaires (architecture ouverte, modularité et virtualisation) permettra de stabiliser l’architecture des systèmes informatiques embarqués. Mais cela étant dit, la dette technique accumulée dans les développements successifs menés de façon erratique et ayant eu pour conséquence un accroissement de l’instabilité des systèmes dans le temps ne permet pas de présager ce qu’il en sera à l’horizon 2030. Au pied du mur, les équipes de Lockheed Martin et le Joint Program Office prendront-ils les bonnes décisions ? Seul l’avenir nous le dira…
Bruno Etchenic