Dassault Aviation confirme une architecture « archifermée » pour le Rafale F5

Et si le futur du Rafale F5 tenait dans un paradoxe assumé ? Alors que l’Armée de l’Air & de l’Espace accélère sur l’intelligence artificielle et les drones de combat collaboratifs, Dassault Aviation confirme une architecture « archifermée » pour son prochain standard. Découvrez pourquoi ce choix, à première vue contre-intuitif, pourrait s’imposer… et ce qu’il change pour les opérations, l’industrie, et la coopération avec les alliés. La raison surprenante derrière cette fermeture, les marges d’ouverture possibles, et l’impact sur les drones de combat seront détaillés plus loin.

Une révolution en marche… sous contraintes

Depuis plusieurs années, les armées occidentales convergent vers un modèle de combat collaboratif : plateformes habitées, « ailiers » téléopérés, capteurs distribués, cloud tactique et IA embarquée convergent pour accélérer le tempo décisionnel et saturer l’adversaire. En France, cette transition s’incarne dans HypAIRion, un projet de l’Armée de l’Air & de l’Espace (AAE) visant à tester rapidement des algorithmes d’IA, à développer une autonomie algorithmique robuste et à valider de nouvelles briques logicielles en conditions réelles.

Le choix de la plateforme de test dit tout : deux Mirage 2000D RMV du Centre d’expertise aérienne militaire (CEAM) servent de banc d’essai, car leur architecture informatique est suffisamment ouverte pour accueillir modifications et expérimentations sans tout requalifier. Les spécialistes de l’Escadron des systèmes d’information opérationnels et de cyberdéfense (ESIOC) peuvent ainsi « ouvrir le capot », injecter du code, itérer vite, et mesurer l’apport concret sur des missions représentatives.

À l’inverse, le Rafale, bardé de systèmes critiques, repose sur une architecture plus verrouillée. Ce constat explique en partie le clivage qui monte entre besoin d’agilité logicielle et exigences de sûreté de fonctionnement et de cybersécurité. Jusqu’où peut-on « ouvrir » un avion de combat de première ligne ? Et surtout, jusqu’où doit-on l’ouvrir ?

Pourquoi un « cœur superfermé » sur Rafale F5 ?

Lors d’une audition au Sénat, Éric Trappier, PDG de Dassault Aviation, a été clair : l’architecture du Rafale F5 sera « fermée », même « archifermée ». La raison numéro un ? La dissuasion nucléaire. Quand un système est engagé sur une mission nucléaire, aucun compromis n’est possible : la chaîne fonctionnelle doit être non subvertible, les surfaces d’attaque réduites au strict minimum, et les passerelles avec des réseaux externes limitées, voire neutralisées.

Concrètement, cela signifie :

• Isolation maximale des fonctions critiques (avionique de vol, capteurs maîtres, calculateurs de mission) ;
• Contrôle drastique des mises à jour (cycle de certification long, traçabilité, homologation durcie) ;
• Minimisation des interfaces pour réduire le risque cyber et les dépendances logicielles ;
• Fonctionnement dégradé résilient en environnement brouillé, sans coopération externe si nécessaire.

Ce « cœur du cœur » verrouillé ne signifie pas une coupure totale du monde extérieur. Le Rafale dialogue déjà via la Liaison 16 (L16), un standard OTAN chiffré. Mais la doctrine française revendique la capacité à désinstaller ou désactiver certaines interfaces lorsque l’intégrité absolue est requise. Un choix assumé, car la meilleure défense contre une compromission, c’est encore l’absence d’interface superflue.

Le Mirage 2000D, laboratoire d’agilité que le Rafale ne peut pas être

Pourquoi tant de liberté côté Mirage 2000D RMV ? Son architecture « ouverte » et sa maturité industrielle offrent une flexibilité rare : on peut y embarquer des modules expérimentaux, simuler des comportements de drones, injecter des algorithmes de détection ou de fusion multi-capteurs, sans menacer le noyau sécuritaire. Au CEAM, cette logique s’apparente à un DevSecOps militaire : prototyper, voler, mesurer, corriger, re-voler.

Avantage décisif : le temps opérationnel. Là où un grand système propriétaire réclame des mois de coordination, une architecture plus ouverte permet d’itérer à l’échelle des semaines. Sur le tarmac, au petit matin, quand l’air sent encore le kérosène froid, un ingénieur peut valider la version « n + 1 » d’un algorithme dès le retour de vol d’essai. C’est concret, mesurable, et ça accélère l’appropriation par les équipages.

Ouvrir sans s’exposer : la piste des architectures « à deux vitesses »

Comment concilier la fermeture exigée par la dissuasion et l’ouverture nécessaire au combat collaboratif ? La réponse de Dassault tient en une image : deux architectures. Un « cœur du cœur » intrinsèquement fermé, et une coquille d’accueil plus flexible, capable d’intégrer des fonctions évolutives, sans jamais compromettre le noyau critique.

Dans la pratique, cela renvoie à des mécanismes bien connus en cybersécurité :

• Compartimentation stricte des domaines (séparation physique et logique des bus et calculateurs) ;
• Passerelles unidirectionnelles (« data diodes ») pour empêcher tout retour d’information malveillant vers le cœur ;
• Sandboxing des charges utiles logicielles non-critiques, réinitialisées et auditables ;
• Chaînes d’attestation et de signature renforcées pour chaque brique logicielle.

Ce compromis n’est pas une singularité française : aux États-Unis, le Département de la Défense pousse le MOSA/OMS (Modular Open Systems Approach / Open Mission Systems) tout en verrouillant les couches critiques des systèmes NGAD. La France suit la même philosophie, mais son exigence nucléaire ajoute une couche de rigueur qu’on ne peut pas « modulariser » sans pertes de garanties.

Peut-on séparer Rafale « nucléaire » et Rafale « conventionnel » ?

La suggestion a été évoquée : distinguer les avions dédiés à la mission nucléaire de ceux employés au conventionnel. Sur le papier, cela faciliterait l’ouverture logicielle des seconds. Dans la réalité, cette option se heurte à plusieurs murs :

• Exigences de la FANu (Force aéronavale nucléaire) : la Marine a besoin de flexibilité et de disponibilité sur porte-avions ;
• Polyvalence opérationnelle des FAS (Forces aériennes stratégiques) : les appareils sollicités en opérations « classiques » ne peuvent être figés dans un rôle unique ;
• Coûts et logistique d’une flotte duale avec deux chaînes de configuration et d’homologation séparées.

Au total, l’option « double flotte » risque d’amputer la réactivité opérationnelle. L’enjeu n’est donc pas de créer deux Rafale, mais de penser une architecture unique, stratifiée, où l’ouverture s’exerce dans un périmètre maîtrisé.

Coopérer sans se trahir : liaisons, brouillage et résilience

Un avion « archifermé » coopère-t-il encore ? Oui, mais à ses conditions. Le Rafale F5 doit rester capable d’opérer en essaim distribué, tout en survivant à des environnements très brouillés où toute liaison peut s’effondrer. Concrètement, cela implique :

• Hiérarchie des dépendances : capacités de combat conservées même en silence radio ;
• Régimes de coopération adaptatifs : de la L16 ou liaisons nationales chiffrées jusqu’au mode « autonome » sans partage ;
• Débrayage sélectif de certains systèmes pour garantir l’intégrité de mission « suprême ».

Cette approche oblige également à penser la gouvernance des données : qui possède la donnée générée par les systèmes d’armes ? Qui peut y accéder et la réutiliser pour entraîner des IA ? Les armées françaises défendent une ligne claire : accès libre aux données utiles et capacité de mise à jour rapide, tout en respectant le sanctuaire du noyau critique.

HypAIRion : des algorithmes qui volent vraiment

Au-delà des principes, ce qui compte, c’est la capacité à faire voler des logiciels dans les semaines, pas dans les années. HypAIRion vise justement à industrialiser une boucle courte :

• Définir un besoin tactique (détection embarquée, priorisation de menaces, assistance au tir, navigation dégradée) ;
• Coder et intégrer des briques IA sur un espace expérimental du Mirage 2000D RMV ;
• Voler et mesurer l’apport : charge cognitive, temps de réaction, taux de détection, robustesse en bruit/brouillage ;
• Itérer rapidement avec l’ESIOC et le CEAM pour raffiner l’algorithme et le durcir.

Cette boucle permet de « dé-risquer » des fonctions qui, plus tard, seront portées sur des plateformes plus sensibles. On parle ici de maturité logicielle (TRL), de cybersécurité by design, et d’un socle commun prêt à dialoguer avec les drones de combat collaboratifs quand ils seront au rendez-vous.

Drones collaboratifs : ouverture promise, mais quel écosystème ?

La coopération avec des CCA (Collaborative Combat Aircraft) est un axe central des forces aériennes modernes. Problème : une architecture « archifermée » côté chasseur habité peut-elle réellement s’ouvrir à des drones variés, multiplateformes, voire multi-industriels ? La réponse dépend de la couche d’abstraction choisie.

Deux scénarios se dessinent :

• Écosystème propriétaire : le Rafale F5 coopère d’abord avec des drones conçus et intégrés par l’industriel du chasseur. Avantage : intégration fine, sécurité contrôlée. Risque : dépendance, inertie, innovation ralentie si l’écosystème tarde à émerger.
• Écosystème à standards ouverts (APIs, profils de mission, messages tactiques standardisés) : différents industriels peuvent proposer des « ailiers » compatibles. Avantage : agilité, concurrence, diversité. Risque : surface d’attaque élargie si la gouvernance n’est pas impeccable.

Aux États-Unis, le DoD a imposé une « architecture de référence gouvernementale » qui fixe les règles du jeu et force l’interopérabilité. En Europe, le programme FCAS/SCAF mise sur des « remote carriers » et des « combat clouds » qui devront, eux aussi, arbitrer entre ouverture et sécurité maximale. La France plaide pour une ouverture maîtrisée, où chaque composant doit prouver son innocuité avant de parler au chasseur.

Un drone de combat français ? Un enjeu, des contraintes

Éric Trappier l’a reconnu : « une petite déception : on n’a pas encore lancé de drone de combat ». Les raisons tiennent autant à la contrainte budgétaire qu’aux choix de priorisation capacitaire. Ce décalage n’empêche pas les études amont, mais il repousse l’émergence d’un compagnon de mission natif pour le Rafale F5.

Conséquences possibles :

• Fenêtre d’expérimentation élargie pour HypAIRion et les démonstrateurs « logiciels » sur Mirage 2000D ;
• Intégration progressive de drones existants (ISR, leurrage, munitions téléopérées) via des passerelles standardisées ;
• Accélération ultérieure quand le cadre d’architecture « deux vitesses » sera stabilisé et certifié.

En clair, mieux vaut rendre l’avion prêt (sécurité, interfaces, doctrine de coopération) que d’introduire trop tôt un drone non aligné avec les contraintes de sûreté. C’est une course d’endurance, pas un sprint.

Calendrier Rafale F5 : une marche d’approche prudente

Le contrat de développement du Rafale F5 doit être notifié par la DGA d’ici la fin de l’année. Une version intérimaire pourrait voler à l’horizon 2032/2033. Ce tempo peut sembler long, mais il reflète deux réalités :

• La complexité de certification d’un « cœur archifermé » sous exigences nucléaires ;
• L’intégration progressive de nouvelles fonctions collaboratives, testées en amont dans des environnements maîtrisés.

Dans l’intervalle, les armées capitaliseront sur des standards OTAN éprouvés (L16, liaisons souveraines) et des moyens connectés existants, tout en préparant le saut générationnel vers des architectures plus modulaires autour d’un noyau sanctuarisé.

Industriels et armées : changer les habitudes sans casser la sécurité

Le général Jérôme Bellanger, CEMAAE, a lancé un message net : il faut ouvrir davantage les architectures, donner accès aux données générées et permettre des mises à jour rapides à base d’IA selon les besoins opérationnels. Traduit pour l’industrie, cela signifie :

• Documenter et exposer des interfaces stables, testables et vérifiables ;
• Séparer le code critique certifié du code évolutif « mission » ;
• Partager la donnée utile (télémétrie, logs, métriques de performance) dans un cadre souverain ;
• Accélérer les cycles V&V (vérification/validation) via simulation HIL/SIL et instrumentation de vol.

Le défi est culturel autant que technique : passer d’un modèle « version majeure tous les X ans » à un rythme incrémental où les armées exploitent des « paquets fonctionnels » validés rapidement, sans diluer la robustesse du noyau.

Interopérabilité : la ligne de crête

Sur un théâtre OTAN, l’interopérabilité est non négociable. Mais interopérer ne veut pas dire s’exposer. La clé ? Des profils de mission standardisés et des passerelles certifiées qui encapsulent les échanges. On peut imaginer :

• Des catalogues d’effets partagés (leurrage, suppression de défense aérienne, ISR) pilotables via messages normalisés ;
• Des contrôleurs de mission déportés (sur avion ou sur drone) capables de redistribuer des tâches sans toucher au noyau du chasseur ;
• Des filtres de sécurité qui valident chaque message entrant avant d’autoriser une action coordonnée.

Ainsi, un Rafale F5 peut orchestrer des ailiers sans jamais leur livrer les clés de son cœur critique. La subtilité est là : coopérer, oui ; déléguer l’intégrité, jamais.

Ce que cela change pour la préparation opérationnelle

La montée en puissance des architectures mixtes impose des évolutions tangibles dans la préparation opérationnelle :

• Formation des équipages à la supervision d’effets distribués et à la gestion de modes dégradés ;
• Entraînement au brouillage dur et aux pertes de liaisons, avec scénarios d’autonomie tactique ;
• Qualification croisée des logiciels mission et procédures de reprise en main.

Dans un simulateur, le grondement sourd d’un brouillage large bande peut être presque physique. L’objectif de ces séances immersives : ancrer des réflexes où l’équipage redevient « propriétaire » de la décision quand le cloud tactique disparaît.

Export, souveraineté et attentes clients

Les clients export s’intéressent à la capacité d’évolution autant qu’à la performance brute. Une architecture « archifermée » pourrait sembler dissuasive, mais elle peut séduire si l’industriel propose :

• Un cœur certifié extrêmement sûr, facilitant l’homologation nationale ;
• Un périmètre d’extension documenté où l’utilisateur intègre ses propres charges logicielles non-critiques ;
• Des outils souverains d’analyse de données et de relecture cyber.

La souveraineté ne s’oppose pas à l’interopérabilité, elle s’oppose à la dépendance. Ici encore, le bon niveau d’abstraction — ce qui est ouvert, ce qui ne l’est pas — fera la différence.

À surveiller dans les prochains mois

Plusieurs signaux diront si la promesse d’ouverture maîtrisée devient réalité :

• Publication d’un cadre d’architecture commun pour les extensions logicielles mission (APIs, exigences cyber, V&V) ;
• Feu vert de la DGA pour un pipeline de mise à jour plus agile, assorti de « garde-fous » robustes ;
• Démonstrateurs de coopération chasseur–ailiers (même avec des drones non-spécifiquement « combat ») ;
• Retours CEAM/HypAIRion chiffrés sur la valeur ajoutée de l’IA embarquée (gain de détection, réduction de charge cognitive, temps de boucle OODA).

Questions clés à se poser aujourd’hui

• Comment garantir que la « coquille ouverte » reste étanche au cœur critique dans la durée ?
• Quelle gouvernance des données pour entraîner les IA tout en respectant les secrets opérationnels ?
• Quel standard « européen » d’architecture de référence, à l’image du modèle américain, pour éviter la jungle d’interfaces ?
• Comment planifier l’arrivée de drones de combat sans sacrifier la qualité de certification du Rafale F5 ?

Le point à retenir

Le Rafale F5 sera « archifermé » au cœur, mais pas sourd au monde. Autour de ce noyau, une zone d’innovation contrôlée devra permettre d’intégrer IA, coopérations et nouvelles charges logicielles. Le Mirage 2000D RMV, via HypAIRion, joue le rôle de catalyseur : c’est là que l’agilité se développe, avant d’être transposée, durcie, et certifiée sur le fleuron de première ligne.

En perspective : fermer pour mieux durer, ouvrir pour mieux gagner

Ce choix architectural n’est pas une régression. C’est la reconnaissance qu’un chasseur de dissuasion porte une responsabilité unique. Fermer le cœur, c’est garantir la non-subversion. Ouvrir la périphérie, c’est conserver l’initiative tactique à l’ère des essaims et des IA. Entre les deux, tout se jouera dans la discipline d’ingénierie : interfaces sobres, sandbox inviolables, tests impitoyables, et une boucle de retour d’expérience assez vive pour rester dans le tempo stratégique.

Dans une salle de briefing où clignotent encore les traces radar d’un exercice, un navigateur peut déjà comparer deux vols : avec et sans assistance IA. La différence ? Quelques secondes de décision gagnées, une alerte hiérarchisée au bon moment, un tir simulé mieux calé. Ces secondes valent cher. Demain, elles vaudront peut-être la supériorité aérienne. À une condition : ne jamais sacrifier l’intégrité du cœur. C’est précisément ce que promet l’architecture « archifermée » du Rafale F5 — et ce que l’écosystème français devra démontrer, en vol, dans la durée.

En trois points pour conclure

• Noyau sanctuarisé : le Rafale F5 garde un cœur « archifermé » pour la mission nucléaire et la cybersécurité maximale.
• Ouverture maîtrisée : une seconde architecture, périphérique, permettra d’intégrer des fonctions évolutives et la coopération CCA, sous garde-fous.
• Agilité prouvée : HypAIRion et le Mirage 2000D RMV valident rapidement les briques IA qui, demain, armeront le standard F5.

Ce que vous devez savoir, en définitive : la fermeture n’est pas l’ennemie de l’innovation. Bien pensée, elle en est la condition — surtout quand l’ultime mission ne tolère aucun aléa.