Une première note de ce type avait d’ailleurs été publiée sur les réseaux sociaux autour de l’installation d’une instance AT Protocol, le protocole utilisé notamment par Bluesky.
Avec le recul, elle semble avoir trouvé son public et répondre à un véritable intérêt. Elle sera donc probablement publiée ici également.

Pour cette première, le sujet était presque évident. Il est assumé ici comme ailleurs sur les réseaux sociaux : LaSuite fait aujourd’hui partie des solutions que je teste le plus dans ce parcours autour de la souveraineté numérique. Elle est installée, maintenue, utilisée au quotidien, documentée et régulièrement mise en avant. Il est donc assez naturel d’en parler dès qu’une occasion se présente.

Évidemment, assumer aussi clairement ce choix attire aussi les critiques. Dans les conférences et salons comme sur les réseaux sociaux, certaines remarques viennent de concurrents, d’éditeurs ou simplement de personnes qui craignent que cette initiative portée par l’État ne parasite les investissements des acteurs privés français, voire ne favorise indirectement les grandes solutions américaines. Bref, on connaît la chanson. Ce n’est pas le sujet ici et l’objectif n’est pas d’ouvrir une nouvelle polémique.

En revanche, parmi toutes les remarques reçues, une question revenait régulièrement et méritait d’être prise au sérieux : la souveraineté numérique, c’est bien la liberté de choisir ?

Sur ce point, ma position est sans ambiguïté : oui.

Mais une seconde question venait immédiatement derrière : si cette souveraineté repose réellement sur la liberté de choisir, est-il possible demain de quitter LaSuite sans difficulté et sans y perdre des plumes ?

Et là, il fallait reconnaître une chose : je n’avais pas la réponse.

Il aurait été facile de chercher quelques arguments permettant de défendre une solution appréciée, de sélectionner les éléments les plus favorables et de conclure que tout allait pour le mieux dans le meilleur des mondes possibles. Mais cela aurait complètement raté l’objectif. Une démarche de souveraineté numérique suppose aussi d’accepter de remettre ses propres choix en question. Sinon, il ne s’agit plus vraiment de souveraineté, mais simplement d’une nouvelle guerre de chapelles.

La question devenait donc beaucoup plus concrète : si demain une organisation ou un utilisateur souhaite partir, peut-il récupérer ses documents, ses fichiers, ses données et son travail dans de bonnes conditions ? Et surtout, peut-il réellement repartir ailleurs ?

C’est ce que cette note cherche à examiner.

C’est aussi là que Genma, suivi depuis de nombreuses années et véritable source d’inspiration sur ces sujets, est entré dans l’histoire. Lui aussi a posé cette question. La réponse était simple : nous ne la connaissions pas encore, mais il était possible d’essayer de la trouver à deux.
De là est née une proposition qui me paraissait évidente : pousser l’exercice jusqu’au bout et écrire cette note à quatre mains.

Il a répondu : Chiche

Il n’en fallait pas davantage.

Et travailler cette question avec lui avait justement un intérêt majeur : ne pas rester dans une logique de validation. Son rôle a été au contraire de challenger la démarche, de poser les questions qui fâchent, de pointer les angles morts et d’obliger à aller plus loin. Le but de l’exercice n’était donc absolument pas de faire les louanges de LaSuite, mais de vérifier si cette solution correspond réellement aux principes défendus autour de la souveraineté numérique.

N’étant ni technicien, ni développeur, ni ingénieur, ni issu du sérail, il semblait également indispensable que le regard d’un vrai expert puisse venir compléter cette réflexion. Genma a donc apporté cette dimension : aider à poser les bonnes questions, confronter les intuitions à la réalité technique, et surtout valider, nuancer ou corriger les conclusions lorsque cela était nécessaire.

C’est dans cet esprit que cette note est proposée. Pas comme une vérité définitive, ni comme une démonstration destinée à défendre LaSuite à tout prix, mais comme le résultat d’une recherche menée avec une question simple en tête : peut-on réellement parler de souveraineté si l’on n’est pas libre de partir ?

Et comme toujours dans ce type de démarche, toute correction, remarque, objection ou question supplémentaire est la bienvenue.

Objet de la note

Cette note vise à évaluer dans quelle mesure LaSuite, portée par la DINUM, peut être quittée facilement par une organisation qui souhaiterait migrer vers une autre solution.

L’enjeu est simple : une suite numérique souveraine ne doit pas seulement proposer une alternative à Microsoft 365 ou Google Workspace. Elle doit aussi permettre à ses utilisateurs de garder la maîtrise de leurs données, de leurs fichiers et de leurs usages. Autrement dit, elle ne doit pas recréer une nouvelle forme de dépendance technique.

Dans ce cadre, la question étudiée est la suivante : un utilisateur ou une organisation peut-il récupérer ses données et changer d’outil dans de bonnes conditions ?

Périmètre du test

L’analyse générale porte sur trois briques logicielles de LaSuite : Grist, Fichiers et Docs.
Le test pratique, mené sur une instance auto-hébergée sous YunoHost, porte, lui, uniquement sur Docs, car Fichiers n’est pas disponible dans cette installation et Grist n’y a pas été installé.

Pour rappel, les rôles de ces différentes briques sont les suivants :

• Grist : application pour des tableaux structurés et des bases de données légères ;
• Fichiers : le stockage et le partage des documents
• Docs : pour la rédaction collaborative de documents avec possibilité d’export des contenus.

Ces trois briques ont été retenues car elles concentrent à elles-seules les usages les plus sensibles en matière de réversibilité. Ce sont en effet les espaces où les utilisateurs produisent, stockent, organisent et partagent leurs données de travail.

En cas de migration, ce sont donc les premiers éléments réinstallés pour lesquels on doit pouvoir récupérer proprement les données.

Méthode retenue

L’analyse repose sur quatre démarches complémentaires.

• D’abord, une première question a été posée sur le canal Matrix de la communauté DINUM. L’objectif était d’observer la qualité de l’aide disponible, la réactivité de la communauté et la capacité du canal à orienter un utilisateur vers des réponses concrètes.
• Ensuite, un contact a été pris avec LaSuite.coop, une SCOP qui utilise LaSuite comme base technique et la met à disposition de ses propres clients. Cette démarche permettait d’obtenir un retour plus opérationnel, plus proche des usages réels d’une structure qui accompagne des organisations.
• Une recherche a également été menée dans la documentation officielle de LaSuite, notamment à partir de son dépôt GitHub. Cette étape visait à vérifier si les possibilités d’export, de migration ou de récupération des données sont documentées de manière claire et accessible.
• Enfin, un test pratique a été mené depuis une instance auto-hébergée sur YunoHost. L’objectif est de confronter les éléments théoriques recueillis aux conditions réelles d’usage : installation, récupération des données, possibilités d’export et capacité à repartir vers une autre solution sans rencontrer de blocage majeur.

Cette méthode permet donc de croiser quatre niveaux d’information : l’aide communautaire, le retour d’un acteur professionnel utilisant la solution, la documentation officielle disponible et un test concret en environnement auto-hébergé.

Premiers retours obtenus

1. Retour du canal Matrix de la communauté DINUM

Le premier retour obtenu sur le canal Matrix confirme que la question de la réversibilité est bien identifiée comme un sujet important. Plusieurs réponses ont reconnu que la possibilité de quitter une suite numérique sans perdre ses données, son organisation de fichiers ou ses usages devait être prise au sérieux.

En revanche, les échanges n’ont pas permis d’obtenir une réponse immédiatement complète et opérationnelle. La principale piste évoquée concerne le projet OpenBuro, mentionné par Riël Notermans, de mosa.cloud.

OpenBuro ne se présente pas comme une nouvelle suite bureautique complète, mais plutôt comme un standard commun destiné à faire mieux communiquer entre elles différentes briques libres ou open source : documents, fichiers, messagerie, agenda, outils collaboratifs, etc. L’objectif est de dépasser le simple assemblage d’applications séparées pour construire une expérience plus cohérente, comparable à ce que proposent Microsoft 365 ou Google Workspace, mais sans dépendance à un seul éditeur.

Cette piste est intéressante pour la réversibilité, car elle va dans le sens d’une meilleure interopérabilité entre les outils. À terme, un tel standard pourrait faciliter le passage d’une solution à une autre, en conservant mieux les fichiers, les liens entre services, les droits d’accès, les espaces de travail et l’arborescence documentaire.

Cependant, à ce stade, OpenBuro reste encore un projet en construction. Les éléments disponibles permettent de comprendre l’ambition et la direction prise, mais ne suffisent pas encore à démontrer qu’une migration complète, simple et transparente est déjà possible en conditions réelles. Il s’agit donc d’une piste prometteuse, mais pas encore d’une garantie pratique immédiate pour l’utilisateur final.

Le retour du canal Matrix est donc contrasté : la communauté semble consciente du sujet et capable d’orienter vers des initiatives pertinentes, mais la réponse apportée reste encore prospective.

2. Retour de LaSuite.coop

Le retour de LaSuite.coop apporte des éléments plus concrets, car il vient d’un acteur qui utilise LaSuite comme base technique et la propose à des clients.

Sur les formats de fichiers, plusieurs garanties importantes ressortent.

Pour Docs, l’outil permet l’import de fichiers au format .docx et .md, ainsi que l’export vers .docx, .odt et .pdf. Le format .odt est particulièrement important, car il constitue un format ouvert de référence dans le monde bureautique, notamment avec LibreOffice. Cela va dans le bon sens pour éviter l’enfermement dans un format propriétaire unique.

Pour Fichiers, le point le plus rassurant est que les documents sont conservés à l’identique. Autrement dit, les fichiers déposés dans l’espace de stockage ne sont pas transformés ou enfermés dans un format propre à la plateforme. Ce que l’utilisateur dépose est ce qu’il peut récupérer. C’est un élément important pour la réversibilité, car cela réduit fortement le risque de perte ou de dégradation lors d’un départ vers une autre solution.

Pour Grist, l’import et l’export sont possibles en CSV et en Excel. Son format natif repose sur SQLite, ce qui constitue également un point positif, car SQLite est une technologie ouverte, connue et largement documentée. En revanche, une limite actuelle doit être signalée : l’import au format .ods, utilisé notamment par LibreOffice Calc, n’est pas encore disponible. Cela constitue une faiblesse pour les organisations qui veulent privilégier complètement les formats ouverts dans leurs usages bureautiques.

LaSuite.coop indique également qu’un export complet des données peut être fourni lorsqu’une organisation souhaite mettre fin à son abonnement ou migrer vers un autre prestataire. Ce point est important, car il montre que la réversibilité n’est pas seulement abordée sous l’angle technique, mais aussi sous l’angle de l’accompagnement client.

Toutefois, une limite importante est reconnue : la conversion de formats vers d’autres systèmes n’est pas encore disponible. Elle figure dans la feuille de route, mais ne peut pas encore être considérée comme une fonctionnalité pleinement opérationnelle.

Enfin, LaSuite.coop insiste sur le fait que les outils sont auto-hébergeables et que leur code source est disponible. Cela renforce l’idée qu’une organisation peut, en théorie, reprendre la main sur son hébergement ou confier la gestion à un autre prestataire. Cette possibilité est un élément central de souveraineté : la capacité de partir ne dépend pas seulement d’un bouton d’export, mais aussi de la possibilité de continuer à utiliser ou à déployer les outils ailleurs.

À ce stade, le retour de LaSuite.coop est donc plutôt positif. Il montre que LaSuite repose sur des formats ouverts, des outils auto-hébergeables et une logique d’export des données. Mais il confirme aussi que certaines fonctions de réversibilité avancée, notamment la conversion complète vers d’autres environnements, restent encore à consolider.

3. Lecture de la documentation officielle de LaSuite

La troisième démarche a consisté à lire la documentation publique disponible autour de LaSuite, notamment les pages officielles, les FAQ, les dépôts GitHub de Docs et Fichiers, ainsi que la documentation officielle de Grist vers laquelle LaSuite renvoie.

L’objectif était de vérifier si la réversibilité est seulement un principe affiché, ou si elle repose sur des éléments concrets : formats d’export, import de fichiers, API, possibilité d’auto-hébergement et récupération des données.

La lecture de la documentation montre que les trois briques étudiées disposent bien de portes de sortie techniques.

Pour Docs, les éléments sont plutôt rassurants. L’outil permet l’import de documents en .docx et en Markdown, selon le dépôt GitHub du projet. Il permet aussi l’export vers des formats courants comme Word, PDF et ODT, d’après la page officielle de Docs. Le format .odt est important car il s’agit d’un format ouvert, utilisé notamment par LibreOffice. Docs peut aussi être auto-hébergé, et la documentation mentionne une API permettant de récupérer, lister, déplacer ou restaurer des documents. Cela montre que la sortie ne se limite pas forcément à un export manuel fichier par fichier.

Pour Fichiers, le principe est encore plus simple : la documentation indique que l’outil permet de stocker et télécharger des fichiers de tout type. Cela suggère que les fichiers peuvent être récupérés dans leur format d’origine, sans dépendre d’un format documentaire propre à la plateforme. C’est un point important, car la meilleure garantie de réversibilité, pour un espace de stockage, est de pouvoir récupérer ses fichiers tels qu’ils ont été déposés. La documentation technique montre aussi que Fichiers repose sur un stockage compatible S3 et sur une API permettant de manipuler les éléments, les dossiers et certains paramètres.

En revanche, je n’ai pas trouvé de procédure détaillée, pensée pour un utilisateur non technique, permettant d’exporter simplement tout un espace complet avec son arborescence. Pour une petite structure, la récupération manuelle peut suffire ; pour une organisation avec beaucoup de données, une migration sérieuse demandera probablement un accompagnement technique.

Pour Grist, la documentation est la plus complète sur le sujet de la réversibilité. Grist permet d’exporter une table en CSV ou XLSX. Il permet aussi d’exporter toutes les tables d’un document au format Excel, ou de télécharger un document complet au format .grist, qui repose sur SQLite. Ce point est important, car SQLite est une technologie ouverte, connue et lisible par de nombreux outils. Le fichier .grist permet donc de conserver une copie plus complète du document, et pas seulement une sortie simplifiée en tableur. La documentation indique également que Grist peut être auto-hébergé, ce qui permet de changer d’hébergeur tout en continuant à utiliser le même outil.

Le bilan de cette lecture est donc plutôt positif : LaSuite ne repose pas uniquement sur un discours de souveraineté. Pour les trois briques étudiées, il existe des éléments techniques concrets qui permettent de récupérer ses données, de les exporter ou de réhéberger les outils.

Il faut cependant distinguer deux niveaux.

D’un côté, la réversibilité technique est réelle : formats ouverts ou standards, exports, API, code source ouvert et possibilité d’auto-hébergement.

De l’autre, la réversibilité contractuelle est moins détaillée dans la documentation publique consultée. La DINUM indique bien qu’un service sorti de bêta doit permettre un export des données dans un format ouvert en cas de fermeture du service. Mais je n’ai pas trouvé, pour chaque brique, une présentation très précise des délais de restitution, des formats exacts livrés lors d’un départ, de l’assistance fournie, du coût éventuel d’une migration ou de la récupération complète des droits d’accès et métadonnées.

En résumé, la documentation officielle confirme que l’on peut quitter LaSuite dans de meilleures conditions que des plateformes fermées. Mais elle gagnerait à rendre plus visibles, pour les organisations non techniques, les procédures concrètes de sortie : que récupère-t-on exactement, sous quel format, en combien de temps, avec quel accompagnement et avec quelles limites.

4. Test pratique depuis une instance auto-hébergée sur YunoHost

Un test pratique a été mené depuis une instance auto-hébergée sur YunoHost. Il ne porte que sur Docs, car Fichiers n’est pas disponible dans cette installation YunoHost et Grist n’a pas été installé sur cette instance.

L’application testée est La Suite – Docs, en version 4.8.6~ynh2, installée à l’adresse ecrire.mondomaine.ovh. L’environnement repose également sur Dex, utilisé pour l’authentification, et MinIO, utilisé pour le stockage objet.

Depuis l’interface utilisateur de Docs, un document de test a été créé puis exporté dans les formats proposés par l’application : PDF, DOCX, ODT et HTML sous forme d’archive ZIP. Ces exports permettent bien de récupérer le contenu du document : titre, paragraphes, liste, tableau, lien et structure générale. Ils constituent donc une solution simple pour repartir avec le contenu vers une autre suite bureautique ou un autre outil de traitement de texte.

En revanche, le test montre que ces exports ne conservent pas les éléments collaboratifs. Après partage du document avec une autre adresse, l’export HTML a été refait : il ne contient ni l’adresse invitée, ni le rôle attribué, ni les informations de partage. Le même constat vaut pour les exports bureautiques classiques : ils récupèrent le document, mais pas l’environnement de collaboration qui l’entoure.

La vérification côté serveur donne un résultat différent. La base PostgreSQL de Docs contient bien les informations de partage. Le document de test apparaît dans la table des documents, avec son titre, son identifiant, son niveau d’arborescence et ses paramètres de lien. L’invitation créée pendant le test est également enregistrée dans la base, avec l’adresse invitée, le rôle editor, le document concerné et l’utilisateur à l’origine de l’invitation.

YunoHost permet aussi de créer une sauvegarde technique de l’environnement. Le test a montré qu’une sauvegarde cohérente doit inclure trois briques : lasuite-docs, minio et dex. La sauvegarde de lasuite-docs contient notamment un dump PostgreSQL, tandis que la sauvegarde de minio contient le bucket lasuite-docs, où se trouvent les objets techniques liés aux documents. Un dump direct PostgreSQL et une archive séparée du bucket MinIO ont également été réalisés avec succès.

Ce test confirme donc une distinction importante. Docs permet de récupérer facilement le contenu d’un document dans des formats standards. C’est un point favorable pour la réversibilité. En revanche, les droits, les invitations, les rôles et les informations de partage ne sont pas embarqués dans les exports utilisateur. Ils existent bien dans la sauvegarde technique de l’instance, mais sous une forme applicative, utile pour restaurer Docs, pas pour migrer simplement vers une autre solution.

La réversibilité est donc bonne pour les contenus, mais plus limitée pour l’environnement collaboratif complet. Pour conserver les droits et les partages lors d’une migration vers une autre solution, une opération technique spécifique serait nécessaire : extraction de la base, correspondance des utilisateurs, puis recréation des droits dans l’outil cible.

Conclusion : une sortie possible, mais pas encore une réversibilité complète

À ce stade, le constat est plutôt positif, mais il doit être nuancé. Les trois briques étudiées permettent bien de récupérer les contenus produits dans LaSuite.

Dans Grist, les données peuvent être exportées en formats standards, notamment en CSV ou XLSX. Il est aussi possible d’exporter l’ensemble des tables d’un document au format Excel, ou de télécharger le document complet au format .grist. Ce dernier format est plus riche, puisqu’il repose sur une base SQLite et contient les données, les fichiers joints, les pages, les vues et une partie de l’historique récent. En revanche, la documentation précise que ce fichier ne contient pas les informations sur les personnes avec qui le document est partagé.

Pour Fichiers, la logique semble également favorable à la récupération des contenus. Le code de l’application prévoit un export récursif d’un dossier sous forme d’archive ZIP, avec un service dédié qui reconstruit les chemins relatifs des fichiers et dossiers dans l’archive (service d’export ZIP). Cela signifie que l’arborescence peut être conservée lors de l’export. En revanche, les droits d’accès et les partages sont gérés séparément dans l’application, via un modèle d’accès propre aux fichiers et dossiers (ItemAccess). Rien n’indique que ces droits soient intégrés dans l’archive ZIP exportée.

Pour Docs, la situation est comparable. Le dépôt officiel indique que les documents peuvent être exportés dans plusieurs formats courants, notamment ODT, DOCX et PDF. Ces formats permettent de récupérer le contenu et de le réutiliser dans d’autres outils. En revanche, les droits et les partages sont eux aussi gérés dans un modèle séparé (DocumentAccess). Là encore, rien ne permet d’affirmer qu’un export bureautique conserve automatiquement les personnes autorisées, les rôles ou les invitations associées au document.

La conclusion est donc la suivante : LaSuite ne semble pas enfermer l’utilisateur dans ses formats. Les contenus peuvent être récupérés dans des formats standards ou exploitables. C’est un point important, car il distingue cette approche d’une dépendance fermée où les données resteraient prisonnières de la plateforme.

En revanche, la réversibilité n’est pas encore totale au sens strict. Quitter LaSuite en récupérant les fichiers, les documents et les tableaux paraît possible. Mais quitter LaSuite en conservant automatiquement toute l’organisation de travail : arborescence, droits, partages, personnes autorisées, rôles et invitations, semble nécessiter une opération plus technique, probablement fondée sur des scripts, des API ou une migration accompagnée.

Autrement dit, LaSuite paraît offrir une bonne réversibilité des contenus. Elle ne garantit pas encore, du moins dans les éléments documentés consultés, une réversibilité complète de l’environnement collaboratif.

L’article Migration, réversibilité : est-il possible de quitter LaSuite ? est apparu en premier sur Souverain.

Il y a des objets technologiques que l’on utilise. Et puis il y a ceux qui finissent, presque sans que l’on s’en rende compte, par accompagner une partie de notre vie.

L’iPhone appartient clairement à la seconde catégorie.

Le titre de cet article n’est donc pas choisi au hasard : une séparation annoncée, quelques souvenirs qui remontent, un brin de nostalgie, mais surtout la conviction qu’il est probablement temps d’aller voir ailleurs.

Je ne quitte pas Apple après une mauvaise expérience. Je ne pars pas non plus parce que l’iPhone serait soudain devenu un mauvais téléphone.

C’est même précisément ce qui rend ce changement intéressant.

Je pars après presque dix-sept années passées avec l’iPhone, parce que mes attentes et ma manière d’envisager le numérique ont changé. Et parce qu’une alternative qui me paraissait jusqu’ici trop compliquée, trop imparfaite ou trop contraignante semble enfin correspondre à ce que je recherche.

Mais pour comprendre pourquoi je m’en vais, il faut revenir un peu en arrière.

Tout a commencé en janvier 2007

En janvier 2007, comme beaucoup d’entre vous, j’ai regardé Steve Jobs présenter le premier iPhone.

À l’époque, je suivais déjà avec beaucoup d’intérêt, les évolutions de la téléphonie mobile.

Avant que le mot « smartphone » ou téléphone intelligent ne s’impose véritablement dans notre quotidien, j’avais regardé passer les BlackBerry. Je comprenais leur intérêt, mais leur ergonomie et surtout leur clavier ne m’avaient jamais vraiment séduit.

Même chose pour les Nokia Communicator, avec leur énorme clavier qui donnait davantage l’impression de transporter un ordinateur miniature qu’un téléphone.

Un autre Nokia me faisait pourtant sérieusement de l’œil : le Nokia N90.

Je m’intéressais alors beaucoup à la vidéo et son concept m’intriguait énormément. Je ne l’ai finalement jamais acheté.

À la place, je me suis arrêté sur l’un des premiers téléphones 3G, ou plutôt UMTS, comme on disait encore beaucoup à l’époque, le Nokia 7600.

Avec le recul, ce téléphone n’était vraiment pas pratique (surtout les touches sur le côté pour écrire et appeler…). Quant à son design… l’audace était incontestable ; l’élégance, davantage sujette à discussion.

C’est d’ailleurs tout le paradoxe de l’évolution de la téléphonie mobile : avant l’arrivée de l’iPhone, j’avais plutôt une attirance pour les téléphones de petite taille, avec des formes originales, parfois raffinées, parfois étranges.

Puis Apple a dévoilé cet objet presque monolithique : un large écran noir débarrassé de l’essentiel des attributs traditionnels du téléphone. Et, sans encore en mesurer toute la portée, quelque chose venait de changer la face du monde.

L’iPhone était là… mais pas encore pour moi

Le premier iPhone me faisait envie, évidemment.

Mais il restait beaucoup trop cher pour mes finances (~550€). Et surtout, il ne supportait pas encore la 3G. Il a fallu attendre un peu plus d’un an pour voir arriver l’iPhone 3G, puis l’iPhone 3GS.

Et c’est avec lui que j’ai finalement craqué.

À l’époque, j’avais acheté mon téléphone « nu », c’est-à-dire sans l’associer à l’un de ces forfaits opérateurs qui donnaient parfois l’impression que l’iPhone ne coûtait presque rien.

A l’époque, cette présentation commerciale fonctionnait plutôt bien.

On avançait certes « seulement » 149 euros pour obtenir son téléphone, mais derrière il fallait s’engager pendant douze mois dans le meilleur des cas, et souvent vingt-quatre mois.

Et il fallait facilement compter au moins 50 euros par mois pour disposer d’un forfait permettant réellement de profiter de la connexion 3G de l’iPhone sans trop de restrictions.

Puis un quatrième opérateur est arrivé sur le marché français : Free Mobile. Et cela a changé une autre partie de l’équation.

Free Mobile, l’iPhone 4 et la fin du prix caché dans le forfait

Il faut aussi remettre les choses dans leur contexte. À l’époque, lorsqu’un téléphone coûtait plus de 500 euros, on ne changeait pas nécessairement de modèle chaque année.

En tout cas, moi, je ne me le permettais pas. C’était un vrai budget.

Free proposait alors pour les iPhone 4 et 4S une formule qui ressemblait davantage à ce qu’elle était réellement : d’un côté le forfait mobile, relativement peu cher, de l’autre, le financement du téléphone.

L’iPhone n’était plus autant « emballé » dans un forfait donnant l’impression qu’il coûtait beaucoup moins cher qu’en réalité.

J’ai donc fait mes calculs.

Un forfait raisonnable, un nouvel iPhone payé progressivement sous forme de crédit, et la possibilité de changer de modèle sans devoir sortir immédiatement les quelque 629 euros demandés pour l’acheter comptant.

Entre mon premier iPhone et celui-ci, la hausse du prix était déjà franchement visible.

Mais le problème était ailleurs. Apple avait conçu un produit tellement agréable à utiliser que j’avais déjà beaucoup de mal à imaginer revenir en arrière : c’était pratique, simple et très efficace !

Android était déjà là

Pendant ce temps, Android grandissait presque sous mes yeux. Son développement s’est accéléré au moment où je découvrais mon premier iPhone 3GS, et j’ai évidemment observé cette nouvelle bataille entre iOS et Android.

Mais j’avais une préférence assez nette pour Apple.

Je dois le reconnaître : l’écosystème et le fameux effet « waouh » fonctionnaient particulièrement bien sur moi. Et puis Apple avait déjà derrière elle une longue réputation de fabricant capable de concevoir des machines très abouties.
J’entends évidemment ceux qui, déjà à l’époque, reprochaient à Apple de tout verrouiller : le matériel, le logiciel et une bonne partie de ce qui se trouvait entre les deux.

Oui.

C’était vrai.

Mais je dois aussi reconnaître quelque chose : c’était tout de même sacrément bien fait.

J’avais auparavant utilisé un iPod et j’avais immédiatement apprécié sa finition, sa simplicité et la cohérence générale du produit.

L’iPhone prolongeait exactement cette expérience. Je ne vais donc pas réécrire mon histoire avec les convictions que j’ai aujourd’hui. J’étais à l’aise dans cet environnement. Et cela me convenait parfaitement.

Fidèle, oui. Fanatique, non.

À partir de ce moment-là, je suis resté chez Apple. Mais je n’ai jamais acheté le nouvel iPhone à chacune de ses sorties. Je n’étais vraiment, mais alors pas du tout de ceux qui passaient la nuit devant un Apple Store pour avoir le privilège d’être parmi les premiers à repartir avec le nouveau modèle.

Quelle folie !

Mon cycle de renouvellement tournait plutôt autour de trois à quatre ans. Je regardais donc la bataille entre iOS et Android avec une certaine distance. Et plus les années passaient, plus Android se rapprochait d’une expérience que je pouvais considérer comme comparable à celle d’iOS. Seulement, dans le même temps, un autre problème apparaissait à mes yeux : Google devenait de plus en plus curieux et intrusif dans la vie privée du monde entier. Or j’étais précisément entré dans une période où je cherchais progressivement à réduire les dépendances que j’avais accumulées envers Google sur le Web.

Passer d’un iPhone à Android pour replonger immédiatement dans l’écosystème de Google n’avait donc pas beaucoup de sens pour moi.

Ce n’était tout simplement pas au programme.

Toutes ces alternatives que je regardais de loin

Au fil des années, j’ai vu passer plusieurs tentatives pour proposer autre chose : webOS, Windows Phone, ou bien Tizen. Et, beaucoup plus récemment, des projets comme GrapheneOS.

Je suivais tout cela avec intérêt. Mais il y avait toujours quelque chose qui me chiffonnait un peu : une installation qui me paraissait trop compliquée et un environnement qui nécessitait trop de connaissances.

Bref, un compromis trop important ou simplement l’impression de ne pas retrouver un système aussi complet et aussi agréable à utiliser qu’iOS.

Car il y a un point important dans mon rapport au numérique : je peux nourrir une véritable curiosité pour la technologie sans pour autant souhaiter que l’usage de mon smartphone exige de moi une attention et un investissement permanents. Cela doit rester un outil et il doit simplement fonctionner.

L’écosystème Apple n’a jamais été une frontière

Il y a également une nuance importante à apporter à cette longue fidélité. Même si j’ai testé par curiosité différents services Apple, je n’ai jamais réellement adopté la totalité de son écosystème. Je n’ai jamais construit toute ma vie numérique autour d’iCloud, de Photos et des autres services de la pomme.

Ni tablette, ni montre connectée, dont l’utilité ne s’est jamais réellement imposée, et encore moins d’écouteurs sans fil à 179 euros. Autrement dit, je possédais un iPhone, mais je n’étais pas entré dans une dépendance totale à l’écosystème Apple.

C’est sans doute important aujourd’hui, parce que cela rend aussi le départ beaucoup moins douloureux.

Pour autant, jusqu’à maintenant, j’étais parfaitement satisfait de l’iPhone et d’iOS, et je pense qu’il est nécessaire de le reconnaître. Il ne s’agit pas davantage de renier près de dix-sept années durant lesquelles j’ai sincèrement apprécié ces produits, ni d’ériger aujourd’hui Apple en symbole de tout ce qui dysfonctionne dans le numérique. Ce serait faux et un peu trop facile.

Puis Face ID est arrivé

Il y a pourtant eu une première vraie rupture : Face ID !

Là, c’était un peu trop pour moi.

J’ai donc continué à renouveler mon téléphone uniquement du côté des iPhone SE, qui conservaient l’ancienne technologie : Touch ID.

Cette fidélité s’est poursuivie jusqu’au dernier modèle : l’iPhone SE de troisième génération sorti en 2022, que j’utilisais encore récemment. Touch ID me convenait parfaitement.

L’iPhone disposait déjà, avec cette technologie, des informations nécessaires à la reconnaissance de mes empreintes digitales. Celles-ci ne sont pas envoyées vers les serveurs d’Apple : leur représentation reste protégée localement dans l’iPhone. Je m’étais habitué à ce compromis et n’avais aucune envie particulière d’ajouter la reconnaissance faciale à l’équation.

Et, petit à petit, la gamme d’iPhone correspondant réellement à ce que je voulais s’est réduite. Jusqu’au jour où Touch ID a disparu des nouvelles gammes. Un choix d’autant plus difficile à comprendre que cette technologie n’a nullement été abandonnée par Apple et demeure présente sur certains de ses ordinateurs et claviers.

Puis Commown est apparu dans mon paysage

Il y a quelque temps, j’ai découvert l’offre de location proposée par Commown, qui se présente comme un fournisseur militant d’électronique responsable.

Et, une nouvelle fois, cette découverte doit beaucoup à Genma.

Deux éléments ont immédiatement attiré mon attention : D’abord, la possibilité d’utiliser un Fairphone. Ensuite, celle de l’obtenir avec /e/OS, le système porté par Murena.

Pour la première fois, je voyais se dessiner quelque chose qui correspondait véritablement à ce que je cherchais : un smartphone réparable associé à un environnement mobile complet largement dégooglisé.

Sur le papier, c’était séduisant. Mais j’avais encore beaucoup de doutes. Parce que des expériences alternatives, j’en avais vu passer un certain nombre. Et beaucoup avaient fini par disparaître, stagner ou rester réservées à des utilisateurs suffisamment motivés pour accepter un niveau de complexité que je ne souhaite pas imposer à mon quotidien.

Je regardais donc encore cela avec prudence, jusqu’à une rencontre avec Genma AFK.

La découverte téléphone en main

Lors de cette rencontre, Genma m’a permis de tester son téléphone. Pas de regarder une vidéo, de lire une fiche technique ou de parcourir un site Web. De l’utiliser pour de vrai, entre mes mains. Et j’ai constaté quelque chose que je n’avais pas ressenti depuis longtemps avec une alternative à iOS : cela collait à mes besoins et l’interface était fluide. L’expérience restait agréable et les interactions étaient compréhensibles. Je ne me sentais pas devant un système conçu uniquement pour quelques experts.

Et c’est plus qu’un bon point, car même si j’aime tester, comprendre et expérimenter, j’ai aussi une exigence assez simple : l’ergonomie et l’expérience utilisateur doivent privilégier la simplicité et l’accessibilité pour assurer une navigation intuitive et compréhensible par tous.

L’efficacité d’une interface gagne à être expliquée clairement, car l’opacité technique tend à exclure inutilement ceux qui ne possèdent pas une expertise pointue.

La souveraineté numérique ne saurait avoir pour préalable une maîtrise technique poussée ni transformer l’usage quotidien d’un téléphone en exercice permanent de configuration et de maintenance.

Et j’ai aussi une autre raison, beaucoup plus personnelle, d’être exigeant sur ce point : si j’arrive moi-même à effectuer ce changement simplement, sans difficultés permanentes et sans avoir envie de jeter mon téléphone contre un mur au bout de quinze jours, alors il me sera beaucoup plus facile d’en parler autour de moi, et éventuellement de convaincre.

Parce que recommander une solution suppose, à mes yeux, d’en connaître suffisamment les qualités comme les limites pour pouvoir le faire en toute connaissance de cause.

Mais cette fois, je crois bien être prêt.

Au moment de chercher ce nouveau smartphone, je me suis d’ailleurs assez peu attardé sur la traditionnelle course aux caractéristiques techniques. La quantité de mémoire vive et l’espace de stockage ont retenu mon attention, parce qu’ils conditionnent directement la durée pendant laquelle l’appareil pourra rester confortable à utiliser. Pour le reste, les performances graphiques ou la puissance nécessaire aux jeux vidéo n’entraient pratiquement pas dans l’équation : je ne joue pas sur mon smartphone. Cela ne signifie évidemment pas que ces critères soient sans importance ; ils peuvent être déterminants pour certains usages, simplement pas pour les miens.

Un autre point comptait davantage : conserver la possibilité de déverrouiller l’appareil avec une empreinte digitale. Le Fairphone ne reprend évidemment pas Touch ID, qui demeure une technologie propre à Apple, mais il intègre un lecteur d’empreintes digitales directement dans le bouton situé sur la tranche de l’appareil. Le principe qui m’intéressait reste donc présent : pouvoir m’authentifier d’un geste, sans avoir à recourir à la reconnaissance faciale.

Pouvoir simplement changer une batterie

Il y a également quelque chose de presque dérisoire dans ce changement, mais qui raconte à lui seul une partie du problème. Avec ce nouveau smartphone, lorsqu’une pièce matérielle tombera en panne, il sera possible, dans de nombreux cas, de la remplacer moi-même, en toute autonomie et pour un moindre coût.

Et surtout, cela permettra d’éviter d’engager des frais disproportionnés lorsqu’un appareil fonctionne encore parfaitement et que le seul véritable problème vient, par exemple, de sa batterie.

Cela paraît presque évident. Pourtant, dans une industrie qui nous a progressivement habitués à des appareils collés, soudés, verrouillés ou inutilement complexes à réparer, retrouver cette possibilité ressemble presque à une nouveauté.

Et si ce choix était une erreur de parcours ?

C’est précisément là que le modèle de Commown est intéressant et permet également le retour en arrière. En effet, rien ne dit aujourd’hui que cette expérience sera concluante.
Peut-être que certaines applications vont manquer; que certains usages seront plus compliqués. Peut-être découvrirai-je des contraintes auxquelles je n’avais tout simplement pas pensé.
Et peut-être qu’au bout de quelques mois, l’iPhone SE de 2022 reprendra du service.
Ce serait possible, mais la location proposée par Commown permet justement d’aborder ce changement avec une forme de réversibilité.

Cette possibilité a évidemment un coût. Dans mon cas, pour un Fairphone 6 accompagné d’une coque à rabat et livré avec /e/OS préinstallé, mais sans câble puisque j’en dispose déjà, la location revient à 27,40 euros par mois, avec un engagement initial de douze mois.

Le modèle proposé par Commown présente toutefois une particularité intéressante : passé cette première année, le montant de la location diminue de 6 % tous les six mois, jusqu’à pouvoir atteindre une réduction maximale de 60 %. Le coût ne reste donc pas figé pendant toute la durée d’utilisation du téléphone ; il diminue progressivement à mesure que l’appareil est conservé.

Partir, oui, mais sans transformer cette décision en rupture définitive.

Cela paraît finalement assez cohérent avec ce que je tente de défendre ici depuis le début de cette quête de souveraineté numérique : réduire une dépendance ne devrait pas consister à s’enfermer immédiatement dans une autre.

La suite reste à écrire

C’est aussi pour cette raison que cet article aura une suite. Ce premier texte explique pourquoi je quitte aujourd’hui l’iPhone et iOS. Mais s’arrêter à cette conclusion reviendrait à éluder une part essentielle de l’expérience.

Commander un téléphone alternatif, l’allumer, regarder son écran d’accueil et annoncer que l’on vient de retrouver une souveraineté numérique n’aurait pas beaucoup de sens.

Le véritable test commence maintenant :

• Est-ce que mes applications habituelles fonctionneront ?
• Est-ce que mes usages bancaires suivront ?
• Est-ce que la navigation, les transports, les communications, l’authentification et tous ces petits usages devenus tellement naturels avec un smartphone resteront aussi simples ?
• Est-ce que l’absence des services Google sera réellement transparente ?

Et surtout : est-ce que je continuerai à utiliser ce téléphone lorsque l’enthousiasme de la nouveauté sera passé ?

Voilà les questions auxquelles je préfère répondre avec quelques mois de recul plutôt qu’avec quelques heures d’utilisation.

Une semaine plus tard, le téléphone est arrivé

Un peu plus d’une semaine après la validation de ma commande, le smartphone est arrivé !

Et cette fois, le départ devient réel. Après presque dix-sept années d’iPhone, il est temps de voir ailleurs. Mais pas en prétendant qu’Apple n’aurait rien apporté. Et certainement pas en reniant toutes ces années durant lesquelles ses smartphones m’ont parfaitement convenu.

Au contraire.

Si cette séparation ressemble un peu à celle évoquée par Gainsbourg, c’est justement parce qu’on ne quitte pas de la même manière quelque chose que l’on a détesté et quelque chose qui nous a longtemps satisfaits.

L’iPhone a profondément changé ma manière d’utiliser un téléphone. Il m’a accompagné pendant une très grande partie de ma vie numérique. Mais les critères qui me faisaient choisir un smartphone en 2009 ne sont plus exactement ceux qui me font en choisir un en 2026.

Aujourd’hui, la réparabilité, la maîtrise de mes données, la dépendance aux grandes plateformes, la durée de vie du matériel et la possibilité de choisir davantage les services que j’utilise comptent beaucoup plus dans l’équation. Il est donc temps de vérifier s’il est possible de concilier ces exigences avec celle que je refuse toujours d’abandonner : utiliser un smartphone caractérisé par sa sobriété, son efficacité et une expérience utilisateur optimale.

Une conviction à confronter à la réalité

Rendez-vous dans quatre ou cinq mois pour savoir si les sanglots longs de cette séparation auront fini par me faire revenir chez Apple… ou si mon iPhone restera définitivement dans un tiroir.

Sans chercher à sauver l’expérience si elle se passe mal.

Sans chercher non plus à l’embellir parce qu’elle correspondrait davantage aux idées défendues sur ce site.

Je pourrai alors répondre à une question très simple :

ai-je fini par reprendre mon iPhone SE de 2022, ou ai-je réellement quitté cet univers pour quelque chose de plus libre et de plus cohérent avec ce que j’essaie de construire ici ?

Car être souverain ne signifie pas vivre en autarcie; cela signifie plutôt, à mes yeux, essayer de retrouver suffisamment de maîtrise pour pouvoir choisir, comprendre, changer… et partir lorsque cela devient nécessaire.

Encore merci à Genma pour la découverte et pour m’avoir permis de tester concrètement cette alternative avant de me lancer.

Merci également à Commown pour la qualité des échanges et de son service avant comme après la commande.

Et une dernière précision, importante : cet article n’est pas sponsorisé. Je n’ai aucun partenariat avec Commown et je ne gagne absolument rien si, à votre tour, vous décidez de tenter l’expérience.

L’article Je suis venu te dire que je m’en vais est apparu en premier sur Souverain.

Choisir l’open source permet-il réellement de sortir des dépendances numériques ? Derrière la liberté offerte par les licences peuvent subsister des contraintes liées au support, aux compétences, à l’interopérabilité ou aux coûts de migration. À travers les regards de Florian Caringi et de Cédric Ravalec, une question est parfois négligée : comment adopter l’open source sans recréer, ailleurs, l’enfermement que l’on cherchait précisément à quitter ?

Il y a près de deux mois, grâce à Genma, j’assistais à OW2con, la conférence annuelle organisée par OW2 autour des logiciels libres et open source. J’ai notamment pu participer à la présentation de Florian Caringi, directeur adjoint chargé des données et de l’open source au sein du groupe BPCE (Banque Populaire et Caisse d’Épargne).

Le sujet n’était évidemment pas de nous expliquer comment fonctionne une banque. Non pas que la question soit inintéressante, mais ce n’est pas vraiment le genre de conférence qu’organise OW2.

Florian Caringi était venu présenter la manière dont il avait contribué à mettre en place, au sein du groupe BPCE, une véritable organisation consacrée à l’open source : des méthodes, des règles, des bonnes pratiques et une gouvernance permettant de mieux gérer son utilisation dans l’entreprise. Autrement dit, il expliquait comment l’open source pouvait devenir une brique solide de l’organisation, et non plus seulement une succession d’initiatives techniques dispersées.

Sa présentation m’avait particulièrement plu, car c’était l’une des premières fois que je voyais une organisation de cette nature réellement mise en œuvre sur le terrain. Et pas dans la plus simple des structures : nous parlons tout de même d’un grand groupe bancaire.

Comme je l’expliquais dans mon article consacré à OW2con 2026 et à l’open source européen, j’avais pu échanger avec Florian à la suite de sa présentation. J’avais apprécié son accessibilité, sa manière de transmettre son expérience et une forme d’humilité devenue, me semble-t-il, trop rare.

Nous nous sommes revus quelques semaines plus tard, lors de la soirée À la French.
Cédric Ravalec, directeur opérationnel chez Open Source Experts, était également présent.

Bref, pour moi, il y avait là du lourd !

Au regard de mon expérience personnelle autour de la souveraineté numérique et de l’open source, il était assez évident que je ne faisais pas le poids face à leur expérience professionnelle. Mais là n’était finalement pas la question. Florian et Cédric faisaient preuve d’une réelle disponibilité et d’une grande générosité dans notre échange. Ils partageaient leurs connaissances, répondaient à mes questions et acceptaient volontiers de discuter avec quelqu’un qui, comme moi, n’est pas du tout un professionnel de l’informatique et encore moins du sérail.

Au fil de la conversation, nous sommes arrivés à une conclusion qui peut sembler évidente, mais qui mérite pourtant d’être rappelée : lorsqu’on parle de souveraineté numérique et d’open source, il faut se garder de tomber dans l’idéologie ou dans l’illusion d’un monde parfait, entièrement gratuit et dépourvu de zones d’ombre.

L’open source apporte des libertés essentielles. Mais il ne fait pas disparaître pour autant les intérêts économiques, les rapports de force, les contraintes techniques ni les risques de dépendance.

Florian et Cédric m’ont alors mis la puce à l’oreille sur un sujet que je connaissais peu, voire pas du tout : la situation dans laquelle une organisation choisit une distribution Linux, puis découvre que les conditions de support rendent très difficile sa sortie de cet environnement.

À vrai dire, je ne savais même pas que le sujet existait sous cette forme.

Dans mon esprit, une distribution Linux et, plus largement, une solution open source étaient précisément censées permettre d’échapper à l’enfermement que l’on reproche régulièrement aux logiciels propriétaires. Puisque le code est ouvert, il devrait être possible de changer de prestataire, de reprendre la solution, de la faire évoluer ou de migrer vers une autre. En théorie, oui.

Mais ils m’ont fait prendre conscience qu’entre la liberté prévue par la licence et celle réellement exercée par une organisation, il peut exister un écart considérable.

Lorsqu’une entreprise décide de s’appuyer sur l’open source pour administrer une partie importante de son infrastructure, et qu’elle souhaite réellement renforcer sa souveraineté sans reproduire les erreurs commises avec certaines solutions propriétaires, elle doit regarder de fond en comble ce que ce choix implique.

Elle doit notamment étudier les frais de migration d’un système vers un autre ; dans ce cas, le passage d’un système propriétaire à un système dit ouvert, mais aussi les conditions du support technique.

Elle doit également vérifier si son organisation lui permet de recourir à ce que les professionnels appellent le dual sourcing, ou « double approvisionnement » en français.
Cette stratégie, issue à l’origine de la gestion des chaînes d’approvisionnement, consiste à pouvoir s’appuyer sur deux fournisseurs différents pour un même composant, un même matériau ou un même service. Appliquée à l’informatique, elle permet d’éviter qu’un fournisseur devienne le seul acteur capable de maintenir, de faire évoluer ou de supporter une solution pourtant ouverte.

Il faut aussi prendre en considération le footprint, c’est-à-dire l’empreinte globale prise par un éditeur au sein d’une organisation. Cette empreinte peut être mesurée par le nombre de produits utilisés, de serveurs concernés, de projets déployés, d’utilisateurs, de souscriptions ou d’abonnements.

Plus cette empreinte grandit, plus le changement peut devenir complexe, coûteux et risqué.

Et puis il y a l’interopérabilité, c’est-à-dire la capacité de différents logiciels, services et systèmes à fonctionner ensemble sans dépendre d’un environnement unique.

Nous avons donc échangé autour de ces différents sujets. C’est à ce moment-là qu’est apparue, au cours de la discussion, la comparaison entre les écosystèmes de Red Hat et de SUSE. Non pas pour débattre des différences techniques entre les deux distributions ou pour déterminer laquelle serait la meilleure, mais pour nous intéresser à leurs modèles d’accompagnement et de support, notamment autour d’OpenShift chez Red Hat et de Rancher Prime chez SUSE.

L’idée n’était absolument pas d’affirmer que l’un serait meilleur que l’autre.

Ce n’est pas l’objet de cette réflexion.

L’enjeu était plutôt de comprendre comment deux acteurs de l’open source pouvaient proposer des approches différentes et, surtout, comment le support, les certifications, les compétences disponibles, les outils complémentaires et l’ensemble des services qui entourent une technologie pouvaient influencer la capacité d’une organisation à changer de fournisseur.

Car même lorsqu’un projet repose sur des logiciels open source, il est possible de retomber dans une forme de dépendance.

Dans ce cas, la dépendance n’est pas juridique. Personne ne vous interdit formellement de partir et la licence du logiciel peut parfaitement vous en donner le droit. Elle peut en revanche devenir opérationnelle : la sortie reste théoriquement possible, mais elle devient tellement difficile, coûteuse ou risquée que l’organisation ne peut plus raisonnablement l’envisager.

L’idée a commencé à germer à la suite de cette conversation. Elle a continué à mûrir au fil des semaines. Puis, dans le rapport de la commission d’enquête parlementaire sur nos vulnérabilités et nos dépendances numériques, un chiffre m’a particulièrement interpellé : celui des dépenses publiques consacrées aux logiciels :

Près de 30 millions d’euros de dépenses étaient associés à IBM et à Red Hat et sans oublier que Red Hat est passé sous le contrôle d’IBM en 2019.

Sur les 268 millions d’euros de dépenses bénéficiant à des acteurs extra-européens, IBM et Red Hat représentaient ainsi un peu plus de 11 %.

Autrement dit, un peu plus d’un euro sur dix dépensé auprès d’acteurs extra-européens revenait à ces deux entreprises de l’IT.

Ce chiffre ne permet évidemment pas, à lui seul, de conclure que ces dépenses seraient injustifiées, ni que Red Hat constituerait nécessairement un mauvais choix. Mais il permet de mesurer l’importance qu’un acteur issu de l’open source peut prendre au sein des systèmes informatiques publics.

Il rappelle également une réalité que l’on oublie parfois : choisir une technologie ouverte ne signifie pas choisir une technologie sans éditeur, sans modèle économique, sans prestations de support ou sans risque de concentration.

J’ai donc eu le privilège de pouvoir retrouver Florian et Cédric lors d’un entretien en visioconférence afin de comprendre et d’en apprendre beaucoup plus.

Contexte

La question était de savoir comment une organisation pouvait adopter l’open source sans recréer les dépendances dont elle cherchait précisément à se libérer, comment distinguer un support indispensable d’un support qui finit par devenir un verrou et, surtout, quelles interrogations une entreprise ou une administration devrait se poser avant de faire un choix qui l’engagera parfois pour de nombreuses années.

Car adopter de l’open source ne suffit pas toujours à garantir sa liberté.

Encore faut-il savoir comment la préserver.

Florian Caringi, de la data à la gouvernance de l’open source

Pour comprendre le regard que Florian Caringi porte sur l’open source, il faut d’abord s’intéresser à son parcours. Ingénieur diplômé de Télécom Bretagne, devenue IMT Atlantique (après sa fusion avec l’École nationale supérieure des mines de Nantes et de Télécom Bretagne), il a commencé sa carrière dans l’univers de la banque et de la finance. Il a notamment occupé plusieurs fonctions au sein de la banque de financement et d’investissement de Natixis, où il travaillait déjà sur les données et leurs usages.
Dès 2019, il était ainsi présenté comme leader Big Data de Natixis lors d’une intervention consacrée à l’utilisation de la science des données dans les activités bancaires.

Son parcours l’a ensuite conduit à prendre la responsabilité d’une équipe composée d’ingénieurs et d’architectes de données au sein de l’entité transverse Tech Expertise & Solutions du groupe BPCE. Sa mission ne consiste pas seulement à déployer des technologies : elle vise aussi à accélérer les projets liés aux données, à construire et faire évoluer les plateformes du groupe, puis à accompagner leur utilisation dans une organisation particulièrement vaste et décentralisée. Il occupe aujourd’hui la fonction de directeur adjoint chargé des données et de l’open source au sein du groupe BPCE.

Cette double responsabilité est importante. Florian Caringi ne regarde pas l’open source uniquement comme un ensemble de logiciels ou de licences. Il l’aborde depuis le terrain, au sein d’un grand groupe bancaire où les choix techniques doivent répondre à des exigences élevées de sécurité, de continuité, d’industrialisation et de maîtrise des risques. Son expertise se situe précisément à la rencontre de plusieurs mondes : l’architecture des données, l’intelligence artificielle, les infrastructures informatiques et la gouvernance de l’open source. Ses interventions publiques portent d’ailleurs régulièrement sur la manière d’arbitrer entre solutions ouvertes, services en ligne et modèles propriétaires.

Mais son engagement dépasse le cadre de BPCE. Florian Caringi est vice-président du TOSIT : The Open Source I Trust, une association qui réunit de grandes entreprises et des administrations souhaitant mutualiser leurs expériences, leurs besoins et certains développements open source. Il y représente notamment le groupe BPCE et participe à des travaux portant sur les plateformes de données, l’intelligence artificielle, les standards ouverts et la maîtrise des dépendances technologiques.

Florian a également mis son expérience au service du Comité d’organisation des Jeux olympiques et paralympiques de Paris. De mars à septembre 2024, il a occupé la fonction de responsable adjoint des infrastructures technologiques des cérémonies d’ouverture. Il a participé à la coordination et au pilotage des infrastructures technologiques et de télécommunications nécessaires à la cérémonie olympique organisée sur la Seine, puis à la cérémonie paralympique organisée place de la Concorde. Une mission particulièrement exigeante, au croisement de la technologie, de la coordination opérationnelle et de la gestion d’un événement suivi dans le monde entier.

En mars 2026, il a également été élu président d’OW2, communauté internationale consacrée au développement et à la promotion de logiciels open source, dont le siège est en France. Cette responsabilité le place au contact d’un écosystème beaucoup plus large, composé de développeurs, d’entreprises, d’administrations, d’établissements de recherche, d’associations et d’éditeurs. Elle témoigne aussi d’un engagement qui ne se limite pas à utiliser l’open source : il s’agit de contribuer à organiser, à faire vivre et à renforcer les communautés qui le rendent possible.

Son parcours comporte enfin une dimension de transmission. En parallèle de ses responsabilités professionnelles et associatives, Florian Caringi enseigne à l’ESCP et à l’ESG. Depuis 2021, il met également bénévolement ses compétences au service du Paris FC, en contribuant notamment à l’architecture applicative et aux sujets liés aux données du club. Ces engagements sont cohérents avec une conviction qu’il exprime régulièrement : les compétences, les expériences et les technologies prennent davantage de valeur lorsqu’elles sont partagées.

C’est sans doute ce qui caractérise le mieux son profil : Florian Caringi n’est pas seulement un spécialiste de la donnée devenu responsable de l’open source dans un grand groupe.
C’est un praticien qui cherche à relier les contraintes très concrètes de l’entreprise aux principes de coopération, d’ouverture et de mutualisation portés par les communautés du logiciel libre.

Et c’est précisément parce qu’il connaît à la fois les promesses de l’open source et les conditions réelles de son déploiement qu’il peut en parler sans naïveté. Son discours n’est ni celui d’un opposant aux éditeurs ni celui d’un défenseur d’un monde où tout devrait être gratuit. Il nous invite plutôt à regarder ce qui se joue autour du code : le support, les compétences, la gouvernance, le modèle économique et, surtout, la capacité à conserver la maîtrise de ses choix.

Préparer la sortie avant même d’entrer

Lors de notre entretien, Florian a beaucoup insisté sur un point qui traverse l’ensemble de son raisonnement : le caractère open source d’une technologie ne suffit pas, à lui seul, à garantir la liberté d’une organisation.

Pour conserver la maîtrise de son système d’information, la direction doit penser bien au-delà de la licence. Elle doit regarder la manière dont la solution est assemblée, déployée, maintenue et intégrée au reste de son infrastructure. Elle doit surtout se demander, dès le début du projet, dans quelles conditions elle pourra un jour la faire évoluer, changer de prestataire ou la remplacer.

Le principe de l’appliance

Florian accorde notamment beaucoup d’importance au principe de l’appliance. Dans le vocabulaire informatique, cela désigne une solution conçue et préparée pour remplir une fonction précise. Elle peut prendre la forme d’un équipement réunissant le matériel et les logiciels nécessaires, mais aussi celle d’une machine virtuelle préconfigurée comprenant le système d’exploitation, les composants techniques et l’application. L’ensemble est fourni comme un produit cohérent, prêt à être déployé et, généralement, pris en charge par un même support. IBM définit ainsi une appliance comme une offre unique associant des composants matériels et logiciels pour assurer une fonction déterminée ; une virtual appliance rassemble, quant à elle, le système d’exploitation, les logiciels intermédiaires et les applications au sein d’un même ensemble préconfiguré.

L’intérêt est notamment de réduire la complexité du déploiement et de clarifier la responsabilité du support. Lorsqu’un logiciel, son système d’exploitation et son matériel proviennent de fournisseurs différents, chacun peut être tenté, lorsqu’un problème survient, d’en attribuer la responsabilité à l’autre. Avec une appliance, l’organisation dispose en principe d’un interlocuteur capable de prendre en charge l’ensemble de la solution. C’est précisément l’un des avantages mis en avant dans la discussion du site Developpez.net que Florian m’avait indiquée.

Cette « simplicité » ne doit cependant pas être confondue avec l’indépendance. Une solution parfaitement intégrée peut être très facile à installer et à maintenir, tout en devenant difficile à remplacer. L’appliance doit donc être étudiée avec les mêmes précautions que le reste de l’infrastructure :

• Les interfaces sont-elles documentées ?
• Les données peuvent-elles être récupérées facilement ?
• Peut-elle fonctionner sur plusieurs environnements ?
• Un autre prestataire peut-il en assurer le support ?
• Les composants qui la constituent reposent-ils sur des standards ouverts ?

Les standards ouverts comme condition de la mobilité

La mise en place de standards ouverts par les DSI est justement une condition essentielle pour faciliter les futures stratégies de migration et renforcer l’interopérabilité.

Un standard ouvert permet à plusieurs logiciels, plateformes ou fournisseurs de s’appuyer sur des règles communes, publiquement documentées et utilisables par différents acteurs. L’organisation ne construit alors plus son système d’information autour des seuls choix techniques d’un éditeur. Elle conserve davantage de possibilités pour faire communiquer plusieurs solutions, remplacer un composant ou transférer ses données.

Cela ne signifie pas qu’une migration devient simple ou gratuite. Mais plus les formats, les interfaces et les protocoles sont ouverts et partagés, moins l’organisation dépend d’un savoir-faire détenu par un seul fournisseur.

L’interopérabilité ne doit donc pas être considérée comme une étape abstraite que l’on ajouterait à la fin d’un projet. Elle doit être pensée dès la conception de l’architecture. Une DSI qui impose des standards ouverts prépare en réalité ses possibilités futures : elle se donne davantage de latitude pour intégrer de nouvelles solutions, faire travailler plusieurs prestataires et éviter qu’un composant ou un logiciel ne devienne indissociable du reste du système d’information.

Surveiller le footprint

Florian est également revenu à plusieurs reprises sur le footprint, c’est-à-dire l’empreinte qu’un éditeur, une technologie ou un écosystème prend progressivement dans une organisation.

Cette empreinte ne se limite pas au nombre de licences achetées. Elle peut correspondre au nombre de serveurs concernés, de produits utilisés, de projets déployés, de souscriptions, d’utilisateurs dépendants de la solution ou encore d’applications développées autour de ses technologies.

Pris séparément, chacun de ces choix peut sembler raisonnable. Mais leur accumulation peut progressivement donner à un fournisseur une place centrale dans le système d’information.

Une première solution est installée pour répondre à un besoin précis. Puis viennent les outils de supervision, les bases de données, les mécanismes de sécurité, les services cloud, les formations, les certifications et les applications développées en interne. Au fil du temps, les équipes acquièrent des compétences très spécialisées dans cet environnement et les processus de l’organisation commencent eux aussi à en dépendre.

Le footprint permet donc de regarder la dépendance dans son ensemble. Il ne s’agit plus seulement de savoir si un logiciel peut être remplacé, mais de mesurer tout ce qui s’est progressivement construit autour de lui.

Cette empreinte doit être suivie par les DSI comme un véritable indicateur stratégique.
Plus elle s’étend, plus il devient nécessaire de vérifier que l’organisation conserve des solutions de remplacement et une capacité réelle de négociation.

Ne pas dépendre d’un seul fournisseur grâce au dual sourcing

Le second principe sur lequel Florian a beaucoup insisté est celui du dual sourcing, ou double approvisionnement en français.

Dans le domaine informatique, cette stratégie consiste à ne pas confier un composant, une technologie ou un service critique à un fournisseur unique. L’organisation cherche à maintenir au moins deux sources possibles de compétences, de prestations ou de support.

Dans un environnement open source, cette possibilité devrait théoriquement constituer l’un des grands avantages du modèle. Le code étant accessible, plusieurs entreprises peuvent intervenir sur une même technologie. Une organisation peut donc choisir un éditeur, un intégrateur ou une société de support sans abandonner définitivement la possibilité d’en solliciter un autre.

Mais cette liberté théorique doit être organisée concrètement.

Si toutes les compétences internes ont été formées aux outils spécifiques d’un seul fournisseur, si les procédures dépendent de ses propres interfaces et si les contrats ont été construits de manière à lui réserver l’essentiel du support, l’existence du code source ne suffira pas à rendre le changement facile.

Le dual sourcing consiste donc à entretenir volontairement plusieurs options. Il peut s’agir de travailler avec deux prestataires, de préserver des compétences en interne, de vérifier qu’un second acteur serait capable de reprendre le support ou encore d’éviter que les développements réalisés autour de la solution ne reposent exclusivement sur des extensions propres au fournisseur principal.

L’objectif n’est pas nécessairement de diviser chaque contrat entre deux entreprises ni de mettre constamment les fournisseurs en concurrence. Il s’agit de s’assurer qu’une alternative crédible existe et qu’elle pourra réellement être mobilisée en cas de besoin.

Pour Florian, les concepts de footprint et de dual sourcing sont ainsi étroitement liés : Le premier permet de mesurer l’ampleur prise par un acteur dans l’organisation. Le second préserve la possibilité du choix lorsque cette empreinte devient (trop) importante.

Ces deux notions conduisent directement à celles sur lesquelles il a également beaucoup insisté : le lock-in et le coût de sortie.

Le lock-in (ou vendor lock-in : verrouillage fournisseur)

Le lock-in désigne une situation dans laquelle une organisation devient tellement dépendante d’un logiciel, d’un éditeur ou d’un fournisseur cloud, qu’il devient difficile de le remplacer.

Cette dépendance peut venir de :

• formats de données propriétaires ;
• applications conçues autour de technologies spécifiques ;
• interfaces incompatibles avec les solutions concurrentes ;
• compétences internes concentrées sur un seul environnement ;
• contrats ou licences complexes ;
• nombreuses intégrations avec le reste du système d’information.

Le client n’est pas juridiquement obligé de rester. Il peut théoriquement partir, mais le changement devient trop difficile, trop risqué ou trop coûteux.

Le coût de sortie

Il représente tout ce qu’une organisation doit supporter pour quitter une solution ou un fournisseur. Il ne s’agit pas seulement du prix d’un nouveau logiciel.

Il faut prendre également en considération :

• la récupération et la migration des données ;
• la reconstruction des applications et des interfaces ;
• la formation des équipes ;
• le recours possible à des consultants ou intégrateurs ;
• les interruptions de service ;
• les pénalités contractuelles (dans certains cas) ;
• les risques de perte de données ou de fonctionnalités ;
• le temps consacré au projet de migration.

Ce coût peut donc être financier, technique, humain, contractuel et opérationnel.

La différence entre les deux notions

Le lock-in est la situation de dépendance.
Le coût de sortie mesure la difficulté réelle pour en sortir.

Plus le coût de sortie est élevé, plus le verrouillage est fort.

Une solution peut ainsi être peu coûteuse au départ, mais devenir très chère à abandonner après plusieurs années, lorsque les données, les applications, les compétences et les processus de l’organisation se sont construits autour d’elle.

Exemple concret

Une entreprise utilise pendant dix ans les services cloud propriétaires d’un fournisseur.
Ses applications dépendent de ses bases de données, de ses outils de sécurité, de ses mécanismes d’intelligence artificielle et de ses interfaces techniques.

Changer de fournisseur suppose alors de :

• transférer plusieurs pétaoctets de données ;
• réécrire une partie des applications ;
• remplacer les outils propriétaires ;
• former les équipes ;
• maintenir temporairement les deux environnements.

L’entreprise reste donc chez son fournisseur, non parce qu’elle en est totalement satisfaite, mais parce que le prix et le risque du départ sont devenus supérieurs aux inconvénients de rester.

Le véritable pouvoir d’un fournisseur ne tient pas seulement à la qualité de ses produits, mais au coût qu’il impose pour les quitter. Plus les données, les applications et les compétences d’une organisation dépendent de son environnement, plus le coût de sortie augmente et plus le verrouillage se renforce.

Il est également possible dans cette situation, de parler de réversibilité : une solution réellement réversible permet de récupérer ses données, de transférer ses applications et de changer de fournisseur dans des conditions maîtrisées. Le coût de sortie constitue donc, pour une DSI, un indicateur concret du niveau de dépendance numérique.

Le regard de Florian conduit finalement à renverser la manière dont une organisation évalue ses choix informatiques. Il ne suffit pas de se demander combien coûtera l’entrée dans une solution, quelles fonctions elle propose ou avec quelle rapidité elle pourra être déployée.

Il faut aussi se demander combien coûtera sa sortie.

Une architecture réellement maîtrisée n’est pas celle que l’on ne quittera jamais. C’est celle que l’on pourra quitter sans mettre en péril l’activité de l’organisation.

Dans cette perspective, l’open source n’est pas une garantie automatique contre l’enfermement. Il constitue plutôt un ensemble de libertés qu’il faut rendre opérationnelles grâce aux standards ouverts, à l’interopérabilité, à la maîtrise du footprint, au dual sourcing et à une véritable stratégie de réversibilité.

La liberté ne dépend donc pas seulement de l’accès au code source. Elle dépend de la capacité réelle à exercer le choix que cet accès est censé permettre.

Cédric Ravalec, vingt-cinq ans au cœur de l’open source

Le parcours de Cédric Ravalec se confond en grande partie avec l’histoire de l’open source professionnel en France. Il travaille dans cet univers depuis plus de vingt-cinq ans, près avoir commencé sa carrière au moment où l’open source professionnel se développait avec l’essor d’Internet. En effet, la grande majorité des infrastructures d’Internet sont basées sur l’open source, qui s’est progressivement installé dans les organisations à mesure que le web s’étendait.

Ses premiers pas professionnels se font chez Alcôve, l’une des toutes premières SSII (ou ESN : Entreprises de Services du Numérique) spécialisées dans les logiciels libres.
Il occupe ensuite différentes responsabilités commerciales et managériales chez OpenTrust (rachetée par Atos en 2019) et Linagora.

Cette trajectoire lui a permis d’observer l’évolution de l’open source depuis une période où son adoption dans les entreprises restait encore marginale, parfois même dissimulée dans les infrastructures, jusqu’à son rôle désormais central dans le cloud, les systèmes embarqués, les applications mobiles et les systèmes d’information des grandes organisations.

En 2011, après une douzaine d’années passées dans le conseil et les services informatiques open source, Cédric Ravalec reconnaît dans Android le même phénomène d’émergence technologique majeure qu’il avait observé avec l’arrivée de Linux à l’époque d’Internet.
C’est lors d’une réunion du Paris Android User Group qu’il se convainc du potentiel du système d’exploitation mobile. Il s’y implique ensuite très fortement.

Cette même année, il décide de se lancer dans l’aventure entrepreneuriale et cofonde Genymobile, une des premières sociétés de services dédiée à Android. Cédric aura vu juste, car Android équipe aujourd’hui plus de 4 milliards de smartphones dans le monde.
En 2013, il reçoit le prix de l’innovation d’avenir lors des Prix EY de l’Entrepreneur.
Son entreprise sera rachetée par Shadow en 2023.

Son intérêt pour les systèmes mobiles ouverts se poursuit notamment autour de Firefox OS. Cédric y voit un enjeu commercial majeur : rendre accessible le smartphone à des milliards d’individus dans les pays en voie de développement, en permettant le passage du téléphone à touches vers le smartphone. Cofondateur, avec Loïc Cuguen, de Phoxygen, il participe activement à l’animation de la communauté française de Firefox OS, en organisant des rencontres régulières consacrées au système d’exploitation mobile de Mozilla. Leur engagement est publiquement salué par Mozilla en 2015.

Il développe ensuite une expertise particulière dans les domaines des systèmes embarqués, de l’Internet des objets et des infrastructures ouvertes. Chez Smile, il occupe notamment des responsabilités autour de l’offre « Embarqué et IoT », puis du Cloud. Cédric contribue également au livre blanc Android pour l’embarqué, principalement rédigé par Pierre Ficheux, alors directeur technique de Smile-ECS. Il en signe le dernier chapitre, consacré aux marchés actuels et futurs d’Android dans l’industrie et l’Internet des objets.

Son expertise ne s’arrête pas là. Elle porte aussi sur une question décisive pour les entreprises et les administrations : comment rendre ces technologies réellement exploitables, faciles à maintenir et correctement supportées dans la durée ?
Dans le monde propriétaire, l’éditeur reste généralement l’interlocuteur naturel en cas de problème. Avec l’open source, le paysage est plus éclaté : une communauté, plusieurs sociétés de services, des contributeurs indépendants ou différents intégrateurs peuvent intervenir autour d’un même projet. Cette diversité élargit les possibilités, mais elle oblige aussi à identifier les bons partenaires et à organiser le support pour éviter que la liberté de choisir ne se transforme en incertitude.

En cette même année, Cédric prend la direction d’Open Source Experts : une structure cofondée par cinq acteurs de référence dans l’open source : FactorFX, Worteks, Arawa, Bluemind et Inno3 et créée dans le but de fédérer cet écosystème français, d’aider les entreprises à trouver les compétences nécessaires pour maintenir leurs solutions ouvertes et d’organiser un support technique adapté à cet environnement fragmenté.

La liberté de choisir existe, mais encore faut-il savoir vers qui se tourner et comment garantir la continuité du support.

Cédric participe régulièrement aux événements de l’écosystème open source français.
Son expertise est également reconnue par l’écosystème professionnel : en 2023, il participe à la direction du programme d’Open Source Experience en tant que vice-président de la thématique consacrée aux systèmes embarqués, à l’IoT, à l’Open Hardware et à l’industrie.

Le recul de l’expérience, sans perdre la passion

Son parcours dessine ainsi un profil à la croisée de plusieurs mondes : les technologies ouvertes, le développement commercial, l’accompagnement des organisations, le support professionnel et l’animation des communautés. Il connaît l’open source non seulement comme utilisateur ou observateur, mais comme une activité économique qu’il faut structurer pour qu’elle puisse répondre aux exigences des entreprises et des administrations.

Cette expérience lui permet de distinguer ce que l’open source promet de ce qu’il exige réellement sur le terrain. Après avoir accompagné l’évolution pendant plus de vingt-cinq ans, il en connaît les possibilités, mais aussi les fragilités : la dispersion des compétences, le manque de support sur certains projets, la difficulté à identifier les bons interlocuteurs et le risque de voir une technologie ouverte devenir malgré tout une nouvelle source de dépendance.

Entre la publication d’un code source et son utilisation durable dans une organisation, il existe tout un écosystème à construire : des compétences, des entreprises, des communautés, des contrats, du support et une véritable stratégie industrielle.

Le regard de Cédric sur ces questions est donc celui d’un professionnel qui a traversé plusieurs périodes de l’open source. Cette ancienneté ne fait pas de lui un observateur tourné vers le passé. Elle lui donne surtout du recul.

Il rejoint Florian Caringi sur de nombreux sujets : l’importance du coût de sortie, la nécessité de surveiller l’empreinte prise par un fournisseur, le besoin d’interopérabilité et l’intérêt de ne pas dépendre d’un seul prestataire.

Mais Cédric élargit également le paysage.

Canonical, une troisième voie

Lorsque nous parlons des solutions d’entreprise construites autour de Linux et de Kubernetes, deux noms reviennent rapidement : Red Hat et SUSE.

Pour Cédric, il ne faut cependant pas oublier une troisième voie : celle de Canonical, l’entreprise qui développe Ubuntu et commercialise notamment Ubuntu Pro ainsi que différentes prestations de support autour d’Ubuntu, de Kubernetes, d’OpenStack, de Ceph et d’autres composants open source.

Une précision est toutefois nécessaire : OpenShift, Rancher Prime et les offres de Canonical ne sont pas trois produits parfaitement équivalents.

OpenShift est une plateforme applicative d’entreprise construite autour de Kubernetes.

Rancher Prime est principalement une plateforme permettant de déployer et de gérer des environnements Kubernetes, y compris différentes distributions certifiées.

Canonical propose de son côté un ensemble de souscriptions, de technologies et de services autour d’Ubuntu et d’une infrastructure ouverte plus large.

La comparaison porte donc moins sur des fonctions strictement identiques que sur la manière dont ces entreprises transforment des technologies ouvertes en offres professionnelles accompagnées, maintenues et supportées.

La véritable question n’est donc pas de déterminer quel produit est le meilleur, mais de comprendre comment chaque éditeur relie les différentes briques de son offre : le système d’exploitation, les logiciels intermédiaires qui font fonctionner les applications et la plateforme proposée au client. Plus ces éléments sont étroitement liés, plus il peut devenir difficile d’en remplacer un sans remettre en cause l’ensemble.

Le couplage, critère décisif

Dans ce contexte, le couplage désigne le degré de dépendance entre les différentes briques d’une offre informatique : le système d’exploitation, les logiciels intermédiaires et la plateforme.

Plus le couplage est fort, plus ces éléments sont conçus pour fonctionner ensemble et plus il devient difficile d’en remplacer un sans modifier tout le reste ou rester dépendant du même éditeur.

C’est sur ce critère que les trois modèles se différencient réellement.

• Chez Red Hat, les différents logiciels sont conçus pour fonctionner ensemble et sont commercialisés sous la forme d’une offre complète. OpenShift s’appuie généralement sur l’environnement Red Hat : le système d’exploitation, la plateforme qui fait fonctionner les applications, les outils d’administration et les logiciels certifiés sont étroitement liés.
  C’est l’une des grandes forces du modèle : tout est pensé pour être cohérent et bien intégré.
  Mais c’est aussi ce qui peut rendre un changement de fournisseur difficile et coûteux. Il ne suffit pas toujours de remplacer un seul logiciel : il faut parfois revoir une grande partie de l’ensemble.
  

• SUSE défend une approche différente. Avec Rancher Prime, l’entreprise met en avant la possibilité de gérer des environnements Kubernetes très variés, y compris lorsqu’ils ne fonctionnent pas avec les systèmes de SUSE. L’outil de gestion peut donc être séparé du système d’exploitation utilisé en dessous.
  Cette indépendance fait partie des principaux arguments de SUSE.
  

• Canonical suit une troisième voie. Elle ne structure pas son offre autour d’une plateforme applicative unique directement équivalente à OpenShift. Elle propose plutôt plusieurs briques et plateformes d’infrastructure qui peuvent être adoptées séparément ou assemblées dans une architecture intégrée : Ubuntu pour le système d’exploitation, Kubernetes pour les applications, OpenStack pour le cloud et Ceph pour le stockage.

Ces différentes solutions peuvent être utilisées séparément. Une entreprise peut choisir Ubuntu sans acheter d’autres services auprès de Canonical. Elle peut aussi utiliser Ceph sans adopter le reste de son catalogue. Les différentes couches sont donc relativement indépendantes les unes des autres.

Que se passe-t-il lorsque l’on arrête de payer ?

Cette différence est importante lorsqu’une direction informatique cherche à savoir si elle pourra facilement changer de fournisseur.
La question essentielle à prendre en compte : que se passe-t-il lorsque l’entreprise arrête de payer son abonnement ?

Avec Red Hat Enterprise Linux, l’accès aux mises à jour et aux correctifs de sécurité dépend de la souscription. Sans contrat actif, le système ne s’arrête pas de fonctionner. En revanche, il ne reçoit plus les mises à jour nécessaires à sa maintenance et à sa sécurité.

Autrement dit, pour continuer à bénéficier d’un système correctement sécurisé, il faut conserver un abonnement.

Avec Ubuntu, le fonctionnement est différent. Les versions dites LTS (versions maintenues à long terme) bénéficient gratuitement de cinq années de mises à jour de sécurité, y compris lorsqu’elles sont utilisées en entreprise.

L’abonnement Ubuntu Pro permet d’obtenir une protection sur un plus grand nombre de logiciels et de prolonger la durée de maintenance. Mais il vient compléter un système qui reste déjà utilisable et maintenu gratuitement.

Dans un cas, le contrat est indispensable pour continuer à recevoir les mises à jour de sécurité. Dans l’autre, il permet surtout d’obtenir davantage de services et une protection plus longue. La difficulté et le coût d’une sortie ne sont donc pas comparables.

Canonical ne peut donc pas être présenté comme un simple modèle intermédiaire entre Red Hat et SUSE. Par la manière dont ses solutions peuvent être utilisées séparément et par les conditions prévues en cas d’arrêt de l’abonnement, son modèle est sensiblement plus ouvert que celui de Red Hat.

Canonical n’est pas pour autant totalement indépendant

Cela ne signifie pas que Canonical échappe à toute forme de dépendance. Canonical conserve une influence déterminante sur les orientations, les versions, l’infrastructure et le financement d’Ubuntu, même si le projet comprend également des instances de gouvernance communautaires.

Certains de ses choix ont d’ailleurs suscité des critiques dans la communauté. C’est notamment le cas du Snap Store, la plateforme de distribution de logiciels Snap, dont l’infrastructure reste largement contrôlée par Canonical.

L’objectif n’est donc pas de désigner un bon et un mauvais modèle. Il s’agit plutôt de comprendre que Red Hat, SUSE et Canonical organisent différemment les relations entre leurs logiciels, leur support, leurs partenaires et leurs clients.

Or, dans la pratique, cette organisation compte souvent davantage que la licence elle-même. C’est elle qui détermine la liberté réelle d’une entreprise, sa capacité à changer de fournisseur et le coût d’un éventuel départ.

Le cas particulier de Debian

La situation est encore différente avec Debian.

Debian n’est pas le produit d’une entreprise chargée de développer la distribution puis de vendre directement son support. Il s’agit d’un projet communautaire mondial, organisé autour de contributeurs, de développeurs et d’associations.

Il n’existe donc pas, pour Debian, d’offre commerciale centralisée exactement comparable à Red Hat Enterprise Linux, Ubuntu Pro ou aux souscriptions proposées par SUSE.

Si l’on observe la manière dont le système d’exploitation, les logiciels intermédiaires et la plateforme sont liés, Debian constitue un cas à part. La distribution n’appartient à aucun éditeur et aucune entreprise ne dispose d’une offre commerciale officielle ou exclusive contrôlant l’ensemble du projet. Il est donc beaucoup plus difficile de se retrouver enfermé dans l’écosystème d’un fournisseur précis. Avec Debian, la question n’est pas tant de savoir comment en sortir, mais plutôt de choisir soi-même les prestataires et les outils qui l’accompagnent.

Cela ne signifie pas qu’une entreprise utilisant Debian serait privée de support professionnel. Le projet publie d’ailleurs une liste de consultants, d’organisations et de sociétés proposant des prestations payantes autour de la distribution. Mais l’utilisateur ne trouve pas, derrière Debian, un éditeur unique qui engagerait directement sa responsabilité sur l’ensemble de la solution.

Cédric cite notamment Freexian, une société de services spécialisée dans les logiciels libres et fortement engagée dans l’écosystème Debian.

Freexian coordonne et finance une partie du support à long terme de Debian. Elle propose également un programme commercial de support étendu, ou Extended Long Term Support (ELTS), qui permet de maintenir certaines versions bien au-delà de leur cycle normal. Ce programme joue un rôle important, notamment pour les organisations qui ne peuvent pas migrer rapidement leurs systèmes. Mais Debian précise elle-même que l’ELTS constitue une offre commerciale et non un projet officiel de Debian.

La différence de modèle est fondamentale.

Avec Red Hat, SUSE ou Canonical, l’entreprise qui pilote la distribution propose également une offre commerciale structurée autour de celle-ci. Avec Debian, le projet reste indépendant des sociétés qui proposent du support. Une entreprise comme Freexian intervient autour de Debian, contribue à son maintien et organise des services professionnels, mais elle ne possède pas la distribution et ne parle pas au nom de l’ensemble du projet.

Cette absence d’éditeur central peut représenter une liberté supplémentaire. Elle évite qu’un seul acteur concentre tout le pouvoir économique et technique.

Ce modèle présente un intérêt particulier lorsqu’il est question de souveraineté numérique. Debian est développée et dirigée par une communauté internationale indépendante. Une entreprise ou une administration peut ensuite choisir une société française ou européenne pour l’accompagner et assurer le support, sans que cette société contrôle Debian ni que Debian dépende d’elle.

Mais elle peut aussi rendre la situation plus difficile à appréhender pour une grande organisation. Une DSI doit alors identifier elle-même les bons prestataires, construire son dispositif de support et déterminer qui sera responsable lorsqu’un incident critique surviendra.

Cette liberté a toutefois une contrepartie : Debian demande davantage d’autonomie. L’entreprise ou l’administration doit conserver les compétences nécessaires, suivre les évolutions techniques et organiser elle-même le support. Autrement dit, ce qui n’est pas fourni sous la forme d’une offre prête à l’emploi par un éditeur doit être construit en interne ou assemblé avec l’aide de différents prestataires.

L’angle mort : la certification

L’absence d’un interlocuteur unique chez Debian a une conséquence souvent sous-estimée : elle rend plus difficile la certification du matériel et des logiciels professionnels.

Lorsqu’un fabricant de serveurs, un éditeur de logiciels ou un fournisseur de bases de données veut certifier son produit pour une distribution Linux, il doit pouvoir s’entendre avec une entreprise clairement identifiée. Les deux parties fixent alors les versions prises en charge, les règles de compatibilité, la durée du support et les responsabilités de chacun en cas de problème. Red Hat, SUSE et Canonical peuvent conclure ce type d’accord. Debian, qui est portée par une communauté et non par une entreprise, ne dispose pas du même interlocuteur commercial.

C’est pourquoi Debian apparaît moins souvent dans les listes officielles de compatibilité publiées par les grands fabricants et éditeurs, même lorsque sa base technique est proche de celle d’autres distributions. Cela ne signifie pas qu’elle est moins fiable. Cela signifie surtout que très peu d’entreprises s’engagent contractuellement au nom du projet Debian.

Pour une direction informatique, cette différence peut avoir des conséquences très concrètes : un serveur peut fonctionner sans être officiellement pris en charge, un logiciel métier peut être installé en dehors des configurations certifiées et, en cas de panne, le fournisseur peut refuser d’assumer la responsabilité.

Nous retrouvons ici toute l’ambivalence de l’open source : la décentralisation réduit le risque de dépendre d’un acteur unique, mais elle peut également compliquer la construction d’une offre industrielle lisible.

Ce que Red Hat avait compris avant les autres

Cédric rappelle également que Red Hat disposait, dès le départ, d’un avantage qui n’était pas seulement technique.

L’entreprise avait compris très tôt que, pour entrer durablement dans les grandes organisations, il ne suffisait pas de proposer une bonne distribution Linux. Il fallait construire autour d’elle tout ce qu’attendent les entreprises : des cycles de maintenance prévisibles, des certifications, des relations avec les constructeurs, des engagements de support, une documentation complète et un interlocuteur clairement identifié.

Dès 2001, Red Hat a choisi de développer une édition destinée aux entreprises et vendue sous la forme d’un abonnement. Red Hat Enterprise Linux est ensuite devenu son produit central, avec une première version publiée en 2002 et un travail particulier mené avec les fabricants afin d’assurer la compatibilité du matériel, des pilotes et des différentes couches logicielles.

Red Hat n’a donc pas seulement vendu Linux.

L’entreprise a vendu aux grandes organisations la possibilité d’utiliser Linux avec le niveau de prévisibilité, de responsabilité et de sécurité contractuelle qu’elles avaient l’habitude d’attendre d’un éditeur propriétaire.

Et c’est précisément sur cette intuition que repose une grande partie de son succès.

Même PostgreSQL finit par avoir besoin d’une offre industrielle

Cette logique ne concerne pas uniquement les systèmes d’exploitation ou les plateformes Kubernetes. Cédric rappelle que l’on retrouve les mêmes mécanismes autour des bases de données libres.

PostgreSQL est un logiciel open source reconnu, mature et largement utilisé. Une organisation peut librement le télécharger, l’installer et l’administrer. Mais lorsqu’il s’agit de gérer des bases de données critiques, réparties sur une très grande infrastructure, les besoins changent. Il faut garantir la haute disponibilité, organiser les sauvegardes, préparer la reprise après incident, surveiller les performances, gérer les mises à jour, sécuriser les accès et disposer d’une assistance capable d’intervenir rapidement.
Cédric prend alors l’exemple d’IBM, qui commercialise une offre appelée EDB Postgres Enterprise and Standard with IBM. Elle associe PostgreSQL aux technologies et aux services professionnels d’EDB afin de répondre aux besoins des environnements d’entreprise. IBM propose également un service PostgreSQL entièrement administré dans son propre cloud.
Il faut toutefois éviter un raccourci : IBM ne possède pas PostgreSQL et ne constitue pas le seul chemin possible pour l’exploiter à grande échelle.
Le projet PostgreSQL recense lui-même de nombreuses entreprises proposant du support professionnel. En Europe, des sociétés comme Dalibo, CYBERTEC et plusieurs autres accompagnent déjà des infrastructures critiques.

Mais l’exemple cité reste révélateur. Même lorsqu’une organisation choisit une base de données libre, elle peut finalement se tourner vers un acteur comme IBM pour obtenir la structure, les garanties et la capacité de support nécessaires à une utilisation massive.

Le logiciel reste ouvert. Le besoin de réassurance commerciale et opérationnelle, lui, ne disparaît pas.

Le DSI ne cherche pas seulement une technologie : il cherche à être rassuré

Pour Cédric, la logique suivie par Red Hat est donc compréhensible. Un directeur des systèmes d’information ne sélectionne pas uniquement un logiciel sur la qualité de son code ou sur les libertés inscrites dans sa licence. Par ses décisions, il engage la continuité des services utilisés par des milliers, voire des millions de personnes, ainsi que la sécurité d’applications critiques et de données sensibles.

Il cherche naturellement à être rassuré.

Il veut savoir qui répondra lorsqu’un incident se produira. Il veut connaître la durée de maintenance du produit, les délais d’intervention, les responsabilités contractuelles et les compétences disponibles. Il veut pouvoir présenter à sa direction un fournisseur identifié, un contrat, un budget et des engagements mesurables.

Red Hat a su apporter cette réponse.

Le problème n’est donc pas que cette entreprise ait construit un modèle économique autour du support. Le support est indispensable, et il est légitime que les entreprises qui le fournissent puissent financer leurs ingénieurs, leurs infrastructures et leurs contributions.

Le véritable problème apparaît lorsque cette réassurance ne peut plus être obtenue qu’auprès d’un acteur unique, avec des conditions qui réduisent progressivement les possibilités de choix du client.

L’Europe doit construire ses propres offres

Sans désigner une entreprise particulière, Cédric estime que les intégrateurs, les éditeurs et les entreprises de services numériques européennes devraient davantage unir leurs forces.

L’Europe dispose de développeurs, d’experts, de sociétés de support et d’intégrateurs de grande qualité. Elle dispose également de technologies reconnues et de nombreuses communautés open source.

Ce qui lui manque encore, ce sont des offres communes suffisamment lisibles, puissantes et rassurantes pour concurrencer les grands acteurs internationaux.

Une grande organisation ne veut pas seulement entendre qu’une solution existe. Elle veut savoir qui l’installera, qui la maintiendra, qui assurera son support vingt-quatre heures sur vingt-quatre, qui garantira les mises à jour de sécurité et qui prendra la responsabilité du service pendant dix ou quinze ans.

Pour rivaliser avec Red Hat, il ne suffit donc pas de proposer une autre distribution ou de rappeler que le code source est disponible. Il faut bâtir tout l’écosystème industriel qui l’accompagne.

On observe cependant une certaine frilosité parmi les acteurs européens.

Construire une offre commune suppose d’investir, de partager les responsabilités, d’accepter une gouvernance collective et de financer des équipes avant même de disposer d’un volume important de clients. Or le modèle économique de l’open source ne repose pas nécessairement sur la vente de licences. Il dépend du support, de l’expertise, de l’intégration, de la maintenance et des services.

L’écosystème cherche encore son équilibre.

Chaque entreprise peut être tentée de préserver ses propres clients, ses propres compétences et son propre catalogue plutôt que d’investir dans une offre commune dont la valeur serait partagée entre plusieurs acteurs.

Pourtant, c’est précisément cette capacité à s’unir qui pourrait permettre de construire une véritable alternative européenne : une offre suffisamment solide pour rassurer les DSI, mais suffisamment ouverte pour ne pas transformer cette réassurance en nouvelle dépendance.

IA et communs numériques : l’open source change de modèle

Enfin, Cédric voit se dessiner deux évolutions susceptibles de transformer en profondeur l’open source :

L’intelligence artificielle modifie déjà la manière de travailler des développeurs, en automatisant certaines tâches et en déplaçant une partie de leur travail vers la vérification, la correction et l’intégration du code.

Dans le même temps, les communs numériques, comme LaSuite de l’État, font émerger une autre manière de concevoir et de gouverner les logiciels. Les acteurs publics et privés ne se contentent plus d’utiliser des solutions existantes : ils peuvent contribuer à une infrastructure commune, en partager la gouvernance et en assurer collectivement la pérennité.

Selon lui, cette convergence pourrait ouvrir une troisième voie entre la dépendance à un éditeur propriétaire et les fragilités de projets open source trop dispersés. La souveraineté technologique reposerait alors moins sur la propriété exclusive du code que sur sa maîtrise et sa gouvernance collective.

Deux générations, une même exigence

Les regards de Florian Caringi et de Cédric Ravalec ne se confondent pas, et c’est justement ce qui fait leur intérêt.

Florian n’appartient pas à la génération historique de l’open source professionnel. Son arrivée plus récente dans cet écosystème constitue une force. Il porte un regard neuf, apporte une énergie différente et montre que l’open source n’est pas un domaine réservé à celles et ceux qui le fréquentent depuis les débuts de Linux.

Son parcours peut aussi susciter des vocations.

Il montre à une nouvelle génération qu’il est possible de travailler dans l’open source au cœur d’un grand groupe, de participer à sa gouvernance, de construire des politiques ambitieuses et de rapprocher les enjeux techniques des questions de souveraineté.

L’open source n’est plus un sujet périphérique. Il offre désormais des parcours professionnels d’avenir, modernes, stratégiques et profondément utiles.

Cédric apporte pour sa part la mémoire de cette transformation. Il a connu l’époque où l’open source devait encore démontrer qu’il n’était pas seulement une affaire de passionnés, de bricoleurs ou de geeks. Il fait partie de celles et ceux qui ont contribué à le faire entrer dans les entreprises, à construire des offres, à créer des sociétés, à organiser des communautés et à faire reconnaître la valeur du support professionnel.

Cette longue expérience ne l’a rendu ni cynique ni désabusé, et n’a rien retiré à sa passion.

Elle lui permet au contraire de regarder le chemin parcouru sans oublier ce qui reste à construire. L’open source a démontré qu’il constituait une alternative sérieuse, robuste et crédible aux systèmes propriétaires. Ses fondations n’ont plus à rougir de la comparaison.

Le temps de la démonstration technique est largement derrière nous.

Le temps de la construction industrielle, lui, est MAINTENANT.

C’est maintenant qu’il faut investir.
Maintenant qu’il faut faire émerger des offres européennes communes.
Maintenant qu’il faut sécuriser les compétences, financer le support et transformer les réussites dispersées en véritables acteurs capables de rivaliser à l’échelle internationale.

Il était donc important de dresser le portrait de ces deux personnalités.

Leurs parcours sont différents, leurs expériences appartiennent à des moments distincts de l’histoire de l’open source, mais leurs chemins se croisent sur des questions essentielles : la maîtrise, la réversibilité, l’interopérabilité et la capacité à ne pas remplacer une dépendance propriétaire par une dépendance commerciale construite autour d’un logiciel ouvert.

Tous deux m’ont mis sur une piste particulièrement intéressante : celle d’une comparaison approfondie entre Red Hat OpenShift et SUSE Rancher Prime.

Mais cette comparaison ne doit pas, elle non plus, devenir une nouvelle illusion.

Cette complémentarité ne se limite d’ailleurs pas à leurs témoignages. Florian et Cédric sont également à l’origine du Data & AI Sovereignty Summit : Florian en est le cofondateur et président, tandis que Cédric siège au comité de direction de l’événement. Cette rencontre consacrée à la donnée et à l’intelligence artificielle place la souveraineté au cœur de sa réflexion : comment continuer à innover tout en gardant la maîtrise de ses données, de ses infrastructures et de ses choix technologiques ?
Il ne s’agit pas de prétendre tout construire seul, mais de limiter les dépendances subies, de préserver sa capacité de décision et de concevoir des systèmes plus ouverts et plus résilients. Prévue le 25 février 2027 à Paris, la première édition réunira des décideurs, des experts et des professionnels venus partager des solutions et des retours d’expérience concrets.

Et si SUSE changeait de mains ?

Il serait tentant de considérer SUSE comme l’alternative européenne qui permettrait de disperser les dépenses aujourd’hui concentrées autour d’IBM et de Red Hat.

Mais la localisation actuelle d’une entreprise ne garantit pas éternellement son indépendance.

IBM a achevé l’acquisition de Red Hat en 2019 pour environ 34 milliards de dollars. Comme cela a été rappelé au début de cet article, le rapport de la commission d’enquête parlementaire indique qu’en 2025, les administrations de l’État ont consacré 17,1 millions d’euros à Red Hat et 12,6 millions à IBM, soit près de 30 millions d’euros pour les deux entreprises.

Que se passerait-il si SUSE était à son tour rachetée par un grand groupe américain ou par un consortium extra-européen ?

La question n’est d’ailleurs plus entièrement théorique. SUSE est aujourd’hui contrôlée par le fonds d’investissement suédois EQT, qui l’a retirée de la Bourse en 2023. En mars 2026, Reuters a rapporté qu’EQT étudiait une éventuelle cession de SUSE, dans une opération qui pourrait valoriser l’entreprise autour de six milliards de dollars. Les discussions étaient alors présentées comme préliminaires et aucune vente n’était acquise.

Si SUSE passait demain sous le contrôle d’un groupe extra-européen, la nature fondamentale du problème ne changerait pas.

Au lieu de voir les dépenses concentrées sur une seule ligne correspondant au duo IBM-Red Hat, une deuxième ligne apparaîtrait simplement dans les comptes. L’argent serait mieux réparti entre plusieurs fournisseurs, ce qui réduirait peut-être certaines dépendances opérationnelles, mais il continuerait à bénéficier à des entreprises contrôlées depuis l’extérieur de l’Europe.

La diversification est nécessaire, mais elle ne constitue pas à elle seule une politique de souveraineté.

Il serait peut-être temps de poser une question plus ambitieuse : pourquoi l’Europe ne construirait-elle pas un acteur capable de concurrencer sérieusement Red Hat ?

Pourquoi ne pas imaginer un consortium européen, réunissant des industriels, des intégrateurs, des entreprises de services, des investisseurs de long terme et éventuellement des acteurs publics, afin de sécuriser durablement l’ancrage européen d’une entreprise comme SUSE ?

Et pourquoi limiter cette réflexion à SUSE ?

D’autres distributions, d’autres plateformes et d’autres communautés pourraient servir de fondation à des offres européennes capables d’associer support professionnel, standards ouverts, interopérabilité et véritable réversibilité.

Un simple drapeau européen ne suffirait évidemment pas. Il faudrait garantir une gouvernance durable, empêcher qu’une nouvelle concentration ne recrée les mêmes dépendances et inscrire l’ouverture, la portabilité et le coût de sortie au cœur même du modèle.

Mais rien n’interdit de l’imaginer. Et surtout, rien ne justifie d’attendre davantage pour commencer à le construire.

L’article OP€N $OURCE : sortir d’une dépendance pour entrer dans une autre ? Sauf si… est apparu en premier sur Souverain.

• 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.