L’Agence nationale formalise sa doctrine open source au moment où le débat sur la souveraineté numérique s’intensifie en France et en Europe. Cette clarification intervient alors que certains éditeurs capitalisent sur l’image d’ouverture du logiciel libre pour positionner leurs offres comme alternatives souveraines. L’Anssi introduit un cadre technique et organisationnel précis, pour structurer les pratiques publiques.
Le débat sur la souveraineté numérique s’est intensifié à mesure que les dépendances aux fournisseurs soumis à des réglementations extraterritoriales ont été mises en lumière. Dans cette séquence, les tenants de l’open source ont saisi l’occasion pour capitaliser sur la réputation d’ouverture et de transparence de l’open source, présenté comme une garantie d’indépendance. La doctrine publiée par l’Anssi apporte une distinction essentielle entre visibilité du code, contrôle industriel et autonomie juridique.
Le document actualisé structure la stratégie autour de quatre axes. L’Agence publiera certains développements sous licences libres, contribuera à des projets existants, soutiendra l’écosystème de cybersécurité open source et privilégiera l’usage de solutions ouvertes lorsque les exigences techniques et de sécurité le permettent. Cette formalisation transforme une pratique historique en doctrine explicite.
Des choix de licences pensés pour l’usage industriel
L’ANSSI indique privilégier, selon les cas, des licences permissives telles qu’Apache 2.0. Une licence permissive autorise la réutilisation, la modification et l’intégration du code dans des produits propriétaires, sans obligation de redistribuer les modifications sous la même licence. Pour un éditeur ou une entreprise cliente, cela facilite l’intégration dans des environnements hybrides, y compris dans des logiciels internes non publiés.
À l’inverse, l’Agence peut recourir à des licences dites à réciprocité, comme la GNU GPL. Ce type de licence impose que toute redistribution d’un logiciel modifié conserve la même licence et rende public le code source correspondant. Autrement dit, un acteur qui intègre un composant sous GNU GPL dans un produit redistribué doit publier les modifications apportées. Ce mécanisme juridique empêche l’appropriation d’un code libre et garantit la pérennité de l’ouverture.
Pour les clients, la distinction est stratégique. Une licence permissive maximise la flexibilité d’intégration. Une licence à réciprocité protège l’écosystème contre la captation privée, mais peut imposer des contraintes fortes en cas de redistribution logicielle. Le choix de licence influence donc directement la gouvernance des développements internes, la politique de contribution et les risques juridiques associés.
Pour les organisations publiques et les opérateurs d’importance vitale, la maîtrise des obligations de redistribution, des clauses de responsabilité et des contraintes de compatibilité entre licences devient un élément indispensable de la gouvernance logicielle. L’ouverture ne se suffit donc pas de la publication du code, elle exige une stratégie juridique cohérente.
Audits de sécurité et certification de composants critiques
La doctrine s’appuie sur des actions concrètes déjà engagées. L’Anssi a organisé ou soutenu des audits de sécurité sur des projets open source largement déployés, notamment KeePassXC ou nftables. Ces évaluations peuvent s’inscrire dans le cadre de la Certification de sécurité de premier niveau, ce qui fournit des rapports techniques détaillant les vulnérabilités identifiées et les mesures correctives.
Pour un RSSI, ces audits publics constituent des références exploitables dans les analyses de risques. Ils permettent d’évaluer la maturité d’un composant, la qualité de la maintenance, la rapidité de correction et la robustesse de la communauté contributrice. La sécurité devient ainsi mesurable et documentée, et non supposée du seul fait de l’ouverture du code.
Contribution upstream, SBOM et maîtrise de la chaîne logicielle
L’Anssi affirme une logique de contribution dite upstream, c’est-à-dire directement vers les référentiels principaux des projets. Cette approche maximise l’impact technique et évite la dérive de versions internes non maintenues. Elle contribue également à sécuriser la chaîne d’approvisionnement logicielle en réduisant les écarts entre les correctifs publiés par la communauté et les versions effectivement déployées.
Sur le plan opérationnel, cette stratégie produit plusieurs effets mesurables. Elle réduit le délai d’application des correctifs de sécurité, limite la prolifération de forks internes non synchronisés et améliore la traçabilité des correctifs via les systèmes de gestion de versions. Elle facilite aussi l’intégration automatisée des mises à jour dans les chaînes d’intégration et de déploiement continus, avec des contrôles systématiques des dépendances, des signatures logicielles et des artefacts distribués.
Cette logique s’articule avec la mise en place d’un inventaire structuré des composants logiciels, souvent formalisé sous la forme d’une Software Bill of Materials, ou SBOM. Une SBOM recense l’ensemble des bibliothèques, modules et dépendances intégrés dans un logiciel, avec leurs versions précises. Pour un RSSI, cet inventaire permet d’identifier rapidement les composants affectés par une vulnérabilité publiée et de déclencher des mises à jour ciblées. Pour une DSI, il constitue un outil de pilotage de la conformité et de la gestion des risques liés aux dépendances tierces.
La souveraineté logicielle prend alors une dimension concrète. Elle suppose la capacité à cartographier précisément les briques utilisées, à suivre l’évolution des vulnérabilités, à intégrer les correctifs dans des cycles maîtrisés et à documenter les dépendances critiques. L’ouverture du code facilite l’audit, mais la résilience repose sur la discipline d’ingénierie, la gouvernance des dépendances et la transparence des composants intégrés.
Open source et offres hybrides du marché
La publication intervient dans un contexte où plusieurs éditeurs mettent en avant leur caractère open source pour se positionner comme alternatives souveraines. Or, nombre d’offres reposent sur des modèles hybrides combinant un noyau libre et des modules propriétaires, parfois associés à des services hébergés soumis à une juridiction étrangère.
La doctrine de l’Anssi invite implicitement à analyser la pile complète, comprenant la licence, la gouvernance du projet, la localisation des équipes de développement, la structure capitalistique et la dépendance éventuelle à des services annexes. L’ouverture du code constitue un facteur de transparence, mais la souveraineté repose sur un ensemble cohérent intégrant le juridique, l’industriel et l’opérationnel.
En clarifiant sa position, l’Anssi fournit aux DSI, aux RSSI et aux ingénieurs un cadre d’évaluation technique structuré. La souveraineté numérique ne se décrète pas par un label open source. Elle se construit par la vérifiabilité du code, la maîtrise des licences, la contribution active aux projets critiques et la gouvernance rigoureuse de la chaîne logicielle. Cette formalisation contribue à élever le débat au-delà des arguments marketing et à renforcer la cohérence des architectures publiques et privées.
