L’ANSSI passe de l’ouverture à la durée avec Keysas
Le 29 avril 2026, ANSSI a annoncé le transfert à Tyrex de la maintenance de Keysas, prototype open source de « station blanche ». Vue de loin, l’information ressemble à une actualité technique parmi d’autres. Vue de près, elle déplace le centre de gravité des communs cyber publics. La question décisive n’est plus la publication initiale du code, mais l’architecture de maintenance qui permet à une ressource ouverte de durer, d’être patchée, d’être reprise et d’entrer réellement dans les usages. Cette lecture propose de traiter le cas Keysas à partir de la soutenabilité des communs numériques, c’est-à-dire de leur capacité à tenir dans le temps grâce à une articulation entre ressource, communauté et gouvernance.

Avec Keysas, la maintenance sort du hors champ
L’annonce de l’ANSSI est brève, mais elle est d’une rare précision sur l’essentiel. Keysas y est présenté comme un prototype de « station blanche », autrement dit un dispositif de décontamination de fichiers et de transfert vers des réseaux de niveau de sécurité supérieur. L’agence y explique explicitement qu’elle n’a pas pour mission première d’éditer et de maintenir des logiciels, et qu’elle transfère donc la maintenance à Tyrex afin d’en assurer la pérennité. Dans le même temps, l’agence précise que le projet reste mis à disposition de la communauté en open source, sous licence GPL-3.0, sur son dépôt public. Le portail public du projet expose en outre une documentation utilisateur et des SBOM mis à jour automatiquement, tandis que le dépôt décrit un audit de sécurité externe et l’application des correctifs sur la version courante. Le dépôt public initialement visible sur GitLab remonte au 24 juin 2022, ce qui donne une profondeur temporelle minimale à l’effort de maintenance déjà consenti avant le transfert.
Ce geste n’arrive pas hors doctrine. Le 9 février 2026, l’ANSSI a reformulé sa politique open source autour de quatre axes, publier, contribuer, structurer l’écosystème et utiliser des solutions open source. Sa page de doctrine rappelle en parallèle que l’open source est jugé essentiel pour la maîtrise des solutions numériques, la sécurisation des chaînes logicielles, la résilience des systèmes d’information et des communs numériques. La même page ajoute toutefois que les publications de l’agence sont « circonscrites à certains domaines » et que l’ANSSI n’a pas pour mission première d’éditer des logiciels pour des acteurs extérieurs. Depuis 2017, l’agence finance aussi des évaluations de sécurité de briques open source largement utilisées, ce qui révèle une posture moins centrée sur le rôle d’éditeur durable que sur celui d’acteur de sécurisation et de structuration d’écosystème.
Le choix de Tyrex n’a rien d’un prestataire indifférent. Le site de l’entreprise montre une offre déjà installée sur le segment des stations blanches et de la décontamination des supports USB, avec supervision centralisée, intégration de briques de détection partenaires et support de proximité en France. Le formulaire de contact cible explicitement, parmi d’autres, « une administration publique ». Le transfert de maintenance ne correspond donc pas à une sortie sèche hors du champ cyber public. Il ressemble plutôt à un relais vers un opérateur déjà positionné sur un marché et sur un usage voisins.
Un commun durable n’est pas seulement financé
Dans les travaux récents de Valérian Guillier et Mélanie Dulong de Rosnay autour de NGI Commons, la soutenabilité d’un commun numérique n’est pas réduite à un budget. Elle renvoie à la combinaison concrète entre financement, organisation communautaire, achats publics, contributions et règles de gouvernance. Le rapport de cartographie présenté par le consortium insiste précisément sur la diversité des « sustainability models » et sur le rôle structurant du secteur public, qui soutient les communs en contribuant, en achetant, en subventionnant ou en fournissant d’autres formes d’appui. La maintenance n’est donc pas une couche secondaire. Elle fait partie du mécanisme de pérennisation lui-même.
Un commun numérique ne tient pas par la licence seule
La première leçon théorique tient en une phrase simple. Un dépôt GPL n’est pas encore un commun. Dans leur article de référence, Felix Stalder et Mélanie Dulong de Rosnay définissent les communs numériques comme un sous-ensemble des communs où les ressources sont des données, informations, cultures et connaissances créées ou maintenues en ligne. Leur intérêt n’est pas seulement juridique. Il est aussi institutionnel. Les auteurs insistent sur le fait que ces ressources ne sont pas menacées par la surexploitation matérielle, mais peuvent l’être par le sous-approvisionnement, des cadres juridiques inadéquats, des problèmes de qualité ou de trouvabilité. Autrement dit, un commun numérique peut rester ouvert et pourtant dépérir faute de travail ordinaire, d’attention et d’organisation.
Cette idée est particulièrement opératoire pour Keysas. Le logiciel est ouvert, documenté et rendu publiquement observable. Le portail expose les branches, la documentation et les SBOM. Le dépôt décrit des composants, une architecture, une politique de sécurité. Sur le plan de la ressource, les conditions minimales du partage existent. Mais la littérature récente sur les communs numériques rappelle qu’un commun ne se résume pas à une ressource librement accessible. Les travaux de NGI Commons montrent un déplacement conceptuel important. Les définitions les plus récentes ne mettent plus l’accent sur la seule ouverture, mais sur la production, la propriété et la gouvernance distribuées, avec des règles d’accès et de partage destinées à soutenir à la fois la ressource et la communauté, et à empêcher la capture exclusive de la valeur.
Vu sous cet angle, le transfert vers Tyrex n’est ni anecdotique ni purement contractuel. C’est une décision sur la répartition des obligations de maintenance, de patching, de publication de versions, de support, de consolidation des dépendances et de relation aux réutilisateurs. L’annonce publique documente le passage de relais et maintient l’ouverture du code. En revanche, elle ne dit rien, à la date de consultation, de la durée du montage, d’une éventuelle feuille de route publique, d’une politique de support, d’une instance de gouvernance, ni de la façon dont la communauté extérieure pourrait entrer dans le cycle de décision. C’est précisément là que se loge la tension analytique. Le code reste ouvert, mais la forme sociale du commun demeure encore en construction.
Le précédent ADULLACT rappelle la nécessité d’un portage
Ce que le cas Keysas met au jour n’est pas entièrement nouveau. Le précédent historique le plus instructif, dans l’administration française, est celui de ADULLACT. Fondée en 2002, l’association se donne explicitement pour objet de constituer un patrimoine de logiciels libres utiles aux missions de service public. Son texte de présentation met l’accent sur la mutualisation des ressources et sur une intuition centrale, l’argent public ne doit pas financer plusieurs fois des développements similaires. Dès 2003, l’association crée une forge coopérative afin de soutenir, développer et maintenir un patrimoine de logiciels libres métiers dédiés au service public. Elle revendique aujourd’hui plus de 700 projets hébergés et 13 700 contributeurs sur cette infrastructure.
Le parallèle est précieux parce qu’il dissipe une illusion tenace. L’enjeu décisif n’a jamais été seulement de « publier du code ». L’ADULLACT a duré parce qu’elle a construit une fonction de portage entre la ressource logicielle et ses réutilisateurs. Cette fonction combine hébergement, outillage, animation, qualification, catalogage et reconnaissance mutuelle entre administrations et prestataires. Le Comptoir du Libre, créé fin 2016, répond exactement à cette logique en documentant les logiciels, leurs utilisateurs et leurs prestataires, donc en épaississant l’espace social qui entoure la ressource. Le commun devient alors moins un dépôt qu’un assemblage institutionnel.
Le contraste avec Keysas est ici éclairant. L’ADULLACT est une structure collective née d’un besoin de mutualisation interadministrative. Keysas reste, à ce stade, un projet de cybersécurité développé par une agence nationale, puis relayé vers une entreprise. Les formes ne sont pas les mêmes. La proximité structurelle est ailleurs. Dans les deux cas, la question critique est la même. Qui porte le logiciel après le moment initial de production, qui finance la continuité, qui administre les évolutions, qui rend la maintenance visible et réutilisable par d’autres acteurs publics ?
Le steward, celui qui tient le commun quand l’État se retire
Le rapport 2024 de RISE Research Institutes of Sweden sur la réutilisation des logiciels libres dans le secteur public conclut que les exemples les plus robustes passent souvent par des « neutral proxy organizations acting as stewards », autrement dit des organisations intermédiaires jouant le rôle de steward ou d’administrateur durable des projets. Sur le site de code.gouv, l’entretien consacré à cette étude ajoute que les OSPO, c’est-à-dire les fonctions d’appui dédiées au logiciel libre, sont précisément utiles pour mutualiser des ressources et rendre la gouvernance et la maintenance durables. Ce vocabulaire modifie la focale. La bonne question n’est plus « qui a publié le code ? », mais « qui tient le projet dans le temps ? ».
La souveraineté se joue dans l’architecture de maintenance
Le transfert de Keysas semble pouvoir être lu comme une externalisation, donc comme une perte de maîtrise. Cette lecture est trop rapide. La page de politique industrielle de l’ANSSI décrit une agence qui s’appuie explicitement sur des relais privés compétents, sur des dispositifs de transfert de technologies et sur une logique de structuration d’offre. Elle précise que l’agence entretient des liens étroits avec la recherche pour faciliter le transfert de savoir-faire vers le secteur privé et rappelle, à propos de France Relance, l’implication de 197 prestataires sur le territoire ainsi que 40 millions d’euros consacrés à l’acquisition de produits de cybersécurité français et européens, dont 33 millions pour des produits français. Dans ce cadre, la sortie de la maintenance hors de l’agence n’est pas une anomalie. C’est un geste cohérent avec une politique industrielle de relais.
La vraie question n’est donc pas l’externalisation en soi. La vraie question est le type d’externalisation. Si le transfert permet à un prototype public de passer dans un régime de maintenance industrielle compatible avec les exigences de sécurité, de support et de diffusion, alors il peut renforcer la souveraineté pratique du projet. Tyrex dispose déjà d’une offre de stations blanches, d’une solution de management et de supervision centralisée, de support de proximité en France et d’un écosystème technologique articulé à plusieurs partenaires. Sur un objet cyber, où la maintenance est une affaire de vulnérabilités, de dépendances et de réactivité, cette capacité compte davantage que la seule symbolique d’une conservation interne du code.
Encadré : l’administration sait déjà acheter de la maintenance ouverte
Le marché interministériel piloté par DGFiP couvre 350 logiciels libres, avec la possibilité d’en qualifier 80 comme critiques. Le texte du marché précise qu’il couvre tout le cycle de vie du logiciel, de l’identification à l’exploitation, et impose de reverser systématiquement aux communautés les correctifs issus de l’activité de support. En parallèle, le pôle open source et communs numériques de DINUM indique accompagner les administrations dans la publication et la mutualisation de leurs codes sources. L’État français sait donc déjà organiser une maintenance achetée sans rompre le lien avec l’écosystème ouvert. Le cas Keysas déplace cette logique de l’usage des logiciels libres vers la pérennisation d’un logiciel conçu par l’État lui-même.
C’est ici qu’apparaît l’angle mort du discours institutionnel. La souveraineté logicielle est encore souvent racontée à partir de l’origine nationale des acteurs, de l’ouverture du code ou du mot d’ordre open-by-default. Or la maintenance de long terme relève d’une autre couche de réalité. Elle suppose des responsables identifiés, une politique de sécurité, une trajectoire de versions, une capacité à financer les tâches ingrates, un espace public pour les contributions et, idéalement, une forme de steward identifiable. Ce déplacement n’est pas propre à la France. La European Commission a établi en octobre 2025 le Digital Commons EDIC précisément pour développer, maintenir et faire passer à l’échelle des communs numériques, avec support juridique et technique pour la maintenance et le changement d’échelle, avant la mise en place annoncée d’un guichet et d’un hub d’expertise d’ici 2027. L’époque ne parle plus seulement d’ouverture. Elle commence à instituer la maintenance comme objet de politique publique.
Le commun se vérifiera dans le steward, pas dans le dépôt
L’hypothèse la plus testable est la suivante. Si Keysas inaugure un modèle robuste de pérennisation des communs cyber publics, alors d’ici au 29 avril 2027 le projet affichera publiquement autre chose qu’un dépôt encore accessible. Trois indicateurs observables devraient alors apparaître. D’abord, une cadence identifiable de versions, de correctifs ou d’avis de sécurité publiés après le transfert. Ensuite, une documentation clarifiant les responsabilités de maintenance, de contribution et de support, et pas seulement l’existence du code source. Enfin, des signes d’appropriation par des tiers hors du binôme initial ANSSI et Tyrex, par exemple via la documentation, les remontées publiques, les contributions ou des intégrations visibles dans d’autres environnements. Les instruments publics existent déjà, dépôt, documentation, SBOM, et le cadre européen évolue vers des structures explicitement dédiées à la maintenance et au passage à l’échelle. La question est désormais celle de leur articulation.
Si ces indices n’apparaissent pas, l’interprétation changera nettement. Keysas restera certes un logiciel ouvert au sens juridique. Mais il ressemblera moins à un commun stabilisé qu’à un prototype public à maintenance déléguée, adossé à une relation bilatérale de service. C’est cette différence, discrète en apparence, qui donne au cas sa portée générale. Dans les SI publics, la publication du code devient progressivement une norme de maturité. La prochaine frontière de maturité portera sur la manière d’instituer le travail de maintenance, donc sur la façon dont l’État accepte de distinguer, puis d’organiser, les rôles de producteur, de mainteneur, de financeur et de steward.
Note méthodologique
Cette lecture privilégie l’angle de la maintenance plutôt que celui de la seule proclamation souverainiste, parce que c’est le point où les sources primaires sont les plus explicites. Deux ambiguïtés ont été tranchées prudemment. Le « transfert » à Tyrex est traité ici comme un transfert de maintenance, et non comme un transfert de propriété du projet, faute de précision publique sur le montage contractuel. L’antériorité publique de Keysas est fixée au 24 juin 2022, date de création du dépôt GitLab rendue visible, sans exclure un développement interne antérieur.
Sources
Sources primaires institutionnelles
- ANSSI, Open-source : L’ANSSI maintient le projet Keysas et en transfère la maintenance à la société Tyrex, 29 avril 2026,
https://cyber.gouv.fr/actualites/open-source-lanssi-maintient-le-projet-keysas-et-en-transf%C3%A8re-la-maintenance-%C3%A0-la-soci%C3%A9t%C3%A9-tyrex/. - ANSSI, L’ANSSI met à jour sa politique open source, 9 février 2026,
https://cyber.gouv.fr/actualites/lanssi-met-a-jour-sa-politique-open-source/. - ANSSI, Open-source, page thématique consultée le 6 mai 2026,
https://cyber.gouv.fr/enjeux-technologiques/open-source/. - ANSSI, Politique industrielle, page thématique consultée le 6 mai 2026,
https://cyber.gouv.fr/offre-de-service/politique-industrielle/. - Keysas, The Keysas Project, portail public consulté le 6 mai 2026,
https://keysas-fr.github.io/keysas/. - keysas-fr, keysas, dépôt GitHub consulté le 6 mai 2026,
https://github.com/keysas-fr/keysas. - r3dlight, keysas, dépôt GitLab créé le 24 juin 2022,
https://gitlab.com/r3dlight/keysas. - Tyrex Cyber, TYREX – décontamination USB, site consulté le 6 mai 2026,
https://tyrex-cyber.com/.
Écosystème public et mutualisation
- code.gouv.fr, Pôle open source et communs numériques, consulté le 6 mai 2026,
https://code.gouv.fr/fr/. - code.gouv.fr, Marchés interministériels support et expertise à l’usage des logiciels libres, 18 janvier 2022,
https://code.gouv.fr/fr/utiliser/marches-interministeriels-support-expertise-logiciels-libres/. - code.gouv.fr, Entretien avec Johan Linåker (RISE) au sujet du rapport sur la réutilisation de logiciels, 16 mai 2024,
https://code.gouv.fr/fr/blog/entretien-avec-johan-linaker-RISE-2024/. - ADULLACT, Association, consulté le 6 mai 2026,
https://adullact.org/association. - ADULLACT, Initiatives, page consultée le 6 mai 2026,
https://adullact.org/projets/initiatives.
Cadres théoriques et rapports académiques
- Mélanie Dulong de Rosnay, Felix Stalder, Digital commons, Internet Policy Review, 17 décembre 2020,
https://policyreview.info/concepts/digital-commons. - NGI Commons, Active communities of commoners and relevant commons, 26 juin 2025,
https://commons.ngi.eu/2025/06/26/active-communities-of-commoners-and-relevant-commons/. - Johan Linåker, Sachiko Muto, Software Reuse through Open Source Software in the Public Sector: A qualitative survey on Policy and Practice, RISE Report 2024:7, 2024,
https://www.diva-portal.org/smash/get/diva2%3A1848137/FULLTEXT01.pdf.
Contexte européen
- European Commission, Commission to launch Digital Commons EDIC to support sovereign European digital infrastructure and technology, 29 October 2025,
https://digital-strategy.ec.europa.eu/en/news/commission-launch-digital-commons-edic-support-sovereign-european-digital-infrastructure-and. - European Commission, European Digital Infrastructure Consortium - EDIC, page consultée le 6 mai 2026,
https://digital-strategy.ec.europa.eu/en/policies/edic. - Digital Commons EDIC, Mission, page consultée le 6 mai 2026,
https://digital-commons-edic.eu/about/.