
Des déclarations aux actes : quels chantiers pour la mise en application du rapport « dépendances numériques » ?
Le rapport de la commission d’enquête de l’Assemblée nationale sur les dépendances structurelles et les vulnérabilités systémiques dans le secteur du numérique, adopté le 8 juillet et rendu public ce 15 juillet 2026, retient l’attention à plus d’un titre. L’Open Source et les communs numériques n’y sont plus traités comme une alternative à encourager, mais comme l’infrastructure d’une politique publique de souveraineté, avec à la clé des obligations, des financements et des institutions dédiés. Entre ce que prône le rapport et sa mise en application, des actions doivent être menées tout en prenant en considération l’écosystème actuel et les enjeux qui lui sont propres. Dans ce troisième et dernier billet, sur la base des travaux que nous menons au sein d’inno³, nous proposons quelques points de vigilance et mesures à prendre pour faire de ce rapport audacieux un véritable levier de changement pour les praticiens.
Découvrez les deux premiers billets de notre série sur le rapport « dépendances numériques » :
Le rapport « dépendances numériques » marque un déplacement : la représentation nationale y cesse de considérer l’Open Source comme un sujet technique pour le traiter comme ce qu’il est, c’est-à-dire une question de souveraineté, d’économie politique et de gouvernance collective. « L’open source est désormais au cœur de la stratégie de souveraineté politique européenne », écrit la rapporteure. L’affirmation n’est plus isolée : elle s’inscrit dans une séquence (l’EDIC Digital Commons, la coalition EuroCommons, le paquet souveraineté du 3 juin) qui lui donne une consistance institutionnelle qu’elle n’avait pas il y a deux ans. Si la réception médiatique s’est d’abord concentrée sur le moratoire visant les data centers extra-européens et sur les prises de participation de l’État dans Mistral AI et ChapsVision, c’est bien le volet Open Source et communs qui constitue, à nos yeux, l’apport le plus structurant du rapport ; c’est donc lui que nous poursuivons ici. Mais adhérer au fond n’interdit pas la lucidité.
La filière économique en retrait dans les auditions
Un premier point à noter est le déséquilibre entre la représentation des acteurs associatifs et communautaires du libre et celle des organisations de la filière économique. La table ronde consacrée au logiciel libre (6 mai) n’a réuni que le versant associatif et communautaire (April, Framasoft, Mastodon, Échirolles), tandis que Signal a été entendu séparément. Les organisations qui fédèrent les éditeurs et intégrateurs (CNLL, Numeum) ne figurent pas parmi les personnes entendues, alors même qu’elles porteront l’essentiel du passage à l’échelle (le CNLL n’y est cité qu’au détour d’une étude, par un participant qui le désigne comme « nos amis »). L’asymétrie est d’autant plus notable que des voix industrielles généralistes, elles, ont bien été auditionnées (France Digitale, le Cigref, le comité stratégique de filière « solutions numériques de confiance », des éditeurs SaaS français). Le point mérite d’être relevé : en juillet 2025, Numeum adressait précisément aux pouvoirs publics un manifeste sur l’écosystème open source qui réclamait, entre autres, l’open source « par défaut » dans les marchés publics, l’une des mesures que le rapport reprend aujourd’hui à son compte. Les réserves exprimées en commission (coûts de maintenance, hétérogénéité des licences, « l’open source n’est pas la panacée ») comme la contribution du groupe RN (une valeur du code ouvert « trop souvent captée par des entreprises étrangères » faute d’opérateurs nationaux capables de déployer et de maintenir) appellent justement une réponse de filière. Le rapport l’esquisse avec un « contrat de filière » adossé à la commande publique ; des coalitions comme EuroCommons, lancée le 1er juillet par la Caisse des Dépôts pour organiser des migrations mutualisées, commencent à la structurer côté demande (notre lecture).
Plusieurs autres chantiers sont importants à considérer pour conditionner le passage de ce rapport aux actes.
Manquements : composants, SBOM et Cyber Resilience Act
Le rapport raisonne presque exclusivement au niveau macro (hyperscalers, éditeurs propriétaires, cloud, semi-conducteurs, souveraineté des données). Il laisse dans l’ombre un niveau plus fin, déterminant pour la sécurité : celui des composants et des bibliothèques open source qui forment, par empilement de dépendances, la matière première de quasiment tous les logiciels, y compris propriétaires. Ni « SBOM » (nomenclature logicielle), ni « dépendance transitive » ou « supply chain », ni « Cyber Resilience Act » ne figurent parmi les vingt-neuf propositions et dix-huit recommandations ; dans le corps du rapport, la chaîne d’approvisionnement logicielle n’apparaît d’ailleurs qu’incidemment, à propos de l’indice de résilience numérique. Cette absence est d’autant plus notable que DORA et NIS 2 sont, eux, discutés : le Cyber Resilience Act, règlement (UE) 2024/2847, est précisément le texte qui convertit l’intuition du rapport, maintenir les briques critiques, en obligations opposables : établissement d’un SBOM couvrant a minima les dépendances de premier niveau, gestion et signalement des vulnérabilités (notification dès le 11 septembre 2026, pleine application au 11 décembre 2027). Le texte fait peser une responsabilité particulière sur les opérateurs commerciaux tout en ménageant un régime spécifique aux dépositaires et contributeurs open source.
Or, en creusant dans les comptes rendus, on constate que le CRA a bien été évoqué en audition (Henri Verdier, Thierry Breton, Outscale), et l’importance des SBOM par l’Anssi. Vincent Strubel, son directeur général, le résume d’une image : « nous disposons de davantage d’informations lorsque nous achetons une saucisse, dont nous pouvons retracer l’origine jusqu’au cochon, que lorsque nous acquérons un logiciel » ; et de désigner la réponse : « une partie de la réponse viendra du règlement européen sur la cyber-résilience, le CRA, qui imposera une première forme de traçabilité avec le SBOM (Software Bill of Materials), mais il faudra évidemment étendre cette exigence à l’intelligence artificielle ». Le rapport pressent d’ailleurs le problème du côté de la maintenance : entendu par la commission, Renaud Chaput évoque « une faille […] découverte dans une bibliothèque logicielle gérée par une seule personne sur son temps libre », qui « impactait des serveurs dans le monde entier », son mainteneur n’ayant « jamais reçu un euro de financement » (p. 352). On reconnaît l’archétype, celui qu’ont illustré Heartbleed (OpenSSL, 2014) puis la porte dérobée de xz/liblzma (2024), mais la synthèse le saisit par le seul bout du financement, non par celui de la sécurité de la chaîne d’approvisionnement.
Les deux versants sont pourtant complémentaires : financer la maintenance (Sovereign Tech Fund, Flos, Logic) traite l’amont ; cartographier et sécuriser les dépendances traite l’aval. Sans nomenclature des composants, l’obligation d’open source de 2030 comme la clause d’entiercement (proposition n° 11) restent incomplètes : l’une rend visible la licence, l’autre la continuité de service, mais aucune ne donne à voir la composition réelle des logiciels acquis, c’est-à-dire leur surface d’exposition. Rendre les SBOM visibles et exigibles dans la commande publique (au format SPDX ou CycloneDX) est un complément naturel des propositions du rapport, et par ailleurs une obligation du CRA : on ne sécurise, ni ne subventionne utilement, que ce que l’on sait inventorier. C’est le terrain quotidien de nos travaux sur la transparence de la chaîne logicielle et de l’outil de conformité et de gestion de SBOM Hermine que nous codéveloppons, là où se noue concrètement l’articulation entre licences, sécurité et CRA.
L’omission est d’autant plus regrettable qu’il existe des méthodes partagées sur le sujet, telle celle conçue dans le cadre de l’étude FOSSEPS que nous avons menée pour la Commission européenne (2022) pour inventorier les composants open source critiques des services publics européens.
La sécurisation juridique de l’obligation de 2030
Exiger l’Open Source dans la commande publique est défendable en droit, et le débat n’est pas neuf. Le Conseil d’État l’a admis dès 2011 pour un marché de services portant sur une solution libre déterminée (décision Région Picardie). L’Italie est allée plus loin : sa Cour constitutionnelle a jugé dès 2010 que la préférence pour le logiciel libre ne porte pas sur une marque ou un produit mais sur une « caractéristique juridique », la licence ; et l’article 68 du Codice dell’Amministrazione Digitale réserve depuis le logiciel propriétaire aux cas d’impossibilité motivée de recourir au libre ou au réemploi. Autant de questions débattues de longue date, notamment lors des conférences EOLE consacrées aux aspects juridiques du logiciel libre dans les administrations, dont l’édition 2026 porte justement sur le thème « Open Source and Sovereignty ».
Reste la difficulté propre du rapport : une obligation générale, étendue à l’interdiction des IA propriétaires, devra composer avec le droit européen de la commande publique et l’Accord sur les marchés publics de l’OMC, et s’appuyer sur une définition stable, alors que le CRA raisonne déjà en activité commerciale, le RIA en licence et la NPLD en gratuité. La demande d’une définition européenne commune, formulée par Philippe Latombe en commission, mérite d’être entendue, à condition de ne pas rouvrir ce que quarante ans de pratique ont stabilisé.
L’échelle des moyens
Le rapport fournit lui-même le contraste :
- 109 milliards d’euros d’investissements privés annoncés au sommet de l’IA (dont l’essentiel fléché vers les data centers), 15 GW de capacité électrique réservée (24 % de la puissance du parc nucléaire) captée en très large majorité par des acteurs extra-européens ou des fonds.
- En face : 25 millions d’euros pour le Sovereign Tech Fund allemand, « quelques millions » pour l’EDIC.
Un rapport de 1 à 1 000 entre la politique d’attractivité des infrastructures et la politique des communs.
Le fonds Logic et le STF européen changeront la donne s’ils sont dotés à la hauteur de la criticité désormais reconnue : c’est le critère sur lequel se jugeront les suites, à commencer par les amendements annoncés dès l’examen du projet de loi relatif à la résilience des infrastructures critiques et à la cybersécurité, attendu en séance le 21 septembre, puis par le PLF 2027 que le président de la commission désigne comme véhicule budgétaire. Miser sur ces instruments reste toutefois un pari, d’autant que les vingt-neuf propositions n’engagent formellement que la rapporteure : dans un contexte politique instable et à l’approche de l’échéance présidentielle de 2027, l’inscription budgétaire de ces financements est tout sauf acquise. Le gouvernement, de son côté, revendique un gradualisme déjà engagé (doctrine des achats publics numériques de février 2026, feuille de route de la Dinum, préfiguration de l’Ariane) : « la désintoxication est urgente, et elle a commencé », reconnaissait en audition le ministre David Amiel, tout en prévenant que « ceux qui promettent une sortie immédiate, totale et indolore des dépendances racontent des histoires ». Ce constat renforce une conviction que nous portons de longue date : la réponse ne peut être seulement politique. Elle suppose d’associer durablement acteurs publics et privés (éditeurs, intégrateurs, collectivités, fondations), pour que la trajectoire ne dépende ni d’une seule majorité ni d’un seul budget.
Par ailleurs, ces financements restent fragiles, comme l’a montré le précédent du programme européen Next Generation Internet (NGI), dont le non-renouvellement dans Horizon Europe en 2024 avait ému tout l’écosystème : une politique de communs adossée à un seul guichet reste réversible.
La gouvernance réelle des communs : le rôle de la communauté
Reste le plus difficile, que quarante ans d’écosystème enseignent : une ressource ouverte ne vaut que par la communauté qui la porte et la gouvernance qui la protège. Les institutions proposées (Flos, Logic, syndicats de données) offrent un cadre ; leur portée dépendra de la capacité de l’écosystème, collectivités, éditeurs, communautés et chercheurs, à s’en saisir. Une fondation et un fonds ne font pas une communauté : on ne décrète pas un commun, on le fait vivre. La tension, documentée par le rapport lui-même, entre La Suite numérique et les éditeurs français lauréats de France 2030 rappelle que la frontière est fine entre « l’État contributeur aux communs » et « l’État producteur centralisé ». Henri Verdier répond utilement que soutenir un éditeur de logiciel libre pour qu’il améliore son produit est une option de politique publique à part entière. La Flos ne tiendra ses promesses que si sa gouvernance donne une place effective à la filière et aux communautés, et non un strapontin.
Auteur/Autrice

Benjamin JEAN
Ressources associées
Évènement
Un 1er juillet sous le signe des communs et de la souveraineté
Article
Les défis et opportunités du CRA pour les communautés Open Source
Article
Open Source et IA : trois règlements européens, trois logiques, un même écosystème
Article
