Open source is not a simple sovereignty fix for the public sector: officials and experts hearing the French parliamentary inquiry on digital dependencies warned that “free” software can become a form of hidden lock-in when it is too dependent on a single vendor. Yves Billon, head of digital services at the general secretariat of the economic ministries, pointed to several such cases, singling out one company with a red-hat logo as particularly problematic. Matthieu Weill, director for digital transformation at the Interior Ministry, made the same point: many open-source solutions are effectively built around an editor whose core team depends on a company. The risk, he said, is that an investor arrives, the strategy changes, and the free version is reduced to a shell while maintenance, security operations and the most valuable features become paid.

For Weill, open source should be assessed with the same long-term lens as proprietary software, including maintenance in operational and security conditions, or MCO and MCS. A digital commons that is not maintained over time can create the same kind of dependency as a private supplier that goes bankrupt, forcing the administration into an emergency fix.

Alain Garnier, president of Jamespot, was more skeptical about digital commons. He acknowledged they can accelerate industrial capability, but argued they do not by themselves let a vendor package a product, innovate or provide support. More importantly, he warned that they give GAFAM raw material for their AI systems and services. In his view, the next decade could see public money funding building blocks that Big Tech then exploits “before selling them back” with the right marketing, support and integration. Mélanie Dulong de Rosnay, a CNRS research director, echoed that concern: open and free licenses help diffusion, but they also allow value extraction without reciprocity or support for creation and infrastructure, even though digital commons are often produced with public funding or volunteer community work.

The speakers also stressed that deploying open-source tools in large organizations requires adapting to technological shifts and existing systems. Billon cited Office 365 as a major break: LibreOffice can handle office work, but it does not offer the same user experience or cloud experience, and rebuilding the surrounding stack led to functional losses that users felt. He also recalled the DGFiP’s need for an Active Directory equivalent. Samba could not handle the complexity of the tax administration’s environment, so additional resources had to be allocated to adapt it. Even then, the ministry-level budgeting process cost one to one and a half years in negotiations. Billon said this shows why DSI teams need people who are known to open-source communities, or ideally recognized within them.

Tomasz Blanc, head of information systems at the DGFiP, said open source can mean less polished ergonomics and collaboration features than commercial products, and it requires technical discipline to avoid getting lost in an overly fragmented ecosystem. On a fleet of 110,000 to 115,000 workstations, the challenge is device administration: security patches must be deployed quickly and software pushed remotely without physical intervention. Windows benefits from highly advanced automation, and equivalent tools must be available. The DGFiP also has to account for legacy infrastructure, including IBM Z servers that still run historic tax-calculation and banking-exchange applications. They are reliable and performant, but expensive at €4.5 million, and moving away from them is complex. Migrating Cobol applications to open-source software requires long projects and rigorous testing, as shown by the gradual overhaul of the civil servants’ payroll system.

Maintenance and interoperability came up repeatedly. Thomas Jan, deputy CEO in charge of innovation and digital strategy at UniHa, highlighted interconnection and interoperability issues. Baptiste Grigy, CIO of the CEA, said his organization tries to move to open source where possible, but not everywhere: Microsoft is deeply embedded in its systems beyond Windows and Office, including identity management through Active Directory and PC/server fleet management. He also warned that pricing can change over time: what starts free can become paid as usage grows, data volumes increase or certain features are needed. More broadly, he said open source creates update challenges and requires significant internal resources.

Damien Rousset, deputy general manager for administration at Inserm, made a similar point. Open source has limits, especially in human resources for maintenance, which public bodies do not always have. Proprietary software, by contrast, often arrives as ready-to-deploy update packages. Open-source tools require more effort and sometimes mean “opening the hood.” Inserm also does not always find open-source replacements for proprietary tools, especially in cybersecurity. Its CIO, Sammy Sahnoune, said some open-source solutions would require “an army behind them” because administration is almost command-line based, even if a skilled administrator can manage them. He added that American tools are often extremely ergonomic and easy to use. Vincent Strubel, director general of ANSSI, confirmed that specialized open-source cybersecurity options are often limited.

The picture is more mixed in AI. Dominique Luzeaux, a French general and NATO digital transformation official, said the open resource ecosystem is richer, but it is both a response and a vulnerability. When low-level services downloaded by huge numbers of developers are written by a tiny community of Russian programmers employed by Yandex, vulnerability becomes acute. Not every user can verify all the code they use, and the sheer number of communities on GitHub makes exhaustive review impossible.

Attention au « faux » libre, c’est-à-dire du gratuit trop dépendant d’une entité.

Yves Billon l’avait fait remarquer à la commission d’enquête parlementaire sur les dépendances numériques lorsque celle-ci menait, au printemps, ses auditions. « Cela concerne plusieurs sociétés, avait assuré le chef du service du numérique au secrétariat général des ministères économiques. Mais l’une, en particulier, dont le logo représente un chapeau rouge, nous pose des difficultés », avait-il ajouté…

Risque de centralisation

Matthieu Weill, intervenu lors de la même audition, lui avait en quelque sorte fait écho. « Nous avons de multiples exemples de solutions libres dont le cœur de l’équipe éditrice dépend en fait d’une société », avait expliqué le directeur de la transformation numérique au ministère de l’Intérieur. De là naît un risque : « Au début, le modèle économique de la société éditrice repose sur un logiciel libre avant qu’un nouvel investisseur n’arrive et que la stratégie change : la version libre est alors réduite à peau de chagrin, les maintiens en conditions opérationnelles et de sécurité ou les fonctionnalités de grande valeur que l’on utilisait deviennent payantes ».

Il faut, plus globalement, appliquer au logiciel libre le même type d’analyse et de réflexion que pour les solutions privées, affirme Matthieu Weill. En particulier, donc, avoir une « vision de long terme qui englobe le MCO et le MCS ».

À ce sujet, l’intéressé ajoute : « De même qu’un fournisseur peut faire faillite, un commun numérique qui n’est pas suivi dans la durée peut créer un problème de dépendance que l’on devra résoudre dans l’urgence ».

Ne pas trop miser sur les communs numériques ?

Auditionné ultérieurement, Alain Garnier s’est montré circonspect quant aux communs numériques. Ils sont certes un levier d’accélération de la capacité industrielle, a reconnu le président de Jamespot. Mais ils « ne rendent pas un industriel capable de packager un produit, d’innover et d’assurer un support ». Surtout, ils procurent aux GAFAM une matière première pour leurs IA et leurs systèmes. Alain Garnier y voit un « risque que nous courons pour les dix prochaines années » : celui de financer, par nos impôts, les briques que les Big Tech exploiteraient à leur profit « avant de nous les revendre avec le marketing, le support et l’intégration adéquats ».

Mélanie Dulong de Rosnay, directrice de recherche au CNRS, va dans le même sens. Les licences libres et ouvertes favorisent la diffusion, mais « autorisent l’extraction de la valeur sans réciprocité ni soutien à la création ou à l’infrastructure, alors que les communs numériques sont produits grâce à des financements publics ou au travail bénévole de communautés ».

Penser relations communautaires

Le déploiement d’outils libres nécessite aussi d’intégrer les ruptures technologiques, telle celle qu’a introduite Office 365, a rappelé Yves Billon. « On peut faire de la bureautique avec LibreOffice, mais on ne bénéficie pas de l’expérience utilisateur d’Office 365, de l’expérience cloud. Il a fallu reconstruire beaucoup de choses derrière. On y a beaucoup perdu sur le plan fonctionnel. Les utilisateurs l’ont ressenti. »

Les logiciels libres nécessitent, plys globalement, des ajustements avant leur installation dans de grandes organisations. Yves Billon mentionne le cas de la DGFiP. Non dépendante de Microsoft, elle s’était vu enjoindre d’opérer une structuration plus profonde de son SI au moyen d’un équivalent à Active Directory. La solution, Samba, n’était pas en mesure de gérer la complexité de l’organisation. On a donc dégagé des moyens pour l’adapter. « Nous nous sommes efforcés de mutualiser l’action à l’échelon interministériel. Nous avons perdu un an à un an et demi dans les négociations budgétaires pour trouver un accord. »

La démarche illustre ce qu’Yves considère comme une nécessité globale : savoir travailler avec les communautés. « Il importe qu’au sein des DSI, un certain nombre de personnes soient connues des communautés ou, au mieux, soient référentes au sein de celles-ci. »

Tenir compte de l’existant

Chez Tomasz Blanc, même son de cloche au sujet des ruptures technologiques. Le libre « offre parfois une ergonomie ou des fonctions collaboratives moins abouties » que des solutions commerciales, déclare le chef du service des SI de la DGFiP. Il impose aussi une discipline technique « pour ne pas s’égarer dans un écosystème trop foisonnant ».

« Il y a aussi des préalables techniques à valider, reconnaît l’intéressé, en écho à ses collègues. Sur un parc de 110 000 à 115 000 postes de travail, le défi, c’est l’administration de la flotte. Il faut pouvoir diffuser rapidement des correctifs de sécurité et déployer des logiciels à distance sans intervention physique. [Notre] environnement Windows bénéficie d’une automatisation très poussée. Nous devons nous assurer de disposer d’outils équivalents. »

Il faut aussi tenir compte de l’existant. À la DGFiP, il y a notamment encore des serveurs IBM Z qui supportent les applications historiques de calcul de l’impôt ou d’échanges bancaires. « Fiables et performants », ils sont coûteux (4,5 M€). Et en sortir est complexe : « La migration d’applications cobol vers des logiciels libres exige des projets longs et des tests rigoureux, comme l’illustre la refonte progressive de la paye des fonctionnaires d’État. »

La question de la maintenance

Dans le même esprit qu’Yves Billon, Thomas Jan, DGA en charge de l’innovation et de la stratégie numérique de l’UniHa (Union des hôpitaux pour les achats), souligne les questions d’interconnexion et d’interopérabilité que soulève le déploiement de logiciels libres.

Baptiste Grigy n’en dit pas moins, quoique dans un registre plus spécifique. « Nous essayons d’aller vers l’open source là où c’est possible, mais [ça ne l’est pas] partout. […] Microsoft, par exemple, est très profondément ancré dans nos SI, au-delà de ce que l’on voit comme l’OS et la suite Office : il pilote aussi la gestion de nos identités avec Active Directory ou la gestion de nos parcs de PC et de serveurs. »

Le DSI du CEA mentionne lui aussi le risque d’évolution des politiques tarifaires (« Au départ, c’est gratuit, puis, à mesure que l’usage augmente, que vous voulez mettre plus de données ou utiliser certaines fonctionnalités, cela devient payant »). Il élargit son propos : l’open source « présente une difficulté de mise à jour et nécessite des ressources internes importantes ».

Damien Rousset exprime le même sentiment. « L’open source a ses limites, notamment en termes de ressources humaines pour la maintenance, que nous n’avons pas toujours », déplore le directeur général délégué à l’administration de l’Inserm. « Avec les solutions propriétaires, nous recevons des paquets de mises à jour sur lesquels il suffit de cliquer pour les déployer, ajoute-t-il. Les outils open source […] demandent plus d’efforts : il faut […] parfois ‘ouvrir le capot’ ».

Des angles morts, comme en cyber

Dans ce contexte, l’Inserm ne perçoit pas toujours de débouchés open source pour remplacer ses outils propriétaires. Notamment dans la cyber. Son DSI Sammy Sahnoune confirme : « Nous avons évoqué les ressources humaines nécessaires pour administrer des solutions open source. J’en ai plusieurs en tête pour lesquelles il faudrait une armée derrière, car l’administration se fait presque en ligne de commande. C’est possible pour un administrateur compétent. Mais au-delà de cela, je dirais que c’est la conception même des outils américains qui est extrêmement ergonomique et facilitatrice. »

Les options open source en matière d’outils spécialisés en cybersécurité « sont souvent limitées », confirme Vincent Strubel, directeur général de l’ANSSI.

Le catalogue de ressources ouvertes dans le domaine de l’IA est plus foisonnant. Mais il est « à la fois une réponse et une vulnérabilité », avertit Dominique Luzeaux, général de division, chargé de mission « transformation numérique » auprès du commandant suprême allié pour la transformation de l’OTAN. « Lorsque des services de très bas niveau, téléchargés par de très nombreux développeurs sont programmés par une toute petite communauté d’informaticiens russes employés par l’entreprise Yandex, la question de la vulnérabilité se pose de façon aiguë. Or, tous les utilisateurs ne sont pas capables de vérifier l’intégralité des codes proposés. Et le très grand nombre de communautés qui existent, notamment sur GitHub, ne permet pas d’effectuer une revue exhaustive desdits codes. »

À consulter en complément :

Le rapport de la commission d’enquête et ses 29 propositions

L’analyse des dépendances de la sphère publique à Microsoft, à Oracle et à VMware

Les livrables produits en un an par le Conseil national de l’IA et du numérique

L’alerte de la Cour des comptes sur les pépites françaises de l’informatique quantique

Souveraineté numérique : le diagnostic fait consensus, pas le remède

Illustration générée par IA

The post Open source et secteur public : pourquoi ce n’est pas si facile appeared first on Silicon.fr.