Pourquoi nous ouvrons le code d'un système de défense

Cercle Digital publie le socle d’OC2-Edge, un nœud edge de combat, sous licence Apache-2.0. Le dépôt contient le code du socle, les outils de build et de test, et la documentation d’architecture. Cet article expose le constat qui motive cette décision, la structure du marché dans laquelle elle s’inscrit, le périmètre exact de ce que nous publions et de ce que nous ne publions pas.

Le constat ukrainien

Le conflit ukrainien agit comme un filtre technique. Les rapports du Royal United Services Institute (RUSI) sur les premières phases de l’invasion documentent un environnement où les équipements sont brouillés, détruits ou capturés à un rythme qui interdit les cycles d’acquisition classiques : seuls les matériels et les logiciels capables d’itérer en semaines, de fonctionner déconnectés et de survivre à la guerre électronique restent en service [1].

Le système ukrainien Delta illustre ce filtre. Conçu et durci sous le feu, ce système de connaissance de situation a été testé en interopérabilité avec les systèmes de l’OTAN lors de l’exercice CWIX 2024, sur cinq standards et treize domaines d’essai [2]. Un logiciel de commandement et contrôle (C2) validé uniquement en salle, dépendant d’une connectivité permanente et d’un cycle de mise à jour annuel, n’aurait pas passé ce filtre.

Les doctrines alliées tirent la même conclusion. La stratégie américaine JADC2 (Joint All-Domain Command and Control) pose comme principe que le C2 doit rester opérant dans des environnements électromagnétiques dégradés et contestés [3]. C’est le cadre dit DDIL : connectivité refusée, perturbée, intermittente ou à bande passante limitée. Un nœud tactique se conçoit pour ce cadre, pas pour le réseau de garnison.

Trois exigences sortent de ce constat : itération rapide du logiciel, fonctionnement nominal en mode déconnecté, discipline d’émission. OC2-Edge est construit sur ces trois exigences.

Les trois couches du marché

Le logiciel de défense tactique se structure en trois couches.

1. La couche 1 est le socle d’exécution générique : système d’exploitation durci, démarrage vérifié, signature et isolation des modules, maillage de communication multi-porteuses, mécanisme de mise à jour, cryptographie. Cette couche est identique quel que soit le métier.
2. La couche 2 regroupe les applications métier : image tactique, coordination des feux, logistique, renseignement. Cette couche porte la valeur opérationnelle et la différenciation des industriels.
3. La couche 3 est l’intégration programme : raccordement à un programme d’armement précis, qualification, homologation d’instance, maintien en condition opérationnelle.

Les couches 2 et 3 sont le terrain naturel des industriels et des maîtrises d’œuvre : elles concentrent le savoir-faire métier et la relation contractuelle. La couche 1, elle, est aujourd’hui vacante en ouvert. Chaque acteur la reconstruit en propriétaire, avec les mêmes briques (Secure Boot, conteneurs, VPN, dépôt de mises à jour) assemblées différemment, non auditables par les autres, non fédérables entre elles.

La vacance mérite d’être précisée, car l’open source générique existe et couvre une partie du besoin : noyau Linux, orchestrateurs, hyperviseurs. Ce que l’écosystème civil ne fournit pas assemblé, c’est la combinaison des contraintes de défense : démarrage vérifié de bout en bout, signature et révocation de modules gérées hors ligne, discipline d’émission, fonctionnement nominal sans aucune infrastructure distante, cryptographie post-quantique. Chaque brique existe quelque part ; le socle assemblé, testé et documenté pour ces contraintes n’existait pas en ouvert.

OC2-Edge occupe cette couche 1 et la publie. Le projet ne concurrence pas les applications métier : il fournit le socle sur lequel elles s’exécutent, se signent et se mettent à jour.

L’ouverture comme condition de la souveraineté

La souveraineté logicielle se vérifie sur pièces, pas sur promesses. Un code fermé s’audite sous accord de confidentialité, sur un périmètre défini par l’éditeur, à une date définie par l’éditeur. Un code ouvert s’audite à tout moment, par tout acteur habilité ou non, sur l’intégralité du périmètre, y compris l’historique des modifications. La confiance cesse d’être un attribut déclaré du fournisseur pour devenir une propriété vérifiable de l’objet.

L’objection classique porte sur l’aide apportée à l’attaquant : publier le code lui donnerait la carte du système. L’objection décrit mal la situation réelle. Un attaquant étatique obtient le code d’un système fermé par d’autres voies : compromission de la chaîne de sous-traitance, exfiltration, rétro-ingénierie des binaires. La fermeture ne le prive de rien de durable ; elle prive surtout les défenseurs, les auditeurs et les alliés d’une capacité de vérification. Le projet applique la règle cryptographique exposée plus bas : rien dans le code publié ne doit affaiblir une instance, et cette propriété se vérifie précisément parce que le code est publié.

La présence d’open source dans les systèmes industriels est par ailleurs un fait acquis : l’édition 2026 de l’étude Open Source Security and Risk Analysis mesure que 98 % des bases de code commerciales auditées contiennent des composants open source [4]. Le sujet n’est plus la présence de code ouvert dans les systèmes critiques. Le sujet est sa maîtrise : provenance, version, vulnérabilités, licence. Un socle publié, avec inventaire de composants et build reproductible bit à bit, rend cette maîtrise exerçable.

L’ouverture conditionne aussi la mutualisation au sein de la base industrielle et technologique de défense (BITD). Chaque industriel qui reconstruit seul sa couche 1 paie un coût de développement, d’audit et de maintien dupliqué, pour un composant qui ne le différencie pas. Un socle commun ouvert inverse l’équation : le coût du socle se mutualise, l’effort propriétaire se concentre sur les couches 2 et 3, et deux instances issues d’industriels différents restent fédérables parce qu’elles partagent les mêmes protocoles et les mêmes formats.

Ce que nous publions

Le périmètre publié couvre trois ensembles.

1. Le socle : système d’exploitation immuable à démarrage vérifié (Secure Boot, UKI, images A/B signées), modules signés, isolés et révocables, cryptographie post-quantique (signatures ML-DSA-65 conformes à FIPS 204, KEM hybride X25519MLKEM768), maillage multi-porteuses, image tactique dans un navigateur avec tuiles hors ligne, mises à jour via dépôt TUF.
2. Les outils : environnement d’émulation x86-64 et ARM64, les 9 chaînes d’intégration continue, la suite de ~930 tests automatisés, le build reproductible bit à bit qui permet à un tiers de vérifier que les binaires publiés correspondent aux sources publiées.
3. La documentation : architecture, spécifications des principes de conception, modèle de menace, guides d’instanciation.

La licence est Apache-2.0. Elle autorise l’usage commercial, la modification et la redistribution, et inclut une concession explicite de droits de brevet par chaque contributeur [5]. C’est la licence qui permet à un industriel d’instancier le socle dans un programme sans ambiguïté juridique.

La gouvernance des contributions repose sur le Developer Certificate of Origin (DCO) : chaque commit porte une attestation signée de son auteur certifiant qu’il a le droit de soumettre ce code sous la licence du projet [6]. Ce mécanisme, léger et traçable, établit la chaîne de provenance juridique du code sans transfert de propriété intellectuelle.

Ce que nous ne publions pas

L’ouverture porte sur les mécanismes, pas sur les secrets d’emploi. Restent fermés, par conception et non par omission :

1. les clés privées : clés de signature des images et des modules, clés d’infrastructure des dépôts de mise à jour, gérées hors ligne et propres à chaque opérateur d’instance ;
2. les configurations opérationnelles : plans de fréquences, topologies de maillage déployées, paramètres d’émission, cartographies embarquées d’une instance ;
3. les données de flotte : télémétrie, journaux, positions, tout ce qu’une instance produit en service.

Cette séparation applique un principe classique de la cryptographie : la sécurité repose sur le secret des clés, pas sur l’obscurité du mécanisme. Un attaquant qui lit le code d’OC2-Edge n’y trouve aucun élément qui affaiblisse une instance déployée. Un auditeur qui lit le même code peut, lui, vérifier chaque affirmation de cette page.

Cloner, auditer, rejouer

Ce blog est l’organe de preuve du projet : chaque article renvoie à un élément vérifiable du dépôt. Pour celui-ci, l’élément de preuve est le dépôt lui-même. La démarche proposée tient en trois étapes.

1. Cloner : le dépôt public contient les sources, les tests, les chaînes CI et la documentation, sans inscription ni accord préalable.
2. Auditer : chaque lecteur choisit son angle. Un cryptographe lira l’implémentation ML-DSA-65 et le KEM hybride, un intégrateur lira les chaînes de build, un homologateur lira le modèle de menace et la correspondance entre exigences et tests.
3. Rejouer : la démonstration complète s’exécute sur émulateur x86-64 ou ARM64, sans aucun matériel spécifique. Le guide pas à pas est publié dans l’article Rejouer la démo sur émulateur.

Les écarts constatés, les faiblesses trouvées et les désaccords d’architecture se déposent en issue publique sur le dépôt. C’est le fonctionnement attendu.

Sources

1. Mykhaylo Zabrodskyi, Jack Watling, Oleksandr V. Danylyuk, Nick Reynolds (RUSI), « Preliminary Lessons in Conventional Warfighting from Russia’s Invasion of Ukraine: February-July 2022 », 2022, https://www.rusi.org/explore-our-research/publications/special-resources/preliminary-lessons-conventional-warfighting-russias-invasion-ukraine-february-july-2022
2. NATO Allied Command Transformation, « Battlefield Innovation: Ukraine’s DELTA System Paves the Way for Allied Interoperability at CWIX24 », 2024, https://www.act.nato.int/article/delta-system-cwix/
3. U.S. Department of Defense, « Summary of the Joint All-Domain Command and Control (JADC2) Strategy », 2022, https://media.defense.gov/2022/Mar/17/2002958406/-1/-1/1/SUMMARY-OF-THE-JOINT-ALL-DOMAIN-COMMAND-AND-CONTROL-STRATEGY.pdf
4. Black Duck, « Open Source Security and Risk Analysis Report (OSSRA), édition 2026 », 2026, https://www.blackduck.com/resources/analyst-reports/open-source-security-risk-analysis.html
5. Apache Software Foundation, « Apache License, Version 2.0 », 2004, https://www.apache.org/licenses/LICENSE-2.0
6. Linux Foundation, « Developer Certificate of Origin, version 1.1 », 2004, https://developercertificate.org/