Le logiciel au coeur de la souveraineté défense : pourquoi l'agilité industrielle devient une exigence stratégique

La guerre en Ukraine a fourni une démonstration inattendue : un pays qui met à jour le logiciel de ses drones en quarante-huit heures gagne un avantage tactique que dix années de R&D matérielle ne peuvent pas compenser (voir le panorama de la révolution des drones depuis 2022). Ce que les théoriciens de la guerre network-centric décrivaient depuis les années 2000 s'est matérialisé dans des friches industrielles reconverties en ateliers de soudure et des groupes Telegram devenus canaux de retour terrain.

La leçon n'est pas anecdotique. Elle touche à ce que signifie "souveraineté défense" en 2026. La capacité à développer, déployer et mettre à jour du logiciel de combat à rythme opérationnel est devenue une dimension de puissance au même titre que la capacité industrielle à produire des munitions.

Pour les acteurs du numérique civil qui travaillent avec la BITD ou souhaitent s'y positionner, cela change plusieurs choses fondamentales.

Quand le logiciel est devenu l'arme

Les systèmes d'armes modernes sont majoritairement des systèmes informatiques avec des effets cinétiques. Un char de combat contemporain embarque plusieurs millions de lignes de code. Un système de défense antiaérienne repose sur des algorithmes de fusion de données et de classification des menaces. Un drone de renseignement n'est efficace que si son traitement d'image est à jour par rapport aux nouvelles tactiques de camouflage adverses.

Ce n'est pas nouveau en théorie. Ce qui est nouveau, c'est le rythme auquel les mises à jour logicielles ont une valeur tactique directe. Dans le conflit ukrainien, des bataillons de drones FPV ont modifié leurs schémas de vol et leurs protocoles d'interférence radio en réponse à des contre-mesures adverses déployées en quelques jours. Les cycles de mise à jour qui fonctionnaient sur des trimestres sont devenus des cycles hebdomadaires.

Ce rythme est structurellement incompatible avec les processus de validation et d'homologation traditionnels de la défense. Et c'est là que commence le vrai problème industriel.

Les contraintes spécifiques du delivery en contexte défense

Sécurité et cloisonnement

Le premier écart entre le delivery numérique civil et le delivery défense tient à la surface d'attaque. Dans un contexte de sécurité nationale, chaque composant logiciel est un vecteur d'attaque potentiel. Les dépendances open-source, courantes dans le développement civil, deviennent des risques de supply chain. Les pipelines CI/CD connectés à des dépôts publics sont incompatibles avec les exigences de cloisonnement.

Cela n'interdit pas les méthodes agiles. Cela exige de les adapter : environnements air-gappés, audits de code systématiques, gestion des dépendances sur des miroirs internes, traçabilité totale des modifications. Le delivery management dans ce contexte n'est pas plus lent, mais il est différemment outillé.

Cycles longs vs. urgence opérationnelle

La défense française fonctionne sur des programmes d'armement dont les cycles vont de dix à trente ans. Le PA2, le char Leclerc Evolution, le SCAF : des projets dont les spécifications initiales datent d'une époque où les menaces actuelles n'existaient pas sous leur forme courante.

La tension entre ces cycles longs et la nécessité d'une réactivité logicielle rapide produit ce qu'on pourrait appeler une dette de cadrage institutionnelle : des contrats signés avant que les besoins opérationnels réels soient stabilisés, avec des processus de modification contractuelle qui prennent plus de temps que le cycle de vie de la menace qu'ils cherchent à adresser.

J'ai exploré la mécanique de cette dette de cadrage dans mon article sur les deux premières semaines de projet. Dans le contexte défense, les enjeux sont simplement décuplés : une hypothèse non formulée dans un programme d'armement peut coûter des centaines de millions d'euros et une dizaine d'années de retard.

Interopérabilité avec des systèmes hérités

Les armées françaises et européennes opèrent avec des systèmes dont les architectures logicielles s'étendent sur plusieurs décennies. L'interopérabilité entre ces systèmes hérités et les nouvelles capacités logicielles est souvent plus complexe que le développement de la nouvelle capacité elle-même.

C'est le problème de la dette technique dans les systèmes critiques : la traçabilité n'est pas optionnelle, les interfaces ne peuvent pas être cassées, et chaque modification doit être validée dans un contexte d'utilisation opérationnel que le développeur civil ne maîtrise pas toujours.

Ce que le conflit ukrainien a changé dans l'approche

Trois observations concrètes issues du terrain ukrainien ont modifié la réflexion des industriels de la défense européens.

L'attrition logicielle existe. Quand un système est détruit au combat, le logiciel disparaît avec lui. La capacité à redéployer rapidement, sur d'autres plateformes ou des équipements de remplacement, suppose une architecture portable et documentée. Les monolithes propriétaires liés à un hardware spécifique deviennent des vulnérabilités.

La boucle décision-action s'est compressée. Les cycles OODA (Observer, Orienter, Décider, Agir) qui duraient des heures dans les doctrines classiques se jouent désormais en minutes sur certains segments tactiques. Cela suppose des systèmes capables d'intégrer et de traiter des données de façon autonome, avec des mises à jour de leurs modèles qui suivent l'évolution du terrain.

Les acteurs non-BITD sont devenus stratégiques. SpaceX (Starlink), Palantir, Microsoft, Amazon Web Services : des entreprises sans tradition défense ont fourni des capacités critiques que les industriels traditionnels ne pouvaient pas déployer à ce rythme. Ce précédent redéfinit qui peut être un acteur de souveraineté défense.

Agilité et défense : une tension réelle

L'agilité au sens méthodologique du terme (Scrum, Kanban, delivery continu) est incompatible dans sa forme pure avec les processus de qualification et d'homologation défense. Ce n'est pas une question de résistance culturelle : c'est une question de responsabilité. Un logiciel embarqué dans un système d'armes engage des vies. Les processus de validation qui semblent lents depuis l'extérieur ont une logique sécuritaire réelle.

Ce que l'agilité peut apporter, ce n'est pas la suppression de ces processus. C'est leur restructuration. Des sprints courts sur des composants non-critiques, des boucles de retour terrain documentées, une architecture modulaire qui permet de mettre à jour des sous-systèmes sans revalider l'ensemble : ce sont des gains réels, compatibles avec les contraintes du secteur.

L'enjeu pour les acteurs du numérique civil qui entrent sur ce marché est de comprendre que le dual-use, dont j'ai exploré les enjeux dans mon article sur l'innovation civile comme actif de souveraineté, ne signifie pas copier-coller des pratiques d'une industrie à l'autre. Cela signifie adapter les méthodes aux contraintes de chaque contexte.

Ce que ça change pour les acteurs privés du numérique

Pour une agence, un éditeur logiciel ou un cabinet de conseil numérique qui envisage de travailler avec la BITD française, les implications sont concrètes.

Les certifications comptent. SecNumCloud pour l'hébergement, les qualifications ANSSI pour certains types de produits, et les habilitations personnelles pour les équipes travaillant sur des projets classifiés : ce sont des prérequis, pas des options. Les délais d'obtention se comptent en mois.

La traçabilité n'est pas négociable. Chaque modification, chaque déploiement, chaque décision d'architecture doit être documentée de façon à pouvoir être auditée. Les pratiques de delivery qui fonctionnent sur "convention over configuration" dans le civil deviennent des risques de conformité dans le contexte défense.

Les cycles sont différents. Une relation commerciale avec un industriel de la défense s'inscrit souvent dans des horizons de trois à cinq ans minimum. La capacité à construire une expertise sectorielle, à maintenir une relation dans la durée et à absorber les délais de décision institutionnels est aussi importante que la compétence technique.

La stratégie industrielle de défense européenne (EDIS) et la montée en puissance du Fonds européen de défense ouvrent des opportunités réelles pour les PME numériques. Mais elles supposent de comprendre que l'entrée dans ce secteur est un projet en soi, avec ses propres délais de cadrage.