Le 7 octobre 2026, la loi pour une République numérique a eu dix ans. Son article 16 dispose que les administrations « encouragent » l'utilisation des logiciels libres et des formats ouverts. Le verbe employé avait fait débat : en 2016, l'April, le CNLL et des parlementaires de tous bords réclamaient une « priorité », que la ministre et le Législateur n'ont pas retenue. Dix ans plus tard, le bilan est maigre. Les administrations achètent chaque année pour environ 1,5 milliard d'euros de logiciels à des fournisseurs extra-européens, dont au moins un milliard pour des logiciels qui ont déjà un équivalent libre. Aucune administration de l'État n'a fait massivement passer ses postes de travail sous un système libre depuis la Gendarmerie, qui avait achevé sa migration en 2014, avant même la loi (Cour des comptes, 2025).

Ce constat vient de la commission d'enquête de l'Assemblée nationale sur les dépendances structurelles du secteur numérique, présidée par Philippe Latombe (MoDem), avec Cyrielle Chatelain (Écologiste) pour rapporteure. Son rapport, adopté le 8 juillet 2026, propose notamment de renforcer l'article 16 « en passant d'une logique d'encouragement à une logique contraignante ». Reste à savoir comment. Le CNLL y répond dans une proposition qui détaille aussi ce qui peut être engagé d'ici mai 2027.

La règle proposée, que le gouvernement peut poser dès maintenant sans attendre une modification de la loi : quand une administration de l'État achète un logiciel, elle retient un logiciel libre, sauf justification écrite, publiée et examinée par l'autorité numérique de l'État. Deux mécanismes doivent empêcher cette règle de rester lettre morte. D'abord, la justification doit chiffrer le coût sur toute la durée du contrat (TCO ou coût total de possession), y compris celui d'un futur changement de fournisseur (coût de sortie). Ensuite, cette justification est examinée par ARIANE, l'autorité qui remplacera la DINUM (direction interministérielle du numérique) le 1er janvier 2027. Comme la règle ne vise que les nouveaux marchés et les renouvellements, le gouvernement fixe aussi une trajectoire pour le parc existant : les dépenses de licences propriétaires qui ont un équivalent libre (le milliard d'euros annuel cité plus haut) doivent être divisées par deux d'ici 2031 et ramenées à zéro en 2035.

Sommaire

• Pourquoi l'encouragement n'a pas suffi
• La proposition du CNLL
• L'appui d'un papier franco-allemand peu connu
• Le droit et les précédents étrangers
• Quatre mesures d'ici mai 2027

Pourquoi l'encouragement n'a pas suffi

Remplacer « encourager » par « donner la priorité » ne suffirait pas sans contrôle : deux priorités écrites existent déjà, toutes deux contournées. Le ministère de la Défense s'en était donné une par directive dès 2006. Il a pourtant signé en 2009, sans appel d'offres, le contrat « open bar » avec Microsoft, reconduit en 2026. Dans l'enseignement supérieur, la loi de 2013 dispose que « les logiciels libres sont utilisés en priorité ». Il a tout de même fallu une procédure du CNLL pour que l'École polytechnique suspende, en 2025, sa migration vers Microsoft 365. Dans les deux cas, l'acheteur a décidé seul : aucune autorité extérieure ne lui demandait de justifier son choix. La dépense, elle, continue de croître : rien que par l'UGAP (la centrale d'achat public), les achats de produits Microsoft sont passés de 233 à 293 millions d'euros entre 2024 et 2025, selon la commission d'enquête.

La proposition du CNLL

• La règle. L'article 16 demande déjà aux administrations de préserver « la maîtrise, la pérennité et l'indépendance » de leurs systèmes d'information. Dans cet esprit, le gouvernement pose une règle d'achat : les administrations de l'État retiennent les logiciels libres et les formats ouverts, sauf justification écrite. Une circulaire du Premier ministre et les textes qui créent ARIANE suffisent pour cela. La règle s'applique à tout nouveau marché et à tout renouvellement. Son extension aux opérateurs de l'État, aux entreprises publiques et aux concessionnaires de service public (que propose la commission d'enquête), puis aux grandes collectivités, demandera une loi, qui pourra aussi renforcer l'article 16 lui-même.
• Les exceptions justifiées. L'acheteur qui écarte le libre indique les solutions libres qu'il a examinées et chiffre le coût sur toute la durée du contrat, sortie comprise. Il évalue aussi l'offre qu'il retient selon trois critères tirés du papier franco-allemand présenté plus bas : la possibilité de changer de fournisseur, la part de la valeur créée dans l'Union, la maîtrise de la technologie. Il joint un plan de sortie, qui dit comment l'administration pourra changer de solution à l'échéance ou en cas de coupure du service.
• Le contrôle. La justification est examinée par ARIANE avant la signature du marché ou de sa reconduction. La DINUM, à laquelle elle succède, rend déjà un avis conforme (que l'administration est tenue de suivre) sur les grands projets informatiques de l'État. Depuis le décret du 18 mars 2026, cet avis vérifie le respect de l'article 16 et couvre aussi les suites collaboratives de plus de 2 millions d'euros par an. Le mécanisme existe ; il suffit de l'étendre aux achats de logiciels. Au-dessus de 2 millions d'euros, l'avis d'ARIANE est lui aussi conforme. Pour les marchés plus petits qui dépassent les seuils européens (ceux qui imposent une procédure formalisée), l'avis est consultatif et publié. Sous ces seuils, la justification est publiée et contrôlée par sondage.
• La transparence. Les justifications sont publiées dans un registre ouvert. Chaque année, une annexe au budget mesure, ministère par ministère, la part du libre dans la dépense informatique et l'écart à la trajectoire de 2035.
• Les moyens. Examiner des justifications et conseiller des acheteurs demande du personnel. La mission logiciels libres de la DINUM n'a jamais compté plus de trois équivalents temps plein. ARIANE se dote donc d'un bureau du logiciel libre (un OSPO, pour « Open Source Programme Office »), en réseau avec celui de la Commission européenne et ceux des autres États membres. Ce bureau privilégie les logiciels libres existants et travaille avec les éditeurs et les mainteneurs qui les développent. Dans les grands marchés de support sur logiciels libres, l'État contracte directement avec l'éditeur ou le mainteneur de chaque logiciel, pour qu'une part de la dépense revienne à ceux qui le font vivre. Un fonds finance enfin la maintenance des logiciels libres dont l'État dépend.

L'appui d'un papier franco-allemand peu connu

Le 17 juin 2026, la France et l'Allemagne ont publié un papier conjoint sur la souveraineté numérique pour orienter les travaux législatifs européens. Les deux gouvernements y écrivent qu'il faut « éviter l'enfermement propriétaire ». Ils veulent des systèmes conçus pour permettre « de changer de fournisseur et de technologie dans un délai raisonnable et sans dépenses excessives ». Le texte ajoute : « Des solutions open source peuvent et devraient jouer un rôle important à cet égard. » Le gouvernement français a donc déjà souscrit à ces objectifs ; il lui reste à les appliquer à ses propres achats.

Le droit et les précédents étrangers

Sur le plan juridique, le Conseil d'État a jugé en 2011 que désigner un logiciel libre dans un marché ne favorise aucun opérateur, puisque toute entreprise peut l'adapter et le maintenir. En mars 2026, le service scientifique du Bundestag a conclu, dans un avis qu'un acheteur peut réserver un marché à l'open source si cette restriction est justifiée, proportionnée et motivée par écrit. L'avis concerne le droit allemand, mais celui-ci transpose les mêmes directives européennes sur les marchés publics que le droit français. La règle proposée remplit ces conditions : elle est justifiée par l'objet du marché (pouvoir changer de fournisseur), proportionnée (elle admet des exceptions) et motivée par écrit à chaque décision.

Dans les faits, l'Allemagne a pris de l'avance. La Thuringe inscrit une priorité au libre dans sa loi depuis 2020 ; au niveau fédéral, la loi sur l'administration électronique (EGovG) demande depuis 2024 de privilégier l'open source pour tout nouveau logiciel. Le Schleswig-Holstein, où le gouvernement du Land conduit lui-même la migration, montre qu'elle fonctionne. Sa messagerie est entièrement passée au libre en octobre 2025 ; près de 80 % des postes de son administration utilisaient LibreOffice en décembre 2025. En septembre 2026, la chancellerie du Land a fait passer ses postes de travail sous Linux.

L'Italie montre à l'inverse ce que devient une règle sans contrôle. Depuis 2012, son code de l'administration numérique oblige chaque administration à comparer les solutions avant d'acheter un logiciel, en examinant d'abord la réutilisation d'un logiciel public existant puis le logiciel libre. L'administration ne peut acheter une licence propriétaire que si aucune de ces options ne convient. Mais c'est l'acheteur qui mène la comparaison ; aucune autorité ne la relit. En 2020, la Cour des comptes italienne constatait que 16,7 % seulement des logiciels en usage dans les collectivités relevaient des options que le code déclare prioritaires. C'est ce contrôle extérieur, absent en Italie comme en France, que la proposition confie à ARIANE.

Quatre mesures d'ici mai 2027

Ces mesures relèvent de l'initiative du gouvernement et peuvent être engagées tout de suite.

1. Inscrire dans les textes qui créeront ARIANE au 1er janvier 2027 (ils ne sont pas encore parus) l'examen des justifications, le registre public et le bureau du logiciel libre.
2. Exiger dès maintenant, par une circulaire du Premier ministre, une justification écrite et publiée pour tout achat de logiciel propriétaire par l'État.
3. Créer, dans le budget pour 2027, l'annexe qui mesure la part du libre par ministère ; doter le fonds de maintenance, que la commission d'enquête propose elle aussi.
4. Défendre la même règle au Conseil de l'Union, qui prépare sa position sur le règlement européen sur le développement du cloud et de l'IA (Cloud and AI Development Act) : son article 41, dans sa rédaction actuelle qui peut encore être amendée par le Conseil et le Parlement, se contente lui aussi d'« encourager ».

Le texte complet de la proposition, avec ses références, est disponible sur le site du CNLL.

Libera Suite est une « nouvelle » suite bureautique libre pour Linux, Windows et macOS. Elle comprend actuellement un traitement de texte, un tableur, un logiciel de présentation et une visionneuse de fichiers Visio. Elle fonctionne sur votre ordinateur, sans compte, sans service en ligne et sans télémétrie. Elle sait ouvrir et enregistrer les formats de Microsoft Office et OpenDocument. Comparées à d’autres applications similaires, elle est relativement rapide à démarrer et légère.

Elle est bâtie sur les composants d’Euro-Office, le fork d’ONLYOFFICE lancé en avril par une coalition d’entreprises européennes, dont Abilian (société de l’auteur de cette dépêche), qui développe Libera Suite. Elle est en bêta publique depuis le 1ᵉʳ octobre.

Quatre applications

Une seule commande, libera, ouvre chaque document dans l’application qui lui correspond :

• Libera Words, le traitement de texte : .docx, .odt, .rtf, .txt, .md ;
• Libera Tables, le tableur : .xlsx, .ods, .csv ;
• Libera Slides, les présentations : .pptx, .odp ;
• Libera Diagrams, la visionneuse de fichiers Visio : .vsdx.

Les quatre applications partagent des fonctions comme l’export PDF, l’impression, la correction orthographique en cinq langues et la récupération du travail après un plantage.

Addition pratique: la commande libera --convert permet de convertir entre les différents formats pris en charge, ou d’exporter vers PDF. Par exemple, libera --convert *.docx -t pdf convertit un lot de documents vers PDF sans ouvrir de fenêtre. Son ergonomie est inspirée de Pandoc.

Comment l’installer

• Linux (Ubuntu 22.04, Debian 12, Fedora 36, RHEL 9 et plus récents, x86_64 et arm64) : curl -fsSL https://cdn.abilian.com/libera/install.sh | sh. Si Flatpak est présent, le script installe un paquet Flatpak qui contient tout ; sinon, il installe la commande libera.
• macOS (Apple Silicon) : brew install abilian/tap/libera, ou le même script. Homebrew fonctionne aussi sous Linux (à condition évidemment de l’avoir installé).
• Windows 10 et 11 : un installateur, sans droits d’administration.

Pour les utilisateurs et les utilisatrices de Python, Libera Suite est aussi publiée sur PyPI. Sous macOS et Windows, uvx libera suffit : au premier lancement, la commande propose de télécharger les composants d’Euro-Office. Sous Linux, un environnement Python isolé ne voit pas les liaisons GTK de la distribution : il faut passer par pipx install --python /usr/bin/python3 --system-site-packages libera.

La page d’installation de la doc donne le détail des principales méthodes d’installation ; la page autres façons d’installer couvre le reste.

Architecture

Euro-Office fournit ses outils d’édition sous forme de composants Web, écrits en JavaScript. Ces composants s’exécutent dans un moteur de navigateur et confient les conversions de fichiers, l’accès au disque et les autres aspects de l’intégration au système d’exploitation et à l’environnement graphique hôte (menus, boîtes de dialogue…) à l’application qui les héberge. Libera Suite est cette application hôte, écrite en Python. Elle affiche les composants dans le moteur de rendu web fourni par le système (WebKit sous Linux et macOS, WebView2 sous Windows) et confie les conversions de formats (y compris l’import/export de fichiers) au convertisseur d’Euro-Office.

Près de 700 tests automatisés vérifient son fonctionnement. Une partie d’entre eux ouvre de vrais documents dans ces composants et contrôle le résultat affiché.

Nous compilons nous-mêmes les composants d’Euro-Office, depuis ses sources, pour Linux, macOS et Windows. Les correctifs nécessaires sont tous publiés et expliqués. Nous avons aussi corrigé (à ce jour) 68 défauts du convertisseur dans la lecture et l’écriture des fichiers OpenDocument, repérés grâce aux fichiers de test de LibreOffice.

L’application hôte est sous licence Apache 2.0. Les composants issus d’Euro-Office / ONLYOFFICE restent sous licence AGPL 3.0.

Réseau

Libera Suite se connecte pour télécharger les composants d’Euro-Office à l’installation. Une fois par jour au plus, elle vérifie aussi si une nouvelle version existe, sans rien télécharger ; la ligne check_updates = false du fichier de configuration désactive cette vérification.

Les limites de la bêta

L’interface est en anglais. Chaque document a sa propre fenêtre, sans onglets. Microsoft Office ne voit pas les verrous de Libera Suite. L’application Diagrams est en lecture seule. Ni l’édition des PDF ni le publipostage ne sont encore disponibles. L’installateur Windows et l’application macOS ne sont pas encore signées. La page État des lieux en donne la liste complète.

Vos retours

Nous cherchons des testeurs. Le moteur de mise en page est relativement éprouvé (plus pour les formats MS-Office que pour ODF, mais on y travaille). La cause des bugs éventuels se trouve le plus probablement dans notre processus de build, de paquetage et de distribution, dans l’absence d’une police ou d’une ressource. Ces défauts se corrigent vite, à condition de les voir. Le retour le plus utile est donc un document qui s’affiche mal, joint à un ticket avec la sortie de libera --diagnose.

Le Frido est un livre libre (licence FDL) de mathématique qui reprend l’ensemble de la mathématique depuis la construction des entiers jusqu’à tout ce qu’on peut placer à l’agrégation : probabilités, distributions, anneaux, groupes, géométrique, etc.

Sommaire

• Tout en un
• Nouveautés 2026
  • Cauchy-Lipschitz analytique
  • Groupe symétrique
  • Problèmes d’ordre
  • Partition de l’unité
  • Neutralité en moyenne
  • Indépendance de variables aléatoires
  • Algèbre
  • LaTeX et encodage
  • luatex
  • Passage à 5 volumes
• Laurent est un pédant
• L’Humanité

Tout en un

Une particularité du Frido est d’être «tout en un». Un seul livre (PDF de 3000 pages) qui contient toutes les matières : algèbres, analyse, probabilités, etc.

L’intérêt est de pouvoir citer les théorèmes d’algèbre linéaire utilisé en analyse, de mesure utilisée en probabilité, etc.

Un enchaînement particulièrement long et interdisciplinaire est la chose suivante.

1. Définir une rotation comme composée de deux symétries axiales.
2. Définir les fonctions trigonométriques par leurs séries.
3. Définir les applications linéaires et leurs matrices associées.

À partir de là, montrer que la matrice d’une rotation a la forme qu’elle a avec ses fonctions trigonométriques.

Nouveautés 2026

Cauchy-Lipschitz analytique

Le gros morceau de cette année est le théorème Cauchy-Lipschitz analytique en passant par Cauchy-Lipschitz holomorphe. Je suis convaincu qu’on peut faire sans passer par les fonctions holomorphes. En cherchant le label THOooZEBOooQJOSQj dans le PDF, vous trouverez une démonstration quasiment complète sans passer par les fonctions holomorphes. À mon avis le bout qu’il manque est juste un peu de combinatoire qui m’échappe. Si vous connaissez des choses à ce propos, n’hésitez pas à répondre à l’une ou l’autre de ces questions qui sont (je crois) équivalentes :

https://math.stackexchange.com/questions/5111835/analytic-map-on-the-banach-x-times-y
https://math.stackexchange.com/questions/5113042/analytic-picard-lindel%C3%B6f-theorem

Note : j’ai déjà demandé à de l’IA sans succès (mais c’était il y a quelque mois). Je n’ai rien contre une démonstration générée par IA, mais comme je l’explique ici, j’ai quelque chose contre « j’ai demandé à l’IA et voici le résultat ». Si vous me proposez une démonstration par IA, soyez sûrs de la comprendre d’un bout à l’autre dans tous les détails. Sinon, ça ne me sert à rien. Quand les IA font des fautes, c’est toujours subtil — et on ne les découvre que via une lecture très attentive de chaque ligne.

Groupe symétrique

Démonstration de la décomposition en cycles des éléments du groupe symétrique.

Problèmes d’ordre

L’ordre des chapitres dans le Frido est l’ordre logique mathématique, et non l’ordre pédagogique. Les théorèmes se démontrent uniquement avec des théorèmes démontrés plus haut. Du point de vue de , les \ref pointent toujours vers des \label plus haut. C’est une grosse contrainte.

Quelques exemples de dépendances qui m’ont fait déplacer des parties cette année ?

En théorie des groupes, la formule des classes demande les rationnels, les rationnels sont le corps des fractions, donc demande les anneaux.

Le symbole de sommation demande de savoir la décomposition en cycles des permutations (groupe symétrique) pour montrer que la somme ne change pas si on change l’ordre de sommation; la décomposition en cycles demande le théorème de Lagrange qui demande les rationnels et donc les anneaux. Les anneaux demandent le symbole de sommation pour écrire le terme général d’un idéal engendré par une partie.

Il faut donc découper la partie sur les anneaux en plusieurs parties. Quant au symbole de sommation, sa définition est découpée en plusieurs parties en fonction du niveau de généralité.

Tout cela pour dire que le Frido n’est pas arrangé par ordre pédagogique et encore moins par ordre de difficulté. Le principal déterminant à l’ordre et au découpage des chapitres est l’impossibilité de faire des références vers le bas.

Avant 2026, j’étais parvenu à mettre la construction des entiers, rationnels et réels dans le même chapitre avec seulement ce qu’il fallait d’anneaux pour dire que les rationnels sont le corps des fractions des entiers. Maintenant que je me suis rendu compte des boucles de dépendances dont je parle plus haut (parce que j’ai démontré la décomposition en cycles), j’ai décomposé en plus de chapitres.

• entiers relatifs (les naturels sont admis)
• groupes
• anneaux
• rationnels et réels

Partition de l’unité

Il y avait trop d’énoncés différents sans démonstration. Il reste maintenant deux théorèmes : un qui donne une partition de l’unité subordonnée à des ouverts et un autre spécifique dans le cas des compacts. Le deuxième est démontré; la démonstration du premier est dans mon interminable liste de choses à faire.

Neutralité en moyenne

Lorsque je dois écrire «La personne qui lit doit rester attentive», j’écris

\randomGender{Le lecteur}{La lectrice} doit rester \randomGender{attentif}{attentive}. 

avec la macro :

\newcounter{rndgendercont}
\newcommand{\randomGender}[2]{%
    \setcounter{rndgendercont}{%
        \numexpr\value{chapter}+\value{numtho}\relax%
    }%
    \ifthenelse{\isodd{\value{rndgendercont}}}{#1}{#2}%
}

En gros, ça donne masculin ou féminin au hasard. Plus précisément, ça donnera masculin si la somme entre le numéro du chapitre et le numéro du dernier théorème énoncé est pair et féminin si impair.

La nouveauté 2026 est de faire « chapitre+théorème ». Avant, je faisais « numéro de page+théorème », et j’ai eu des problèmes avec une phrase qui passait d’une page à une autre—et donc une incohérence entre deux appels à randomGender.

Indépendance de variables aléatoires

Définition de l’indépendance d’une famille quelconque d’évènements. Définition d’un -système et lien avec l’indépendance de tribus.

Algèbre

… rien cette année. Étonnamment, cette année, aucun énoncé supplémentaire de la forme «Dans un anneau XXXX, tout élément/idéal YYYY est ZZZZ» n’a été démontré.

Pourtant je suis certain qu’il y en a encore plein qui manquent.

LaTeX et encodage

On a discuté de l’encodage des accents dans les URL.

L’objectif aurait été de faire fonctionner une macro \myurl permettant d’écrire

\myurl{https://fr.wikipedia.org/wiki/Idéal_premier}


Et franchement, ça n’a pas été un succès.

J’ai déjà fait des choses comme

\documentclass[a4paper,11pt]{book}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{hyperref}
\usepackage{xstring}

% Encode certains caractères UTF-8 pour l’URL
\newcommand{\MakeUTFPerCent}[1]{%
  \def\result{#1}%
  \StrSubstitute{\result}{é}{\%C3\%A9}[\result]%
  \StrSubstitute{\result}{à}{\%C3\%A0}[\result]%
  \StrSubstitute{\result}{è}{\%C3\%A8}[\result]%
  \StrSubstitute{\result}{_}{\%5F}[\result]%
}

% Macro finale
\newcommand{\myurl}[1]{%
  \MakeUTFPerCent{#1}%
  \href{\result}{#1}%
}

\begin{document}

Lien encodé : \myurl{https://fr.wikipedia.org/wiki/Idéal_premier}

\end{document}

Mais rien ne marche. Et j’en profite pour noter que chatGPT est nettement moins bon en LaTeX qu’en math ou en python.

luatex

Donc passage à LuaTeX, et ça a été assez facile.

• temps de compilation plus long
• texte raccourci : au moment du passage à LuaTeX je suis passé d’environ 3050 à 2775 pages.

Très peu de changements :

-\documentclass[a4paper,twoside,11pt]{book}
+\documentclass[french]{book}
+\RequirePackage{luatex85}      % Pour xy (voir https://tex.stackexchange.com/questions/328602/lualatex-and-xypic)

et

-\usepackage{listingsutf8}  
+\usepackage{listings}

Passage à 5 volumes

Comme à chaque mois de septembre, une version figée est commercialisée pour celles qui voudraient avoir du papier (et aussi parce que la dernière fois que j’ai lu le règlement de l’agrégation, la commercialisation était obligatoire).

Le nombre maximum de pages étant de 750 par volume, le nombre total de page étant de 2872, j’ai dû passer à 5 volumes. Et c’est là que je suis content d’avoir dès le départ, dans mes scripts, mis le nombre de volumes en variable.

Laurent est un pédant

Je suis un insupportable pédant. Et je propose même de fonder un club. Dans des discussions non mathématiques sur LinuxFr.org je suis parvenu à me fritter à propos (au moins) de l’utilisation correcte de

• novlang
• exponentielle. Plusieurs fois.
• Pluton — mais là le troll n’a pas pris. On ne peut pas toujours gagner.

Le Frido aussi est un peu pédant par exemple si est un polynôme, il est démontré que . On pourrait croire que c’est seulement une notation, mais non. C’est un théorème.

Le Frido démontre aussi que si on induit la topologie de vers le cercle et qu’on construit la tribu de Lebesgue à partir de là (boréliens, complétion), on obtient la même tribu que si on induit directement la tribu de Lebesgue de vers le cercle. C’est important pour prouver des isomorphismes d’espaces de Lebesgue avec .

À part ça, le Frido est un pédant de notations. J’ai horreur des abus de notations, et je prétends que la formule d’Euler ne contient pas le nombre .

L’Humanité

L’Humanité a publié un article sur le Frido. Encore un en 2027 et le Frido rentre dans des critères d’admissibilité de Wikipédia :).

Le règlement (UE) 2024/2847, aussi appelé Cyber Resilience Act ou CRA, impose des exigences de cybersécurité à tout « produit comportant des éléments numériques » mis sur le marché de l’Union (logiciels compris, mais pas les services web). Son article 14 est entré en application le 11 septembre 2026. Tout fabricant doit signaler sous 24 heures toute vulnérabilité activement exploitée dans son produit et tout incident grave de sécurité, y compris pour les produits déjà sur le marché, puis compléter ce signalement sous 72 heures et le clore par un rapport final. Le reste du règlement s’applique à partir du 11 décembre 2027.

L’écosystème du libre s’était alarmé dès la proposition de 2022, et LinuxFr.org s’en était fait l’écho : le CRA menace l’avenir du logiciel libre, puis le texte du CRA a été finalisé. Le point d’achoppement était la notion d’« activité commerciale », dont dépend l’application du règlement. Le texte adopté en 2024, puis l'orientation de la Commission publiée le 27 juillet 2026, document interprétatif non contraignant, l’ont précisée dans un sens qui épargne les contributeurs individuels et les projets non monétisés.

Restent des chantiers ouverts : aucune norme harmonisée publiée à ce jour au Journal officiel, pas encore de mécanisme d’attestation de sécurité pour le logiciel libre, une plateforme de signalement sans API, et la question de qui paie les mainteneurs.

Sommaire

• Deux définitions du règlement
• Ce que l’écosystème a obtenu depuis 2023
• Les obligations vis-à-vis des mainteneurs
• Ce qui n’est pas prêt
• Qui paie les mainteneurs ?
• Prochaine manche : le règlement sur l’IA

Ce qui s’applique aujourd’hui

L’article 14 comporte deux déclencheurs : une vulnérabilité activement exploitée présente dans le produit, et un incident grave « ayant des répercussions sur la sécurité du produit », par exemple l’exécution d’un code malveillant dans le produit ou chez ses utilisateurs, qu’une faille ait été identifiée ou non. Chacun suffit. Les deux suivent la même cadence, au rapport final près :

• 24 heures : alerte précoce à l’ENISA (l’agence européenne de cybersécurité) et au CSIRT de son État membre (l’équipe publique de réponse aux incidents, CERT-FR pour la France), via la plateforme de signalement unique ;
• 72 heures : notification complémentaire, avec les éléments techniques et les mesures engagées ;
• rapport final : quatorze jours après la mise à disposition d’un correctif pour une vulnérabilité exploitée, un mois après la notification à 72 heures pour un incident grave.

Le texte apporte deux nuances. L’obligation de signaler s’impose à tous les fabricants, mais l’amende n’est pas la même pour tous (article 64(10)). Une microentreprise ou une petite entreprise qui dépasse les 24 heures n’est pas sanctionnée pour ce retard. Un intendant de logiciels ouverts (défini plus bas) n’encourt, lui, aucune amende, quel que soit le manquement. Enfin, l’article 14 vise les vulnérabilités « contenues dans » le produit : une faille exploitée dans une dépendance n’est à signaler que si le produit embarque le code vulnérable et que ce code y est effectivement atteignable. Une bibliothèque vulnérable dont le code fautif n’est jamais exécuté par le produit n’a pas à être signalée.

Côté outillage, la plateforme de l’ENISA ouvre aujourd’hui sans API : les signalements se saisissent à la main, en texte, dans une vingtaine de champs, et aucune pièce jointe n’est acceptée.

Deux définitions du règlement

Le texte français des articles et des annexes n’emploie pas une seule fois l’expression « open source ». Voici l’article 3, point 48) :

« logiciel libre et ouvert » : un logiciel dont le code source est partagé de manière ouverte et qui est mis à disposition sous licence libre et ouverte prévoyant tous les droits pour qu’il soit librement accessible, utilisable, modifiable et redistribuable ;

La définition pose deux conditions : une licence libre, et le partage ouvert du code source. Du code sous licence libre remis au seul client qui l’a commandé, sans publication, remplit la première condition et pas la seconde : il n’est pas « logiciel libre et ouvert » au sens du règlement. La FAQ officielle de la Commission le confirme pour le développement sur mesure : livrer à un client un logiciel écrit pour lui est une mise sur le marché, le prestataire qui le livre sous son propre nom en est le fabricant, sans aucun des allègements réservés au libre. Il peut seulement aménager par contrat deux des exigences essentielles de sécurité (question 4.2.5). La FAQ de l’ORC WG, le groupe de travail de la Fondation Eclipse qui suit le règlement pour l’écosystème du libre, ajoute, sur la base de l’orientation, qu’installer, configurer ou intégrer un logiciel existant pour un client reste une prestation de service.

L’article 3, point 14), crée une catégorie juridique inédite :

« intendant de logiciels ouverts » : une personne morale, autre que le fabricant, qui a pour objectif ou finalité de fournir un soutien systématique et continu au développement de produits spécifiques comportant des éléments numériques qui répondent aux critères de logiciels libres et ouverts et sont destinés à des activités commerciales, et qui assure la viabilité de ces produits ;

Le mot « steward » s’est imposé dans l’usage, y compris en français. Le statut est réservé aux personnes morales, sans condition de forme ni de but : une association loi de 1901, une fondation ou une société commerciale peuvent y prétendre. Le considérant 19 (les considérants forment l’exposé des motifs qui ouvre le règlement) vise expressément les entités qui développent et publient du logiciel libre dans un cadre professionnel. La FAQ de l’ORC WG répond sans détour qu’une société peut être intendante.

Reste le cas de la société qui est aussi fabricant, le plus courant chez les éditeurs. Les versions linguistiques y divergent. L’anglaise dit « a legal person, other than a manufacturer » : une personne morale qui n’est pas un fabricant, ce qui interdit d’être fabricant d’un produit et intendant d’un autre. La française dit « une personne morale, autre que le fabricant » : autre que le fabricant des produits soutenus, ce qui autorise le cumul en général mais l’interdit pour un même produit, précisément le cas courant de l’éditeur qui vend une édition de son logiciel et publie l’autre. Les vingt-quatre versions linguistiques ont la même valeur juridique. Sur ce point, elles ne disent pas la même chose. L’orientation de juillet 2026 va plus loin que l’une et l’autre : la même entité peut être fabricant de l’édition qu’elle monétise et intendante de l’édition communautaire du même logiciel. Tant mieux pour les éditeurs. Mais un document sans valeur contraignante accorde ainsi ce qu’aucune version du règlement ne dit. Sur le point le plus disputé du texte, le législateur a laissé deux versions qui se contredisent. L’édifice tient par une orientation que la Commission peut réviser.

Ce que l’écosystème a obtenu depuis 2023

Les contributions et les dons. Le considérant 18 exclut du règlement ceux qui contribuent à un logiciel qui « ne relève pas de leur responsabilité ». Un logiciel relève de la responsabilité de celui qui le publie et contrôle son développement, ses versions et sa distribution ; un accès en écriture au dépôt ne suffit pas. Un salarié qui envoie un correctif à un projet tiers pour le compte de son employeur reste un contributeur hors champ. Qui est payé pour le logiciel est fabricant ; qui est payé pour travailler sur le logiciel est prestataire, ou contributeur. Afficher un lien de don ne vaut pas intention de faire du profit ; les dons ne deviennent suspects que si l’ensemble des revenus du projet dépasse de loin ses coûts, dans lesquels entrent les frais de subsistance raisonnables du mainteneur.

L’intendant. L’article 24 lui impose trois choses : une politique de cybersécurité documentée et vérifiable, la coopération avec les autorités de surveillance du marché, et le signalement de l’article 14 dans la mesure où il participe au développement, si bien qu’un intendant purement financier ou juridique ne signale rien. Il le dispense de tout le reste : ni exigences essentielles de sécurité de l’annexe I, ni marquage CE, ni documentation technique, ni SBOM (l’inventaire des composants d’un produit), ni obligation de corriger. L’article 64(10)(b) l’exempte de toute amende.

Les modèles économiques. Le cas du bénévole isolé était pour l’essentiel acquis dès la proposition initiale de septembre 2022. La difficulté la plus sérieuse portait sur les éditeurs qui vendent de la maintenance sur ce qu’ils publient librement. C’est pour eux, plus que pour les bénévoles, que les associations professionnelles comme le CNLL ont bataillé. La réponse figure dans l’orientation, avec la fragilité relevée plus haut : les rôles s’apprécient logiciel par logiciel et activité par activité, y compris en open core (cas où l’édition payante étend la base de code de l’édition libre et ouverte). La condition est que les deux éditions soient réellement séparées : dépôts, artefacts et canaux distincts.

Les obligations vis-à-vis des mainteneurs

L’article 13(6) impose aux fabricants une obligation envers les mainteneurs des composants qu’ils intègrent. Le voici, deux renvois en moins :

Lorsqu’ils identifient une vulnérabilité dans un composant, y compris un composant logiciel ouvert, qui est intégré au produit comportant des éléments numériques, les fabricants signalent la vulnérabilité à la personne ou à l’entité qui assure la maintenance du composant […]. Lorsque les fabricants ont mis au point une modification logicielle ou matérielle pour remédier à la vulnérabilité de ce composant, ils partagent le code ou la documentation correspondants […], dans un format lisible par machine s’il y a lieu.

Le signalement est dû dans tous les cas. Le partage, lui, suppose que le fabricant ait effectivement développé une modification : s’il n’a rien écrit, il n’a rien à remettre. Et ce qu’il remet correspond à ce qu’il a fait, les deux « ou » de la phrase se répondant : le code pour une modification logicielle, la documentation pour une modification matérielle. L’orientation y ajoute des bornes : l’obligation ne porte que sur la version intégrée du composant et sur ses propres failles, elle s’exerce dans le respect de la politique de divulgation du projet, et elle tombe si le composant n’a plus de mainteneur. L’obligation ne dépend d’aucun lien contractuel entre le fabricant et le projet. Rien dans le règlement ne donne pour autant au mainteneur d’action propre pour l’exiger : la faire respecter revient aux autorités de surveillance du marché.

Ce qui n’est pas prêt

• Les normes harmonisées. Appliquer l’une d’elles vaut présomption de conformité : le fabricant est réputé satisfaire aux exigences qu’elle couvre, sans avoir à le démontrer autrement. Sur les 41 commandées aux trois organismes européens de normalisation (CEN, CENELEC, ETSI), aucune n’a encore été publiée au Journal officiel. Or l’article 27 ne fait naître la présomption qu’à cette publication. Trois projets sont en approbation (prEN 40000-1-1, -1-2, -1-3) ; le lot du catalogue d’exigences génériques a été mis en attente faute de contributeurs.
• Les attestations de sécurité du logiciel libre (article 25). Le règlement habilite la Commission à créer, par acte délégué (un texte d’application que la Commission adopte seule), des programmes volontaires d’attestation de sécurité pour le logiciel libre, afin de faciliter la vérification que les fabricants doivent faire des composants qu’ils intègrent, la « diligence raisonnable » de l’article 13, paragraphe 5. Le texte ne dit pas qui les financerait. L’ORC WG propose d’en faire le canal par lequel les fabricants paieraient les projets dont ils dépendent ; pour les projets libres, c’est l’absence la plus coûteuse. Aucun acte délégué n’a été publié ni planifié. En attendant, les référentiels de l’OpenSSF, la fondation de la Linux Foundation consacrée à la sécurité du logiciel libre, servent de justificatifs : Scorecard, Best Practices Badge, OSPS Baseline et SLSA.
• L’orientation elle-même. Elle n’existe qu’en anglais, n’a pas de valeur contraignante, et n’est pas encore formellement adoptée, faute des autres versions linguistiques. Tout ce que la section précédente lui attribue a la solidité d’une interprétation, que la Commission peut réviser et qu’un juge n’est pas tenu de suivre.
• Très peu de projets auront un intendant. Le rapport OSSRA 2025 de l’éditeur d’outils d’audit Black Duck, sur 965 bases de code commerciales auditées en 2024, y a dénombré 282 521 paquets JavaScript distincts. L’OpenJS Foundation héberge environ 35 projets. Un projet publie souvent plusieurs paquets, mais l’écart reste de plusieurs ordres de grandeur : la plupart des dépendances d’un produit n’auront ni fabricant ni intendant, et leur sécurité restera à la charge de qui les intègre.
• Le matériel libre. L’article 24 vise les logiciels : RISC-V International, l’OSHWA (Open Source Hardware Association) ou l’OpenHW Group ne peuvent pas prétendre au statut d’intendant.
• Les sanctions nationales. L’article 64 laisse aux États membres le soin de fixer le régime de sanctions, d’où des lois d’application nationales. Le règlement exempte les intendants de toute amende. Le projet de loi finlandais en prévoyait pourtant : le Parlement finlandais ne les a retirées qu’au printemps 2026.

Qui paie les mainteneurs ?

L'étude d’impact qui accompagnait la proposition de 2022 estimait qu’un cycle de développement sécurisé ajoute en moyenne 30,5 % au coût de développement d’un produit, pour un fabricant qui part de zéro : 42 700 € sur un produit moyen à 140 000 €. S’y ajoutent 9 % de coûts administratifs, documentation et signalement compris. C’est le « 30 % » que citait le CNLL en 2023. Aucune actualisation n’a été publiée depuis.

Le fabricant répercute ce surcoût sur son client, ou l’absorbe et cesse d’investir ailleurs. Le mainteneur n’a pas de client à qui le répercuter. Le travail lui arrive quand même. L’article 13(5) oblige le fabricant qui intègre un composant à en vérifier la sécurité ; beaucoup s’en acquittent en envoyant leurs questions au projet, sous forme de questionnaires de sécurité, de demandes de SBOM ou de délais de correction à confirmer. Hors champ du règlement, le mainteneur ne doit rien de tout cela. Rien n’oblige pour autant les fabricants à cesser : l’ORC WG en est réduit à plaider pour une « diligence respectueuse », qui ne traite pas un projet libre comme un fournisseur.

Le mécanisme d’attestation de l’article 25, seul canal de financement esquissé par le règlement, n’existe pas. La stratégie européenne pour l’open source du 3 juin 2026 annonce un « instrument de maintenance de l’open source », que l’écosystème réclamait sur le modèle du Sovereign Tech Fund allemand, sans budget ni calendrier.

Trois ans de mobilisation ont produit un règlement vivable pour le libre. Qui paie les mainteneurs dont il fait dépendre tout l’édifice, le texte ne le dit pas, et personne d’autre non plus, à ce stade.

Prochaine manche : le règlement sur l’IA

Le règlement sur l’intelligence artificielle exempte lui aussi les systèmes publiés sous licence libre (article 2, paragraphe 12), sauf s’ils sont mis sur le marché comme systèmes à haut risque. Or un système est classé à haut risque d’après l’usage auquel son fournisseur le destine. Le projet d’orientations publié par la Commission le 19 mai 2026 retient qu’un système présenté comme largement applicable, dont le fournisseur n’exclut pas de façon constante les usages à haut risque, est réputé les couvrir. Une simple déclaration, ajoute-t-il, ne suffit pas. Un composant d’IA publié en libre est mal armé pour ce test : son auteur ne maîtrise ni les usages ni les utilisateurs, et une licence qui restreindrait les champs d’application cesserait d’être libre (liberté 0 de la FSF, critère 6 de l'Open Source Definition). L’exemption s’évanouirait donc là où elle compte. Reste à savoir quel poids une autorité accordera aux limitations inscrites dans un README ou une fiche de modèle.