• la synthèse que j’ai choisie de lire
• le rapport complet pour approfondir les travaux de la commission
• ainsi qu’un document présentant les principaux chiffres clés.

Je précise donc d’emblée que cet article repose essentiellement sur la version de synthèse. Il ne prétend pas restituer chaque audition, chaque donnée ni toutes les nuances du rapport complet. Mon objectif est simplement de partager ce que j’en ai compris et les enseignements qui me paraissent les plus importants. Les personnes qui souhaitent aller plus loin pourront consulter les trois documents directement sur le site de la députée.

Au fil des pages, ce rapport met en évidence une réalité devenue difficile à ignorer : notre dépendance numérique n’est ni marginale ni seulement technique. Elle concerne désormais l’ensemble de notre société, de l’administration aux entreprises, des services publics aux moyens de paiement, jusqu’aux outils d’intelligence artificielle que nous utilisons chaque jour.

Le rapport ne se contente pas d’aligner des chiffres ou de dénoncer la domination des grandes plateformes. Il montre comment des choix techniques, économiques et politiques accumulés pendant des années ont progressivement réduit notre capacité à choisir nos outils, à protéger nos données, à maîtriser nos infrastructures et, en définitive, à décider librement.

Ce qui est décrit ici n’est donc pas une simple bataille commerciale entre entreprises américaines et européennes. C’est une question de continuité des services publics, de sécurité, de libertés fondamentales, de souveraineté politique et de maîtrise collective de notre avenir numérique.

Voici, en termes simples, ce que j’ai compris de cette synthèse :

Idée générale du rapport

La commission estime que la France et l’Europe sont devenues structurellement dépendantes de quelques entreprises numériques, principalement américaines, pour leurs logiciels, leur cloud, leurs données, leurs moyens de paiement et désormais leurs outils d’intelligence artificielle.

Cette dépendance ne constitue plus seulement un problème économique ou industriel. Elle crée des risques pour :

• la continuité des services publics
• la confidentialité des données
• l’indépendance politique et diplomatique
• la sécurité nationale
• les finances publiques
• les droits fondamentaux
• la capacité de la France à décider librement de sa politique numérique.

Le rapport ne propose pas simplement de remplacer les entreprises américaines par de grands monopoles européens. Il défend un modèle fondé sur le logiciel libre, les standards ouverts, l’interopérabilité, la maîtrise des infrastructures et la diversité des acteurs.

Contexte de la commission d’enquête

La commission a travaillé du 3 février au 15 juillet 2026. Elle a entendu 112 personnes lors de 45 auditions et étudié 61 contributions écrites.

Elle part d’un constat : les alertes sur la souveraineté numérique existaient déjà, mais deux événements ont rendu la situation plus urgente :

• La dégradation des relations entre les États-Unis et l’Union européenne depuis 2025
• Le déploiement massif de l’intelligence artificielle générative.

La commission cherche donc à passer d’un discours général sur la souveraineté numérique à une cartographie concrète des dépendances, afin d’identifier les solutions qui pourraient être remplacées et les secteurs réellement vulnérables.

Première partie : Le diagnostic

1. Les dépendances numériques des administrations

Applications métiers

Les applications spécifiquement développées pour les ministères sont plutôt bien maîtrisées :

• environ deux tiers des logiciels étudiés sont des applications spécifiques
• 69 % des applications les plus critiques sont fournies par des acteurs français
• cette proportion monte à 83 % pour les applications nécessaires à une mission essentielle de service public ;
• sur 417 applications analysées, 64 % appartiennent aux administrations utilisatrices
• 16 % sont développées en open source.

Le danger ne réside donc pas principalement dans l’ensemble des applications métiers, mais dans quelques applications critiques, coûteuses et très difficiles à remplacer, notamment dans la santé, la justice, la police ou la comptabilité publique.

Logiciels supports

La dépendance la plus profonde concerne les briques utilisées partout :

• Microsoft pour Windows, Office et Microsoft 365
• Oracle pour les bases de données
• VMware pour la virtualisation
• dans une moindre mesure IBM et Red Hat

Ces outils sont difficiles à remplacer parce qu’ils constituent le socle du système d’information et sont connectés à de nombreuses applications.

La Gendarmerie nationale constitue le principal contre-exemple. Elle a progressivement migré vers Linux et des logiciels libres. Microsoft Office ne serait encore installé que sur moins de 2 % des postes, principalement pour des problèmes de compatibilité avec certains partenaires.

Cloud et hébergement des données

Les administrations continuent majoritairement à héberger leurs données en interne, particulièrement dans les ministères régaliens. L’État dispose notamment de deux clouds internes :

• Pi, porté par le ministère de l’Intérieur
• Nubo, porté par la Direction générale des finances publiques.

Mais le recours au cloud commercial progresse rapidement. Les commandes passées par l’intermédiaire du marché Nuage public de l’UGAP sont passées de 20 millions d’euros en 2022 à 84 millions en 2025.

Le rapport relève plusieurs situations préoccupantes :

• 83 % des dépenses cloud de France Travail étaient concentrées chez ServiceNow, AWS et Microsoft Azure ;
• près de 98 % des dépenses cloud de la CNAF allaient vers des hébergeurs américains
• le ministère de l’Éducation nationale utilise Salesforce pour son application des ressources humaines : Virtuo, malgré les réserves de la CNIL et de l’ANSSI concernant les lois extraterritoriales
• certaines plateformes d’aide aux victimes utilisées par la police et la gendarmerie ne sont pas hébergées dans un environnement SecNumCloud.

Intelligence artificielle dans l’administration

Claude, Copilot, Gemini et ChatGPT sont déjà largement utilisés dans les administrations, souvent à travers les infrastructures d’AWS, Microsoft ou Google.

Le risque est double :

• transmettre des données administratives sensibles à des acteurs étrangers
• laisser ces données être réutilisées ou exposées lors du fonctionnement ou de l’entraînement des modèles

Des alternatives apparaissent néanmoins :

• l’Inserm développe des modèles sur son propre cloud
• la DGFIP utilise des solutions open source
• la DINUM a développé Albert, reposant notamment sur des modèles Mistral dans un environnement SecNumCloud.

Le rapport alerte surtout sur la shadow IA, c’est-à-dire l’utilisation informelle d’outils non approuvés. Dans une enquête portant sur 1 867 agents, 55 % reconnaissaient utiliser personnellement des agents conversationnels en dehors du cadre prévu par leur employeur.

2. Les entreprises publiques, privées et les paiements

Entreprises publiques

Les systèmes industriels critiques, comme les systèmes de conduite des réseaux électriques ou ferroviaires, apparaissent relativement bien protégés. Ils utilisent souvent des infrastructures internes, européennes ou cloisonnées.

En revanche, les fonctions administratives et tertiaires restent massivement dépendantes de Microsoft 365, VMware, Oracle et des clouds américains.

Entreprises privées

Les entreprises commencent à identifier la dépendance numérique comme un risque géopolitique et économique, mais elles mettent encore peu de plans de migration en œuvre.

Les principaux risques sont :

• le verrouillage propriétaire
• les hausses tarifaires
• l’absence de réversibilité
• le coût et la complexité des migrations

Le rapport propose de développer des grilles d’achat et des clauses contractuelles imposant davantage de réversibilité et d’interopérabilité.

Banques et paiements

Le règlement européen DORA oblige les établissements financiers à cartographier leurs prestataires numériques critiques. Sur les 19 prestataires critiques identifiés en Europe en novembre 2025 :

• 11 avaient leur siège aux États-Unis
• seulement 4 avaient leur siège dans l’Union européenne.

Visa et Mastercard dominent les paiements européens : environ 60 % des paiements européens ne seraient plus souverains.

La France conserve cependant une certaine maîtrise grâce au réseau Cartes Bancaires, qui traite la majorité des paiements domestiques. Le rapport soutient également :

• Wero, solution européenne de paiement instantané
• le projet d’euro numérique
• une infrastructure européenne autonome pour les paiements

Deuxième partie : Les conséquences économiques et systémiques

3. Les pertes économiques et le gaspillage d’argent public

Domination économique

Les entreprises américaines occupent une place considérable sur le marché français :

• Microsoft France réalise environ 4,7 milliards d’euros de chiffre d’affaires
• Google, Meta et Amazon captent environ 72 % de la publicité en ligne française
• les acteurs américains du cloud génèrent beaucoup de chiffre d’affaires en France, mais relativement peu d’emplois locaux.

Le rapport oppose notamment le modèle d’OVHcloud, qui conçoit et exploite ses infrastructures en France et emploie davantage de personnes, à celui des hyperscalers dont une grande partie de la valeur est produite et comptabilisée à l’étranger.

Faible contribution fiscale

Les filiales françaises des grandes plateformes exercent souvent principalement des fonctions commerciales. Les logiciels, licences et services sont facturés depuis l’Irlande, le Luxembourg ou d’autres pays.

L’essentiel de la valeur ajoutée et des bénéfices est donc localisé hors de France. La taxe sur les services numériques est présentée comme essentielle pour compenser partiellement la faiblesse de l’impôt sur les sociétés payé par ces groupes.

Dépenses publiques de logiciels

Le rapport estime à au moins 1,5 milliard d’euros par an les achats de logiciels des administrations françaises auprès d’entreprises américaines.

Sur le périmètre strict de l’État :

• les dépenses de logiciels atteignent environ 361 millions d’euros
• 268 millions, soit 74 %, bénéficient à des acteurs extra-européens.

Parmi les principaux achats de 2025 :

• Microsoft : 115 millions d’euros pour les seules administrations d’État
• VMware : 34,1 millions
• Oracle : 23,1 millions
• Red Hat : 17,1 millions
• IBM : 12,6 millions

Le rapport estime qu’environ un milliard d’euros de dépenses publiques concerne des logiciels pour lesquels des solutions de substitution, notamment open source, ont été identifiées : Linux, LibreOffice, PostgreSQL, OpenStack, Proxmox ou Kubernetes.

Les dépenses évitées par la Gendarmerie nationale sont estimées à 534 millions d’euros cumulés depuis 2004.

Inflation des licences

Entre 2024 et 2025, les dépenses réalisées auprès de plusieurs éditeurs ont fortement augmenté :

• Microsoft : +26 %
• VMware : +113 %
• Red Hat : +90 %
• Salesforce : +138 %

Certaines organisations ont rapporté des augmentations pouvant aller jusqu’à 800 % pour VMware après son rachat par Broadcom.

Le rapport considère que ces augmentations illustrent le pouvoir acquis par les fournisseurs une fois leurs produits devenus indispensables.

4. Les atteintes aux droits et aux données personnelles

Hébergement aux États-Unis

Les données européennes hébergées ou traitées par des entreprises américaines restent exposées aux lois américaines.

Le rapport considère également que les fondements juridiques du Data Privacy Framework, utilisés pour permettre certains transferts de données vers les États-Unis, sont désormais gravement fragilisés et demande à la Commission européenne de l’annuler.

Captation de l’attention

Le modèle économique des grandes plateformes repose sur :

• la collecte massive de données
• le suivi des utilisateurs
• la publicité ciblée
• la personnalisation des contenus
• l’augmentation du temps passé en ligne

Cette collecte permet de créer des profils extrêmement détaillés et peut favoriser les comportements addictifs, les discriminations et la manipulation de l’information.

Violations du RGPD

Les violations concernent notamment :

• les cookies déposés sans consentement
• les interfaces rendant le refus plus difficile que l’acceptation
• les transferts illicites de données
• les paramètres trop permissifs pour les mineurs
• les interfaces truquées, ou dark patterns en anglais, conçues pour influencer le choix des utilisateurs.

Depuis 2019, la CNIL a prononcé 953 millions d’euros d’amendes sur le fondement de la directive ePrivacy. Sur ce total, 903 millions concernent les plus grandes plateformes étrangères.

Données utilisées pour l’IA

Les grandes plateformes réutilisent des contenus, des historiques de navigation, des données de localisation et des publications publiques pour entraîner leurs modèles d’IA.

Le rapport parle d’une forme de colonialisme des données : les entreprises captent des connaissances financées par l’argent public ou produites bénévolement, sans rémunération ni contribution équivalente aux communs.

Courtiers en données

Les courtiers en données, ou data brokers, collectent et revendent des données provenant :

• des cartes de fidélité
• des applications mobiles
• de la navigation
• des enchères publicitaires
• de la géolocalisation

Même présentées comme anonymes, ces données permettent souvent de réidentifier une personne et de déduire ses opinions, sa religion, sa santé ou son orientation sexuelle.

Application inégale du RGPD

Le système européen du guichet unique donne à l’autorité du pays où se situe le siège européen d’une entreprise la responsabilité principale du dossier.

Comme de nombreuses plateformes sont installées en Irlande, l’autorité irlandaise concentre les procédures. Le rapport critique sa lenteur et le faible recouvrement des sanctions : seulement 0,6 % des amendes prononcées entre 2020 et 2024 auraient effectivement été recouvrées.

La rapporteure propose de confier directement au Comité européen de la protection des données le contrôle des plus grandes plateformes transfrontalières.

5. Espionnage, sanctions et coupure des services

Accès aux données par des puissances étrangères

Le FISA et le Cloud Act peuvent obliger les entreprises américaines à transmettre des informations aux autorités, même lorsque les données sont hébergées en Europe.

Les rapports de transparence cités par la commission font état de milliers de demandes gouvernementales américaines, dont 5 587 adressées à Microsoft et environ 60 000 à Google sur les périodes étudiées.

Le rapport conclut que la véritable protection contre les lois extraterritoriales suppose que le fournisseur soit exclusivement soumis au droit européen.

Le cas du juge Nicolas Guillou

Sanctionné par les États-Unis en raison de ses fonctions à la Cour pénale internationale, le juge aurait perdu l’accès à plusieurs services :

• Apple et iCloud
• Google
• Amazon
• PayPal
• certains moyens de paiement et assurances

Ce cas montre qu’une décision politique américaine peut provoquer, sans procédure européenne, une exclusion numérique et financière presque immédiate.

Risque de « kill switch »

Le rapport envisage une coupure générale ou ciblée des services américains en Europe :

• arrêt des logiciels et applications
• interruption du cloud
• perte d’accès aux données
• arrêt du support et des mises à jour
• perturbation des messageries et réseaux sociaux
• difficultés de paiement avec Visa ou Mastercard

Même un logiciel installé localement resterait vulnérable si les mises à jour de sécurité et le support étaient interrompus.

Troisième partie : Pourquoi ces dépendances persistent

6. Une régulation toujours en retard

Les GAFAM contrôlent plusieurs couches à la fois :

• infrastructures
• cloud
• systèmes d’exploitation
• navigateurs
• applications
• boutiques d’applications
• publicité
• données

Cette intégration verticale et horizontale leur permet de favoriser leurs propres produits et de rendre les concurrents dépendants de leurs infrastructures.

Depuis 2010, les procédures européennes de concurrence ont conduit à environ 17,2 milliards d’euros d’amendes. Mais elles interviennent souvent plusieurs années après les pratiques contestées.

Le DMA cherche à agir en amont en imposant :

• l’interopérabilité
• la portabilité
• l’interdiction de favoriser ses propres services
• des limites aux ventes groupées
• la possibilité de désinstaller les applications imposées

7. Le récit selon lequel il n’existerait aucune alternative

Le rapport considère que l’absence d’alternative est en grande partie un narratif de résignation.

Des acteurs comme OVHcloud, Scaleway, Outscale ou Cloud Temple peuvent déjà répondre à de nombreux besoins avec des performances et des prix compétitifs.
Le rapport ne le mentionne pas, mais je me permets d’ajouter Clever Cloud à cette liste

Cabinets de conseil et centrales d’achat

Les cabinets de conseil et les grandes ESN recommandent fréquemment Microsoft, AWS ou Google, avec lesquels ils entretiennent des partenariats.

Capgemini et Sopra Steria auraient ainsi reçu, à elles deux, un montant de crédit d’impôt recherche cinquante fois supérieur à celui reçu par Mistral AI en 2025.

L’UGAP (Union des Groupements d’Achats Publics) joue aussi un rôle déterminant. Le rapport lui reproche cependant une méthodologie pouvant conduire à qualifier de françaises des solutions américaines selon la structure juridique de leur distributeur : une forme de sovereignty washing. Pour comprendre la définition de ce dernier terme, je vais me permettre de reprendre l’explication du média Synth, c’est-à-dire : de se donner des airs de champion de la souveraineté numérique, tout en laissant filer, derrière le rideau, une bonne partie de l’indépendance promise.

Dépendance construite dès l’école

L’utilisation de Microsoft à l’école et à l’université crée des habitudes durables chez les élèves, enseignants, informaticiens et futurs décideurs.

En 2025, l’Éducation nationale a renouvelé pour quatre ans un accord Microsoft pouvant atteindre 152 millions d’euros.

Health Data Hub

Le choix initial de Microsoft Azure pour la Plateforme des données de santé est présenté comme un exemple d’enfermement technologique et de dépendance aux cabinets de conseil.

La migration engagée vers un opérateur français montre néanmoins qu’une alternative souveraine était techniquement possible.

8. Un État qui a perdu des compétences

Les taux d’externalisation informatique varient de 10 à 80 % selon les ministères et les fonctions considérées.

Le rapport considère qu’au-delà de 60 %, la situation devient risquée et qu’au-delà de 80 %, elle devient pratiquement impossible à maîtriser.

Exemples :

• les ministères sociaux externalisent environ 97 % du développement
• le ministère de la Justice dispose de moins de vingt développeurs internes et dépense environ 200 millions d’euros par an en prestations informatiques, soit l’équivalent de 1 500 emplois à temps plein.

Cette externalisation transforme l’administration en acheteur de produits plutôt qu’en concepteur de ses propres systèmes.

La DINUM développe pourtant des solutions mutualisées :

• Tchap
• Visio
• FranceTransfert
• Messagerie
• Fichiers
• Docs
• Grist
• Albert

Ces outils commencent à remplacer Zoom, Webex ou Teams, mais leur généralisation reste incomplète.

9. Le poids du lobbying

En 2025, dix grandes entreprises numériques auraient dépensé 49 millions d’euros en lobbying européen, dont 35 millions pour les seuls GAFAM.

Elles mobiliseraient environ 210 lobbyistes et organiseraient en moyenne plus d’une rencontre par jour ouvré avec la Commission européenne.

Le rapport critique fortement le projet d’omnibus numérique, présenté comme une simplification mais qui pourrait :

• sortir certaines données pseudonymisées du RGPD
• élargir les possibilités d’utiliser les données pour l’IA
• affaiblir les droits d’opposition et d’effacement
• transférer la régulation des cookies de la CNIL vers les autorités des pays où les plateformes ont leur siège
• faciliter l’exploitation des données par les entreprises disposant déjà des plus grandes bases

La commission demande à la France de s’opposer à tout affaiblissement du RGPD.

10. Le financement des entreprises européennes

Les entreprises américaines bénéficient de trois avantages majeurs :

• une commande publique massive, notamment militaire
• un marché intérieur homogène de plus de 300 millions de consommateurs
• un capital-risque capable de financer des entreprises pendant leur croissance.

L’Europe dispose d’un marché plus fragmenté et finance difficilement les entreprises lorsqu’elles doivent passer à grande échelle.

Conséquence : des entreprises françaises soutenues par l’argent public sont ensuite :

• rachetées par des groupes étrangers
• cotées aux États-Unis
• déplacées hors de France

Le rapport estime que les aides publiques sont assorties de trop peu de contreparties et ne protègent pas suffisamment les entreprises stratégiques contre les rachats extra-européens.

11. Les risques liés à l’intelligence artificielle

Risque économique et financier

Les investissements dans l’IA et les centres de données augmentent très rapidement, alors que la rentabilité reste incertaine.

Le rapport cite une étude du MIT, fondée sur des entretiens avec des représentants d’entreprises, selon laquelle 95 % des entreprises ayant investi dans l’IA générative ne constataient aucun retour sur investissement.

Il identifie également une circularité : les mêmes groupes sont à la fois investisseurs, clients, fournisseurs de puces et financeurs, ce qui pourrait gonfler artificiellement les valorisations.

Emploi

Les effets restent incertains et varient selon les métiers.

Les professions les plus exposées seraient notamment :

• les fonctions administratives
• l’informatique
• l’ingénierie
• la finance
• le droit
• la rédaction et certaines activités créatives

Les métiers physiques, les soins, la restauration et le nettoyage sont moins facilement automatisables.

Cybersécurité et IA agentique

Les agents autonomes nécessitent un accès très large aux données et peuvent agir directement dans les systèmes.

Ils créent donc des risques :

• de fuite de données
• d’action non contrôlée
• de décisions discriminatoires
• d’attaques automatisées
• de découverte massive de vulnérabilités avant leur correction

Vulnérabilités sociales et culturelles

L’IA peut renforcer :

• le management algorithmique
• la surveillance des salariés
• la précarisation
• les inégalités touchant notamment les jeunes et les femmes
• la dépendance culturelle envers des modèles américains ou chinois

Elle pose également la question du droit d’auteur et de l’utilisation sans autorisation des productions journalistiques, scientifiques et artistiques.

12. Les centres de données

Faibles retombées locales

Les centres de données créent des emplois lors de leur construction, mais relativement peu pendant leur exploitation : quelques dizaines d’emplois pour un site de 100 MW.

La présence physique d’un centre de données en France ne garantit donc :

• ni que l’entreprise soit française
• ni que la valeur reste en France
• ni que les données échappent au droit américain

Captation de l’électricité

Près de 15 GW de capacité de raccordement auraient été réservés, soit environ 24 % de la puissance installée du parc nucléaire français.

Seulement 9 % de ces capacités seraient réservées par des acteurs français ou européens spécialisés.

La consommation des centres de données pourrait atteindre :

• 21 à 32 TWh en 2035
• environ 50 TWh en 2050

Environnement

Les risques concernent :

• la consommation d’électricité
• l’utilisation d’eau
• l’artificialisation des sols
• les groupes électrogènes de secours
• les fluides frigorigènes
• les îlots de chaleur

Politique gouvernementale

Environ 95 milliards d’euros d’investissements dans les centres de données ont été annoncés en 2025, majoritairement via des capitaux étrangers.

Le rapport reproche au gouvernement de faciliter tous les projets sans les hiérarchiser selon :

• la nationalité de l’opérateur
• l’utilité publique
• la destination de la capacité de calcul
• les retombées économiques
• la souveraineté réelle du projet

Quatrième partie : Le modèle proposé

13. Les alternatives existent

Logiciel libre et open source

Le libre réduit :

• le verrouillage propriétaire
• les redevances de licence
• la dépendance à un fournisseur unique
• l’impossibilité d’auditer le code

La filière open source française représentait, selon l’étude citée :

• 5,9 milliards d’euros
• 11 % du marché numérique
• environ 63 800 emplois en équivalents temps plein.

Sa faiblesse principale est le financement de la maintenance. Des briques utilisées dans le monde entier reposent parfois sur quelques développeurs bénévoles.

Standards ouverts

L’interopérabilité permet de changer de fournisseur tout en continuant à communiquer avec les utilisateurs restés sur l’ancien système.

Mastodon et Tchap sont cités comme exemples d’architectures fédérées : plusieurs serveurs indépendants communiquent grâce à des protocoles communs.

Le rapport considère que la puissance publique doit reprendre la maîtrise de la définition des standards, des protocoles et des API.

IA frugale et ouverte

Une IA frugale doit :

• être utilisée seulement lorsqu’elle apporte une utilité réelle
• réduire ses besoins matériels et énergétiques
• mesurer son impact
• être comparée à des solutions moins consommatrices

Le rapport met également en garde contre l’open washing : certains modèles se présentent comme ouverts alors que leurs données d’entraînement, leur code ou leur méthode ne sont pas réellement accessibles.

14. Les principales propositions

Le rapport complet comporte 29 propositions et 18 recommandations. La synthèse met notamment en avant les mesures suivantes.

Faire du libre le pilier de la politique numérique

• créer une fondation France libre open source
• créer un fonds de financement des communs numériques
• rendre les marchés publics de l’État 100 % open source à partir de 2030
• permettre aux agents publics de consacrer une journée par an aux communs
• renforcer les équipes numériques internes
• instaurer un crédit d’impôt open source pour les PME

Protéger les entreprises stratégiques

• exiger le remboursement de certaines aides publiques en cas de vente à un acteur extra-européen
• permettre à l’État de conserver un pouvoir de contrôle sur certaines décisions stratégiques de Mistral AI et de ChapsVision, notamment en cas de vente à un acteur étranger
• intégrer une clause de souveraineté finale dans les marchés publics et les financements
• créer un établissement bancaire public protégé de l’extraterritorialité américaine.

Encadrer les data centers

• instaurer un moratoire sur les projets profitant aux acteurs extra-européens
• créer un cadre permettant de privilégier les projets servant l’intérêt national
• envisager une structure publique d’investissement

Réduire le pouvoir des plateformes

• viser le « zéro Microsoft dans les écoles » et utiliser des logiciels libres pour l’apprentissage
• arrêter la communication publique sur les réseaux non interopérables, en commençant par X
• renforcer les instruments européens contre les sanctions extraterritoriales
• créer un syndicat des données
• permettre les recours collectifs au titre du RGPD
• suspendre les plateformes présentant des dangers graves

Donner une véritable direction politique

• créer un ministère du Numérique de plein exercice
• créer une délégation au numérique à l’Assemblée nationale
• faire évaluer économiquement les dépendances françaises et les conséquences d’une coupure générale des services américains

Conclusion

Cet article ne constitue, à ce stade, qu’une restitution de ma propre compréhension de la synthèse du rapport. Il ne prétend ni remplacer sa lecture intégrale, ni rendre compte de toutes les nuances du document complet. Je n’ai pas non plus souhaité donner ici mon avis sur chacune des analyses ou des propositions formulées. Certains de ces sujets ont déjà été abordés dans mes précédents articles et pourront faire l’objet de réflexions plus approfondies. Ce n’était pas l’objectif de ce texte, qui cherchait avant tout à rendre les principaux constats du rapport accessibles au plus grand nombre.

Il faut néanmoins mesurer la portée du travail accompli. Les dépendances numériques de la France ne sont plus seulement évoquées à partir d’intuitions, de témoignages isolés ou de rumeurs difficiles à vérifier. Elles ont désormais fait l’objet d’une longue enquête parlementaire, nourrie par de nombreuses auditions, des contributions écrites, des questionnaires adressés aux administrations et l’analyse de données économiques, techniques et institutionnelles.

Une commission d’enquête parlementaire n’est pas une étude académique au sens strict. Elle constitue toutefois un travail officiel, documenté et contradictoire, réalisé sous le contrôle de l’Assemblée nationale et engageant la responsabilité de ses auteurs. Ses constats peuvent être discutés, certaines estimations peuvent être précisées et certaines propositions contestées. Mais ils ne peuvent plus être écartés comme de simples fabulations ou comme le discours alarmiste de quelques personnes préoccupées par la souveraineté numérique.

Ce rapport oblige désormais les responsables politiques, les administrations, les entreprises et les citoyens à prendre le sujet au sérieux. Le débat ne porte plus sur l’existence de ces dépendances, mais sur ce que nous sommes collectivement prêts à faire pour les comprendre, les réduire et retrouver une véritable capacité de choix.

L’article Rapport de la commission d’enquête sur nos vulnérabilités et dépendances numériques : jusqu’où la France dépend-elle des géants technologiques ? est apparu en premier sur Souverain.

L’OW2con’26 m’avait déjà permis de mesurer à quel point l’open source européen ne se résume pas à une affaire de spécialistes. Il y avait des développeurs, des entreprises, des acteurs publics, des communautés, mais aussi une question qui revenait sans cesse : comment faire sortir ces sujets des cercles techniques pour les rendre compréhensibles, désirables et utiles au plus grand nombre ?

Quelques jours plus tard, la soirée À la French a prolongé cette impression. Dans un autre cadre, avec une autre énergie, mais avec cette même idée : quelque chose se passe autour de la souveraineté numérique. Les discussions deviennent plus concrètes. Les personnes se parlent. Les mondes se croisent.

Parmi toutes ces rencontres, quatre m’ont particulièrement marqué.
Il y a d’abord eu Virgile Deville, responsable produit autour de Docs de LaSuite numérique portée par la DINUM. Puis Sylvain Zimmer, également à la DINUM, engagé notamment sur La Suite territoriale pour l’ANCT, et à l’origine du projet MaSuite.fr.

Il y a eu aussi Thierry Lelégard, architecte sécurité chez SiPearl, qui a eu la gentillesse de répondre à mes premières questions lors de cette soirée, puis d’accepter un entretien de plus d’une heure et demie autour de SiPearl, des processeurs et de la souveraineté numérique.

Ce soir-là, Thierry Lelégard n’était pas venu les mains vides. Il avait avec lui le premier modèle de processeur produit par SiPearl : Rhea1. Voir cet objet, même sans être ingénieur, avait quelque chose de très concret. La souveraineté numérique, d’un coup, ne se limitait plus à un mot, une doctrine, une intention politique ou un débat d’experts. Elle tenait aussi dans une puce.

Et puis il y a eu une autre rencontre, le temps d’un week-end : Markus Feilner.

Markus est un spécialiste allemand de Linux et des logiciels libres, mais il est avant tout correspondant européen pour la souveraineté numérique. Il travaille dans l’écosystème open source depuis 1994. Il a été consultant IT, responsable documentation chez SUSE, journaliste technique, notamment comme rédacteur en chef adjoint pour Linux-Magazin et Heise iX. Depuis 2000, il dirige aussi Feilner IT, une structure de conseil spécialisée dans les stratégies open source, la documentation, la formation et l’accompagnement des organisations.

Il intervient régulièrement comme auteur, conférencier, animateur et analyste sur les enjeux du logiciel libre, de la souveraineté technologique et de la transformation numérique. Il est également associé à grommunio, où il est présenté comme ambassadeur open source, avec un travail centré sur les alternatives libres aux solutions collaboratives propriétaires.

Nous avons beaucoup discuté pendant ce week-end. Vraiment beaucoup. Nous avons voulu refaire le monde, comme cela arrive parfois quand deux personnes partagent une inquiétude, une curiosité et une certaine impatience. Nous avons surtout essayé de comprendre pourquoi l’open source et la souveraineté numérique ne pouvaient plus se contenter d’exister dans les discours.

Notre conclusion provisoire tenait en une idée : les débats techniques entre experts restent indispensables, mais ils ne suffisent plus. Une autre étape s’ouvre, celle du récit. Celle de la capacité à fédérer au-delà des communautés déjà convaincues. Expliquer encore, vulgariser davantage, démontrer concrètement, raconter les réussites, faire comprendre que ces sujets ne concernent pas seulement les développeurs, les DSI ou les administrations, mais aussi les citoyens.

Nous avions cette impression étrange que le moment n’était plus seulement à la réflexion, mais au passage à l’acte. Une brèche s’était ouverte. Il fallait la saisir MAINTENANT ou, pour le dire avec un peu moins de solennité : à force d’attendre le moment parfait, on finit souvent par regarder les autres écrire l’histoire à notre place.

Une amitié est née. Les jours et les semaines qui ont suivi, nos échanges ont continué. Presque quotidiennement. Une forme d’ébullition intellectuelle qui ne s’est pas vraiment interrompue depuis.

Et pour en revenir à SiPearl, j’ai envoyé un courriel à Thierry Lelégard pour lui demander un entretien. Il a répondu favorablement presque immédiatement. J’ai prévenu Markus. Nous étions excités comme des gosses. Ce sujet nous attirait d’autant plus qu’il touchait à une partie de la souveraineté numérique que nous connaissions moins. Les processeurs, les semi-conducteurs, les outils de conception, les fonderies, les chaînes industrielles mondiales : tout le monde sait que c’est important, voire vital. Mais ces sujets restent souvent abordés sous la forme d’un slogan : il faut y penser ; il faut le faire ; il faut rattraper notre retard. On en parle beaucoup moins dans le détail. On les comprend encore moins.

J’ai alors proposé à Markus de m’envoyer trois questions que je poserais à Thierry Lelégard. Markus et moi n’avons pas exactement la même façon de voir les choses, ni le même parcours, ni le même regard. Lui regarde ces sujets depuis l’Allemagne. Moi depuis la France. Bien loin d’être un obstacle, cette disparité nous nourrit au contraire mutuellement : elle évite de réduire la souveraineté numérique à un réflexe national, et oblige à regarder le sujet à l’échelle où il se joue vraiment, celle de l’Europe.

Ses trois questions étaient les suivantes :

1. Quel est le rôle de l’Allemagne dans ce contexte et quel impact peut-on attendre, ou espérer ?
2. Comment percevez-vous l’Allemagne ? Sommes-nous suffisamment agiles ? Devrions-nous, pourrions-nous, en faire davantage ? L’Allemagne a longtemps été à la pointe de certaines technologies liées aux puces électroniques et à la robotique.
   L’est-elle encore ? Peut-elle redevenir un leader ? Que faudrait-il faire ?
3. Quels sont les points cruciaux à prendre en compte dans une telle alliance, notamment en matière de langue et de culture ? Peut-on comparer ce projet à un « Airbus de l’informatique » ou des puces électroniques ? Y a-t-il des enseignements à tirer de cette comparaison, notamment entre la France et l’Allemagne ?

J’ai posé ces questions à ma manière. Je ne suis ni journaliste, ni ingénieur, ni technicien, et encore moins du sérail. J’avance avec mes mots, mes angles morts et mes efforts de compréhension.

Avant d’entrer dans le détail de l’entretien avec Thierry Lelégard, il faut aussi raconter comment cette rencontre a été rendue possible. C’est grâce à Steeve Morin : entrepreneur et ingénieur logiciel basé à Paris. Il est fondateur et CEO de ZML, une entreprise qui développe une technologie d’inférence IA de nouvelle génération, pensée pour améliorer les performances des modèles sur différents types de puces et d’infrastructures matérielles.

Avant ZML, il a notamment été Vice-président chargé de l’ingénierie chez Zenly, l’application française de géolocalisation rachetée par Snap, où il a piloté des équipes techniques à grande échelle. Son parcours l’associe aussi à des projets comme boot2docker et LegiGPT.

Aujourd’hui, il intervient régulièrement dans les débats sur l’IA, le matériel informatique (le hardware), l’open source et les infrastructures numériques, notamment dans le podcast À la French, aux côtés de Jean-Baptiste Kempf et Mehdi Medjaoui.
Sans cette mise en relation, cet entretien n’aurait probablement pas eu lieu. Il mérite donc d’être remercié dès le début de ce récit.

Le rendez-vous est pris. Le jour de l’entretien arrive. Et bien sûr, cela ne va pas tout à fait se passer comme prévu.

Comme souvent désormais, j’utilise Visio / Meet, l’outil de visioconférence de LaSuite numérique, installé sur mon propre serveur via le paquet YunoHost. Je suis connecté à l’heure. Thierry aussi. Sauf que la visioconférence ne fonctionne pas. Je le vois connecté, mais pas de son, pas d’image. De son côté, même problème.

C’était la première fois que Visio échouait ainsi chez moi. D’habitude, j’ai plutôt droit à l’effet « waouh » et j’en suis généralement assez fier. Installer une solution souveraine, l’héberger soi-même, inviter quelqu’un dessus et voir que tout fonctionne : c’est exactement le genre de petit moment qui donne envie de continuer à tester, installer, documenter.

Cette fois, l’effet waouh a pris une autre tournure.

Après l’entretien, j’ai cherché à comprendre ce qui s’était passé. Il semble que tous les ports nécessaires n’étaient pas suffisamment ouverts pour garantir le bon fonctionnement de LiveKit et de la partie WebRTC dans tous les cas. C’est désormais corrigé. J’ai aussi créé un ticket du paquet Meet de LaSuite afin de demander aux mainteneurs d’ajouter cette information pour les prochains utilisateurs qui souhaiteraient tester ou déployer cette solution.

Bref, première leçon très concrète de souveraineté numérique : nous avons dû passer sur Microsoft Teams.

Je dois reconnaître que cela ne m’a pas fait plaisir. Non par posture. Simplement parce que le but d’une solution alternative est justement d’éviter que la technique devienne une perte de temps pour l’interlocuteur. Dans ce cas précis, ce qui a manqué, ce n’est pas forcément la qualité du projet, mais une documentation suffisamment explicite pour éviter ce type de blocage.

La prochaine fois, normalement, je serai prêt.

Ce petit incident nous a conduits directement au cœur du sujet. Thierry m’a fait remarquer, à juste titre, que la force de Microsoft repose aussi sur l’expérience accumulée, le nombre immense d’utilisateurs et la remontée continue des problèmes à chaque lancement de solution. Les bugs existent partout. La différence se joue souvent dans la capacité à les détecter, les documenter et les corriger rapidement.

Dans l’open source, ce mécanisme existe aussi. Il ne fonctionne pas toujours de la même manière, ni avec les mêmes moyens. Tout dépend du projet, de la communauté, de l’équipe, de la maturité de l’écosystème. Dans certains cas, comme j’ai pu le tester avec grommunio, des corrections peuvent arriver très vite, parfois dans la journée. Dans d’autres cas, le chemin est plus lent, plus artisanal, plus dépendant des retours d’utilisateurs.

C’est aussi cela, la souveraineté numérique : accepter que l’indépendance ne soit pas seulement un idéal, mais une pratique. Elle implique des essais, des erreurs, de la documentation, de la patience, des retours, des corrections et parfois quelques visioconférences qui se terminent sur Teams alors que l’on aurait préféré faire la démonstration inverse.

Une phrase m’a travaillé

Nous sommes ensuite revenus à SiPearl : lors de notre premier échange, pendant la soirée À la French, Thierry Lelégard m’avait déjà dit quelque chose qui m’avait interpellé : un projet comme SiPearl ne peut pas se faire en autarcie totale. Selon lui, il faut au moins trois continents pour concrétiser un tel projet.

Elle venait d’un professionnel du sujet, quelqu’un qui connaît intimement les enjeux de sécurité, de processeurs, de souveraineté et de chaînes industrielles. Je pouvais difficilement balayer cette remarque d’un revers de main. En revanche, elle venait toucher certaines de mes croyances. J’avais tendance à penser que l’autonomie stratégique consistait à tout refaire chez nous, sans dépendre d’autres continents.

Factuellement, ce n’est pas le cas.

Thierry m’a alors aidé à déplacer la question. La souveraineté ne signifie pas nécessairement tout produire seul, dans un coin, en fermant les portes. Elle peut aussi signifier connaître la chaîne, maîtriser les choix critiques, réduire les dépendances les plus dangereuses, organiser les interdépendances et éviter qu’un acteur extérieur puisse décider seul de notre capacité à calculer, simuler, sécuriser ou innover. Pour vulgariser, il m’a donné une image : celle d’une coopérative.
Dans une coopérative agricole, les machines peuvent être partagées. Les agriculteurs gardent leur autonomie, mais ils mutualisent certains équipements, certains savoir-faire, certains investissements. Dans les processeurs et les puces, on retrouve une logique comparable, à une autre échelle : des acteurs différents, situés dans plusieurs pays, participent à une chaîne de valeur commune.

Mais quel est le rapport avec un processeur européen ?

La fabrication d’un processeur de très haut niveau repose sur plusieurs couches. Il y a d’abord ASML, entreprise néerlandaise qui fabrique les machines de lithographie et de photolithographie les plus avancées, indispensables à la production des puces les plus complexes. Ces machines sont ensuite utilisées par des fondeurs comme TSMC à Taïwan.

Taïwan n’est pas devenu central par hasard. Le pays a accumulé près d’un demi-siècle d’expérience industrielle dans les semi-conducteurs, depuis les premières lignes de circuits intégrés à la fin des années 1970 jusqu’à la maîtrise actuelle des procédés les plus avancés. Cette expérience ne s’improvise pas. Elle ne se copie pas en quelques mois. Elle repose sur des générations d’ingénieurs, d’usines, de fournisseurs, d’habitudes industrielles, de formation, de culture de production.

Bien sûr, les coûts jouent aussi. Produire à Taïwan peut être moins coûteux que produire en Europe ou aux États-Unis. Néanmoins, focaliser le débat uniquement sur le coût serait une erreur. La vraie difficulté tient à la profondeur de l’écosystème. Dans ce domaine, l’expérience industrielle compte autant que l’investissement financier.

Et l’investissement financier, lui aussi, donne le vertige : pour obtenir les dernières technologies, la construction d’une usine de semi-conducteurs avancés, dépasse souvent les 20 milliards de dollars. Comme vous l’imaginez, ce n’est pas une ligne budgétaire que l’on ajoute entre deux réunions.

Les États-Unis eux-mêmes en ont fait l’expérience avec TSMC en Arizona. Le projet initial, annoncé en 2020, prévoyait 12 milliards de dollars d’investissement. Il a ensuite été intégré à un mouvement beaucoup plus large de relocalisation industrielle américaine. Mais les difficultés ont été nombreuses : manque de main-d’œuvre qualifiée, retards, coûts plus élevés, tensions avec les syndicats, besoin de faire venir des experts taïwanais pour installer les équipements et former les équipes locales.

Il y a même eu des tensions autour des visas et du recours à des spécialistes venus de Taïwan pour des opérations sans équivalent local. En 2024, environ 2 200 personnes travaillaient sur le site, dont une part très importante venait de Taïwan. Selon certaines estimations, près de la moitié des effectifs étaient alors déployés depuis l’île.

Autrement dit, même les États-Unis, avec leur puissance financière, politique et technologique, ne reconstituent pas en quelques années ce que Taïwan a mis des décennies à bâtir.

Ce constat ne signifie pas que l’Europe devrait renoncer. Il signifie plutôt qu’elle doit avancer par étapes. Comprendre la chaîne. Maîtriser certaines briques. Réduire les dépendances les plus sensibles. Accumuler de l’expérience. Et éviter de confondre souveraineté numérique et fantasme d’autarcie.

Une autre couche de cette chaîne se trouve aux États-Unis : les outils de conception électronique, souvent appelés EDA, pour Electronic Design Automation.
Ces logiciels servent à concevoir, vérifier et analyser des systèmes électroniques complexes : circuits intégrés, cartes électroniques, assemblages, puces, interconnexions. Ils sont utilisés dans les semi-conducteurs, l’automobile, l’aéronautique, les télécommunications, l’électronique grand public. Sans ces outils, concevoir un processeur moderne devient totalement impossible.

Là encore, le marché est dominé par un petit nombre d’acteurs : Cadence Design Systems, Synopsys et Mentor Graphics, devenu Siemens EDA après son rachat par l’allemand Siemens en 2016. La nuance est intéressante, mais elle doit être prise avec précaution. Sur le plan économique, Mentor Graphics appartient bien à un groupe allemand. Mais sur le plan de la souveraineté, l’histoire est moins évidente. L’entreprise reste profondément liée à son ancrage américain, à ses équipes, à ses technologies, à son environnement juridique et à l’écosystème industriel dans lequel elle s’est développée.

Ces questions sont complexes, car la notion de souveraineté ne se limite pas uniquement à la nationalité d’un actionnaire. Elle se joue dans un mélange de liens économiques, de dépendances techniques, de droit applicable, de localisation des compétences et de rapports de force. En cas de conflit ou de tension géopolitique, ce sont souvent ces rapports de force qui finissent par peser le plus lourd.

L’exemple récent des restrictions américaines sur les outils EDA à destination de la Chine le montre bien : même Siemens EDA, pourtant rattaché à un groupe allemand, a été concerné par les décisions américaines sur les logiciels de conception de puces. Autrement dit, le rachat de Mentor Graphics par Siemens apporte bien une dimension européenne. Mais il ne suffit pas, à lui seul, à faire disparaître les dépendances américaines qui structurent encore une partie de cette industrie.

Cette dépendance logicielle est moins visible que les usines ou les machines ASML. Elle est pourtant essentielle. Même dans le domaine du matériel, le logiciel revient toujours par la fenêtre. Concevoir une puce, ce n’est pas seulement dessiner un objet physique. C’est manipuler des couches de modélisation, de simulation, de validation, de vérification, avec des outils extrêmement matures.

L’open source existe déjà dans ce domaine, avec des projets comme OpenROAD, LibreLane (anciennement OpenLane), Yosys, Magic ou KLayout. Ces outils sont importants, car ils démocratisent une partie de la conception de puces, permettent d’apprendre, de prototyper et de travailler sur des circuits plus accessibles. Mais nous ne sommes pas dans la même situation que dans le logiciel classique, où l’open source a fini par produire des références industrielles majeures.
Dans le domaine de l’EDA, les outils ouverts restent encore très en retrait pour les usages industriels les plus avancés. Ils sont surtout adaptés à des circuits plus modestes ou à des procédés de fabrication plus matures, justement ceux que l’on sait déjà mieux produire dans des usines européennes.

Le saut vers les processeurs de très haute performance est d’une autre nature. Il suppose des années de développement, de maintenance, de validation, et pour les processeurs les plus avancés, les flux industriels restent encore très largement adossés aux grands outils propriétaires de l’EDA. Notamment Cadence, Synopsys et Siemens EDA, parce que l’accès aux PDK des fondeurs, c’est-à-dire aux kits techniques qui décrivent précisément les règles de fabrication d’une puce pour une usine donnée (pour Process Design Kit, soit l’ensemble des informations techniques permettant de dessiner et de fournir des circuits viables sur le process choisi, avec les caractéristiques des couches, les largeurs, épaisseurs et espacements permis. Ces informations dépendent de chaque usine/fondeur), la vérification, le sign-off, autrement dit la validation finale avant fabrication : une série de contrôles qui permet de s’assurer que le dessin de la puce respecte bien les contraintes industrielles du fondeur, qu’il correspond au schéma prévu, qu’il pourra être produit correctement et qu’il a de bonnes chances de fonctionner une fois sorti de l’usine. La validation industrielle reste une des étapes extrêmement critique.
Cela ne veut pas dire que la situation restera figée et que l’open source n’a pas sa place dans cette industrie. Mais si l’Europe veut avancer rapidement sur les processeurs de très haute performance, elle doit composer, dans un premier temps, avec cette réalité.

Cette coopérative mondiale fonctionne donc avec des acteurs européens, taïwanais, américains, parfois japonais ou coréens. Elle repose sur des interdépendances. Ces interdépendances ne sont pas toujours confortables, mais elles structurent aujourd’hui l’industrie mondiale des semi-conducteurs.

Il existe pourtant un contre-exemple majeur : la Chine.

Les Chinois ont été progressivement écartés de certaines technologies, notamment par les restrictions américaines sur les semi-conducteurs avancés, les équipements de production et les outils de conception. Ce qui était d’abord une stratégie de rattrapage est devenu, pour Pékin, une stratégie de survie industrielle.

C’est ce qui rend le cas chinois intéressant. La Chine ne s’est pas lancée dans une forme d’autarcie par simple préférence idéologique. Elle y a été poussée par la pression américaine. Les sanctions ont accéléré une volonté d’autosuffisance. Comme le résumait La Tribune dans un titre très parlant : Semi-conducteurs : malgré les sanctions, la Chine tient le cap et rêve d’autosuffisance.

Le sujet est passionnant, mais le temps de Thierry est compté. Je dois donc revenir au déroulé de mes questions.

Si ce monde fonctionne comme une grande coopérative internationale, pourquoi SiPearl ? D’ailleurs, c’est quoi SiPearl ? Et comment cette entreprise a-t-elle réussi à aller aussi vite sur un sujet aussi complexe ?

SiPearl est une société française de semi-conducteurs qui conçoit des microprocesseurs européens pour les supercalculateurs, l’intelligence artificielle, les centres de données et, désormais, certains usages de défense et de sécurité. Son produit central est Rhea1, un processeur conçu en Europe, fondé sur l’architecture Arm, destiné à équiper des machines de calcul très puissantes comme le supercalculateur européen JUPITER.

SiPearl ne fabrique pas elle-même ses puces. Elle les conçoit, puis les fait produire par TSMC à Taïwan. L’idée est assez simple à comprendre, même si sa réalisation est extrêmement complexe : aujourd’hui, une grande partie de la puissance de calcul mondiale dépend de technologies américaines ou asiatiques. SiPearl cherche à donner à l’Europe une brique critique qui lui manque : un processeur généraliste de très haute performance. Celui qui pilote les calculs, dialogue avec la mémoire, les accélérateurs IA, les GPU et fait tourner les grands codes scientifiques ou industriels.

Concrètement, SiPearl développe des CPU. En quelque sorte, des intelligences transversales, destinés dans un premier temps, aux serveurs de calcul. Son premier grand processeur, Rhea1, contient 80 cœurs Arm Neoverse V1, de la mémoire très rapide HBM, des interfaces DDR5 et de nombreuses lignes PCIe Gen5 pour dialoguer avec des accélérateurs, notamment des GPU.

Pour les caractéristiques techniques, ce sont celles affichées par SiPearl. Je ne vais pas prétendre ici être capable de dire, seul, si c’est puissant ou non. Ce serait malhonnête de ma part. En revanche, d’après les échos de Steeve Morin, et au regard des articles de presse spécialisée que j’ai pu consulter, le produit semble solide. Les retours sont très positifs. Nous n’avons visiblement pas à rougir.

La société insiste sur trois axes :

• performance,
• sobriété énergétique
• souveraineté technologique.

Il convient aussi de ne pas confondre SiPearl avec Nvidia. Cette société multinationale américaine domine surtout les GPU, devenus essentiels pour l’IA. SiPearl travaille plutôt sur le CPU souverain, destiné à s’intégrer dans des supercalculateurs hybrides, avec des GPU, des accélérateurs IA ou d’autres composants. Son ambition n’est donc pas de remplacer toute la chaîne de calcul mondiale. Elle est de rendre l’Europe moins dépendante sur une brique stratégique.

SiPearl prépare aussi Athena1, une déclinaison de Rhea1 pensée pour des usages plus sensibles : défense, aéronautique, administrations, centres de données privés, communications sécurisées, cryptographie, réseaux tactiques, cyberdéfense ou traitement local de données. Sa commercialisation est annoncée pour le second semestre 2027.

D’où vient SiPearl ?

SiPearl naît officiellement en juin 2019, sous l’impulsion de Philippe Notton, pour industrialiser les travaux issus de l’European Processor Initiative, l’EPI. Ce programme européen vise à maintenir et développer en Europe des compétences de conception de processeurs haut de gamme pour le calcul intensif.

Le lancement opérationnel de SiPearl intervient en janvier 2020, avec un financement européen Horizon 2020 de 7,4 millions d’euros. L’entreprise s’inscrit donc dès le départ dans une logique hybride : une société privée, mais née dans le sillage d’un programme européen stratégique.

C’est un point important pour comprendre SiPearl. Ce n’est pas une startup classique qui découvre ensuite un marché public. C’est une entreprise construite dès l’origine autour d’un besoin européen de souveraineté dans le calcul intensif.

Son histoire récente peut se lire en quatre étapes :

• Entre 2019 et 2020, c’est la naissance et le choix technologique. SiPearl est créée pour concrétiser le processeur européen issu de l’EPI. Elle obtient une licence stratégique Arm Neoverse V1 en 2020.
• Entre 2021 et 2023, c’est la structuration industrielle. L’entreprise ouvre un centre de recherche et développement à Barcelone, proche du Barcelona Supercomputing Center, puis réalise une levée de fonds de 90 millions d’euros.
• Entre 2023 et 2025, c’est la validation stratégique. Rhea1 est choisi pour JUPITER, premier supercalculateur exascale européen. Une nouvelle levée de fonds de 130 millions d’euros est réalisée en 2025, avec notamment l’arrivée de Cathay Venture, investisseur taïwanais.
• Entre 2026 et 2027, c’est le passage à l’industrialisation. Les communiqués de presse de SiPearl indiquent que Rhea1 a été allumé pour évaluation fonctionnelle en mai 2026, avec une sortie commerciale visée fin 2026. Athena1 doit ensuite viser les marchés défense et sécurité à partir de 2027.

Et le rôle de l’Allemagne ?

C’est maintenant le moment de revenir aux questions de Markus sur l’Allemagne.
L’une d’elles portait sur le rôle de l’Allemagne dans ce contexte. Une autre sur la comparaison possible avec Airbus.
La réponse est nuancée : l’Allemagne ne joue pas, dans SiPearl, le même rôle que dans Airbus. La comparaison a ses limites. Dans les équipes et le conseil d’administration de SiPearl, on retrouve des profils européens et internationaux : français, espagnols, italiens, suédois, britanniques, taïwanais, américains. On ne peut pas dire que le montage ressemble à celui d’Airbus, avec un équilibre franco-allemand structurant. En revanche, l’Allemagne joue un rôle majeur à travers JUPITER. Ce supercalculateur, opéré par le centre de recherche de Jülich, est l’un des grands moteurs de cette histoire. Il a contribué à donner une finalité concrète au programme European Processor Initiative : disposer d’un supercalculateur européen capable d’intégrer, au moins en partie, un processeur européen comme Rhea1.

Ce n’est donc pas un Airbus des puces au sens institutionnel et industriel classique. Mais c’est bien une aventure européenne. Une aventure où l’Allemagne occupe une place décisive par l’usage, l’infrastructure de calcul et la validation stratégique.

Reste ma question de départ, celle sur laquelle j’ai insisté : si ce système de coopérative mondiale n’est pas en soi un danger, pourquoi lancer un programme comme SiPearl ?
La réponse vient d’un constat plus large : sans processeurs, sans supercalculateurs, sans cloud, sans outils de conception et sans fonderies, l’Europe dépend d’autres puissances pour calculer, simuler, entraîner des IA, sécuriser ses infrastructures et faire tourner une partie de son économie.

L’European Processor Initiative affiche clairement sa mission : retrouver une indépendance européenne dans les technologies de processeurs pour le calcul haute performance, avec l’objectif de faire émerger une machine exascale européenne reposant sur des briques européennes.

Autrement dit, l’Europe voulait éviter de rester uniquement cliente de processeurs américains ou asiatiques pour ses supercalculateurs. Le calcul intensif sert à la météo, au climat, au nucléaire, à la défense, à l’industrie, à l’IA, aux simulations médicales ou énergétiques. Celui qui ne maîtrise pas une partie de cette chaîne dépend des choix techniques, commerciaux et politiques des autres.

La crainte du « kill switch »

Le risque n’est pas forcément une fonction secrète cachée dans une puce. Le vrai kill switch moderne peut être juridique, commercial, logiciel ou géopolitique : suspension de service, arrêt des mises à jour, coupure de licence, restriction d’exportation, accès conditionné à une infrastructure, dépendance à une maintenance étrangère.

C’est moins spectaculaire qu’un scénario de film d’espionnage, mais souvent plus réaliste.

La question des portes dérobées, elle aussi, ne relève pas seulement du fantasme. Il existe des faits documentés. Les révélations Snowden ont montré que des équipements réseau américains destinés à l’étranger avaient été interceptés et modifiés par la NSA avant livraison. Des routeurs et serveurs ont été ouverts, équipés, puis renvoyés à leurs destinataires.

L’affaire Crypto AG est un autre exemple majeur. Cette société suisse vendait des machines de chiffrement à de nombreux États. Elle était en réalité contrôlée en sous-main par la CIA et les services allemands, ce qui permettait l’écoute de communications supposées sécurisées dans plus de 120 pays. L’un des modèles, la H-460, aurait même été directement construit par la NSA.

Un autre exemple avec l’affaire Dual_EC_DRBG : un générateur de nombres aléatoires controversé. De nombreux experts ont considéré qu’il contenait une porte dérobée conçue par la NSA, et les documents Snowden ont renforcé cette lecture.

Sur les CPU Intel ou AMD, en revanche, la prudence reste nécessaire. Il existe des inquiétudes sérieuses autour de composants opaques comme Intel Management Engine. 01net l’a décrit comme un ordinateur dans l’ordinateur, doté de privilèges très élevés, opaque, avec accès à la mémoire et au réseau, difficilement désactivable. Des vulnérabilités critiques ont aussi été découvertes dans ce composant.

Mais cela ne constitue pas une preuve publique d’une porte dérobée de la NSA dans tous les processeurs Intel ou AMD. En 2024, des accusations chinoises ont affirmé qu’Intel intégrerait des portes dérobées de la NSA dans ses CPU via le Management Engine. Aucune preuve technique publique solide n’a toutefois été présentée pour soutenir ces accusations. Dans ce domaine, la prudence est essentielle, car la cyberguerre est aussi une guerre de récits et de propagande.

SiPearl n’est donc pas un projet né par hasard. L’entreprise est, en quelque sorte, « l’enfant industriel » d’une inquiétude européenne plus large : la dépendance aux processeurs, aux supercalculateurs, aux outils de conception et aux infrastructures étrangères place l’Europe dans une position de vulnérabilité stratégique.

L’EPI répond à plusieurs peurs concrètes :

• dépendre des processeurs américains ou asiatiques pour les supercalculateurs européens
• ne pas pouvoir auditer ou maîtriser les composants critiques utilisés dans la recherche, la défense, l’IA ou l’énergie
• subir des restrictions d’exportation comme celles que les États-Unis utilisent déjà dans la guerre technologique contre la Chine
• découvrir que le kill switch moderne passe moins par un « bouton secret » que par des licences, des mises à jour, le cloud, la maintenance ou le droit extraterritorial
• revivre, sous une autre forme, les précédents liés aux équipements interceptés, au chiffrement affaibli, à Crypto AG ou à Dual_EC_DRBG.

L’Europe n’a pas lancé l’European Processor Initiative pour entretenir l’illusion d’une puissance technologique autonome. Elle l’a fait parce que les processeurs, les supercalculateurs et les infrastructures de calcul sont devenus des instruments technologiques de puissance.

Dans un monde où des services numériques peuvent être coupés, où des mises à jour peuvent dépendre de décisions politiques étrangères, où des équipements réseau ont déjà été interceptés et modifiés par des services de renseignement, la maîtrise des briques critiques n’est plus un luxe industriel. C’est une condition de souveraineté numérique.

C’est là que j’ai vraiment pris conscience de l’importance de SiPearl, mais aussi du titre exact de Thierry Lelégard : « Security Architecture » : Architecte en sécurité des systèmes.

La sécurité n’est pas une couche ajoutée en bout de chaîne dans un projet de cette envergure. Elle traverse toute l’architecture et concerne la conception, les choix industriels, les dépendances, les composants, les logiciels, les usages, les clients, les marchés, les États, les alliances.

L’entretien avec Thierry était riche. J’aurais volontiers continué cet échange pendant des heures. Mais à un moment, il faut savoir lâcher la grappe à son interlocuteur, même quand celui-ci a encore beaucoup de choses passionnantes à dire.

J’ai terminé mon entretien avec deux questions simples :

• À quel concurrent SiPearl peut-il être comparé ?
  Réponse : Intel.

• Est-ce que demain SiPearl pourrait équiper des centres de données européens, en dehors des supercalculateurs ?
  Réponse : oui.

Je me suis donc pris à imaginer qu’un jour, peut-être, un processeur SiPearl pourrait se retrouver dans l’un de mes serveurs. Ce n’est qu’une supposition personnelle. Je n’ai pas eu le temps de poser la question dans le détail. Mais l’idée m’a amusé. Et, à vrai dire, elle m’a aussi un peu réjoui.

En terminant cet entretien, je me suis surtout dit une chose : ce que SiPearl a réussi à faire en quelques années force le respect.

C’est mon opinion, bien sûr, mais quand on regarde les faits, elle est fondée. L’entreprise a été créée en 2019, lancée opérationnellement en 2020, et elle a déjà créé un processeur européen de très haute performance, conçu pour équiper des supercalculateurs de premier rang. Tout cela dans un secteur industriel d’une complexité extrême, avec des levées de fonds jamais simples à réaliser, des chaînes de dépendance mondiales, une bureaucratie européenne rarement connue pour sa vitesse supersonique, et un sujet où l’erreur coûte très cher.

SiPearl reste un acteur de cette grande coopérative mondiale des semi-conducteurs. Elle ne fabrique pas tout. Elle ne remplace pas ASML, TSMC, Cadence, Synopsys, Siemens EDA, Nvidia ou l’ensemble de l’écosystème mondial. Mais elle apporte une brique européenne là où l’Europe en manquait une.

Et c’est déjà beaucoup.

En un peu plus de six ans opérationnels, cette entreprise n’a pas à rougir. Elle montre à nouveau qu’impossible n’est pas français, même quand le dossier passe par Bruxelles, Taïwan, les États-Unis, l’Allemagne, Arm, des outils EDA, des supercalculateurs, des milliards d’investissement et une bonne dose de patience industrielle.

Je tiens enfin à remercier à nouveau Steeve Morin, pour avoir rendu cet échange possible et pour prouver, par son parcours et ses prises de parole, qu’une autre vision de la tech peut exister.

I have it in my hand and you don’t, the SiPearl Rhea 1 pic.twitter.com/xn7MexUD20

— Steeve Morin (@steeve) June 2, 2026

Merci aussi à Thierry Lelégard pour sa patience, sa pédagogie et sa capacité à expliquer des sujets d’une complexité extrême à quelqu’un qui, je le rappelle volontiers, n’est ni technicien, ni développeur, ni ingénieur, et encore moins du sérail.

L’objectif de cet article est de permettre au grand public de mieux comprendre ce qu’est SiPearl, pourquoi ce projet compte, et pourquoi la souveraineté numérique ne se limite pas aux logiciels, aux clouds ou aux services en ligne.

Elle se joue aussi là : dans les processeurs, les architectures, les machines, les chaînes industrielles, les coopérations internationales et les choix de sécurité.

En sortant de cette lecture, j’espère que vous ne regarderez plus un processeur européen comme un simple objet technique, mais comme une pièce très concrète de notre autonomie future.

L’article SiPearl : l’histoire d’un processeur européen conçu avec le monde entier est apparu en premier sur Souverain.

Un commun numérique, ce n’est pas seulement un logiciel gratuit ou un code publié en ligne.
C’est une ressource numérique produite, entretenue et gouvernée collectivement.
Cette ressource peut être un logiciel, une base de données, une cartographie, un standard technique, une documentation, une infrastructure ou un ensemble d’outils.

Elle devient un commun lorsqu’une communauté l’utilise, la maintient, l’améliore et définit des règles pour éviter sa capture par un seul acteur.

Cette distinction est essentielle :

• Un logiciel peut être ouvert sans être réellement gouverné comme un commun.
• Une donnée peut être accessible sans que les utilisateurs aient leur mot à dire sur son évolution.

Un commun numérique suppose trois éléments :

• une ressource partagée,
• une communauté active
• et une gouvernance capable d’organiser la contribution, la maintenance, les droits d’usage et la pérennité.

Wikipédia, OpenStreetMap, certains logiciels libres, solutions ou encore des briques techniques utilisées par des administrations et des entreprises peuvent être compris dans cette famille.
Leur valeur ne tient pas seulement au fait qu’ils sont accessibles. Elle tient aussi à leur capacité à être améliorés, transmis, audités, adaptés et réutilisés sans enfermer leurs utilisateurs dans une dépendance propriétaire.

Cette idée du commun numérique rejoint une réflexion plus ancienne sur le don, le savoir et la contribution. Dans une intervention d’Edgar Morin, le point de départ n’est pas la technique, mais la vie sociale. Avant l’économie monétaire, rappelle-t-il, il y a le don.

Donner, recevoir, rendre, transmettre : ces gestes ne relèvent pas seulement de l’échange matériel. Ils construisent une relation. Ils créent une forme de reconnaissance mutuelle.

Le théoricien de la pensée complexe observe que cette part du gratuit et du don s’est rétrécie dans nos sociétés.

Beaucoup de choses qui relevaient autrefois du service rendu, du bien commun ou de l’attention ordinaire sont désormais calculées, tarifées, mesurées. Son propos ne consiste pas à nier l’économie, mais à rappeler qu’une société ne peut pas vivre uniquement dans la quantification. Tout ne se résume pas à un prix, à une facture, à une performance ou à un indicateur.

Dans ce cadre, Internet apparaît comme un espace profondément ambivalent. Il peut accueillir le meilleur comme le pire : la communication, la rencontre, la connaissance, mais aussi la manipulation, le trafic, la captation et l’exploitation. Cette ambivalence est importante. Le numérique n’est pas bon ou mauvais en soi. Tout dépend des formes sociales, économiques et politiques qui l’organisent.

La pensée de Bernard Stiegler apporte un second éclairage. Dans l’intervention partagée, le philosophe ne parle pas du logiciel libre comme d’un simple sujet technique. Il le présente comme une matrice sociale, culturelle et politique. Le logiciel libre devient, dans son analyse, une manière de lutter contre la dépossession des savoirs.

Pour le philosophe, les sociétés industrielles modernes ont produit une forme de prolétarisation qui ne touche plus seulement les ouvriers. Elle concerne aussi les consommateurs, les soignants, les chercheurs, les enseignants, les cadres, les familles. Quand les procédures, les outils fermés, les systèmes automatisés et les plateformes remplacent progressivement les savoir-faire, les individus perdent une part de leur capacité à comprendre et à agir.

Le logiciel libre ouvre une autre possibilité. Parce qu’il permet d’étudier, modifier, partager et améliorer un programme, il redonne une place à la contribution. Il ne se contente pas de fournir un outil : il rend visible la manière dont cet outil fonctionne. Il permet à des communautés de produire ensemble, de documenter, de corriger, de débattre, de transmettre. Il transforme l’utilisateur passif en acteur possible.

Cette idée rejoint l’un des concepts importants chez Stiegler : la technique comme pharmakon, à la fois poison et remède. Le numérique peut détruire des savoirs lorsqu’il enferme, automatise et dépossède. Mais il peut aussi devenir un support de reconstruction lorsqu’il permet la coopération, la compréhension et la contribution collective.

C’est dans ce passage du libre au commun, puis du commun à l’infrastructure, que se situe l’enjeu européen actuel.

Depuis plusieurs années, l’Europe cherche à organiser des coopérations numériques à grande échelle. L’un des instruments créés pour cela s’appelle l’EDIC, pour European Digital Infrastructure Consortium. Derrière ce sigle un peu administratif, à la sauce U.E, se trouve une idée assez simple : permettre à plusieurs États membres de l’Union européenne de porter ensemble de grands projets numériques transfrontaliers.

Un EDIC est un cadre juridique européen. Il permet de mutualiser des moyens, de définir une gouvernance commune, d’associer des acteurs publics et privés, et de construire des infrastructures numériques que chaque pays aurait du mal à développer seul.

L’objectif est de sortir de la dispersion : plutôt que de multiplier des initiatives isolées, les États peuvent bâtir des projets communs, reconnus juridiquement, capables de durer.

Cette logique est particulièrement importante pour les communs numériques. Un commun peut naître dans une communauté de développeurs, de chercheurs, d’administrations ou d’utilisateurs. Mais lorsqu’il devient critique pour des millions de personnes, la question de sa stabilité devient centrale :

• Qui le finance ?
• Qui le maintient ?
• Qui garantit qu’il ne sera pas capturé, abandonné ou orienté par un seul acteur ?
• Qui décide de ses évolutions ?

Le Digital Commons EDIC s’inscrit dans cette perspective. Il vise à donner aux communs numériques européens une structure plus solide, en réunissant États, administrations, communautés open source, entreprises et développeurs autour de ressources ouvertes, interopérables et réutilisables. L’enjeu n’est pas seulement de créer de nouveaux logiciels. Il s’agit de construire un environnement dans lequel des briques ouvertes peuvent devenir des infrastructures fiables, maintenues et adoptées à grande échelle.

Cette orientation rejoint aussi les recommandations formulées par le CIANum dans son rapport consacré à la souveraineté numérique. Le sujet a déjà été traité : le rapport y apparaît comme une tentative de sortir d’une opposition trop simpliste entre l’État, le marché et les communautés open source. Sa ligne de fond consiste plutôt à organiser leur coopération.
Les communs numériques y sont présentés comme des ressources stratégiques, à financer, maintenir et gouverner dans la durée, au même titre que des infrastructures essentielles.
Le rapport insiste également sur la nécessité de passer à l’échelle européenne, notamment autour de l’EDIC Digital Commons, de fonds dédiés, de standards ouverts et de mécanismes capables de protéger ces communs contre l’abandon ou la capture.

EuroCommons s’inscrit donc dans une continuité claire : transformer une recommandation de politique publique en méthode opérationnelle, avec des coalitions, des financements, des migrations concrètes et une gouvernance partagée.

Le programme lancé par la Caisse des Dépôts dans le cadre d’Horizon Numérique 2030. Son ambition est très concrète : aider de grandes organisations européennes, publiques et privées, à migrer vers des solutions indépendantes, fondées sur des communs numériques, de l’open source, des standards ouverts et une gouvernance européenne.

Ce que l’on appelait encore hier une dépendance invisible apparaît aujourd’hui pour ce qu’elle est : une fragilité concrète, inscrite au cœur des logiciels, des infrastructures et des usages quotidiens. Elle concerne les outils de travail collaboratif, la messagerie, les annuaires, l’identité numérique, la virtualisation, le cloud, les bases de données, les outils de cybersécurité, les systèmes d’exploitation, les applications mobiles ou encore les données géographiques. Autrement dit, une grande partie de la chaîne technique sur laquelle reposent les administrations, les entreprises et les services du quotidien.

EuroCommons propose une méthode fondée sur les coalitions. Plutôt que de demander à chaque organisation de migrer seule, avec ses risques, ses coûts et ses incertitudes, le programme invite les grandes DSI européennes, les éditeurs open source, les intégrateurs, les fondations et les acteurs des communs numériques à travailler ensemble sur des briques prioritaires.

Cette logique change l’échelle du problème. Une organisation isolée peut hésiter à quitter une solution propriétaire dominante. Le risque technique paraît élevé, les coûts de migration sont difficiles à absorber, les alternatives semblent parfois dispersées.
En « coalition », ces obstacles peuvent être abordés autrement : la demande est mutualisée, les coûts peuvent être partagés, les besoins fonctionnels sont exprimés collectivement, les fournisseurs européens gagnent en visibilité, et les migrations peuvent être coordonnées.

Les documents de présentation d’EuroCommons identifient onze grands domaines technologiques critiques :

• environnement de travail numérique,
• communications,
• applications métiers,
• outils de gestion de projet et d’administration informatique
• virtualisation,
• cloud et données,
• annuaires et identité,
• sécurité,
• systèmes d’exploitation de bureau,
• systèmes mobiles
• et données géographiques.

Ce ne sont pas des couches techniques secondaires. Ce sont les fondements sur lesquels reposent les usages, les décisions et la capacité de résilience d’une organisation.

Le programme ne prétend pas que toutes les migrations doivent suivre le même chemin. Certaines alternatives existent déjà et fonctionnent en production. D’autres nécessitent de financer ensemble le « dernier kilomètre », c’est-à-dire les quelques fonctionnalités manquantes qui empêchent une adoption massive. D’autres encore supposent de faire travailler plusieurs solutions européennes ensemble, grâce à des standards ouverts, pour éviter de remplacer une dépendance par une autre.

Le soutien annoncé ne se limite pas nécessairement au développement logiciel. Une migration sérieuse commence souvent avant la première ligne de code : par des audits, des études d’impact, des comparaisons entre solutions propriétaires et solutions open source, des analyses de coût complet, des évaluations de sécurité, de réversibilité, d’interopérabilité et de résilience. C’est un point encore trop peu documenté dans le débat public. Les solutions ouvertes sont souvent jugées sur leur coût immédiat ou sur leur apparence fonctionnelle à court terme, alors que leur intérêt se mesure aussi dans la durée :

• maîtrise des coûts,
• absence de verrouillage,
• capacité à changer de prestataire,
• auditabilité,
• adaptation aux besoins réels,
• indépendance stratégique
• et potentiel d’innovation.

En soutenant des coalitions, des diagnostics et des mécanismes de financement, EuroCommons peut aussi contribuer à produire les éléments de preuve qui manquent encore aux décideurs : des comparatifs solides, des retours d’expérience, des trajectoires de migration crédibles et des modèles économiques capables de démontrer que l’open source n’est pas seulement une alternative de principe, mais une option industrielle sérieuse.

La Caisse des Dépôts se positionne ici comme tiers de confiance. Son rôle consiste à poser un cadre, accompagner les projets, contribuer au financement, mettre les acteurs en relation et aider les coalitions à atteindre une masse critique. Cette approche est intéressante parce qu’elle ne réduit pas la souveraineté numérique à un slogan. Elle la replace dans des conditions très concrètes : gouvernance, modèle économique, interopérabilité, maintenance, partage des risques et capacité réelle de migration.

Le 1er juillet 2026, l’EuroCommons Coalition Day doit ouvrir une première séquence opérationnelle à la Salle Wagram de Paris. La journée réunira l’ensemble des acteurs européens engagés dans la réduction des dépendances numériques. L’objectif annoncé est de lancer les premières coalitions, d’identifier les besoins, de présenter les alternatives déjà disponibles et de préparer les premiers TechSprint où des « cycles d’action de quelques mois centrés sur une brique numérique prioritaire, au terme desquels les organisations engagées pourront migrer vers des communs numériques européens ouverts et pérennes. » 

Il ne s’agit pas seulement de débattre, mais de faire avancer concrètement des migrations, des financements, des choix techniques et des modèles de gouvernance. Les organisations peuvent participer à différents niveaux : observer, contribuer, co-diriger une coalition, ou simplement apprendre des acteurs déjà engagés.

Pour le grand public, le sujet peut sembler inaudible. Pourtant, il touche directement à la manière dont les services publics, les entreprises, les collectivités, les hôpitaux, les écoles ou les associations utilisent le numérique. Derrière une suite bureautique, une messagerie, un annuaire d’identités ou un outil de visioconférence, il y a toujours des choix d’infrastructure. Ces choix déterminent où vont les données, qui maîtrise les évolutions, qui fixe les prix, qui peut interrompre un service, qui peut auditer le code, qui peut adapter l’outil aux besoins réels.

L’enjeu n’est donc pas de remplacer une dépendance par un réflexe de fermeture ou de faire croire que l’autarcie serait une solution. Il s’agit plutôt de redonner de la marge de manœuvre : Pouvoir choisir, comprendre, contribuer, changer de prestataire sans tout perdre et construire des outils qui ne soient pas seulement consommés, mais aussi gouvernés.

La réflexion d’Edgar Morin sur le don et celle de Bernard Stiegler sur la contribution éclairent alors le sujet d’une autre manière. Les communs numériques ne sont pas une nostalgie du gratuit ni une simple affaire de développeurs. Ils posaient une question politique : quelles ressources une société souhaite-t-elle construire, maintenir et transmettre ensemble ?

EuroCommons apporte une réponse institutionnelle et industrielle à cette question. Elle ne suffira pas à elle seule à résoudre les dépendances numériques européennes. Mais elle ouvre un cadre concret pour passer du diagnostic à l’action, de la critique à la migration, du logiciel libre isolé au commun numérique durable.

Pour les organisations ou personnes concernées, l’événement du 1er juillet peut offrir un point d’entrée utile : comprendre les coalitions, rencontrer des pairs, découvrir les briques prioritaires, mesurer les conditions de migration et prendre part à une dynamique européenne en construction. Pour toutes celles et ceux qui suivent les sujets de souveraineté numérique, cette journée mérite votre attention : elle pourrait marquer une étape importante dans la transformation des communs numériques en véritables infrastructures européennes.

Les inscriptions sont ouvertes depuis la page officielle de la Caisse des Dépôts. Pour les grandes organisations, les éditeurs, les intégrateurs, les fondations et les acteurs publics qui souhaitent comprendre cette démarche ou y prendre part, l’EuroCommons Coalition Day du 1er juillet constitue une occasion rare de voir comment les communs numériques peuvent passer du discours à l’action collective.

L’article EuroCommons : un des remparts de l’Europe face à la colonisation numérique est apparu en premier sur Souverain.

Avant-propos

Avant d’entrer dans la note publiée par le Cigref, un détour par les mots paraît nécessaire. Non par goût de la nuance abstraite, mais parce que le vocabulaire employé dans le débat engage déjà une manière de penser l’action publique, les responsabilités des entreprises et la place des citoyens. Souveraineté numérique, autonomie stratégique, résilience, indépendance technique, maîtrise des dépendances, autonomie numérique : ces termes circulent parfois comme s’ils étaient interchangeables. Ils ne le sont pas tout à fait.

Le mot « souverain » vient de l’ancien français soverain ou suverain. Les dictionnaires le rattachent généralement à un latin populaire ou bas latin superanus (oui je sais…), dérivé de super, « au-dessus ». Le CNRTL signale toutefois une nuance étymologique : une forme voisine, supranus, dérivée de supra, est également évoquée, et le latin médiéval superanus pourrait être ce qu’on appelle une relatinisation.

Le terme apparaît dès le XIᵉ siècle. Son sens initial est très concret : ce qui se situe au degré le plus élevé, ce qui domine, ce qui occupe le sommet d’un ordre. On comprend alors pourquoi le mot a pu conserver plusieurs usages : un remède souverain désigne un remède d’une efficacité supérieure ; un État souverain désigne un État qui ne dépend pas juridiquement d’une autorité supérieure ; le souverain, dans l’ordre politique, désigne celui qui détient le pouvoir suprême.

Le mot « souveraineté », formé à partir de « souverain » avec le suffixe « -eté », apparaît quant à lui au XIIᵉ siècle. Il désigne d’abord ce qui est le plus élevé, le sommet, avant de prendre, à partir du XIIIᵉ siècle, un sens plus nettement politique : l’autorité suprême, le pouvoir suprême du souverain. Cette évolution est importante. La souveraineté ne désigne pas simplement la capacité de se débrouiller seul, de limiter ses dépendances ou d’agir avec une certaine autonomie. Elle renvoie à une autorité ultime, placée au sommet d’un ordre politique ou juridique.

Cette précision est nécessaire pour éclaircir directement le débat sur la souveraineté numérique. Si souverain signifie « au-dessus », et si souveraineté renvoie à l’autorité suprême, alors le mot se prête mal à certains usages devenus courants dans le numérique : cloud souverain, IA souveraine, datacenter souverain, logiciel souverain, offre souveraine. Ces expressions peuvent avoir une utilité commerciale ou pédagogique, mais elles brouillent souvent les pistes. Un outil n’est pas souverain par nature. Un fournisseur ne devient pas souverain parce qu’il est européen. Une infrastructure technique peut contribuer à une politique de souveraineté, ou renforcer la résilience d’une organisation, mais elle ne détient aucune volonté politique, aucune légitimité démocratique, aucune capacité d’arbitrage suprême.

La nuance est donc décisive. La souveraineté relève du pouvoir politique et de la capacité d’arbitrer :

• L’autonomie désigne la capacité à agir par soi-même.
• La résilience désigne la capacité à tenir malgré les chocs.
• L’indépendance technique désigne la capacité à limiter ou maîtriser ses dépendances.
• La réversibilité désigne la capacité à changer d’outil, de fournisseur ou d’infrastructure sans se retrouver prisonnier d’un choix antérieur.

Ces notions sont proches, mais elles ne disent pas la même chose.

La question n’est pas seulement lexicale. Elle est devenue politique. D’après mes recherches, l’une des premières occurrences structurées connues de l’expression « souveraineté numérique » apparaît en 2006 dans l’article « Souveraineté et réseaux numériques », rédigé par Bernard Benhamou et Laurent Sorbier dans la revue Politique étrangère.
Vingt ans plus tard, le malaise demeure. L’expression s’est imposée, mais son sens continue de glisser. Elle peut désigner une politique industrielle, une exigence de protection des données, un refus des dépendances technologiques, une volonté de relocalisation, un projet européen, une stratégie d’État, une promesse de fournisseur ou un simple argument de marque.

Il semble également pertinent d’ouvrir le propos à une autre lecture de la souveraineté numérique, à travers cet extrait de l’émission À la French. : La vérité sans tabous sur la souveraineté numérique française, par Jean-Baptiste Kempf, CEO de Kyber et président de VideoLAN / VLC :

En général, je commence toujours par un petit laïus sur ce qu’est la souveraineté. C’est un très, très, très mauvais mot. La souveraineté, ça parle d’un suzerain, et c’est exactement l’état dans lequel on est dans la « tech », on a des gens qui nous dominent et, en fait, ce qu’on cherche, ce n’est pas vraiment la souveraineté. C’est l’autonomie. Autonomie numérique …
C’est pour ça, et moins souvent, je parle donc d’autonomie numérique, parce que l’important, c’est d’être capable de sortir, mais c’est aussi parce que, dans la tech, on a fait un truc complètement débile où on est fier de n’avoir qu’un seul fournisseur.
Et toi, tu te souviens, les 01net… : « J’ai fait mon move intégral sur microsoft, … ». Et en fait, quand tu vas, si, tu vas avec n’importe quel pote qui bosse chez Airbus, chez Renault, chez n’importe quel industriel, tu dis : « J’ai qu’un seul fournisseur. » Il te regarde, il te dit : « Mais vous êtes complètement fou », parce qu’en fait, tu veux plusieurs fournisseurs. Pour avoir différentes sources.
Et ça arrive très souvent, d’ailleurs, dans l’agglomération toulousaine, par exemple, où il y a quelques sociétés qui sont devenues très, très dépendantes d’Airbus et, en fait, c’est un problème pour Airbus. Et parfois pour Airbus, soit ils rachètent la société, soit, avec Bouygues, Dassault et Safran, ils forment un consortium pour acheter des boîtes qui sont les fournisseurs.
Mais, en informatique : « whaouu ou je suis trop content, je fais que du microsoft ».
Et évidemment, il y a une bonne raison pour ça, on n’est pas juste idiot, c’est qu’en fait, ça te permet de simplifier ton SI, d’avoir une conformité, d’avoir la sécurité et de réduire tes coûts. Mais quand même, c’est quand même très bizarre. Et donc, en fait, c’est arrivé. Et là, en fait, on se rend compte qu’on est vraiment très dépendant, très peu autonome.
Et c’est surtout sur la partie logicielle, parce que, par exemple, je l’ai vu chez Scaleway et plein d’autres avec tout ce qui est Open Compute Project (OCP), en fait, que t’achètes du SuperMicro, du Dell, Gigabyte, du Lenovo, c’est plus ou moins interopérable. C’est toujours « rackable », de la même façon, tu peux mettre électricité…
Et c’est d’ailleurs très, très étonnant. C’est que sur la partie cloud : les clouds souverains européens sont beaucoup plus alignés avec meta que les autres d’ailleurs, parce qu’eux, ne font pas de cloud. Mais bref …

Ce flottement explique une partie des crispations. Le mot « souveraineté » n’est pas, historiquement, un mot d’extrême droite. Il appartient d’abord au vocabulaire républicain. La Déclaration des droits de l’homme et du citoyen de 1789 affirme que le principe de toute souveraineté réside essentiellement dans la Nation. La Constitution de 1958 reprend cette idée en disposant que la souveraineté nationale appartient au peuple, qui l’exerce par ses représentants et par la voie du référendum. Sur le fond, la souveraineté est donc une notion républicaine, démocratique et populaire. Elle signifie que le pouvoir ne vient ni du roi, ni d’une caste, ni d’un empire, ni d’un marché, mais du peuple constitué politiquement.

Pourtant, dans le débat public, le mot n’est pas assumé par tout le monde. Une partie de la gauche s’en méfie, non parce que la souveraineté serait par essence réactionnaire, mais parce qu’elle a souvent été captée par des discours où elle ne signifie plus seulement le pouvoir du peuple, mais aussi le repli national, la méfiance envers l’Europe, la fermeture migratoire, la priorité nationale ou la défense d’une identité culturelle figée. Le malaise vient moins du mot « souveraineté » que du glissement vers le « souverainisme », devenu beaucoup plus chargé politiquement.

La distinction est essentielle. La souveraineté peut être républicaine, démocratique, sociale, européenne, populaire. Le souverainisme, dans une partie de ses usages, renvoie davantage à une opposition frontale entre la Nation et l’Europe, entre les nationaux et les étrangers, entre le peuple et les élites, entre les frontières et la mondialisation. C’est de là, je suppose, que naît la crainte : celle de voir une souveraineté populaire se transformer en souveraineté identitaire.

Dans une souveraineté populaire, le peuple décide de ses lois. Dans une souveraineté identitaire, la première question est plutôt de savoir qui est vraiment « ce peuple ». Le basculement n’est pas anodin. Pour une partie de la gauche, la République doit rester un cadre d’égalité : droits sociaux, services publics, libertés publiques, justice fiscale, protection des travailleurs, accès aux biens communs. Lorsque la souveraineté sert à hiérarchiser les appartenances, à trier les droits ou à réserver la solidarité nationale selon des critères d’identité, elle change de nature. Elle ne parle plus seulement de démocratie, elle devient un instrument d’exclusion.

Cette inquiétude est renforcée par une bataille de perception. Dans plusieurs enquêtes consacrées à la souveraineté européenne, le terme apparaît comme politiquement ambigu. Beaucoup de citoyens ne l’associent ni clairement à la droite ni clairement à la gauche, mais lorsqu’une couleur politique lui est attribuée, elle penche plus souvent vers la droite. D’autres travaux montrent que la souveraineté réactive le clivage gauche-droite, tandis que la souveraineté européenne fait plutôt apparaître un clivage entre pro-européens et anti-européens. Cela explique pourquoi certains militants, décideurs, intellectuels ou responsables politiques de gauche avancent avec prudence : ils savent que le mot transporte déjà des connotations de puissance, de frontière, de nation, parfois de nostalgie.

Abandonner le mot serait pourtant une erreur. Le laisser entièrement à l’extrême droite reviendrait à renoncer à une partie du vocabulaire démocratique. Il existe une souveraineté républicaine parfaitement compatible avec une lecture sociale, européenne et ouverte du numérique : celle qui parle de contrôle démocratique, de services publics, de capacité industrielle, de maîtrise des infrastructures, de refus des monopoles privés, de communs numériques, d’interopérabilité, de transparence, d’open source et d’indépendance face aux grandes plateformes. Dans cette perspective, la souveraineté numérique ne désigne pas une fermeture au monde. Elle désigne la capacité collective de choisir et de rester libre.

▶

Autre aspect : Parler de souveraineté numérique ne devrait pas signifier rejeter l’Amérique, ni construire un nationalisme technologique, ni de rêver d’une autarcie numérique (qui serait d’ailleurs impossible). Il s’agit plutôt de refuser les dépendances subies, les verrouillages invisibles, les chaînes techniques non maîtrisées et les asymétries de puissance qui privent progressivement les États, les organisations et les citoyens de véritables marges de décision. La souveraineté numérique, dans cette lecture, n’est pas une promesse de pureté. Elle devient une exigence de lucidité.

Et cette exigence suppose de distinguer plusieurs niveaux. La souveraineté numérique relève du politique : elle concerne l’État, l’Europe, la loi, la commande publique, la politique industrielle, les infrastructures critiques, la capacité normative. La résilience numérique relève des organisations : entreprises, administrations, collectivités, associations, qui doivent garantir la continuité de leurs services, sécuriser leurs données, diversifier leurs fournisseurs, documenter leurs dépendances et préparer leur capacité de migration. L’autonomie numérique relève davantage des citoyens, des petites structures et des usages concrets : choix d’outils, auto-hébergement, logiciels libres, sauvegardes, compréhension des services utilisés, capacité à quitter une plateforme.

Cette distinction permet aussi d’aborder une autre difficulté : que signifie exactement la « souveraineté numérique européenne » ? À première vue, l’expression semble entrer en tension avec une lecture stricte de la souveraineté. Si la souveraineté est une prérogative d’État, comment l’Union européenne pourrait-elle être souveraine alors qu’elle n’est pas un État fédéral complet et que ses membres conservent des intérêts industriels, diplomatiques, fiscaux et stratégiques parfois divergents ?

La contradiction n’est pas totale, mais elle existe dès que le mot est employé sans précision. L’Union européenne n’a pas une souveraineté originelle comparable à celle d’un État. Elle agit dans les domaines où les États membres lui ont transféré ou partagé des compétences. Il serait donc plus rigoureux de dire que les États européens exercent ensemble certaines compétences numériques au niveau de l’Union. Dire que « l’Union européenne est souveraine numériquement » est plus simple politiquement, mais plus fragile juridiquement.

Lorsque la Commission européenne parle de souveraineté technologique ou de souveraineté numérique européenne, elle semble employer le mot dans un sens stratégique et géopolitique. Il s’agit moins d’une souveraineté constitutionnelle que d’une capacité d’action : réduire les dépendances structurelles, développer des technologies critiques, sécuriser les infrastructures, renforcer la base industrielle européenne, soutenir l’open source, maîtriser les données et élargir les choix technologiques disponibles pour les entreprises, les administrations et les citoyens. Autrement dit, la Commission parle souvent de souveraineté là où l’on pourrait aussi parler d’autonomie stratégique, de capacité industrielle, de résilience technologique, de puissance normative ou de maîtrise collective des dépendances.

La vraie difficulté tient à l’absence d’un intérêt européen unique. La France peut défendre une politique industrielle plus affirmée. L’Allemagne peut arbitrer différemment selon ses intérêts exportateurs, ses dépendances industrielles ou sa relation aux États-Unis. Les pays baltes et la Pologne peuvent privilégier une lecture plus atlantiste, marquée par la menace russe. L’Irlande, les Pays-Bas ou le Luxembourg peuvent avoir des intérêts fiscaux et économiques qui ne se confondent pas avec ceux d’autres États membres. Certains pays privilégient la concurrence, d’autres la protection industrielle, d’autres encore la sécurité ou l’innovation de marché.

La souveraineté numérique européenne n’existe donc réellement que lorsqu’un compromis politique transforme ces intérêts divergents en action commune. L’Union européenne sait produire des normes : RGPD, DSA, DMA, AI Act, NIS2, DORA, politiques de cybersécurité, programmes de financement. Elle se montre souvent plus hésitante lorsqu’il s’agit de bâtir des capacités industrielles communes, de choisir des champions, d’assumer une préférence européenne ou de coordonner durablement des investissements lourds.

La formule la plus juste serait peut-être celle d’une souveraineté mutualisée, ou d’une souveraineté exercée en commun. Les États ne disparaissent pas. Ils reconnaissent simplement que certains enjeux sont trop vastes pour être traités seuls. Aucun État européen, même parmi les plus puissants, ne peut (pour l’instant) à lui seul peser durablement face aux hyperscalers américains, aux chaînes de semi-conducteurs asiatiques, aux plateformes globales ou aux normes technologiques imposées par d’autres blocs. L’échelle européenne devient nécessaire. Elle ne devient toutefois souveraine que si les États acceptent de coordonner leurs choix, leurs budgets, leurs marchés publics, leurs normes et leurs priorités industrielles.

La note du Cigref permet justement de clarifier ce point. Elle rappelle que la souveraineté n’est pas une qualité que l’on colle à un produit, à un fournisseur, à un cloud ou à une infrastructure. Dans les débats, on parle aussi de sovereign washing. Pour le Cigref, la souveraineté est une compétence qui s’exerce. Elle appartient à l’ordre politique. Elle suppose une puissance publique capable de décider, réguler, investir, protéger et arbitrer. Les entreprises, elles, ne sont pas souveraines : elles construisent leur résilience. Les citoyens et les petites structures, eux, peuvent développer leur autonomie numérique. Cette distinction ne ferme pas le débat, elle permet surtout d’éviter que chaque acteur soit renvoyé à une responsabilité qui ne serait pas la sienne.

Résumé de la note d’information du Cigref

Le Cigref part d’un constat : la souveraineté numérique est devenue omniprésente dans le débat public, mais son usage s’est brouillé. Le terme est désormais employé pour désigner des produits, des fournisseurs, des infrastructures, parfois avec une forte dimension marketing. Pour le Cigref, l’utilisation de l’expression « souveraineté numérique » pose problème, car elle mélange des réalités très différentes : nationalité d’un fournisseur, localisation des données, maîtrise technique, exposition aux lois extraterritoriales, réversibilité, indépendance stratégique, etc.

La thèse du Cigref tient dans une distinction claire : la souveraineté numérique ne se décrète pas par l’origine d’un fournisseur, la localisation d’une infrastructure ou la nature d’une technologie. Elle relève d’une compétence politique, exercée par la puissance publique, à travers la loi, la régulation, la capacité normative et les choix industriels. Une entreprise, un cloud, un centre de données ou un logiciel peuvent contribuer à une stratégie de souveraineté, mais ils ne sont pas souverains en eux-mêmes.

La notion que le Cigref veut mettre en avant pour les entreprises est plutôt celle de résilience numérique. Une entreprise ne serait pas souveraine; elle serait plus ou moins résiliente. Cela signifie qu’elle doit être capable de continuer à fonctionner malgré une cyberattaque, une défaillance de fournisseur, une rupture géopolitique, une hausse brutale des prix, un verrouillage propriétaire ou une loi extraterritoriale.

Le rapport critique aussi l’illusion d’une « pureté souveraine ». Pour le Cigref, une entreprise européenne peut très bien dépendre de marchés américains, de technologies non européennes ou de contraintes économiques mondiales. À l’inverse, un fournisseur européen peut lui aussi créer du verrouillage, pratiquer des hausses tarifaires abusives ou exploiter une dépendance client. Autrement dit : la nationalité européenne d’un fournisseur ne suffit pas à garantir une relation saine, réversible ou protectrice.

La conclusion de cette note : l’État exerce la souveraineté, les entreprises construisent leur résilience. La souveraineté suppose une politique publique de long terme : commande publique, politique industrielle, régulation, infrastructures critiques, capacité normative, coordination européenne. La résilience, elle, se mesure dans les choix opérationnels : continuité de service, maîtrise des dépendances, réversibilité, sécurité, capacité de migration, gouvernance des risques.

Comparaison avec la ligne éditoriale défendue ici

Globalement, la note ne contredit pas ce que je tente de défendre ici. Elle déplace et renforce l’usage du terme « souveraineté numérique » sur le plan sémantique.

Dans le manifeste que je propose, la souveraineté numérique est déjà indiquée comme une démarche politique, économique et culturelle liée à la maîtrise des outils, des données, des infrastructures et à la capacité de décider par soi-même. J’insiste aussi sur le fait qu’elle ne doit pas être pensée comme un slogan, un absolu ou une rupture totale, mais comme une construction progressive, lucide et concrète. C’est très proche de l’esprit du Cigref.

Mes articles vont aussi dans le sens d’une souveraineté par la réduction des dépendances : alternatives aux GAFAM, open source européen, auto-hébergement, LaSuite numérique, la solution grommunio, Proton, Actalis, réversibilité, standards ouverts, capacité de migration. L’objectif reste toujours le même : tester des outils, expliquer les dépendances, rendre le sujet accessible et relier les choix techniques à des enjeux politiques et citoyens.

Ma principale nuance avec le Cigref : il est vrai que j’utilise souvent le terme « souveraineté » dans un sens pratique et pédagogique, là où le Cigref veut le réserver à l’État. Par exemple, quand je parle d’une solution, d’un service ou d’une suite « souveraine », le Cigref dirait probablement : ce n’est pas la solution qui est souveraine, elle peut seulement contribuer à une stratégie de souveraineté publique ou renforcer la résilience d’une organisation.

C’est particulièrement visible dans l’article sur le rapport du CIANum. La souveraineté numérique y est décrite comme la capacité à choisir ses outils, changer de prestataire, récupérer ses données, comprendre ses dépendances et éviter l’enfermement propriétaire. Cette définition est cohérente avec mon approche, mais le Cigref la qualifierait plutôt de résilience, d’autonomie opérationnelle ou de maîtrise des dépendances, pas de souveraineté au sens strict.

Les points de divergence

Le premier point de divergence concerne les indices et scores de souveraineté. Le Cigref se méfie des indices qui prétendraient mesurer une « pureté souveraine ». Or, j’expérimente justement des méthodes d’évaluation : dépendances des sites, fournisseurs DNS, hébergement, certificats, prestataires, outils tiers. Ce n’est pas forcément incompatible, mais d’après le Cigref, il faudrait peut-être renommer ou recadrer ces tests. Le Cigref serait plus à l’aise avec des expressions comme score de dépendance numérique, indice de résilience, analyse d’exposition, cartographie des dépendances ou capacité de réversibilité. L’analyse sur les partis politiques parle déjà de souveraineté comme capacité d’action, de résilience et de maîtrise des données, ce qui pourrait facilement être rapproché de la doctrine Cigref.

Le deuxième point concerne les solutions européennes. J’essaye souvent de valoriser les alternatives européennes ou françaises lorsqu’elles réduisent une dépendance : LaSuite numérique, Proton, grommunio, Actalis, OVHcloud, open source européen. Le Cigref ne rejette pas cela, mais il ajoute une précaution importante : européen ne veut pas automatiquement dire réversible, loyal, robuste ou protecteur. Un fournisseur européen peut lui aussi enfermer ses clients. Cette nuance pourrait peut-être à l’avenir enrichir mes réflexions et articles, surtout ceux qui comparent des prestataires.

Le troisième point concerne l’open source. Je reconnais que je lui donne une place très importante, avec une vision optimiste : transparence, auditabilité, communs numériques, mutualisation, alternatives aux grands acteurs propriétaires. Le Cigref ne s’y oppose pas, mais sa note est moins militante sur l’open source : elle insiste davantage sur la responsabilité de l’État, la politique industrielle, la coordination et la résilience opérationnelle. En résumé : l’open source est souvent considéré ici comme un levier central de souveraineté. Pour le Cigref, il serait plutôt un instrument possible au service d’une politique publique ou d’une stratégie de résilience.

Le quatrième point est le rôle de l’individu et de l’auto-hébergement. Je pars souvent d’une expérience concrète : quitter Gmail, installer YunoHost, tester LaSuite, reprendre la main sur ses usages, documenter les erreurs. Le Cigref parle depuis le point de vue des grandes entreprises et administrations. Il ne nie pas l’intérêt de ces pratiques, mais son cadre est plus institutionnel : directions générales, conseils d’administration, État, Europe, politiques publiques, continuité des services critiques.

Conclusion

La note du Cigref ne dit pas que mon approche est fausse. Elle dit plutôt : attention à ne pas appeler « souveraineté » ce qui relève parfois de la résilience, de l’autonomie, de la réversibilité ou de la réduction des dépendances.

L’approche défendue ici se situe volontairement ailleurs : davantage du côté de la pédagogie, des essais concrets et des retours d’expérience accessibles au grand public. Le Cigref adopte une lecture plus doctrinale, juridique et institutionnelle. Ces deux approches ne s’opposent pas nécessairement. Là où je pars du terrain, des usages et des dépendances visibles au quotidien, la note du Cigref rappelle le cadre conceptuel et politique dans lequel ces pratiques doivent être replacées.

Vingt ans après l’article de Bernard Benhamou et Laurent Sorbier, la souveraineté numérique s’est imposée dans le débat public. Mais le terme ne fait pas encore consensus : son importance est largement reconnue, sans que son périmètre, ses responsabilités et ses implications soient compris de la même manière par l’État, l’Union européenne, les entreprises, les fournisseurs et les citoyens. L’expression a permis de nommer des dépendances longtemps invisibles, mais elle a aussi servi d’étiquette commode à des offres, des labels ou des discours parfois contradictoires. La note du Cigref intervient dans ce contexte : non pour disqualifier la souveraineté numérique, mais pour rappeler que le mot engage une responsabilité politique.

La meilleure évolution serait peut-être d’assumer cette formule : la souveraineté numérique appartient au politique, mais elle se prépare aussi dans des choix techniques, économiques et culturels qui renforcent notre résilience collective.

L’article Souveraineté numérique, autonomie stratégique, résilience… Sémantique et la note du Cigref est apparu en premier sur Souverain.

Autrement dit, le sujet est là. Il revient, il insiste, il accompagne presque chaque étape de cette démarche d’auto-hébergement.

Et pourtant, reconnaissons-le : parler de sauvegarde ne signifie pas toujours être parfaitement au point sur le sujet.

Et c’est précisément ce que cette « opération » matérielle a remis en lumière. Pendant longtemps, la sauvegarde restait un sujet sérieux, documenté, compris dans ses grandes lignes, mais encore partiellement théorique. J’ai évoqué les sauvegardes YunoHost, des copies vers le NAS, des procédures, des scripts, des alertes, des rapports. Mais il me manquait encore une étape concrète : celle qui touche réellement au disque système du serveur, avec le risque très concret de tout casser.

Cette fois, le passage s’est fait du « il faudrait vraiment le faire proprement » au « c’est fait, vérifié, et le serveur redémarre » (ouf 😮‍💨).

Ce retour d’expérience ne prétend pas encore atteindre la règle des 3-2-1, souvent rappelée dans les bonnes pratiques de sauvegarde : trois copies, deux types de supports, une copie hors-site. La démarche reste perfectible. Mais elle avance dans cette direction. Et surtout, elle rappelle une chose que l’on oublie facilement : une sauvegarde n’est rassurante que lorsqu’elle s’inscrit dans une procédure que l’on comprend, que l’on peut répéter, et dont on a testé au moins une partie du chemin de retour.

Le contexte : remplacer le NVMe du serveur homelab

Le serveur concerné est le serveur homelab principal, une machine YunoHost utilisée pour héberger plusieurs services personnels. L’objectif semblait simple : remplacer le SSD NVMe interne par un modèle plus récent, plus fiable, et mieux adapté à l’usage quotidien du serveur.

Le choix s’est porté sur un Samsung SSD 970 EVO Plus NVMe M.2 de 500 Go. Le modèle n’a pas été choisi au hasard : l’idée était d’avoir un support reconnu, suffisamment performant, avec de bonnes capacités en lecture et en écriture, afin de rester cohérent avec le reste de l’infrastructure locale.

Le serveur dispose désormais d’un adaptateur réseau 2,5 Gb, connecté à un switch compatible et à une connexion fibre. Le stockage n’est évidemment pas le seul facteur de performance, mais autant éviter que le disque devienne une faiblesse inutile dans une chaîne technique que l’on cherche progressivement à rendre plus solide.

Au départ, le plan paraissait assez direct :

ancien disque NVMe du serveur → clonage avec Rescuezilla → nouveau Samsung → redémarrage. FIN !

Sur le papier, rien de très compliqué.

En pratique, un détail a changé toute l’opération.

Le piège des « 500 Go » face aux « 512 Go »

La première surprise est venue de la capacité réelle des disques.

L’ancien disque du serveur était annoncé comme un NVMe de 512 Go. Le nouveau Samsung, lui, était un modèle de 500 Go. Jusqu’ici, cela pouvait sembler être une différence commerciale sans grande importance. Après tout, le disque du serveur n’était pas rempli. La partition principale n’utilisait qu’une petite partie de l’espace disponible.

Mais un clonage disque ne raisonne pas seulement en « données utilisées ». Il regarde aussi la taille des partitions et leur position sur le disque.

Et là, le problème est devenu très concret : l’ancien disque faisait environ 512 Go, tandis que le Samsung faisait environ 500 Go. Plus exactement, sous Linux, le Samsung apparaissait comme un disque de 465,8 Gio. La partition principale de l’ancien disque était trop grande pour être copiée telle quelle sur le nouveau support.

La leçon du moment : pour un clonage direct, un disque « 500 Go » n’est pas forcément un remplaçant naturel d’un disque de « 512 Go ».

C’est une erreur facile à faire. Elle semble même assez logique quand on n’a pas encore été confronté à la différence entre capacité commerciale, capacité réelle, Go, Gio, taille des partitions et contraintes de clonage. Mais au moment de migrer un serveur, cette nuance était devenue bloquante.

Première étape : contrôler le nouveau SSD

Avant de toucher au serveur, le nouveau Samsung a été branché sur un ordinateur via un adaptateur USB/NVMe, afin de vérifier qu’il était bien détecté et qu’il ne présentait pas d’erreur évidente.

Le système reconnaissait correctement le disque comme un Samsung SSD 970 EVO Plus. Le SMART n’était pas disponible via l’adaptateur USB, ce qui arrive souvent avec ce type de boîtier. Un test de lecture complet a donc été lancé depuis le terminal pour lire l’intégralité du disque, sans écrire dessus.

Le résultat a été rassurant : le disque a été lu du début à la fin, sans erreur d’entrée/sortie.

Ce contrôle ne remplace pas un vrai diagnostic SMART lorsque le disque est branché directement en NVMe interne, mais il permet déjà d’écarter un défaut manifeste avant de commencer une opération plus sensible.

Deuxième étape : comprendre que le clonage direct ne suffisait pas

Une fois la taille du disque actuel vérifiée, le problème est plus devenu clair : le disque source était plus grand que le disque cible. Et même si les données tenaient très largement sur le Samsung, la partition principale ne pouvait pas être copiée telle quelle.

Deux options existaient alors :

• acheter un NVMe plus grand, par exemple 1 To, pour faire un clonage direct sans se poser de question. Toutefois, l’actuelle techflation rendait la chose exorbitante.

• ou conserver le Samsung 500 Go, mais réduire proprement la partition de l’ancien disque avant de cloner.

La seconde option a été retenue, mais avec une précaution indispensable : faire d’abord une sauvegarde complète du disque actuel.

Troisième étape : faire une vraie sauvegarde avant de toucher aux partitions

Avant de redimensionner quoi que ce soit, un disque externe USB de 1,5 To a été branché au serveur. Rescuezilla a été utilisé pour créer une sauvegarde complète du disque NVMe actuel.

Cette étape change tout psychologiquement.

Sans sauvegarde, redimensionner la partition système d’un serveur peut vite devenir une opération anxiogène. Avec une sauvegarde complète, vérifiée, le risque ne disparaît pas, mais il s’affaiblit.

Une fois la sauvegarde terminée, Rescuezilla a permis de lancer une vérification de l’image. Les partitions importantes ont été validées. La partition swap, elle, a généré un avertissement normal : ce type de partition ne se vérifie pas comme une partition classique contenant des fichiers. Rien d’inquiétant à ce stade.

Le point important était ailleurs : il existait désormais une copie de sécurité avant de modifier le disque système.

Quatrième étape : réduire la partition avec GParted

La machine a ensuite été démarrée depuis Rescuezilla, qui permet aussi d’utiliser GParted.

L’ancien disque contenait trois partitions :

• une partition EFI de 512 Mio
• une grande partition ext4 pour le système YunoHost
• une petite partition swap

La grande partition ext4 occupait presque tout le disque de 512 Go. Pour qu’elle tienne sur le Samsung, elle a été réduite à 460 Gio. Ce choix permettait de rester très proche de la capacité utile du Samsung, tout en gardant une petite marge de sécurité.

La partition swap, placée après la partition principale, a ensuite été déplacée juste après elle. L’espace non alloué s’est retrouvé à la fin de l’ancien disque, ce qui permettait au nouvel agencement de tenir dans le Samsung.

Cette étape est probablement la plus importante de toute l’opération.
Le but n’était pas de recréer un disque, ni de formater, ni de repartir de zéro. Il s’agissait simplement de réduire proprement la partition existante, puis de repositionner la swap.

GParted a appliqué les opérations avec succès 🥳

Cinquième étape : cloner l’ancien disque réduit vers le Samsung

Une fois le disque source redimensionné, le Samsung a été branché au serveur via son adaptateur USB/NVMe.

Rescuezilla a ensuite été utilisé en mode clonage disque vers disque.

La source était l’ancien NVMe interne du serveur.
La destination était le Samsung SSD 970 EVO Plus branché en USB via l’adaptateur.

⚠️ Attention : c’est probablement l’erreur la plus dangereuse dans ce type d’opération : inverser source et destination revient à écraser le bon disque avec le disque vide.

Le clonage a copié les trois partitions :

• la partition EFI
• la partition système ext4
• la partition swap

Rescuezilla a également mis à jour les éléments nécessaires au démarrage. Le clonage s’est terminé sans erreur.

Sixième étape : remplacer physiquement le disque

Une fois le clonage terminé, la machine a été éteinte proprement.

Le Samsung cloné a été retiré de son adaptateur USB, puis installé physiquement à la place de l’ancien NVMe dans le serveur.

L’ancien disque n’a pas été effacé. Il a été conservé intact, comme disque de secours. C’est une précaution simple, mais précieuse : si un problème de démarrage était apparu, il aurait suffi de remettre l’ancien disque pour retrouver le serveur dans son état précédent.

Au redémarrage, le serveur a démarré normalement sur le Samsung.

Septième étape : vérifier que tout fonctionne

Après le premier démarrage, plusieurs vérifications ont été faites.

Le système voyait bien le Samsung comme disque principal :

• partition EFI montée sur /boot/efi
• partition ext4 montée sur /
• partition swap active.

Le contrôle SMART du Samsung, cette fois branché directement en NVMe interne, indiquait un état sain :

• test SMART global : réussi
• usure : 0 %
• erreurs d’intégrité des données : 0
• température correcte pour un NVMe après migration

Le système ne signalait aucun service en échec. Le diagnostic YunoHost était globalement bon. Les alertes restantes concernaient des éléments déjà connus : un domaine à renouveler prochainement et une application YunoHost signalée comme cassée dans le catalogue. Rien qui soit lié au changement de SSD.

À ce stade, l’opération pouvait être considérée comme réussie.

Derrière le clonage, une question de résilience

Cette migration n’est pas seulement une histoire de SSD. Elle révèle plusieurs choses utiles pour celles et ceux qui auto-hébergent leurs services.

La première : un clonage simple n’est simple que si le disque cible est au moins aussi grand que le disque source. Sinon, même avec très peu de données utilisées, la taille des partitions peut bloquer l’opération.

La deuxième : une sauvegarde n’est pas une option de confort. C’est ce qui permet de travailler avec une marge de sécurité. Dans cette expérience, la sauvegarde complète sur disque externe a permis de redimensionner le disque source avec beaucoup moins d’appréhension.

La troisième : Rescuezilla et GParted forment un duo très accessible, à condition de prendre son temps. Rescuezilla rassure pour la sauvegarde et le clonage. GParted permet d’adapter proprement les partitions lorsque la situation n’est pas aussi simple que prévu.

La quatrième : conserver l’ancien disque intact après ce type d’opération technique est une excellente assurance. Même si tout fonctionne, ce disque reste une copie physique complète de l’ancien système. Il ne règle pas tout, mais il offre une possibilité de retour rapide en cas de problème imprévu.

Sauvegarder, ce n’est pas seulement copier

Le point le plus intéressant, au fond, est peut-être celui-ci : sauvegarder ne se limite pas à produire des fichiers quelque part sur un NAS ou sur un autre support de stockage.

Une sauvegarde devient vraiment sérieuse et utile lorsqu’elle entre dans une chaîne complète :

• savoir où elle se trouve
• savoir comment elle a été produite
• vérifier qu’elle n’est pas corrompue
• comprendre comment elle pourrait servir
• tester, au moins partiellement, le scénario de retour

Cette migration de disques n’est sûrement pas encore une stratégie parfaite. Il reste des marges de progression : copie hors-site, chiffrement systématique selon les usages, test complet de restauration sur une autre machine, documentation plus formelle.

Mais elle marque une étape importante : le serveur principal a été sauvegardé, son disque a été redimensionné, son système a été cloné, puis il a redémarré sur un nouveau support.

Dans un parcours d’auto-hébergement, ce genre d’expérience compte. Non pas parce qu’elle serait spectaculaire, mais parce qu’elle rapproche la résilience de sa réalité la plus matérielle : un disque, une sauvegarde, une erreur possible, une méthode, et la capacité de reprendre la main.

PS : Merci à Genma pour son article sur la la règle des 3-2-1 ainsi qu’à Alex Hoyau pour l’inspiration du titre et les échanges autour du sujet.

L’article Pourquoi la sauvegarde c’est encore et toujours un sujet aussi compliqué ? est apparu en premier sur Souverain.

Au départ, je ne pensais pas écrire un article sur un certificat SSL.
Pour être tout à fait honnête, je ne pensais même pas changer celui de ce site.
Comme beaucoup de personnes qui administrent un site internet sans être ingénieur, expert TLS ou administrateur système de métier, j’avais fait ce que l’on fait souvent quand l’option est disponible chez son hébergeur : j’avais cliqué et puis c’est tout !

Chez OVH, l’hébergeur de ce site, la solution Let’s Encrypt était proposée par défaut. Gratuit, automatique, facile à activer. Un bouton, un peu d’attente, et le site passait en mode HTTPS. Dans le genre expérience utilisateur, difficile de faire plus rassurant et plus facile. Pas besoin de terminal, pas besoin de comprendre ce qu’est une clé privée, pas besoin de savoir ce qu’est une chaîne de certificats : le cadenas apparaissait dans le navigateur, et tout semblait en ordre 🔒.

Pour le grand public (dont je fais partie), un certificat SSL, ou plus exactement TLS aujourd’hui, sert à sécuriser la connexion entre un site web et ses visiteurs. C’est lui qui permet au navigateur d’afficher le fameux cadenas HTTPS. Il contribue à chiffrer les échanges, à éviter qu’ils circulent en clair sur le réseau, et à établir une relation de confiance entre l’internaute et le site consulté. Sans ce certificat, un site reste en HTTP, les navigateurs le signalent davantage, et l’expérience inspire immédiatement moins confiance.

Dit comme cela, l’affaire paraît simple : un certificat, un cadenas, un site sécurisé. Sujet réglé. Merci et au revoir !

Le hic, c’est que cette quête de souveraineté numérique et d’autonomie a une fâcheuse tendance (de temps en temps, je dois bien le reconnaître) à transformer un détail technique en une question d’une ampleur considérable.

On tire un fil presque par curiosité, et l’on se retrouve à regarder une chaîne entière de dépendances que l’on n’avait pas forcément vues venir.

Dans mon cas, tout a commencé avec un test réalisé via l’excellent outil de Patrice Andreani : Indépendance. Le nom est limpide, presque évident, et l’outil l’est tout autant dans son intention. Il permet d’évaluer concrètement le niveau de dépendance technologique d’un site internet.

Indépendance repose sur six grands piliers :

• les dépendances externes,
• l’hébergement,
• le fournisseur DNS,
• le bureau d’enregistrement du nom de domaine,
• le certificat TLS,
• les courriels et les serveurs MX.

Autrement dit, l’outil ne se contente pas de demander si un site essaye de se la jouer souverain. Il regarde ce qui se passe réellement sous le capot : qui héberge, qui résout le nom de domaine, qui fournit le certificat, quels services externes sont appelés, par où passent les courriels.
Il y a dans cette démarche quelque chose de très sain. On quitte le discours général pour entrer dans la vérification technique. On ne parle plus seulement d’intention, mais de dépendances mesurables.

Et dans cette enquête un peu artisanale, plusieurs outils de test de souveraineté numérique sont passés entre mes mains. Certains donnent des indications utiles, d’autres permettent de repérer quelques dépendances techniques, mais aucun ne m’a paru aussi lisible, aussi complet et aussi directement exploitable que celui de Patrice. L’outil permet de comprendre pourquoi un site dépend de tel ou tel acteur, où se situent les points de fragilité, et comment une évaluation peut devenir un début de pédagogie plutôt qu’un simple score.

Autre point important : cette solution est gratuite, open source, et son code est disponible sur GitLab. Et ce n’est pas un détail. Le fait de publier le code permet à chacun de regarder la méthode, de l’auditer, d’avoir des échanges et de proposer des améliorations. Aussi, le fait que cela soit hébergé sur GitLab, et non sur GitHub, a pour moi une portée symbolique dans un contexte où GitHub appartient à Microsoft (même si j’utilise encore GitHub 🤦‍♂️). Cela ne règle pas toutes les questions, bien sûr, mais cela montre une certaine cohérence dans la démarche : l’outil ne demande pas seulement aux autres d’être transparents, il expose aussi sa propre éthique.

Enfin, cette transparence donne du poids à la démarche, surtout lorsqu’on prétend mesurer une partie de la souveraineté numérique.

Modification du 8 juin : Depuis la publication de cet article, plusieurs échanges ont attiré l’attention sur une autre initiative digne d’intérêt : NextHop, un outil gratuit développé par Sylvain Rutten.

L’histoire commençait donc plutôt bien.

Je me lance dans le test avec une confiance plutôt assumée. Enfin, disons avec cette petite prétention de celui qui pense avoir plutôt bien travaillé. Après tout, ce projet et ce site existent précisément pour interroger ces sujets. Il me semblait vraiment avoir pris la peine de vérifier beaucoup de points. Je m’attendais donc à un score plutôt élevé. Peut-être même à frôler la perfection. Rien que cela.

Humilité oblige, le résultat n’était pas exactement à la hauteur de mes espérances.

Le score n’était pas catastrophique, loin de là. Mais il n’était pas parfait. Et l’un des points bloquants venait du certificat TLS : il était fourni par Let’s Encrypt.

Sur le moment, je l’avoue, cela m’a surpris. Let’s Encrypt fait partie de ces services que l’on utilise sans trop se poser de questions, précisément parce qu’ils fonctionnent bien. Comme je souhaite à nouveau le rappeler, chez OVH, il suffisait juste de l’activer. Le certificat se mettait en place automatiquement. Le renouvellement était géré lui aussi automatiquement. Le site passait en HTTPS sans complication. Pour quelqu’un qui n’est pas spécialiste du sujet, c’est plutôt l’expérience idéale.

Je ne m’étais donc jamais vraiment demandé qui était derrière. Je savais vaguement que c’était important, que cela permettait d’avoir le cadenas HTTPS, que sans cela le site serait moins sécurisé. Mais, comme beaucoup, je pense, je m’étais arrêté là. Le certificat était gratuit, reconnu par les navigateurs, proposé par mon hébergeur, et tout fonctionnait.

À la suite de ce test, j’ai commencé à regarder Let’s Encrypt de plus près :

Let’s Encrypt est une autorité de certification gratuite, automatisée, très largement utilisée, opérée par l’ISRG, une organisation américaine à but non lucratif. Il serait injuste de nier son rôle historique dans la sécurisation du Web. Sans Let’s Encrypt, une quantité immense de petits sites, d’associations, de blogs, de médias indépendants ou de services auto-hébergés seraient probablement restés en HTTP, ou auraient dû gérer des certificats payants avec une complexité peu compatible avec leurs moyens.

Let’s Encrypt a démocratisé HTTPS. C’est un fait, et c’est à mettre à son crédit.

Mais en poursuivant mes recherches, un chiffre m’a interpellé : Let’s Encrypt représenterait plus de 60 % des certificats TLS observés sur le Web. Et là, forcément, je me suis dit : « Heu… c’est quand même beaucoup ! »

C’est à ce moment-là que commence (encore) une nouvelle question de dépendance.

À nouveau, il ne s’agit pas de faire un amalgame. Une technologie peut être très majoritaire sans être immédiatement problématique. Linux est lui aussi très présent sur les serveurs web, et cela ne m’inquiète pas pour autant. La question n’est donc pas seulement celle de la part de marché. Elle est aussi celle de la nature de la dépendance, de la gouvernance, du cadre juridique, de la possibilité réelle de changer, et du rôle joué par cette brique dans la confiance du Web.

Alors j’ai continué à creuser.

J’ai vite compris que Let’s Encrypt ne devait pas être caricaturé. Ce n’est pas Google Cloud, AWS ou Microsoft Azure. Ce n’est pas un service commercial classique qui enfermerait volontairement ses utilisateurs. Le projet repose sur des standards ouverts, notamment ACME, il est largement intégré, très documenté, et soutenu par un écosystème large.

Mais j’ai aussi compris que sa gratuité avait une contrepartie logique : le service ne fournit pas de contrat ni d’engagement de niveau de service opposable comme peut le faire une offre contractuelle payante. En cas de panne, de problème d’automatisation ou de difficulté critique, l’utilisateur assume l’essentiel du risque opérationnel. Ce n’est pas scandaleux : c’est gratuit. Mais c’est précisément ce qui mérite d’être compris lorsqu’on parle d’infrastructures critiques.

Il existe aussi des enjeux de conformité. Certaines organisations doivent justifier précisément leurs choix techniques, leurs dépendances, leur traçabilité et leur résilience, notamment dans des contextes réglementaires exigeants. Là encore, cela ne veut pas dire que Let’s Encrypt serait inadapté par nature. Cela signifie simplement que son modèle gratuit, automatisé, très efficace pour le Web ouvert, ne répond pas toujours aux mêmes besoins qu’une relation contractuelle avec une autorité de certification choisie, documentée et intégrée dans une politique de conformité.

Il y a enfin un risque plus opérationnel : la durée courte des certificats impose un renouvellement automatisé impeccable. Quand tout est bien configuré, cela fonctionne très bien. Mais dans certains environnements complexes, hybrides ou mal documentés, une rupture dans la chaîne d’automatisation peut provoquer des erreurs TLS en production. Sur un petit site, cela peut être gênant. Sur une infrastructure critique, cela peut devenir beaucoup plus sérieux.

Soyons clairs : cela ne signifie pas que Let’s Encrypt lit le trafic HTTPS de vos visiteurs. C’est une confusion fréquente que j’ai remarquée lors de mes recherches. Le certificat permet d’établir la confiance et de chiffrer la connexion : il ne donne pas automatiquement accès au contenu des communications. Le sujet de souveraineté n’est donc pas celui d’une surveillance directe du trafic. Il porte plutôt sur une dépendance juridique, opérationnelle et industrielle : qui émet, révoque, journalise, automatise, devient incontournable dans une couche aussi essentielle du Web ?

À ce stade de mes recherches, la conclusion n’était pas : « Let’s Encrypt est un problème. » Ce serait trop simpliste, et probablement injuste (d’autres pourraient me dire que c’est faux).

La conclusion était plutôt : « Let’s Encrypt est un service remarquable, mais sa place dominante mérite d’être interrogée lorsqu’on parle de souveraineté numérique. »

Et comme je suis curieux, que j’aime parfois mettre les mains dans le cambouis, et que j’ai cette fâcheuse tendance à vouloir comprendre les détails une fois que j’ai commencé à tirer le fil, alors, j’ai décidé de chercher une alternative.

C’est ici que mon « enquête » a pris une tournure un peu moins confortable.

Dans ma grande naïveté et n’étant ni journaliste spécialisé, ni expert en infrastructures de confiance, je pensais qu’il serait assez simple de trouver une autorité européenne, de demander un certificat, de remplacer Let’s Encrypt, et de passer à autre chose. Après tout, un certificat reste un certificat, non ?

Évidemment, non 😒

Plus je cherchais, plus je découvrais que le sujet était moins simple que prévu. Certaines offres étaient payantes. D’autres étaient difficiles à comprendre. Certaines autorités de certification semblaient sérieuses, mais les tarifs montaient vite. Au départ, je m’étais dit : s’il faut payer quelques euros pour la cohérence, pourquoi pas. Puis, au fil des recherches, les prix grimpaient, les conditions se complexifiaient, et je commençais à me dire que cette histoire de certificat gratuit activé par défaut m’avait peut-être rendu dépendant sans même m’en rendre compte.

C’est une sensation étrange : vous n’avez jamais vraiment choisi Let’s Encrypt, vous l’avez simplement activé parce que votre hébergeur vous le proposait, et lorsque vous voulez regarder ailleurs, vous découvrez que le confort du départ a créé une forme de réflexe et de dépendance.

C’est à ce moment-là que je suis revenu vers Patrice Andreani.

Avec beaucoup de simplicité, et en quelques heures à peine, il m’a indiqué une piste : Actalis.
Il a été très clair : il ne l’avait pas testée lui-même, mais la solution lui paraissait intéressante sur le papier. Cette précision est importante. Il ne m’a pas vendu une solution, il ne m’a pas promis que tout fonctionnerait, il m’a simplement orienté vers une option qui méritait d’être regardée.

Je ne connaissais pas Actalis, je suis donc allé voir : société italienne, autorité de certification européenne, rattachée au groupe Aruba, reconnue dans l’écosystème des certificats. Sur le papier, l’option avait de quoi retenir l’attention. Restait à comprendre si elle pouvait réellement répondre à mon besoin, et surtout si elle proposait une offre accessible.

Bonne nouvelle : Actalis propose bien une offre gratuite.

Mais nuance : je ne peux pas dire que cette offre gratuite m’ait sauté aux yeux immédiatement. Il a fallu chercher un peu. L’offre existe, mais elle n’a pas exactement l’évidence d’un gros bouton « certificat gratuit ici » au milieu de la page. À force de fouiller, j’ai fini par trouver l’URL directe du plan gratuit.

Là encore, l’expérience raconte quelque chose : Let’s Encrypt est devenu si intégré, si automatique, si présent dans les interfaces d’hébergement, que l’on oublie la différence entre une solution devenue standard de fait et une alternative encore peu connue du grand public. Actalis existe, l’offre gratuite aussi, mais le chemin pour y arriver demande déjà un peu plus de volonté.

Une fois cette piste trouvée, il fallait encore la comparer sérieusement.

Changer pour changer n’avait aucun intérêt. Remplacer Let’s Encrypt uniquement pour pouvoir dire que l’on a remplacé Let’s Encrypt n’aurait pas grand intérêt.
Le vrai sujet était de savoir ce qu’Actalis changeait réellement.

Actalis apporte d’abord un argument que Let’s Encrypt ne peut pas offrir : une autorité de certification européenne, italienne, intégrée à l’écosystème européen de la confiance numérique. Dans une réflexion sur la souveraineté numérique, ce n’est pas anecdotique. Le certificat TLS participe à la chaîne de confiance du site. Choisir l’autorité qui l’émet, ce n’est donc pas seulement choisir un prestataire technique : c’est aussi choisir un acteur qui intervient dans une brique fondamentale du Web.

Mais rigueur oblige !

Le certificat gratuit d’Actalis est un certificat DV, pour Domain Validation. Cela signifie qu’il prouve essentiellement le contrôle du domaine. Il ne valide pas fortement l’identité de l’organisation derrière le site, contrairement à d’autres catégories comme les certificats OV, EV ou certains certificats qualifiés. Autrement dit, le fait qu’Actalis soit une autorité européenne ne transforme pas automatiquement un certificat DV gratuit en certificat « souverain » au sens strict du terme.

Son intérêt est ailleurs.

Actalis montre qu’il existe une alternative européenne crédible, gratuite pour certains usages de base, compatible avec les standards du Web, et capable de fournir un certificat reconnu par les navigateurs. Mais cela ne remplace pas une stratégie complète d’autonomie.
Il faut aussi regarder les limites. Actalis n’a pas « l’universalité » pratique de Let’s Encrypt. Ce dernier est intégré presque partout : hébergeurs, panels, YunoHost, scripts, documentations, tutoriels. Toute une culture technique s’est construite autour de son usage. Actalis propose bien l’usage d’ACME, notamment via Certbot avec des identifiants EAB fournis dans l’espace client. Pour un administrateur habitué à gérer un serveur, la procédure peut être relativement simple. Ma réserve porte plutôt sur le parcours d’un utilisateur grand public ou d’un site hébergé en mutualisé : l’expérience reste moins directement intégrée que les déploiements Let’s Encrypt déjà présents dans de nombreux panneaux d’hébergement.
Dans mon cas, comme je passais par OVH et non par une automatisation complète, il a fallu générer un CSR, gérer une clé privée, valider le domaine, récupérer le certificat, extraire la chaîne intermédiaire, puis importer tout cela manuellement.

Autre limite : Actalis reste très petit face à Let’s Encrypt. Les statistiques de W3Techs donnent à Let’s Encrypt une part de marché supérieure à 60 % dans les certificats TLS, tandis qu’Actalis reste très loin derrière (~ 0,7%). Cela ne rend pas Actalis moins intéressant, mais cela rappelle que l’on ne remplace pas un standard de fait par un simple changement individuel et isolé. On teste une alternative, on documente une possibilité, on ouvre une voie. On ne renverse pas « un équilibre mondial » en changeant le certificat d’un site personnel.

Enfin, il ne faut pas idéaliser Actalis sous prétexte qu’il est européen. Une autorité européenne n’est pas automatiquement parfaite. Comme toutes les autorités de certification, elle doit être reconnue par les navigateurs, respecter des règles strictes, être auditée, corriger ses éventuels incidents, et maintenir la confiance dans la durée. La souveraineté numérique ne consiste pas à remplacer une dépendance américaine par une confiance aveugle dans n’importe quel acteur européen. Elle consiste plutôt à choisir en connaissance de cause, avec des critères explicites, des limites identifiées, et une capacité de vérification.

À ce stade, ma décision était prise.

Non, Let’s Encrypt n’était pas devenu l’ennemi.
Non, Actalis n’était pas une solution parfaite.
Non, je n’allais pas résoudre la souveraineté numérique du Web avec un simple certificat TLS.

Mais l’expérience valait la peine d’être menée.

D’abord parce qu’elle permettait de tester concrètement une alternative européenne. Ensuite parce qu’elle obligeait à comprendre ce que l’on manipule réellement lorsque l’on parle de ce sujet. Enfin parce qu’elle pouvait servir à d’autres : celles et ceux qui, comme moi, ne sont pas spécialistes du sujet, mais veulent comprendre comment passer d’un constat de dépendance à une action technique concrète.

C’est donc à ce moment-là que l’histoire bascule vers le tutoriel.

Et là, les choses se sont révélées un peu plus sportives que prévu.

Il a fallu :

• générer une demande de certificat,
• comprendre la différence entre un CSR et une clé privée,
• choisir la bonne méthode de validation,
• ajouter une entrée TXT chez OVH,
• corriger une erreur liée aux noms de domaine,
• découvrir que le certificat couvrait finalement le domaine et le www,
• récupérer les fichiers fournis par Actalis,
• extraire la chaîne intermédiaire depuis un fichier .p7b,
• supprimer l’ancien certificat Let’s Encrypt chez OVH avant de pouvoir importer le nouveau,
• attendre que l’interface OVH se mette à jour,
• puis vérifier en ligne de commande que le site servait bien le certificat Actalis.

Autrement dit : exactement le genre d’opération que l’on imagine simple tant qu’on ne l’a pas faite soi-même.

Cet article raconte donc une bascule réelle, avec ses hésitations, ses erreurs, ses messages d’alerte, ses délais d’attente et ses vérifications. Ce n’est surtout pas un guide « certifié » écrit depuis une documentation officielle.
C’est un retour d’expérience concret : comment ce site est passé de Let’s Encrypt à Actalis, pourquoi cette démarche peut avoir du sens dans une réflexion sur la souveraineté numérique, et quelles précautions prendre avant de se lancer.

Tutoriel : remplacer Let’s Encrypt par Actalis chez OVH, sans perdre le HTTPS en route

Avant d’entrer dans le détail, je préfère apporter une précision importante : il ne s’agit pas là d’une procédure universelle applicable à tous les hébergeurs, à toutes les configurations ou à toutes les autorités de certification. Mais elle peut servir de base très concrète à celles et ceux qui veulent comprendre ce qui se passe réellement lorsqu’on remplace un certificat TLS automatique par un certificat personnalisé.

Dans mon cas, le point de départ était simple :

• le domaine était géré chez OVH
• le site était hébergé chez OVH
• Let’s Encrypt était déjà activé
• le site fonctionnait correctement en HTTPS
• l’objectif était de remplacer ce certificat par un certificat Actalis
• le certificat devait couvrir à la fois le domaine principal et sa version avec www.

Sur le papier, cela paraît raisonnable. Dans la pratique, il a fallu avancer avec méthode.

Comprendre ce qu’Actalis me demande : un CSR, pas une clé privée

La première étape consiste à demander un certificat chez Actalis.

Dans le formulaire, Actalis propose plusieurs options, dont la génération automatique d’un CSR. Pour rester dans une logique de maîtrise, j’ai préféré ne pas laisser un tiers générer cette demande à ma place.

Le bon choix, dans mon cas, était donc de cocher la case J’ai déjà un fichier CSR.
Un CSR, pour Certificate Signing Request, est une demande de certificat. Il contient notamment le nom de domaine concerné et une clé publique. En revanche, il ne contient pas la clé privée.

C’est un point essentiel : la clé privée doit rester sous votre contrôle.

Le principe est donc le suivant :

• CSR → transmis à Actalis
• clé privée → conservée par vous

ATTENTION : La clé privée ne doit pas être envoyée à Actalis. Elle servira plus tard, au moment de l’import du certificat chez OVH.

Générer la clé privée et le CSR

Sur macOS, j’ai utilisé le Terminal et OpenSSL.
J’ai d’abord créé un dossier dédié :

mkdir -p ~/certificats-souverain
cd ~/certificats-souverain

Puis j’ai généré un premier fichier de configuration pour créer un CSR.

Au départ, j’ai tenté de générer un CSR couvrant à la fois :

souverain.ovh
www.souverain.ovh

Techniquement, cela avait du sens. Beaucoup de certificats TLS modernes utilisent des SAN, (pour Subject Alternative Names), afin de couvrir plusieurs noms dans un même certificat.
Mais Actalis m’a renvoyé une erreur : « Nombre de champs SAN non valide pour un seul hôte »
Traduction : pour ce type de demande, Actalis ne voulait pas de plusieurs noms dans le CSR.

J’ai donc refait un CSR uniquement pour mon domaine principal, c’est-à-dire : souverain.ovh avec cette configuration :

cat > csr-souverain-seul.conf <<'EOF'
[req]
default_bits = 2048
prompt = no
default_md = sha256
distinguished_name = dn
req_extensions = req_ext

[dn]
C = FR
CN = souverain.ovh

[req_ext]
subjectAltName = @alt_names

[alt_names]
DNS.1 = souverain.ovh
EOF

openssl req -new -nodes -newkey rsa:2048 \
-keyout souverain.ovh-single.key \
-out souverain.ovh-single.csr \
-config csr-souverain-seul.conf

Cette commande crée deux fichiers :

• souverain.ovh-single.key → la clé privée
• souverain.ovh-single.csr → la demande de certificat

ATTENTION : Le fichier le plus sensible est la clé privée, c’est-à-dire : souverain.ovh-single.key
Il ne faut pas la publier, ne pas la coller dans Actalis, ne pas la partager dans une capture d’écran, ne pas l’envoyer par courriel.

Vérifier le contenu du CSR

Avant de copier le CSR dans Actalis, j’ai vérifié qu’il contenait bien uniquement le domaine attendu :

openssl req -in souverain.ovh-single.csr -noout -text | grep -A2 "Subject Alternative Name"

Le résultat devait afficher :

X509v3 Subject Alternative Name:
DNS:souverain.ovh

C’est seulement après cette vérification que j’ai copié le CSR :

cat souverain.ovh-single.csr | pbcopy

Sur macOS, la commande ne renvoie rien dans le Terminal. C’est normal : elle copie simplement le contenu dans le presse-papiers.

Ensuite, dans Actalis, il faut coller ce bloc dans le champ CSR. Il commence par :
—–BEGIN CERTIFICATE REQUEST—–
et se termine par :
—–END CERTIFICATE REQUEST—–

Choisir la validation DNS chez Actalis

Actalis propose plusieurs méthodes de validation du domaine. Dans mon cas, j’ai choisi la validation par enregistrement TXT DNS. C’est la méthode la plus propre lorsqu’on gère son domaine chez OVH, car elle consiste simplement à prouver que l’on contrôle la zone DNS du domaine.

Actalis m’a demandé d’ajouter une entrée TXT de ce type :

actalis-dcv=xxxxxxxxxxxxxxxxxxxx

Chez OVH, il faut aller dans :
Domaines → votre nom de domaine → Zone DNS → Ajouter une entrée → TXT

Puis renseigner :

Sous-domaine : @
Type : TXT
Valeur : actalis-dcv=xxxxxxxxxxxxxxxxxxxx
TTL : par défaut

Le @ signifie que l’entrée est placée à la racine du domaine.

Une fois l’entrée ajoutée, il faut patienter un peu, puis vérifier qu’elle est bien visible publiquement :

dig TXT souverain.ovh +short

Dans mon cas, le résultat affichait bien l’entrée Actalis :

"actalis-dcv=..."

À ce moment-là seulement, il était possible de retourner chez Actalis et de poursuivre la validation.

Recevoir le certificat Actalis

Après validation, Actalis m’a envoyé un courriel indiquant que le certificat était émis. Dans ce courriel, il y avait plusieurs éléments importants. D’abord, des codes de gestion et de révocation. Ces informations doivent rester privées. Elles ne doivent pas être publiées dans une capture d’écran ou dans un article. Ensuite, Actalis fournissait deux fichiers ZIP.
Dans mon cas, les fichiers contenaient :

• Le fichier .cer correspond au certificat serveur.
• Le fichier .p7b contient la chaîne de certificats, c’est-à-dire les éléments permettant de relier le certificat serveur à l’autorité de certification reconnue par les navigateurs.

À ce stade, le formulaire d’OVH ne peut pas encore être rempli au hasard. Il faut identifier précisément les trois éléments nécessaires :

• le certificat serveur
• la clé privée
• la chaîne de certificats

Extraire et vérifier le certificat reçu

J’ai d’abord extrait le fichier .cer :

unzip -o ~/Downloads/"CCR Certificats Souverain"/Certificato_*.zip -d .

Puis j’ai vérifié son contenu :

openssl x509 -in Certificato_*.cer -noout -subject -issuer -dates -ext subjectAltName

Et là, bonne surprise : même si le CSR ne contenait que souverain.ovh, le certificat émis par Actalis couvrait finalement les deux noms :

• DNS:www.souverain.ovh
• DNS:souverain.ovh

Cela signifie que, dans mon cas, une seule demande Actalis suffisait pour couvrir souverain.ovh ainsi que www.souverain.ovh

C’est un point important, car au départ je pensais devoir faire deux demandes séparées.

Vérifier que le certificat correspond bien à la clé privée

Avant d’importer quoi que ce soit chez OVH, il fallait vérifier que le certificat reçu correspondait bien à la clé privée générée au départ.

J’ai utilisé cette commande :

openssl x509 -noout -modulus -in Certificato_*.cer | openssl md5 && \
openssl rsa -noout -modulus -in souverain.ovh-single.key | openssl md5

Le but n’est pas d’utiliser la fonction MD5 pour sécuriser quoi que ce soit. Ici, le calcul demandé sert uniquement à comparer deux empreintes locales. Les deux lignes doivent être identiques.
Dans mon cas, elles l’étaient. Cela confirmait que le certificat Actalis reçu correspondait bien à ma clé privée.

Convertir le fichier .p7b en chaîne de certificats exploitable

OVH demande une chaîne de certificats dans un format texte compatible.

J’ai donc extrait le fichier .p7b :

unzip -o ~/Downloads/"CCR Certificats Souverain"/Certificate_*.zip -d .

Puis je l’ai converti en PEM :

openssl pkcs7 -inform DER -in Certificate_*.p7b -print_certs -out actalis-chain-from-p7b.pem

Ensuite, j’ai vérifié qu’il contenait bien des certificats :

grep "BEGIN CERTIFICATE" actalis-chain-from-p7b.pem

Dans mon cas, il y avait deux certificats et j’ai vérifié lesquels :

grep -E "subject=|issuer=" actalis-chain-from-p7b.pem

Le fichier contenait :

Actalis Domain Validation Server CA G3
souverain.ovh

Pour OVH, il fallait isoler uniquement le certificat intermédiaire :

awk 'BEGIN{n=0} /-----BEGIN CERTIFICATE-----/{n++} n==1{print} /-----END CERTIFICATE-----/ && n==1{exit}' actalis-chain-from-p7b.pem > actalis-intermediate.pem

Puis vérifier :

openssl x509 -in actalis-intermediate.pem -noout -subject -issuer

Le résultat devait correspondre à l’autorité intermédiaire Actalis :

subject=... CN=Actalis Domain Validation Server CA G3
issuer=... CN=Actalis Authentication Root CA

Renommer les fichiers pour éviter les erreurs

Avant l’import dans OVH, j’ai créé des copies avec des noms plus explicites :

cp Certificato_*.cer actalis-souverain.ovh-certificat.cer
cp souverain.ovh-single.key actalis-souverain.ovh-cle-privee.key
cp actalis-intermediate.pem actalis-souverain.ovh-chaine-ca.pem

À ce stade, les trois fichiers nécessaires étaient prêts :

• actalis-souverain.ovh-certificat.cer → certificat SSL
• actalis-souverain.ovh-cle-privee.key → clé privée
• actalis-souverain.ovh-chaine-ca.pem → chaîne CA / intermédiaire

Importer le certificat personnalisé chez OVH

C’est ici que les choses se sont compliquées. Dans OVH, il faut aller dans :
Web Cloud → Hébergements → votre hébergement → Certificats SSL
Puis cliquer sur : Import de votre propre certificat SSL. OVH demande alors trois champs :

• le certificat
• la clé privée non chiffrée
• la chaîne de certificats

J’ai donc copié successivement les trois fichiers.

Pour le certificat :

cat actalis-souverain.ovh-certificat.cer | pbcopy

Pour la clé privée :

cat actalis-souverain.ovh-cle-privee.key | pbcopy

Pour la chaîne de certificats :

cat actalis-souverain.ovh-chaine-ca.pem | pbcopy

Chaque contenu doit être collé dans le bon champ OVH.

Mais au moment de valider, OVH a refusé l’import. La raison était simple : Let’s Encrypt était encore actif sur le domaine.

Le piège OVH : supprimer Let’s Encrypt avant d’importer Actalis

C’est probablement le point le plus important de tout ce tutoriel. Chez OVH, il ne suffit pas d’importer le nouveau certificat par-dessus l’ancien. Si Let’s Encrypt est encore actif sur le domaine concerné, l’import peut échouer. Dans mon cas, il a fallu désactiver le certificat Let’s Encrypt déjà présent.
Première tentative : j’ai désactivé SSL sur le domaine principal, c’est-à-dire : souverain.ovh
Puis j’ai attendu que l’interface OVH se mette à jour.
L’entrée a fini par disparaître, mais l’import Actalis échouait encore. Pourquoi ? Parce que le certificat Let’s Encrypt était encore actif sur : www.souverain.ovh
Il a donc fallu désactiver également SSL sur www.souverain.ovh.
C’est un moment un peu délicat, car on touche à un site en production. Il peut y avoir une courte période pendant laquelle le HTTPS n’est pas encore correctement rétabli. Il vaut mieux ne pas faire cela dans la précipitation, et éviter de multiplier les manipulations dans tous les sens.

La bonne séquence, dans mon cas, a été :

• désactiver SSL sur souverain.ovh
• attendre que l’interface OVH se mette à jour
• désactiver SSL sur www.souverain.ovh
• attendre à nouveau
• relancer l’import du certificat Actalis

Hourra !

Après cette seconde désactivation, l’import a finalement été accepté.

Attendre OVH : l’interface ne se met pas à jour immédiatement

Même après validation de l’import, tout n’a pas été instantané. Pendant un moment, l’interface OVH ne montrait pas encore clairement le nouveau certificat. De mon côté, les lignes liées à l’ancien certificat ne disparaissaient pas immédiatement, et l’état affiché n’était pas parfaitement synchronisé avec la réalité.

J’ai donc vérifié directement ce que le site servait réellement comme certificat.

Première vérification :

echo | openssl s_client -connect souverain.ovh:443 -servername souverain.ovh 2>/dev/null | openssl x509 -noout -subject -issuer -dates

À un moment intermédiaire, le site servait encore un certificat OVH mutualisé :

subject=CN=cluster129.hosting.ovh.net
issuer=Let's Encrypt

Ce n’était pas encore bon, mais cela ne signifiait pas forcément que l’opération avait échoué. OVH était simplement encore en train de propager la nouvelle configuration.

Il a fallu attendre.

Puis, après quelques minutes, le bon certificat est apparu :

subject=CN=souverain.ovh
issuer=... Actalis Domain Validation Server CA G3

L’interface OVH a fini elle aussi par afficher le certificat comme actif, avec :

Type : Custom
Domaine principal : souverain.ovh
SAN : www.souverain.ovh
État : Actif

Le petit + visible dans l’interface OVH indiquait simplement que le certificat couvrait aussi un nom supplémentaire, ici www.souverain.ovh.

Vérifier le domaine principal et le www

Dernière étape : vérifier que les deux noms servent bien le certificat Actalis.

Pour le domaine principal :

echo | openssl s_client -connect souverain.ovh:443 -servername souverain.ovh 2>/dev/null | openssl x509 -noout -subject -issuer -dates

Pour le www :

echo | openssl s_client -connect www.souverain.ovh:443 -servername www.souverain.ovh 2>/dev/null | openssl x509 -noout -subject -issuer -dates

Dans les deux cas, le résultat devait afficher :

issuer=... Actalis Domain Validation Server CA G3

C’est seulement à ce moment-là que l’on peut considérer que la bascule est réellement terminée.

Ce qu’il faut retenir avant de se lancer

Cette opération m’a appris plusieurs choses. D’abord, il ne faut jamais perdre la clé privée. Dans mon cas, elle était contenue dans actalis-souverain.ovh-cle-privee.key
Sans cette clé, le certificat reçu ne peut pas être utilisé correctement.
Ensuite, il ne faut jamais exposer cette clé privée. Pas de capture d’écran, pas de copie dans un document public, pas d’envoi par courriel.

Il faut aussi conserver les trois fichiers finaux :

• actalis-souverain.ovh-certificat.cer
• actalis-souverain.ovh-cle-privee.key
• actalis-souverain.ovh-chaine-ca.pem

Autre point important : le certificat Actalis obtenu dans cette procédure est valable environ 90 jours. Dans mon cas, il expirait le 29 août 2026.

C’est un point essentiel, car OVH ne renouvellera probablement pas automatiquement un certificat personnalisé importé manuellement comme il le faisait avec Let’s Encrypt.

Il faudra donc prévoir un renouvellement avant l’expiration depuis l’interface d’administration de mon espace sur Actalis.

Enfin, l’entrée DNS TXT utilisée pour la validation Actalis peut rester en place. Elle ne gêne pas le fonctionnement du site. Elle peut même être utile en cas de renouvellement ou de nouvelle validation.

Au final, cette bascule n’a rien changé pour le visiteur, mais

Le site s’ouvre toujours en HTTPS. Le cadenas est toujours là. Les pages se chargent normalement. Personne, en arrivant ici, ne se dit : « Tiens, ce certificat TLS a l’air plus européen que ce matin. » L’objectif n’était pas de rendre le site plus spectaculaire, l’objectif était beaucoup plus simple : comprendre une dépendance, tester une alternative, documenter la procédure, et voir si cette alternative pouvait fonctionner concrètement chez OVH.
La réponse est oui.
Pour autant, cette bascule valait la peine. Elle m’a obligé à comprendre ce que je faisais. Elle m’a permis de remplacer un choix par défaut par un choix assumé. Elle m’a aussi donné matière à écrire cet article et ce tutoriel, avec les erreurs, les attentes, les détours et les petites surprises qui ne figurent pas toujours dans les documentations officielles.

Et puis il y a le résultat, très concret.

Depuis cette modification, j’obtiens 100 points sur 100 au test Indépendance de Patrice.
Ce n’est ni un diplôme, ni une certification, ni une garantie absolue. Un score reste un indicateur, pas une vérité gravée dans le marbre. Mais après avoir tiré ce fil, compris le problème, suivi la piste Actalis, traversé l’import OVH et vérifié le certificat en ligne de commande, voir ce 100/100 apparaître a eu une saveur particulière.

Cette histoire avait commencé par un clic presque machinal sur une option par défaut. Elle se termine avec une brique technique mieux comprise, un choix plus assumé, et cette petite satisfaction que procure une dépendance que l’on a enfin réussi à regarder en face.

Un remerciement particulier à Patrice Andreani, d’abord pour avoir développé son outil « Indépendance », mais aussi pour avoir pris le temps d’entendre mes questions, mes critiques, et de m’orienter vers la piste Actalis qui a rendu ce test possible.

Si des spécialistes voient dans cette démarche des erreurs, des limites ou une méthode plus simple pour atteindre le même résultat, leurs remarques sont les bienvenues : ce tutoriel ne prétend pas être une procédure dans les règles de l’art, mais une tentative documentée, perfectible, et ouverte à la discussion.

Enfin, si ce retour d’expérience peut aider d’autres personnes à comprendre ce qu’il y a derrière leur cadenas HTTPS, alors ce petit détour par les certificats TLS aura largement valu le temps passé.

L’article Tout est parti d’un score : comment un test m’a conduit de Let’s Encrypt vers Actalis est apparu en premier sur Souverain.

L’OW2con est LA conférence annuelle organisée par OW2, communauté européenne dédiée aux logiciels open source. L’édition 2026, organisée les 2 et 3 juin à Paris-Châtillon, avait un thème particulièrement en phase avec les préoccupations de ce site : Open Source and Open Models to Drive European Sovereignty, autrement dit le rôle de l’open source et des modèles ouverts dans la construction d’une souveraineté numérique européenne. Pendant deux jours, développeurs, entreprises, chercheurs, associations, acteurs publics et membres de communautés libres s’y sont retrouvés pour discuter autant de technique que de modèles économiques, d’interopérabilité, de résilience, de confiance et d’indépendance technologique.

Si j’ai découvert cet événement, c’est grâce à Genma. C’est lui qui m’en a parlé, qui m’a donné envie d’en savoir davantage, qui m’a encouragé à m’inscrire et qui m’a ouvert la porte de cette journée. Qu’il en soit ici très sincèrement remercié. Je le connaissais déjà à travers ses écrits, ses engagements et ses sujets de prédilection, mais le rencontrer AFK fut aussi l’un des grands moments de cette journée. J’ai découvert quelqu’un d’encore plus ancré dans cette communauté que je ne l’imaginais, entouré d’un réseau considérable, visiblement très apprécié, et toujours dans cette même disposition : expliquer, transmettre, relier les personnes entre elles.

Avant même que la journée ne commence vraiment, Genma a eu la gentillesse de m’offrir un livre : Ada & Zangemann : Un conte sur les logiciels, le skateboard et la glace à la framboise. Il écrit par Matthias Kirschner, président de la Free Software Foundation Europe, et vise à faire comprendre aux enfants et aux jeunes adolescents ce que signifie le logiciel libre. Le symbole était parfait. Entrer dans une journée consacrée à l’open source par un livre destiné à rendre ces sujets accessibles aux plus jeunes, c’était déjà poser une question centrale : comment sortir ces débats des cercles spécialisés pour les transmettre plus largement ?

Orange Gardens, un cadre idéal pour une journée d’échanges

L’événement se tenait chez Orange, sur le campus d’Innovation, Recherche et Développement de Châtillon, plus connu sous le nom d’Orange Gardens. On y circule dans un espace vaste, agréable, lumineux, pensé pour la collaboration et les rencontres. L’environnement contribue à cette sensation d’ouverture : on n’est pas dans un salon impersonnel, mais dans un lieu où les échanges semblent pouvoir se prolonger naturellement entre deux conférences.

J’arrive, je récupère mon badge et très vite la journée prend son rythme : dense, intense, presque trop courte. Les conférences s’enchaînent, mais les rencontres aussi. Et c’est là que l’OW2con prend une dimension particulière.

Je dois d’ailleurs le préciser d’emblée : je n’ai pas pu assister à l’intégralité des conférences. Non par négligence, ni par manque d’intérêt, mais parce que les conversations étaient parfois si passionnantes, si riches humainement et intellectuellement, qu’il devenait impossible de les interrompre brutalement pour retourner en salle de conférence. J’ai donc manqué certains débuts, parfois certaines interventions entières. Je pourrais le regretter. En réalité, je crois que cela faisait aussi partie de l’expérience. Dans un événement de cette nature, le contenu n’est pas seulement sur scène. Il est aussi dans les autres pièces, autour d’un café, pendant un déjeuner, dans ces discussions où des parcours différents se croisent et où les idées circulent.

Une conférence en anglais, mais pas un mur linguistique

L’OW2con se déroule en anglais. La majorité des participants croisés étaient français, mais les intervenants et les visiteurs venaient aussi d’autres pays. Le choix de l’anglais est donc parfaitement compréhensible. L’open source ne s’arrête pas aux frontières françaises, et un événement filmé, retransmis et ouvert à l’écosystème international doit pouvoir circuler au-delà de notre seul espace national.

Pour celles et ceux qui, comme moi, n’ont pas un anglais oral irréprochable, il ne faut pas se laisser impressionner. Mon ressenti est même plutôt rassurant : l’anglais parlé par des Français ou des Européens non anglophones reste souvent très accessible. Les mots sont bien détachés, les idées sont souvent construites avec une logique française, et l’on suit beaucoup mieux qu’on pourrait le craindre. Ce n’est pas un reproche, bien au contraire. Cela fait aussi partie du charme de l’événement : un anglais de travail, international, imparfait parfois, mais utile, vivant, compréhensible, au service de la circulation des idées.

Venir sans être « du sérail »

Je n’arrivais pas à l’OW2con avec la posture d’un expert (surtout pas). Je ne suis pas développeur, ingénieur ni DSI. Je ne suis pas non plus, ce qu’on appelle parfois, un décideur. Je suis un citoyen qui essaye de comprendre ce monde numérique, d’en observer les dépendances, les contradictions, les promesses, puis d’en partager l’expérience pour sensibiliser le grand public à deux sujets qui me semblent décisifs : l’open source et la souveraineté numérique.

C’est important de le dire, car je me suis rendu à cet événement avec une vraie interrogation sur ma légitimité. Les sujets traités ici allaient-ils rencontrer un intérêt dans un environnement aussi spécialisé ? Est-ce que mes questions, parfois formulées depuis une position extérieure, allaient être entendues ?

Je n’y allais pas pour faire du « business », ni pour faire du « réseautage » au sens classique du terme. Je n’y allais pas non plus pour distribuer des cartes de visite. Je venais en spectateur curieux, avec l’envie de confronter mes idées, d’écouter, de comprendre, et peut-être de mesurer si ce travail de vulgarisation autour de la souveraineté numérique pouvait trouver un écho auprès de ceux qui fabriquent, défendent et structurent l’open source au quotidien.

La réponse fut oui. Très clairement oui.

J’ai reçu de nombreux retours, des sollicitations, des conseils, des objections constructives, des idées nouvelles. J’ai pu expliquer ma position, mes angles, mes préoccupations. J’ai aussi découvert que certaines intuitions développées ici rejoignaient des préoccupations très concrètes chez des acteurs de terrain. Comme souvent, Genma avait vu juste : il y avait bien une liaison à faire entre deux mondes qui se regardent encore trop peu. Celui des communautés techniques et celui du récit public que j’essaie de construire et de développer. Celui de l’open source comme pratique professionnelle, et celui de la souveraineté numérique comme enjeu démocratique.

BPCE, OW2, TOSIT : quand l’open source devient une brique solide de l’organisation dans l’entreprise

La première conférence à laquelle j’ai assisté était celle de Florian Caringi, du groupe BPCE : A FOSS strategy multi-perspective look from BPCE, OW2 and TOSIT. Florian Caringi est directeur adjoint Data & Open Source chez BPCE, président élu d’OW2 depuis mars 2026, et vice-président de TOSIT, structure qui rassemble de grandes organisations utilisatrices autour de l’open source.

À mes yeux, c’est un exemple de réussite organisationnelle. L’open source n’y apparaît pas comme une simple préférence technique, ni comme un argument de communication, mais comme une méthode, une organisation de travail, une culture à structurer et à faire vivre.

Pour aller plus loin, la présentation (en anglais) de Florian Caringi est disponible en ligne et permet de mieux comprendre la démarche open source mise en place chez BPCE.

J’ai eu la chance d’échanger brièvement avec lui après sa conférence. Ce que je lui ai dit, au fond, tient en une idée : il manque encore au monde de l’open source une dernière brique, celle du récit de réussite.

La méthode présentée par Florian Caringi mérite d’être davantage partagée. Pas pour transformer cette expérience en slogan, ni un pour en faire un récit trop flatteur, mais parce qu’il est nécessaire de montrer ce qui fonctionne. Dans le monde du logiciel libre et de l’open source, nous avons, et je m’inclus dans ce « nous », parfois trop d’humilité face au succès. Nous savons décrire les risques, les dépendances, les limites des modèles propriétaires, les vertus de l’ouverture. Mais nous racontons encore trop peu les réussites concrètes, les organisations qui changent, les méthodes qui progressent, les entreprises qui apprennent à travailler autrement.

Or ce que Florian Caringi a présenté est précisément de cet ordre : une réussite professionnelle, sérieuse, solide. Elle mérite d’être assumée comme telle. Sans arrogance, sans emphase inutile, sans promesse artificielle. Simplement en assumant pleinement la valeur de ce qui a été construit.

Sur ce point, notre échange fut très positif. J’ai eu le sentiment que certaines prises de conscience, qui auraient peut-être été plus difficiles à formuler il y a quelques années, deviennent aujourd’hui audibles. L’open source ne peut plus seulement demander à être reconnu. Il doit aussi apprendre à raconter pourquoi il fonctionne, où il fonctionne, et ce qu’il transforme concrètement.

Pour reprendre une idée que défend Cristina Caffarra, la souveraineté numérique ne peut pas rester au seul niveau des intentions politiques. Elle se construit dans les choix d’achat des administrations, des industriels, des banques, des hôpitaux, des universités, des collectivités et des grands groupes. La présentation de Florian Caringi en donnait une illustration très concrète.

Proxmox : comprendre avant de juger

J’ai ensuite assisté à la conférence de François-Xavier Guidet, de FactorFX : Regaining Control of Virtualization with Proxmox: Solutions and Outlook.

Cette intervention portait sur la manière dont Proxmox VE peut permettre aux organisations de reprendre le contrôle de leur virtualisation, dans un contexte marqué par la dépendance à des solutions propriétaires coûteuses, peu transparentes et parfois difficiles à quitter. Le sujet était très technique. Je serais donc de mauvaise foi si je prétendais avoir un avis approfondi sur la question à ce stade.

Mais une chose est certaine : maintenant que j’ai mon propre homelab, il va bien falloir que je teste Proxmox. Genma me l’a d’ailleurs rappelé lors d’un échange avec François-Xavier Guidet : tester, non pour suivre une tendance, mais pour comprendre. Comprendre ce que cette solution permet, ce qu’elle implique, ce qu’elle change dans la gestion d’une infrastructure, même petite comme la mienne. Et surtout déterminer si ce type d’outil correspond réellement à mes besoins.

C’est aussi cela, la souveraineté numérique à petite échelle : ne pas rester sur ses acquis, mais au contraire : installer, tester, casser parfois, recommencer, comparer et se faire une idée à partir de l’expérience.

IAM, identités numériques et dépendances silencieuses

J’ai malheureusement manqué le début de la conférence de Clément Oudot, de Worteks : Are you sovereign? Yes IAM!. Le sujet était pourtant central : peut-on encore accepter de confier l’authentification, l’un des processus les plus sensibles de notre vie numérique, à Active Directory, EntraID, Okta, Google, Facebook ou d’autres grandes plateformes ?

L’intervention mettait en avant l’existence d’une pile IAM open source autour de projets comme LemonLDAP::NG, LSC, LDAP Tool Box ou FusionDirectory. Dit simplement, l’IAM : Identity and Access Management, concerne la manière dont une organisation gère les identités, les connexions, les droits et les accès à ses services numériques. C’est un sujet moins visible que l’hébergement ou la messagerie, mais absolument stratégique : celui qui contrôle les identités contrôle une partie décisive de l’infrastructure.

Avec Genma, nous avons tout de même pu échanger brièvement avec Clément Oudot. Il m’a paru à la fois convaincant et réaliste. Je n’ai pas encore un avis assez éclairé sur ces solutions, mais je repars avec une liste de sujets à creuser. Et c’est déjà beaucoup.

QSOS : évaluer l’open source avec méthode

J’ai ensuite découvert le projet QSOS, présenté par Jérôme Herledan (Genma) et Raphaël Semeteys de Worldline.

QSOS signifie Qualification and Selection of Open Source Software. En langage simple, c’est une méthode pour évaluer des logiciels libres. Elle permet d’analyser un projet open source selon plusieurs critères : sa maturité, sa communauté, sa licence, sa documentation, sa pérennité, ses usages, sa capacité à répondre à un besoin donné. L’objectif n’est pas seulement de dire « ce logiciel est libre », mais de comprendre s’il est adapté, maintenu, fiable, intégrable et pertinent dans un contexte précis.

La méthode QSOS avait été utilisée pendant de nombreuses années, notamment dans des études françaises de veille interministérielle, avant de connaître une période plus dormante. Une nouvelle version a été annoncée pour l’occasion, avec de nouveaux outils, une pile technique actualisée et un code toujours publié sous licence libre.

Cette présentation m’a donné envie d’aller plus loin. J’aimerais installer la solution et l’appliquer à ma propre (petite) infrastructure. Non pas pour produire une expertise définitive, mais pour comprendre ce que cela implique : évaluer les logiciels que l’on utilise, objectiver ses choix, identifier ses dépendances, mesurer ses angles morts. Pour ma curiosité personnelle, ce type d’approche est précieux. Il permet de passer du discours général à une grille de lecture plus concrète.

Open source : la viabilité passe aussi par les utilisateurs

La présentation de Valentina Del Prete, venue d’Italie et directrice générale de Seacom, portait un titre très clair : Why Customer Validation Is the Real Lifeline for Open Source Sustainability.

Son idée allait droit au but, et je dois reconnaître que j’aime beaucoup cette approche. Financer le développement open source par des subventions, des politiques publiques ou des dons communautaires est essentiel. Mais cela ne suffit pas. Pour qu’un projet open source soit viable à long terme, il faut aussi que des organisations réelles l’adoptent, s’appuient dessus et investissent dans son écosystème.

Cette idée peut sembler évidente. Elle ne l’est pas toujours dans les débats. On parle beaucoup de financement initial, de soutien public, de communs numériques, de contribution. Mais la durabilité d’un projet dépend aussi de sa capacité à rencontrer des usages concrets, des clients, des administrations, des entreprises, des équipes qui acceptent d’en faire un élément de leur système d’information. L’open source ne peut pas seulement vivre de conviction. Pour durer, un projet doit être utilisé, maintenu, financé et intégré dans de vraies organisations.

J’ai trouvé cette présentation très intéressante parce qu’elle rappelait une tension centrale : un projet libre peut être éthique, avoir une expérience utilisateur réfléchie, être utile, techniquement solide, et pourtant rester fragile s’il n’est pas réellement adopté, maintenu et soutenu dans le temps. Là encore, le sujet rejoint directement la souveraineté numérique. Une solution dite « résiliante » qui disparaît faute d’adoption ne renforce personne. La souveraineté exige aussi de la viabilité.

Pause déjeuner : XWiki, CryptPad et la promesse d’un nouveau test

La pause déjeuner fut l’occasion d’une autre belle rencontre : Ludovic Dubost, fondateur de XWiki et de CryptPad.

Nos débats ont porté sur la souveraineté numérique et les conséquences de la réélection de Trump II, avec sa nouvelle administration.

XWiki et CryptPad occupent une place particulière dans cet écosystème : outils collaboratifs, logiciels libres, enjeux de chiffrement, d’autonomie, de collaboration en ligne, d’alternatives crédibles aux grands services dominants. Ce sont précisément les sujets que j’essaie de traiter ici, avec mes mots et mon niveau d’expérience.

Message personnel pour Ludovic Dubost : promis, je vais refaire un test de CryptPad.

Et je le dis avec humilité : il y a des solutions que l’on croit connaître parce qu’on les a croisées une fois (ou deux…), essayées trop rapidement ou mises de côté un peu trop vite. Puis une discussion suffit à rappeler qu’un outil évolue, qu’un projet a une histoire, qu’une équipe porte une vision, et qu’il mérite parfois une seconde exploration.

Silex : vers un site plus léger ?

Toujours pendant le déjeuner, j’ai eu la joie de partager un moment avec Brice Martin, de whynotprod, et Alex Hoyau, co-fondateur (avec Moly Richez) de l’agence web Internet 2000 . Tous deux contribuent au projet Silex.

Silex est un éditeur visuel de sites statiques, libre et open source. Pour le dire simplement : il permet de créer des sites web sans dépendre d’une plateforme propriétaire de type Webflow, tout en produisant des pages légères, rapides, fondées sur les standards du web. L’outil peut aussi se connecter à un CMS (comme par exemple WordPress) ou à une API. Autrement dit, il devient possible de garder un back-office de publication, tout en générant un front-office statique plus simple, plus rapide et plus sobre.

La discussion m’a convaincu de tenter une expérimentation concernant la gestion de ce site. L’idée serait de continuer à utiliser WordPress pour la partie back-office, mais de tester une partie front-office plus légère via un site statique construit avec Silex. Pour un site qui parle de souveraineté numérique, de dépendances techniques, de sobriété, de performance et de réversibilité, l’expérience a du sens.

Silex a d’ailleurs reçu le Technology Award, ce qui confirme que le projet commence à être reconnu au-delà de son cercle initial. Là encore, je retrouve un motif récurrent de cette journée : des outils existent, des communautés travaillent, des alternatives se structurent. Encore faut-il les tester, les raconter et les mettre à l’épreuve.

Open Interop, ou la souveraineté par la cohérence des alternatives

J’ai malheureusement manqué la conférence de Julia Mouzon, du Comité Stratégique de Filière Logiciels et Solutions Numériques de Confiance, consacrée à Open Interop.

Le sujet mérite pourtant l’attention. Open Interop part d’un constat simple : l’Europe dispose déjà d’alternatives aux grandes solutions étrangères, qu’il s’agisse de postes de travail numériques, de plateformes cloud ou d’outils de cybersécurité. Mais pour que ces alternatives soient réellement adoptées, elles doivent mieux fonctionner ensemble. Les utilisateurs n’attendent pas seulement une collection de bons logiciels. Ils attendent des solutions cohérentes, intégrées, interopérables, capables de remplacer des suites dominantes sans recréer de nouvelles frictions.

Open Interop vise donc à définir et promouvoir des standards ouverts, des bancs de test et des implémentations de référence pour faciliter l’intégration des solutions européennes. C’est un sujet majeur. La souveraineté ne se joue pas uniquement dans l’existence d’alternatives, mais dans leur capacité à former un ensemble crédible, utilisable et maintenable.

À ce stade, je n’ai pas encore trouvé de documentation publique suffisamment complète sur Open Interop pour en proposer une présentation plus précise. J’ai donc pris contact afin d’obtenir des éléments officiels, une note de synthèse ou des sources complémentaires. Dès que j’aurai une réponse ou de la documentation fiable, je mettrai cet article à jour afin de partager les informations disponibles et les sources permettant de mieux comprendre cette initiative.

Si je n’ai pas assisté à cette présentation, c’est parce que j’ai été aspiré par une discussion d’un tout autre ordre, mais passionnante : celle des machines à voter.

Machines à voter : une discussion trop dense pour être résumée en quelques paragraphes

J’ai eu un échange particulièrement stimulant avec Benoît Sibaud autour des machines à voter. Benoît Sibaud est une figure de longue date du logiciel libre français : ancien président de l’April, webmestre de LinuxFr.org, ingénieur chez Orange, il travaille depuis longtemps sur les enjeux de logiciel libre, de transparence et de démocratie numérique.

Je ne vais pas tenter ici une synthèse de notre échange. Le sujet est trop vaste, trop sensible, trop important pour être résumé en quelques lignes sans risquer la simplification ou la mauvaise interprétation. Les machines à voter posent des questions démocratiques fondamentales : transparence, auditabilité, confiance, vérifiabilité, rôle du citoyen, limites de la technique dans un acte aussi essentiel que le vote.

Pour aller plus loin, j’invite plutôt à écouter l’épisode de RdGP consacré au sujet. Il en parle mieux que je ne le ferais ici, avec l’expérience et la précision nécessaires.

Cette conversation m’a toutefois rappelé une chose : le logiciel libre n’est pas une réponse automatique à tous les problèmes. Sur certains sujets, la question n’est pas seulement « le code est-il ouvert ? », mais « le processus démocratique reste-t-il compréhensible, vérifiable et maîtrisable par les citoyens ? ». C’est une nuance essentielle.

SBOM, Log4Shell et Cyber Resilience Act : voir ce qui compose nos logiciels

J’ai aussi manqué le début de la conférence d’Anthony Harrison, fondateur d’APH10 et cofondateur de SBOM Europe, et d’Olle E. Johansson, fondateur d’Edvina AB et également cofondateur de SBOM Europe. Leur intervention s’intitulait : State of the SBOM union: Are we ready for another Log4Shell ?

Le sujet du SBOM est directement lié à un article que j’avais déjà rédigé sur le Cyber Resilience Act. Un SBOM « Software Bill of Materials » peut se comprendre comme une nomenclature logicielle. C’est la liste des composants utilisés dans un logiciel : bibliothèques, dépendances, versions, briques tierces. L’idée est simple : pour sécuriser un logiciel, encore faut-il savoir de quoi il est composé.

Depuis des failles majeures comme Log4Shell, cette question est devenue centrale. Comment savoir si une organisation est exposée à une vulnérabilité si elle ignore quelles dépendances sont présentes dans ses produits ou ses services ? Comment gérer la conformité, la sécurité, les mises à jour, les responsabilités, sans visibilité sur la chaîne logicielle ?

SBOM Europe travaille précisément à construire une communauté européenne autour de cette transparence logicielle : comprendre, discuter, tester les outils, partager les bonnes pratiques et accompagner les organisations face aux nouvelles exigences réglementaires, notamment celles du Cyber Resilience Act.

Cette conférence confirmait une évolution majeure : la souveraineté numérique n’est pas seulement une affaire d’hébergement ou de nationalité des prestataires. Elle touche aussi à la transparence sur les briques techniques que l’on utilise au quotidien. Une organisation qui ne sait pas ce que contiennent ses logiciels ne maîtrise pas réellement son risque.

BlueMind : une piste française à tester

À la pause café, j’ai également rencontré Pierre Baudracco, président et fondateur de BlueMind.

Cette rencontre tombe à point nommé. J’ai déjà publié un article sur mon test de grommunio dans une logique de courriel souverain, de résilience et d’auto-hébergement. BlueMind mérite désormais que je m’y intéresse sérieusement. La solution s’inscrit dans un espace qui me semble stratégique : la messagerie collaborative, les agendas, les contacts, les usages quotidiens de l’entreprise et des organisations.

Le sujet a du sens dans ce que j’essaye de construire. Tester BlueMind en parallèle de grommunio permettra peut-être de mieux comprendre les forces, les limites et les cas d’usage de ces alternatives.

Et il y a un élément qui compte : BlueMind est une entreprise française, engagée depuis longtemps dans l’écosystème open source. Cela ne suffit évidemment pas à tout justifier, mais cela rend le test pertinent dans le cadre d’une réflexion sur la résilience et la souveraineté numérique.

De la souveraineté à l’indépendance technique

En fin d’après-midi, j’ai assisté au débat animé par Emiel Brok, ambassadeur international de la souveraineté numérique auprès de SUSE, accompagné notamment de Pierre-Yves Gibello, président d’OW2. Le débat portait un titre révélateur : « From sovereignty to technical independence » ou en français : De la souveraineté à l’indépendance technique

Les questions abordées étaient nombreuses :

• Faut-il préférer des logiciels libres provenant de pays hors Union européenne ou des logiciels propriétaires européens ?
• Faut-il avancer de manière radicale ou progressive ?
• Pourquoi ne pas miser davantage sur la blockchain ?

Je ne vais pas en proposer ici une synthèse détaillée. Je pense que la vidéo du débat sera disponible prochainement et mérite d’être regardée directement. Mais le cadre général rejoint parfaitement les questions que je me pose depuis des années : la souveraineté numérique n’est pas un slogan. Elle se vérifie dans l’architecture, les dépendances, les contrats, les formats, les compétences, les choix d’achat, les capacités de migration et la possibilité réelle de continuer à fonctionner lorsque le contexte se dégrade.

Ce débat avait le mérite de sortir du mot-valise pour revenir à une question plus exigeante : qu’est-ce que la résilience permet réellement, et à quelles conditions ?

La fin d’une journée, le début de plusieurs idées

Avant de partir, j’ai eu l’honneur de pouvoir remercier Pierre-Yves Gibello, président d’OW2, et lui faire une promesse simple : revenir l’année prochaine.

J’ai aussi eu la chance, trop furtivement, de saluer Olivier Bouzereau, président et fondateur de PulsEdit, mais aussi membre actif de l’organisation de cet événement. PulsEdit accompagne des groupes de presse, éditeurs de logiciels, organisateurs de congrès et sociétés innovantes dans la réalisation de contenus stratégiques : guides, livres blancs, témoignages vidéo, cas clients, conférences, débats publics ou contenus communautaires. Là encore, un point de jonction apparaît entre technique, récit et transmission.

Alex Bourreau, des constats partagés et beaucoup de pistes à poursuivre

Pour terminer cette série de rencontres, j’ai longuement échangé avec Alex Bourreau, ingénieur et développeur engagé, notamment à travers sa nouvelle mission de gouvernance open source pour la BPCE.

Notre échange fut l’un des plus marquants de la journée. Nous avons longuement discuté du terme « souveraineté numérique », de ses usages, de ses limites, de ses angles morts, de l’évolution de l’open source, de ce qui fonctionne, de ce qui bloque, de ce qui manque encore. Ce fut passionnant parce que nos points de vue étaient complémentaires. Par moments, nous étions surpris de constater à quel point certains constats se rejoignaient, même lorsque nos chemins d’arrivée étaient différents.

Ce type de rencontre fait partie de ce que l’OW2con rend possible. On vient pour écouter des conférences, et l’on repart avec des idées qui mûrissent, des concepts à retravailler, des pistes d’articles, des tests à réaliser, des doutes plus précis et des intuitions plus solides.

J’espère revoir Alex Bourreau prochainement et poursuivre cet échange. En fin d’événement, c’était pour moi l’une des plus belles rencontres de la journée : celle qui permet de se dire que l’alchimie humaine d’un tel rendez-vous peut réellement faire grandir une réflexion.

Ce que j’ai retenu de cet événement

Je repars de cette journée avec beaucoup plus que des notes. Je repars avec des visages, des noms, des projets à tester (et des articles à rédiger), des conférences à rattraper via les rediffusions accessibles sous peu, des outils à installer, des sujets à creuser. Proxmox, QSOS, CryptPad, Silex, BlueMind, les enjeux IAM, les SBOM, Open Interop, la viabilité économique de l’open source : chacun de ces sujets pourrait devenir un article à part entière.

Mais je repars surtout avec le souvenir d’un accueil rare et de conversations d’une grande richesse.

Je ne m’attendais pas à trouver une communauté aussi accessible. Les échanges ne se sont pas construits autour de cartes de visite distribuées mécaniquement dans un certain « conformisme » , comme dans beaucoup d’autres salons. Au maximum, on échangeait un compte LinkedIn ou Mastodon. Le vrai vecteur de rencontre, ici, c’était la conversation. Les retours d’expérience. L’envie d’expliquer. La capacité à entendre des critiques constructives. L’absence de prétention. Le fait de ne pas prendre les autres de haut, même lorsqu’ils ne viennent pas du même monde professionnel.

Pour quelqu’un comme moi, qui ne vient pas du sérail, c’est précieux.

J’étais venu avec des questions sur ma légitimité. Je repars avec la conviction que ces sujets doivent justement sortir du seul cercle des spécialistes. L’open source ne gagnera pas seulement parce qu’il est techniquement pertinent. Il gagnera aussi s’il devient compréhensible, concret et accessible au plus grand nombre, et si les citoyens, les élus, les journalistes, les entrepreneurs, les enseignants, les associations et les utilisateurs peuvent se l’approprier.

L’OW2con m’a montré que ce passage est possible. Il existe des ponts à construire entre celles et ceux qui développent, maintiennent, structurent, financent et défendent ces solutions, et celles et ceux qui essayent d’en faire comprendre les enjeux auprès du grand public.

Une invitation pour la prochaine édition

Je ne peux donc que recommander de s’intéresser à l’écosystème OW2 et, si possible, de participer à la prochaine édition de l’OW2con. On peut y aller avec ses questions, ses limites, parfois ses hésitations, et en ressortir pourtant plus éclairé.

L’événement permet d’apprendre, de rencontrer, de confronter ses idées, mais aussi de découvrir des projets déjà solides, des communautés engagées depuis longtemps, des réussites concrètes, des limites, des tensions et des débats. C’est précisément cette richesse qui rend l’OW2con si précieuse : elle donne à voir un écosystème vivant, avec ses forces, ses questions et ses chemins encore ouverts.

Cette journée fut l’un des événements les plus enrichissants de mon année, à la fois sur le plan intellectuel et humain. J’y ai fait de belles rencontres, mais j’ai aussi confronté mes points de vue, et mieux compris certains angles morts de l’open source. Cela n’a fait que confirmer l’importance de mon sujet central : la souveraineté numérique.

Merci à OW2 pour l’organisation. Merci aux intervenants et aux personnes rencontrées pour leur générosité dans les échanges. Merci à celles et ceux qui prennent le temps de construire des alternatives ouvertes, souvent dans l’ombre, parfois avec trop de modestie.

Et surtout, merci Genma. Sans toi, je n’aurais probablement pas franchi cette porte. Grâce à toi, cette journée est devenue bien plus qu’une conférence : une étape importante dans ce long cheminement.

L’article OW2con’26 : la belle surprise d’une plongée vivante et accessible dans l’open source européen est apparu en premier sur Souverain.

Contexte : qui a produit ce rapport ?

Cette instance indépendante est placée auprès de la ministre chargée de l’intelligence artificielle et du numérique : Anne Le Hénanff.
Le CIANum a pour mission d’étudier toute question relative au développement du
numérique et de l’intelligence artificielle et à leur impact sur la société, l’économie
et les territoires. Il est composé d’un collège interdisciplinaire de membres nommés par
le Premier ministre et de parlementaires nommés par les présidents du Sénat et de
l’Assemblée nationale.

Le rapport a été piloté par plusieurs profils issus du public, du privé, des territoires, de l’université et des communs numériques :

• Dorie Bruyas, présidente de la MedNum
• Céline Colucci, déléguée générale des Interconnectés
• Aymeril Hoang, directeur d’EuroCommons au sein du groupe Caisse des Dépôts
• Guillaume Poupard, Chief Trust Officer chez Orange
• Sébastien Soriano, directeur général de l’IGN
• Olivier Wong-Hee-Kam, vice-président numérique de l’Université de Rennes.

Le travail a été soutenu par Joséphine Corcoral, directrice adjointe du CIANum, et Laurine Dupont, rapporteure au CIANum.

Le rapport pose une question très concrète : comment la France et l’Europe peuvent-elles réduire leur dépendance aux grandes plateformes étrangères sans créer de nouvelles dépendances internes, et sans opposer inutilement l’État, les entreprises et les communautés open source ?

Le rapport part d’un constat : le numérique est devenu aussi stratégique que l’énergie, les transports ou les télécommunications. Pourtant, une grande partie des outils utilisés tous les jours : cloud, logiciels bureautiques, systèmes d’exploitation, IA, données, standards techniques… dépend d’acteurs principalement non européens, en particulier américains. Cela crée des risques économiques, juridiques, politiques, industriels et de sécurité.

La thèse centrale est la suivante : la souveraineté numérique absolue n’existe pas.
La France ne peut pas tout produire seule, et l’Europe non plus. L’objectif n’est donc pas l’autarcie, mais la capacité à choisir, à changer de fournisseur, à maîtriser ses données, à utiliser des standards ouverts, à éviter l’enfermement propriétaire et à construire des alternatives crédibles. Le rapport défend une coopération entre trois mondes : l’État, le marché et les communs numériques.

Le rapport complet compte 97 pages et couvre de nombreux enjeux liés à la souveraineté numérique.
J’ai souhaité en proposer ici une version condensée, sous la forme d’un résumé chapitre par chapitre, afin d’en retenir les idées principales. Il s’agit bien entendu de mon interprétation et de ma compréhension du rapport, sans prétendre remplacer la lecture intégrale du document.

1. Définir la souveraineté numérique

La souveraineté numérique ne signifie pas « tout faire soi-même ». Elle signifie plutôt ne pas être prisonnier d’un fournisseur, d’un pays ou d’une technologie. Une organisation souveraine doit pouvoir choisir ses outils, changer de prestataire, récupérer ses données, comprendre ses dépendances et garantir la sécurité de ses systèmes. Le rapport identifie plusieurs piliers importants :

• liberté de choix
• réversibilité
• diversification
• sécurité
• régulation
• sobriété
• formation.

La souveraineté numérique, ce n’est pas se couper du monde ; c’est garder la capacité de choisir, de comprendre et de maîtriser ses outils essentiels.

2. Logiciel libre, open source et communs numériques

Il y a une distinction claire entre le logiciel libre, l’open source et les communs numériques.

• Le logiciel libre insiste sur les libertés des utilisateurs : utiliser, étudier, modifier et redistribuer un programme.
• L’open source met plutôt l’accent sur l’efficacité pratique : transparence du code, sécurité, performance, réutilisation.
• Les communs numériques vont plus loin : ce sont des ressources partagées, comme le logiciel, les bases de données, les protocoles ou les connaissances, entretenues par une communauté avec des règles de gouvernance.

Le rapport veut montrer que ces communs ne sont pas seulement des outils militants ou associatifs. Ils peuvent devenir des briques industrielles stratégiques pour construire une souveraineté numérique durable.

3. Une dépendance numérique largement documentée

Le rapport dresse d’abord un état des lieux sévère. La dépendance française et européenne ne concerne pas seulement les applications visibles comme Microsoft Office, Google, Amazon ou les réseaux sociaux. Elle touche toute la chaîne : semi-conducteurs, câbles sous-marins, terres rares, cloud, systèmes d’exploitation, logiciels, protocoles, standards, données et modèles d’intelligence artificielle.

Le rapport insiste aussi sur les conséquences : hausse possible des prix, coupures de service, dépendance à des lois étrangères, risques de surveillance, lobbying, perte de compétences et fragilité en cas de crise géopolitique. Pour le dire simplement : si les outils essentiels de l’État, des entreprises et des citoyens dépendent d’acteurs extérieurs, alors une partie de notre capacité d’action dépend aussi d’eux.

4. L’action publique : des avancées, mais encore beaucoup de contradictions

Le rapport reconnaît que l’État français a fait des progrès. Il cite notamment :

• La loi pour une République numérique
• Le Socle interministériel des logiciels libres
• La doctrine « cloud au centre »
• SecNumCloud,
• La Suite numérique de l’État, Tchap, FranceTransfert, Visio, FranceConnect, ProConnect
• Les travaux récents autour de l’IA générative souveraine.

Mais le rapport souligne aussi une contradiction : l’État parle de souveraineté numérique tout en restant encore très dépendant de solutions étrangères, notamment Microsoft ou certains hyperscalers américains. Il existe donc un écart entre le discours politique et la réalité des usages. Autre problème : les ministères, les collectivités et les administrations travaillent souvent chacun de leur côté. La DINUM coordonne, mais le rapport estime qu’elle manque encore de moyens et de pouvoir contraignant pour imposer une stratégie réellement unifiée.

L’État a compris le problème, mais il n’a pas encore complètement aligné ses achats, ses outils, ses budgets et sa gouvernance avec son discours.

5. Les acteurs privés français et européens : des forces réelles, mais trop dispersées

Le rapport ne nie pas l’existence d’acteurs européens solides. Il cite par exemple ASML, SAP, STMicroelectronics, OVHcloud, Scaleway, Outscale, Deutsche Telekom Cloud, IONOS ou Orange. Mais il montre que ces acteurs restent trop fragmentés face aux géants américains et asiatiques. Le marché européen du cloud reste très largement dominé par les hyperscalers non européens.

Le problème est aussi politique et industriel. Les entreprises européennes existent, mais elles manquent souvent de taille critique, de coordination, de visibilité sur la commande publique et de stratégie commune. Le rapport plaide pour une meilleure articulation entre l’État, les collectivités, les entreprises et les communautés open source.

6. Les communs numériques : un potentiel stratégique sous-exploité

Le rapport insiste fortement sur la valeur économique et stratégique du logiciel libre, de l’open source et des communs numériques. Il rappelle que les grandes entreprises mondiales utilisent massivement ces briques : Linux, Apache, MySQL, Python, etc. Les communs numériques ne sont donc pas marginaux : ils sont déjà au cœur de l’économie numérique mondiale.

Mais le paradoxe français est que l’État reconnaît l’importance du libre sans toujours l’intégrer réellement dans ses achats, ses politiques publiques et ses stratégies industrielles. Le rapport estime que les communs doivent être traités comme de véritables infrastructures : ils doivent être financés, maintenus, gouvernés et intégrés dans la durée.

Le libre n’est pas gratuit : il repose sur du travail, des compétences, de la maintenance et des communautés qu’il faut soutenir sérieusement.

Les solutions proposées

7. Les erreurs à éviter

Le rapport identifie plusieurs pièges.

• Premier piège : ne regarder que les outils visibles, comme les suites bureautiques ou la visioconférence, en oubliant les couches profondes : cloud, serveurs, systèmes d’exploitation, bases de données, API, réseaux.
• Deuxième piège : repartir de zéro alors que des solutions existent déjà.
• Troisième piège : disperser les financements dans une multitude de petits projets sans stratégie claire.

Le message est très important : la souveraineté numérique ne se construit pas avec des annonces isolées, mais avec une stratégie patiente, coordonnée et financée dans la durée.

8. Organiser les besoins et créer des standards communs

Le rapport préconise une meilleure structuration de l’organisation concernant la demande publique et privée. Cela veut dire que les administrations, collectivités et grandes organisations gagneraient à formaliser plus clairement leurs besoins communs, plutôt que de commander chacune sa propre solution de manière isolée. Cette mutualisation permettrait de faire émerger des solutions plus robustes, plus interopérables et plus faciles à financer.

L’une des propositions centrales est la création d’une Fabrique des Communs Numériques. Son rôle serait d’identifier les briques prioritaires, de cartographier les dépendances, de fédérer les acteurs, de labelliser les solutions sérieuses et de piloter la pérennisation de projets ouverts.

Plutôt que de reconstruire chacun son propre outil, on identifie les besoins communs, on choisit des standards ouverts, et on construit ensemble des briques réutilisables.

9. Assurer la durabilité juridique et financière

Le rapport insiste sur un point souvent oublié : un commun numérique doit avoir un cadre juridique et un financement stable. Il évoque plusieurs formes possibles : SCOP, SCIC, GIP, services d’intérêt économique général, appels à communs, fiducies de données ou structures hybrides. L’objectif est de trouver des modèles où le public, le privé et les communautés peuvent coopérer sans que l’un prenne entièrement le contrôle sur les autres.

Le rapport propose aussi un fonds public dédié aux communs numériques stratégiques, hébergé par l’Autorité nationale du numérique et de l’intelligence artificielle de l’État (surnommée Ariane) : une nouvelle entité en cours de préfiguration par le Premier ministre Sébastien Lecornu, visant à renforcer le pilotage et la sécurité du numérique public français pour financer le développement, la maintenance et l’amélioration des projets prioritaires. Le rapport défend également le principe du public money, public code and public governance. Autrement dit : lorsqu’un projet est financé par de l’argent public, il doit autant que possible produire du code ouvert et une gouvernance ouverte.

10. Passer à l’échelle européenne

Le rapport estime que la France ne peut pas réussir seule. Le numérique fonctionne par effets d’échelle : plus un outil est utilisé, plus il devient puissant, utile et attractif. Une stratégie uniquement nationale risque donc d’être trop petite face à Microsoft, Amazon, Google, Apple ou aux grands acteurs chinois.

Il propose de renforcer l’approche européenne autour de l’EDIC Digital Commons, de créer un fonds européen pour les communs numériques, d’imposer des standards ouverts comme Matrix ou ActivityPub dans les politiques publiques européennes, et de créer un label « European Open Standard » pour certifier les projets conformes aux standards ouverts.

La souveraineté numérique française doit être pensée dans un cadre européen, sinon elle restera trop faible face aux grandes plateformes mondiales.

Une question peut toutefois se poser à la lecture du rapport. La création d’une Fabrique des Communs Numériques, pensée à l’échelle française, est une proposition structurante. Mais puisqu’un EDIC Digital Commons existe déjà au niveau européen, ne serait-il pas plus puissant de concentrer l’effort sur cet outil commun, plutôt que de multiplier les structures ? L’enjeu ne serait alors pas de remplacer la proposition du rapport, mais peut-être de la projeter plus directement à l’échelle européenne. On pourrait imaginer un EDIC renforcé, associant non seulement les administrations nationales, mais aussi de grands acteurs publics et privés européens : la Caisse des Dépôts, les équivalents européens de la DINUM, comme le ZenDiS allemand, des ministères de la Défense, l’EuroHPC JU, la DG Connect, des opérateurs publics stratégiques comme EDF, mais aussi Orange, Iliad-Free, Deutsche Telekom, Telefónica, SAP, OVHcloud, Scaleway, IONOS, Schneider Electric, Siemens, Thales, Airbus, Nokia, Ericsson ou STMicroelectronics. Une telle coalition aurait peut-être davantage de poids pour financer, maintenir et industrialiser des briques ouvertes réellement communes. La question mérite en tout cas d’être posée : la souveraineté numérique européenne gagnerait-elle à juxtaposer des fabriques nationales, ou à renforcer un organisme européen unique, capable de fédérer les besoins, les financements et les standards ? Le débat reste ouvert.

Conclusion

Le rapport conclut que les dépendances numériques françaises et européennes sont désormais bien connues. Le problème n’est plus seulement de les constater, mais d’organiser une réponse crédible. Cette réponse doit éviter deux illusions : croire que l’État peut tout faire seul, ou croire que le marché réglera naturellement le problème.

La proposition centrale est donc une alliance organisée entre public, privé et communs numériques. L’État doit fixer une direction, mutualiser la demande, utiliser la commande publique, financer les briques stratégiques et garantir l’intérêt général. Les entreprises doivent contribuer, industrialiser et proposer des services solides. Les communautés open source doivent être reconnues comme des partenaires essentiels, pas comme une ressource gratuite dans laquelle chacun vient puiser sans contribuer.

Ce rapport est important parce qu’il sort d’une opposition stérile entre « l’État doit tout faire » et « il faut laisser faire le marché ». Il défend une voie plus réaliste : construire une souveraineté numérique par la coopération, les standards ouverts, la réversibilité, la mutualisation et le financement durable des communs.

Et la Direction interministérielle du numérique dans tout ça ?

Le rapport contient bien plusieurs passages importants sur la DINUM et cite notamment l’audition de Stéphanie Schaer, directrice interministérielle du numérique.

Concrètement, le rapport dit trois choses.

D’abord, il reconnaît un rôle positif de la DINUM dans plusieurs projets publics structurants : La Suite numérique, Tchap, FranceConnect, ProConnect, FranceTransfert, Visio ou encore les travaux autour de l’IA générative. Le rapport rappelle aussi que la DINUM doit coordonner un plan interministériel de réduction des dépendances extra-européennes, avec des plans demandés aux ministères sur les postes de travail, les outils collaboratifs, l’antivirus, l’IA, les bases de données, la virtualisation et les équipements réseau.

Ensuite, le rapport nuance l’accusation selon laquelle la DINUM construirait seule des outils publics en concurrence directe avec le privé. Stéphanie Schaer explique que La Suite numérique n’est pas conçue uniquement par la DINUM, qui dispose de très peu de développeurs en interne, mais qu’elle est co-construite avec des acteurs privés. Le rapport cite aussi FranceConnect et ProConnect comme des exemples de gouvernance structurée entre acteurs publics et privés. Dans le cas de FranceConnect, cette coopération ne signifie pas nécessairement un co-développement avec une entreprise privée unique, mais plutôt l’intégration d’acteurs publics et privés comme La Poste, IDnow ou A3BC, dans un cadre où l’État fixe les règles et les standards sans forcément se substituer aux entreprises.

Enfin, le rapport formule une critique claire : la DINUM a un rôle de coordination, mais elle manque encore de moyens et de pouvoir contraignant pour imposer une approche vraiment unifiée aux différentes DSI ministérielles. Le rapport laisse entendre qu’il faudrait renforcer son autorité, notamment pour éviter les choix dispersés, les achats contradictoires et les dépendances maintenues malgré les discours officiels.

Le rapport reconnaît les avancées portées par la DINUM, valorise sa démarche de co-construction, tout en estimant qu’elle doit être renforcée pour devenir un véritable levier stratégique de souveraineté numérique.

L’article Rapport du CIANum sur la souveraineté numérique : sortir des dépendances par la coopération est apparu en premier sur Souverain.

Dans les coulisses, le sujet est devenu hautement politique. Les futures propositions européennes sur le cloud, l’intelligence artificielle, les semi-conducteurs, les infrastructures numériques et l’open source arrivent dans un moment de tension transatlantique. L’administration Trump a déjà mis en garde Bruxelles contre des mesures jugées trop protectionnistes, notamment si elles devaient restreindre l’accès des entreprises américaines aux marchés européens stratégiques.

La Commission répond que ce paquet ne vise pas les États-Unis, mais l’avenir de l’Europe. Tout l’enjeu européen se tient dans cette tension : bâtir une autonomie sans être accusé de fermer son marché. L’Europe peut-elle encore construire sa souveraineté numérique sans froisser les puissances dont elle dépend ?

C’est dans ce contexte, à quelques jours de la présentation du prochain paquet européen sur la souveraineté technologique, attendue le 3 juin, que plusieurs entreprises européennes de l’open source, réunies autour d’une lettre ouverte publiée par SUSE, demandent un changement de méthode très concret : inscrire un principe Open Source First non seulement dans les futurs textes européens, mais aussi dans les arbitrages immédiats de ce paquet très attendu. Le compte à rebours affiché sur le site de la lettre ouverte dit clairement l’urgence politique du moment.

Derrière cette demande, les entreprises signataires poursuivent trois objectifs précis. D’abord, une résilience stratégique : passer d’une dépendance technique subie à une véritable capacité de pivot dans un contexte géopolitique instable. Ensuite, un leadership de marché : créer, par la commande publique, le signal économique qui permettrait à l’industrie open source européenne de passer à l’échelle. Enfin, une transparence opérationnelle : garantir que l’argent public finance des infrastructures maintenables, auditables et réellement maîtrisables dans la durée.

L’idée n’est pas de bannir les logiciels propriétaires. Elle n’est pas non plus de fermer brutalement les marchés publics aux entreprises non européennes. La proposition est plus simple, et peut-être plus puissante : lorsqu’une administration, une collectivité, un hôpital, une université ou une institution publique achète un logiciel ou un service numérique, elle devrait d’abord évaluer s’il existe une solution open source qualifiée avant de se tourner vers une solution propriétaire.

Cette évaluation devrait être documentée, transparente et auditable. Autrement dit, l’Europe ne se contenterait plus de déclarer son attachement à la souveraineté numérique. Elle commencerait à modifier le réflexe d’achat qui, depuis des années, nourrit sa dépendance.

La commande publique, angle mort de la souveraineté numérique

Le point central de cette lettre ouverte n’est pas seulement technique. Il est économique, industriel et politique.

Depuis des années, l’Europe affirme vouloir réduire sa dépendance aux grandes plateformes numériques étrangères. Mais dans les faits, une part considérable de l’argent public continue d’alimenter les mêmes écosystèmes propriétaires, souvent américains, déjà dominants dans le cloud, les logiciels collaboratifs, les infrastructures de données, les outils métiers et désormais l’intelligence artificielle.

C’est tout le paradoxe européen. Le continent dispose d’ingénieurs, d’entreprises, de laboratoires, de communautés open source, de PME innovantes, d’acteurs industriels crédibles. Mais il peine à transformer cette richesse en puissance de marché.

Cette question a déjà été abordée dans l’article consacré à l’open source comme levier de souveraineté numérique pour l’Europe : le logiciel libre n’est plus un sujet secondaire réservé aux développeurs. Il est devenu une couche fondamentale de l’économie numérique. Il irrigue le cloud, la cybersécurité, l’intelligence artificielle, les infrastructures publiques et les services numériques du quotidien.

Mais un commun numérique ne vit pas seul. Il demande de la maintenance, du support, de la documentation, des audits, des financements, des contrats, des utilisateurs, des intégrateurs et des acheteurs capables de lui faire confiance. Sans débouchés solides, même les meilleurs projets restent fragiles.

C’est là que la lettre de SUSE frappe juste. Elle ne demande pas seulement de reconnaître la valeur de l’open source. Elle demande à l’Europe de créer la demande qui permettra à son industrie open source de changer d’échelle.

Open Source First : changer le réflexe, pas interdire le choix

Le principe Open Source First peut se résumer ainsi : avant d’acheter une solution fermée, l’acheteur public devrait vérifier sérieusement s’il existe une solution ouverte, maintenable et souveraine.

Ce principe ne signifie pas que l’open source serait toujours le meilleur choix. Il signifie que le choix propriétaire ne devrait plus être automatique. Aujourd’hui, trop de décisions d’achat public sont prises dans un environnement où les grandes solutions déjà installées bénéficient d’un avantage considérable : habitudes des équipes, contrats existants, dépendance aux formats, peur de la migration, compatibilité avec les usages déjà en place, capacité commerciale des grands fournisseurs.

Résultat : plus une solution propriétaire est installée, plus elle devient difficile à quitter. Plus elle devient difficile à quitter, plus elle capte les budgets suivants. Et plus elle capte ces budgets, plus les alternatives européennes ont du mal à grandir.

La lettre ouverte tente de briser ce cercle. Non par un slogan, mais par une obligation procédurale : examiner d’abord l’alternative ouverte, expliquer le choix, rendre la décision vérifiable et publique.

Ce point est essentiel. La souveraineté numérique ne se résume pas à l’origine géographique d’un fournisseur. Elle repose aussi sur la capacité à auditer, maintenir, modifier, transférer et remplacer une technologie. Une solution ouverte n’offre pas automatiquement toutes ces garanties, mais elle donne souvent plus de marges de manœuvre qu’une solution fermée, opaque et verrouillée.

Trois objectifs : résilience, marché, transparence

Les signataires de la lettre ouverte avancent trois objectifs majeurs.

Le premier est la résilience stratégique. Dans un contexte géopolitique instable, l’Europe ne peut plus seulement chercher à localiser ses données ou à multiplier les clauses contractuelles. Elle doit être capable de pivoter. Cela signifie pouvoir changer de fournisseur, reprendre le contrôle d’une brique critique, maintenir une infrastructure même si un contexte politique, juridique ou commercial se dégrade.

La souveraineté numérique n’est donc pas seulement une question de protection. C’est une capacité de repli et de redéploiement. Une administration vraiment souveraine n’est pas celle qui ne dépend de personne, ce qui serait illusoire. C’est celle qui peut sortir d’une dépendance excessive sans être paralysée.

Le deuxième objectif est le leadership de marché. L’Europe ne manque pas seulement de solutions. Elle manque souvent de clients structurants. Si les administrations européennes continuent d’acheter massivement les technologies dominantes venues d’ailleurs, les entreprises européennes resteront trop petites, trop dispersées, trop fragiles. La commande publique peut devenir le signal qui transforme une filière prometteuse en industrie solide.

Ce raisonnement rejoint directement la question des PME européennes. Dans un article d’Axel Laniez expliquant la stratégie de Quentin Adam (Clever Cloud), il rappelait que la commande publique devait devenir un outil de puissance, de structuration industrielle et de soutien aux entreprises européennes. Un Small Business Act européen, un Buy European Tech Act, des marchés découpés, des procédures plus accessibles et une préférence assumée dans les secteurs stratégiques ne relèvent pas d’un caprice protectionniste. Ils peuvent devenir les conditions pratiques d’une souveraineté crédible.

Le troisième objectif est la transparence opérationnelle. L’argent public ne devrait pas financer des boîtes noires difficiles à auditer, à maintenir ou à quitter. Lorsqu’un État, une région ou une collectivité dépense de l’argent public dans une infrastructure numérique, cette dépense devrait renforcer une capacité durable. Elle devrait produire de la compétence, de la maîtrise, de la documentation, de la réversibilité, de la sécurité et de la confiance.

À l’inverse, lorsqu’un marché public enferme durablement une administration dans un fournisseur unique, il ne finance pas seulement un service. Il finance une dépendance future.

Les entreprises françaises déjà dans la bataille

La liste des signataires rappelle que l’open source européen n’est pas une promesse théorique, mais un tissu d’entreprises déjà engagé. Plusieurs acteurs français ou fortement liés à l’écosystème français figurent parmi les entreprises mobilisées.

On y retrouve notamment :

• Smile, acteur majeur de l’intégration open source
• Probabl, issue de l’écosystème Inria et engagée autour de la bibliothèque libre Python « scikit-learn » et de l’intelligence artificielle open source
• Symfony, framework PHP open source devenu une référence majeure du développement web
• Rudder, solution ouverte de conformité et d’automatisation des infrastructures
• Linagora, éditeur français historique de logiciels libres
• Freexian, spécialiste de Debian GNU/Linux et du logiciel libre
• Murena, connue pour /e/OS et ses solutions mobiles dégooglisées
• SensioLabs, créateur de Symfony et acteur français structurant de l’écosystème PHP open source
• Worteks, acteur de l’infrastructure open source, de l’identité numérique et de l’hébergement souverain, également contributeur de projets libres comme LemonLDAP::NG, LDAP Tool Box ou LSC.
• Francelabs, éditeur français de Datafari, solution open source de recherche d’entreprise, et spécialiste des technologies Apache Lucene / Solr, Elasticsearch et ManifoldCF
• XWiki, éditeur français de logiciels libres pour le partage de connaissances et la collaboration, développe XWiki et CryptPad, deux solutions européennes pensées pour la maîtrise des données, la transparence et l’indépendance numérique.
• Biru, une SCOP qui développe Tenzu, outil open source de gestion de projet pour les équipes agiles, pensé pour prolonger l’héritage de Taiga dans une logique coopérative, sobre et souveraine.

Ces entreprises ne représentent pas toutes le même segment du marché. Certaines travaillent sur l’infrastructure, d’autres sur l’IA, le système d’exploitation, la collaboration, la conformité, le support ou la mobilité. Leur point commun est ailleurs : elles incarnent une industrie européenne du numérique qui existe déjà, mais qui a besoin d’un environnement d’achat plus favorable pour atteindre une taille critique.

L’Europe ne part donc pas de zéro. Elle dispose de briques, de compétences, de communautés et d’entreprises. Ce qui manque encore trop souvent, c’est l’alignement entre les discours politiques, les règles d’achat et les dépenses réelles.

Cristina Caffarra et la question décisive de la demande

La vidéo récente de Cristina Caffarra apporte ici un éclairage précieux. Elle y résume l’un des problèmes européens les plus profonds : le moteur de cette transformation doit être la demande.

Son diagnostic est sans détour. L’Europe est une puissance économique majeure, mais elle continue trop souvent à penser petit face à son avenir industriel. Mario Draghi a déjà alerté sur la soutenabilité du modèle économique européen à long terme. Si le continent ne retrouve pas une base productive et technologique solide, son modèle social, ses retraites, ses écoles, ses hôpitaux et sa prospérité deviendront plus difficiles à financer.

Cristina Caffarra pointe aussi la responsabilité des grands dirigeants économiques européens. Beaucoup continuent d’acheter Microsoft ou d’autres solutions dominantes, au lieu de contribuer à construire des alternatives européennes. Cette remarque rejoint parfaitement la lettre ouverte de SUSE.

D’un côté, SUSE et les signataires demandent à la puissance publique de modifier ses règles d’achat. De l’autre, Cristina Caffarra rappelle que la souveraineté numérique ne pourra pas reposer uniquement sur les institutions. Les grandes entreprises européennes doivent, elles aussi, accepter de créer la demande, de prendre des risques, de soutenir des fournisseurs européens, de sortir de la simple logique du confort contractuel.

La souveraineté numérique ne peut pas rester au seul niveau des intentions politiques. Elle se construit dans les choix d’achat des administrations, des industriels, des banques, des hôpitaux, des universités, des collectivités et des grands groupes.

Acheter européen, ce n’est pas se fermer au monde

L’un des débats les plus sensibles sera évidemment celui de la préférence européenne. Dès que l’Europe envisage de réserver une part de ses achats stratégiques à ses propres entreprises, l’accusation de protectionnisme surgit.

Mais le débat demande d’être posé autrement. Les États-Unis utilisent depuis longtemps la commande publique comme un outil de puissance. La Chine organise son marché intérieur pour soutenir ses champions. Les grandes puissances ne traitent pas leurs achats publics comme une simple procédure administrative neutre. Elles y voient un moyen de construire des capacités.

L’Europe, elle, a longtemps voulu croire que l’ouverture suffisait à produire de la puissance. Cette vision atteint aujourd’hui ses limites. Dans le numérique, l’ouverture sans stratégie finit souvent par renforcer les acteurs déjà dominants.

Acheter européen dans les secteurs stratégiques ne signifie pas se couper du monde. Cela signifie que l’argent public européen doit d’abord servir à renforcer les capacités européennes lorsque des alternatives crédibles existent. Dans le cloud, l’IA, les logiciels critiques, la cybersécurité ou les outils collaboratifs, cette orientation devient difficile à éviter.

L’argent des contribuables européens ne devrait pas, par défaut, financer l’approfondissement des dépendances européennes.

La formation, condition cachée de la bascule

Un autre point mérite d’être rappelé : aucune stratégie Open Source First ne fonctionnera sans compétences. C’était le cœur d’un précédent article consacré au rôle décisif du recrutement et de la formation dans la construction d’une autonomie numérique européenne.

Changer de logiciels, de cloud, d’outils collaboratifs ou d’infrastructures ne se résume pas à signer de nouveaux contrats. Cela demande des équipes capables d’évaluer les solutions, de migrer les données, de former les utilisateurs, de maintenir les systèmes, d’assurer le support et d’accompagner les organisations.

L’exemple de SensioLabs illustre bien cette dimension. Autour de Symfony, l’entreprise a construit un véritable écosystème de montée en compétence : formations, e-learning, préparation à la certification, accompagnement des équipes techniques et parcours adaptés aux différents niveaux. Cette capacité à former, certifier et accompagner les développeurs montre qu’une technologie ouverte ne devient réellement solide pour les organisations que lorsqu’elle s’appuie aussi sur des compétences structurées.

Enfin, si la demande augmente plus vite que les compétences disponibles, le risque sera réel : les projets seront perçus comme trop complexes, trop chers et trop longs. Les fournisseurs dominants déjà installés pourront alors présenter le statu quo comme une solution de prudence, alors qu’il entretient souvent la dépendance.

La souveraineté numérique se joue donc aussi dans les ressources humaines. Former les acheteurs publics, les DSI, les agents, les intégrateurs, les techniciens, les ingénieurs, les développeurs et les décideurs devient une condition de réussite. Le logiciel libre ne devient une véritable alternative que lorsqu’il est porté par des compétences solides, des prestataires capables de l’accompagner et des organisations prêtes à en maîtriser les usages.

Une Europe qui régule, ou une Europe qui construit ?

La lettre ouverte publiée par SUSE arrive à un moment révélateur. L’Europe parle de souveraineté technologique, prépare un paquet stratégique, réfléchit au cloud, à l’IA, aux semi-conducteurs, aux infrastructures ouvertes. Mais les arbitrages restent sensibles, parce qu’ils touchent directement aux intérêts des grandes puissances technologiques.

Le choix qui se présente n’est pas entre ouverture et fermeture. Il est entre dépendance subie et autonomie stratégique organisée.

L’Europe peut continuer à produire des stratégies ambitieuses tout en laissant ses marchés publics renforcer les positions des géants étrangers. Elle peut décider que ses achats publics deviennent un levier et un instrument de transformation industrielle.

Le principe Open Source First ne résoudra pas tout. Il ne remplacera pas les investissements, la formation, les infrastructures, les standards, la cybersécurité, ni la politique industrielle. Mais il peut imposer une discipline nouvelle : avant de financer une dépendance, regarder sérieusement s’il existe une voie plus ouverte, plus maîtrisable et plus européenne existe.

Ce serait déjà un changement profond.

Car au fond, la question posée par cette lettre ouverte est simple : à quoi sert de parler de souveraineté numérique si l’argent public continue d’acheter l’enfermement ?

Le 3 juin, la Commission européenne ne présentera peut-être qu’une étape. Mais cette étape dira beaucoup de la direction prise par l’Europe. Une Europe qui encadre le numérique des autres ou une Europe qui commence enfin à bâtir les conditions de sa propre puissance.

L’article Open Source First : l’appel des entreprises européennes pour changer les règles du jeu est apparu en premier sur Souverain.

L’avant-propos du rapport est signé par Cina Lawson, ministre togolaise de l’Efficacité du service public et de la Transformation numérique, et Aaron Maniam, expert praticien associé à la Blavatnik School of Government de l’université d’Oxford, où il travaille sur les liens entre transformation numérique, politiques publiques et administration. Tous deux sont co-présidents du Global Future Council on GovTech and Digital Public Infrastructure. Le rapport s’inscrit toutefois dans une contribution collective de ce Conseil, et non dans la prise de position de deux auteurs isolés.

Avant d’entrer dans le fond, il est toujours bon de rappeler le contexte : le World Economic Forum n’est ni un gouvernement, ni une institution européenne, ni une autorité publique démocratiquement élue. Ce rapport doit donc être lu pour ce qu’il est : une contribution issue d’un espace international de réflexion et de coopération public-privé, et non comme une doctrine officielle à adopter sans recul. Cette distance est nécessaire, surtout lorsqu’il est question de services publics, de données citoyennes et d’infrastructures numériques critiques.

L’intérêt de ce document tient pourtant à un point précis : même dans un cadre aussi institutionnel et modéré que celui du WEF, la souveraineté numérique apparaît désormais comme un sujet difficile à contourner. Elle n’est plus seulement une affaire d’experts, de juristes, d’ingénieurs ou de militants du logiciel libre. Elle concerne directement la vie quotidienne des citoyens : les impôts, la santé, l’école, la retraite, l’identité, les aides sociales, le logement ou encore l’accès aux droits.

Le grand public a tout intérêt à s’emparer du sujet qui le concerne directement. Un service public numérique peut simplifier une démarche pour certains, tout en devenant un obstacle pour d’autres : personnes âgées, citoyens peu à l’aise avec l’écrit, foyers mal connectés, usagers sans smartphone récent, personnes en situation de handicap ou publics déjà fragilisés par la complexité administrative. La souveraineté numérique commence aussi là : dans la capacité d’un État à garantir que la modernisation ne crée pas une citoyenneté à deux vitesses.

Elle se joue aussi dans les choix techniques et contractuels. Lorsqu’une administration devient dépendante d’un prestataire privé, d’un logiciel fermé, d’un cloud difficile à quitter ou d’un format de données peu réutilisable, le problème dépasse la simple question technique. Il touche au coût du service public, à la capacité de changer de fournisseur, à la maîtrise des données et, plus largement, à l’indépendance des décisions de l’État.

Les données des citoyens ne sont pas une matière première ordinaire. Elles peuvent dire quelque chose de notre santé, de notre situation familiale, de nos revenus, de nos déplacements, de nos droits ou de nos fragilités. Leur protection ne relève donc pas seulement de la cybersécurité : elle engage la confiance démocratique. Un citoyen ou une citoyenne doit pouvoir savoir qui utilise ses données, dans quel but, sous quelle législation, avec quelles garanties et avec quels recours en cas d’erreur ou d’abus.

La souveraineté numérique concerne aussi les logiciels, les standards, les contrats, l’interopérabilité, la portabilité des données, les compétences internes de l’administration, les audits indépendants, la possibilité de contester une décision automatisée et la capacité de l’État à corriger ses propres systèmes. Avec l’arrivée de l’intelligence artificielle dans certains services publics, cette question devient encore plus sensible : lorsqu’un algorithme contribue à une décision administrative importante, l’explication, le contrôle humain et le droit au recours ne sont pas des détails techniques, mais des garanties démocratiques.

Au fond, la souveraineté numérique pose une question simple : un État peut-il encore garantir des services publics fiables, accessibles et protecteurs s’il ne maîtrise ni ses outils, ni ses données, ni ses prestataires, ni les règles techniques qui organisent l’accès aux droits ? À sa manière, ce rapport confirme qu’au-delà des principes politiques, la souveraineté numérique implique des actions concrètes et se joue également dans des choix pragmatiques, souvent invisibles pour les citoyens. Cette transformation doit aussi être évaluée au regard de sa capacité à rester maîtrisable, transparente, inclusive et responsable dans le temps.

Numériser ne suffit pas à améliorer le service public

La numérisation des services publics peut être très utile. Elle peut simplifier des démarches, réduire les lourdeurs administratives, éviter des déplacements inutiles, accélérer certains traitements et améliorer l’accès à l’information. Le rapport reconnaît cette promesse : bien encadrées, les technologies publiques peuvent améliorer la qualité des services, réduire les charges administratives et élargir l’accès aux services publics.

Mais le rapport insiste aussi sur l’autre versant du sujet. Une numérisation mal pensée peut produire exactement l’inverse : exclure les publics les plus fragiles, rendre les décisions plus opaques, renforcer la dépendance à des fournisseurs privés et affaiblir la confiance dans l’État. Le problème ne vient donc pas seulement de la technologie elle-même, mais de la manière dont elle est conçue, gouvernée, contrôlée et corrigée dans le temps.

En clair : un service public en ligne n’est pas automatiquement un meilleur service public. Tout dépend de la capacité de l’État à garder la maîtrise de ses choix techniques, de ses données, de ses prestataires, de ses règles de contrôle et de ses voies de recours.

C’est précisément là que la souveraineté numérique entre dans le débat.

Les principes directement liés à la souveraineté numérique

1. Éviter la dépendance aux fournisseurs privés

Le principe 4 du rapport est probablement le plus directement lié à la souveraineté numérique. Il affirme que les technologies publiques et les infrastructures numériques doivent créer de la valeur pour la société, et non extraire cette valeur au profit d’acteurs qui finiraient par contrôler les systèmes essentiels.

Le rapport met en garde contre plusieurs risques très concrets : le verrouillage fournisseur, la dépendance technique, la perte de souveraineté, la monétisation des données citoyennes et la perte de contrôle sur des infrastructures critiques.

Le verrouillage fournisseur, ou vendor lock-in, désigne une situation simple à comprendre : une administration choisit une solution, puis devient tellement dépendante de son prestataire qu’elle ne peut presque plus en sortir. Les données sont difficiles à récupérer, les formats ne sont pas ouverts, les contrats sont rigides, les compétences internes ont disparu, et chaque changement devient coûteux.

Dans un service public, ce risque est majeur. Il ne concerne pas seulement le prix d’un logiciel. Il concerne la capacité de l’État à changer de trajectoire, à migrer vers une autre solution, à auditer un système, à corriger une erreur ou à reprendre la main en cas de conflit avec un fournisseur.

C’est pour cela que le rapport insiste sur les standards ouverts, les architectures interopérables, la portabilité des données, les contrats permettant la migration, les audits indépendants et les stratégies multi-fournisseurs.

Autrement dit, la souveraineté numérique ne se joue pas uniquement au moment où l’État achète une solution. Elle se joue aussi dans la capacité à en sortir.

2. Protéger les données des citoyens

Le principe 6 est encore plus explicite. Il parle de souveraineté des données citoyennes et affirme que les gouvernements doivent conserver une souveraineté numérique au niveau national, notamment en maintenant un contrôle stratégique sur les infrastructures critiques, les standards et l’évolution des systèmes dans le temps.

Ce passage est central. Il rappelle que les données publiques ne sont pas de simples informations techniques. Elles peuvent concerner l’identité, la santé, la fiscalité, les prestations sociales, les déplacements, les droits ou les situations personnelles des citoyens.

Le rapport recommande donc plusieurs garde-fous : des lois de protection des données, une supervision indépendante, des sanctions en cas d’abus, le stockage et le traitement des données sensibles sous juridiction nationale, le chiffrement, la limitation des accès, la traçabilité, ainsi que des stratégies de cloud sécurisé et souverain.

Derrière l’expression « cloud souverain », l’enjeu n’est pas seulement technique. Il ne s’agit pas seulement de savoir où se trouve physiquement un serveur. L’enjeu est aussi juridique, contractuel et opérationnel :

• qui contrôle l’infrastructure ?
• quelle loi s’applique ?
• qui peut accéder aux données ?
• l’État peut-il auditer le système ?
• peut-il migrer ailleurs ?
• peut-il garantir la continuité du service ?

Cette approche rejoint directement les débats européens sur la souveraineté numérique : la maîtrise des données n’a de sens que si elle s’accompagne d’une maîtrise des infrastructures, des règles d’accès, des prestataires et des capacités internes.

Contrôle, résilience, audit : les autres visages de la souveraineté numérique

3. Auditer, expliquer et contester les décisions numériques

Le principe 5 ne parle pas de souveraineté au sens industriel du terme. Il parle de transparence, de responsabilité et de confiance. Mais il touche à un point essentiel : lorsqu’un algorithme intervient dans une décision administrative importante, l’enjeu n’est pas seulement technique. Le citoyen doit pouvoir comprendre la décision, la contester, obtenir une révision humaine et savoir qui en porte la responsabilité.

Le rapport explique que les systèmes publics doivent être explicables, auditables et gouvernés par l’État de droit. Il recommande des mécanismes de contrôle pour l’usage des données et de l’IA, des traces d’audit pour les décisions automatisées, des exigences d’explicabilité, des recours humains et des mécanismes de correction lorsque des décisions importantes affectent les droits des citoyens.

Ce point est fondamental. Lorsqu’un algorithme participe à une décision sur une aide sociale, une allocation, un contrôle, une orientation administrative ou un accès à un droit, la souveraineté ne signifie pas seulement héberger les données chez soi. Elle signifie aussi : pouvoir comprendre comment la décision a été produite, pouvoir la contester, pouvoir identifier une erreur, pouvoir suspendre un système problématique.

C’est une souveraineté démocratique autant que technique.

4. Refuser le numérique pour le numérique

Le principe 7 critique une tentation bien connue : celle du tout-numérique. Autrement dit, l’idée qu’une nouvelle plateforme, une nouvelle application ou un nouvel outil technique serait nécessairement la meilleure réponse à un problème administratif. Le rapport invite au contraire à une approche plus sobre : réutiliser ce qui existe, simplifier les démarches avant de les numériser, conserver des alternatives lorsque c’est nécessaire et éviter d’ajouter de nouvelles couches techniques à des systèmes déjà complexes.

Ce principe est fortement lié à la souveraineté numérique, car l’empilement de plateformes, de logiciels et de prestataires crée souvent une dépendance par la complexité. Plus l’État multiplie les systèmes fermés, mal documentés et peu interopérables, plus il devient difficile de les maintenir, de les faire communiquer ou de les remplacer.

La souveraineté numérique demande souvent de bâtir. Mais elle demande aussi de savoir ne pas construire juste pour construire. Simplifier une procédure, supprimer une étape inutile, mutualiser une brique commune ou réutiliser une infrastructure existante peut être plus souverain que lancer une nouvelle plateforme.

Le rapport insiste notamment sur les architectures modulaires, les modèles d’interopérabilité et la réduction des systèmes spécifiques trop lourds.

5. Construire des systèmes résilients, pas des vitrines numériques

Le principe 8 insiste sur la résilience. Un service public numérique doit pouvoir évoluer, résister aux crises, être corrigé après un incident et continuer à fonctionner même en cas de panne. Le rapport parle de systèmes modulaires, sécurisés, adaptables, de gestion des incidents, de plans de secours et de réduction de la dette technique.

Cette idée rejoint directement la souveraineté numérique. Un État ne peut pas se dire souverain s’il ne sait pas maintenir ses propres systèmes, les réparer, les documenter, les sécuriser ou les faire évoluer. La dépendance ne vient pas seulement d’un fournisseur étranger. Elle peut aussi venir d’une perte de compétence interne, d’une documentation absente, d’un empilement technique devenu impossible à maîtriser.

La souveraineté numérique est donc aussi une capacité de maintenance. Ce sont des sujets peu visibles, mais ce sont eux qui déterminent si l’État garde réellement la main sur ses systèmes.

6. Mesurer les résultats réels

Le principe 9 rappelle qu’une politique numérique doit être évaluée. Le rapport recommande de définir des indicateurs avant le lancement, de publier des données de performance, de mesurer la qualité du service, d’analyser les réclamations, les recours et les erreurs, puis d’adapter les services en continu.

Ce principe est moins directement lié à la souveraineté numérique que les précédents, mais il joue un rôle utile. Beaucoup de projets numériques sont présentés comme des succès dès leur lancement. Mettre un service public en ligne ne suffit pas à en faire un progrès : encore faut-il regarder ce qu’il produit réellement. C’est-à-dire :

• les citoyens l’utilisent-ils ?
• les publics fragiles y accèdent-ils ?
• les erreurs diminuent-elles ?
• les délais baissent-ils ?
• les recours sont-ils traités ?
• le coût réel est-il maîtrisé ?

La souveraineté numérique suppose aussi une culture de l’évaluation : regarder ce que les services produisent réellement, corriger ce qui ne fonctionne pas et ne pas confondre lancement d’une plateforme avec réussite du service public.

7. Faire de la souveraineté un sujet de pilotage politique

Le principe 10 affirme que les projets GovTech ne sont pas seulement des projets techniques. Ce sont des transformations institutionnelles. Ils demandent un pilotage politique clair, des responsabilités identifiées, une coordination entre administrations, des budgets cohérents, une conduite du changement et des compétences internes.

Ce point est déterminant. La souveraineté numérique ne se décrète pas uniquement par de grands discours. Elle demande une administration capable de piloter ses choix techniques, de rédiger de bons contrats, d’éviter les dépendances, de conserver des compétences, de former ses agents et de coordonner ses décisions.

Sans pilotage, la souveraineté devient un mot posé sur des systèmes que personne ne maîtrise vraiment.

Ce que le Forum économique mondial disait déjà en 2025

Le lien avec l’article publié par le WEF en janvier 2025 (en anglais) est intéressant. Cet article, signé par Sean Fleming, expliquait que la souveraineté numérique dépasse la seule régulation des données. Elle inclut aussi l’innovation, le financement, les infrastructures, les logiciels, le matériel et les standards.

L’article définissait la souveraineté numérique comme la capacité à contrôler son « destin numérique » : les données, le matériel et les logiciels dont un pays dépend ou qu’il crée. Il rappelait aussi une grille de lecture en trois couches :

• la couche physique, c’est-à-dire les infrastructures et technologies
• la couche du code, c’est-à-dire les standards, les règles et le design
• et la couche des données, c’est-à-dire leur propriété, leurs flux et leurs usages.

Le texte de 2025 soulignait également que la souveraineté numérique est devenue un enjeu de compétition entre l’Union européenne, les États-Unis et la Chine. Il évoquait la concentration du pouvoir numérique dans un petit nombre d’entreprises, les débats sur le RGPD, l’AI Act, les transferts de données transatlantiques et le cloud souverain.

Là encore, une précision est nécessaire : l’article de 2025 précise que les avis exprimés sont ceux de l’auteur, et non nécessairement ceux du World Economic Forum. On peut donc rester prudent sur la portée exacte de ces textes, tout en constatant une continuité : la souveraineté numérique apparaît désormais comme un enjeu récurrent dans les réflexions portées autour du Forum économique mondial.

Les continuités entre 2025 et 2026

1. La souveraineté numérique reste une affaire de contrôle

En 2025, le FEM présentait la souveraineté numérique comme la capacité à contrôler les données, les logiciels, le matériel et les infrastructures dont on dépend. En 2026, le rapport applique cette logique aux services publics : il parle de contrôle stratégique sur les infrastructures critiques, les standards et l’évolution des systèmes publics dans le temps.

La continuité est nette : la souveraineté n’est pas réduite à la localisation des données. Elle concerne toute la chaîne technique et institutionnelle.

2. Les données restent au cœur du sujet

En 2025, l’article mettait en avant le rôle du RGPD et la capacité des citoyens européens à mieux contrôler l’usage de leurs données. En 2026, le rapport parle de souveraineté des données citoyennes, de protection juridique, de droit d’accès, de correction, de suppression, de limitation des usages et de supervision indépendante.

La logique se prolonge : la donnée citoyenne ne relève pas seulement de la gestion administrative. Elle engage la protection des personnes, l’exercice des droits et la confiance démocratique.

3. Le cloud souverain reste un point de friction majeur

En 2025, l’article présentait le cloud souverain comme un levier pour maintenir les données publiques dans un environnement technique et juridique maîtrisé. En 2026, le rapport prolonge cette logique en recommandant des stratégies de cloud sécurisé et souverain, afin de mieux protéger les données citoyennes, d’encadrer leur traitement et de garantir la continuité des services publics qui en dépendent.

La continuité est toujours présente : sans maîtrise du cloud, une partie de la souveraineté des services publics reste fragile.

4. La concentration du pouvoir numérique reste identifiée comme un problème

L’article de 2025 évoquait le sentiment, chez de nombreux décideurs publics, d’un pouvoir trop concentré entre les mains d’un petit nombre d’entreprises technologiques. En 2026, le rapport formule ce risque dans le langage de l’administration : verrouillage fournisseur, dépendance, perte de contrôle sur les infrastructures critiques, monétisation des données citoyennes.

Le vocabulaire change, mais le diagnostic reste proche.

5. L’IA reste un sujet de souveraineté démocratique

En 2025, l’article comparait les approches européenne, américaine et chinoise de la gouvernance de l’IA, en rappelant notamment l’approche européenne fondée sur les droits humains, les obligations de transparence et les systèmes à haut risque. En 2026, le rapport traduit cette préoccupation dans les services publics : audit des décisions automatisées, explicabilité, recours humain, supervision et possibilité d’arrêter ou de revenir en arrière sur un système à risque.

La souveraineté numérique ne se limite donc pas à l’hébergement. Elle touche aussi à la capacité démocratique de contrôler les décisions automatisées.

Ce qui évolue entre 2025 et 2026

1. Le sujet devient moins géopolitique et plus opérationnel

En 2025, l’article présentait la souveraineté numérique dans un cadre très géopolitique : Union européenne, États-Unis, Chine, concurrence des modèles de gouvernance, régulation, transferts de données, cloud souverain.

En 2026, le rapport s’attache davantage aux choix très concrets qui déterminent la maîtrise d’un service public numérique : marchés publics, contrats, standards ouverts, portabilité, audits, plans de sortie, compétences internes, résilience, accessibilité, conduite du changement.

Ce n’est pas un changement de fond. C’est un changement d’échelle. Le sujet passe du grand récit géopolitique aux choix qui déterminent, au quotidien, la maîtrise d’un service public numérique.

2. La souveraineté est davantage reliée à l’expérience citoyenne

En 2025, la souveraineté numérique était surtout présentée comme un enjeu de puissance, de régulation et de contrôle. En 2026, elle est rattachée plus directement à la qualité du service public : inclusion, accessibilité, recours, confiance, droit à l’explication, correction des erreurs.

Cette évolution est importante. Elle permet de sortir la souveraineté numérique d’un débat réservé aux experts. Elle montre que la souveraineté se mesure aussi dans la vie quotidienne : une démarche accessible, une décision contestable, une donnée protégée, un service qui continue de fonctionner.

3. Le rapport 2026 encadre plus fortement les partenariats public-privé

Le FEM reste fidèle à son ADN : il ne rejette pas les partenariats entre acteurs publics et privés. En 2025 déjà, l’article soulignait que la souveraineté numérique ne se limite pas à la régulation, mais comprend aussi l’innovation, l’entrepreneuriat et le financement.

Mais le rapport 2026 ajoute des garde-fous très concrets : contrats permettant la migration, audits indépendants, standards ouverts, stratégies multi-fournisseurs, documentation complète, compétences internes et plans de transition.

Enfin, le privé n’est pas présenté comme un ennemi, mais comme un partenaire possible, à condition que l’État ne perde pas la main.

4. Le rapport 2026 parle davantage de capacité interne de l’État

Le texte de 2025 traitait surtout de souveraineté au niveau des grands blocs, des normes et des infrastructures. Le rapport 2026 insiste davantage sur la capacité de l’État à faire vivre ses systèmes : former les agents, piloter les projets, gérer les incidents, documenter les architectures, réduire la dette technique, maintenir des plans de secours.

C’est peut-être l’évolution la plus intéressante : la souveraineté numérique n’est pas seulement une question de choix technologique. C’est aussi une question de compétence publique.

Conclusion

La souveraineté numérique n’est pas un réflexe de fermeture. Elle n’est pas non plus un slogan brandi contre toute coopération privée. Elle désigne une exigence plus simple : l’État doit pouvoir décider, comprendre, auditer, corriger, maintenir et, lorsque nécessaire, changer de fournisseur.

Le rapport 2026 du Forum économique mondial ne dit pas autre chose. Il ne reprend pas forcément les mots du débat français ou européen, mais il en confirme plusieurs piliers. Enfin, la question n’est pas théorique, mais pragmatique : lorsqu’un service public dépend d’un outil numérique, l’État conserve-t-il les moyens de le comprendre, de le réparer et de le faire évoluer ?

L’article Derrière les services publics en ligne, une question de souveraineté est apparu en premier sur Souverain.