Ces rencontres ont eu lieu dans des salons professionnels, des conférences et parfois dans des soirées beaucoup plus informelles. Parmi les plus marquantes figurent notamment OW2con, la soirée organisée par l’équipe de À la French, puis, plus récemment, EuroCommons, organisé par la Caisse des Dépôts.
Un article avait d’ailleurs été publié avant l’événement pour expliquer pourquoi il semblait intéressant de s’y rendre. Il manquait encore le retour sur cette journée. Ce n’était pas un oubli. Il fallait probablement un peu de temps pour digérer ce qui avait été entendu et observé sur place. Car ces rencontres ont progressivement alimenté une réflexion beaucoup plus large.
Elles ont permis de mettre des visages derrière des organisations, de confronter certains discours à la réalité, mais aussi, dans quelques cas, d’entrevoir les coulisses d’un milieu qui reste assez difficile à comprendre lorsqu’on le regarde uniquement de l’extérieur.
Et tout cela sans avoir à se compromettre. Pour comprendre la suite, il faut aussi situer la position depuis laquelle cette réflexion est menée.
Je ne suis pas journaliste. Je ne suis pas non plus issu de ce sérail. Je ne possède aucune action ni aucun intérêt financier dans les sociétés citées sur ce site ou dont les solutions ont été testées. Je ne travaille pas davantage pour la DINUM, pour un ministère ou pour une organisation chargée de défendre une politique gouvernementale.
Cette position n’est évidemment pas une garantie d’avoir raison. Elle permet de conserver une certaine liberté.
L’objectif reste le même depuis le début : essayer de comprendre ce que pourrait signifier concrètement la souveraineté numérique et, autant que possible, regarder ces questions sous l’angle de l’intérêt général plutôt qu’à travers la défense d’un intérêt privé, industriel ou gouvernemental.
Cette liberté implique aussi une chose qui paraît essentielle : pouvoir changer d’avis.
Certaines idées séduisent immédiatement. Elles semblent évidentes, cohérentes, parfois même enthousiasmantes. Puis on commence à gratter. Un peu. Beaucoup parfois. Et l’on découvre qu’elles sont techniquement irréalistes, économiquement fragiles, politiquement difficiles à mettre en œuvre ou simplement moins bonnes qu’elles n’en avaient l’air au départ. D’autres, au contraire, résistent à l’examen. Plus elles sont confrontées aux faits et aux contradictions, plus elles semblent solides.
Et puis il existe une autre catégorie : les idées auxquelles on n’adhère pas spontanément. Elles bousculent parfois les convictions de départ. Pourtant, à force de lectures, de discussions et de confrontations avec le réel, elles commencent à prendre forme. Elles deviennent plus précises, plus matures, jusqu’à parfois finir par convaincre.
Changer d’avis ne devrait pas être considéré comme une faiblesse. C’est même probablement une condition nécessaire pour essayer de rester libre intellectuellement. Comme une forme de plasticité d’esprit qui oblige à accepter qu’une idée puisse évoluer, être remise en question ou parfois abandonnée.
Après plus d’un an passé à explorer ces sujets, un peu de recul commence donc à être possible.
Certainement pas assez pour prétendre tout connaître, ce serait prétentieux, mais suffisamment pour constater que le raisonnement a évolué au fil des expériences, des lectures et surtout des rencontres.
La saison estivale a aussi été l’occasion de relire L’Étrange Défaite de Marc Bloch, entré au Panthéon en juin. Cette lecture reste toujours et encore troublante.

Le livre m’avait déjà laissé une forte impression lors d’une première lecture. Mais certaines pages prennent une autre dimension lorsqu’elles sont relues après avoir passé des mois à s’intéresser au fonctionnement des organisations, aux administrations, à leur rapport à la technologie, à la décision, au changement et parfois à leur difficulté à remettre en cause leurs propres habitudes.
Il ne s’agit évidemment pas de comparer la situation actuelle à la défaite militaire de 1940.
Ce serait historiquement absurde et intellectuellement malhonnête. Mais certains mécanismes décrits par Marc Bloch résonnent étrangement avec des discussions, des témoignages et des lectures accumulés au cours de cette expérience autour de la souveraineté numérique.
Cette impression n’était d’ailleurs pas tout à fait isolée. En poursuivant mes recherches, je suis retombé sur une tribune publiée par Tariq Krim en avril 2025, dont le titre pouvait difficilement être plus évocateur : L’Étrange Défaite Numérique. Lui aussi convoquait Marc Bloch pour interroger notre capacité à regarder en face les transformations en cours et, surtout, la manière dont l’État français se prépare aux enjeux de souveraineté numérique. Nos conclusions et expériences ne sont pas nécessairement les mêmes, notamment sur le rôle que devraient jouer l’État et le secteur privé, mais découvrir qu’il avait lui aussi établi ce parallèle quelques mois auparavant m’a conforté sur un point : les résonances perçues à la lecture de Bloch n’étaient peut-être pas si incongrues.
La difficulté à faire un pas de côté, le poids des organisations, la circulation parfois imparfaite de l’information, l’incapacité de certaines structures à s’adapter lorsque l’environnement change, la tentation de reproduire les méthodes qui ont fonctionné hier alors même que le problème, lui, a changé.
Et surtout cette question qui m’obsède : comment une organisation composée de personnes compétentes peut-elle collectivement avoir autant de difficultés à se transformer ?
C’est notamment cette interrogation qui sert de point de départ à l’idée de cet article.

Je souhaitais revenir sur l’histoire de la DINUM, comprendre ce qu’elle avait réellement produit, regarder ses réussites comme ses échecs et essayer de comprendre pourquoi, vu de l’extérieur, certaines transformations semblent avancer beaucoup moins vite qu’on pourrait le souhaiter.
Il fallait aussi prendre au sérieux les critiques entendues ces derniers mois. Certaines ont été formulées directement lors de rencontres. D’autres apparaissent dans des articles, des rapports, des interviews, des conférences ou des prises de position publiques. Elles ne disent pas toutes la même chose. Elles ne viennent pas non plus des mêmes milieux.
Certaines concernent la place de l’État face au marché. D’autres interrogent la manière dont sont développés les communs numériques. D’autres encore portent sur la gouvernance, les méthodes de travail, les financements, les relations avec les éditeurs privés ou la capacité de l’administration à transformer une expérimentation réussie en véritable politique industrielle. Ces critiques doivent être regardées pour ce qu’elles disent, y compris lorsqu’elles viennent bousculer mes propres conclusions. D’autant qu’avant d’aller plus loin, un autre élément doit être rappelé aux nouveaux lecteurs de ce site : la défense de LaSuite numérique m’a déjà valu quelques critiques.
Lorsque LaSuite a été découverte puis testée ici, l’enthousiasme n’a pas été dissimulé :
Docs, Visio et plus largement la logique de cette suite d’outils collaboratifs et bureautiques correspondaient à une grande partie des besoins recherchés depuis le début de cette expérience. Avec le recul, cet enthousiasme n’a pas disparu.
LaSuite correspond toujours à mes besoins. Ses évolutions sont suivies de près, tout comme les développements de ses différents outils, et jusqu’à présent la trajectoire observée continue d’aller dans ce qui semble être la bonne direction. Cela ne signifie pas pour autant que tout soit parfait.
Et c’est précisément sur ce point que plusieurs détracteurs de mes précédents articles ont formulé une critique : le regard porté sur LaSuite ne serait pas suffisamment attentif aux conséquences de son développement sur le marché, en particulier pour les éditeurs privés français et européens. Cette critique existe notamment chez certains éditeurs, syndicats ou organisations qui défendent ce secteur. Elle doit être entendue et même parfaitement compréhensible. Mais il existe probablement ici un malentendu sur l’intention de départ.
Défendre une initiative publique qui semble pertinente ne signifie pas vouloir favoriser systématiquement l’État ou la DINUM au détriment du marché. L’objectif n’a jamais été de choisir un camp et encore moins de chercher à fragiliser une industrie française ou européenne du logiciel. Ce n’est ni la volonté de ce site, ni son rôle, ni même sa prétention.
Le sujet est ailleurs : essayer de rendre ces enjeux compréhensibles par le grand public et regarder ce qui pourrait réellement contribuer à davantage de souveraineté numérique.
Il serait donc tout aussi absurde de considérer par principe que tout ce qui vient de l’État est souhaitable, que d’estimer que toute initiative publique devient suspecte dès lors qu’un acteur privé propose déjà une solution sur le marché.
La question est plus complexe : Qui doit produire quoi ? Dans quelles conditions ? Avec quelle gouvernance ? Avec quel financement ? Jusqu’où l’État doit-il développer ses propres outils ? À partir de quel moment doit-il s’appuyer sur le marché ? Comment soutenir les entreprises européennes tout en développant des communs numériques ?
Et surtout : comment éviter de reconstruire de nouvelles dépendances en prétendant sortir des anciennes ?
Il y a quelque chose d’un « je t’aime, moi non plus » dans la manière dont la DINUM est regardée. Elle agace, parfois beaucoup. On peut contester certains de ses choix, sa manière d’occuper un espace où des entreprises françaises et européennes cherchent elles aussi à construire des solutions souveraines, ou s’interroger sur cette frontière devenue de plus en plus floue entre l’État stratège et l’État opérateur. Tariq Krim (oui, encore) en a fait l’une de ses critiques les plus fortes, tandis que le CNLL défend depuis plusieurs années une autre répartition des rôles : à l’État la définition des standards, l’interopérabilité, la commande publique et le soutien à la filière ; aux éditeurs et à l’écosystème professionnel la production et l’exploitation des solutions lorsqu’un marché existe déjà.
Mais regarder la DINUM uniquement sous cet angle conduirait à manquer une autre partie de l’histoire. Derrière l’institution, il y a aussi des équipes qui construisent, expérimentent, abandonnent parfois ce qui ne fonctionne pas et recommencent autrement. Tout n’aboutit pas, et certains échecs ont coûté du temps et de l’argent public. D’autres projets, en revanche, finissent par trouver leurs usages.
LaSuite en fournit aujourd’hui un exemple assez éclairant : lorsque la Cour des comptes examine en 2024 ce qui constitue alors la préfiguration de l’actuelle LaSuite, elle s’inquiète d’outils encore peu utilisés et coûteux ; deux ans plus tard, leur adoption a sensiblement changé d’échelle.
Cela n’annule en rien les réserves formulées à l’époque. Cela rappelle simplement qu’en matière de numérique, une photographie à « l’instant T » peut rapidement devenir trompeuse lorsqu’on oublie que le produit continue à évoluer.
C’est aussi ce qu’il y a d’intéressant dans la position de Framasoft. Leur défense de LaSuite n’est pas béate : certaines critiques leur paraissent fondées, notamment sur la contribution aux communs, la réutilisation de logiciels libres existants, la pérennité des équipes ou la place que la DINUM doit occuper comme opérateur. Mais ils refusent pour autant de jeter l’ensemble du projet avec ses imperfections. Cette position paraît assez juste. Nous sommes en droit de demander des comptes à la DINUM, questionner ses méthodes et ses choix industriels, tout en reconnaissant qu’il s’y produit aussi quelque chose d’utile.

C’est probablement cette tension qui paraît la plus intéressante. Il ne s’agit ni de transformer chaque projet de la DINUM en réussite exemplaire, ni de considérer chaque tentative infructueuse comme la preuve que l’État serait incapable de produire du numérique.
Il s’agit plutôt de comprendre pourquoi certaines équipes parviennent à faire émerger des projets qui trouvent leur public, tandis que d’autres s’épuisent, disparaissent ou ne réussissent jamais à franchir le passage à l’échelle. Et c’est cette dernière question qui traversera la suite de cet article : qu’est-ce qui, dans cette organisation, permet de réussir, et qu’est-ce qui l’en empêche ?

C’est peut-être là que se situe le vrai débat. Il reste toutefois une confusion à éviter : Considérer LaSuite comme une réussite ne signifie pas, à mes yeux, que ce succès doive être rattaché à la défense d’un quelconque mandat présidentiel.

Vous me voyez venir. Et vous avez raison de vous poser la question.

Un projet porté par l’administration existe nécessairement dans un contexte politique.
Il dépend de décisions, d’arbitrages budgétaires et d’orientations prises par des gouvernements successifs. Cela ne transforme pas pour autant toute analyse de ce projet en soutien au pouvoir en place. Ce n’est pas le sujet de cet article.
L’objectif est justement de remonter plus loin. De regarder l’histoire de la DINUM, ses transformations successives, ses méthodes, ses projets et les personnes qui ont contribué à faire évoluer la politique numérique de l’État.

Autrement dit, essayer de comprendre comment on en est arrivé là.

Et, puisque la formule a été entendue suffisamment souvent ces derniers mois, essayer aussi de comprendre ce « pourquoi tant de haine ? » qui semble parfois entourer la DINUM.

Pourquoi cette direction cristallise-t-elle autant de critiques ?
Pourquoi certaines de ses initiatives sont-elles perçues comme une menace par une partie du secteur privé ?
Pourquoi d’autres acteurs considèrent-ils au contraire que l’État ne va pas assez loin ?
Pourquoi certaines réalisations reconnues coexistent-elles avec des échecs, des lenteurs ou des frustrations ?
Et surtout : que raconte le fonctionnement de la DINUM de notre manière collective de construire notre souveraineté numérique ?

Pour essayer d’y répondre, il va falloir regarder de près une partie de son fonctionnement, son histoire et sa gouvernance. Il faudra revenir sur des projets qui ont fonctionné, sur d’autres qui ont échoué, sur les choix qui ont été faits et sur ceux qui n’ont peut-être jamais vraiment été tranchés.
Il faudra également tenter d’esquisser une vision, quelques idées et peut-être un horizon.
Certains trouveront sans doute la démarche prétentieuse. Après tout, qui suis-je pour porter un jugement sur une administration, sur des femmes et des hommes qui travaillent sur ces sujets depuis parfois plusieurs décennies ?

La réponse est assez simple : personne de particulier.

Il faut simplement lire ce qui suit pour ce que c’est : le regard d’un citoyen qui cherche juste à comprendre.

Il ne s’agit pas de distribuer des bons et des mauvais points, encore moins de donner des leçons à ceux qui font. Il s’agit d’essayer de comprendre à partir de lectures, de recherches, de témoignages, de rencontres et d’expériences concrètes.
La seule demande faite au lecteur est donc de prendre le temps d’aller jusqu’au bout du raisonnement avant de se forger une opinion sur ce qui va suivre.

La contradiction est évidemment bienvenue. Les commentaires sont ouverts pour cela. Pour celles et ceux qui préfèrent ne pas publier leur avis ou leurs désaccords publiquement, le formulaire de contact reste disponible. Enfin, lorsqu’un échange mérite davantage qu’une succession de messages, une visioconférence est toujours possible.

L’objectif est plutôt de comprendre ce que l’histoire de la DINUM, ses réussites, ses échecs et ses contradictions peuvent nous apprendre sur une question beaucoup plus large :

Comment construit-on réellement une souveraineté numérique ?

Cette question arrive d’ailleurs à un moment particulier de l’histoire de la DINUM :
Le 30 avril 2026, dans le contexte des nombreuses attaques informatiques ayant touché les services de l’État, le Premier ministre annonçait une profonde réorganisation de son pilotage numérique. Quelques mois plus tard, Walter Arnaud, ingénieur général de l’armement et ancien directeur adjoint de la Direction de l’industrie de défense de la DGA, où il pilotait notamment le chantier économie de guerre, prenait la tête de la DINUM tout en étant chargé de préfigurer sa transformation en ARIANE : la future autorité du numérique et de l’intelligence artificielle de l’État. Ce choix de profil n’est pas anodin et Alexandre Berge en propose une lecture intéressante dans son article au titre volontairement provocateur : Ariane, le numérique d’État saisi par l’armement. Après des années durant lesquelles la DINUM s’est notamment construite autour de la transformation numérique, des méthodes produit, des communs et de l’accompagnement des usages, l’État semble désormais vouloir ajouter une logique plus marquée de souveraineté industrielle, de sécurité et de maîtrise de grands programmes. Quelques semaines plus tard, l’auteur poursuivait son analyse avec Ariane, une autorité avant d’être une capacité, en posant une autre question : donner davantage d’autorité à l’organisme qui pilote le numérique de l’État suffira-t-il si les moyens, les compétences et la capacité d’exécution ne suivent pas ? À l’heure où ces lignes sont écrites, ARIANE n’existe d’ailleurs pas encore juridiquement comme nouvelle autorité : sa création administrative est annoncée avant le 1er janvier 2027. Il serait donc prématuré de juger ce qu’elle sera. Mais cette transformation rend encore plus nécessaire de comprendre ce dont elle hérite. Et pour cela, il faut revenir à l’histoire de la DINUM.

La suite de cet article reviendra sur la naissance de la DINUM et sur les différentes étapes qui ont façonné son rôle au sein de l’État. Il ne s’agira pas d’en dresser une chronologie exhaustive, mais de s’arrêter sur quelques moments, quelques projets et quelques trajectoires qui permettent de mieux comprendre ce qu’elle est devenue. L’analyse passera aussi par plusieurs figures qui ont compté dans cette histoire. Non pas seulement celles qui ont créé ou dirigé l’institution, mais celles qui, à l’intérieur, ont porté des projets, défendu des méthodes, tenté des transformations et parfois essuyé des échecs. C’est souvent dans ces réalisations, réussies ou non, que l’on comprend le mieux le fonctionnement réel d’une organisation, au-delà de ses organigrammes et de ses communiqués.

Enfin, j’essaierai, en dernier lieu, d’esquisser quelques horizons. Ils resteront ceux d’un citoyen, extérieur à l’appareil d’État et à ses arbitrages, mais ils seront formulés avec le sérieux qu’impose désormais la situation. Car derrière les choix d’organisation, de gouvernance ou d’outillage se joue souvent une question beaucoup plus grande : celle de notre capacité collective à conserver une maîtrise réelle de notre environnement numérique.

LaSuite a, à sa manière, montré qu’il pouvait se passer quelque chose dans cet écosystème français du numérique. Derrière les outils, il y a eu des femmes et des hommes qui ont accepté de faire autrement, de construire, d’expérimenter, de travailler avec le logiciel libre, les communs et les contraintes propres à l’État. C’est peut-être cela, au fond, une « Génération LaSuite » que j’arrive à entrevoir à travers le choix de ce titre : pas une équipe figée ou une nouvelle marque d’État, mais une génération de personnes capables de faire émerger une autre culture du numérique public.
La question est désormais de savoir si cette dynamique restera limitée à quelques projets et à quelques équipes, ou si elle peut devenir un mouvement plus large. Il faudra susciter des vocations, attirer des compétences, donner envie à d’autres de rejoindre cette manière de faire et créer les conditions pour que cette génération ne reste pas une exception.
ARIANE ouvre une nouvelle phase. Elle peut devenir l’occasion d’amplifier ce qui a commencé à émerger avec LaSuite, mais elle peut aussi reproduire des mécanismes que l’histoire de la DINUM permet justement d’identifier.
Les propositions qui suivront doivent être lues dans cet esprit : comme une contribution citoyenne qui ne cherche ni à dramatiser ni à rassurer, mais à regarder les fragilités en face et à proposer modestement, un horizon.

Historique de la DINUM

La DINUM (Direction interministérielle du numérique) porte ce nom depuis 2019, sous le gouvernement d’Édouard Philippe. Elle s’inscrit toutefois dans une histoire plus ancienne. La DISIC (Direction interministérielle des systèmes d’information et de communication de l’État) avait été créée en 2011 sous Nicolas Sarkozy et François Fillon pour coordonner les systèmes d’information de l’État. Elle devient en 2015, sous François Hollande et Manuel Valls, la DINSIC (Direction interministérielle du numérique et du système d’information et de communication de l’État), avec un champ élargi au numérique et l’intégration notamment d’Etalab.
En 2019, la DINSIC devient la DINUM : la logique dépasse alors celle d’une sorte de direction informatique centrale chargée de coordonner les systèmes d’information des différents ministères, pour englober plus explicitement la transformation numérique des politiques publiques, les services numériques, les données, les méthodes de développement et les compétences numériques de l’État.

Depuis, son rôle a continué à s’élargir. Une réforme de 2023 lui confie plus explicitement l’élaboration de la stratégie numérique de l’État, soumise au Premier ministre, ainsi que le pilotage de sa mise en œuvre et l’accompagnement des administrations et organismes sous tutelle.
En mars 2026, son pouvoir de contrôle est encore renforcé : l’avis conforme, déjà requis pour les projets numériques ministériels et interministériels dépassant certains seuils, est étendu aux projets concernés des organismes placés sous la tutelle de l’État. Le décret du 18 mars ajoute également un avis conforme pour certaines commandes de suites collaboratives ou de logiciels SaaS hébergés dans un cloud fourni par un prestataire privé. Cet examen porte notamment sur la sécurité et l’hébergement des données, mais aussi sur la maîtrise, la pérennité et l’indépendance technologique des systèmes concernés.
Enfin, le gouvernement a annoncé en 2026 une nouvelle transformation : la DINUM doit devenir ARIANE : l’Autorité référente pour l’intelligence artificielle et le numérique de l’État, avec un rôle davantage affirmé d’architecte technique de l’État, de définition des standards, de mutualisation des infrastructures et de maîtrise des dépendances technologiques.

Les directeurs et directrices de la DINUM depuis 2019

• Nadi Bou Hanna (octobre 2019 à janvier 2022)
  Il était déjà directeur de la DINSIC avant son changement de nom et devient donc le premier directeur de la DINUM. Il quitte ses fonctions à sa demande.
• Xavier Albouy (janvier 2022 à septembre 2022)
  Par intérim, après le départ de Nadi Bou Hanna.
• Stéphanie Schaer (septembre 2022 à juin 2026)
  C’est notamment sous son mandat que sont lancées la nouvelle feuille de route de 2023 et la montée en puissance de LaSuite.
• Walter Arnaud (depuis le 24 juin 2026)
  Ingénieur général de l’armement venu de la DGA, il a notamment été nommé dans le contexte de la réorganisation qui doit conduire la DINUM vers ARIANE.

Génération LaSuite : les prémices

Pour comprendre d’où viennent certaines des méthodes et des idées qui structurent aujourd’hui une partie du numérique public, il faut remonter un peu plus loin.
Bien avant LaSuite, avant même que le nom de DINUM n’apparaisse, une autre génération d’acteurs commence à entrer dans le numérique de l’État. Certains sont fonctionnaires, d’autres viennent du privé, de la société civile, des communautés du logiciel libre ou de l’entrepreneuriat. Ils n’ont pas tous les mêmes parcours ni les mêmes idées, mais plusieurs d’entre eux vont progressivement défendre une autre manière de construire des services numériques publics.

2013

Pendant cette période, deux cultures coexistent encore assez distinctement au sein de l’État. D’un côté, la DISIC, créée en 2011, est chargée d’orienter, coordonner et rationaliser les systèmes d’information des administrations. Elle travaille sur les infrastructures, les réseaux, les grands projets, les standards ou encore la mutualisation des moyens. Le décret qui la crée lui confie explicitement la mission d’améliorer « la qualité, l’efficacité, l’efficience et la fiabilité » des systèmes d’information de l’État et d’organiser les opérations de mutualisation entre administrations.

De l’autre côté existe Etalab, créée elle aussi en 2011 mais avec une mission très différente. Placée à l’origine sous l’autorité du Premier ministre, elle doit créer un portail interministériel permettant de rendre librement accessibles les données publiques et de favoriser leur réutilisation. Ce portail deviendra data.gouv.fr.
Etalab doit également coordonner l’action des administrations dans ce domaine et aider à construire un écosystème autour de l’open data. En 2012, DISIC et Etalab se retrouvent toutes deux au sein du nouveau Secrétariat général pour la modernisation de l’action publique, (le SGMAP), mais elles restent encore deux entités distinctes.

Henri Verdier prend la direction d’Etalab en 2013.

Autour d’Etalab et plus largement du SGMAP commencent alors à apparaître, ou à se développer, des projets qui vont compter dans la suite de cette histoire :
la refonte de datagouv, OpenFisca (créé en 2011 au Centre d’analyse stratégique, devenu France Stratégie en 2013, et dont Etalab devient ensuite un contributeur majeur), Mes Aides, la Base Adresse Nationale, les premières Startups d’État, puis progressivement les API et cette idée d’un « État plateforme » dans lequel les administrations ne construiraient plus seulement de grandes applications isolées, mais également des briques communes pouvant être réutilisées par d’autres.

L’open data a amené Henri Verdier à réfléchir à l’open innovation ; la donnée, à l’État plateforme. Pierre Pezziardi, qu’il rencontre à cette période, arrive pour sa part avec cette idée encore embryonnaire d’un « État en mode startup », entendue alors comme la possibilité de confier un problème à de petites équipes autonomes capables de construire, tester et faire évoluer rapidement un service.

Le rapprochement décisif intervient finalement en septembre 2015, sous François Hollande et le gouvernement de Manuel Valls.

La DISIC disparaît au profit de la DINSIC : la Direction interministérielle du numérique et du système d’information et de communication de l’État. Et son organisation raconte assez bien l’ambition du moment. Le texte réglementaire prévoit qu’elle comprend désormais un service et deux missions :

• le service « performance des services numériques »
• la mission « Etalab »
• la mission « incubateur de services numériques »

Le Réseau interministériel de l’État lui est également rattaché. Ce regroupement n’est pas seulement une réorganisation administrative, il correspond à une prise de conscience : le numérique ne se résume plus à l’informatique.
La DISIC avait été élaborée principalement autour des systèmes d’information : infrastructures, réseaux, mutualisation, architecture, maîtrise des coûts et contrôle des grands projets. Pendant ce temps, une autre culture s’était développée autour d’Etalab et du SGMAP : données ouvertes, API, services numériques, développement agile, réutilisation du logiciel libre, collaboration avec des communautés extérieures à l’administration et expérimentation de nouveaux modes de production.
Le passage de la DISIC à la DINSIC est à cet égard assez révélateur. Une lettre vient s’ajouter à l’acronyme : le N de numérique. La presse spécialisée de l’époque interprète explicitement cette réforme comme le rapprochement d’une vision technique, tournée vers la mutualisation, avec des approches davantage orientées vers les usages. Il existe aussi une raison beaucoup plus concrète à ce rapprochement : les données et les systèmes qui les produisent ne peuvent pas durablement être pensés séparément.
Le gouvernement l’explique d’ailleurs lui-même, quelques mois plus tard, à l’Assemblée nationale (page 160). La création de la DINSIC est présentée comme une opportunité permettant d’intégrer l’ouverture des données aux évolutions du système d’information de l’État. Autrement dit, plutôt que de construire un système puis de se demander ensuite quelles données pourraient en sortir, l’objectif devient de réfléchir dès sa conception à leur circulation, leur ouverture et leur réutilisation.

Jacques Marzin, qui dirigeait jusque-là la DISIC et participe à la conception de cette nouvelle organisation, défend alors une idée voisine : on ne peut pas séparer durablement les infrastructures des nouveaux usages qui reposent dessus.
Selon lui, créer d’un côté une informatique historique chargée des infrastructures et, de l’autre, une informatique « numérique » chargée d’innover conduirait à des doublons et à des surcoûts. La DINSIC doit donc réunir ces mondes : la puissance technique de la DISIC, la culture de la donnée portée par Etalab et les méthodes émergentes de l’incubateur de services numériques.
Pourtant, Jacques Marzin ne devient pas le directeur durable de cette structure élargie. Le 23 septembre 2015, le Conseil des ministres nomme Henri Verdier directeur interministériel du numérique et du système d’information et de communication de l’État.
Autrement dit, en l’espace de deux ans, celui qui dirigeait une mission relativement spécialisée consacrée à l’ouverture des données prend la tête de l’administration qui réunit désormais l’ancienne DISIC, Etalab et l’incubateur de services numériques. La presse de l’époque ne manque d’ailleurs pas le symbole : le « Chief Data Officer » devient le nouveau patron du numérique de l’État.

Ce choix permet peut-être de comprendre une partie de ce qui va suivre. En 2015, l’État ne se contente pas d’intégrer Etalab à sa direction informatique : il confie aussi la nouvelle direction numérique au patron d’Etalab. C’est un signal assez clair de la transformation recherchée. Il ne s’agit plus seulement d’assurer la cohérence et l’efficacité de l’informatique existante, mais d’élargir la réflexion à la manière dont l’État conçoit ses services numériques.

Et c’est à cette même période qu’une autre figure de cette « Génération LaSuite » va prendre davantage de place : Pierre Pezziardi.

Pierre Pezziardi : faire autrement

Son parcours tranche avec celui d’un haut fonctionnaire classique. Entrepreneur et informaticien, cofondateur du cabinet OCTO Technology puis impliqué dans plusieurs projets entrepreneuriaux, il arrive dans l’écosystème d’Etalab avec une idée assez simple à formuler, mais beaucoup moins évidente à appliquer dans l’administration : plutôt que de chercher à prévoir pendant des mois ou des années ce que devra être un service numérique, pourquoi ne pas constituer une petite équipe, mettre rapidement quelque chose entre les mains des utilisateurs, observer ce qui fonctionne et corriger le reste ? Lui-même résumera plus tard cette approche par des équipes « pluridisciplinaires et autonomes », donnant la priorité aux besoins des usagers et construisant les services de manière incrémentale.

Sa rencontre avec Henri Verdier intervient justement au moment où Etalab cherche à refondre datagouv. Le projet est une sorte de laboratoire. La plateforme existante est alors jugée coûteuse, difficile à faire évoluer et insuffisamment tournée vers ceux qui réutilisent réellement les données. Pierre Pezziardi propose de rompre avec la logique habituelle et de constituer directement une petite équipe capable de concevoir, développer et exploiter le service. Henri Verdier obtient le feu vert de Jérôme Filippini, alors secrétaire général pour la modernisation de l’action publique, et de Jacques Marzin, directeur de la DISIC. Quelques mois plus tard, une nouvelle version de datagouv est mise en ligne. Une enquête du Monde consacrée aux Startups d’État revient elle aussi sur cette refonte et rapporte une facture « divisée par vingt » par rapport aux prestataires précédents.

Mais l’importance de l’expérience ne tient probablement pas seulement à datagouv. Elle en fait une démonstration : une petite équipe disposant d’une autonomie importante peut mettre un service en production rapidement, continuer à le faire évoluer après son lancement et juger sa réussite à partir de son utilisation plutôt qu’à partir du simple respect d’un cahier des charges. La refonte de datagouv est ainsi considérée comme la première expérimentation de ce qui deviendra la Startup d’État. Les résultats obtenus conduisent ensuite à reproduire la méthode sur d’autres problèmes, avec notamment Marchés Publics Simplifiés, Mes Aides ou API Entreprise.

C’est là que Pierre Pezziardi commence à jouer un rôle plus large. Il est présenté comme un « entrepreneur en résidence«  et anime à partir de 2013 la communauté qui deviendra beta.gouv.fr. L’idée n’est pas de créer des « startups » au sens économique du terme : elles n’ont ni capital à lever, ni entreprise à revendre. Il s’agit plutôt d’emprunter à l’entrepreneuriat quelques principes d’organisation : partir d’un problème concret, confier sa résolution à une petite équipe autonome, mettre rapidement un produit face à de vrais utilisateurs, mesurer son impact puis décider de poursuivre, modifier ou arrêter. En 2018, il expliquera au Monde que cette aventure était partie d’une note rédigée en 2013 plaidant pour la création d’un incubateur au sein de l’État.

L’expérience finit par entrer dans l’organigramme. Lorsque la DINSIC est créée en septembre 2015, l’« incubateur de services numériques » devient officiellement l’une de ses deux missions, aux côtés d’Etalab. Le texte de l’arrêté du 21 septembre 2015 lui confie la tâche de développer des services numériques innovants, de les maintenir pendant une période déterminée puis, lorsqu’ils ont fait leurs preuves, de les transférer à l’administration appelée à les exploiter durablement.

Ce qui n’était encore, deux ans auparavant, qu’une expérience assez marginale autour de datagouv devient donc progressivement une méthode reconnue par l’État pour produire certains de ses services numériques. Et l’association entre Verdier et Pezziardi commence à dessiner une doctrine plus large. En 2017, ils la formaliseront ensemble dans Des Startups d’État à l’État plateforme : les petites équipes et leurs produits ne sont plus pensées comme des expériences isolées, mais comme les composantes d’un État capable de mettre à disposition des données, des API et des infrastructures communes sur lesquelles d’autres services pourront se construire.

Il faut toutefois y apporter une nuance : Pierre Pezziardi n’est pas fonctionnaire et son statut au sein de cette aventure est particulier. Derrière l’appellation d’ « entrepreneur en résidence », il intervient notamment comme prestataire extérieur. Une enquête du Monde publiée en 2023 a soulevé des questions sur ce statut, les marchés liés à beta.gouv et ses relations passées avec OCTO Technology mais il a contesté une partie des interprétations de cette enquête, et la DINUM indiquait que les marchés concernés avaient été attribués conformément aux règles de la commande publique. Cette particularité n’est pas anecdotique : la génération qui commence alors à transformer le numérique public ne vient justement pas uniquement de l’administration. Elle se constitue aussi au contact de développeurs, graphistes, ergonomes, entrepreneurs et communautés techniques venus de l’extérieur. On comprend alors que l’État ne doit pas seulement acheter ou piloter des projets numériques ; il doit aussi conserver la capacité de comprendre, de construire, d’expérimenter et d’améliorer lui-même certains des outils dont dépend son action.

Qu’est-ce que cette méthode a réellement produit ?

La réponse la plus facile consisterait à dresser une liste de services. Elle serait déjà assez longue. Mais elle manquerait peut-être l’essentiel. Depuis les premières expérimentations de 2013, beta.gouv a investigué et/ou développé 464 services numériques selon le décompte réalisé par la Cour des comptes. Parmi eux, 42 avaient été pérennisés, c’est-à-dire déployés à l’échelle nationale et entrés dans une phase d’exploitation, tandis que 24 avaient obtenu le statut de service à impact national.
Ces chiffres sont à manier avec précaution. Ils ne signifient évidemment pas que les quelques 400 autres projets sont autant d’échecs. Une partie de la méthode consiste précisément à arrêter tôt une idée lorsqu’elle ne démontre pas son utilité, plutôt que de continuer à l’alimenter parce qu’un budget a été voté ou qu’un plan doit être exécuté jusqu’à son terme. La Cour des comptes relève d’ailleurs que l’arrêt peut intervenir dès la phase d’investigation, avant même qu’un véritable produit soit construit.

Reste que plusieurs réalisations issues de cette période ont largement dépassé le stade de l’expérimentation. datagouv, point de départ de cette histoire, enregistrait encore plus de 80 millions de visites concernant les jeux de données et 315 millions de téléchargements en 2025.
Démarche Numérique, née quelques années plus tard dans cet écosystème, a dépassé 19,5 millions de dossiers déposés et est utilisée par plus de 1 200 partenaires publics. D’autres projets comme Pix, Mon-entreprise ou le Pass Culture ont quitté l’incubateur pour être repris par les administrations ou organismes chargés de les exploiter durablement.

À côté des Startups d’État, la même période voit également se développer les briques de ce que Verdier appelait l’État plateforme. Comme par exemple FranceConnect, initié par la DISIC en 2015 puis lancé en 2016 sous la DINSIC. Mais il appartient bien à cette transformation plus large et dix ans après son lancement, il compte 45 millions d’utilisateurs et plus de 1 500 services publics connectés, pour quelque 500 millions de connexions en 2025.

Marchés Publics Simplifiés illustre peut-être encore mieux ce que cette méthode pouvait produire et a fini par disparaître pour devenir DUME (Document Unique de Marché Européen). Si l’on s’en tient au nom du service, on pourrait conclure à un échec, mais pour faire fonctionner ce simple bouton permettant aux entreprises de répondre plus facilement à un marché public, l’équipe avait besoin que les informations déjà détenues par l’administration puissent circuler automatiquement. Ce besoin a contribué à faire émerger API Entreprise, qui, elle, a survécu et est devenue une infrastructure réutilisée par de nombreux services publics.

Certains reconnaissent même avoir initialement sous-estimé l’importance de la co-construction permanente avec les utilisateurs : Philippe Vrignaud propose alors d’aller plus loin que quelques consultations ponctuelles en organisant un “OpenLab” mensuel avec les parties prenantes. La pratique se généralisera ensuite dans les Startups d’État, beta.gouv décrivant l’OpenLab comme une réunion régulière où les partenaires opérationnels participent à l’orientation concrète du produit.

Ce dernier exemple est important, car il empêche de raconter l’histoire comme l’application parfaite d’une doctrine imaginée par quelques visionnaires. La méthode elle-même s’est construite en expérimentant, en se trompant et en apprenant. Et peut-être est-ce finalement son résultat le plus durable. Car beta.gouv n’a pas seulement produit des logiciels. Il a contribué à installer dans l’administration des métiers, des méthodes et une communauté de plusieurs métiers habitués à travailler différemment. À partir de 2016, le programme Entrepreneurs d’intérêt général va encore accélérer cette ouverture en faisant entrer temporairement dans les administrations des professionnels venus de l’extérieur.
Entre 2016 et 2023, plus de 200 talents ont ainsi été recrutés et plus de 100 projets ont été conduits dans plus de 80 administrations.

Une nouvelle génération, mais pas seulement venue du privé

Cette capacité à faire entrer des profils venus d’horizons très différents n’est pas anecdotique : elle a permis à des personnes issues du logiciel libre, de l’entrepreneuriat, de la tech ou de la société civile de travailler aux côtés d’agents publics et de faire circuler progressivement une culture commune entre ces différents mondes.

En remontant le fil de ces équipes, on retrouve un nombre assez remarquable de personnalités issues du logiciel libre, de l’entrepreneuriat, de la tech ou de la société civile, venues travailler quelques années, ou parfois beaucoup plus longtemps, au service de l’État comme par exemple : Christian Quest, Bastien Guerry, Matti Schneider, Laurent Bossavit, Hela Ghariani, Samuel Paccoud, Sylvain Zimmer, Virgile Deville, Benjamin Bayart, Jérôme Desboeufs, et même Tristan Nitot.
La Cour des comptes constate elle-même que les communautés créées autour de beta.gouv et des Entrepreneurs d’intérêt général, sont devenues un vivier de recrutement pour la DINUM, et que d’anciens participants ou prestataires ont ensuite rejoint directement la direction, y compris à des fonctions de responsabilité.

Une première ligne de force apparaît : l’État a su faire entrer de nouveaux profils, de nouvelles méthodes et de nouvelles manières de construire ses services numériques. La difficulté commence lorsque ces expérimentations doivent dépasser leur cadre initial et s’inscrire durablement dans le fonctionnement de l’administration.

Cette difficulté rejoint assez directement la distinction que Pierre Pezziardi et Frédéric Lippi proposent entre travail prescrit et travail réel : les Startups d’État ont précisément cherché à réduire cet écart en redonnant de l’autonomie aux équipes de terrain, sans parvenir pour autant à faire de cette logique la norme dans l’administration. Créer des espaces où l’on peut travailler autrement est une chose mais transformer l’organisation qui doit ensuite les accueillir en est une autre.

De la « Débureaucratisation » au retour à une réalité : la bureaucratie

Les réussites permettent de comprendre ce que cette méthode a rendu possible. Les limites apparaissent surtout lorsqu’il faut inscrire ces nouvelles façons de faire dans la durée, au sein d’organisations plus vastes et plus contraintes.

Mais que deviennent ces méthodes lorsqu’elles quittent le laboratoire ?
Et que se passe-t-il lorsque la petite équipe autonome doit rejoindre une administration beaucoup plus grande, retrouver ses règles budgétaires, ses chaînes hiérarchiques, ses contraintes de recrutement, ses marchés publics et ses systèmes informatiques existants ?

Au fil des rencontres et des lectures accumulées ces derniers mois, cette difficulté revient régulièrement. Elle est d’ailleurs très clairement documentée par la Cour des comptes, qui considère que « la sortie d’incubation des produits à impact » constitue aujourd’hui le principal défi rencontré par les Startups d’État. L’administration reste largement organisée selon une logique de « projet » : un budget, un début, une fin, une livraison. Le mode produit suppose au contraire qu’une équipe continue à travailler après la mise en ligne, mesure les usages, corrige ce qui ne fonctionne pas et dispose durablement des compétences nécessaires pour faire évoluer le service. Cette différence apparemment technique finit par toucher aux budgets, aux ressources humaines et jusqu’à l’organisation même des administrations.

Une fois le produit lancé, un autre défi commence : préserver dans la durée l’équipe, les moyens et la capacité d’évolution qui ont permis son succès initial.

L’histoire de Mes Aides en fournit un exemple intéressant. Le service, lancé en 2014, permettait à chacun d’estimer rapidement ses droits aux prestations sociales. Il avait dépassé le million d’utilisateurs dès 2017 et obtenu le statut de service à impact national. Pourtant, en 2019, un arbitrage décide de son absorption dans mesdroitssociaux.gouv.fr et le service ferme définitivement en mars 2020.

Ce qui rend le cas instructif est que l’équipe de beta.gouv a elle-même choisi de classer Mes Aides parmi les services abandonnés, plutôt que de présenter son absorption comme une simple réussite. Sa fiche publique explique pourquoi : une petite équipe autonome laisse place à une organisation beaucoup plus complexe, le code ouvert du premier service n’a pas d’équivalent immédiat dans le second et les modes de développement diffèrent profondément. La critique est évidemment celle de l’ancienne équipe et doit être lue comme telle, mais beta.gouv a choisi de conserver publiquement ce post-mortem.

Ce cas permet de constater une première contradiction assez inconfortable :
l’État peut parvenir à créer autour d’un produit les conditions exceptionnelles permettant à une petite équipe de travailler autrement, puis rencontrer beaucoup plus de difficultés lorsqu’il faut réintégrer cette exception dans son fonctionnement ordinaire.

Ce problème n’appartient d’ailleurs pas seulement au passé. La question de la transmission reste actuelle. En 2025, Mes Aides Réno, autre produit développé selon la méthode Startup d’État, a été transféré à l’ANAH (Agence Nationale de l’Habitat). Sa fiche beta.gouv précise très ouvertement que le logiciel a été repris, mais sans l’équipe et sans reprise de l’organisation produit. Le service continue donc d’exister mais la manière de travailler qui l’a fait naître, elle, ne suit pas nécessairement le même chemin.

C’est à mes yeux une nuance essentielle, pour juger les réussites du numérique public.
Faire survivre le logiciel n’est pas exactement la même chose que préserver la capacité à continuer de l’améliorer.

Mesurer, corriger, parfois renoncer

Il faudrait cependant se méfier de l’excès inverse. Accepter l’échec fait partie de cette culture d’expérimentation. Encore faut-il ne pas transformer chaque projet arrêté en preuve que le système fonctionne parfaitement. La méthode beta.gouv repose précisément sur la possibilité de constater qu’une hypothèse ne fonctionne pas et d’arrêter de la financer. Cela signifie aussi qu’il existe de véritables échecs.

La Bonne Rénov’ est un bon exemple : après quelques mois d’expérimentation, son financement n’est pas renouvelé en avril 2023. L’équipe indique publiquement avoir rencontré des difficultés pour acquérir des utilisateurs, observé un taux de rebond important et obtenu des résultats insuffisants au regard du temps et de l’argent investis. Le service ferme quelques semaines plus tard.

La Cour des comptes retrouve cette réalité à une échelle plus large. Parmi les Startups d’État arrêtées dont elle a pu identifier la cause, 19 % l’ont été en raison de résultats ou d’un impact insuffisants. D’autres disparaissent à la suite d’un changement de priorité, du départ d’un intrapreneur ou parce qu’une autre solution finit par les remplacer.

À nouveau, le droit à l’échec ne doit donc pas devenir une manière de nier l’échec.

Sa véritable différence se situe peut-être ailleurs : permettre de constater suffisamment tôt qu’une solution ne produit pas les résultats espérés, arrêter d’y investir et accepter d’essayer autre chose. Cela peut sembler évident mais dans les grandes organisations, ça ne l’est pas forcément. Plus un projet a mobilisé de temps, de personnes et de budget, plus il devient difficile d’admettre que poursuivre n’améliorera rien.

Quand la méthode cherche à passer à l’échelle

Une autre limite apparaît lorsqu’il faut appliquer ces méthodes à des systèmes d’information beaucoup plus vastes et plus anciens. Les Startups d’État ont démontré qu’il était possible de créer ponctuellement de petites équipes travaillant autrement. Mais peut-on appliquer cette logique non plus à quelques nouveaux services, mais à un système d’information historique composé de centaines d’applications, de milliers de personnes et de décennies d’accumulation technique ?

Et bien France Travail tente actuellement cette expérience.

Son incubateur existe depuis 2015 et a produit plusieurs services devenus importants. L’établissement cherche désormais à étendre certaines de ces méthodes au-delà de l’incubateur en réorganisant progressivement son système d’information autour d’équipes produit, de chaînes de valeur et d’objectifs d’impact.

Le livre blanc public consacré aux incubateurs décrit cette transformation comme un passage à l’échelle de la méthode. Une partie des équipes de l’incubateur a ainsi rejoint une « Product and Design Office », aux côtés de membres de la DSI, pour accompagner les autres équipes. L’idée est toujours la même : livrer rapidement, observer le terrain, mesurer les résultats et réviser les investissements en conséquence.
Mais le document donne également une indication de ce que cela implique concrètement : à partir d’octobre 2023, environ 30 % des budgets présentés dans les nouveaux comités produit n’ont pas été validés, tandis que d’autres l’ont été avec réserves. Les auteurs reconnaissent que cette nouvelle manière de décider bouscule fortement les habitudes des équipes et du management.

En 2025, France Travail indiquait poursuivre le déploiement de cette organisation, appelée à s’étendre progressivement : chaînes de valeur, budgets davantage discutés en fonction de l’impact attendu, équipes orientées produit.

Il faut donc résister ici encore à la tentation d’un récit trop simpliste. Le mode produit n’est pas une recette qu’il suffirait d’installer dans une grande administration pour la transformer. Il modifie la répartition des budgets, des responsabilités et parfois du pouvoir. Des méthodes conçues dans de petites équipes doivent composer avec la sécurité, la dette technique, la continuité de service, les fonctions transversales et des systèmes que l’on ne peut évidemment pas arrêter six mois pour repartir de zéro.

L’enjeu n’est donc pas de transformer l’administration en startup, mais de comprendre ce qu’elle peut réellement reprendre de ces méthodes sans perdre ses propres contraintes ni ses responsabilités.
Qu’en est-il du passage à l’échelle ? Et l’administration peut-elle intégrer cette méthode sans la neutraliser, et jusqu’où est-elle prête à faire évoluer ses propres règles pour lui permettre de durer ?

2019 : une rupture devient visible

Cette difficulté à institutionnaliser une culture nouvelle ne se manifeste pas seulement à travers les produits. À partir de 2019, elle apparaît également au sein de la DINSIC elle-même et plusieurs départs deviennent publics.

En février 2019, Christian Quest, figure d’OpenStreetMap France et membre d’Etalab, remet sa démission. Dans une lettre rapportée par Next, il critique la nouvelle feuille de route de Nadi Bou Hanna, qu’il qualifie d’« utilitariste et court-termiste », et explique ne quasiment plus y retrouver les valeurs qui l’avaient conduit à rejoindre Etalab.

Quelques mois plus tard, en octobre, Hela Ghariani, Pierre Pezziardi et Ivan Collombet, trois acteurs historiques de beta.gouv, annoncent eux aussi leur départ. Leur désaccord est cette fois explicitement politique. Ils avaient proposé de donner davantage d’autonomie au dispositif à travers un « accélérateur de politiques publiques » mais le gouvernement ne retient pas cette proposition et ils estiment que l’exécutif a choisi le statu quo. Leur témoignage éclaire une partie du conflit, mais pas l’ensemble.

La nouvelle direction défend alors une autre préoccupation : une structure financée par l’État peut-elle durablement laisser une place aussi importante à des prestataires extérieurs dans son fonctionnement et son pilotage ? Acteurs Publics décrit précisément ce conflit autour de la gouvernance de beta.gouv. Les animateurs historiques craignent une bureaucratisation de l’incubateur ; la nouvelle direction souhaite au contraire réinternaliser davantage de responsabilités et remettre la structure sous un pilotage administratif plus classique.

Ce n’est pas seulement une opposition entre ceux qui voudraient avancer et ceux qui voudraient empêcher le changement. Deux problèmes légitimes entrent ici en tension : préserver suffisamment d’autonomie pour permettre l’expérimentation, tout en garantissant qu’une politique publique reste réellement maîtrisée par l’État.

Ce conflit de gouvernance va progressivement se doubler d’une crise plus profonde.

Une période de forte instabilité

En décembre 2021, Le Monde publie une enquête fondée sur les témoignages de plus de vingt agents ou anciens agents de la DINUM. Plusieurs décrivent une importante dégradation des conditions de travail, une perte de sens et un management qu’ils jugent brutal. Laurent Bossavit, spécialiste historique des méthodes agiles passé par la DINUM, est le seul à accepter de témoigner publiquement sous son nom.

Nadi Bou Hanna conteste fermement ce témoignage. Il évoque des tentatives de déstabilisation, souligne que les arrêts maladie restent, selon ses chiffres, inférieurs à ceux observés dans la fonction publique et rappelle que plusieurs mesures ont été prises après les alertes internes. Son droit de réponse sera publié dans le même article.

Mais le rapport publié par la Cour des comptes en 2024 permet au moins de constater objectivement une très forte rotation des équipes pendant cette période. Entre 2019 et 2022, le taux de rotation annuel moyen est élevé ; en 2021, les sorties représentent 43 % des effectifs présents au début de l’année lorsque les contrats courts sont intégrés. La Cour des comptes relève également plusieurs saisines de la mission chargée des situations de souffrance au travail dans les services du Premier ministre.

Ces données ne prouvent évidemment aucune accusation individuelle. Elles montrent en revanche qu’il s’est bien produit quelque chose de suffisamment important pour dépasser le cadre de quelques mécontentements isolés.

Laurent Bossavit donnera d’ailleurs sa propre lecture de cette période après son départ. Dans une tribune publiée en 2022, il estime qu’entre 2019 et 2021 la DINUM a perdu plusieurs personnes ayant joué un rôle moteur dans la transformation précédente et reproche à la nouvelle organisation d’avoir découragé certaines initiatives qui ne découlaient pas directement d’une commande politique. C’est son analyse personnelle, mais elle apporte un témoignage public particulièrement intéressant sur ce changement de culture.

Le parcours de Christian Quest apporte toutefois un contrepoint intéressant à cette période. Après son départ de la DINSIC en 2019, il revient chez Etalab en 2021 pour travailler sur un sujet qu’il défend depuis plusieurs années : les géocommuns. L’année suivante, il participe au lancement de Panoramax, développé par l’IGN avec OpenStreetMap France, et en devient l’un des pilotes. La suite donne une autre dimension à ce retour. En quelques années, Panoramax est passé de l’expérimentation à une infrastructure rassemblant plus d’une centaine de millions de photographies de terrain, utilisée notamment par des collectivités, des organismes publics et des entreprises.
En 2026, la DINUM le présente elle-même comme un « modèle de succès » des communs numériques. Le parcours de Christian Quest rappelle ainsi que cette culture ne disparaît pas nécessairement avec les départs : elle peut circuler dans l’État, trouver ailleurs les conditions pour se développer et finir par produire des projets qui passent réellement à l’échelle.

TECH.GOUV : les difficultés du passage à une nouvelle organisation

Cette période correspond à la mise en place de TECH.GOUV, la grande stratégie de transformation numérique lancée en 2019.
L’ambition est considérable : organiser la transformation numérique de l’État autour de plusieurs grandes missions communes. Mais quatre ans plus tard, la Cour des comptes en tire un bilan sévère : Son organisation matricielle aurait créé des redondances et des incompréhensions, y compris à l’intérieur de la DINUM. La mission DATA de TECH.GOUV recouvrait ainsi en partie les fonctions déjà exercées par Etalab.

Mais ces chevauchements organisationnels ne racontent peut-être qu’une partie de l’histoire. Les années précédentes avaient aussi fait entrer à la DINUM des profils auxquels on avait donné, ou qui avaient progressivement conquis, une autonomie inhabituelle dans l’administration : la possibilité de porter un produit, de prendre des décisions et d’en assumer directement la responsabilité.

On peut alors faire une autre lecture des nombreux départs qui ont accompagné cette période. Si TECH.GOUV a été perçu comme une reconcentration du pilotage et de la décision, certains de ceux qui étaient précisément venus chercher cet espace de responsabilité ont pu avoir le sentiment de le perdre. Il serait évidemment excessif d’en faire la cause exclusive des départs. Mais on peut aussi y voir un paradoxe : ceux que la DINUM avait attirés pour transformer les méthodes de l’État étaient peut-être les moins disposés à retrouver les formes d’organisation dont cette transformation cherchait justement à s’affranchir.

À l’été 2021, un épisode particulièrement inhabituel illustre les tensions internes. Nadi Bou Hanna propose aux agents de se prononcer dans ce qui est présenté comme un « vote de confiance » envers sa vision et sa direction. La Cour des comptes indique que la démarche est jugée « inconvenante » par les autorités et les organisations syndicales. Elle est finalement retirée.

Puis Nadi Bou Hanna quitte ses fonctions en janvier 2022 et le projet TECH.GOUV s’interrompt pratiquement avec son départ.

Le départ de Nadi Bou Hanna ne suffit évidemment pas à expliquer l’arrêt du projet. Mais le fait que le programme s’essouffle presque au même moment révèle une fragilité plus profonde : la stratégie n’avait pas suffisamment trouvé de relais dans les administrations qu’elle devait entraîner.

C’est aussi ce que pointe la Cour des comptes lorsqu’elle souligne sa faible appropriation. TECH.GOUV avait bien produit un cadre commun, des missions, des objectifs et des indicateurs, mais ce cadre n’était pas devenu pour autant une manière de travailler suffisamment partagée pour continuer naturellement après le changement de direction.

Il y a peut-être, derrière cet épisode, une tension plus fondamentale encore. L’État fonctionne historiquement par hiérarchies, chaînes de décision et responsabilités distribuées du sommet vers la base. Or la fabrication de services numériques s’accommode souvent mal de cette verticalité : elle repose davantage sur des équipes capables de décider au plus près du produit, d’expérimenter, de corriger et surtout d’être réellement responsables de ce qu’elles construisent.

Finalement, la difficulté de la nouvelle organisation portée par Nadi Bou Hanna n’aurait donc pas seulement tenu à l’ambition de donner davantage de cohérence à la transformation numérique de l’État. Elle aurait aussi résidé dans le choix d’un pilotage plus centralisé, alors que les années précédentes avaient justement montré ce que l’autonomie et la responsabilité laissées aux équipes pouvaient produire.

Alors, pourquoi tant de haine ?

Après ce détour par l’histoire, la formule entendue à plusieurs reprises ces derniers mois devient peut-être un peu plus compréhensible. Pourquoi la DINUM cristallise-t-elle autant de critiques ? Probablement parce qu’elle se trouve au croisement de plusieurs tensions que l’État n’a jamais complètement résolues. Elle doit coordonner des ministères qui tiennent à leur autonomie, développer des capacités internes tout en travaillant avec des prestataires, encourager l’expérimentation sans échapper aux règles de l’administration, produire certains outils tout en laissant une place aux éditeurs privés, construire des communs sans devenir pour autant l’opérateur de tout le numérique public.

À cela s’ajoute une difficulté plus profonde : chacun semble attendre d’elle quelque chose de différent. Certains lui reprochent d’aller trop loin lorsqu’elle développe ses propres solutions, d’autres de ne pas aller assez loin face aux dépendances technologiques. Certains voudraient qu’elle fixe davantage de règles, d’autres qu’elle laisse davantage d’autonomie à ceux qui construisent. Et ses propres réussites rendent parfois ses échecs, ses lenteurs ou ses changements de cap encore plus visibles.
Au fond, ce « pourquoi tant de haine ? » révèle peut-être moins un problème propre à la DINUM qu’une contradiction presque structurelle : on lui demande de transformer un système dont elle ne possède ni tous les leviers, ni tous les moyens, ni toujours le dernier mot.

La difficulté n’est pas seulement de discerner les transformations nécessaires, mais de parvenir à les inscrire dans une organisation dont les règles, les habitudes et les centres de décision résistent au mouvement. Sur ce terrain, les pages de Marc Bloch résonnent encore avec une étonnante actualité.

Ce que Marc Bloch nous dit encore

Il faut en revenir à nouveau à L’Étrange Défaite avec la même précaution qu’au début de cette longue réflexion : il ne s’agit évidemment pas de comparer la France de 2026 à celle de 1940, ni la dépendance numérique à une défaite militaire (même si l’on évoque régulièrement les expressions colonisation numérique et protectorat numérique).
Marc Bloch décrit avec une grande précision ce qui arrive lorsqu’une organisation continue de raisonner avec des méthodes devenues inadaptées à un monde qui a changé.
Lorsqu’il écrit que les chefs français « n’ont pas su penser cette guerre », il ne leur reproche pas seulement des erreurs techniques : il décrit un commandement qui raisonne encore avec les cadres du passé, accorde trop de confiance aux scénarios préparés sur le papier et peine à improviser lorsque le réel s’en écarte. Bloch distingue également avec beaucoup de finesse, l’« ordre statique du bureau » de la capacité d’organisation qu’exige l’action. Il ne condamne pas le premier, il écrit même que les deux formes d’ordre ne s’excluent pas.
Son avertissement est plus subtil : la procédure, la discipline et l’organisation administrative ne produisent pas, à elles seules, la faculté de comprendre une situation nouvelle et d’y répondre.

Huit mois pour ne pas recommencer

Un autre passage de L’Étrange Défaite résonne ici avec une précision presque troublante, à condition, là encore, de ne pas trop forcer le parallèle. Revenant sur la campagne de Pologne et sur les mois qui précèdent l’offensive allemande à l’Ouest, Bloch écrit : « Ils nous firent le cadeau de huit mois d’attente, qui auraient pu être aussi de réflexion et de réforme. Nous n’en avons pas profité. » Son propos est très concret : les responsables militaires disposaient d’informations, d’un précédent observable et surtout de temps pour adapter leurs méthodes. Ce qui lui importe n’est pas l’absence d’avertissements, mais l’incapacité à transformer ces avertissements en changements suffisamment rapides.

À l’heure où j’écris ces lignes, moins de huit mois nous séparent de l’échéance présidentielle de 2027. La coïncidence du chiffre n’a évidemment aucune valeur historique ; la question du temps disponible, elle, mérite d’être posée. Car nous ne manquons plus vraiment de diagnostics.

Si comprends, un observatoire, qui va observer (donc ne rien faire) pendant genre 1-2 ans, puis rendre un rapport, publier un avis, que sais-je. C'est bien, d'observer. Mais ça peut signifier ne rien faire pendant 2 ans.
L'art de ne pas traiter un problème. https://t.co/tu6rKRlK4D

— Benjamin Bayart (@bayartb) 27 janvier 2026

Les dépendances ont été cartographiées, leurs conséquences économiques et stratégiques largement documentées, et les pistes d’action commencent à converger : renforcer les compétences internes, développer les logiciels libres et les standards ouverts, financer les communs numériques, organiser les migrations et porter cette politique à l’échelle européenne. Le rapport de la commission d’enquête de l’Assemblée nationale va jusqu’à proposer la création d’une fondation consacrée au libre et d’un fonds de financement des communs numériques.

Autorité, capacité, responsabilité : qui peut réellement agir ?

C’est aussi l’un des avertissements que je retiens des analyses d’Alexandre Berge sur la création d’Ariane. Il faut d’abord corriger une interprétation que j’avais moi-même faite trop rapidement à propos du Plan Calcul. Alexandre Berge ne dit pas que son échec serait venu de la nomination d’un militaire par Valéry Giscard d’Estaing. Il rappelle au contraire que Robert Galley et Maurice Allègre, les deux premiers responsables de la délégation à l’informatique, ne venaient pas du corps de l’armement. Surtout, il insiste sur une autre leçon : le Plan Calcul n’a pas seulement buté sur des questions techniques ; sa trajectoire a été interrompue par une décision politique, avec l’abandon par Valéry Giscard d’Estaing de la stratégie précédente et du projet européen Unidata.
Une capacité industrielle peut mettre des années à se construire et disparaître beaucoup plus vite lorsqu’elle ne survit pas aux alternances politiques.
Son second avertissement concerne Ariane elle-même. Après les crises de cybersécurité de 2026, l’État a choisi de renforcer son pouvoir de coordination et de contrôle.
La logique se comprend. Mais Alexandre Berge relève le risque de répondre à une faiblesse de capacités, de compétences, d’infrastructures, et de maîtrise technique principalement par davantage de normes, de procédures et de pouvoirs administratifs. C’est ce qu’il analyse, en s’appuyant sur les travaux de Béatrice Hibou, comme un processus de bureaucratisation.
En août 2026, Ariane n’existait d’ailleurs toujours pas juridiquement comme nouvelle autorité : Walter Arnaud dirige encore la DINUM tout en préparant sa transformation annoncée pour 2027.

Le choix auquel l’État est confronté ne devrait pourtant pas opposer ces deux dimensions.
Il faut de l’autorité pour fixer une direction, mais il faut aussi la capacité de construire, de maintenir, d’expérimenter et de faire travailler ensemble ceux qui savent faire.

L’histoire récente de Visio en donne un exemple assez parlant. Lorsqu’il rejoint la DINUM, fin 2023, Samuel Paccoud ne raconte pas avoir reçu pour mission de créer un nouvel outil de visioconférence. Il rejoint alors l’équipe chargée de transformer un ensemble d’outils déjà existants en un véritable environnement numérique de travail, au moment où la DINUM cherche précisément à rationaliser et rénover son offre interministérielle.
Jitsi et BigBlueButton sont alors déjà utilisés par l’État, mais en explorant une autre voie autour de LiveKit, Samuel prend l’initiative de faire réaliser un premier prototype par trois étudiants de CentraleSupélec pendant sept semaines, puis décide d’affecter un développeur au projet.

La suite est assez révélatrice : ce qui n’était pas une commande initiale devient, moins de deux ans plus tard, la solution que l’État décide de généraliser à l’ensemble de ses services.

Visio illustre ainsi une dimension parfois oubliée de la capacité d’action : disposer des compétences nécessaires compte, mais leur laisser suffisamment d’autonomie pour explorer une piste qui n’était pas prévue au départ peut compter tout autant.

En mars 2026, lors d’un séminaire de l’École de Paris du management, Pierre Pezziardi revient lui-même sur les conditions dans lesquelles LaSuite s’est développée. Il place au premier rang l’autonomie, la maîtrise et le sens du travail, et choisit précisément Visio pour illustrer cette manière de travailler : Stéphanie Schaer et lui avaient, explique-t-il, prévu et voulu Docs, mais pas Visio. L’initiative est venue de l’équipe avant que l’outil ne soit finalement retenu puis généralisé par l’État. Ce témoignage apporte un éclairage complémentaire sur cette réussite : l’autonomie n’apparaît plus seulement comme une liberté laissée ponctuellement à Samuel Paccoud, mais comme l’un des principes d’organisation revendiqués par ceux qui ont construit LaSuite.

Mais à l’autonomie doit répondre une autre notion : la responsabilité. Non pas celle que l’on invoque après coup pour rechercher à qui imputer un échec, mais celle qui consiste à pouvoir agir et à répondre de ce que l’on fait.

Dans l’article « travail réel, travail prescrit« , les auteurs expliquent que les processus doivent appartenir à ceux qui les mettent en œuvre et que ceux-ci doivent avoir « autorité et responsabilité » pour les modifier et les adapter en permanence au réel. L’autonomie prend alors un sens beaucoup plus exigeant : elle ne consiste pas seulement à laisser faire, mais à rapprocher la décision, les moyens d’agir et la responsabilité de ceux qui sont effectivement confrontés au problème. À l’inverse, lorsque la décision se disperse entre plusieurs directions, niveaux hiérarchiques, comités ou structures, ces trois dimensions peuvent finir par se séparer. Certains savent ce qu’il faudrait faire sans avoir le pouvoir de le décider ; d’autres possèdent l’autorité formelle mais sont plus éloignés du terrain et la responsabilité du résultat finit par se répartir entre suffisamment d’acteurs pour que l’on ne sache plus très bien qui pouvait réellement agir. C’est, sous une autre forme, le phénomène de dilution de la responsabilité décrit depuis longtemps en psychologie sociale : lorsque chacun ne détient qu’une fraction de la responsabilité, il devient plus facile d’attendre que l’action vienne d’un autre.

Les évolutions engagées depuis l’arrivée de Walter Arnaud rendent cette question de responsabilité particulièrement prégnante. Les débats apparus en 2026 autour de la cybersécurité de l’État montrent bien que multiplier les structures ne suffit pas nécessairement à augmenter sa capacité d’action. Après les attaques qui ont touché plusieurs administrations, Franceinfo rapporte précisément cette interrogation : plutôt qu’un nouvel étage dans un paysage institutionnel déjà complexe, certains spécialistes réclament surtout davantage de pouvoirs pour les acteurs existants et la possibilité d’imposer effectivement les mesures nécessaires.

La question n’est donc peut-être pas tant de savoir qui possède l’autorité que de savoir qui dispose réellement du pouvoir d’agir, et qui, en retour, en assume la responsabilité.

L’histoire que j’ai tenté de reconstituer et d’interpréter, montre justement ce que la DINUM a parfois réussi lorsque autorité, capacité d’agir et responsabilité ont pu être réunies au même endroit, et ce qui a pu se produire lorsqu’elles se sont éloignées.

Cette « Génération LaSuite » a peut-être fonctionné parce que certaines équipes n’ont pas seulement reçu des instructions : elles ont surtout disposé de suffisamment de liberté pour décider, et de suffisamment de responsabilité pour assumer ce qu’elles construisaient.

Cette articulation entre autorité, capacité et responsabilité conduit alors à une autre question : comment la reproduire à l’échelle européenne sans recentraliser la décision ni recréer, un étage plus haut, les lourdeurs que l’on cherche précisément à dépasser ?
L’enjeu ne serait plus seulement de donner à l’Europe davantage de pouvoir numérique, mais d’organiser ce pouvoir de manière à ce que la capacité d’agir et la responsabilité restent aussi proches que possible de ceux qui construisent, opèrent et améliorent réellement les services.

Une fondation pour changer d’échelle

Plutôt que de faire de LaSuite un produit français qu’il faudrait ensuite tenter d’exporter, pourquoi ne pas aller jusqu’au bout de sa logique de commun et confier progressivement la gouvernance de ses briques ouvertes à une fondation européenne indépendante ?

La souveraineté ne peut d’ailleurs pas être étrangère à une certaine idée de grandeur. Non pas celle de la domination, de la prédation ou de la construction d’un nouvel empire, mais celle de l’ambition, de la puissance d’agir et de l’échelle. Face à des acteurs qui pensent et construisent leurs services pour le monde entier, l’Europe doit elle aussi porter un projet de rang mondial : soit elle se donne les moyens de construire à cette échelle, soit elle continuera d’adopter, d’acheter et de subir des infrastructures conçues ailleurs.

La puissance européenne ne doit pas devenir une imitation des puissances impériales : l’Europe n’est pas issue d’un projet impérial, elle doit définir son propre modèle de puissance, sans imitation et en résistant aux idéologies prédatrices. La puissance n’est pas incompatible avec le projet européen, mais peut au contraire en être une condition

Cette distinction entre puissance et impérialisme était également au cœur de l’intervention du sénateur Raphaël Daubet lors d’un débat consacré aux réponses de l’Union européenne face au retour des impérialismes, en février 2026.

La France pourrait en être l’initiatrice sans en être propriétaire. Les États européens, les institutions de l’Union, les éditeurs, les entreprises utilisatrices, les communautés du libre et la société civile pourraient y disposer d’une place clairement définie. L’État français continuerait naturellement à opérer LaSuite pour ses agents ; d’autres administrations ou entreprises pourraient exploiter leurs propres instances. Mais le code commun, sa feuille de route et les règles de contribution ne dépendraient plus d’un ministère, d’un gouvernement ou d’un seul acteur économique.

Ce mouvement a d’ailleurs déjà commencé sans attendre une telle structure. mosa.cloud construit une offre commerciale à partir de LaSuite aux Pays-Bas ; LaSuite.coop propose elle aussi des services basés notamment sur Docs, Fichiers et Visio et vient d’ouvrir sa gouvernance à ses sociétaires. Ces initiatives ne sont pas des concurrentes du projet public : elles sont précisément ce que permet un commun lorsqu’il commence à dépasser son créateur.

Une telle fondation permettrait également de répondre à une partie des critiques adressées à la DINUM par les éditeurs. L’État n’aurait plus à choisir entre tout construire lui-même et tout acheter au marché. Il pourrait financer et contribuer à un socle commun, tandis que plusieurs entreprises construiraient autour de ce socle des services, du support, de l’intégration, de l’hébergement ou des fonctionnalités complémentaires.

Cette articulation entre infrastructure publique et écosystème privé rejoint d’ailleurs une question soulevée par Alexandre Berge à propos de LaSuite. En revenant sur le précédent du kiosque Minitel, il rappelle qu’une infrastructure publique ne suffit pas, à elle seule, à faire émerger un écosystème : encore faut-il organiser les conditions dans lesquelles des acteurs privés peuvent s’y raccorder et créer de la valeur autour d’elle. Le Minitel ne reposait pas seulement sur une infrastructure construite par la puissance publique, il y avait un véritable régime d’accès et de rémunération qui permettait aux éditeurs de proposer leurs propres services. La comparaison a évidemment ses limites, mais elle fait apparaître un angle mort intéressant pour LaSuite : ouvrir le code et garantir l’interopérabilité ne suffisent peut-être pas si les règles permettant à un écosystème économique de se construire autour de ce socle restent indéterminées. Une fondation européenne pourrait précisément contribuer à définir durablement ces règles du jeu, sans que celles-ci dépendent exclusivement de l’État français ni d’un acteur privé.

OpenBuro montre très bien pourquoi cette question de gouvernance est importante. Alexandre Berge à nouveau, relève que le projet revendique une future fondation neutre, mais qu’à la mi-2026 cette structure n’était pas encore juridiquement constituée. Son interrogation ne porte pas seulement sur la technique : si un standard doit être utilisé par plusieurs éditeurs concurrents, ceux-ci doivent pouvoir avoir confiance dans la manière dont il évolue. Une gouvernance réellement indépendante devient alors une condition de son adoption.

Cela éviterait aussi de refaire certains choix du passé. Cloudwatt et Numergy reposaient sur une autre logique : l’État avait investi avec des industriels désignés pour faire émerger des champions nationaux. Le résultat n’a pas produit l’écosystème espéré. Une fondation de communs suivrait une logique différente : ne pas choisir à l’avance le champion qui recevra l’argent, mais financer une infrastructure ouverte sur laquelle plusieurs acteurs peuvent ensuite construire et se concurrencer.

Le DC-EDIC (Consortium européen pour une infrastructure numérique) pourrait alors jouer un rôle complémentaire. Et je ne pense pas que cela soit une énième « coquille juridique ». Il possède déjà une assemblée des États membres, un directeur, et dispose par ailleurs d’une capacité à définir une stratégie commune. Quant à ses statuts, ils prévoient aussi un conseil consultatif, actuellement en cours de constitution, dont les membres doivent être nommés en novembre 2026.

Une fondation n’aurait donc pas vocation à se substituer à cette infrastructure.
Elle pourrait constituer le niveau opérationnel et communautaire qui lui manque nécessairement : celui où le code est maintenu, où les éditeurs travaillent ensemble, où les choix techniques sont arbitrés et où les contributions privées et publiques peuvent être organisées dans la durée.

EuroCommons apporte encore une autre pièce du puzzle. La Caisse des Dépôts organise déjà des coalitions de DSI, d’éditeurs et de contributeurs pour financer les développements manquants et préparer des migrations communes. Bpifrance, les grands groupes français et européens, mais aussi leurs équivalents allemands, néerlandais, espagnols ou italiens pourraient rejoindre cette dynamique. La logique serait moins celle de la subvention que celle du co-investissement dans des outils dont tous ont besoin.

Allez chiche @Xavier75 on migre de Zimbra à Messagerie de #LaSuite @Numerique_Gouv et on offre aux abonnés un accès à Visio, Docs, Grist, Fichiers, on met de l'IA avec @MistralAI et on migre Free Transfert par la solution de la DINUM Francetransfert. Et @free devient le premier…

— Souverain (@Souverain_ovh) 20 juillet 2026

Ne serait-ce pas là l’un des angles morts que les directions successives et les ministres chargés du numérique n’ont jamais pleinement pris en compte ?
Walter Arnaud ne se trouve-t-il pas aujourd’hui à un tournant historique décisif, face à une occasion rare de marquer durablement, par son passage à la DINUM, le paysage numérique français et européen ?
L’enjeu ne serait alors pas de repartir une nouvelle fois de zéro, mais de regarder froidement ce que quinze années de DISIC, DINSIC puis DINUM ont produit : les échecs, les conflits, les changements de stratégie, mais aussi Etalab, beta.gouv, FranceConnect, les API, les communs numériques et désormais LaSuite.

Ariane peut apporter davantage d’autorité au numérique de l’État. Elle ne devrait pas perdre, en échange, la capacité d’expérimentation et d’ouverture qui a permis à ces projets d’exister.

L’article Génération LaSuite est apparu en premier sur Souverain.

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.

Contexte : qui a produit ce rapport ?

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

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

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

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

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

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

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

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

1. Définir la souveraineté numérique

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Les solutions proposées

7. Les erreurs à éviter

Le rapport identifie plusieurs pièges.

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

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

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

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

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

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

9. Assurer la durabilité juridique et financière

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

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

10. Passer à l’échelle européenne

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

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

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

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

Conclusion

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

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

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

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

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

Concrètement, le rapport dit trois choses.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Trois objectifs : résilience, marché, transparence

Les signataires de la lettre ouverte avancent trois objectifs majeurs.

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

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

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

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

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

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

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

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

On y retrouve notamment :

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

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

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

Cristina Caffarra et la question décisive de la demande

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

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

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

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

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

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

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

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

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

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

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

La formation, condition cachée de la bascule

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

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

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

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

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

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

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

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

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

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

Ce serait déjà un changement profond.

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

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

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

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

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

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

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

Elle se joue aussi dans les choix techniques et contractuels. Lorsqu’une administration devient dépendante d’un prestataire privé, d’un logiciel fermé, d’un cloud difficile à quitter ou d’un format de données peu réutilisable, le problème dépasse la simple question technique. Il touche au coût du service public, à la capacité de changer de fournisseur, à la maîtrise des données et, plus largement, à l’indépendance des décisions de l’État.

Les données des citoyens ne sont pas une matière première ordinaire. Elles peuvent dire quelque chose de notre santé, de notre situation familiale, de nos revenus, de nos déplacements, de nos droits ou de nos fragilités. Leur protection ne relève donc pas seulement de la cybersécurité : elle engage la confiance démocratique. Un citoyen ou une citoyenne doit pouvoir savoir qui utilise ses données, dans quel but, sous quelle législation, avec quelles garanties et avec quels recours en cas d’erreur ou d’abus.

La souveraineté numérique concerne aussi les logiciels, les standards, les contrats, l’interopérabilité, la portabilité des données, les compétences internes de l’administration, les audits indépendants, la possibilité de contester une décision automatisée et la capacité de l’État à corriger ses propres systèmes. Avec l’arrivée de l’intelligence artificielle dans certains services publics, cette question devient encore plus sensible : lorsqu’un algorithme contribue à une décision administrative importante, l’explication, le contrôle humain et le droit au recours ne sont pas des détails techniques, mais des garanties démocratiques.

Au fond, la souveraineté numérique pose une question simple : un État peut-il encore garantir des services publics fiables, accessibles et protecteurs s’il ne maîtrise ni ses outils, ni ses données, ni ses prestataires, ni les règles techniques qui organisent l’accès aux droits ? À sa manière, ce rapport confirme qu’au-delà des principes politiques, la souveraineté numérique implique des actions concrètes et se joue également dans des choix pragmatiques, souvent invisibles pour les citoyens. Cette transformation doit aussi être évaluée au regard de sa capacité à rester maîtrisable, transparente, inclusive et responsable dans le temps.

Numériser ne suffit pas à améliorer le service public

La numérisation des services publics peut être très utile. Elle peut simplifier des démarches, réduire les lourdeurs administratives, éviter des déplacements inutiles, accélérer certains traitements et améliorer l’accès à l’information. Le rapport reconnaît cette promesse : bien encadrées, les technologies publiques peuvent améliorer la qualité des services, réduire les charges administratives et élargir l’accès aux services publics.

Mais le rapport insiste aussi sur l’autre versant du sujet. Une numérisation mal pensée peut produire exactement l’inverse : exclure les publics les plus fragiles, rendre les décisions plus opaques, renforcer la dépendance à des fournisseurs privés et affaiblir la confiance dans l’État. Le problème ne vient donc pas seulement de la technologie elle-même, mais de la manière dont elle est conçue, gouvernée, contrôlée et corrigée dans le temps.

En clair : un service public en ligne n’est pas automatiquement un meilleur service public. Tout dépend de la capacité de l’État à garder la maîtrise de ses choix techniques, de ses données, de ses prestataires, de ses règles de contrôle et de ses voies de recours.

C’est précisément là que la souveraineté numérique entre dans le débat.

Les principes directement liés à la souveraineté numérique

1. Éviter la dépendance aux fournisseurs privés

Le principe 4 du rapport est probablement le plus directement lié à la souveraineté numérique. Il affirme que les technologies publiques et les infrastructures numériques doivent créer de la valeur pour la société, et non extraire cette valeur au profit d’acteurs qui finiraient par contrôler les systèmes essentiels.

Le rapport met en garde contre plusieurs risques très concrets : le verrouillage fournisseur, la dépendance technique, la perte de souveraineté, la monétisation des données citoyennes et la perte de contrôle sur des infrastructures critiques.

Le verrouillage fournisseur, ou vendor lock-in, désigne une situation simple à comprendre : une administration choisit une solution, puis devient tellement dépendante de son prestataire qu’elle ne peut presque plus en sortir. Les données sont difficiles à récupérer, les formats ne sont pas ouverts, les contrats sont rigides, les compétences internes ont disparu, et chaque changement devient coûteux.

Dans un service public, ce risque est majeur. Il ne concerne pas seulement le prix d’un logiciel. Il concerne la capacité de l’État à changer de trajectoire, à migrer vers une autre solution, à auditer un système, à corriger une erreur ou à reprendre la main en cas de conflit avec un fournisseur.

C’est pour cela que le rapport insiste sur les standards ouverts, les architectures interopérables, la portabilité des données, les contrats permettant la migration, les audits indépendants et les stratégies multi-fournisseurs.

Autrement dit, la souveraineté numérique ne se joue pas uniquement au moment où l’État achète une solution. Elle se joue aussi dans la capacité à en sortir.

2. Protéger les données des citoyens

Le principe 6 est encore plus explicite. Il parle de souveraineté des données citoyennes et affirme que les gouvernements doivent conserver une souveraineté numérique au niveau national, notamment en maintenant un contrôle stratégique sur les infrastructures critiques, les standards et l’évolution des systèmes dans le temps.

Ce passage est central. Il rappelle que les données publiques ne sont pas de simples informations techniques. Elles peuvent concerner l’identité, la santé, la fiscalité, les prestations sociales, les déplacements, les droits ou les situations personnelles des citoyens.

Le rapport recommande donc plusieurs garde-fous : des lois de protection des données, une supervision indépendante, des sanctions en cas d’abus, le stockage et le traitement des données sensibles sous juridiction nationale, le chiffrement, la limitation des accès, la traçabilité, ainsi que des stratégies de cloud sécurisé et souverain.

Derrière l’expression « cloud souverain », l’enjeu n’est pas seulement technique. Il ne s’agit pas seulement de savoir où se trouve physiquement un serveur. L’enjeu est aussi juridique, contractuel et opérationnel :

• qui contrôle l’infrastructure ?
• quelle loi s’applique ?
• qui peut accéder aux données ?
• l’État peut-il auditer le système ?
• peut-il migrer ailleurs ?
• peut-il garantir la continuité du service ?

Cette approche rejoint directement les débats européens sur la souveraineté numérique : la maîtrise des données n’a de sens que si elle s’accompagne d’une maîtrise des infrastructures, des règles d’accès, des prestataires et des capacités internes.

Contrôle, résilience, audit : les autres visages de la souveraineté numérique

3. Auditer, expliquer et contester les décisions numériques

Le principe 5 ne parle pas de souveraineté au sens industriel du terme. Il parle de transparence, de responsabilité et de confiance. Mais il touche à un point essentiel : lorsqu’un algorithme intervient dans une décision administrative importante, l’enjeu n’est pas seulement technique. Le citoyen doit pouvoir comprendre la décision, la contester, obtenir une révision humaine et savoir qui en porte la responsabilité.

Le rapport explique que les systèmes publics doivent être explicables, auditables et gouvernés par l’État de droit. Il recommande des mécanismes de contrôle pour l’usage des données et de l’IA, des traces d’audit pour les décisions automatisées, des exigences d’explicabilité, des recours humains et des mécanismes de correction lorsque des décisions importantes affectent les droits des citoyens.

Ce point est fondamental. Lorsqu’un algorithme participe à une décision sur une aide sociale, une allocation, un contrôle, une orientation administrative ou un accès à un droit, la souveraineté ne signifie pas seulement héberger les données chez soi. Elle signifie aussi : pouvoir comprendre comment la décision a été produite, pouvoir la contester, pouvoir identifier une erreur, pouvoir suspendre un système problématique.

C’est une souveraineté démocratique autant que technique.

4. Refuser le numérique pour le numérique

Le principe 7 critique une tentation bien connue : celle du tout-numérique. Autrement dit, l’idée qu’une nouvelle plateforme, une nouvelle application ou un nouvel outil technique serait nécessairement la meilleure réponse à un problème administratif. Le rapport invite au contraire à une approche plus sobre : réutiliser ce qui existe, simplifier les démarches avant de les numériser, conserver des alternatives lorsque c’est nécessaire et éviter d’ajouter de nouvelles couches techniques à des systèmes déjà complexes.

Ce principe est fortement lié à la souveraineté numérique, car l’empilement de plateformes, de logiciels et de prestataires crée souvent une dépendance par la complexité. Plus l’État multiplie les systèmes fermés, mal documentés et peu interopérables, plus il devient difficile de les maintenir, de les faire communiquer ou de les remplacer.

La souveraineté numérique demande souvent de bâtir. Mais elle demande aussi de savoir ne pas construire juste pour construire. Simplifier une procédure, supprimer une étape inutile, mutualiser une brique commune ou réutiliser une infrastructure existante peut être plus souverain que lancer une nouvelle plateforme.

Le rapport insiste notamment sur les architectures modulaires, les modèles d’interopérabilité et la réduction des systèmes spécifiques trop lourds.

5. Construire des systèmes résilients, pas des vitrines numériques

Le principe 8 insiste sur la résilience. Un service public numérique doit pouvoir évoluer, résister aux crises, être corrigé après un incident et continuer à fonctionner même en cas de panne. Le rapport parle de systèmes modulaires, sécurisés, adaptables, de gestion des incidents, de plans de secours et de réduction de la dette technique.

Cette idée rejoint directement la souveraineté numérique. Un État ne peut pas se dire souverain s’il ne sait pas maintenir ses propres systèmes, les réparer, les documenter, les sécuriser ou les faire évoluer. La dépendance ne vient pas seulement d’un fournisseur étranger. Elle peut aussi venir d’une perte de compétence interne, d’une documentation absente, d’un empilement technique devenu impossible à maîtriser.

La souveraineté numérique est donc aussi une capacité de maintenance. Ce sont des sujets peu visibles, mais ce sont eux qui déterminent si l’État garde réellement la main sur ses systèmes.

6. Mesurer les résultats réels

Le principe 9 rappelle qu’une politique numérique doit être évaluée. Le rapport recommande de définir des indicateurs avant le lancement, de publier des données de performance, de mesurer la qualité du service, d’analyser les réclamations, les recours et les erreurs, puis d’adapter les services en continu.

Ce principe est moins directement lié à la souveraineté numérique que les précédents, mais il joue un rôle utile. Beaucoup de projets numériques sont présentés comme des succès dès leur lancement. Mettre un service public en ligne ne suffit pas à en faire un progrès : encore faut-il regarder ce qu’il produit réellement. C’est-à-dire :

• les citoyens l’utilisent-ils ?
• les publics fragiles y accèdent-ils ?
• les erreurs diminuent-elles ?
• les délais baissent-ils ?
• les recours sont-ils traités ?
• le coût réel est-il maîtrisé ?

La souveraineté numérique suppose aussi une culture de l’évaluation : regarder ce que les services produisent réellement, corriger ce qui ne fonctionne pas et ne pas confondre lancement d’une plateforme avec réussite du service public.

7. Faire de la souveraineté un sujet de pilotage politique

Le principe 10 affirme que les projets GovTech ne sont pas seulement des projets techniques. Ce sont des transformations institutionnelles. Ils demandent un pilotage politique clair, des responsabilités identifiées, une coordination entre administrations, des budgets cohérents, une conduite du changement et des compétences internes.

Ce point est déterminant. La souveraineté numérique ne se décrète pas uniquement par de grands discours. Elle demande une administration capable de piloter ses choix techniques, de rédiger de bons contrats, d’éviter les dépendances, de conserver des compétences, de former ses agents et de coordonner ses décisions.

Sans pilotage, la souveraineté devient un mot posé sur des systèmes que personne ne maîtrise vraiment.

Ce que le Forum économique mondial disait déjà en 2025

Le lien avec l’article publié par le WEF en janvier 2025 (en anglais) est intéressant. Cet article, signé par Sean Fleming, expliquait que la souveraineté numérique dépasse la seule régulation des données. Elle inclut aussi l’innovation, le financement, les infrastructures, les logiciels, le matériel et les standards.

L’article définissait la souveraineté numérique comme la capacité à contrôler son « destin numérique » : les données, le matériel et les logiciels dont un pays dépend ou qu’il crée. Il rappelait aussi une grille de lecture en trois couches :

• la couche physique, c’est-à-dire les infrastructures et technologies
• la couche du code, c’est-à-dire les standards, les règles et le design
• et la couche des données, c’est-à-dire leur propriété, leurs flux et leurs usages.

Le texte de 2025 soulignait également que la souveraineté numérique est devenue un enjeu de compétition entre l’Union européenne, les États-Unis et la Chine. Il évoquait la concentration du pouvoir numérique dans un petit nombre d’entreprises, les débats sur le RGPD, l’AI Act, les transferts de données transatlantiques et le cloud souverain.

Là encore, une précision est nécessaire : l’article de 2025 précise que les avis exprimés sont ceux de l’auteur, et non nécessairement ceux du World Economic Forum. On peut donc rester prudent sur la portée exacte de ces textes, tout en constatant une continuité : la souveraineté numérique apparaît désormais comme un enjeu récurrent dans les réflexions portées autour du Forum économique mondial.

Les continuités entre 2025 et 2026

1. La souveraineté numérique reste une affaire de contrôle

En 2025, le FEM présentait la souveraineté numérique comme la capacité à contrôler les données, les logiciels, le matériel et les infrastructures dont on dépend. En 2026, le rapport applique cette logique aux services publics : il parle de contrôle stratégique sur les infrastructures critiques, les standards et l’évolution des systèmes publics dans le temps.

La continuité est nette : la souveraineté n’est pas réduite à la localisation des données. Elle concerne toute la chaîne technique et institutionnelle.

2. Les données restent au cœur du sujet

En 2025, l’article mettait en avant le rôle du RGPD et la capacité des citoyens européens à mieux contrôler l’usage de leurs données. En 2026, le rapport parle de souveraineté des données citoyennes, de protection juridique, de droit d’accès, de correction, de suppression, de limitation des usages et de supervision indépendante.

La logique se prolonge : la donnée citoyenne ne relève pas seulement de la gestion administrative. Elle engage la protection des personnes, l’exercice des droits et la confiance démocratique.

3. Le cloud souverain reste un point de friction majeur

En 2025, l’article présentait le cloud souverain comme un levier pour maintenir les données publiques dans un environnement technique et juridique maîtrisé. En 2026, le rapport prolonge cette logique en recommandant des stratégies de cloud sécurisé et souverain, afin de mieux protéger les données citoyennes, d’encadrer leur traitement et de garantir la continuité des services publics qui en dépendent.

La continuité est toujours présente : sans maîtrise du cloud, une partie de la souveraineté des services publics reste fragile.

4. La concentration du pouvoir numérique reste identifiée comme un problème

L’article de 2025 évoquait le sentiment, chez de nombreux décideurs publics, d’un pouvoir trop concentré entre les mains d’un petit nombre d’entreprises technologiques. En 2026, le rapport formule ce risque dans le langage de l’administration : verrouillage fournisseur, dépendance, perte de contrôle sur les infrastructures critiques, monétisation des données citoyennes.

Le vocabulaire change, mais le diagnostic reste proche.

5. L’IA reste un sujet de souveraineté démocratique

En 2025, l’article comparait les approches européenne, américaine et chinoise de la gouvernance de l’IA, en rappelant notamment l’approche européenne fondée sur les droits humains, les obligations de transparence et les systèmes à haut risque. En 2026, le rapport traduit cette préoccupation dans les services publics : audit des décisions automatisées, explicabilité, recours humain, supervision et possibilité d’arrêter ou de revenir en arrière sur un système à risque.

La souveraineté numérique ne se limite donc pas à l’hébergement. Elle touche aussi à la capacité démocratique de contrôler les décisions automatisées.

Ce qui évolue entre 2025 et 2026

1. Le sujet devient moins géopolitique et plus opérationnel

En 2025, l’article présentait la souveraineté numérique dans un cadre très géopolitique : Union européenne, États-Unis, Chine, concurrence des modèles de gouvernance, régulation, transferts de données, cloud souverain.

En 2026, le rapport s’attache davantage aux choix très concrets qui déterminent la maîtrise d’un service public numérique : marchés publics, contrats, standards ouverts, portabilité, audits, plans de sortie, compétences internes, résilience, accessibilité, conduite du changement.

Ce n’est pas un changement de fond. C’est un changement d’échelle. Le sujet passe du grand récit géopolitique aux choix qui déterminent, au quotidien, la maîtrise d’un service public numérique.

2. La souveraineté est davantage reliée à l’expérience citoyenne

En 2025, la souveraineté numérique était surtout présentée comme un enjeu de puissance, de régulation et de contrôle. En 2026, elle est rattachée plus directement à la qualité du service public : inclusion, accessibilité, recours, confiance, droit à l’explication, correction des erreurs.

Cette évolution est importante. Elle permet de sortir la souveraineté numérique d’un débat réservé aux experts. Elle montre que la souveraineté se mesure aussi dans la vie quotidienne : une démarche accessible, une décision contestable, une donnée protégée, un service qui continue de fonctionner.

3. Le rapport 2026 encadre plus fortement les partenariats public-privé

Le FEM reste fidèle à son ADN : il ne rejette pas les partenariats entre acteurs publics et privés. En 2025 déjà, l’article soulignait que la souveraineté numérique ne se limite pas à la régulation, mais comprend aussi l’innovation, l’entrepreneuriat et le financement.

Mais le rapport 2026 ajoute des garde-fous très concrets : contrats permettant la migration, audits indépendants, standards ouverts, stratégies multi-fournisseurs, documentation complète, compétences internes et plans de transition.

Enfin, le privé n’est pas présenté comme un ennemi, mais comme un partenaire possible, à condition que l’État ne perde pas la main.

4. Le rapport 2026 parle davantage de capacité interne de l’État

Le texte de 2025 traitait surtout de souveraineté au niveau des grands blocs, des normes et des infrastructures. Le rapport 2026 insiste davantage sur la capacité de l’État à faire vivre ses systèmes : former les agents, piloter les projets, gérer les incidents, documenter les architectures, réduire la dette technique, maintenir des plans de secours.

C’est peut-être l’évolution la plus intéressante : la souveraineté numérique n’est pas seulement une question de choix technologique. C’est aussi une question de compétence publique.

Conclusion

La souveraineté numérique n’est pas un réflexe de fermeture. Elle n’est pas non plus un slogan brandi contre toute coopération privée. Elle désigne une exigence plus simple : l’État doit pouvoir décider, comprendre, auditer, corriger, maintenir et, lorsque nécessaire, changer de fournisseur.

Le rapport 2026 du Forum économique mondial ne dit pas autre chose. Il ne reprend pas forcément les mots du débat français ou européen, mais il en confirme plusieurs piliers. Enfin, la question n’est pas théorique, mais pragmatique : lorsqu’un service public dépend d’un outil numérique, l’État conserve-t-il les moyens de le comprendre, de le réparer et de le faire évoluer ?

L’article Derrière les services publics en ligne, une question de souveraineté est apparu en premier sur Souverain.

Depuis plusieurs années, ma réflexion sur la souveraineté numérique avance par étapes. Je n’ai jamais vraiment cru aux ruptures décrétées du jour au lendemain, à ces départs presque héroïques où l’on prétend quitter Google ou Microsoft en une nuit, sans rencontrer quelques frictions, sans abandonner certains réflexes, sans hésiter, sans parfois revenir sur ses pas. Dans la vraie vie, la migration numérique ressemble plutôt à un cheminement patient : on teste, on hésite, on compare, on se trompe parfois, puis on finit par déplacer un service, puis un autre.

C’est dans cet esprit que je veux parler aujourd’hui de Proton. Non pas de toutes ses solutions, car l’écosystème est désormais large : Proton Mail, Proton Calendar, Proton Drive, Proton Docs, Proton Sheets, Proton Meet, Proton VPN, Proton Pass, Proton Wallet, Lumo AI, Proton Authenticator… La liste s’allonge vite. Proton présente d’ailleurs désormais ses services comme un véritable écosystème, visible dans son offre et ses pages produits.

Mais dans ce retour d’expérience, je veux volontairement réduire le champ. Je ne vais pas m’attarder sur Proton VPN, Proton Pass, Proton Wallet ou Lumo AI, même si ces produits mériteraient chacun un article séparé. Mon sujet ici est plus précis : Proton comme suite bureautique et collaborative, autour de Proton Mail, Proton Calendar, Proton Meet, Proton Drive, Proton Docs et Proton Sheets, avec un petit détour rapide par Proton Authenticator.

Mon passage à Proton Mail : une migration qui ne s’est pas faite du jour au lendemain

Il faut repartir du commencement : le courriel.

J’ai déjà raconté en détail pourquoi j’ai quitté Gmail. Comme beaucoup, j’ai longtemps utilisé les services de Google parce qu’ils étaient pratiques, bien conçus, presque évidents. Gmail, Google Calendar, Google Drive, Google Docs, Google Meet : tout fonctionnait, tout était intégré et semblait gratuit. Puis les questions sont venues : que devient ma vie privée ? Que fait Google de mes données ? Pourquoi une telle qualité de service est-elle offerte sans contrepartie financière ? Et surtout : pourquoi avons-nous si peu d’alternatives européennes réellement confortables à proposer au grand public ?

Mon départ de Gmail n’a donc pas été un geste impulsif. J’ai d’abord accepté de payer pour un service de courriel indépendant avec Fastmail. Puis j’ai franchi une étape décisive : utiliser mon propre nom de domaine afin de ne plus dépendre d’une adresse liée à un fournisseur. Cette étape m’a donné une liberté très concrète : si je change de prestataire, mon adresse reste la même. Je ne suis plus prisonnier d’une adresse en @gmail.com ou autre.

J’ai aussi envisagé d’autres pistes : le courriel fourni par un F.A.I, l’auto-hébergement, un serveur maison. Mais très vite, j’ai compris qu’héberger soi-même une messagerie fiable ne s’improvise pas. Derrière une simple adresse e-mail se cachent des choix techniques exigeants : DNS, sécurité, SMTP, IMAP, lutte contre le spam, réputation d’adresse IP, sauvegardes, maintenance. À ce stade, il me fallait un compromis : plus d’indépendance, plus de confidentialité, mais sans faire de chaque message envoyé une petite épreuve d’administration système…

C’est là que Proton Mail est devenu, progressivement, mon choix par défaut. Je n’ai pas basculé immédiatement avec un enthousiasme aveugle. Au départ, je trouvais Proton moins confortable que Gmail. L’interface me paraissait plus austère, certaines options moins évidentes, l’ensemble moins fluide. Mais Proton a beaucoup évolué. Aujourd’hui, je peux dire que Proton Mail répond à l’essentiel de mon besoin : une messagerie moderne, financée par ses utilisateurs, pensée autour de la confidentialité, avec calendrier, contacts, alias, filtres et applications mobiles solides.

Je ne dis pas que tout est parfait. Je continue d’espérer voir émerger un équivalent français aussi abouti, et je reste prêt à tester toute solution sérieuse qui apparaîtrait. Mais, pour l’instant, Proton Mail reste l’une des rares alternatives qui me permette de sortir de Gmail sans avoir l’impression de revenir vingt ans en arrière.

Proton Drive, Docs et Sheets : la question du quotidien

Après le courriel, l’autre grand chantier, c’est la bureautique.

J’ai beaucoup utilisé Google Docs et Google Sheets. Dans mon usage personnel et professionnel, ces deux outils avaient fini par remplacer Word et Excel dans la majorité des cas. Je pensais avoir gagné une petite bataille contre Microsoft, avant de constater que j’avais surtout remplacé un GAFAM par un autre. C’était confortable et plus pratique, oui. Mais ce n’était pas vraiment ce qu’on appelle de l’émancipation.

Lorsque j’ai testé Proton Sheets, ma question était simple : peut-il vraiment remplacer Google Sheets ? Ma réponse reste nuancée. Proton Sheets ressemble beaucoup à Google Sheets, et c’est déjà une bonne nouvelle. On ne repart pas de zéro, on retrouve une logique familière, on comprend rapidement où cliquer. Mais Google reste encore devant sur l’ergonomie pure, les micro-détails, la documentation, les fonctions immédiatement visibles et certains comportements qui paraissent secondaires jusqu’au moment où ils deviennent essentiels.

Pourtant, c’est précisément cette proximité qui m’intéresse. Concernant Proton Docs et Proton Sheets, ce sont aujourd’hui, parmi les solutions que j’ai testées, celles qui se rapprochent le plus de l’expérience Google Docs et Google Sheets. Et ce point est important : il n’y en a pas trop, mais il y en a suffisamment. Je veux dire par là que Proton n’a pas essayé de réinventer entièrement la bureautique en ligne. L’interface reste lisible, les usages de base sont là, et l’on peut imaginer une migration sans grand « traumatisme ».

C’est exactement ce que je cherche : retrouver assez de confort pour quitter Google Docs et Google Sheets sereinement. Pas pour le plaisir de copier Google. Mais parce que l’adoption passe aussi par des repères. Lorsqu’un utilisateur veut partir d’un outil dominant le marché, il ne demande pas toujours une révolution conceptuelle. Souvent, il demande simplement : “Est-ce que je peux continuer à travailler sans perdre mes habitudes essentielles ?”

Sur Proton Docs, je suis plus prudent. J’ai testé, j’aime bien, et je trouve le produit prometteur. Mais pour l’instant, je m’en passe. J’ai installé LaSuite Docs, j’en suis satisfait, et il m’a déjà fallu du temps pour réussir à quitter Google Docs au profit d’une autre solution. Je n’ai donc pas encore de raison suffisamment sérieuse pour changer à nouveau. Dans une migration numérique, il ne faut pas sous-estimer l’aspect psychologique du changement. Même lorsque la nouvelle solution répond aux besoins, il faut parfois laisser les usages se stabiliser.

Je trouve néanmoins que Proton Docs et Proton Sheets avancent dans le bon sens. Proton indique d’ailleurs vouloir renforcer les fonctionnalités et la collaboration dans Docs et Sheets, avec une meilleure intégration entre ses applications et des améliorations de Proton Drive. Mais j’aimerais davantage de communication concernant les produits. Pas forcément des promesses spectaculaires, plutôt une transparence plus régulière : où en sont-ils ? Quelles fonctionnalités arrivent ? Quels bugs sont identifiés ? Quels choix ont été faits, et pourquoi ?

Sur ce terrain, Proton a déjà commencé à publier des feuilles de route, ce qui est appréciable. Mais pour un utilisateur qui cherche à quitter Google ou Microsoft, la confiance ne vient pas seulement de la sécurité ou du chiffrement. Elle vient aussi du rythme, de la lisibilité, de la sensation qu’un produit avance et que l’on sait dans quelle direction il avance.

Fileverse : la solution que j’ai envie de mettre davantage en lumière

Je veux aussi profiter de cet article pour parler d’une solution encore trop peu visible à mon goût : Fileverse, avec dDocs et dSheets.

Je le dis avec prudence : je ne connais pas toutes les alternatives existantes. Je m’efforce de chercher, de tester, de comparer, tout en ayant bien conscience que mon tour d’horizon reste incomplet. Cela étant dit, parmi les solutions que j’ai pu essayer, Fileverse fait partie de celles qui m’ont le plus agréablement surpris.

Pourquoi ?

Parce que dDocs et dSheets se rapprochent encore davantage, à mes yeux, de l’expérience Google. L’interface est fluide, rapide et agréable. Or c’est très souvent ce qui manque aux alternatives : elles sont vertueuses, parfois brillantes techniquement, mais elles donnent encore trop souvent l’impression d’être plus lentes, plus rugueuses, moins naturelles à prendre en main.

Fileverse présente dDocs comme une alternative open source et orientée vie privée à Google Docs et Microsoft Word, avec chiffrement de bout en bout, des fonctions de collaboration, un mode hors ligne, la prise en charge du Markdown, et de LaTeX et un fonctionnement accessible sans création de compte immédiate. dSheets, de son côté, est présenté comme une alternative à Google Sheets et Excel, accessible depuis un navigateur, avec une interface familière et des fonctions standard comme VLOOKUP, INDEX ou MATCH.

Je ne dis pas que Fileverse est la réponse définitive. Je dis simplement que c’est une piste que je trouve enthousiasmante, parce qu’elle prend au sérieux un point décisif : la fluidité. Si les alternatives veulent toucher un public plus large, elles devront être rapides, agréables, simples, presque évidentes. Sur ce point, Fileverse mérite clairement plus d’attention.

Proton Meet : la vraie surprise

Je savais que Proton Meet était annoncé depuis longtemps. Je savais également que Proton voulait compléter son écosystème avec une brique de visioconférence. Mais je ne savais pas exactement ce qu’il y avait sous le capot, ni à quel niveau d’aboutissement le produit arriverait.

Et là, c’est la bonne surprise !

Pour une bêta, ou en tout cas pour un produit encore jeune, Proton Meet donne déjà une impression assez solide. On est sur quelque chose de simple, propre, efficace. Proton présente Meet comme un outil de visioconférence chiffré de bout en bout, utilisant Messaging Layer Security (MLS), et permettant même à des participants de rejoindre une réunion sans inscription.

Autre point intéressant : Proton Meet repose sur LiveKit Cloud pour la transmission et le routage des données de visioconférence, tout en chiffrant le contenu côté client avec MLS avant qu’il ne quitte l’appareil. C’est un point technique important, et il mérite d’être regardé avec nuance. D’un côté, LiveKit est une brique moderne, efficace, que l’on retrouve aussi dans LaSuite Meet / Visio. Le paquet YunoHost de LaSuite Meet indique également que l’outil est “Powered by LiveKit”. De l’autre, l’usage d’une infrastructure tierce appelle toujours des questions légitimes sur les métadonnées, la juridiction, les dépendances techniques et le niveau exact de maîtrise. Ce n’est pas un jugement, c’est simplement le genre de point qu’il faut documenter clairement.

Ce que j’aime, c’est que Proton Meet peut se tester facilement depuis son interface, y compris pour se faire une première idée sans entrer immédiatement dans une logique d’engagement. L’offre gratuite permet d’organiser des appels jusqu’à 50 personnes pendant une heure, avec cinq liens de réunion par jour. Les fonctions professionnelles ajoutent notamment des réunions plus longues, plus de participants, la planification et l’enregistrement vidéo.

Pour l’instant, les fonctions d’enregistrement ne sont pas disponibles dans les offres gratuites. Et dans mon cas, avec mon offre actuelle, il faudrait ajouter environ 96 € si je m’engage sur un an. À ce stade, vu mon niveau de satisfaction avec Visio / Meet de LaSuite, je ne vais pas payer ce supplément. Je suis déjà très satisfait de LaSuite sur ce point. J’aimerais simplement que l’équipe de la DINUM ajoute, ou rende plus accessible, la fonctionnalité d’enregistrement vidéo dans le paquet YunoHost mis à disposition.

Modification du 27 mai :

Après publication, plusieurs lecteurs ont attiré mon attention sur un article critique de Sam Bent consacré à Proton Meet. Celui-ci ne remet pas nécessairement en cause le chiffrement de bout en bout du service, mais interroge plus précisément sa chaîne d’infrastructure, en particulier le recours à LiveKit Cloud et à plusieurs acteurs américains. Cette précision mérite d’être intégrée au débat : la souveraineté numérique suppose aussi d’examiner les métadonnées, les prestataires techniques et les dépendances réelles qui rendent le service possible.

Le vrai sujet (et mon obsession assumée) : le flux opérationnel complet

Si je reparle de Proton aujourd’hui, c’est aussi parce que cet écosystème commence à répondre à une idée que je défends depuis longtemps : le flux opérationnel complet.

J’avais déjà développé cette notion dans mon article sur les suites bureautiques souveraines. Mon point était simple : l’enjeu n’est pas d’avoir “plein d’apps”. L’enjeu, c’est que les outils s’enchaînent naturellement. Messagerie, calendrier, contacts, fichiers, documents, visio : toutes ces briques doivent pouvoir dialoguer naturellement. Sinon, on obtient une juxtaposition de bons outils, pas une vraie suite.

C’est précisément ce qui fait la force de Microsoft 365 ou Google Workspace. On reçoit un courriel, on crée une réunion, on invite un contact, on joint un document, on ajoute un lien de visioconférence en un clic, on retrouve l’événement dans l’agenda, les participants reçoivent tout ce qu’il faut. L’utilisateur n’a pas l’impression de “changer d’application”. Il poursuit simplement son travail, sans rupture.

Avec Proton Mail et Proton Calendar, je commence enfin à retrouver ce flux. Depuis Proton Calendar, je peux créer une réunion, inviter une personne déjà présente dans mes contacts, puis ajouter en un clic un lien Proton Meet. Proton a d’ailleurs annoncé une planification de rendez-vous intégrée à Proton Calendar, capable de créer automatiquement un événement et de générer un lien Proton Meet privé.

C’est exactement le genre d’intégration qui change tout.

Il reste toutefois, à mes yeux, quatre améliorations qui rapprocheraient Proton de ce fameux flux opérationnel complet :

• Depuis Proton Calendar, j’aimerais pouvoir voir si la personne invitée est disponible ou non, comme dans Microsoft 365. C’est une fonction très simple en apparence, mais décisive dans un usage professionnel.
• Toujours depuis Proton Calendar, je trouve dommage de ne pas pouvoir ajouter un document en un clic, en explorant directement le contenu disponible depuis Proton Drive.
• Depuis Proton Mail, il manque une fonction permettant de créer une réunion directement depuis la rédaction d’un courriel, sans devoir passer explicitement par Proton Calendar.
• Enfin, sur l’application mobile iOS de Proton Meet, je regrette de ne pas pouvoir accéder directement à mon carnet d’adresses pour ajouter un contact. Il faut copier le lien de réunion, puis le coller dans un courriel, un SMS ou une messagerie instantanée. C’est d’autant plus dommage que l’application iOS Proton Calendar pense déjà mieux ce flux : on peut y créer un événement, inviter un collaborateur et générer en même temps un lien Proton Meet. En revanche, comme sur le web, il manque encore la visibilité sur la disponibilité du collaborateur et l’ajout d’un document depuis Proton Drive.

On pourrait dire que ce sont des détails. C’est vrai. Mais ce sont des détails importants, parce qu’ils touchent au cœur de l’expérience. Et dans la bataille face aux GAFAM, l’expérience utilisateur est décisive.

Je formule cela avec humilité, car je sais bien qu’il est plus facile de pointer un manque que de développer proprement une fonctionnalité utilisée par des millions de personnes. Mais j’espère vraiment que l’équipe produit de Proton lira ce type de retour. Ce n’est pas une leçon. C’est plutôt une recommandation d’un client et d’un utilisateur : dans une suite collaborative, le produit ne se juge pas seulement brique par brique mais dans sa capacité à former un ensemble cohérent.

Proton Authenticator : le petit changement facile qui donne envie d’aller plus loin

Avant, j’utilisais Google Authenticator. En testant Proton Authenticator, j’ai été vite séduit, puis converti. Je l’utilise désormais sur mon ordinateur et depuis mon smartphone. Et là, pour le coup, le changement est simple. Très simple.

Proton Authenticator est gratuit, open source, chiffré de bout en bout, disponible sur mobile et sur ordinateur, avec import depuis d’autres applications d’authentification, synchronisation possible, sauvegardes et usage sans compte Proton obligatoire.

C’est peut-être l’un des meilleurs premiers pas pour quelqu’un qui veut quitter un outil Google sans douleur. On ne perd presque aucune habitude. On ne se bat pas avec une interface étrange. On ne doit pas tout réapprendre. On change un outil, puis on se rend compte que c’était possible.

Et psychologiquement, ce n’est pas rien. Une fois qu’on a franchi ce type de petit cap, on se sent plus léger. On se sent aussi plus conforté dans l’idée d’aller plus loin : quitter progressivement d’autres services des GAFAM, non pas par posture, mais parce que l’on découvre que des alternatives crédibles existent.

Les migrations vers Proton deviennent plus visibles

J’observe aussi un phénomène intéressant : de plus en plus de personnes annoncent publiquement leur migration vers Proton.

J’ai vu passer deux publications LinkedIn qui vont dans ce sens. Dans la première, Gilles Babinet explique que son équipe et lui sont passés sur Proton Mail, Proton Drive, etc., avec l’idée de sortir progressivement de l’écosystème Google. Il insiste aussi sur le fait que l’objectif n’est pas forcément de remplacer chaque logiciel par son clone, mais de changer de pratiques avec des outils où l’on contrôle davantage ses données.

Dans la seconde, Sébastien Nouet partage un retour d’expérience sur Proton for Business après plusieurs mois d’usage chez Sovkern. Il évoque une bonne expérience utilisateur, une interface Mail propre, rapide, agréable, un Drive partagé fluide, un Calendar, un Pass, un VPN, puis Proton Meet qui complète l’ensemble depuis avril 2026. Son propos est intéressant parce qu’il ne nie pas les nuances, notamment les débats suisses sur la surveillance, mais il considère que le choix reste structurellement plus cohérent qu’une dépendance aux grands acteurs américains ou chinois.

Ces signaux faibles deviennent justement de moins en moins discrets. Ils montrent que certaines craintes commencent à tomber. La peur de perdre ses repères, de ne pas retrouver ses habitudes, et de se retrouver seul dans un écosystème marginal : tout cela recule. Et c’est une excellente nouvelle.

Pourquoi la Suisse semble-t-elle mieux comprendre la suite bureautique ?

Il y a tout de même quelque chose qui m’étonne : en Suisse, on trouve aujourd’hui deux entreprises qui semblent avoir compris ce que veut dire une suite bureautique en 2026 : Proton et Infomaniak.

Je ne veux pas tirer de conclusion trop rapide. Il faudrait creuser l’histoire industrielle, la culture politique, le rapport suisse à la confidentialité, le tissu économique, la taille du marché, la relation à l’Europe, le rapport aux infrastructures. Mais je trouve frappant que deux des alternatives européennes les plus crédibles à Google Workspace et Microsoft 365 viennent de Suisse.

Pour l’instant, dans mon classement personnel des suites qui me paraissent les plus intéressantes, je mettrais :

1. Proton
2. Infomaniak
3. LaSuite (un peu hors compétition, je le reconnais, et même si je sais bien que cela demande encore des compétences que tout le monde n’a pas)

Ce classement est provisoire, subjectif, lié à mes usages et à mes tests. Il changera peut-être. Mais aujourd’hui, si je devais conseiller quelqu’un qui veut sortir progressivement des suites américaines sans perdre immédiatement tout confort, ce sont les trois noms que je regarderais en premier.

Tout n’est pas rose : Proton, la Suisse et les controverses

Ce serait une erreur de transformer Proton en totem intouchable.

Proton a déjà été critiqué, notamment lors de la controverse autour des adresses IP. En 2021, Proton Mail s’est retrouvé au centre d’une polémique après avoir livré à la police des adresses IP liées à des militants climat français, à la suite d’une procédure passée par Europol puis par la justice suisse. Proton a expliqué qu’il ne pouvait pas se soustraire à une décision de justice suisse, tout en rappelant que le contenu des courriels n’avait pas été communiqué, car Proton n’y avait pas accès. L’affaire a surtout mis en lumière une distinction essentielle : le chiffrement protège la vie privée du contenu, mais il ne rend pas anonyme.

Proton ne transforme pas la confidentialité en invisibilité. C’est une nuance importante. Ce n’est pas non plus une garantie absolue contre toute demande judiciaire. C’est une entreprise soumise à un cadre juridique, avec une architecture technique qui protège fortement certaines données, mais qui ne supprime pas toutes les réalités du monde légal et opérationnel.

Et même en Suisse, le cadre juridique n’est pas immuable. En 2025, Proton a menacé de quitter le pays si de nouvelles règles de surveillance étaient adoptées. Le débat portait notamment sur des modifications qui auraient pu restreindre le chiffrement ou forcer certains acteurs à rendre accessibles des métadonnées, voire des contenus. Andy Yen, le fondateur et directeur général de Proton, a alors déclaré que l’entreprise ne pourrait pas se conformer à une telle loi si elle entrait en vigueur.

Ce point est essentiel dans mon raisonnement. Oui, je trouve étonnant et encourageant que la Suisse parvienne à faire émerger des acteurs comme Proton ou Infomaniak. Mais cela ne signifie pas que tout y soit parfait, ni que la souveraineté numérique soit acquise une fois pour toutes. Même en Suisse, le droit peut évoluer, l’équilibre entre sécurité publique et vie privée peut se déplacer, et il faut toujours rester vigilant.

Les tarifs : tester avant de basculer

Un point rassurant, c’est qu’il est possible de tester Proton gratuitement. L’offre gratuite indiquée sur la page tarifaire française commence avec 1 Go de stockage, un utilisateur et une adresse e-mail chiffrée.

Ensuite, selon les périodes et les promotions, les offres individuelles varient autour de 3,99 €/mois à 9,99 €/mois. Il existe aussi une offre Family, avec jusqu’à 6 utilisateurs et 3 To de stockage. Pour les entreprises, Proton propose notamment Workspace Standard, avec Mail, Calendar, Drive, Docs, Sheets, VPN, Pass et Meet, 1 To de stockage par utilisateur et des fonctions de collaboration. Il existe enfin des offres étudiantes, avec des réductions importantes sur VPN Plus, Mail Plus ou Proton Unlimited.

Les prix exacts peuvent varier, surtout en période promotionnelle, donc il faut toujours vérifier au moment de souscrire. Mais le point important est là : on peut commencer gratuitement, tester, puis décider. Pour une alternative de cette ampleur, c’est essentiel.

Pourquoi j’aime bien Proton

Si je parle autant de Proton, ce n’est pas uniquement parce que les produits s’améliorent. C’est aussi parce que j’aime bien les valeurs affichées par l’entreprise.

J’aime le fait que Proton mette en avant l’open source. L’entreprise affirme que ses applications sont open source, auditées et vérifiables, et que cette transparence est un moyen de gagner la confiance de sa communauté.

J’aime aussi son insistance sur le chiffrement, la confidentialité et la protection de la vie privée. Proton rappelle que l’entreprise est née en Suisse en 2014, après une rencontre de scientifiques au CERN, avec l’ambition de créer un internet plus respectueux de la vie privée.

J’apprécie le fait qu’il existe une vraie communauté autour de Proton. J’ai souvent eu affaire à eux pour des suggestions ou du support, et je n’ai jamais été déçu. J’aime aussi leur communication, parfois malicieuse, parfois en forme de pied de nez aux grands acteurs du numérique. Ce ton compte : il donne le sentiment qu’il y a une culture, pas seulement une fiche produit.

https://t.co/j95nneCeiz pic.twitter.com/QcWzsZVfGB

— Proton Mail (@ProtonMail) 28 avril 2026

J’aime enfin l’existence de la Fondation Proton. Proton explique que cette fondation à but non lucratif est l’actionnaire principal de l’entreprise, avec pour mission de veiller à ce que Proton ne s’écarte pas de son objectif : faire progresser la protection de la vie privée, la liberté et la démocratie dans le monde. La fondation indique aussi avoir accordé plus de 5 millions de dollars de subventions à des organisations alignées avec cette mission.

Tout cela ne rend pas Proton parfait. Aucune entreprise ne l’est. Mais cela forme un ensemble cohérent : une alternative européenne, commercialement raisonnable, techniquement sérieuse, portée par une culture de la confidentialité et une volonté de construire autre chose que le modèle publicitaire dominant.

À mes yeux, Proton est aujourd’hui l’une des plus belles alternatives disponibles pour qui veut sortir progressivement des GAFAM sans renoncer à une expérience « moderne ».

Ce n’est pas une injonction. Ce n’est pas un dogme. Ce n’est pas “quittez tout, maintenant, sans discuter”. C’est plutôt une invitation : testez gratuitement, essayez Proton Mail, regardez Proton Calendar, créez une réunion Proton Meet, ouvrez Proton Drive, testez Docs et Sheets, installez Proton Authenticator.

Puis faites-vous votre propre idée.

Car au fond, c’est peut-être cela, la souveraineté numérique au quotidien : reprendre le droit d’essayer, de comparer, de choisir, et parfois de changer d’avis.

L’article Proton : ma préférence à moi est apparu en premier sur Souverain.

D’abord à Genma, dont le travail de documentation autour de l’auto-hébergement, et notamment de YunoHost, m’a accompagné de manière décisive. Son blog fait partie de ces ressources discrètes, patientes, concrètes, qui permettent à des utilisateurs non spécialistes de franchir un cap : celui qui mène de la simple curiosité à la reprise progressive de ses propres services numériques.

Il est aussi dédié à Benjamin Bayart, dont la conférence donnée en 2007 aux Rencontres Mondiales du Logiciel Libre d’Amiens, Internet libre ou Minitel 2.0 ?, reste l’un des textes fondateurs pour comprendre ce qui se joue derrière nos usages numériques. Elle rappelle une idée simple, mais rarement prise au sérieux jusqu’au bout : héberger son propre serveur de courriel n’est pas seulement une opération technique. C’est reprendre la maîtrise de sa correspondance, refuser que toute communication passe par quelques plateformes centrales, et défendre un Internet réellement décentralisé.

C’est dans cet esprit que s’inscrit cet article.

Il ne s’agit pas ici de vendre une solution miracle, ni de prétendre que l’auto-hébergement serait simple, immédiat ou adapté à tout le monde. Il s’agit plutôt de partager une expérience concrète : l’installation et la prise en main de grommunio, une solution autrichienne open source qui propose de remplacer, au moins en partie, ce que beaucoup d’organisations confient aujourd’hui à Microsoft Exchange ou Microsoft 365.

Dit simplement, grommunio permet de gérer une messagerie professionnelle complète : courriels, calendriers, contacts, tâches, synchronisation avec un téléphone, accès depuis un navigateur, et compatibilité avec des clients comme Outlook ou Apple Mail. Ce n’est donc pas seulement une boîte mail. C’est une tentative de reconstruire, avec des briques ouvertes, une infrastructure de communication que l’on peut installer, administrer et maîtriser soi-même.

Cette ambition mérite d’être examinée avec sérieux. Elle touche à un sujet central de la souveraineté numérique : la possibilité, pour des individus, des associations, des entreprises ou des collectivités, de reprendre la main sur leurs outils de correspondance. Mais elle demande aussi de la prudence. Une solution open source n’est pas automatiquement parfaite parce qu’elle est ouverte. Elle doit être testée, comprise, critiquée, comparée, et confrontée à l’usage réel.

C’est ce cheminement que cet article propose de raconter : non pas depuis un laboratoire ou une documentation commerciale, mais depuis une installation concrète, avec ses réussites, ses réglages, ses doutes et ses limites.

grommunio : une entreprise autrichienne face au verrou Exchange

Avant de raconter l’installation elle-même, il faut s’arrêter sur l’entreprise qui porte cette solution. grommunio n’est pas un grand nom connu du grand public. Ce n’est pas Microsoft, Google, Apple, ni même un acteur open source aussi identifié que Nextcloud ou LibreOffice. C’est une société autrichienne, basée à Vienne, qui s’est construite autour d’une idée assez simple à formuler, mais très difficile à réaliser : proposer une alternative ouverte aux grandes plateformes collaboratives propriétaires.

Sur son site, grommunio explique que l’équipe s’est réunie en 2019, dans un contexte où la pandémie de 2020 a rendu plus visible encore la dépendance aux outils centralisés et aux solutions propriétaires étrangères.

L’entreprise se présente donc comme une réponse européenne à une dépendance très concrète : celle des organisations qui utilisent Microsoft Exchange, Microsoft 365 ou des services équivalents pour gérer leurs courriels, leurs calendriers, leurs contacts, leurs tâches et leurs communications internes. Sa promesse n’est pas seulement de fournir une boîte mail. Elle consiste à proposer une plateforme collaborative complète, capable de s’intégrer à des usages déjà installés dans les entreprises. Sur son site, grommunio met en avant les courriels, les contacts, le calendrier, les tâches, la visioconférence, le chat, les fichiers, la bureautique, l’archivage et la gestion des appareils mobiles.

Dit plus simplement : grommunio cherche à remplacer une partie importante de ce que beaucoup d’organisations délèguent aujourd’hui à Microsoft. Non pas seulement l’adresse de courriel, mais l’environnement quotidien qui va avec : recevoir ses messages, consulter son agenda, synchroniser son téléphone, partager des dossiers, travailler depuis Outlook, Apple Mail, Thunderbird ou un navigateur.

Le cœur technique de cette ambition s’appelle Gromox. C’est le composant central de grommunio, celui qui joue le rôle du moteur sous le capot. Gromox est présenté comme un serveur groupware capable de servir de remplacement à Microsoft Exchange, avec la prise en charge de protocoles comme RPC/HTTP, MAPI/HTTP, EWS, IMAP, POP3 et SMTP. Ces noms peuvent sembler obscurs, mais l’idée est simple : ce sont les « langages » que les logiciels de messagerie utilisent pour dialoguer avec le serveur. Si Outlook sait parler à Exchange, grommunio essaie de faire en sorte qu’Outlook puisse aussi lui parler.

C’est là que la solution devient intéressante du point de vue de la souveraineté numérique. Beaucoup de solutions libres savent faire du mail. Certaines savent très bien gérer des calendriers, des contacts ou des fichiers. Mais reproduire suffisamment le comportement d’un serveur Exchange pour conserver des usages comme Outlook, la synchronisation mobile ou les calendriers partagés est un exercice beaucoup plus délicat. grommunio ne se contente donc pas de proposer un webmail agréable : son pari est de reprendre une place très stratégique, celle du serveur de communication professionnelle.

Derrière cette entreprise, plusieurs noms apparaissent. Le plus visible est Norbert Lambing, fondateur et dirigeant de grommunio. Son parcours public est assez atypique pour le monde du logiciel : avant grommunio, il est notamment connu pour être champion du monde d’aviron et médaillé, avec une carrière sportive et des responsabilités dans la fédération autrichienne. Ce détail ne suffit évidemment pas à résumer l’entreprise, mais il donne une couleur particulière au projet : grommunio n’est pas seulement présenté comme une aventure de développeurs, mais aussi comme une organisation construite autour d’une stratégie, d’une équipe et d’un objectif de long terme.

Norbert Lambing a également plusieurs associés : Jan Engelhardt, Alexander Nosko, Walter Hofstädtler et Martin Witte. Ces noms permettent de comprendre que grommunio repose sur un noyau resserré, davantage proche d’une structure spécialisée que d’un grand éditeur industriel.

Le nom de Jan Engelhardt est particulièrement important sur le plan technique. grommunio le présente comme développeur principal et architecte logiciel. En 2024, il a donné une conférence au FOSDEM, grand rendez-vous européen du logiciel libre, consacrée à l’implémentation de nombreux protocoles Microsoft Exchange en open source. C’est un point majeur : la crédibilité de grommunio repose largement sur cette capacité à comprendre et à réimplémenter des mécanismes techniques complexes, sans disposer du code propriétaire de Microsoft Exchange.

En 2024, grommunio a aussi annoncé l’arrivée de Michael Kromer comme directeur technique. L’entreprise le présente comme un profil expérimenté, avec plus de vingt ans dans l’informatique et des fonctions de direction dans l’écosystème allemand et européen. Là encore, le signal est intéressant : grommunio semble vouloir passer d’un projet très technique, porté par une petite équipe spécialisée, à une solution plus structurée pour des organisations, des clients et des partenaires.

Le modèle économique est assez classique dans le monde de l’open source professionnel. Le produit repose sur du code ouvert, mais l’entreprise vend des abonnements, du support et des services. grommunio indique que l’achat d’une souscription donne accès aux fonctionnalités, au support selon le niveau choisi, et contribue au développement du produit open source. Ce point mérite d’être rappelé, car il évite deux malentendus : open source ne veut pas dire absence de modèle économique, et gratuit ne veut pas dire absence de coût réel d’administration.

Il faut donc regarder grommunio pour ce qu’elle est : une solution européenne, jeune à l’échelle du marché de la messagerie professionnelle, ambitieuse sur le plan technique, et positionnée face à un acteur immense. Sa force est de s’attaquer à un verrou très concret : la dépendance des organisations à Exchange et à Outlook. Sa limite potentielle tient au même endroit : plus la compatibilité recherchée est profonde, plus les détails techniques deviennent nombreux, sensibles et parfois difficiles à stabiliser.

Ce n’est pas une raison pour l’écarter. C’est au contraire ce qui rend l’expérience intéressante. grommunio appartient à cette famille de solutions qui ne se contentent pas de critiquer les grandes plateformes propriétaires, mais tentent de reconstruire une alternative fonctionnelle. L’enjeu n’est donc pas de savoir si elle remplace parfaitement Microsoft du jour au lendemain. La vraie question est plutôt celle-ci : jusqu’où une infrastructure ouverte, européenne et administrable peut-elle permettre de reprendre la main sur un outil aussi central que la messagerie professionnelle ?

En France, il existe aussi une solution de référence sur ce terrain : BlueMind, fondée par Pierre Baudracco. Elle rappelle que grommunio n’est pas seul à proposer une alternative européenne aux grandes suites collaboratives propriétaires. Les deux solutions jouent dans la même famille : celle des alternatives à Microsoft Exchange et Microsoft 365. Elles cherchent toutes deux à préserver des usages devenus familiers : courriels, calendriers, contacts, mobilité, compatibilité Outlook, tout en redonnant aux organisations davantage de maîtrise sur leurs outils. La nuance se trouve plutôt dans leur approche. BlueMind apparaît davantage comme une messagerie collaborative française structurée pour les organisations, avec une forte logique d’accompagnement, de support et de déploiement professionnel. grommunio, de son côté, met particulièrement en avant sa compatibilité avec l’univers Exchange et Outlook, tout en gardant l’image d’un serveur que l’on peut installer, administrer et intégrer dans sa propre infrastructure. Cette approche n’empêche pas l’existence d’une offre commerciale, avec abonnements, support et réseau de partenaires. Plutôt que de les comparer frontalement, il paraît plus juste de les considérer comme deux réponses différentes à une même dépendance.

Installer grommunio : sortir du confort de YunoHost

L’installation de grommunio commence par un changement d’univers. Jusqu’ici, l’auto-hébergement passait surtout par YunoHost, une solution basée sur Debian, pensée pour simplifier au maximum l’installation de services web : une interface claire, des applications installables en quelques clics, une logique très accessible pour qui accepte d’apprendre progressivement.

Avec grommunio, l’approche est différente. La solution repose sur openSUSE, une distribution Linux issue d’un autre écosystème que Debian. openSUSE est un système libre utilisé pour des ordinateurs, des serveurs et des environnements professionnels. Ce n’est pas un détail bloquant, mais cela oblige à changer certains réflexes : les commandes, les outils d’administration, l’organisation du système et les habitudes ne sont pas exactement les mêmes. Pour quelqu’un qui a appris l’auto-hébergement par YunoHost, c’est donc un nouvel apprentissage. openSUSE présente Leap comme une distribution à vocation stable, liée à l’univers SUSE Linux Enterprise, ce qui explique son usage fréquent côté serveur.

La différence avec YunoHost se voit aussi dans la philosophie générale. Avec YunoHost, un même serveur peut accueillir plusieurs applications : un blog, un cloud, un gestionnaire de mots de passe, un outil de statistiques, une messagerie, etc. Avec grommunio, le serveur devient beaucoup plus spécialisé. On installe bien un système d’exploitation, mais l’objectif est ensuite que grommunio soit la solution centrale de ce serveur. Il ne s’agit pas d’une application ajoutée à côté d’autres services : le serveur est pensé comme une infrastructure de messagerie et de collaboration.

L’installation elle-même reste relativement austère. Elle n’est pas incompréhensible, mais elle n’a pas la douceur pédagogique de YunoHost. L’interface d’installation est en anglais, les choix demandent un minimum de familiarité avec un système Linux, et certaines notions réseau doivent déjà être comprises : nom de domaine, adresse IP, sous-domaine, DNS, pare-feu, ports, certificat, accès SSH. Ce n’est pas réservé aux seuls ingénieurs, mais ce n’est pas encore une expérience grand public au sens habituel du terme.

Le premier travail a donc consisté à installer le système, puis grommunio, sur une machine dédiée. La solution a été volontairement limitée à l’essentiel : courriels, calendriers et contacts. Les autres briques possibles de grommunio : visioconférence, chat, fichiers, bureautique en ligne, n’ont pas été activées. Ce choix permettait de tester d’abord le cœur du sujet : peut-on réellement faire fonctionner une messagerie collaborative ouverte, compatible avec des clients modernes, dans une infrastructure maîtrisée ?

Avant même les courriels : préparer tout l’environnement

La mise en production d’un serveur de courriel ne commence pas au moment où l’on envoie le premier message. Elle commence bien avant, dans la préparation du domaine.

Il a fallu configurer un sous-domaine dédié, ici avec une logique du type mail.domaine.tld, puis préparer le serveur autodiscover. Ce dernier joue un rôle discret mais important : il permet à des clients comme Apple Mail, Outlook ou Thunderbird de trouver automatiquement les bons réglages de connexion. L’objectif est simple : entrer son adresse de courriel et son mot de passe, puis laisser le logiciel découvrir le serveur sans devoir remplir à la main une série de paramètres techniques.

Un autre point a demandé une attention particulière : le reverse DNS. Dans le monde du courriel, il ne suffit pas d’avoir un serveur qui envoie des messages. Il faut aussi que son adresse IP soit cohérente avec le nom de domaine annoncé. Les grands services de messagerie vérifient cette cohérence. Google rappelle par exemple qu’une adresse IP d’envoi doit correspondre au nom d’hôte déclaré dans l’enregistrement PTR, c’est-à-dire le DNS inverse.

Au niveau du bureau d’enregistrement du nom de domaine, il a également fallu préparer les enregistrements SPF, DKIM et DMARC. Ces trois sigles peuvent sembler obscurs, mais leur rôle est assez simple :

• SPF indique quels serveurs ont le droit d’envoyer des courriels pour un domaine.
• DKIM ajoute une signature cryptographique aux messages pour prouver qu’ils n’ont pas été envoyés par n’importe qui.
• DMARC donne une politique générale aux serveurs qui reçoivent les messages : que faire si l’authentification échoue ?

Google présente ces trois mécanismes comme des éléments importants pour limiter l’usurpation de domaine, le spam et les erreurs de délivrabilité.
Ce point était probablement l’une de mes plus grandes inquiétudes, au-delà de la technique elle-même. Un serveur de courriel peut être parfaitement installé, mais devenir presque inutile si ses messages arrivent systématiquement dans les spams. Depuis 2024, Gmail et Yahoo ont renforcé leurs exigences autour de SPF, DKIM et DMARC, notamment pour « fiabiliser » l’authentification des expéditeurs. Mailjet résume bien cet enjeu : ces protocoles ne sont plus seulement des bonnes pratiques, ils deviennent progressivement des conditions de délivrabilité.

Dans cette installation, les premiers tests ont été rassurants : les messages envoyés vers Gmail et Yahoo ne sont pas arrivés dans les courriers indésirables. Cela ne garantit pas tout sur le long terme, car la réputation d’un domaine et d’une adresse IP se construit dans la durée, mais c’était un premier seuil important à franchir.

Reverse proxy, routeur et pare-feu : rendre le serveur joignable sans l’exposer inutilement

Le serveur grommunio n’a pas été exposé directement sur Internet pour tous les usages web. L’accès public en HTTP et HTTPS passe par le serveur YunoHost déjà exposé sur les ports 80 et 443. Celui-ci joue le rôle de reverse proxy : il reçoit les demandes venant d’Internet, puis les transmet au bon serveur interne.

Cette étape a été nécessaire pour rendre accessibles l’interface web de grommunio et le service autodiscover, tout en gardant une architecture cohérente avec l’infrastructure existante. En clair, YunoHost reste la porte d’entrée web principale, tandis que grommunio travaille derrière lui pour la messagerie.

Un port a aussi dû être ouvert sur le routeur pour permettre au serveur de recevoir le courrier depuis l’extérieur. Là encore, l’enjeu n’était pas d’ouvrir largement la machine, mais de laisser passer uniquement ce qui était nécessaire. Le pare-feu a donc été configuré de manière rigoureuse, avec l’idée de limiter l’exposition au strict besoin du service.

L’accès SSH, lui, n’était pas actif dès le départ. Il a fallu l’activer pour pouvoir administrer correctement la machine à distance. Ce détail peut sembler secondaire, mais il fait partie des différences avec une solution plus guidée : sur un serveur de ce type, la ligne de commande reste rapidement indispensable pour comprendre, corriger et vérifier.

DKIM, Rspamd et les petits détails qui comptent

La signature DKIM a été configurée avec rspamadm configwizard. Derrière cette commande se cache une opération importante : générer la clé qui permettra au serveur de signer les courriels sortants. Cette signature aide les serveurs destinataires à vérifier que le message provient bien du domaine annoncé.

Un point de droits a aussi dû être corrigé sur la clé DKIM. Le fichier existait, mais il devait être lisible par le bon service, avec les bons droits. Dans ce cas, la clé a été corrigée avec le propriétaire groas:grommunio et des permissions restrictives en 440. Dit simplement : le fichier devait être accessible au service qui signe les courriels, sans être ouvert inutilement au reste du système.

Ce genre de détail montre bien la nature de l’expérience. Le problème n’est pas toujours spectaculaire. Parfois, tout repose sur un fichier, un droit d’accès, un service à redémarrer, une ligne de configuration oubliée. C’est exactement là que l’auto-hébergement devient formateur : on ne se contente plus de cliquer sur une interface, on commence à comprendre les dépendances entre les briques.

Deux bugs remontés à la communauté

L’installation a aussi révélé deux bugs, qui ont été remontés à la communauté grommunio.

Le premier était bloquant pour une première expérience : à l’ouverture d’un courriel dans grommunio Web, une erreur apparaissait, rendant impossible la lecture du premier message reçu. Pour un utilisateur qui vient tout juste d’installer la solution, voir le webmail échouer au tout premier lancement de l’interface est, évidemment décourageant. Le problème a été documenté précisément sur le forum communautaire, avec l’environnement, les versions installées, le symptôme, le fichier concerné et un contournement temporaire.

Ce bug a ensuite été corrigé très rapidement par mise à jour, en moins d’une journée. Pour une solution open source, c’est un signal intéressant : le problème existait, il était gênant, mais la remontée a été utile et le correctif est arrivé vite.

Le second bug (et corrigé en moins de 48h) était moins bloquant, mais restait important pour la qualité d’administration. Après un redémarrage complet du serveur, l’interface d’administration de grommunio affichait des erreurs DNS : MX, SPF, DKIM, DMARC ou autodiscover pouvaient apparaître comme non résolus, alors que les vérifications manuelles montraient que la configuration DNS était correcte. Le contournement consistait à redémarrer uniquement le service grommunio-admin-api, puis à forcer le rechargement du navigateur. Dans le ticket ouvert, le problème est bien décrit comme un état incohérent de l’interface ou de l’API, plutôt qu’une véritable erreur DNS.

Ces deux épisodes sont utiles à raconter, car ils évitent de présenter l’installation comme une histoire simple et parfaite. Il y a eu des obstacles. Mais il y a aussi eu une documentation du problème, un échange constructif et actif avec la communauté, une correction rapide pour le bug bloquant, et un contournement clair pour le second.

Surveiller le serveur : ne pas seulement l’installer, mais le suivre

Une fois le serveur fonctionnel, il ne suffisait pas de constater que le webmail fonctionnait. Un serveur de messagerie doit être surveillé. Il doit envoyer, recevoir, signer les messages, exposer les bons services, rester joignable et ne pas se dégrader silencieusement.

Un agent Beszel a donc été ajouté (merci à Nidouille pour l’information), pour assurer la surveillance de l’état du serveur. L’idée est de pouvoir suivre les ressources et le comportement général de la machine sans devoir se connecter en permanence dessus.

Des alertes ont aussi été mises en place pour vérifier que les services importants restent bien actifs. C’est un point essentiel dans une démarche d’auto-hébergement : l’autonomie n’a de valeur que si l’on sait quand quelque chose ne fonctionne plus. Un serveur silencieux n’est pas forcément un serveur en bonne santé.

Les premiers usages : webmail, smartphone et ordinateur

Une fois les réglages terminés, les tests ont été faits depuis plusieurs environnements : le webmail, un smartphone et un ordinateur. Le logiciel de lecture des courriels a pu être configuré en mode Exchange. Le webmail fonctionne. Les services essentiels : courriels, calendrier, contacts, répondent correctement.

Le résultat est franchement encourageant pour une solution open source. Il ne s’agit pas encore de conclure que tout est résolu, ni que l’expérience sera parfaite dans la durée. Mais pour une installation auto-hébergée, sur une infrastructure personnelle, avec une solution européenne compatible avec des usages « modernes », le résultat est déjà très concret.

Ce point mérite d’être souligné : il ne s’agit pas seulement d’avoir « réussi à envoyer et recevoir un courriel ». Il s’agit d’avoir mis en place une infrastructure capable de gérer les usages quotidiens d’une messagerie : recevoir, envoyer, synchroniser, consulter depuis plusieurs appareils, signer les messages, passer les contrôles de base des grands « opérateurs », et s’offrir une interface web exploitable.

Le point noir : la sauvegarde

C’est le grand point noir de cette mise en production. Une messagerie personnelle ou professionnelle concentre des éléments sensibles : correspondances, pièces jointes, contacts, calendriers, historique. Tant que la sauvegarde n’est pas pensée, testée et restaurable, l’installation ne peut pas être considérée comme pleinement mature.

Ce n’est pas un détail secondaire. Dans un service de courriel, perdre les données peut être plus grave qu’une panne temporaire. Cette partie devra donc être traitée avant toute bascule sérieuse et durable. L’installation fonctionne, mais la sauvegarde reste l’étape qui sépare encore l’expérimentation avancée d’une vraie exploitation de long terme.

Une bascule possible, mais pas encore décidée

À ce stade, il serait prématuré de me séparer définitivement de Proton Mail. La solution grommunio va plutôt être testée sur plusieurs mois. Ce temps long permettra de répondre à des questions plus importantes que la simple réussite de l’installation initiale :

• La maintenance est-elle soutenable ?
• L’espace disque reste-t-il maîtrisé ?
• Les mises à jour se passent-elles correctement ?
• Les courriels continuent-ils d’arriver proprement chez Gmail, Yahoo et les autres ?
• Le serveur reste-t-il stable après plusieurs semaines ou plusieurs mois ?
• Les alertes suffisent-elles à repérer les problèmes ?
• La sauvegarde peut-elle être mise en place proprement ?
• Qu’est-ce que cela implique dans ma vie, le jour où un service plante et que mon serveur n’est plus accessible pendant plusieurs jours ?

Si ces points se confirment, alors la question de la bascule deviendra sérieuse. Mais elle ne doit pas être posée trop tôt. La souveraineté numérique ne consiste pas à quitter un service fiable pour une installation fragile. Elle consiste à construire progressivement une alternative que l’on comprend, que l’on maîtrise et que l’on peut maintenir.

Conclusion

Cette installation montre aussi une évolution personnelle dans la maîtrise de l’environnement technique. Il ne s’agit pas d’un parcours d’ingénieur système, ni d’un métier exercé au quotidien. Mais à force d’installer, de lire, de casser, de réparer, de documenter et de questionner, certains mécanismes deviennent plus lisibles.

Ce qui semblait totalement opaque il y a quelque temps : DNS, reverse proxy, DKIM, pare-feu, services système, logs, certificats, ports… devient progressivement compréhensible. Pas simple, pas automatique, mais concret.

C’est peut-être l’enseignement le plus intéressant. Une solution comme grommunio n’est pas encore faite pour le grand public. Elle demande trop de préparation, trop de vocabulaire technique et trop de vigilance pour être recommandée à n’importe qui. En revanche, pour des curieux, des amateurs motivés, des personnes qui acceptent d’apprendre et de documenter leur chemin, elle rend quelque chose de très important à nouveau possible : construire une infrastructure de courriel plus résiliente, mieux comprise, mieux surveillée, et moins dépendante d’un point unique de défaillance. L’enjeu n’est pas de désigner un ennemi, mais de retrouver une capacité d’action. Savoir où sont ses données, comprendre comment circule un message, pouvoir maintenir ses propres services, anticiper les pannes et organiser ses sauvegardes : tout cela participe d’une culture numérique plus robuste.

L’expérience ne dit donc pas que tout le monde devrait installer grommunio demain matin. Elle montre plutôt qu’une voie existe. Elle reste exigeante, imparfaite, parfois austère, mais elle devient praticable. Dans un monde où une grande partie de nos communications repose sur quelques infrastructures très concentrées, cette possibilité n’a rien d’anecdotique : elle participe d’une logique de résilience, d’apprentissage et de diversification des chemins numériques.

Cette expérience ne cherche pas à convaincre chacun d’installer grommunio dès demain matin. Elle montre plutôt qu’une voie alternative existe : exigeante, imparfaite, parfois austère, mais elle n’est plus réservée aux seuls spécialistes. Des amateurs motivés peuvent s’y aventurer, tout comme des professionnels souhaitant mieux maîtriser leur environnement technique. Dans un monde où une grande partie de nos échanges dépend de quelques plateformes et de quelques acteurs très concentrés, cette possibilité n’a rien d’anecdotique : elle participe d’une logique de résilience, d’apprentissage et de diversification des outils.

L’article Courriel, souveraineté et résilience : installation et retour d’expérience avec grommunio est apparu en premier sur Souverain.

Début janvier 2026, la Commission européenne a lancé un appel à contributions sur les écosystèmes numériques open source. L’expression peut sembler abstraite. Elle désigne pourtant quelque chose de très concret : les logiciels, composants, infrastructures et communautés qui permettent de construire des services numériques ouverts, auditables, réutilisables et modifiables. La consultation devait nourrir une future « Stratégie européenne pour un écosystème numérique ouvert » (European Open Digital Ecosystem Strategy), pensée comme une stratégie européenne pour renforcer l’open source au service de la souveraineté numérique.

La Commission met ici le doigt sur une réalité souvent invisible : l’open source forme déjà une partie essentielle de notre infrastructure numérique. Elle rappelle que l’open source soutient une part immense de l’économie numérique : entre 70 % et 90 % du code utilisé dans les systèmes logiciels reposerait sur des composants ouverts. Autrement dit, l’open source n’est pas une affaire secondaire. Il est déjà dans les administrations, les entreprises, les services de cloud, les outils de cybersécurité, les systèmes d’intelligence artificielle, les sites web, les applications métiers et les infrastructures critiques.

Le paradoxe européen

L’Europe sait produire du code, former des ingénieurs et faire émerger des communautés techniques solides, mais elle peine encore à transformer cette compétence en puissance économique et stratégique.

C’est le paradoxe que la Commission met en lumière. Les communautés européennes contribuent à de nombreux projets open source, mais une partie importante de la valeur créée finit captée hors d’Europe, souvent par de grands acteurs technologiques étrangers. Cette situation n’est pas seulement économique. Elle touche à la capacité de l’Europe à choisir ses technologies, à sécuriser ses chaînes logicielles, à éviter l’enfermement propriétaire et à garder le contrôle de son infrastructure numérique.

Ce point mérite d’être expliqué simplement. Quand une administration, une école, un hôpital ou une entreprise utilise un service numérique, elle ne dépend pas seulement de l’interface affichée à l’écran. Elle dépend aussi du cloud qui héberge les données, du système d’authentification, des logiciels de gestion, des outils de développement, des mises à jour de sécurité, des contrats de support et parfois même de plateformes étrangères qui deviennent difficiles à quitter.

C’est ici que la question de la souveraineté numérique devient très concrète. Il ne s’agit pas de refuser toute technologie venue d’ailleurs. Il s’agit de ne pas se retrouver dans une position où les choix essentiels, les prix, les conditions d’accès, la sécurité, l’évolution des logiciels, l’exploitation des données se déplacent hors de notre portée, entre les mains d’acteurs qui n’ont ni les mêmes obligations, ni les mêmes intérêts, ni les mêmes comptes à rendre.

Une consultation discrète, mais stratégique

La consultation européenne s’est déroulée du 6 janvier au 3 février 2026. Elle s’adressait aux communautés open source, aux développeurs, aux entreprises, aux administrations publiques, aux industriels et aux institutions de recherche. La Commission cherchait notamment à identifier les freins à l’adoption de l’open source, à documenter sa valeur ajoutée et à recueillir des propositions d’actions concrètes au niveau européen.

Le périmètre annoncé est très large : technologies Internet, cloud, edge computing, intelligence artificielle, cybersécurité, matériel ouvert, logiciels industriels, objets connectés, automobile et industrie manufacturière. Ce détail est essentiel. Bruxelles ne parle plus seulement de logiciels libres pour équiper des postes de travail. Elle regarde l’open source comme une couche stratégique de l’économie numérique européenne.

La future stratégie doit aussi s’inscrire dans une continuité. La Commission avait déjà adopté une stratégie open source interne pour la période 2020-2023, afin de mieux utiliser, publier et soutenir les logiciels libres dans son propre environnement numérique. La nouvelle initiative élargit l’ambition : il ne s’agit plus seulement de la Commission, mais de l’écosystème européen dans son ensemble.

Pourquoi cela concerne tout le monde

Pour le grand public, l’open source peut paraître lointain. Pourtant, il touche à des questions très ordinaires.

Quand une collectivité veut changer de logiciel sans être prisonnière d’un fournisseur unique, l’open source peut lui donner une marge de manœuvre. Quand un hôpital veut auditer un outil critique, le code ouvert peut faciliter la transparence. Quand une PME veut développer un service sans dépendre intégralement d’une plateforme fermée, des composants ouverts peuvent lui permettre de construire plus librement. Quand une administration veut préserver des données sensibles, la maîtrise des briques logicielles et de l’hébergement devient un enjeu de confiance.

La Commission européenne rattache explicitement l’open source à la souveraineté numérique, à la compétitivité et à la cybersécurité. Elle estime que la dépendance de l’Europe à des technologies numériques non européennes limite le choix des utilisateurs, affaiblit la compétitivité des entreprises et peut créer des risques pour la sécurité des chaînes d’approvisionnement.

Ce diagnostic rejoint un constat plus large sur le cloud. Une étude publiée par le Parlement européen en décembre 2025 rappelle qu’AWS, Microsoft Azure et Google Cloud détiennent environ 70 % du marché européen de l’infrastructure cloud, tandis que la part cumulée des fournisseurs européens est tombée autour de 13 %. Le cloud étant devenu la base de nombreuses applications « modernes », cette concentration crée une dépendance stratégique majeure.

L’open source n’est pas « gratuit », c’est un commun numérique !

L’erreur fréquente consiste à réduire l’open source à du logiciel gratuit. En réalité, l’enjeu est plus profond. Un logiciel open source peut être utilisé, étudié, modifié et redistribué. Cette ouverture crée des communs numériques : des ressources partagées, maintenues par des communautés, des entreprises, des chercheurs ou des administrations.

Mais un commun ne vit pas tout seul. Il faut des développeurs, du temps, de la documentation, des audits de sécurité, des infrastructures d’hébergement, des formations, du support, des entreprises capables de vendre des services fiables et des administrations capables d’acheter autrement.

C’est précisément l’un des points faibles identifiés par la Commission : financer seulement la recherche ou les projets pilotes ne suffit pas toujours à faire grandir des solutions open source jusqu’au marché. Les acteurs européens rencontrent des obstacles d’accès au capital, à la commande publique et aux infrastructures nécessaires au passage à l’échelle.

L’étude commandée par la Commission européenne en 2021 à Fraunhofer ISI et OpenForum Europe avait déjà montré le poids économique de l’open source. Elle estimait sa contribution au PIB européen entre 65 et 95 milliards d’euros. Ce chiffre donne une idée de l’ampleur du sujet : l’open source n’est pas seulement une autre façon de concevoir des logiciels, c’est devenu l’une des infrastructures de l’économie numérique.

Un autre signal, plus discret mais très parlant, vient du catalogue European OpenSource. Attention : il ne s’agit pas d’un catalogue officiel de la Commission européenne, mais d’une initiative non gouvernementale qui se présente comme une plateforme destinée à recenser et mettre en visibilité des projets open source portés par des développeurs, des communautés ou des organisations européennes. Le site revendique un objectif clair : construire un catalogue européen, fédérer une communauté et renforcer la souveraineté numérique. Dans ses dernières entrées, trois projets français apparaissent côte à côte : LaSuite Docs, développée par la DINUM dans le cadre de La Suite numérique de l’État, LemonLDAP::NG, solution française d’authentification et de gestion d’accès utilisée par des ministères depuis 2004 et Symfony, présenté dans le catalogue comme un framework PHP créé en France en 2005.
Ce rapprochement est intéressant : il place dans le même paysage un outil porté par l’État, une brique d’identité numérique et un framework web largement utilisé par les développeurs. Trois objets très différents, mais une même logique : des briques techniques ouvertes, maintenues en Europe, qui peuvent contribuer à réduire la dépendance aux grandes plateformes fermées.

Le cas Symfony : une histoire française qui dit beaucoup

Pour comprendre ce que peut être un commun numérique européen, il suffit de regarder du côté de Symfony.

Il faut d’abord corriger un point important : Symfony n’est pas d’abord une entreprise. Symfony est un framework PHP open source : c’est-à-dire un ensemble d’outils qui aide les développeurs à créer des sites web et des applications. Le site officiel le présente à la fois comme un ensemble de composants PHP, un framework web, une philosophie et une communauté.

Mais derrière Symfony, il y a bien une histoire entrepreneuriale française. Fabien Potencier fonde le projet Symfony au milieu des années 2000. Son profil officiel SymfonyConnect indique qu’il a fondé Sensio en 1998, devenue SensioLabs en 2012, puis Symfony SAS en 2018, l’entreprise chargée de soutenir le projet Symfony, la communauté, les conférences, la certification et certains services destinés aux développeurs.

SensioLabs raconte de son côté une trajectoire très française : Sensio naît à Paris en 1998 autour de Fabien Potencier et Grégory Pascal, le framework interne devient Symfony en 2005 et est publié en open source. SensioLabs est créée en 2012 pour soutenir le développement de Symfony et ses usages professionnels.

L’histoire devient encore plus intéressante en 2018 et 2019. Symfony et Blackfire deviennent des sociétés indépendantes, tandis que SensioLabs se rapproche ensuite du groupe Smile, présenté comme un acteur européen majeur de l’open source. SensioLabs indique qu’elle fait pleinement partie du groupe Smile depuis début 2021, avec Ludovic Duval à sa direction générale.

Cette trajectoire a son importance. Dans un secteur où les technologies européennes prometteuses peuvent rapidement passer sous contrôle étranger, l’histoire de Symfony montre qu’un projet ouvert peut grandir à l’international tout en conservant un ancrage français et européen. Symfony SAS reste installée en France, SensioLabs est née à Paris et fait aujourd’hui partie de Smile, groupe français. Ce n’est pas un détail : cela montre qu’il est encore possible de bâtir des communs numériques ambitieux sans les voir immédiatement passer sous le contrôle d’intérêts extra-européens.

Symfony n’est donc pas une « entreprise française » au sens strict du terme. C’est un projet open source mondial né d’une initiative française, soutenu par une société française, Symfony SAS, par SensioLabs, et désormais inscrit dans un écosystème où le groupe Smile joue un rôle important. SensioLabs revendique plus de 3 000 contributeurs dans la communauté Symfony.

Ce cas est précieux pour la souveraineté numérique, car il montre ce que l’Europe sait déjà faire : créer une technologie ouverte, la faire adopter internationalement, fédérer une communauté, bâtir des services professionnels autour d’elle et maintenir un lien entre les communs numériques et le tissu économique local.

Le véritable enjeu : passer de l’exception à la stratégie

Symfony n’est pas seul. L’Europe compte de nombreux projets, entreprises, communautés et institutions impliqués dans l’open source. Mais le problème est rarement l’absence de talent. Le problème est plutôt la capacité à organiser ce talent, à le financer dans la durée, à le faire entrer dans les achats publics et à lui donner une infrastructure européenne solide.

C’est là que la stratégie européenne peut devenir intéressante. La Commission évoque une approche couvrant tout le cycle de vie de l’open source : développement, maintenance, sécurité, durabilité, adoption, intégration au marché. Cette vision est plus réaliste qu’une simple annonce politique. Elle reconnaît qu’un logiciel libre utile doit être entretenu, sécurisé, documenté et soutenu économiquement.

L’Europe a déjà commencé à structurer ce sujet avec le consortium pour une infrastructure numérique européenne (l’EDIC Digital Commons), lancé en décembre 2025 avec la France, l’Allemagne, les Pays-Bas et l’Italie. Cette structure européenne vise à soutenir les communs numériques, à faciliter l’accès aux financements, à accompagner les communautés open source et à accélérer des projets transfrontaliers comme un espace de travail numérique européen.

La question centrale devient alors politique : l’Europe veut-elle seulement encourager l’open source, ou veut-elle en faire un pilier de sa puissance numérique ?

Une stratégie ne suffira pas

Il faut rester prudent. À ce stade, l’initiative européenne relève d’une stratégie, non d’une loi contraignante. Elle ne garantit pas à elle seule des budgets suffisants, des règles d’achat public transformées ou une préférence assumée pour les solutions ouvertes européennes.

Mais elle marque une évolution du discours institutionnel : l’open source n’est plus seulement présenté comme un outil d’efficacité ou d’innovation. Il est désormais rattaché à la souveraineté, à la sécurité, à la compétitivité et à la résilience. Pour un continent qui dépend massivement de plateformes étrangères, ce « changement de ton » n’est pas anodin.

Le risque serait de produire une stratégie de plus, élégante dans ses intentions, mais faible dans ses moyens. L’opportunité serait d’utiliser cette stratégie pour financer la maintenance des composants critiques, soutenir les entreprises européennes du libre, former les acheteurs publics, sécuriser les chaînes logicielles, créer des infrastructures d’hébergement européennes et reconnaître les communs numériques comme des actifs stratégiques.

Un sujet de souveraineté, donc un sujet démocratique

La souveraineté numérique commence souvent dans des choix techniques. Elle suppose une vision, une stratégie, mais ses conséquences dépassent largement le monde des spécialistes. Elle touche à la capacité d’un pays, d’une administration, d’une entreprise ou d’un citoyen à comprendre et maîtriser les outils dont il dépend.

Un logiciel fermé peut être excellent. Une technologie américaine ou asiatique peut être performante. La question n’est pas morale. Elle est stratégique. Que reste-t-il comme liberté de choix lorsque toutes les couches essentielles du numérique : cloud, logiciels métiers, IA, cybersécurité, développement, hébergement, sont contrôlées par quelques acteurs dominants situés hors d’Europe ?

L’open source n’apporte pas, à lui seul, une réponse à tous les problèmes liés à la souveraineté numérique et ce n’est d’ailleurs pas le propos dans cet article. Il ne remplace ni l’investissement, ni l’industrialisation, ni la compétence, ni la volonté politique. Mais il offre une base dont les règles peuvent être lues, discutées, adaptées, plutôt que subies. Il peut permettre à l’Europe de reconstruire des marges de manœuvre là où la dépendance s’est installée par confort, par habitude ou par manque d’alternative crédible.

C’est pourquoi la consultation lancée par la Commission européenne mérite d’être suivie de près. Derrière les mots techniques : open source, composants, frameworks, écosystèmes, cloud, edge, open hardware, se dessine une question de puissance : l’Europe veut-elle rester dépendante d’architectures numériques conçues ailleurs, ou retrouver la maîtrise des outils qui organiseront son avenir ?

Symfony, SensioLabs, Smile et d’autres acteurs européens montrent qu’une autre voie existe déjà. Elle n’a rien d’utopique. Elle demande seulement de reconnaître que les communs numériques ne sont pas des accessoires. Ils sont peut-être l’une des conditions les plus concrètes de notre souveraineté.

L’article Open source : l’Europe veut transformer ses communs numériques en levier de souveraineté est apparu en premier sur Souverain.

Car les photos ne sont pas de simples fichiers. Elles sont nos voyages, nos enfants, nos familles, nos visages, nos fêtes, nos absents, nos instants et nos grands souvenirs. Elles racontent, parfois mieux que nous, ce que nous avons vécu. Il s’agit presque d’une expérience affective, au sens le plus profond du terme !

Depuis longtemps, je voulais sortir de Google Photos. Pas par antiaméricanisme primaire. Pas par réflexe pavlovien contre les GAFAM. Mais parce qu’il y avait, au fond, une incohérence qui devenait de plus en plus difficile à accepter.

D’un côté, je confiais à Google une partie considérable de mon intimité. De l’autre, pour disposer de suffisamment d’espace, je devais payer. Payer n’est pas le problème de fond : il est normal qu’un service de stockage ait un coût. Mais payer tout en alimentant un système dont le modèle économique repose largement sur la captation de données personnelles me donnait l’impression d’une double peine.

Je donnais ma vie privée, et je payais en plus pour que quelqu’un d’autre la garde, sans même savoir précisément comment mes données pouvaient être exploitées.

Cette situation me mettait mal à l’aise. Pourtant, je ne voyais pas d’alternative suffisamment simple, fluide, familiale et crédible pour franchir le pas. Google Photos a un immense avantage : cela fonctionne. C’est simple, rapide, bien intégré, et suffisamment intuitif pour être adopté par des personnes qui n’ont aucune envie de passer leur week-end à comprendre le fonctionnement d’un serveur ou d’une sauvegarde.

C’est précisément là que se situe toute la difficulté de la souveraineté numérique : il ne suffit pas d’avoir raison sur le principe. Il faut aussi proposer une expérience qui ne donne pas envie de revenir en arrière au bout de quelques jours.

Immich : la solution que je suivais depuis longtemps

J’ai connu Immich il y a déjà un moment, presque depuis ses débuts. Pour ceux qui ne connaissent pas encore, Immich est une solution open source de gestion et de sauvegarde de photos et vidéos, souvent présentée comme l’une des alternatives les plus sérieuses à Google Photos.

Je l’ai vue évoluer, progresser, se stabiliser, gagner en fonctionnalités. Et lorsque j’ai vu qu’il était possible de l’installer en auto-hébergement depuis YunoHost, j’ai naturellement foncé.

Sur le papier, c’était exactement ce que je cherchais : reprendre la main sur mes photos, héberger mes données moi-même, ne plus dépendre d’une plateforme américaine, et construire pas à pas une forme d’autonomie numérique concrète.

Mais dans la pratique, je me suis heurté à plusieurs limites. Non pas parce qu’Immich serait une mauvaise solution. Au contraire. Mais parce que l’auto-hébergement, surtout lorsqu’il s’agit de photos familiales, demande un niveau de responsabilité que je ne me sentais pas encore prêt à assumer entièrement.

Le problème du format HEIC : la technique face aux habitudes

Lors de mes premiers essais, le paquet Immich disponible sur YunoHost ne gérait pas correctement le format HEIC, très utilisé par certains smartphones. Il existait bien une solution : modifier les paramètres de son smartphone pour enregistrer les photos en .JPG. De mon côté, cela ne posait pas vraiment de problème. J’avais même trouvé un outil pratique, permettant de convertir par lots des fichiers HEIC en JPG.

Mais je ne pouvais pas raisonnablement demander la même chose à tout le monde.

C’est un point essentiel. Quand on veut faire adopter une solution alternative à sa famille, à ses proches, à un groupe, il faut éviter de transformer une migration en parcours du combattant. Ce qui peut sembler simple pour une personne habituée à bidouiller devient vite pénible pour quelqu’un qui veut simplement retrouver ses photos, les partager, les classer et continuer sa vie.

Changer les habitudes demande de la douceur. Il faut que la transition donne envie. Il faut qu’elle provoque ce petit effet : « Ah, mais en fait c’était simple. Pourquoi ne l’ai-je pas fait plus tôt ? »

C’est seulement à cette condition que l’on peut espérer convaincre autour de soi. Sinon, on obtient l’effet inverse : frustration, rejet, et retour immédiat vers la solution dominante. Le meilleur discours sur la souveraineté numérique ne résiste pas longtemps à une expérience utilisateur ratée.

Depuis mes premiers essais, Immich a évolué et certaines difficultés techniques ont été levées ou améliorées. Mais d’autres problèmes, plus structurels, demeuraient de mon côté.

Auto-héberger les photos des autres, c’est porter une responsabilité

Mon serveur personnel héberge déjà plusieurs services. Avec le temps, l’espace disque disponible diminuait, la maintenance devenait plus sérieuse, et je prenais progressivement conscience d’une chose : les photos ne sont pas des données comme les autres.

Si j’héberge seulement mes propres fichiers, je peux assumer mes erreurs. Si je rate une sauvegarde, si je dois tout réinstaller, si je casse quelque chose, j’en suis le premier responsable et la première victime.

Mais si j’embarque ma famille ou des membres de mes groupes dans cette aventure, la situation change complètement. Je deviens responsable, au moins moralement, de leurs souvenirs numériques.

Et là, je ne voulais pas jouer à l’apprenti sorcier.

Je débute encore dans l’auto-hébergement. Je progresse, j’apprends, je mets en place des services, je découvre les contraintes. Mais je n’ai pas encore réalisé de véritables stress tests ou crash tests : simuler une panne complète, restaurer proprement les sauvegardes, vérifier que tout repart comme prévu, documenter chaque étape.

Tant que ce travail n’est pas fait sérieusement, je ne veux pas promettre à d’autres personnes que leur mémoire photographique est en sécurité chez moi.

Le scénario que je voulais absolument éviter, c’est celui où je dois dire : « Désolé, j’ai fait une erreur, je n’arrive pas à restaurer, je pensais que la sauvegarde fonctionnait. »

Dans l’absolu, nous ne parlons pas de données vitales. Mais nous parlons quand même de souvenirs. Et surtout, un échec de ce type produirait un effet désastreux : « C’est bien gentil, les alternatives souveraines, mais avec Google Photos au moins, ça n’arrive pas. »

Évidemment, ce n’est pas totalement vrai. Les grandes plateformes peuvent aussi connaître des bugs, des pertes, des corruptions ou des erreurs. Mais dans l’imaginaire collectif, elles restent associées au professionnalisme, à la fiabilité et à la simplicité. Face à cela, une alternative doit être au moins aussi sérieuse dans son exécution.

La piste Docker sur YunoHost : fonctionnelle, mais trop fragile pour moi

J’ai aussi testé une installation d’Immich via Docker sur YunoHost, grâce à un paquet communautaire disponible depuis le site Codeberg.

Je veux être clair : je respecte profondément ce type d’initiative. Ce sont souvent ces projets communautaires qui permettent de combler les manques, d’expérimenter, d’ouvrir la voie. Et dans mon cas, la solution fonctionnait.

Mais elle reposait sur un équilibre qui ne me convenait pas pour un usage familial durable. La gestion des mises à jour n’était pas aussi fluide que je le souhaitais. Il fallait suivre, vérifier, attendre que le paquet soit mis à jour après les évolutions officielles d’Immich. Le tout reposait beaucoup sur une personne ou sur un petit effort communautaire.

Pour tester, très bien. Pour porter les souvenirs de plusieurs personnes sur le long terme, je n’étais pas à l’aise.

Le coût réel de l’auto-hébergement

Il y avait aussi la question du coût.

On présente parfois l’auto-hébergement comme une solution gratuite ou presque gratuite. C’est une illusion. L’auto-hébergement peut être formidable, mais il a un coût : matériel, disques, énergie, sauvegardes, temps, maintenance, remplacements, pannes éventuelles.

Dans le cas des photos, il faut prévoir de l’espace disque. Beaucoup d’espace disque. Et surtout, il faut prévoir la sauvegarde. Avoir un disque plein de souvenirs sans stratégie de sauvegarde solide n’est pas une solution souveraine : c’est une bombe à retardement (et des repas bien animés en famille…).

Si l’on veut convaincre son entourage de quitter Google Photos, il faut pouvoir promettre une certaine aisance. Certains paient déjà pour du stockage Google ou iCloud. Ils peuvent donc légitimement attendre une alternative qui ne les oblige pas à compter chaque mégaoctet.

De mon côté, je n’étais pas encore certain de maîtriser complètement le calcul : combien d’espace acheter ? Quelle redondance ? Quelle sauvegarde externe ? Quel coût annuel ? Quelle restauration en cas de panne ?

Je ne dis pas que je ne le ferai jamais. Au contraire, je pense que cette voie reste passionnante. Mais avant de la proposer à d’autres, je veux maîtriser la sauvegarde, la restauration, et le coût complet de l’opération.

Je ne me vois pas faire payer, même indirectement, pour un service qui ne serait pas encore à la hauteur de ce que j’attends moi-même.

Dernière limite : mon serveur dort la nuit

Il y avait enfin un point très simple : mon serveur est éteint la nuit.

C’est un choix que j’assume pour l’instant. Mais je ne voulais pas l’imposer aux autres membres de mes groupes. Une galerie photo familiale doit être disponible quand les gens en ont besoin, pas uniquement quand mon serveur personnel est allumé.

Si quelqu’un veut consulter ou partager des photos tard le soir, tôt le matin, en vacances ou à l’autre bout du monde, il ne doit pas dépendre de mes horaires d’alimentation électrique.

Bien sûr, je pourrais changer de stratégie, laisser le serveur allumé 24 h/24 et 7 j/7, revoir mon installation, intégrer ce coût électrique dans mon calcul global. Je n’y suis pas fermé. Mais je voulais le faire sérieusement, pas sous la pression d’un service déjà utilisé par d’autres.

C’est à ce moment-là que PixelUnion est revenu dans mon esprit.

PixelUnion : l’alternative hébergée que j’avais laissée de côté

Il y a quelques mois, j’avais vu passer PixelUnion.eu, un service européen qui propose une instance basée sur Immich, avec la gestion technique, la maintenance et l’hébergement pris en charge.

Je ne sais pas exactement pourquoi, mais l’idée était restée dans un coin de ma tête. Puis un jour, je suis revenu dessus plus sérieusement.

Et là, j’ai compris que PixelUnion répondait à une partie très précise de mon problème : je voulais Immich, mais je ne voulais pas encore assumer seul toute l’infrastructure pour ma famille et mes groupes.

Techniquement, c’était proche de ce que je voulais faire moi-même sur mon serveur YunoHost, mais avec une couche professionnelle pour l’hébergement, la disponibilité, la maintenance et la gestion de l’instance.

Restait la question du prix.

Le déclic du prix : ma règle de trois

Au départ, j’ai failli passer à côté pour une raison presque ridicule : j’ai mal lu les tarifs.

Je payais jusqu’ici 19,99 € par an chez Google pour 100 Go. En regardant PixelUnion, j’ai vu une offre à 29,50 € par an. Réflexe immédiat : « C’est plus cher que Google. Je ne changerai que si c’est au moins au même prix. »

Sauf que je n’avais pas fait attention à l’espace proposé : 150 Go.

Une simple règle de trois change alors complètement la perception. Rapporté au prix du Go, l’offre devient comparable à celle de Google. Certes, je n’avais pas forcément besoin immédiatement de 150 Go. Certes, cela représente presque 10 € de plus par an. Mais si l’objectif est d’embarquer progressivement la famille et certains groupes, cet espace supplémentaire me donnerait de la souplesse.

Et surtout, il change la nature de la dépense. Je ne paye plus seulement pour du stockage. Je paye pour une alternative européenne, basée sur une solution open source, avec une logique de confidentialité plus alignée sur ce que je défends.

À partir de là, le déclic s’est produit.

Ce qui m’a rassuré

J’ai commencé à explorer plus sérieusement l’offre, les pages d’aide, les engagements affichés, la documentation, la politique de confidentialité, les outils de migration.

Plusieurs éléments m’ont plu.

D’abord, PixelUnion insiste clairement sur la confidentialité et la sécurité des données. On n’est pas dans le même rapport qu’avec Google. Ici, l’idée n’est pas de proposer un service « gratuit » pour mieux capter l’utilisateur dans un écosystème global. Le modèle est plus lisible : vous payez pour un service, et ce service consiste à stocker vos photos.

Ensuite, il existe un outil de migration depuis Google Photos, documenté.

Il existe également une documentation pour migrer depuis iCloud Photos.

C’était un point important pour moi. Une alternative crédible doit prévoir la sortie. Elle doit comprendre que les utilisateurs viennent de quelque part, avec des années d’historique, des albums, des habitudes, des classements, parfois même des erreurs accumulées.

J’ai aussi apprécié l’ancrage européen de PixelUnion. L’entreprise est basée aux Pays-Bas, les serveurs sont annoncés en Europe (en Allemagne et en Finlande), le service s’inscrit dans le cadre européen, et la solution repose sur Immich, un projet open source. Pour moi, ce n’est pas qu’un détail.

À chaque usage réel d’une solution de ce type, on renforce un peu plus l’écosystème. On crée de l’expérience, de la demande, des retours, des améliorations. On ne sort pas d’une dépendance en claquant des doigts, on en sort en construisant des usages crédibles, progressivement.

Autre détail qui n’en est pas un : le site est disponible en français. Cela peut sembler secondaire, mais c’est important. Pouvoir comprendre clairement ce que l’on achète, comment on migre, comment on administre, comment on invite des utilisateurs, c’est une marque de respect envers les clients.

Enfin, PixelUnion propose une page de statut publique.

Ce n’est pas spectaculaire, mais c’est rassurant. La transparence technique, même imparfaite, vaut mieux qu’un silence opaque. Suivez mon regard…

À ce stade, presque toutes les cases étaient cochées.

J’ai donc pris l’offre à 29,50 € par an

J’ai décidé de me lancer avec l’offre à 29,50 € par an. Mon idée était simple : tester sérieusement pendant un an, migrer mes propres photos, vérifier la fiabilité, observer les limites, puis envisager seulement ensuite de faire basculer plus largement ma famille.

Je ne voulais pas promettre trop vite. Je voulais d’abord éprouver la solution.

Car il faut bien commencer un jour. Si l’on attend que tout soit parfait pour quitter les grandes plateformes, on ne les quitte jamais. Mais si l’on part trop vite vers une solution mal maîtrisée, on fabrique de la déception. Toute la difficulté consiste à trouver le bon moment : celui où l’alternative n’est pas parfaite, mais suffisamment mûre pour être prise au sérieux.

La migration depuis Google Photos : techniquement réussie, mais pas forcément la méthode que je recommande

J’ai suivi le tutoriel proposé par PixelUnion pour migrer depuis Google Photos.

La procédure est claire. Elle s’appuie sur Google Takeout, puis sur l’outil de migration proposé par PixelUnion. Sur le plan technique, je n’ai pas rencontré de problème majeur. Tout s’est déroulé correctement.

Et pourtant, avec le recul, je ne recommande pas forcément cette méthode à tout le monde.

Non pas à cause de PixelUnion. Le problème vient plutôt de Google Takeout et de la manière dont Google exporte les photos, les albums et les métadonnées. Quand on a utilisé Google Photos pendant des années, avec des modifications, des classements, des albums, des traitements successifs, l’export ne redonne pas toujours une galerie qui ressemble parfaitement à ce que l’on avait dans l’interface Google Photos.

Résultat : après la migration, j’ai dû reprendre du temps pour ranger, reclasser et retrouver une organisation qui me convenait.

Avec l’expérience, je recommande une méthode plus simple, surtout si vous tenez à conserver une logique d’albums claire : depuis Google Photos, allez dans un album, cliquez sur les trois points en haut à droite, puis choisissez l’option « Tout télécharger ».

Cela prend un peu de temps au départ, mais cela peut en faire gagner beaucoup ensuite. Dans mon cas, j’ai eu l’impression de faire deux fois le travail : télécharger via Google Takeout, importer via l’outil de migration, puis retrier une partie de mes albums.

En téléchargeant album par album, on garde un peu mieux la main sur son organisation. C’est mon retour d’expérience, pas une vérité absolue. Chacun appréciera selon la taille de sa photothèque, son niveau d’exigence sur les albums et le temps qu’il souhaite y consacrer.

Partager avec la famille : simple et efficace

Une fois mes photos rangées comme je le souhaitais, j’ai commencé à partager certains albums avec des membres de ma famille.

Là, l’expérience a été très simple. Depuis l’interface administrateur, il suffit de créer un compte pour la personne concernée. Elle reçoit ensuite une invitation, crée son compte, et peut accéder aux éléments partagés.

Toutes ces étapes ont été réalisées en une après-midi. Et globalement, je dois le dire : c’était presque parfait.

Presque.

Le vrai point noir : l’application Immich sur iOS

Mise à jour du 28 septembre 2026 : depuis la rédaction de cet article, en avril 2026, l’application a bénéficié d’une importante mise à jour. Toute la critique présentée ci-dessous n’est donc plus d’actualité et c’est une excellente nouvelle.

Le principal point faible, à mes yeux, concerne aujourd’hui l’application Immich sur iOS.

Je ne parle pas ici d’un bug bloquant ou d’un problème de fiabilité majeur. Je parle d’expérience utilisateur. Et pour moi, c’est un sujet fondamental.

Sur Google Photos, lorsqu’on veut ajouter une photo à un album depuis l’iPhone, le chemin est très simple : on donne accès à sa bibliothèque, on se rend dans l’album voulu, on clique sur l’icône d’ajout, on sélectionne les photos, puis on valide. Les photos sont téléversées directement au bon endroit.

Sur Immich, c’est plus laborieux. Après avoir donné l’accès complet aux photos de l’iPhone, il faut aller dans « Bibliothèque », puis dans les photos « sur cet appareil », sélectionner les images, les envoyer sur le serveur, puis seulement ensuite les ajouter à l’album souhaité.

Cela fonctionne. Mais c’est trop compliqué.

Et c’est précisément ce type de friction qui peut faire échouer une migration dans un cadre familial. Pour un utilisateur motivé, ce n’est pas dramatique. Pour une adoption plus large, c’est un vrai sujet.

Je suis assez ferme sur ce point : si l’on veut que des alternatives comme Immich deviennent réellement crédibles face à Google Photos, l’ajout de photos à un album depuis un mobile doit être aussi simple, direct et naturel que chez Google.

Ce n’est pas, à proprement parler, une critique de PixelUnion. PixelUnion s’appuie sur Immich, l’application mobile relève du cœur du projet Immich. J’ai d’ailleurs remarqué un ticket sur leur instance GitHub qui signale ce point et demande une amélioration de l’expérience utilisateur.

Je vais suivre le sujet et insister, car je pense que c’est une évolution nécessaire.

La souveraineté numérique ne se gagnera pas uniquement avec des arguments juridiques, politiques ou techniques. Elle se gagnera aussi dans les détails d’interface et dans l’expérience utilisateur qu’elle propose.

Une alternative sérieuse, pas encore parfaite

Après cette migration, mon sentiment est assez clair : oui, il est désormais possible de quitter Google Photos.

Pas pour tout le monde, pas dans tous les cas, pas sans effort, pas sans quelques compromis. Mais c’est possible. Et surtout, cela devient réaliste.

PixelUnion n’est pas une solution magique. Immich n’est pas encore parfait. L’expérience mobile doit encore progresser. La migration depuis Google Photos peut demander de la méthode. Il faut accepter de tester, de comparer, de se faire son avis.

Mais l’essentiel est là : une alternative existe. Elle est européenne, elle s’appuie sur une solution open source, elle propose une offre gratuite de 16 Go pour tester, et ses tarifs ne sont pas déconnectés de ceux de Google, lorsqu’on les rapporte à l’espace proposé.

Ce point est important : quitter Google ne signifie pas forcément payer beaucoup plus cher. Dans mon cas, la différence annuelle est modeste, et elle finance un service dont le modèle me semble plus cohérent avec mes convictions.

Je ne prétends pas que tout le monde doit faire le même choix. Je dis simplement qu’il est désormais possible d’essayer sérieusement.

Le code promo SOUVERAIN, en toute transparence

Comme j’ai trouvé l’équipe PixelUnion accessible, transparente et ouverte à l’échange, je les ai contactés. De cette discussion est né un code promo permettant d’obtenir trois mois gratuits sur une offre payante :

SOUVERAIN

Je précise immédiatement un point important : il n’y a aucun accord commercial entre PixelUnion et moi. Je ne suis pas rémunéré pour écrire cet article. Je reste libre de dire ce que je pense de la solution, y compris ses limites.

Ce code est simplement le résultat d’un échange, d’un intérêt commun pour une alternative européenne crédible, et d’une volonté de permettre à ceux qui le souhaitent de tester plus facilement.

PixelUnion propose également une offre gratuite de 16 Go. Pour ceux qui hésitent, c’est probablement le meilleur point de départ : tester, essayer, importer quelques albums, inviter un proche, voir si l’expérience convient.

Conclusion : partir de Google Photos n’est plus un saut dans le vide

Pendant longtemps, quitter Google Photos me semblait possible en théorie, mais difficile en pratique. Je connaissais Immich, je croyais au projet, mais je ne voulais pas encore porter seul toute la responsabilité technique d’un service familial.

PixelUnion m’a offert une voie intermédiaire : ne plus dépendre de Google Photos, bénéficier de l’écosystème Immich, rester dans un cadre européen, sans devoir immédiatement assumer l’intégralité de l’infrastructure.

Ce n’est pas la seule voie. Ce n’est peut-être pas la meilleure pour tout le monde. Certains préféreront l’auto-hébergement complet. D’autres attendront encore. D’autres choisiront une autre alternative.

Mais c’est précisément cela, l’enjeu : retrouver un choix.

La souveraineté numérique ne consiste pas à remplacer une dépendance par une autre, ni à imposer une solution unique à tout le monde. Elle consiste à rouvrir des chemins, à rendre les alternatives praticables, à permettre aux citoyens de reprendre progressivement la main sur leurs usages.

Mes photos ne sont pas de simples données. Elles sont une partie de mon histoire personnelle et familiale. Les confier à une infrastructure plus respectueuse, plus lisible et plus proche de mes valeurs n’est pas qu’un détail technique. C’est un petit acte d’autonomie.

Imparfait, certes. Mais réel.

Et c’est souvent comme cela que commencent les changements durables.

Si vous avez testé PixelUnion, Immich, l’auto-hébergement ou une autre alternative à Google Photos, vos retours d’expérience sont les bienvenus en commentaire. L’objectif n’est pas d’imposer une solution, mais de partager ce qui fonctionne, ce qui bloque, ce qui progresse, et ce qui peut aider chacun à reprendre un peu de contrôle sur sa vie numérique.

L’article Quitter Google Photos sans renoncer à ses souvenirs : mon passage vers PixelUnion et Immich est apparu en premier sur Souverain.

Cette démarche part d’une expérience simple et modeste : celle d’un citoyen qui a voulu comprendre un texte difficile, dense, parfois aride, et qui a dû s’y reprendre à trois fois avant de pouvoir vous en livrer une lecture claire. Non que l’auteur ait manqué de clarté ou de rigueur, bien au contraire. Mais parce que ce document, publié en anglais fin janvier par Axel Laniez pour Clever Cloud, est sa réponse à la consultation de la Commission européenne sur la réforme des règles de la commande publique européenne et qu’il apporte des éléments particulièrement éclairants : des notions juridiques, des concepts et références économiques, des raisonnements géopolitiques, et surtout une série de propositions concrètes sur la manière dont l’Europe pourrait enfin utiliser sa commande publique comme un levier de puissance. Il me fallait d’abord surmonter l’obstacle de la langue, avant d’entrer dans les concepts et leurs effets concrets. Si j’ai tenu à en proposer ici une interprétation en français, c’est aussi parce qu’un tel discours n’est pas suffisamment présent dans nos médias, alors même qu’il concerne directement l’avenir de notre économie, de notre autonomie stratégique et, en définitive, de notre capacité collective à reprendre la main sur notre destin européen.

Je précise d’emblée ce que cette démarche est, et ce qu’elle n’est pas. Je n’ai aucun intérêt économique, direct ou indirect, avec Clever Cloud. Je ne parle ni au nom de cette entreprise, ni au nom d’un secteur, ni au nom d’un parti. Je ne suis ni un élu, ni un entrepreneur du numérique, ni un expert du sérail politique ou bruxellois. Je suis simplement un citoyen attentif aux enjeux de souveraineté numérique, et capable d’en percevoir l’intérêt général : l’emploi, la prospérité, la résilience, l’autonomie stratégique, la capacité de l’Europe à faire émerger ses propres acteurs et à ne pas abandonner à d’autres la maîtrise de ses infrastructures les plus décisives. Les propositions formulées dans ce texte ne sont donc pas les miennes au sens strict, elles sont celles d’un acteur économique que je considère engagé. Mais je les ai trouvées suffisamment structurées, cohérentes, réalisables et utiles au débat public pour mériter d’être exposées, débattues et prises au sérieux. Cela ne signifie pas qu’elles seraient les seules possibles, ni qu’elles devraient être suivies les yeux fermés. Je reste ouvert à toute autre proposition crédible. Encore faut-il, au minimum, regarder sérieusement celles qui existent déjà.

Lire, comprendre, restituer

Au départ, je pensais écrire une tribune adressée indistinctement à l’ensemble de la classe politique française et européenne, comme si tout le monde accusait ici le même retard. En avançant dans mes recherches, j’ai dû corriger ce mauvais réflexe. Cette fois, la France n’apparaît pas vraiment à la traîne sur le diagnostic. Elle semble même, sur le fond, avoir eu de l’avance, sans toujours être écoutée, et parfois sans toujours savoir convaincre. Depuis longtemps, Paris défend l’idée qu’une Europe trop dépendante de puissances extérieures, notamment des États-Unis, finit toujours par s’exposer à une forme de vulnérabilité stratégique. Longtemps, cette intuition française a été jugée excessive, agaçante, théâtrale, parfois affaiblie aussi par ses propres contradictions. Mais le durcissement des rapports de force, l’évolution du lien transatlantique et le retour brutal de la puissance dans les relations économiques et politiques ont redonné du crédit à cette vieille intuition française.
La France n’avait pas toujours tort, elle avait souvent raison trop tôt, et parfois de la mauvaise manière. C’est peut-être aussi pour cela qu’elle n’a pas toujours été suivie.

Or ce déplacement du regard éclaire directement le sujet qui nous occupe ici. Car ce que l’autonomie stratégique a révélé dans les domaines diplomatiques, militaires ou industriels, la dépendance numérique le révèle désormais avec une acuité particulière dans le cloud, les logiciels critiques, les données, l’intelligence artificielle et la commande publique.
À partir d’un constat que de plus en plus de citoyens perçoivent désormais clairement, nous ne sommes plus aveugles face aux impasses de notre dépendance numérique. Nous comprenons mieux ce que vivent concrètement des entreprises européennes comme Clever Cloud : la difficulté d’exister, d’innover, de grandir et de rivaliser à armes égales dans un environnement où les effets de taille, les logiques de verrouillage, certaines dépendances structurelles, l’influence des lobbies et une partie de la commande publique favorisent trop souvent d’autres acteurs, bien souvent extra-européens. Ce texte n’a donc pas retenu mon attention comme la simple défense d’un intérêt privé, mais comme le symptôme d’un problème politique, économique et stratégique beaucoup plus large, avec un impact direct sur notre souveraineté numérique.

C’est sans doute pour cela qu’un article d’entreprise peut parfois paraître plus réel, plus direct, et même plus utile que bien des discours officiels. Sous certaines apparences technico-juridiques, le texte de Clever Cloud pose une question simple et redoutable : l’Europe veut-elle continuer à financer, avec son propre argent public, les conditions de sa dépendance, ou veut-elle enfin utiliser sa puissance d’achat pour soutenir ses entreprises, ses infrastructures critiques, son innovation et sa souveraineté ?
La question dépasse de très loin l’avenir et les intérêts d’une seule société, et même d’un seul secteur. Elle touche à la place que nous souhaitons laisser aux acteurs européens dans notre propre marché, à la capacité de l’Union européenne à faire de sa dépense publique un levier de puissance, et au droit des citoyens européens à ne pas voir leur avenir technologique décidé ailleurs.

J’assume pleinement que cette lecture n’est pas neutre. C’est une lecture engagée, réfléchie, ouverte à la contradiction, au dialogue et au débat. Mais il me semble que le temps où l’on pouvait traiter ces sujets comme des querelles d’experts à huis clos touche à sa fin.
Les citoyens comprennent de plus en plus qu’il est question ici de rapports de force économiques, de dépendances technologiques, de fragilité industrielle, de perte de maîtrise sur des infrastructures vitales, et, au fond, de notre capacité collective à reprendre la main sur notre destin européen. C’est dans cet esprit que je propose ici ma grille de lecture de ce texte :
non pour clore le débat, mais pour l’ouvrir franchement et contribuer à porter dans l’espace public francophone des questions trop souvent cantonnées à des cercles spécialisés.

Une entreprise, une doctrine, un engagement public

Je vais essayer de poser le décor sans donner l’impression d’écrire une fiche Wikipedia d’une entreprise. L’idée n’est pas de faire une « bonne pub » pour Clever Cloud, mais de montrer pourquoi cette voix mérite d’être écoutée :
Entreprise française du cloud, spécialisée dans des outils qui souhaite « aider les développeurs » à déployer et héberger leurs applications, Clever Cloud se définit elle-même comme un acteur de la souveraineté numérique européenne, avec un discours centré sur l’autonomie stratégique, l’absence de soumission aux lois extraterritoriales et la maîtrise technique de toute la chaîne de valeur du cloud. Sur sa page en anglais, consacrée au Cloud Souverain, l’entreprise explique aussi défendre une conception juridique, technologique et opérationnelle de la souveraineté.

Clever Cloud n’est pas un cas isolé, pas plus qu’elle ne se réduit à une entreprise venue simplement se plaindre dans l’espace médiatique. C’est même plutôt un acteur engagé dans le débat public, et j’ai pu trouver facilement au moins trois exemples solides pour le démontrer :

• Mai 2022 : Quentin Adam (Fondateur de Clever Cloud) devient président de l’Open Internet Project, et prend régulièrement position sur la souveraineté numérique, la concurrence et la protection des données en Europe.
• Janvier 2025 : Clever Cloud rejoint l’Eclipse Cloud Interest Group. Une initiative de la Fondation Eclipse, destinée à promouvoir l’autonomie et l’interopérabilité des services cloud entre différents fournisseurs
• Mars 2026 : la signature, par Quentin Adam, d’une lettre conjointe de dirigeants du cloud européen au sein de CISPE (Le « Cloud Infrastructure Services Providers in Europe » est une association commerciale à but non lucratif regroupant les fournisseurs de services d’infrastructure cloud en Europe, créée en 2015)

Enfin, je mesure la longueur de cette introduction, mais elle m’a semblé nécessaire tant le projet dont il est ici question est dense. Il fallait prendre le temps d’exposer les idées de fond et le contexte sans interruption, avec le souci d’être aussi pédagogique, documenté et factuel que possible.
La tâche n’a pas été simple et la suite de cet article sera donc plus concrète dans son style, et davantage tournée vers mon interprétation des solutions avancées.

Parler de souveraineté ne suffit plus

L’époque a changé, la compétition technologique s’est durcie, les grandes puissances utilisent depuis plus d’une décennie les marchés, les normes, les infrastructures et les dépendances comme des instruments de puissance.
Dès lors, le sujet de la souveraineté ne peut plus rester qu’un élément de langage réservé aux seules conférences ou aux sommets européens, elle doit désormais s’incarner dans des instruments concrets du pouvoir.

Dire qu’on est souverain, sans pouvoir agir, c’est dérouler le tapis rouge à nos adversaires !

La guerre économique est bien réelle !

Lorsqu’un petit nombre d’acteurs contrôle le cloud, les plateformes, les données, les briques d’IA ou les couches logicielles critiques, il ne contrôle pas seulement un marché : il contrôle une partie des capacités d’action des États, des administrations et des économies.

L’idée centrale défendue par Clever Cloud est qu’une Europe dépendante de fournisseurs extérieurs pour ses fonctions critiques s’expose, de fait, à une vulnérabilité stratégique. Le numérique n’est pas seulement un sujet de performance ou de coût, mais de sécurité, de continuité de service, d’indépendance et Tariq Krim ajouterait sans doute de résilience.

La commande publique est une arme

Qu’est-ce qu’un marché public ? C’est quand une administration, un hôpital, une région, un ministère ou une collectivité achète un service, un logiciel, une infrastructure ou un équipement. Le poids de cet instrument est colossal : la commande publique représente environ 15 % du PIB de l’Union européenne, soit autour de 2 500 à 2 600 milliards d’euros par an selon les sources européennes récentes.

Essayez de visualiser l’équivalent de 2 500 milliards d’euros :
2 500 000 000 000 €

Oui, on parle bien de onze zéros !

Cet argent peut orienter un marché, faire émerger des technologies et des entreprises européennes, ou au contraire renforcer des dépendances. Et c’est précisément le reproche adressé au système actuel : il favorise trop souvent les grands acteurs déjà installés, complique l’accès des petites entreprises, et installe les administrations dans des situations de dépendance durable, dans le jargon du secteur, on appelle ça le vendor lock-in, c’est-à-dire qu’une fois qu’une administration a choisi un fournisseur, elle devient techniquement, économiquement et/ou juridiquement dépendante de lui, et il devient très difficile d’en changer.

Le triptyque proposé : PME, préférence européenne, simplification

Le raisonnement de Quentin Adam repose sur trois piliers :

• un « Small Business Act européen » pour redonner une vraie place aux PME dans les marchés publics
• un « Buy European Tech Act » pour introduire une préférence structurée en faveur des entreprises européennes dans les secteurs stratégiques
• une simplification massive des procédures pour que ces objectifs ne restent pas uniquement théoriques

Ces trois axes seraient indissociables car :

• Aider les PME sans revoir les critères de préférence serait insuffisant
• Favoriser les entreprises européennes sans simplifier les règles continuerait souvent à avantager les plus gros acteurs
• Simplifier sans objectifs politiques clairs ne modifierait pas l’équilibre du marché

Les PME, pilier proclamé de l’Europe mais angle mort de la commande publique

Les PME forment l’immense majorité du tissu économique européen, elles emploient massivement, elles innovent souvent, mais elles accèdent encore trop rarement aux grands marchés publics.
Le paradoxe : L’Europe vante ses PME, mais son appareil d’achat public reste trop souvent « calibré » pour les très grands acteurs. C’est pourtant bien indiqué sur le site du Conseil européen :

Les petites et moyennes entreprises constituent l’épine dorsale de l’industrie et de l’économie européennes. L’UE met en place des politiques de soutien aux PME, car elles jouent un rôle essentiel dans la transition vers une économie durable et numérique.

Marchés publics : pourquoi les PME décrochent si peu de contrats ?

Quentin Adam évoque principalement trois raisons :

• La complexité administrative : dossiers lourds, documentation abondante, garanties financières, exigences techniques, temps de réponse, coût humain
• La taille des appels d’offres : trop larges, trop agrégés, trop peu découpés, impossible pour une PME de proposer une réponse sérieuse, en temps et en heure face à une structure dotée de beaucoup plus d’employés et d’experts
• La commande publique demeure aussi difficile d’accès pour les jeunes entreprises innovantes, y compris celles qui ont déjà entamé leur croissance. Le manque de références, des critères de sélection qui privilégient les entreprises disposant déjà d’une forte assise et l’inertie administrative continuent de favoriser les acteurs déjà installés

Pourquoi le soutien aux PME est d’abord un enjeu économique ?

Ce n’est pas qu’une théorie, c’est un fait !
L’innovation vient souvent des nouveaux acteurs, mais la concentration excessive ralentit cette dynamique. Lorsque les mêmes grands groupes captent durablement la commande publique, la destruction créatrice s’affaiblit et la concurrence réelle se rétracte.

Soutenir les PME ne consiste pas à préserver artificiellement les plus petites structures, mais à permettre à des entreprises innovantes de devenir les futurs piliers économiques européens.

Et le Small Business Act, concrètement ?

L’objectif général de ce concept serait de repenser la commande publique pour permettre aux PME d’accéder réellement aux marchés, de grandir et de participer davantage à l’économie européenne. Il s’agit du principe de Think Small First, c’est-à-dire : lorsqu’une règle est conçue, il faut d’abord se demander si une petite ou moyenne entreprise peut réellement s’y conformer.

Clever Cloud propose les objectifs chiffrés suivants : 25 % de la valeur totale des marchés pour les PME, et 35 % dans les secteurs numériques et technologiques stratégiques comme le cloud, la cybersécurité, l’IA, les infrastructures de données, les services publics numériques ou les logiciels critiques.

Le Buy European Tech Act : le point le plus politique

L’idée est la suivante : lorsque l’argent public européen finance des technologies stratégiques, il devrait contribuer en priorité au renforcement d’entreprises européennes. Non pour céder à une tentation de repli, mais pour corriger des déséquilibres devenus structurels.

Sachant qu’un raisonnement proche existe déjà dans l’écosystème français. En effet, France Digitale défend depuis 2025 l’idée d’un Buy European Tech Act, justement pour passer d’une Europe uniquement régulatrice à une Europe capable de soutenir aussi son propre écosystème.

Pourquoi viser d’abord le cloud, la cybersécurité, l’IA et les données ?

Il ne s’agit pas ici de simples solutions techniques parmi d’autres, mais de briques fondamentales de notre environnement numérique. Dès lors qu’une administration dépend d’un fournisseur extérieur pour héberger des données de santé, gérer des identités numériques, stocker des informations fiscales ou faire fonctionner des services publics essentiels, la dépendance serait alors considérée comme stratégique.

La logique défendue ici n’est pas celle d’une préférence européenne sans nuance, mais d’une priorité accordée aux secteurs les plus sensibles.

Filiale en Europe ou entreprise européenne : quelle différence ?

Pour Clever Cloud, une entreprise ne peut pas être qualifiée d’européenne si elle possède seulement une filiale ou un bureau au sein de l’Union européenne. Il faut des critères plus exigeants : le siège, une activité réelle, une gouvernance soumise au droit européen, une absence de dépendance à des lois extraterritoriales incompatibles avec l’ordre juridique européen et le respect des normes européennes. Clever Cloud formule cette idée de manière plus explicite dans sa présentation sur le « Cloud Souverain » (en anglais)

Ce que révèle l’extraterritorialité du droit en matière de souveraineté

Une entreprise étrangère peut être soumise aux lois de son pays d’origine, lesquelles peuvent parfois imposer la transmission de données ou une coopération avec des autorités extérieures, donc la localisation physique des serveurs ne suffit pas à répondre à la question. Clever Cloud insiste précisément sur cette distinction entre simple implantation géographique et contrôle juridique effectif.
Concrètement, il faut comprendre que la souveraineté numérique ne tient pas à la seule présence de centres de données sur le territoire européen.

Non, il ne s’agit pas de fermer le marché européen

Le projet proposé par Clever Cloud ne consiste pas à exclure automatiquement tout acteur non européen, ni à fermer le marché. Il s’agit d’introduire une préférence structurée dans les secteurs stratégiques lorsqu’une solution européenne compétente, fiable et conforme existe.

On parle ici de capacité, de résilience et de souveraineté, non d’un réflexe isolationniste.

Les objectifs chiffrés du Buy European Tech Act

Selon cette proposition, 60 % de la valeur annuelle des achats publics stratégiques dans le numérique et les technologies devraient revenir à de véritables entreprises européennes.
Il ne s’agirait pas d’imposer cette règle appel d’offres par appel d’offres, mais d’en suivre l’application à l’échelle globale, au moyen de tableaux de bord et de rapports annuels.

Ce projet est-il légal ?

L’objection juridique mérite d’être examinée de près et Clever Cloud construit ainsi, dans sa proposition, une démonstration en deux volets :

• D’abord, via la piste pro-PME. En effet, les règles internationales interdisent surtout la discrimination directe fondée sur la nationalité, mais les mécanismes fondés sur la taille de l’entreprise relèvent d’une logique différente.
• Ensuite, la piste stratégique car dans certains domaines sensibles comme le cloud public, les données sensibles, la santé, l’identité, la justice, les fonctions administratives critiques, l’argument des intérêts essentiels pour la sécurité ouvre une marge plus grande pour privilégier des solutions réputées plus sûres.

Les États-Unis le font déjà : pourquoi l’Europe s’en priverait-elle ?

L’État américain utilise depuis longtemps sa commande publique comme un levier de puissance, de soutien industriel et de sécurité économique, tout en restant dans le commerce international. L’idée n’est pas d’en faire un modèle à recopier, mais de souligner que l’Europe est l’une des rares grandes puissances à hésiter encore à se servir pleinement de sa propre dépense publique.

Rendre enfin la commande publique accessible aux PME

Enfin, pour résumé, voici plusieurs leviers concrets proposés par Quentin Adam :

• D’abord, le test PME préalable aux grands appels d’offres.
• Ensuite, la formation et l’accompagnement pour apprendre à répondre.
• Puis les partenariats d’innovation, pour que l’État n’achète pas seulement ce qui existe déjà mais puisse aussi contribuer à faire émerger des solutions.
• Faire en sorte que les systèmes d’acquisition dynamique, c’est-à-dire des procédures d’achat entièrement dématérialisées, auxquelles de nouveaux fournisseurs peuvent se joindre au fil du temps, soient plus souples et accessibles dans la durée.
• Enfin, le découpage obligatoire en lots des appels d’offres, pour empêcher que les très grands marchés ne soient réservés, de fait, qu’aux géants.

Et le but dans tout cela ?

Tout l’enjeu est de faire passer ces principes dans la pratique administrative.

Conclusion : d’une Europe qui encadre à une Europe qui construit

Le sens profond du projet est d’expliquer que dès sa construction, et encore aujourd’hui, l’Europe s’est voulue ouverte, neutre, procédurale mais dans le numérique, cette neutralité a aussi laissé s’installer des dépendances.

Ce que Clever Cloud demande, très concrètement :

• des objectifs chiffrés pour l’accès des PME aux marchés publics
• une préférence européenne assumée dans les achats technologiques stratégiques
• des procédures simplifiées
• des marchés découpés
• des outils d’innovation plus souples
• et une doctrine politique claire

L’Europe ne manque pas seulement d’entreprises ou d’idées, elle peine surtout à transformer sa puissance normative et budgétaire en puissance industrielle.

L’Europe dispose de cerveaux, d’idées, de compétences, de moyens financiers, d’entreprises et de règles, ce qui lui manque encore trop souvent, c’est la volonté politique d’orienter sa commande publique vers les entreprises européennes capables de porter cette ambition.

Et puis il y a parfois des hasards de calendrier qui valent presque démonstration :
Fin janvier 2026, Clever Cloud avançait, à travers cet article, une thèse que beaucoup auraient pu balayer d’un revers de main comme une plainte sectorielle de plus ou comme une obsession française de la souveraineté numérique : l’Europe ne retrouvera aucune maîtrise réelle sur son destin numérique tant qu’elle continuera à traiter sa commande publique comme une mécanique neutre, procédurale, désincarnée, alors qu’elle devrait l’assumer comme un instrument de puissance, de structuration industrielle et de protection de ses intérêts stratégiques. Or, quelques semaines plus tard, le 7 avril 2026, cette intuition trouvait un écho remarquable dans un article (en anglais) publié par la Harvard Kennedy School, au sein du programme Reimagining the Economy du Malcolm Wiener Center for Social Policy, c’est-à-dire l’une des institutions universitaires les plus écoutées au monde, au cœur même des États-Unis, ce pays qui, lui, n’a jamais eu la naïveté de croire qu’un marché public devait être politiquement inoffensif.
Et que dit, au fond, cette analyse venue d’outre-Atlantique ? Exactement que l’argent public n’a de sens que s’il sert une stratégie, qu’il doit produire de la capacité, de l’autonomie, des résultats mesurables et de la valeur collective, au lieu d’alimenter passivement les positions acquises.
Dès lors, il devient plus difficile de renvoyer les propositions portées par Clever Cloud au rang des lubies, des postures ou des caprices français. Elles apparaissent pour ce qu’elles sont bien davantage : des propositions concrètes, discutables certes, perfectibles évidemment, mais sérieuses, cohérentes avec la réalité des rapports de force, et surtout déjà en phase avec un raisonnement doctrinal que même les grandes institutions américaines jugent désormais légitime.

La question est désormais de savoir si l’Europe entend enfin se servir de sa commande publique pour bâtir sa propre puissance, ou si elle préfère continuer à entretenir, avec l’argent de ses contribuables, les mécanismes qui la condamnent progressivement au statut peu enviable de simple colonie numérique.

En fin de compte, il s’agit pour l’Union Européenne, de savoir défendre ses intérêts.

L’article Comment l’Europe peut, en soutenant ses PME, reprendre la main sur le numérique est apparu en premier sur Souverain.

Depuis quelques mois, la souveraineté numérique a changé de statut. Elle n’est plus un sujet de spécialistes. Elle devient un sujet politique, industriel, stratégique. Et, très concrètement, un sujet de marché.

Le signal envoyé par l’État ces dernières semaines est clair. Avec la Direction interministérielle du numérique (DINUM), nous ne sommes plus seulement dans le diagnostic ou dans le commentaire : nous entrons dans une logique d’exécution, avec une volonté assumée de réduction des dépendances extra-européennes, y compris sur le poste de travail, les outils collaboratifs, les bases de données, la virtualisation, l’IA ou encore les équipements réseau.

Ce signal n’a pas créé un nouveau marché : il vient rebattre les cartes d’un secteur jusqu’alors capté en grande partie par quelques acteurs dominants. Et il agit comme le véritable coup d’envoi d’une dynamique déjà sous tension, qui n’attendait qu’une décision officielle pour accélérer.

Autrement dit : nous venons peut-être de basculer du débat vers l’action.

Et quand une opportunité de cette ampleur se présente, il faut regarder les choses avec lucidité : ce ne sont pas seulement des logiciels et autres solutions techniques qu’il faudra déployer, ce sont des équipes qu’il faudra recruter, des organisations qu’il faudra adapter, des agents et des salariés qu’il faudra former, des décideurs qu’il faudra sécuriser et des usages qu’il faudra accompagner.

Le vrai marché qui se dessine n’est donc pas seulement technologique. C’est un marché de la transformation.

Nicolas Vivant a raison de pointer l’angle mort du débat : on parle beaucoup des outils, des budgets, des doctrines, mais pas assez des humains qui rendront cette bascule possible.

Adrien de Linuxtricks le rappelle d’ailleurs très bien dans l’une de ses dernières vidéos :

Passer au logiciel libre et sous GNU Linux, c’est un projet de transformation humaine avant tout, avant d’être technique parce qu’il va falloir former, accompagner et cela a aussi un coût en gestion de projet et en ressources, mais ce sera un coût qui sera amorti sur le long terme. Et cette fois le contexte est différent : entre les tensions géopolitiques mondiales. Rappelez-vous le rachat du Groenland … Et la maturité des solutions open source en 2026. Franchement, on n’a plus d’excuses. La France montre l’exemple dans la lignée du Danemark et de l’Allemagne. Et j’ai aussi hâte de voir comment les autres pays européens vont réagir.

Et c’est précisément pour cela que la question des compétences, du recrutement, de l’acculturation et de l’accompagnement devient centrale.

En off, beaucoup de directions des systèmes d’information, de professionnels des ressources humaines et d’acteurs du secteur commencent déjà à le dire à demi-mot : la demande arrive, et elle arrive vite.

C’est une excellente nouvelle pour la migration vers des solutions plus souveraines, et c’est un signal fort pour l’emploi. Mais cela veut aussi dire qu’il va falloir garder la tête froide.

Car si nous attendons que tous les besoins remontent en même temps, nous créerons nous-mêmes la saturation que nous redoutons : tension sur les recrutements, fuite des talents, hausse des coûts, négociations salariales plus dures, budgets fragilisés, projets ralentis, et parfois, projets abandonnés.

Les signaux RH ne trompent pas. Les cabinets spécialisés décrivent déjà une forte tension sur les profils critiques : cybersécurité, cloud, pilotage, transformation, compétences rares. En clair : le marché comprend déjà que quelque chose est en train de s’ouvrir.

Le constat rejoint d’ailleurs celui du World Economic Forum : les services IT seront le principal moteur de croissance mondiale jusqu’en 2030, mais cette dynamique ne tiendra pas sans investissement massif dans le capital humain. Formation et reconversion y sont présentées comme un choix « sans regret », c’est-à-dire une priorité rentable dans tous les scénarios macroéconomiques. Le paradoxe, c’est que ces investissements restent encore trop faibles par rapport aux besoins.

Cela veut dire qu’il faut agir maintenant.

Former en interne. Sortir des circuits de recrutement habituels. Prendre au sérieux les reconversions. Élargir le réservoir de talents. Repérer les profils atypiques. Faire de la place aux curieux, aux passionnés, à ceux qui apprennent vite. Redonner aussi toute leur valeur aux seniors, à leur expérience, à leur capacité de transmission, de stabilisation et d’accélération.

Le sujet n’est pas seulement de recruter des experts déjà prêts. Le sujet est de construire assez tôt les compétences qui permettront d’éviter le goulot d’étranglement.

Et cela suppose aussi de revoir les politiques RH. Plus de souplesse. Plus d’agilité. Plus d’ouverture d’esprit. Car ce type de bascule ne se pilote pas en utilisant les méthodes habituelles et une appréciation trop conventionnelle des parcours. La situation et la demande sont exceptionnelles.

Comme toujours lorsqu’un marché change, ne soyons pas dupes : il attirera aussi son lot de faux experts et de spécialistes autoproclamés de la souveraineté numérique, de la transformation et de la conduite du changement depuis plus de 50 ans… Vous les verrez arriver de loin. Ceux qui parleront beaucoup de doctrine, mais peu de déploiement réel, de migration, de support, de formation, d’adhésion utilisateur. Le trait est volontairement forcé, mais à peine.

Dans la période qui s’ouvre, la crédibilité comptera autant que l’expertise. Peut-être même davantage.

Et justement, ce marché ne concerne pas seulement les métiers que nous connaissons déjà. Il va aussi faire émerger de nouvelles fonctions.

Chargé de mission accompagnement au changement. Consultant en conduite du changement. Chef de projet d’accompagnement au changement. Formateurs. Profils hybrides entre technique, organisation et acculturation. Mais aussi les métiers de la communication et du marketing, qui devront eux aussi bâtir un nouveau récit : car au fond, c’est une autre histoire collective qu’il va falloir apprendre à raconter et à transmettre. Et demain, des rôles plus transversaux encore.

Tariq Krim évoque même une nouvelle fonction pour qualifier cette évolution, avec la figure du Chief Resiliency Officer : un rôle transversal, pensé pour aider l’entreprise à adapter sa stratégie dans un environnement où la géopolitique, la cyber et les ruptures politiques imposent désormais des décisions hors du cadre habituel.

Il faut aussi comprendre quelque chose de stratégique : la souveraineté numérique est probablement la marche la plus accessible de notre autonomie stratégique.

Pourquoi ?

Parce qu’elle demande de la méthode, du recrutement, de la formation, de la coordination et des arbitrages. Mais elle exige beaucoup moins de capital matériel qu’une réindustrialisation lourde.

Migrer des outils, des environnements de travail, des briques logicielles, des infrastructures ou des chaînes de support n’a rien à voir, en intensité capitalistique, avec l’ouverture d’usines, l’achat de foncier, la construction d’usines, de hangars ou l’installation de chaînes industrielles.

Et pourtant, cette première marche favorise aussi les suivantes.

Pendant que l’Europe essaie de se réarmer sur les semi-conducteurs avec des projets comme ESMC à Dresde, la Smart Power Fab d’Infineon, FAMES à Grenoble, Space Forge au pays de Galles ou encore SILICON BOX en Italie, nous avons sur le logiciel, les services, la formation, les usages et l’accompagnement un terrain plus rapide à activer.

Mais c’est aussi à cet endroit que le raisonnement se complique : un paradoxe majeur apparaît.

Au moment même où la dynamique s’enclenche politiquement et stratégiquement, une autre variable commence à peser sur les budgets : la techflation. Entre les guerres en cours, les tensions énergétiques, le prix du baril, les fragilités logistiques et les coûts de la chaîne technologique, recruter ne voudra pas seulement dire créer des postes. Cela voudra aussi dire équiper. Acheter du matériel. Déployer. Renouveler. Absorber une hausse possible des coûts au pire moment.

Voilà pourquoi il faut tant insister sur l’organisation.

Oui, c’est une opportunité majeure. Oui, le signal est bon. Oui, il y a un potentiel considérable à s’organiser dès maintenant. Oui, l’urgence actuelle peut débloquer des budgets et des décisions qui restaient gelés depuis des mois, parfois des années.

Mais cette opportunité ne se saisira pas dans l’improvisation.

Car si la demande monte plus vite que l’offre de compétences, si les coûts de recrutement et d’équipement montent en même temps, si les décideurs ont le sentiment que la migration vers des solutions souveraines devient trop chère ou trop lente, alors nous entrerons dans une bataille perdue d’avance.

Pourquoi ?

Parce qu’en face, les GAFAM et les grands hyperscalers disposent déjà de l’infrastructure, de l’échelle, des offres packagées et de la capacité à jouer sur les prix. Et si nos coûts montent trop vite, ils auront un argument très simple à opposer aux décideurs : rester dépendants coûtera moins cher, au moins à court terme.

C’est comme cela qu’une ambition stratégique peut retomber. Non pas faute de vision. Mais dans un arbitrage budgétaire.

Le risque est donc clair : si nous ne préparons pas sérieusement les recrutements, la formation interne, les viviers, les reconversions, les profils atypiques et les politiques RH, alors certains projets seront ralentis, d’autres réduits, et certains abandonnés.

Ce serait un échec majeur. Parce que nous sommes, pour une fois, proches d’une vraie possibilité d’action collective. Et ce moment que nous sommes actuellement en train de vivre ne revient pas tous les ans.

La question n’est plus de savoir s’il faut y aller. La vraie question est de savoir si nous allons nous organiser assez tôt pour éviter le goulot d’étranglement, absorber la demande, garder les coûts sous contrôle et transformer cet élan en capacité réelle.

Peut-être que notre plus grand défi n’est pas encore de faire. Peut-être qu’il est d’abord de nous organiser pour pouvoir faire.

Et comme l’indiquait récemment Cristina Caffarra dans un entretien accordé au magazine Le Monde Informatique : « Il nous reste 3 ans pour agir sous peine de rester une colonie digitale des États-Unis. »

L’article Une dynamique vient de s’enclencher. Encore faut-il en préparer la suite est apparu en premier sur Souverain.

Peu de voix aujourd’hui s’expriment avec autant d’aisance à l’intersection de l’économie de la concurrence, de la politique industrielle et de la souveraineté technologique. Cristina Caffarra est une économiste reconnue, avec plus de vingt-cinq ans d’expérience sur des dossiers majeurs de concurrence et d’antitrust, professeure honoraire à l’University College London et cofondatrice du CEPR : « Réseau de recherche sur les politiques de concurrence » (Competition Research Policy Network). Mais son importance tient à autre chose encore : sa capacité à sortir du langage clos des spécialistes pour nommer,avec une justesse si rare, le problème européen. Depuis plusieurs années, elle martèle la même idée : l’Europe ne pourra pas se contenter de réguler ce qu’elle ne construit plus.

Cette singularité se retrouve dans son engagement autour d’EuroStack. Le site officiel rappelle qu’après l’événement fondateur organisé au Parlement européen en septembre 2024, Cristina Caffarra a réuni des acteurs de l’industrie technologique pour produire d’abord un document d’orientation, puis un livre blanc. L’initiative s’est depuis structurée autour d’une idée simple, mais décisive : la souveraineté numérique européenne ne se décrète pas, elle s’organise. Elle suppose des entreprises, des capacités industrielles, du financement, des débouchés et surtout une stratégie claire. En ce sens, EuroStack n’est pas seulement un mot d’ordre ; c’est une tentative pour remettre l’Europe face à ses responsabilités.

C’est aussi pour cela que Cristina Caffarra compte beaucoup dans ce combat. Parce qu’elle incarne ce qui manque encore trop souvent en Europe : des personnalités capables de relier les idées à l’action, l’analyse au rapport de force, la volonté de souveraineté au réel économique. Il en faudrait davantage chez les entrepreneurs, dans les partis, auprès des femmes et des hommes politiques, dans les administrations, et sans doute davantage encore au sein même des institutions européennes. Non pas des figures tonitruantes, mais des voix capables de clarifier le moment, de poser les bons mots et les bons diagnostics sur les bons problèmes, et de rappeler que la souveraineté numérique n’est pas une affaire de communication, mais une affaire de cap, de vision et encore une fois de stratégie !

C’est précisément ce que fait son dernier article. Et c’est pour cela qu’il mérite d’être lu de près. C’est aussi ce que je vais essayer de partager ici, avec mes mots, à partir de ma lecture du texte, de ce que j’en ai compris et de la vision que cela m’inspire :

1. L’Europe est entrée dans un moment de bascule

Premier point, et sans doute le plus important : l’Europe continue trop souvent à raisonner comme si elle se trouvait dans un cadre stable. Or ce n’est plus le cas. Entre le choc géopolitique, la crise énergétique, la pression chinoise et américaine, la révolution de l’IA et l’essoufflement du modèle économique européen, nous sommes entrés dans un moment de rupture. Le message est clair : on ne peut plus aborder cette période avec les raisonnements d’hier.

2. Le véritable défi européen ne s’appelle pas compétitivité, mais croissance

Le problème européen n’est pas seulement une question d’image, de compétitivité proclamée ou de rhétorique institutionnelle. Le problème est plus profond : l’Europe peine à retrouver de la croissance, et surtout à restaurer sa productivité. Tant que cette réalité ne change pas, la rhétorique sur la compétitivité ne remplacera jamais une véritable dynamique de croissance.

3. Les déséquilibres européens ne datent pas d’hier, mais ils se durcissent

Le raisonnement repose sur deux niveaux. Il y a d’abord les faiblesses structurelles bien connues : marché fragmenté, difficulté à faire émerger des acteurs à l’échelle continentale, manque d’investissements, sous-dimensionnement de nombreuses entreprises. Mais il y a aussi l’aggravation du contexte : faiblesse de la demande intérieure, crise énergétique, surcapacité chinoise, dépendances technologiques. La nouveauté est là : ces fragilités ne se juxtaposent plus, elles se combinent désormais pour accentuer les difficultés européennes.

4. L’Europe peine encore à apporter une réponse à la hauteur du moment

La simplification réglementaire ou les accords commerciaux ne sont pas inutiles. Mais ils ne sont plus à la hauteur du moment. Alléger un peu la bureaucratie ou signer quelques accords ne constitue pas une stratégie de redressement. Ce sont, au mieux, des correctifs, au pire, des réponses trop timides face à un décrochage bien plus profond.

5. La puissance du marché européen demeure un levier insuffisamment mobilisé

C’est l’un des axes majeurs de son article : une politique industrielle ne peut pas reposer uniquement sur des aides, des subventions ou des mesures côté offre. Elle doit aussi organiser la demande. Autrement dit : utiliser la force du marché européen pour créer des débouchés, orienter les achats, sécuriser des volumes et donner enfin de l’oxygène à des fournisseurs européens capables d’investir et de grandir.

6. L’exemple des bonus sur les voitures électriques montre ce que l’Europe n’ose pas faire

L’idée d’ « européaniser » le bonus écologique français permet de comprendre très concrètement ce qui se joue : soutenir l’achat de véhicules électriques selon des critères de chaîne d’approvisionnement bas carbone, afin de favoriser, de fait, une production plus européenne sans tomber dans un protectionnisme brut. Ce qui est souligné, ce n’est pas seulement l’idée elle-même, mais le fait qu’une proposition juridiquement défendable, stratégiquement intelligente et tournée vers la demande n’ait finalement pas été reprise. Pourtant, l’idée n’est pas sans rappeler certains travaux déjà portés en France, notamment par Nicolas Meilhan, sur la nécessité de tenir compte non seulement des émissions à l’usage, mais aussi du poids des véhicules et du contenu carbone de leur fabrication.
Au fond, le cas de l’automobile dépasse largement ce secteur : derrière ce débat, c’est la question de savoir si l’Europe accepte enfin de faire de la demande un levier de souveraineté.

7. L’Europe bouge, mais sans toujours assumer le changement qu’elle engage

L’Industry Acceleration Act est cité comme le signe qu’un changement est peut-être en cours : introduire davantage de critères européens dans certains dispositifs de soutien ou de commande publique. Mais ce début d’inflexion révèle aussi toutes les résistances à l’œuvre : peur du protectionnisme, prudence excessive, réticences administratives, lobbying, retrait de secteurs technologiques sensibles au dernier moment. Le constat est sévère : même lorsqu’un mouvement s’amorce, l’Europe hésite encore à aller jusqu’au bout de sa propre logique.

8. Faire de la commande publique un instrument de souveraineté numérique

Autre point central : la commande publique dans le numérique. L’idée défendue ici est celle d’une préférence européenne, relativement mesurée dans ce domaine : autour de 20 à 30 % de la commande publique. Le raisonnement est cohérent : si l’Europe veut sérieusement parler de souveraineté numérique, elle doit cesser d’acheter presque exclusivement à des fournisseurs non européens quand elle pourrait, au moins en partie, donner à ses propres acteurs les moyens de changer d’échelle. Car sans débouchés, il n’y a pas d’écosystème solide.

9. L’Europe continue de s’imposer des limites au nom d’une lecture stricte de l’OMC

C’est l’un des passages les plus tranchants du texte. Le réflexe européen consiste encore trop souvent à brandir les règles de l’OMC comme si elles interdisaient toute préférence européenne. Selon elle, cet argument sert trop souvent de prétexte à l’inaction. Or il est bon de rappeler trois éléments : d’autres pays ont depuis longtemps adopté des mesures permettant de réserver une partie des retombées économiques à leur propre base industrielle, le droit n’interdit pas tout en toutes circonstances et l’Union européenne elle-même n’a jamais fait de sa stricte conformité commerciale une priorité absolue lorsqu’elle estimait que ses intérêts stratégiques étaient en jeu. Dit autrement : l’Europe continue parfois à s’interdire ce que d’autres puissances assument, au nom d’une lecture du libre-échange qui n’est plus en phase avec la réalité stratégique actuelle.

10. Savoir maîtriser l’infrastructure numérique, c’est déjà reconstruire une politique industrielle

Ici, Cristina Caffarra rejoint très directement les débats sur la souveraineté numérique. Son constat est le suivant : pendant que l’Europe régulait, l’essentiel de l’infrastructure numérique sur laquelle reposent aujourd’hui les services, les données et les usages a été consolidé par les hyperscalers américains. Cela ne concerne pas seulement les centres de données ou le cloud au sens strict, mais aussi les outils, les services et les dépendances qui s’empilent autour : hébergement, puissance de calcul, logiciels de base, environnements de développement, services d’intelligence artificielle. Concrètement, cela signifie qu’une part croissante de notre vie économique repose sur des briques essentielles que l’Europe ne possède pas, ne maîtrise pas et ne décide pas. Quand elle écrit que le cloud a été trop longtemps perçu comme une infrastructure parmi d’autres, elle veut dire qu’on l’a traité comme une simple solution technique, alors qu’il détermine en réalité qui capte la valeur, qui fixe les règles et qui contrôle les points d’accès du numérique.

11. Avec l’IA, cette dépendance devient encore plus lourde de conséquences

L’argument devient encore plus fort avec l’intelligence artificielle : si l’Europe développe des usages, des services et des innovations avec l’IA sur des infrastructures contrôlées par d’autres, une partie décisive de la valeur économique lui échappera. Les revenus, la maîtrise technique, les positions de marché et la capacité à imposer des standards se concentreront là où se trouvent déjà les grands fournisseurs de calcul, de cloud et de services d’IA. Le point est limpide : sans maîtrise minimale de ces fondations, l’Europe peut produire des talents et des idées, mais laisser d’autres récolter l’essentiel des bénéfices.

12. En Europe, la politique de concurrence demeure trop largement coupée des priorités du moment

Cristina Caffarra connaît bien ce sujet : c’est son champ de spécialité depuis plus de vingt-cinq ans. C’est précisément pour cela que sa critique mérite d’être prise au sérieux. Ce qu’elle reproche à la politique de concurrence européenne, ce n’est pas d’exister ni de défendre la concurrence. Ce qu’elle lui reproche, c’est de trop souvent se protéger derrière ses procédures, ses tests, ses doctrines et son vocabulaire technico-juridique, au moment même où l’Europe aurait besoin que toutes ses politiques tirent dans le même sens. Son interrogation est très concrète : dans une Europe qui peine encore à faire émerger des entreprises de taille suffisante, à mobiliser l’investissement et à consolider ses infrastructures. Une question décisive se pose alors : la politique de concurrence aide-t-elle réellement l’Europe à se renforcer, ou reste-t-elle trop souvent guidée par ses propres habitudes et ses propres « équilibres » ?

13. Elle ne demande pas d’abandonner la concurrence, mais de la rendre plus utile au redressement européen

Là encore, il faut éviter les contresens. Il n’est pas question de suspendre le droit de la concurrence, ni de soutenir aveuglément de prétendus champions européens. Ce qui est mis en cause, c’est plutôt une forme d’autosatisfaction technocratique : l’idée selon laquelle les outils actuels suffiraient parce qu’ils sont juridiquement cohérents et « intellectuellement » bien établis. Beaucoup trop d’énergie serait encore absorbée par des dossiers très techniques, des « remèdes » souvent limités et des débats internes sur la méthode, alors même que la question essentielle est devenue plus simple et urgente : comment la politique de concurrence peut-elle aider l’Europe à faire grandir ses entreprises, à soutenir l’investissement, à stimuler l’innovation et à rebâtir sa base industrielle ?
C’est LA question !

14. Au fond, elle appelle l’Europe à revoir ses certitudes qui freinent encore son réveil

Le titre de son article le dit explicitement. Lorsqu’elle oppose l’ « impératif de croissance » à ce qu’elle appelle en anglais les sacred cows, c’est-à-dire « les vaches sacrées », elle vise ces principes devenus presque intouchables dans le débat européen : la croyance selon laquelle le libre-échange devrait rester la règle absolue, le réflexe de penser les politiques publiques en silos, l’attachement excessif aux procédures, et cette prudence permanente qui finit par empêcher d’agir. En français, on pourrait parler d’idées reçues installées, de dogmes hérités, ou de réflexes devenus sacrés. Son appel est limpide : l’Europe doit cesser de défendre des cadres devenus trop rigides, quand ses capacités économiques, elles, appellent des choix plus audacieux. Elle doit juger ses politiques à leurs effets concrets dans un monde, lui, bien réel et plus que jamais en tension.

Au fond, le mérite du texte de Cristina Caffarra est de rappeler que la souveraineté numérique n’est ni un sujet périphérique, ni un simple slogan politique, mais bien une question de priorités, d’organisation économique, de vision, de stratégie, d’infrastructures et de puissance. C’est sans doute ce qui rend sa voix si précieuse aujourd’hui : elle ne flatte pas l’Europe, elle la met au défi.

Et c’est précisément pour cela qu’il me semble important qu’elle soit davantage lue, davantage entendue, et que son travail trouve un écho plus large en France, y compris dans les médias et dans le débat public.

L’article Cristina Caffarra, la stratégie là où l’Europe ne voit encore que des règles est apparu en premier sur Souverain.

La Commission européenne a confirmé l’existence de discussions avec Washington autour d’un « dialogue » sur les technologies et les marchés numériques, tout en répétant que le Digital Services Act et le Digital Markets Act ne sont pas censés faire partie des négociations commerciales. Formellement, le message est clair : l’Union ne renonce pas à son cadre réglementaire. Mais le simple fait que ce sujet soit désormais au centre des tensions transatlantiques dit déjà quelque chose d’essentiel : les règles européennes ont cessé d’être uniquement symboliques. Elles commencent sérieusement à toucher des intérêts économiques et stratégiques très concrets.

C’est même sans doute le premier enseignement de cette séquence. Si Washington réagit avec autant d’insistance, ce n’est pas seulement par habitude diplomatique ou par réflexe idéologique. C’est aussi parce que le signal européen est enfin passé. Jacob Helberg, un haut responsable du département d’État américain, a déclaré le 1er avril que les amendes et procédures européennes visant les entreprises américaines constituaient désormais la principale source de friction économique entre les États-Unis et l’Europe. Dit autrement : Bruxelles commence à être prise au sérieux là où cela compte le plus, c’est-à-dire sur le terrain du modèle économique des Big Tech.

Il faut partir de là pour comprendre la portée du moment. Depuis plusieurs années, l’Europe a multiplié les textes, les annonces et les discours sur la souveraineté numérique. Mais ce qui change aujourd’hui, c’est que cette volonté commence à se traduire en actes plus lisibles politiquement. L’idée qu’il faudrait enfin encadrer les plateformes dominantes, reprendre la main sur les infrastructures critiques et réduire la dépendance à l’égard de fournisseurs extra-européens n’est plus cantonnée aux cercles spécialisés. Elle remonte dans le débat public, dans les discours des chefs d’État et dans les arbitrages de la Commission.

Néanmoins, il reste prématuré de présenter cette histoire comme celle d’une Europe déjà émancipée. Le problème central reste intact : l’Union régule les acteurs américains tout en dépendant encore massivement d’eux. Un document du Parlement européen publié en 2025 rappelle que AWS, Microsoft Azure et Google Cloud représentent environ 70 % du marché européen du cloud, tandis que la part cumulée des fournisseurs européens n’est que d’environ 13 %. Le même document indique qu’environ 80 % des dépenses logicielles et cloud des entreprises européennes vont à des fournisseurs américains. Cette dépendance ne concerne donc pas seulement les réseaux sociaux ou la publicité en ligne. Elle touche le cœur même de l’économie numérique.

Et cette dépendance s’aggrave à mesure que le cloud devient l’infrastructure ordinaire de la vie économique. Eurostat indique qu’en 2025, près de 53 % des entreprises de l’Union utilisaient déjà des services cloud payants, contre 17,8 % en 2014. Plus l’Europe se numérise, plus la question de savoir qui héberge, qui administre, qui met à jour, qui verrouille et qui facture devient une question de souveraineté concrète. Il ne s’agit plus d’un débat abstrait sur la stratégie industrielle : il s’agit de la capacité réelle d’un continent à continuer à fonctionner selon ses propres choix.

C’est précisément pour cela que la séquence actuelle ne peut pas être réduite à un simple échange entre alliés. Elle s’inscrit dans une bataille d’influence plus large. Le 25 février, Reuters révélait qu’un câble signé par Marco Rubio demandait aux diplomates américains de s’opposer aux initiatives étrangères de « souveraineté des données » et de contrer les réglementations jugées trop contraignantes, notamment les obligations de localisation. Le texte citait même le RGPD comme exemple de règle imposant des restrictions excessives sur le traitement des données et les flux transfrontaliers. Là encore, le message est limpide : quand l’Europe essaie de reprendre un peu de contrôle, Washington y voit un obstacle pour ses entreprises.

Ce point est crucial, car il oblige à sortir d’une lecture naïve du mot « coopération ». Coopérer entre alliés n’est pas en soi un problème. Aucune souveraineté sérieuse ne se construit dans l’autarcie. Mais encore faut-il savoir de quelle coopération on parle. Le rapport publié en janvier par l’Atlantic Council reconnaît lui-même que le débat européen sur la souveraineté numérique vise à rendre l’Europe moins dépendante et plus capable de défendre ses intérêts. Dans le même temps, il pose la question de savoir si cette souveraineté doit vraiment passer par une approche plus européenne, par des exigences de contrôle effectif ou par des restrictions sur des acteurs non européens, et il réinscrit le sujet dans une logique de partenariat transatlantique. Le désaccord est là : pour beaucoup d’acteurs américains, l’autonomie européenne est acceptable tant qu’elle ne modifie pas trop profondément l’équilibre du marché.

C’est aussi pour cela que la bataille est sémantique autant que politique. À mesure que l’Europe parle davantage de souveraineté, certains discours cherchent à reformuler cette ambition comme un risque de fermeture, de fragmentation ou de perte de confort pour l’utilisateur. Le débat n’est alors plus présenté comme une question de maîtrise stratégique, mais comme un arbitrage entre autonomie d’un côté, innovation et fluidité de l’autre. Ce cadrage est redoutablement efficace, parce qu’il transforme une dépendance subie en choix apparemment raisonnable, et fait passer toute volonté de reprendre la main pour une réaction excessive ou un réflexe de repli.

L’ironie du moment, c’est que même le mot souveraineté devient désormais un argument commercial. Microsoft a annoncé en février l’ouverture de ses premiers European Sovereignty & Digital Resilience Studios à Bruxelles, Munich et Amsterdam. Le groupe explique vouloir aider ses clients à concevoir des solutions « souveraines », et précise que le studio de Bruxelles associe ingénieurs, experts sécurité et équipe européenne des affaires publiques. Tout cela est légal, public, assumé. Mais cela montre bien que la souveraineté européenne n’est plus seulement un mot d’ordre politique : elle est devenue un terrain de concurrence, de communication et d’influence. Quand les hyperscalers se mettent eux-mêmes à vendre de la « souveraineté made in Europe », c’est bien qu’ils ont compris où se déplace le centre de gravité du débat.

Il faut toutefois rester lucide : le réveil européen n’est pas encore une victoire. Oui, il y a aujourd’hui l’impression d’un premier pas en avant. Oui, le ton a changé à Bruxelles. Oui, plusieurs dirigeants européens semblent enfin comprendre que le numérique n’est plus un secteur parmi d’autres, mais l’une des conditions de la puissance, de la résilience et de la liberté de décision. Et oui, le fait que Washington réagisse aussi vivement est en un sens une bonne nouvelle : cela signifie que le message européen commence à inquiéter, donc à compter.

Mais c’est précisément pour cette raison que céder maintenant serait une erreur majeure. Si l’Europe accepte de négocier à la baisse sa régulation, ou même de l’affaiblir discrètement au nom de contreparties commerciales ou d’un apaisement de court terme, elle transformerait ce premier pas en illusion. Ce serait non pas un compromis tactique, mais dix pas en arrière. On ne lâche pas un marathon au moment où l’effort commence enfin à produire un effet. Car si cette fenêtre politique se referme, rien ne garantit qu’elle se rouvrira rapidement. La souveraineté numérique européenne serait à nouveau reportée, comme si elle pouvait toujours attendre une autre fois…

Le danger ne vient d’ailleurs pas seulement de Washington. Il peut aussi venir d’un relâchement intérieur, plus feutré, plus technocratique, mais tout aussi structurant. Sur le Digital Omnibus, par exemple, l’EDPB et l’EDPS ont soutenu l’objectif de simplification, tout en demandant explicitement aux co-législateurs de ne pas adopter certaines modifications de la définition de la donnée personnelle, qu’ils jugent susceptibles d’affaiblir nettement la protection des droits. Là encore, le signal est utile : la compétitivité ne peut pas servir en permanence de prétexte pour affaiblir nos propres règles. Une Europe qui allégerait ses garde-fous au moment même où elle prétend défendre sa souveraineté numérique enverrait un message profondément contradictoire.

Le fond du problème tient en une phrase : réguler ne suffit pas sans capacité industrielle, mais construire des capacités ne sert à rien si l’on commence par renoncer à ses règles. Les deux mouvements doivent avancer ensemble. La Commission l’a d’ailleurs reconnu dans son propre bilan de la décennie numérique : les dépendances excessives de l’Union restent particulièrement fortes dans les semi-conducteurs, le cloud, les infrastructures de données et la cybersécurité. Et si Bruxelles a ouvert fin 2025 des investigations de marché sur AWS et Azure au titre du DMA, c’est précisément parce que le cloud est devenu l’une des couches les plus stratégiques de cette dépendance.

Ce débat ne doit donc pas rester confiné aux experts, aux cabinets ou aux couloirs de la bulle bruxelloise. Il faut que le grand public s’en saisisse, non pour répéter des slogans, mais pour se forger un avis éclairé. Car la souveraineté numérique ne concerne pas seulement les plateformes ou les amendes infligées à quelques groupes américains. Elle concerne la capacité de l’Europe à décider pour elle-même, à protéger ses données, à sécuriser ses services essentiels, à préserver sa marge de manœuvre économique et politique. En d’autres termes : elle concerne notre avenir collectif. Et sur ce sujet, les citoyens ont raison d’attendre davantage que des déclarations de principe. Ils ont besoin de constance, de cohérence et d’une direction claire.

L’article L’Europe régule les géants américains, mais dépend encore d’eux est apparu en premier sur Souverain.

Depuis, mon « laboratoire » a continué d’évoluer. Pas de révolution spectaculaire, pas de promesse magique non plus. Plutôt quelque chose de plus intéressant : une progression lente, concrète, parfois bancale, mais formatrice. Et s’il fallait résumer cette nouvelle étape en une phrase, ce serait peut-être celle-ci : l’auto-hébergement devient vraiment passionnant au moment où il cesse d’être un simple test technique pour devenir un exercice d’autonomie.

YunoHost, confirmé sans ambiguïté

Sur un point au moins, le doute n’existe plus pour moi : YunoHost reste, et il restera. Umbrel avait joué son rôle de porte d’entrée. L’outil a permis de commencer, de prendre confiance, d’oser mettre les mains dans un serveur maison. Mais le plafond de verre a fini par apparaître. Avec YunoHost, quelque chose s’est débloqué : davantage de compréhension, davantage d’autonomie, et surtout le sentiment de ne plus seulement utiliser un système, mais de commencer à l’habiter. YunoHost se présente lui-même comme une distribution serveur conçue pour simplifier l’administration, avec une interface web, un catalogue d’applications, la gestion des certificats SSL, des sauvegardes et même une brique « courriel » complète.

Il faut toutefois reconnaître une chose, avec humilité : ce type de récit risque toujours de froisser les administrateurs système de métier. Elena Rossini, dans l’un de ses guides pour débutants sur YunoHost (en anglais), l’écrit très bien : «  Avertissement : cet article risque de déplaire aux administrateurs système. » La formule est juste. Car ici, il n’est pas question de se faire passer pour un expert. Le métier d’admin système n’est pas le sujet. L’objectif est plus modeste, et sans doute plus honnête : comprendre les concepts, reproduire au plus près ce qui semble propre, apprendre à corriger ses erreurs, et progresser sans jouer un rôle.

Cette logique d’apprentissage a porté ses fruits. Aujourd’hui, ce ne sont plus un, mais trois serveurs qui tournent à la maison. Le choix s’est porté sur des mini-PC reconditionnés, pour éviter une facture énergétique absurde et garder une infrastructure cohérente avec le discours sur la sobriété numérique. Les machines continuent par ailleurs à s’éteindre automatiquement la nuit, et jusqu’ici cela n’a pas créé de contrainte évidente. Sur ce point, les retours d’expérience d’autres auto-hébergeurs seraient d’ailleurs précieux : le débat reste ouvert en commentaire.

Il y a aussi une petite fierté très concrète dans cette progression : le recyclage d’un ancien onduleur. Une batterie neuve, quelques réglages, et voilà désormais une quinzaine de minutes de sécurité en cas de coupure, avec arrêt propre des serveurs quand le niveau devient critique. Cela paraît modeste. Pourtant, dans un parcours d’auto-hébergement, ces petites victoires comptent beaucoup. Elles marquent le moment où l’on cesse simplement d’installer des services pour commencer à penser continuité, résilience et dépendances.

Le vrai point faible : les sauvegardes

Le gros point noir, lui, n’a pas disparu. Il s’est même imposé comme la question centrale : la sauvegarde existe, mais la restauration n’a pas encore été réellement éprouvée. Et c’est précisément là que se niche le danger.

Oui, des sauvegardes automatiques partent vers un NAS depuis le serveur le plus sensible. Oui, le réflexe de protéger les données est installé. Mais tant qu’une restauration complète n’a pas été testée, une part de cette sécurité reste théorique. C’est le genre de vérité qu’on préfère repousser, souvent par peur de provoquer soi-même la catastrophe qu’on cherche justement à éviter. Rescuezilla, de son côté, se présente comme un outil graphique d’image disque et de restauration, amorçable depuis une clé USB, pensé justement pour rendre ces opérations plus accessibles. Ce pourrait être une piste sérieuse pour enfin passer du principe à l’épreuve réelle.

Au fond, l’auto-hébergement oblige à une forme de maturité. Il pousse à regarder en face ses angles morts. Et celui-ci est évident : tant que la restauration n’est pas maîtrisée, l’autonomie reste partielle.

Ce qui fonctionne, et qui est de moins en moins négociable

Dans les services qui se sont installés durablement, LaSuite Meet (Visio) fait partie des évidences. L’outil est utilisé plusieurs fois par semaine, sans friction, sans mise en scène, ce n’est pas une usine à gaz. Et c’est peut-être cela, le meilleur compliment possible pour une brique numérique : quand l’interlocuteur en face est presque surpris par la simplicité du service. Visio est d’ailleurs présenté par DINUM comme une solution de visioconférence souveraine, ouverte, sécurisée et hébergée en France.

Docs, dans le même écosystème, reste plus ambivalent. L’outil a de vraies qualités et son positionnement est clair : un espace d’écriture collaborative simple, pensé pour rédiger, partager et publier. Il entre progressivement dans mes usages. Mais l’expérience d’auto-hébergement rappelle aussi une réalité moins glamour : entre la promesse d’un logiciel et la qualité de son paquet sur une distribution comme YunoHost, il peut subsister un écart frustrant. Quand l’insertion d’une image dans un document ne fonctionne toujours pas, l’adoption reste freinée, même si le potentiel est là.

Karakeep, lui aussi, mérite de rester. La solution pour gérer les favoris est bonne, pratique, et franchement convaincante à l’usage. Mais il faut y ajouter un avertissement de terrain : avant chaque mise à jour, mieux vaut prévoir une sauvegarde ou un export. Ce n’est pas une posture paranoïaque, c’est un retour d’expérience. Trop souvent, la mise à jour tourne mal et impose une désinstallation, une réinstallation, puis une réimportation des données.

Et puis il y a Mastodon. Sans doute la brique la plus symbolique de tout cet ensemble. Parce qu’au-delà du service lui-même, une instance Mastodon auto-hébergée donne une sensation très particulière : celle d’être enfin maître chez soi dans un espace social numérique. Mastodon stocke par défaut les fichiers sur le système de fichiers du serveur, et sa documentation rappelle bien que les médias et caches peuvent vite prendre de la place. Les versions récentes proposent certes des réglages depuis le terminal via des commandes de maintenance, mais sur une petite installation maison, tout cela reste encore trop technique dès qu’il faut vraiment reprendre la main sur l’espace disque.

Le grand chantier toujours repoussé : le courriel

S’il reste un sujet qui concentre à la fois frustration, prudence et appréhension, c’est bien l’hébergement du courrier électronique.

Le passage à l’acte n’a pas encore eu lieu. Pas sérieusement. L’idée serait plutôt d’avancer un jour, par petits pas, avec un domaine dédié, sans exposer d’emblée une adresse critique. Car le courriel n’est pas un service comme les autres. La marge d’erreur y semble plus faible. Il y a la peur du spam, la peur du mauvais paramétrage, la peur d’atterrir dans les indésirables, la peur aussi d’un espace disque mal géré ou d’une panne au mauvais moment.

Une inquiétude revient souvent : un serveur coupé la nuit risque-t-il de faire perdre les messages reçus pendant ce laps de temps ? Sur le fond, le protocole SMTP est plus tolérant qu’on l’imagine. Les serveurs expéditeurs sont censés mettre les messages en file d’attente et réessayer plus tard. La RFC 5321 recommande même des tentatives espacées d’au moins 30 minutes et un abandon seulement après plusieurs jours, généralement au moins quatre à cinq. Cela ne rend pas l’auto-hébergement mail simple pour autant, mais cela évite au moins une idée fausse : un serveur de courriel indisponible quelques heures ne signifie pas automatiquement des messages perdus.

Le contexte, en revanche, ne me rassure pas. Google a renforcé ses exigences depuis le 1er février 2024 pour tous les expéditeurs qui écrivent vers Gmail, avec SPF ou DKIM, DNS cohérents, TLS et contrôle du taux de spam. Pour les expéditeurs volumineux, les contraintes montent encore d’un cran. Yahoo a suivi la même tendance, en demandant notamment l’authentification du courrier, un DNS valide et, pour les envois importants, SPF, DKIM et DMARC. Autrement dit : même pour un petit auto-hébergeur, l’époque ne pousse pas à l’improvisation. Je vous invite d’ailleurs à regarder la vidéo de Benjamin Bayart avec Quentin Adam, qui évoquent justement ce sujet, ainsi que le Fediverse.

C’est d’ailleurs pour cela qu’avant de basculer un jour le courrier en auto-hébergement, la partie sauvegarde et restauration devra être sérieusement maîtrisée. Tant que ce socle n’est pas solide, la tentation de « laisser faire les professionnels » reste parfaitement compréhensible.

Le Fediverse, cette fois comme terrain d’expérimentation concret

Ces derniers temps, le vrai centre de gravité s’est déplacé vers un autre sujet : le Fediverse.

Mastodon, d’abord, est validé. L’outil fonctionne, il est compris, il est assumé. Et surtout, il a montré qu’il était possible, même sans bagage d’admin système, de déployer et maintenir un service fédéré à domicile avec un niveau d’autonomie déjà très satisfaisant.

Pixelfed, en revanche, raconte une autre histoire. L’installation avance bien, le paquet existe dans le catalogue YunoHost, et l’idée d’une alternative fédérée à Instagram est évidemment séduisante. Mais la question de la migration reste, pour l’instant, un vrai point faible. Le sujet n’est pas bloquant dans l’immédiat avec seulement deux photos publiées sur une instance de test, mais il devient important dès que l’on réfléchit à long terme. Migrer proprement d’une instance à une autre, sans perdre le fil de son usage, devrait être une évidence dans un univers qui fait de l’interopérabilité et de la fédération un argument central. Or, même dans les discussions du dépôt Pixelfed, des utilisateurs décrivent une procédure vague, difficile à déclencher et parfois incomplète.

Le message, au fond, est simple : Pixelfed a des promesses, mais sa pédagogie côté migration n’est pas encore au niveau. Et pour un projet qui prétend ouvrir une voie crédible hors des plateformes centralisées, ce n’est pas un détail.

Dans le même mouvement, un autre chantier s’est ouvert avec Matrix. Plus exactement avec Tuwunel, qui se présente comme un serveur Matrix alternatif, évolutif, économique, écrit en Rust, pensé comme une alternative plus scalable et moins coûteuse à Synapse (maintenant Element Synapse). Le choix de Tuwunel s’est donc fait dans une logique de légèreté perçue et d’expérimentation, tout en restant ouvert à la contradiction (en commentaire) si l’analyse mérite d’être corrigée par des utilisateurs plus aguerris du protocole.

Le reverse proxy, ou comment plusieurs serveurs ont commencé à cohabiter

Avec plusieurs serveurs à la maison, une difficulté très concrète s’est imposée : un même port entrant sur un routeur ne peut pointer que vers une seule machine à la fois. Dit autrement, si un service web public sur le port 80 ou 443 doit être servi par plusieurs machines internes, il faut un intermédiaire capable de recevoir la requête et de l’orienter vers le bon serveur. C’est précisément le rôle d’un proxy inverse et le paquet Reverse Proxy de YunoHost est justement conçu pour exposer un autre service web, y compris en HTTPS, vers une destination interne.

Le plus intéressant, ce n’est pas vraiment la définition du reverse proxy, mais le moment où l’on comprend à quoi il sert face à une situation concrète.

Dans mon cas, la mise en place s’est faite en plusieurs étapes très simples à comprendre une fois le principe assimilé.

D’abord, sur le serveur qui est directement exposé à Internet depuis le routeur, il a fallu créer dans YunoHost le sous-domaine qui servira à publier le service, puis lui associer un certificat SSL avec l’option Let’s Encrypt. Cette étape est importante, car c’est ce serveur qui recevra les connexions venant de l’extérieur.

Ensuite, sur le second serveur, celui qui héberge réellement l’application, il a fallu créer exactement le même sous-domaine dans YunoHost. En revanche, cette fois, il n’était ni possible ni utile d’y ajouter un certificat SSL. Ce second serveur n’étant pas exposé directement sur le port 80 du routeur, c’est le premier serveur qui joue le rôle d’intermédiaire.

Une fois cela fait, retour sur le premier serveur, dans le catalogue d’applications YunoHost, pour installer l’application Reverse Proxy.

Au moment de l’installation, voici les champs que j’ai remplis :

• dans Libellé pour Reverse Proxy, il suffit de mettre un nom, celui que vous souhaitez
• dans Choisissez le domaine sur lequel vous souhaitez installer cette application, il faut sélectionner le sous-domaine créé sur les deux serveurs
• dans Choisissez le chemin d’URL (après le domaine) où cette application doit être installée, il faut renseigner simplement /
• dans Emplacement de destination (unix:/fichier pour socket), il faut indiquer l’adresse du serveur qui héberge réellement le service, par exemple https://192.168.0.3/
• dans Qui doit avoir accès à cette application ? (Ceci peut être modifié par la suite), il faut choisir Visiteurs, si l’on veut que le service soit accessible publiquement et sans avoir besoin de s’identifier.
• enfin, dans Dossier pour les fichiers statiques, il est possible de laisser le champ vide.

À ce stade, le reverse proxy est en place. Mais pour que le service fonctionne aussi correctement à la maison, sur le réseau local, il a fallu ajouter une dernière étape. Dans mon cas, comme j’utilise AdGuard Home comme serveur DNS local, j’ai ajouté une Réécriture DNS. Cela permet d’indiquer que le nom de domaine du service doit pointer vers l’adresse IP du serveur concerné sur le réseau local. Grâce à cela, plus besoin de modifier les fichiers hosts sur chaque appareil, ni de taper l’adresse IP manuellement dans le navigateur.

Et c’est là que tout a commencé à devenir vraiment clair : une fois cette configuration terminée, le service était accessible aussi bien depuis la maison que depuis l’extérieur.

Le résultat a quelque chose de très satisfaisant : d’un côté, le service devient accessible proprement depuis la maison, de l’autre, il reste joignable depuis l’extérieur après vérification en 4G. Et surtout, cette compréhension ouvre de nouvelles perspectives. Car derrière cette réussite technique, il y a en réalité une conséquence plus importante : l’infrastructure peut commencer à se répartir intelligemment, au lieu d’empiler tous les services sur une seule machine (et de prendre trop de risques en cas de panne …).

Ce que cette progression change pour la suite

En comprenant mieux comment répartir les services entre plusieurs serveurs, de nouvelles perspectives deviennent possibles. C’est précisément dans ce cadre qu’Immich m’apparaît aujourd’hui comme une option beaucoup plus crédible. L’idée de remplacer sérieusement Google Photos existe depuis longtemps, mais jusqu’ici, installer un service aussi lourd sur la même machine que d’autres briques sensibles me paraissait trop risqué. Il y avait trop de dépendances, trop de concentration de services dans un seul serveur, et donc trop de chances qu’une panne ou une mauvaise manipulation fragilise l’ensemble.

Désormais, la perspective change. Plus l’apprentissage progresse, plus l’infrastructure elle-même appelle une nouvelle organisation. Non pas pour faire plus compliqué, mais pour éviter qu’un seul incident mette à terre toute l’autonomie patiemment construite.

Conclusion

Il faut donc garder une forme de lucidité et d’humilité. Sur le papier, tout cela a quelque chose de très séduisant. Dans la pratique, cela a un coût. Même en essayant de rester mesuré avec des mini-PC reconditionnés, il y a le prix des machines, l’électricité, l’onduleur, qui peut d’ailleurs coûter plus cher qu’un des serveurs et surtout le temps.

À ce stade, il serait malhonnête d’affirmer que tout cela est déjà rentable. Ce n’est pas encore certain. En revanche, une chose devient plus claire avec l’expérience : si demain une solution équivalente, plus simple et moins coûteuse se présente, il n’y aurait aucune raison d’en faire une question dogmatique. L’objectif de départ n’a jamais été de sanctifier l’auto-hébergement. L’objectif, au départ, consistait à tester, comprendre et apprendre, mais avec une idée plus profonde en tête : faire émerger, quand cela fonctionne, de vraies solutions d’usage, capables de réduire durablement certaines dépendances aux GAFAM.

Et rien que pour cela, le chemin valait déjà la peine d’être emprunté.

L’article Le Fediverse, une nouvelle étape durable dans l’auto-hébergement est apparu en premier sur Souverain.

Il y a d’abord eu l’annonce saluée par Stéphane Séjourné de l’accueil, à Lille, de la future Autorité douanière européenne. Le gouvernement et la douane française présentent cette implantation comme un jalon important pour mieux protéger le marché européen, lutter contre les fraudes et renforcer la maîtrise des flux commerciaux. L’enjeu mérite sans doute encore d’être éclairci pour le grand public, tant il reste difficile de mesurer, à ce stade, ce que cette nouvelle autorité changera concrètement en matière de souveraineté économique. Une interpellation a bien été adressée à Stéphane Séjourné sur son compte X à ce sujet, sans réponse à ce jour.

Dans le même temps, le très contesté dispositif souvent désigné sous le nom de Chat Control a connu un coup d’arrêt. Le dossier ne disparaît pas pour autant, puisqu’il pourrait revenir sous une autre forme dans les prochains mois. Il serait donc excessif d’y voir une victoire définitive, mais il reste possible d’y lire, au moins, un répit politique dans un débat où la tentation de la surveillance généralisée demeure forte.

Post by @echo_pbreyer@digitalcourage.social

View on Mastodon

Sur un autre registre, le débat autour du projet Digital Omnibus a lui aussi continué de prendre de l’ampleur. À partir d’un article rédigé en anglais par Axel Laniez pour Clever Cloud, une analyse a également été publié ici afin de proposer une lecture plus pédagogique, en français, tournée vers le grand public. L’enjeu reste toujours le même : rendre lisibles des arbitrages européens souvent techniques, mais dont les effets pourraient être considérables sur l’équilibre entre simplification réglementaire, protection des droits et compétitivité des acteurs européens.

La semaine aura aussi été marquée par une série de commissions et d’auditions qui, chacune à leur manière, ont donné à voir l’état réel du débat français et européen. Une table ronde sur le 28e régime européen de droit des affaires s’est tenue le 24 mars, avec en toile de fond une question décisive : celle de la capacité de l’Union à offrir enfin un cadre plus simple et plus cohérent à ses entreprises. La vidéo semble déjà appeler un article spécifique tant ses implications pourraient être profondes pour le marché intérieur et pour la compétitivité européenne.

Le même mouvement s’est prolongé à l’Assemblée nationale avec la commission d’enquête sur les dépendances structurelles et les vulnérabilités systémiques dans le secteur du numérique, qui a poursuivi ses travaux avec plusieurs séquences marquantes : une table ronde réunissant La Quadrature du Net, Amnesty International et la Ligue des droits de l’Homme sur le thème de la protection des données personnelles, l’audition de Mme Soizic Pénicaud, cofondatrice de l’Observatoire des algorithmes publics, des auditions liées à la Cour des comptes et au Health Data Hub, puis, enfin, l’audition du collectif Eurostack, représenté par Cristina Caffarra et Yann Lechelle.

C’est sur cette dernière audition que cet article souhaite revenir, tant elle éclaire un basculement possible du débat : moins de fascination pour la régulation comme horizon suffisant, davantage d’attention portée à l’action, à la commande, à la doctrine publique et à la capacité européenne de produire enfin ses propres leviers de puissance.

Cet article s’organisera donc en trois volets. D’abord, un résumé de l’audition elle-même. Ensuite, un point sur le sujet de la DINUM, qui occupe en réalité une place moins importante qu’il n’y paraît dans la lecture politique de cette commission. Enfin, un regard sur la stratégie de communication et le champ lexical mobilisés, en particulier par Cristina Caffarra, dont l’approche semble ouvrir une voie intéressante : celle d’un discours qui ne renonce pas à la régulation, mais qui replace l’effort, la construction et la cohésion au centre du débat sur notre souveraineté numérique.

Résumé de l’audition du collectif Eurostack

L’audition part d’un constat simple : l’Europe est devenue massivement dépendante d’acteurs numériques extra-européens, principalement américains, sur l’ensemble de la chaîne technologique, des infrastructures cloud aux logiciels, jusqu’aux briques d’intelligence artificielle. Pour Cristina Caffarra comme pour Yann Lechelle, cette dépendance ne constitue pas seulement un risque en matière de sécurité ou de résilience, elle représente surtout un problème économique majeur, car elle prive l’Europe de la capacité à capter la valeur créée par les services numériques qu’elle consomme.

Le cœur de leur thèse est que l’Europe a trop longtemps cru que la régulation des grandes plateformes suffirait à corriger les déséquilibres. Selon eux, cette stratégie a montré ses limites : l’Union européenne a effectivement produit des règles, engagé des procédures et sanctionné certains abus, mais elle n’a pas, dans le même temps, fait émerger à grande échelle des alternatives européennes capables de reconquérir le marché. En d’autres termes, l’Europe a davantage encadré qu’elle n’a construit. Cette idée traverse toute l’audition et sert de point de départ à un déplacement plus large du débat : il ne s’agirait plus seulement de contenir des positions dominantes, mais de reconstruire une capacité industrielle et commerciale européenne.

Eurostack déplace le centre du débat : le sujet principal ne serait pas l’absence d’offre européenne, mais l’absence de demande réellement orientée vers cette offre. Yann Lechelle insiste sur ce point à plusieurs reprises : les compétences existent, les entreprises existent, les briques technologiques existent, mais elles restent trop petites, trop dispersées et trop peu achetées pour atteindre la taille critique. Le problème ne serait donc pas d’abord technique, il serait structurel, commercial et politique.

Les auditionnés chiffrent ce déséquilibre en rappelant qu’environ 260 à 300 milliards d’euros quitteraient chaque année l’Europe pour rémunérer des fournisseurs extra-européens, dont une part considérable pour le cloud et le logiciel. Leur idée est qu’un simple redéploiement d’une faible fraction de ces flux vers des acteurs européens pourrait suffire à changer radicalement leur taille, leur capacité d’investissement et leur aptitude à consolider le secteur. C’est ce qu’ils présentent comme le véritable levier de souveraineté : non pas un discours abstrait, mais une réorientation concrète des achats.

Dans cette logique, la commande publique occupe une place centrale. Eurostack considère qu’elle devrait servir d’amorce, non pour remplacer le marché, mais pour créer un signal économique clair, soutenir les acteurs européens crédibles et leur permettre d’atteindre une masse critique. Dans cette lecture, les achats publics ne relèveraient plus seulement de la gestion administrative, ils deviendraient un instrument de politique industrielle, susceptible d’enclencher ensuite un mouvement d’entraînement dans le secteur privé.

Au-delà de la commande publique, l’audition insiste aussi sur la nécessité de transformer les pratiques d’achat elles-mêmes. Les hyperscalers américains bénéficient d’un avantage décisif : ils proposent des offres intégrées, lisibles, faciles à acheter et faciles à déployer. À l’inverse, l’offre européenne existerait bien, mais sous une forme fragmentée. Il faudrait donc apprendre à « dé-bundler » les offres dominantes et, symétriquement, à recomposer des solutions européennes assemblées à partir de briques locales. Cela supposerait, selon eux, un véritable changement de culture chez les acheteurs publics et privés.

L’open source apparaît, dans cette audition, comme un levier stratégique majeur. Non pas comme un slogan, mais comme un outil de réversibilité, d’interopérabilité et de rattrapage. Yann Lechelle soutient que l’exigence d’un socle open source dans les cahiers des charges permettrait de limiter l’enfermement propriétaire, de garder la maîtrise technique du « sous-jacent » et de rendre possibles des bascules d’un fournisseur à l’autre. Plus largement, l’ « open » est présenté comme une méthode pragmatique pour reconstruire des marges de manœuvre européennes couche par couche.

Sur la question de la régulation, l’audition est plus nuancée qu’un simple rejet. Cristina Caffarra distingue clairement la régulation économique, qu’elle juge trop lente et trop peu efficace face à des acteurs déjà ultra-dominants, des régulations destinées à protéger les citoyens, les enfants, les données personnelles ou certaines valeurs européennes, dont la légitimité n’est pas contestée. Son point n’est donc pas d’abandonner toute régulation, mais de rappeler que la régulation économique, à elle seule, ne recréera pas un marché européen puissant si elle n’est pas accompagnée d’une politique industrielle et commerciale assumée.

L’autre obstacle mis en avant est politique. L’audition laisse apparaître une critique du climat européen de prudence, de lenteur et de peur face aux accusations de protectionnisme. En filigrane, les intervenants suggèrent qu’une partie du débat européen resterait paralysée par des réflexes défensifs, alors même que plusieurs États membres convergeraient davantage qu’on ne le dit sur la nécessité de rééquilibrer la chaîne de valeur numérique. L’enjeu, dans cette perspective, serait moins de commenter indéfiniment la dépendance que de commencer à organiser les conditions de sa réduction.

Il apparaît qu’Eurostack ne se contente pas de dénoncer la dépendance européenne aux Big Tech américaines. Le collectif adresse aussi un message direct à l’appareil d’État français : la souveraineté numérique ne se reconstruirait ni par la seule régulation, ni par une administration qui chercherait à produire elle-même toutes les briques de haut niveau. En visant explicitement la DINUM, Yann Lechelle soutient que l’État devrait d’abord jouer un rôle de stratège et d’acheteur : identifier les briques pertinentes, imposer des exigences de réversibilité et d’ouverture, puis orienter ses budgets vers des acteurs capables d’industrialiser l’offre. La commande publique deviendrait alors non plus un simple outil administratif, mais un levier de politique industrielle.

La fin de l’audition revient enfin sur les communs numériques, le rôle de l’État et l’indice de résilience numérique. Sur ce point, Yann Lechelle plaide pour une distinction claire : les communs numériques ont leur utilité, mais ils ne devraient pas être confondus avec une offre industrielle structurée. L’État, dans cette perspective, n’aurait pas vocation à devenir lui-même éditeur logiciel sur toute la chaîne, son rôle consisterait plutôt à sélectionner, orienter, financer intelligemment et acheter les bonnes solutions, idéalement auprès d’acteurs capables de maintenir des briques ouvertes. Quant à l’indice de résilience numérique, il est présenté comme un outil de pédagogie et de mesure destiné à aider les entreprises à objectiver leur dépendance et à prendre conscience de leurs vulnérabilités réelles.

La souveraineté numérique européenne ne se gagnerait ni par la seule dénonciation des Big Tech, ni par la seule régulation. Elle se construirait en redirigeant les flux économiques, en réarmant la commande publique, en structurant une demande européenne et en s’appuyant sur l’open source pour rendre possibles des alternatives crédibles. Et, dans le cas français, cette ligne implique aussi un débat plus précis sur la place que devrait occuper la DINUM dans l’architecture de cette stratégie.

Le point sur la DINUM

Il apparaît que certains propos de Yann Lechelle ne vise pas seulement, de manière abstraite, l’administration ou l’État. Il évoque le rôle de la DINUM, c’est-à-dire la direction interministérielle du numérique, dont la mission officielle consiste à élaborer la stratégie numérique de l’État et à piloter sa mise en œuvre.

Dans l’audition, Yann Lechelle explique en substance que la DINUM essaye de tout faire en même temps, qu’elle devrait davantage s’appuyer sur des technologies ouvertes déjà disponibles, et que son rôle ne serait pas tant de développer elle-même que de sélectionner les bonnes piles technologiques, puis d’orienter ses budgets vers les acteurs capables de les maintenir et de les industrialiser. Il ajoute même que ces budgets seraient, selon lui, mieux employés s’ils allaient vers des entreprises « motivées par la performance ».

Dans cette logique, l’État devrait surtout être stratège, acheteur et architecte de la demande, plutôt que producteur direct sur toute la chaîne.

Ce point mérite toutefois d’être replacé dans son contexte. Officiellement, la DINUM ne se présente pas comme un éditeur commercial appelé à prendre la place du marché. Elle se présente comme la cheffe de file du numérique de l’État, et LaSuite comme une collection d’applications conçue pour le secteur public et réutilisable par tous. La doctrine publiée par l’État en février 2026 précise d’ailleurs les conditions dans lesquelles les administrations doivent privilégier des solutions disponibles sur le marché, ou, à l’inverse, développer en interne, dans une logique de soutien au numérique français et européen.

Autrement dit, le désaccord mis au jour par cette audition ne semble pas opposer frontalement la souveraineté numérique à l’économie de marché. Il porterait plutôt sur la répartition des rôles. D’un côté, Eurostack soutient que l’État devrait d’abord créer les conditions de marché permettant à des acteurs européens de monter à l’échelle. De l’autre, la stratégie publique actuelle montre qu’une partie de l’administration considère aussi légitime de bâtir un socle public ouvert, notamment lorsqu’aucune offre ne s’est imposée avec suffisamment de clarté, de cohérence ou de réversibilité.

Or c’est précisément au moment où l’État, via la DINUM, met en circulation un socle concret avec LaSuite, qu’une partie du marché hausse le ton et parle de concurrence déplacée ou de brouillage des rôles. Cette séquence peut donc donner le sentiment d’une contradiction : appeler à l’action, puis contester plus vivement l’intervention publique lorsqu’elle cesse d’être théorique. Les critiques existent bel et bien publiquement : le CNLL a dénoncé une « concurrence irresponsable », Acteurs publics a relevé que le projet ne faisait pas l’unanimité, et LeMagIT a décrit une initiative « très critiquée » par des acteurs français du secteur.

Cette tension surprend d’autant plus que le marché ne semble pas avoir été pris de court. Les signaux envoyés par l’État sur l’open source et les communs numériques sont anciens et répétés. Une première circulaire du Premier ministre sur l’usage des logiciels libres dans l’administration remonte à 2012. En 2021, une nouvelle circulaire du Premier ministre sur la donnée, les algorithmes et les codes sources annonçait déjà la mise en place, au sein de la DINUM, d’une mission dédiée au logiciel libre et aux communs numériques. En 2026, la doctrine d’achat public numérique a encore précisé que l’État devait arbitrer entre solutions de marché et développement interne dans une logique de soutien au numérique français et européen. À cela s’ajoute une chronologie publique sur LaSuite elle-même : lancement officiel en mai 2024, communication continue de la DINUM, médiatisation grand public en 2025, sans oublier le fait que, dès 2020, les difficultés de l’administration à trouver une alternative satisfaisante à Zoom étaient déjà discutées publiquement. Il serait donc difficile de soutenir que l’écosystème n’avait ni vu venir le sujet, ni compris que la question d’une suite collaborative souveraine finirait par se poser de manière opérationnelle.

Dans les textes officiels, la DINUM n’explique d’ailleurs pas vouloir commercialiser LaSuite ni évincer le marché. La documentation publique précise au contraire que LaSuite n’est pas destinée à un usage interne aux entreprises privées, tout en ajoutant que toute organisation non éligible à l’offre mutualisée de l’État peut déployer sa propre instance et l’exploiter sous sa responsabilité. La doctrine publiée en février 2026 va dans le même sens : elle présente LaSuite comme une architecture en trois cercles, avec un socle stratégique opéré par l’État, des services complémentaires proposés sans exclusivité aux côtés d’outils du secteur privé, puis des outils innovants mobilisant la filière française des éditeurs. Pris au pied de la lettre, ce cadre ne décrit donc pas une nationalisation du collaboratif, mais plutôt la mise à disposition d’un socle ouvert, susceptible de laisser de la place à des intégrateurs, éditeurs et prestataires européens.

Il serait également excessif d’affirmer qu’aucune offre française n’existe pour les entreprises. Des acteurs comme Jamespot, Wimi ou Whaller se présentent précisément comme des plateformes collaboratives souveraines ou des « digital workplaces » françaises pour organisations publiques et privées. Le point plus juste serait ailleurs : malgré l’existence de ce marché, aucun acteur ne semble s’être imposé, à ce stade, comme le véhicule évident d’une suite ouverte, interopérable et suffisamment lisible pour agréger à grande échelle les usages que l’État cherchait à couvrir. C’est peut-être là que se loge le vrai malentendu : non dans l’absence pure et simple d’offre, mais dans l’incapacité du marché à transformer, assez tôt, cette offre en réponse suffisamment claire pour éviter l’émergence d’un socle public.

La question budgétaire mérite, elle aussi, d’être regardée sans caricature. Oui, la Cour des comptes a pointé un coût de déploiement de près de 9,3 millions d’euros fin 2023, ainsi qu’un coût annuel de maintenance de 5 millions d’euros. Mais le même rapport rapporte aussi l’argument de la DINUM selon lequel ce niveau de dépense doit être relativisé au regard des coûts antérieurs : les licences privées donnant accès à une suite numérique complète auraient représenté entre 300 et 590 euros par agent et par an, là où LaSuite reviendrait alors à environ 75 euros par agent et par an, pour un coût total d’un peu moins de 15 millions d’euros et une utilisation moyenne de moins de 200 000 agents à cette date. Framasoft reprend ce point pour montrer que le débat ne peut pas être réduit à une simple dénonciation de la dépense publique : à périmètre comparable, l’enjeu n’est pas seulement ce que l’État a dépensé pour construire un socle, mais aussi ce qu’il dépensait auparavant, par utilisateur, pour rester dépendant de solutions sous licence. Dans cette lecture, la dépense initiale peut aussi être comprise comme un coût d’amorçage visant à créer enfin une base mutualisée, réutilisable et potentiellement moins coûteuse à long terme. Cela ne suffit pas, à lui seul, à clore le débat sur l’efficacité ou l’adoption, mais cela oblige au moins à comparer honnêtement le coût de construction avec le coût antérieur de dépendance.

Une prudence reste toutefois nécessaire : Framasoft reconnaît ne pas disposer du chiffrage exhaustif consolidé pour 2024 et 2025, et la Cour des comptes soulignait en 2024 que l’offre restait encore peu lisible et peu utilisée par une grande partie des agents. L’argument budgétaire le plus solide, à ce stade, n’est donc pas de prétendre que tout serait définitivement démontré, mais de rappeler qu’il existe désormais un ordre de grandeur documenté montrant qu’une suite publique open source pourrait coûter, par utilisateur, sensiblement moins cher que les solutions privées auxquelles l’État avait recours jusque-là.

Une lecture plus critique pourrait enfin relever que ce type de réaction défensive n’a rien d’exceptionnel dans l’histoire économique. Il serait trop simple d’en faire une loi universelle en affirmant que, « toujours », lorsqu’une corporation a peur, elle attaque. En revanche, il existe bien un schéma récurrent : lorsqu’un acteur installé perçoit une menace crédible pour sa rente, sa position ou son récit de légitimité, il tend souvent d’abord à délégitimer, encadrer ou ralentir ce qui le menace. Les exemples abondent : Microsoft décrivait l’open source comme une « menace directe » dans ses mémos internes de 1998, l’OMS documente depuis longtemps les tactiques des industriels du tabac pour peser sur les gouvernements, discréditer des politiques publiques et menacer de contentieux, la FTC a elle aussi documenté la manière dont des opérateurs télécoms ont longtemps combattu les réseaux municipaux plutôt que de laisser émerger une concurrence locale. Dans cette perspective, la virulence d’une partie des critiques adressées à la DINUM pourrait être lue moins comme la preuve d’une faute originelle de l’État que comme le symptôme d’un rapport de force devenu enfin concret.

Reste alors une question de fond, peut-être la plus politique de toutes : si tout le monde s’accorde désormais à dire qu’il faut agir, construire, acheter européen, structurer une demande et cesser de dépendre entièrement des grands fournisseurs extra-européens, pourquoi l’apparition d’un socle public ouvert suscite-t-elle d’abord autant de crispations au lieu de produire une dynamique d’appropriation, de service et d’industrialisation ? Formulée ainsi, la critique ne viserait plus seulement l’État. Elle inviterait aussi le marché à s’interroger sur sa propre capacité à saisir les occasions qu’il réclame pourtant depuis des années.

Cristina Caffarra, la voix qui oblige enfin l’Europe à parler puissance

Le titre de cette dernière partie aurait pu être également : « Cristina Caffarra, celle qui rappelle que la souveraineté ne se décrète pas, elle se construit » car l’un des aspects les plus intéressants de cette audition tient moins aux mesures évoquées qu’à la manière dont le problème est formulé. Sur ce point, Cristina Caffarra occupe une place singulière. Son discours ne consiste pas d’abord à détailler un plan technique ni à défendre un outil précis. Il consiste avant tout à requalifier le problème. Là où le débat européen reste souvent enfermé dans le langage de la conformité, de la régulation et de la protection, elle propose un déplacement plus large : la dépendance numérique ne relèverait pas seulement de la sécurité ou de la résilience, mais aussi de la croissance, de la productivité et de la captation de valeur. Ce glissement est loin d’être anodin, car il fait sortir la souveraineté numérique du seul registre défensif pour la replacer dans le champ de l’économie politique.

C’est probablement là que se situe la force de son intervention. Cristina Caffarra ne dit pas que la régulation serait inutile en toutes circonstances. Elle prend même soin de distinguer la régulation économique, qu’elle juge trop lente et trop peu transformatrice face à des acteurs déjà installés sur des trajectoires de domination, des régulations qui protègent les citoyens, les enfants, les données personnelles ou les valeurs européennes, dont elle ne conteste pas la légitimité. Ce qu’elle remet en cause, ce n’est donc pas le principe même de la règle. C’est l’idée, devenue presque réflexe en Europe, selon laquelle la règle suffirait à recréer un marché, une industrie et un rapport de force. Autrement dit, son propos ne consiste pas à abandonner la régulation, mais à la remettre à sa juste place.

Son champ lexical est révélateur. Les mots qui reviennent le plus souvent renvoient à la vulnérabilité, à la croissance, à la valeur, au retard, au lobbying, à la peur, à la nécessité de construire à l’échelle. Même lorsque le propos est économique, il n’est jamais présenté de manière purement comptable. Il est constamment relié à un imaginaire du rapport de force : celui d’une Europe qui aurait cru pouvoir corriger le réel par la norme, pendant que d’autres captaient les infrastructures, les usages, les marchés et, au bout du compte, la valeur. Lorsqu’elle explique que l’Europe a beaucoup régulé mais n’a pas construit à l’échelle, elle ne formule pas seulement une critique technique, elle propose une lecture historique de l’échec européen sur le numérique.

Cette stratégie discursive repose aussi sur une syntaxe très identifiable. Cristina Caffarra raisonne souvent à partir d’une syntaxe qui déplace le centre du débat : ce n’est pas seulement un sujet de sécurité, c’est aussi un sujet de croissance, ce n’est pas seulement un sujet de résilience, c’est aussi un sujet de valeur, ce n’est pas simplement un problème réglementaire, c’est un problème de capacité économique. Ce type de formulation n’a rien de secondaire. Il permet de déplacer le centre de gravité du débat sans donner l’impression de nier ce qui existait auparavant. La régulation n’est pas rejetée, elle est replacée dans un ensemble plus vaste. La souveraineté n’est pas réduite à la technique, elle est reliée à la puissance. Et le numérique n’est plus présenté comme un simple secteur parmi d’autres, mais comme l’infrastructure même sur laquelle se bâtissent d’autres chaînes de valeur.

Il faut également relever une seconde dimension de son discours : la mise au jour du récit adverse. Lorsqu’elle évoque Bruxelles, la pression des groupes d’intérêt, la peur du protectionnisme, ou encore l’idée selon laquelle toute tentative européenne de réorientation des flux serait immédiatement caricaturée comme une fermeture dangereuse, elle montre que le débat n’est pas seulement technique ou juridique. Il est déjà structuré par des mots, par des récits, par des intimidations symboliques. Son intervention consiste alors à dire, en creux, que l’Europe n’aurait pas seulement perdu du temps sur le terrain industriel, elle aurait aussi perdu du terrain dans le langage qu’elle utilise pour penser sa propre marge de manœuvre. En ce sens, Cristina Caffarra apparaît moins comme une experte venue commenter un secteur que comme une stratège du récit politique.

Face à elle, Yann Lechelle joue un rôle très différent, mais complémentaire. Là où Cristina recadre, Yann opérationnalise. Son vocabulaire est celui de l’offre, de la demande, des flux, de la masse critique, des carnets de commande, des acheteurs, du bundle et de la stack. Là où elle cherche à convaincre la commission que le vieux paradigme européen ne suffirait plus, lui cherche à montrer ce qu’il faudrait faire à la place : réorienter les achats, agréger des briques locales, développer une culture d’achat plus segmentée, exiger davantage d’ouverture et de réversibilité, considérer enfin la commande comme un levier de croissance et non comme un simple acte de gestion. L’un travaille le cadre intellectuel, l’autre travaille la mécanique de mise en œuvre.

C’est précisément cette articulation qui rend l’audition intéressante. Cristina Caffarra ouvre une brèche dans la manière habituelle de penser le sujet. Yann Lechelle s’y engouffre pour proposer une doctrine plus concrète de marché, de commande et d’assemblage industriel. L’une politise le diagnostic, l’autre industrialise la réponse. L’une dit, au fond, qu’il serait devenu illusoire d’attendre de la seule régulation économique qu’elle inverse la trajectoire. L’autre répond que, dans ce cas, il faudrait remplir les carnets de commande, structurer la demande et cesser de se raconter que le problème serait d’abord l’absence d’offre.

C’est sans doute pour cela que l’intervention de Cristina Caffarra mérite une attention particulière. Son intérêt ne tient pas seulement au contenu des propositions, mais à la discipline mentale qu’elle tente d’imposer au débat. Elle invite à sortir d’un face-à-face stérile entre fascination réglementaire et résignation stratégique. Elle ne nie pas l’importance des règles, mais elle semble rappeler que les règles, seules, ne construisent ni filière, ni marché, ni capacité. En cela, son approche ouvre effectivement une voie plus exigeante : celle d’un discours qui n’abandonne pas la régulation, mais qui replace au centre des préoccupations l’effort, la construction, la cohésion et la capacité d’agir ensemble.

Formulée ainsi, cette ligne a aussi un mérite politique. Elle permet de sortir d’une posture devenue familière en Europe : celle qui consiste à diagnostiquer lucidement les dépendances, à documenter les vulnérabilités, à multiplier les colloques et les procédures, tout en remettant sans cesse à plus tard la question la plus inconfortable, celle de la mise en capacité collective. Or c’est peut-être là, au fond, que cette audition cherche à produire son effet : faire comprendre qu’à force de commenter le décrochage, le risque serait de le transformer en habitude. Et qu’à l’inverse, le langage de la souveraineté numérique ne retrouverait de crédibilité que s’il acceptait enfin de parler non seulement de protection, mais aussi de construction.

L’article Après les discours, la construction : ce que révèle l’audition Eurostack est apparu en premier sur Souverain.

Pour le grand public, le mot omnibus peut sembler abstrait. En réalité, il désigne une méthode législative assez classique : au lieu de modifier un seul texte, on regroupe plusieurs ajustements dans un même paquet. Dans le cas présent, la Commission européenne a présenté en novembre 2025 un ensemble de modifications touchant plusieurs pans du droit numérique européen, dont les règles sur les données personnelles, la cybersécurité et certains volets liés à l’intelligence artificielle. L’objectif affiché est de simplifier la vie des entreprises, des administrations et, en théorie, des citoyens, tout en rendant l’économie européenne plus compétitive.

Sur le principe, difficile d’être contre la simplification. Le problème commence lorsque cette simplification touche au RGPD, c’est-à-dire au socle européen de protection des données personnelles. Entré en vigueur en 2016, le RGPD repose sur une idée claire : lorsqu’une information permet d’identifier une personne, directement ou indirectement, elle doit être protégée. Cela concerne évidemment le nom ou l’adresse de courriel, mais aussi, dans de nombreux cas, des identifiants, des données de localisation, des profils ou des recoupements d’informations.

Pourquoi est-ce si important ? Parce que le RGPD ne protège pas un simple « détail administratif ». Il protège une part de notre liberté concrète dans la vie numérique. Savoir qui collecte nos données, pour quoi faire, combien de temps, avec quels droits de regard ou d’opposition : tout cela conditionne notre capacité à rester des citoyens, et pas seulement des profils exploitables.

C’est dans ce contexte, celui de la consultation lancée par la Commission européenne pour nourrir le futur Digital Omnibus, qu’Axel Laniez a publié pour Clever Cloud une prise de position critique. L’entreprise ne rejette pas le principe d’une simplification. Elle soutient même certains allègements, notamment lorsqu’ils permettent de mieux coordonner les obligations de cybersécurité ou de tenir compte de la réalité des PME européennes. Mais elle estime que certaines modifications envisagées franchissent une ligne rouge dès lors qu’elles touchent à la définition de la donnée personnelle ou au traitement de données sensibles dans le cadre de l’intelligence artificielle.

Le premier sujet de friction concerne la définition de la donnée personnelle. La proposition discutée dans le cadre du Digital Omnibus introduit l’idée qu’une information ne serait pas nécessairement une donnée personnelle pour tous les acteurs, dès lors qu’un acteur donné n’aurait pas, lui, les moyens raisonnables d’identifier la personne concernée. Dit autrement : une même donnée pourrait être considérée comme protégée dans un contexte, mais plus forcément dans un autre. Clever Cloud y voit un risque de fragmentation du cadre européen. Et cette inquiétude n’est pas marginale : Le Comité européen de la protection des données (EDPB), qui veille à une application cohérente du RGPD dans l’Union européenne avec les autorités nationales, ainsi que le Contrôleur européen de la protection des données, ont eux aussi demandé aux co-législateurs de ne pas adopter ce changement. Ils estiment qu’il réduirait sensiblement la portée de la notion de donnée personnelle et créerait une insécurité juridique.

Pour un citoyen, l’enjeu est très concret. Si la définition devient plus « flottante », il devient plus difficile de savoir à quel moment nos informations sont réellement protégées, par qui, et selon quelles obligations. Or la confiance numérique ne repose pas sur des zones grises. Elle repose sur des règles lisibles et stables.

L’audition de Max Schrems rappelle que le débat sur l’omnibus numérique dépasse la seule technique juridique : il touche aussi aux dépendances du secteur numérique et à la protection concrète des droits en Europe.

Le second sujet sensible touche aux données dites « sensibles » : celles qui révèlent par exemple l’état de santé, les opinions politiques, l’origine ethnique, la religion ou l’orientation sexuelle. Le RGPD encadre déjà ces données de manière particulièrement stricte, précisément parce qu’elles exposent davantage les personnes au risque de discrimination, de surveillance ou d’atteinte à leur dignité.

Or le débat européen porte aussi sur l’introduction d’une nouvelle dérogation liée au développement et au fonctionnement des systèmes d’intelligence artificielle. Sur ce point, le message mérite d’être nuancé. Les autorités européennes de protection des données ne rejettent pas en bloc toute adaptation, elles reconnaissent qu’un encadrement plus clair peut être utile. Mais elles demandent des limites précises, une portée mieux définie et des garanties robustes sur tout le cycle de vie de l’IA, afin que l’exception ne devienne pas une porte d’entrée trop large. Clever Cloud formule, de son côté, une critique plus politique : accélérer l’IA ne doit pas conduire l’Europe à rogner ce qui fait justement sa singularité, à savoir des droits fondamentaux élevés et une vision exigeante de la protection des personnes.

Il serait pourtant réducteur de présenter tout le paquet comme une menace. Certaines mesures vont dans le bon sens. C’est notamment le cas de l’idée que soutient Clever Cloud: la création d’un point d’entrée unique européen pour signaler les incidents de cybersécurité. Aujourd’hui, selon les règles applicables, une organisation peut devoir déclarer un même incident à plusieurs interlocuteurs différents. Sous NIS2 (la directive européenne qui renforce la cybersécurité des organisations et services essentiels), par exemple, les incidents doivent être signalés à l’autorité nationale compétente et/ou au CSIRT national, c’est-à-dire à l’équipe chargée de réagir aux incidents informatiques, comme les cyberattaques ou les intrusions.

L’ENISA, l’Agence de l’Union européenne pour la cybersécurité (European Union Agency for Cybersecurity), coordonne déjà une partie de cette coopération entre États membres et appuie le réseau des équipes nationales de réponse aux incidents. L’idée du point d’entrée unique est donc simple : permettre aux organisations de transmettre une information une seule fois, via une interface commune, au lieu de répéter plusieurs démarches proches. La Commission assure que cela ne supprimerait pas les autorités existantes, mais simplifierait le signalement. Dans l’esprit, c’est une mesure de bon sens : mieux faire circuler l’information, plus vite, avec moins de complexité.

C’est d’ailleurs tout le cœur du débat. Simplifier, oui. Déréguler discrètement, non. L’Europe a construit avec le RGPD une référence mondiale. Ce texte est souvent critiqué pour sa complexité, parfois à raison. Mais il a aussi fixé une idée forte : dans l’économie numérique, la compétitivité ne saurait se bâtir au détriment des droits. Elle doit s’appuyer sur la confiance.

Le sujet mérite donc mieux qu’un réflexe pro-entreprise ou anti-entreprise. La bonne question est plus exigeante : quelles simplifications améliorent réellement la vie économique sans rogner les garanties offertes aux citoyens ? Car au fond, ce débat dépasse la technique : il touche à la manière dont l’Europe entend encadrer le numérique, entre efficacité économique, sécurité juridique et protection des libertés.

L’article Derrière la directive Omnibus, un débat essentiel pour les citoyens et leurs droits numériques est apparu en premier sur Souverain.

C’est à ce moment précis que la question du logiciel libre mérite d’entrer dans la discussion. Non comme un sujet réservé aux techniciens, ni comme une affaire de spécialistes, mais comme une question très concrète de souveraineté locale, de maîtrise des outils, de dépenses publiques, de continuité du service et, au fond, de liberté d’action.

Au départ, j’avais en tête une idée assez simple : je voulais écrire un guide. Un point d’appui concret pour aller voir sa mairie, ouvrir le dialogue, montrer que le passage au libre est possible, et tenter de faire bouger les lignes. L’intention était claire : partir du terrain, du concret, et voir comment un citoyen peut contribuer, à son échelle, à remettre un peu de souveraineté numérique dans la vie locale.

Puis j’ai échangé avec Nicolas Vivant, directeur de la stratégie et de la culture numériques de la Ville d’Échirolles. Je connaissais déjà sa conférence: Passer au libre, c’est changer de monde ! Mais ce n’est pas la conférence, à elle seule, qui a fait évoluer mon angle, c’est l’entretien. C’est la manière dont Nicolas m’a fait comprendre que ce sujet ne se résume ni à un catalogue d’outils, ni à une démonstration de principe, ni même à une simple volonté politique.

Je suis arrivé avec des idées bien arrêtées. J’en suis reparti avec autre chose : une vision plus solide du terrain, des résistances qu’il faut savoir décrypter, des relais qu’il faut identifier, des précautions qu’il faut prendre, et surtout une méthode plus réaliste que le guide que j’avais d’abord en tête. Autrement dit, je ne suis pas sorti de cet échange avec un mode d’emploi. Je suis sorti avec une manière différente de poser le problème.

Car faire évoluer une mairie vers davantage de logiciel libre ne relève ni d’une solution miracle, ni d’une simple volonté affichée. Cela demande du temps, de la méthode, de la confiance et une bonne compréhension du fonctionnement réel d’une commune. À Échirolles, le passage au libre a été engagé en 2021 : on parle donc d’un chantier mené sur plus de trois ans, pas d’un simple remplacement de logiciels opéré en quelques semaines. Ce temps peut impressionner. Il ne devrait pas décourager. Il indique simplement la nature du travail à mener : reconstruire des habitudes, faire monter les équipes en compétence, reprendre la main sur certaines dépendances, et redéfinir peu à peu ce que peut être un numérique public plus maîtrisé.

Et c’est aussi ce qui m’a marqué dans cet échange : le discours de Nicolas n’a rien de théorique. Il repose sur une expérience conduite dans la durée, avec ses résistances, ses arbitrages, ses lenteurs aussi. Mais il repose aussi sur une conviction forgée par le terrain :

C’est possible de le faire et ça se passe bien !

C’est donc l’objet de cet article. Non pas proposer un « guide pratique », mais partager ce que cet entretien m’a permis de mieux comprendre : comment une commune peut commencer à bouger, où se situent les blocages, quels acteurs peuvent aider, et pourquoi la question du libre, dans l’organisation concrète d’une mairie, est d’abord une affaire de confiance, de méthode et de continuité.

Pour aller plus loin, j’ai regroupé l’ensemble de ma veille : sources, retours d’expérience et ressources, dans un dossier accessible en ligne depuis Flus.

Pour ma part, je parlerai surtout depuis un point d’observation bien précis : celui d’une commune de moins de 5 000 habitants. Les moyens y sont souvent limités, les équipes resserrées, et le numérique dépend de peu d’acteurs. Le sujet peut alors sembler, à tort, hors de portée. Or c’est précisément à cette échelle que l’on mesure le mieux ce qu’un tel changement peut impliquer.

Qui est Nicolas Vivant, et pourquoi son regard compte ?

Avant d’entrer dans le vif du sujet, il faut dire d’où parle Nicolas Vivant. Ce n’est pas un détail. Nicolas a travaillé dans le privé avant de rejoindre le secteur public. Il connaît donc les deux univers : leurs logiques, leurs réflexes, leurs habitudes et leurs manières de décider. Pour ma part, j’aborde ces questions avec un regard d’abord façonné par le privé. Lui a traversé les deux mondes. Et cela change beaucoup de choses.

Autre point important : Nicolas n’est pas, à l’origine, un « libriste » au sens militant du terme. Il vient d’un environnement où, comme beaucoup de responsables informatiques, on utilise les solutions dominantes du marché, celles que tout le monde connaît, celles qui rassurent parce qu’elles sont installées partout. Lorsqu’il découvre le monde du libre et de l’open source, il ne me le raconte pas comme une conversion idéologique. Il me le raconte comme une évidence progressive, presque comme un retour au bon sens.

Et c’est précisément ce qui rend son expérience précieuse. Nicolas n’est pas un puriste, et c’est très bien ainsi. Moi non plus, je ne le suis pas. Il existe parfois, dans certains discours autour du libre, une forme de pureté qui finit par se refermer sur elle-même. Or une mairie ne fonctionne pas dans la pureté. Elle fonctionne dans le compromis, dans l’héritage, dans les contraintes, dans les urgences, dans l’humain. C’est pour cela que notre échange a été si éclairant : il ne m’a pas donné un récit idéal, il m’a donné une méthode réaliste.

Ce que cet entretien a changé dans mon regard

Au départ, j’avais en tête quelque chose d’assez simple. Je voulais écrire sur une sorte de boîte à outils pour aller voir son maire, sa mairesse ou les agents de sa commune, ouvrir le dialogue, montrer que le passage au libre est possible, et essayer de faire bouger les lignes.

En sortant de cet entretien, j’avais changé de perspective.

Non pas parce que cette ambition serait mauvaise. Mais parce qu’elle était trop simpliste au regard de la réalité. Nicolas m’a fait comprendre qu’on ne fait pas bouger une commune avec un argumentaire bien ficelé et deux ou trois démonstrations techniques. On fait bouger une commune en comprenant son fonctionnement réel, ses fragilités, ses dépendances, ses équilibres, ses peurs et les personnes qui, à l’intérieur, peuvent rendre le changement crédible.

C’est là, à mes yeux, le cœur de ce qu’il m’a transmis. Non pas une « recette » à appliquer mécaniquement, mais une manière d’aborder le sujet sans naïveté.

Il faut dire aussi que Nicolas a construit sa stratégie à partir du terrain. Il a commencé dans une commune de 22 000 habitants avec quelques 600 employés. Il a observé et compris pourquoi, dans d’autres mairies, les tentatives de passage au libre échouaient si souvent. Il en a tiré un bilan, puis ses propres conclusions. Et c’est à partir de cette expérience accumulée qu’il a construit sa stratégie. Si elle mérite l’attention, c’est justement parce qu’elle ne vient pas d’un raisonnement théorique, mais d’un travail d’introspection et d’essais au long cours.

Pas de recette toute faite, mais des fondamentaux

De notre échange, trois piliers ressortent nettement.

Le premier : se débarrasser des idées reçues.
Le deuxième : savoir être fourbe.
Le troisième : être patient, fédérer, accompagner et repérer des ambassadeurs.

Dit comme cela, le mot « fourbe » peut surprendre. Nicolas l’emploie pourtant dans un sens très particulier, et même très utile. Il ne s’agit pas d’être trompeur. Il s’agit d’être rusé, fin, stratège. L’étymologie elle-même est intéressante : les dictionnaires ne sont pas parfaitement alignés, le CNRTL reliant d’abord le mot à « fourbir », quand Littré mentionne aussi l’italien furbo. Or furbo, en italien courant, désigne d’abord quelqu’un d’astucieux, de scaltro, capable de comprendre vite une situation et d’y trouver le bon angle. C’est dans ce sens-là qu’il faut entendre Nicolas : non pas tromper, mais savoir comment faire avancer un changement, sans l’exposer trop tôt à des blocages prévisibles.

C’est sur ce point que l’entretien a le plus changé ma manière de voir les choses. J’étais encore dans une logique assez frontale : montrer, convaincre, démontrer, pousser. Nicolas, lui, m’a fait comprendre qu’une collectivité se transforme rarement de face. Elle évolue souvent par la confiance, par la preuve, par l’acculturation progressive.

Comment fonctionne réellement une mairie ?

Pour espérer faire bouger les choses, il faut d’abord comprendre comment fonctionne une mairie. Et là encore, la réalité est plus rugueuse que l’idée qu’on s’en fait.

Sans délégation, un conseiller municipal n’a pas autorité sur les agents communaux. Plus largement, même lorsqu’une équipe municipale a une volonté sincère d’aller vers davantage de souveraineté numérique, cela ne suffit pas. Celui qui sait faire, et celui qui a la main sur le système informatique, pèse souvent beaucoup plus concrètement sur la situation. Cela peut être un service informatique ou un prestataire ou dans les petites communes, un entre-deux assez fragile.

Et c’est là que le problème apparaît clairement pour les communes de moins de 5 000 habitants. Très souvent, il n’existe pas de véritable service informatique structuré, avec des équipes, du temps, des moyens et une vision d’ensemble. Souvent, l’informatique est sous-traitée à une entreprise locale dans le cadre d’un contrat. Parfois, elle repose aussi en partie sur quelques élus de bonne volonté, qui « bricolent » comme ils peuvent, sans que cela relève pleinement de leur fonction, ni qu’ils aient réellement le temps de s’en saisir sérieusement.

Autrement dit : c’est souvent bancal.

Et cette fragilité doit être regardée en face. Non pour accabler les petites communes, mais pour comprendre à partir de quoi il faut travailler.

Au fil de nos échanges, un autre point m’a marqué, presque surpris par son ampleur. En réalité, je le connaissais déjà, mais sans mesurer à quel point il est répandu, ni à quel point il est pratiqué sans véritable conscience des enjeux. Dans de nombreuses communes, il est devenu courant d’utiliser des outils comme Google Forms pour collecter des informations ou organiser des sondages. L’intention est souvent louable : aller vite, toucher facilement les habitants, simplifier la logistique, obtenir des réponses exploitables sans effort. Mais derrière cette apparente simplicité, il y a un angle mort.

Car ces usages ne sont pas neutres. Ils reposent sur des services commerciaux, extérieurs, dont la maîtrise échappe largement à la collectivité. Et surtout, ils installent une norme implicite : si la mairie utilise ces outils, alors leur usage semble aller de soi. Pour les citoyens, le message est simple et puissant : c’est acceptable, donc c’est sans conséquence.

C’est là que la question dépasse la seule technique. Elle touche à une forme d’exemplarité publique. Lorsqu’une collectivité adopte ce type d’outils sans en mesurer les implications, elle ne se contente pas de gérer un service : elle participe, sans toujours le vouloir, à normaliser des pratiques qui interrogent pourtant directement la souveraineté numérique et la maîtrise des données.

Et c’est sans doute l’un des angles morts les plus frappants : ces pratiques sont répandues, rarement accompagnées, et encore moins encadrées. On pourrait s’attendre à ce qu’il existe des repères plus clairs, des formations systématiques, des outils recommandés, voire à des obligations sur certains usages, notamment au regard du RGPD. Or, dans bien des cas, les agents comme les élus avancent seuls, sans toujours mesurer les risques, ni connaître les alternatives pourtant disponibles.

Avant tout : comprendre qui a la main

La première chose à faire, m’explique Nicolas, c’est donc d’identifier le fonctionnement réel du numérique dans votre mairie.

Qui gère ?
Un élu ?
Le secrétaire de mairie ?
Le DGS ?
Un prestataire local ?
Une structure intercommunale ?

Tant que cette question n’est pas éclaircie, le reste demeure abstrait.

Ensuite seulement, il devient possible d’adapter la stratégie. Si l’informatique est suivie de près par un élu réceptif, il faut lui montrer qu’il existe des solutions concrètes, utiles, accessibles, qui peuvent être mises en place sans budget démesuré, ni lourdeur excessive. Si, au contraire, tout passe par un prestataire, alors il faudra aussi comprendre sa logique, ses intérêts, ses limites et sa capacité, ou non, à accompagner un mouvement vers davantage de solutions libres.

C’est là que le sujet cesse d’être purement technique pour devenir presque politique au sens local du terme : il faut comprendre les rapports de force, les dépendances et les habitudes.

Partir du concret, pas du discours

L’autre leçon forte de notre entretien, c’est qu’il faut partir du concret. Pas d’un grand discours sur le libre. Pas d’une profession de foi. Du concret.

Dans le cas d’un élu ouvert au sujet, cela veut dire montrer ce qu’on peut améliorer rapidement et utilement. Par exemple : filmer et diffuser un conseil municipal, mettre en place un écran d’information libre, proposer un meilleur système de fichiers, remplacer une solution de visioconférence payante par un outil plus sobre et souverain, améliorer la gestion du réseau local, faciliter l’accès à distance à certains postes, ou encore faire comprendre qu’une partie des dépenses actuelles peut être repensée.

Le point important, ici, n’est pas simplement d’aligner des outils. C’est de rendre visible une promesse de fonctionnement plus simple, plus sobre, plus durable et parfois moins coûteuse.

Dans cette logique, la démonstration compte énormément. Nicolas m’a conforté dans l’idée qu’il faut savoir montrer concrètement comment cela fonctionne. Faire une démo sur une machine virtuelle par exemple. Montrer une interface familière. Écrire un document en direct depuis Docs. Faire toucher du doigt, très concrètement, et rassurer en démontrant que l’on n’est pas en train de proposer un saut dans l’inconnu.

Et c’est là que la notion de « fourberie » prend tout son sens.

Sans confiance, pas de changement

Le vieux réflexe, dans beaucoup d’organisations, consiste encore à penser qu’une solution propriétaire connue serait forcément plus sérieuse, plus professionnelle, plus éprouvée. Nicolas me l’a dit très clairement : ce réflexe continue d’exister. Il ne sert à rien de le mépriser. Il faut le comprendre.

Dès lors, toute la stratégie consiste à construire de la confiance.

Cela demande d’écouter les agents, de comprendre leurs inquiétudes, leurs habitudes, leurs résistances, leurs demandes. Cela demande aussi d’identifier des personnes volontaires, des profils plus ouverts, des testeurs, des relais possibles. Car à la fin, le sujet n’est pas seulement technique. Il touche à des routines, à des gestes quotidiens, à des repères de travail. Et dès que l’on touche à cela, on touche à quelque chose de profondément humain.

Le changement fait rarement peur pour des raisons purement rationnelles. Il inquiète surtout parce qu’il modifie des habitudes de travail ancrées.

C’est pourquoi Nicolas insiste tant sur l’expérience utilisateur. Si les outils libres choisis sont fluides, rassurants, bien accompagnés, alors ils cessent d’être perçus comme une contrainte. Ils deviennent des solutions crédibles. Et c’est à ce moment-là que le libre commence réellement à gagner du terrain.

Un écosystème pour accompagner le mouvement

C’est peut-être l’un des points les plus importants de tout cet entretien : non, une petite commune n’est pas condamnée à improviser seule dans son coin. Il n’existe pas de guide universel, de parcours administratif parfait ou de méthode prête à l’emploi. En revanche, il existe aujourd’hui un véritable écosystème d’appui, de mutualisation et de ressources qui peut éviter à une mairie de repartir de zéro.

Premier repère utile : France Numérique Libre. Le collectif se présente lui-même comme le réseau des responsables informatiques des collectivités territoriales autour des logiciels libres. C’est un site où circulent des retours d’expérience, des méthodes, des références concrètes et des ressources pensées pour les collectivités. Sur sa page ressources, on retrouve par exemple le Comptoir du Libre de l’ADULLACT, qui recense des logiciels libres utiles aux services publics, leurs utilisateurs et leurs prestataires. Pour une commune ou pour un élu qui cherche à sortir du tête-à-tête avec un fournisseur habituel, c’est déjà une porte d’entrée très utile : on n’est plus dans l’idée abstraite, on entre dans un paysage d’outils, de cas d’usage et de partenaires identifiables.

Deuxième repère : la Suite numérique de l’État, portée par la DINUM. Elle rassemble des outils cohérents, sécurisés et interopérables pour le travail public. Docs est présenté comme l’outil d’écriture collaborative de l’État ; Fichiers comme une solution souveraine de stockage et de partage de documents, ouverte et hébergée en France ; Visio comme une solution de visioconférence simple, performante et souveraine, avec code ouvert et auditable. Des webinaires d’information sont proposés directement sur les pages de ces solutions, et la plateforme permet aussi de réserver un échange avec les équipes pour examiner l’architecture, la sécurité et les conditions de déploiement.

Il faut toutefois préciser un point important pour éviter toute confusion : l’offre interministérielle standard de La Suite est d’abord pensée pour les agents de l’État et leurs collaborateurs invités. Pour une commune, la porte d’entrée la plus pertinente est souvent la Suite territoriale, développée par l’ANCT avec la DINUM et en lien avec les OPSN. Cette offre vise les communes de moins de 3 500 habitants et les EPCI de moins de 15 000 habitants, elle réutilise et adapte certaines briques de la Suite numérique pour les territoires. On y retrouve notamment des services comme Messagerie pour le courriel professionnel sécurisé et Fichiers pour le stockage et le partage de documents. Là encore, une commune peut poser ses questions directement aux équipes de La Suite territoriale et suivre les évolutions du service via leur infolettre.

À cela s’ajoute la formation : La DINUM propose sur Mentor un parcours intitulé S’approprier les usages numériques et les produits collaboratifs de la Suite Numérique. Le parcours est en accès permanent, 100 % à distance et en autonomie. Il est structuré en deux volets : des modules organisés par « moments de vie au travail », donc par usages concrets, et des modules produits pour apprendre à maîtriser les outils eux-mêmes. Pour des agents ou des élus qui ont besoin de se familiariser avec ces briques sans entrer immédiatement dans une logique de migration lourde, c’est une ressource particulièrement intéressante.

J’ai également sollicité Open Source Experts, dont je connais le sérieux dans l’écosystème open source. Parmi les acteurs qu’ils m’ont signalés figure Atol CD, qui travaille étroitement avec les collectivités territoriales et a notamment développé plusieurs communs numériques.

Enfin, il existe aussi des structures publiques de mutualisation. Le SITPI, dans la région grenobloise, en est un bon exemple. Cet opérateur public de services numériques, organisé en syndicat intercommunal, accompagne ses collectivités membres sur l’exploitation, l’assistance, la sécurisation des systèmes d’information et même l’assistance à maîtrise d’ouvrage. Le SITPI n’est évidemment pas un modèle national exportable partout à l’identique, mais il montre quelque chose de décisif : entre la solitude d’une petite commune et la dépendance à un prestataire unique, il existe des formes intermédiaires, publiques, mutualisées, capables de porter une stratégie numérique plus autonome.

C’est sans doute la bonne manière de poser le sujet. Vous n’avez pas entre les mains un mode d’emploi universel. Vous avez mieux que cela : un chemin déjà balisé par d’autres, des outils déjà disponibles, des formations, des réseaux, des opérateurs publics, des collectivités qui essuient les plâtres et qui documentent ce qui fonctionne. Le vrai enjeu n’est donc pas de tout savoir d’avance. Il est d’identifier les bons appuis, d’ouvrir le dialogue et d’entrer dans une dynamique de confiance.

Conclusion : avancer sans brusquer les équilibres

Notre échange s’est achevé sur une apparente digression : le choix d’une distribution Linux. En réalité, ce n’en était pas une. Car là encore, Nicolas revenait à la même idée : un bon choix technique est aussi un choix psychologique.

Prenons l’exemple de Zorin OS. Ce qui intéresse Nicolas dans cette distribution, ce n’est pas seulement sa légèreté ou ses qualités techniques. C’est sa capacité à rassurer. Le projet lui-même se présente comme une alternative à Windows et macOS pensée pour être familière, avec une interface que l’on sait utiliser presque immédiatement et dont l’apparence peut rappeler l’environnement auquel l’utilisateur est déjà habitué. Dans une mairie, cette continuité compte énormément : il y a bien un changement, mais il ne vient pas brusquer les habitudes de l’utilisateur. Et cela, dans une stratégie de confiance, c’est capital !

Mais cette réflexion va, au fond, plus loin que le seul cas des collectivités. J’ai repensé à mes enfants. J’avais installé sur une machine un environnement qui me paraissait cohérent, léger, adapté. Nicolas m’a fait voir autre chose : on n’éduque pas seulement à des fonctionnalités, on éduque aussi à des gestes, à des interfaces, à des réflexes, à une manière d’entrer dans le numérique. Or les enfants apprennent aussi par mimétisme.
La littérature sur l’imitation rappelle qu’ils imitent très tôt les gestes et actions des adultes autour d’eux, et qu’ils reproduisent aussi ce qui les rapproche des personnes auxquelles ils veulent ressembler.

C’est là que le sujet devient, à mes yeux, presque culturel. Si l’on donne aux enfants un environnement numérique « à part », avec des codes que les adultes n’utilisent jamais et une interface qui semble cantonnée au monde des enfants ou des machines bricolées, on risque d’inscrire dans leur esprit l’idée que le libre relève d’un univers distinct, en marge des usages ordinaires de l’informatique. À l’inverse, si l’on choisit un environnement libre qui reste familier, lisible et proche des usages ordinaires, on cesse d’infantiliser le rapport à l’ordinateur. On construit une continuité. L’enfant n’a pas le sentiment d’utiliser un environnement numérique à part, il se familiarise avec les mêmes usages que les adultes, mais sur d’autres bases.

C’est peut-être là, finalement, l’une des idées les plus fines que je retiens de cet échange avec Nicolas. Le libre ne gagne pas seulement lorsqu’il est plus sobre, plus ouvert ou moins coûteux. Il gagne aussi lorsqu’il cesse d’apparaître comme un univers à part. Lorsqu’il devient une évidence d’usage. Lorsqu’il transmet, sans brutalité ni folklore, une autre manière d’entrer dans le numérique. C’est aussi ainsi, je pense, que se prépare, très concrètement, la souveraineté numérique des générations qui viennent.

Au fond, ce que Nicolas m’a appris tient en peu de mots : pour faire bouger une mairie, il ne suffit pas d’avoir raison. Il faut savoir convaincre, démontrer, rassurer et durer.

Et c’est précisément ce qui rend ce chemin exigeant et possible.

L’article Souveraineté numérique : comment convaincre sa mairie de passer au libre ? est apparu en premier sur Souverain.

Numérique : l’UE ne peut s’émanciper sans sacrifier l’expérience utilisateur selon Google
Faudra t-il faire un choix entre la souveraineté numérique de l'Europe et la qualité des produits proposés aux consommateurs ? https://t.co/kDd19rci24 pic.twitter.com/4HxAa5dMQn

— fabienne billat (@fadouce) March 21, 2026

Il ne s’agit pas ici de crier à la manipulation à chaque prise de parole, ni de prétendre que tout argument défendant l’ouverture des marchés serait illégitime. Les jeux d’influence existent dans toute bataille économique, industrielle et réglementaire. Ils sont même, jusqu’à un certain point, dans l’ordre normal du débat. Des entreprises défendent leurs intérêts. Des États défendent leur puissance. Des think tanks défendent des visions du monde. Rien de tout cela n’a, en soi, quelque chose de scandaleux. Ce qui mérite en revanche notre attention, c’est la manière dont ces intérêts se traduisent dans le langage, dans l’imagerie mentale, dans les peurs mobilisées et dans les évidences qu’on cherche à installer.

Car l’enjeu n’est pas seulement technique. Il est aussi sémantique. Avant de gagner une décision publique, il faut souvent gagner la bataille des mots du débat. Il faut imposer un cadre. Faire passer une dépendance pour une coopération naturelle. Présenter une vulnérabilité comme le prix inévitable de la modernité. Faire glisser l’idée de souveraineté vers celle de fermeture, de retard ou d’inconfort. En face, celui qui veut simplement comprendre ce qui se joue peut vite se retrouver désarmé, non par défaut de discernement, mais parce qu’il lui manque parfois les concepts pour nommer ce qu’il observe.

C’est précisément pour cela qu’il est utile de ralentir un instant. Non pour distribuer des bons et des mauvais points. Non pour sombrer dans le soupçon permanent. Mais pour se donner quelques instruments intellectuels simples. Savoir reconnaître un cadrage. Distinguer un argument d’une stratégie de communication. Identifier le moment où l’on ne cherche plus seulement à convaincre, mais à rendre psychologiquement impensable toute alternative. Car lorsqu’un discours laisse entendre, explicitement ou non, que nous serions incapables de bâtir sans eux, d’innover sans eux, ou même simplement de maintenir nos usages sans leur bienveillance, il ne parle plus seulement d’économie : il touche à notre confiance collective.

C’est là que deux notions deviennent particulièrement utiles : le sharp power et la souveraineté cognitive.

Le sharp power, c’est une forme d’influence politique qui ne cherche pas vraiment à convaincre honnêtement, mais à brouiller les esprits, manipuler le débat public ou affaiblir la confiance dans une société.

En clair :
Ce n’est pas de la propagande classique qui dit ouvertement regardez comme nous sommes formidables.
C’est plus subtil et plus agressif.

Par exemple :
Un État, un groupe ou un réseau peut diffuser de fausses informations, amplifier des polémiques sur les réseaux sociaux, financer discrètement certains relais d’opinion, ou pousser des récits destinés à diviser la population.

Le but n’est pas forcément de vous faire adhérer à une idée précise.
L’objectif peut être simplement que vous ne sachiez plus quoi croire, que vous vous méfiiez de tout, et que la société devienne plus fragile.

On peut le résumer ainsi :
le soft power attire, le sharp power perturbe.

• Soft power : on vous séduit par la culture, les idées, l’image.
• Sharp power : on cherche à vous influencer par la désinformation, la confusion, la pression psychologique ou informationnelle.

La souveraineté cognitive, c’est la capacité d’un peuple, d’un pays ou d’un individu à penser librement, comprendre le réel par lui-même, et ne pas se faire dicter sa vision du monde par des puissances extérieures ou par des systèmes de manipulation.

Dit autrement :
c’est le fait de garder la maîtrise de son jugement.

Pour un citoyen, cela veut dire :

• pouvoir s’informer correctement
• comparer les sources
• ne pas être enfermé dans des récits fabriqués
• ne pas laisser des plateformes, des algorithmes ou des propagandes décider à sa place de ce qu’il pense important, vrai ou normal.

La souveraineté cognitive ne consiste pas à « penser tous pareil ».
Au contraire.
Elle consiste à faire en sorte que les désaccords démocratiques reposent sur un minimum de réalité partagée, et non sur une manipulation permanente.

Le lien entre les deux est simple :

• le sharp power est une arme d’influence
• la souveraineté cognitive est une forme de défense.

L’un cherche à pénétrer votre esprit collectif.
L’autre cherche à protéger votre capacité de jugement.

Par exemple :
Imaginez qu’en période électorale, des milliers de comptes sur les réseaux sociaux diffusent :

• des rumeurs
• des vidéos sorties de leur contexte
• de faux scandales
• des messages destinés à opposer les gens entre eux

Même si tout le monde ne croit pas à ces contenus, le résultat peut être :

• plus de confusion
• plus de colère
• moins de confiance dans les institutions
• moins de confiance dans les médias
• moins de confiance entre citoyens

Ça, c’est une logique de sharp power.

Face à cela, la souveraineté cognitive, ce serait :

• une population mieux formée à l’esprit critique
• des médias solides
• des outils numériques transparents
• une capacité à produire, vérifier et diffuser une information fiable
• des citoyens qui gardent leur autonomie de jugement.

Pour résumer :

• Sharp power : influence hostile qui cherche à manipuler, diviser ou désorienter une société.
• Souveraineté cognitive : capacité d’un peuple à conserver sa liberté de penser et son autonomie de jugement.

Pourquoi c’est important aujourd’hui ?

Parce qu’aujourd’hui, le pouvoir ne passe pas seulement par les armes, l’économie ou le territoire. Il est utile de connaître certains automatismes cognitifs, ces mécanismes rapides par lesquels nous trions, interprétons et jugeons une information sans toujours prendre le temps d’un examen approfondi

Celui qui influence ce que vous voyez, ce que vous croyez, ce que vous craignez et ce que vous jugez important détient déjà une part du pouvoir.

J’essaierai, aussi longtemps que je le pourrai et chaque fois que cela me semblera utile, de rendre ces notions plus accessibles, afin d’éclairer le lecteur et de lui offrir des instruments de compréhension face à des concepts qui structurent pourtant déjà une part du débat public.

Enfin, comme à ma nouvelle habitude, je mets également à disposition, gratuitement via Flus, l’ensemble de la documentation que j’ai collectée pour la rédaction de cet article.

Vos questions, vos contradictions et vos apports d’information sont les bienvenus, si ce texte peut aussi servir de point de départ à un échange utile.

L’article La souveraineté numérique se joue aussi dans la bataille sémantique est apparu en premier sur Souverain.

« En ne contrôlant pas nos infrastructures numériques critiques, nous avons abandonné une partie de notre avenir économique et de notre capacité à faire respecter nos lois et nos valeurs » Titre d’origine de l’article HiPEAC

Ce qui m’a frappé, ce n’est pas seulement le contenu de cette analyse. C’est aussi le fait qu’elle reste largement cantonnée à des cercles spécialisés. Le sujet est bien discuté par des professionnels, des experts du numérique et des acteurs déjà sensibilisés à ces enjeux. Mais il peine encore à être porté clairement jusqu’au grand public, dans les médias généralistes et dans le débat public au sens large. Comme si cette question devait rester enfermée entre spécialistes du cloud, de l’industrie, du droit ou des infrastructures. Comme si le citoyen ordinaire n’avait pas besoin de comprendre ce qui se joue.

J’ai donc décidé modestement, de m’en saisir. Pas pour produire une traduction mot à mot, sans relief et sans souffle. Parce que ce sujet mérite mieux qu’un jargon technique réservé à quelques initiés. Il mérite d’être porté dans le débat public.

Car derrière les mots un peu froids de souveraineté numérique, il y a une réalité très concrète : qui contrôle les outils dont nous dépendons tous les jours ? Qui héberge nos données ? Qui impose ses règles ? Qui capte la valeur ? Et que reste-t-il de notre autonomie politique, économique et démocratique lorsque les infrastructures essentielles du monde numérique échappent peu à peu à notre contrôle ?

Ce débat ne devrait appartenir à aucun camp. Il relève de l’intérêt général. Il concerne nos institutions, nos entreprises, nos services publics, mais aussi chacun d’entre nous. Et c’est précisément pour cela qu’il faut le rendre compréhensible, accessible et impossible à ignorer.

Si ce texte peut contribuer, même modestement, à faire sortir cette question de la marge, alors il aura déjà servi à quelque chose.

Pourquoi le contrôle du numérique est devenu vital pour l’Europe

L’Europe commence à prendre conscience d’un problème majeur : elle dépend beaucoup trop de technologies venues d’ailleurs, surtout des États-Unis, pour faire tourner son numérique.

Cela concerne des choses très concrètes : le cloud, les logiciels, les centres de données, les outils d’intelligence artificielle, les réseaux, les services sur lesquels reposent les entreprises et les administrations.

Le projet EuroStack, lancé en 2024, veut répondre à ce problème. Il est porté par des acteurs européens de la tech, qui défendent une idée simple : si l’Europe ne maîtrise pas ses outils numériques de base, elle perd peu à peu la main sur son économie, sa sécurité et même sa capacité à appliquer ses propres règles.

Pourquoi c’est un problème ?

1. Parce que cela coûte très cher à l’Europe

Aujourd’hui, beaucoup d’entreprises européennes utilisent des services numériques américains : cloud, logiciels, plateformes, outils professionnels, etc.

Conséquence : une grande partie de l’argent dépensé en Europe repart vers l’étranger.
Selon les personnes interrogées dans l’article, cette dépendance représenterait environ 265 milliards d’euros par an au bénéfice de l’économie américaine.

Dit autrement : l’Europe paie, mais ce sont d’autres qui encaissent, grandissent, innovent et créent les emplois.

L’idée défendue ici est donc la suivante : en laissant d’autres pays fournir nos briques numériques essentielles, nous affaiblissons notre propre économie.

2. Parce que cela rend l’Europe vulnérable

Pendant longtemps, cette dépendance a surtout été vue comme un sujet commercial.
Aujourd’hui, elle est aussi vue comme un risque stratégique.

Pourquoi ?
Parce que si vos outils essentiels dépendent d’acteurs étrangers, vous êtes plus fragile en cas de crise politique, économique ou géopolitique.

En clair :
Si demain les relations se tendent, ou si des décisions sont prises à l’étranger, l’Europe peut se retrouver dépendante de technologies qu’elle ne contrôle pas vraiment.

3. Parce que cela pose un problème juridique et de sécurité

L’article insiste sur un point sensible : certaines lois américaines, comme le CLOUD Act ou FISA, peuvent permettre aux autorités américaines d’exiger l’accès à certaines données détenues par des entreprises relevant de leur juridiction.

Même si les données concernent des Européens.

L’argument défendu ici est donc simple :
si vos données, vos outils ou vos services dépendent d’acteurs soumis à des lois étrangères, votre souveraineté est affaiblie.

Qu’est-ce que la « souveraineté numérique » ?

Dans l’article, la souveraineté numérique signifie la capacité, pour les citoyens, les entreprises et les États européens, de :

• Choisir leurs outils numériques librement
• Contrôler leurs données
• Gérer leurs infrastructures
• Ne pas subir des décisions prises ailleurs.

Autrement dit, c’est la capacité de rester maître chez soi dans le monde numérique.

Ce n’est pas seulement une question de stockage de données. C’est aussi une question de pouvoir réel :

Qui contrôle les logiciels, les serveurs, les mises à jour, fixe les règles, qui peut couper, bloquer ou imposer ses conditions ?

Le constat de fond : l’Europe a laissé filer le contrôle

L’une des idées fortes de l’article est la suivante :

Pendant que l’Europe passait beaucoup de temps à réguler les géants du numérique, ces acteurs ont continué à construire les infrastructures, les centres de données, les plateformes et les écosystèmes dont tout le monde dépend aujourd’hui.

En résumé :
l’Europe a essayé d’encadrer le numérique sans suffisamment bâtir le sien.

EuroStack, c’est quoi exactement ?

EuroStack est une initiative européenne qui veut transformer cette prise de conscience en action concrète.

Son objectif n’est pas seulement de dénoncer la dépendance, mais de définir des critères précis pour savoir ce qu’est un vrai acteur numérique européen souverain.

Car selon ses promoteurs, beaucoup d’entreprises font du marketing autour de la souveraineté sans être réellement indépendantes.
Ils appellent cela du « sovereignty washing » : faire croire qu’on est souverain alors qu’on dépend encore de structures, de lois ou de technologies étrangères.

Les 5 critères d’un fournisseur numérique européen « souverain »

EuroStack propose cinq grands critères.

1. Souveraineté juridique

L’entreprise doit être réellement basée en Europe, soumise au droit européen, et ne pas être contrôlée de façon décisive par un acteur non européen.

En clair : pas seulement une vitrine européenne, mais un vrai contrôle européen.

2. Souveraineté technique

Le service doit éviter d’enfermer le client dans une technologie propriétaire étrangère.
Cela passe notamment par :

• L’open source
• Les standards ouverts
• La possibilité de récupérer ses données
• La possibilité de changer de fournisseur

En clair : vos données ne doivent pas être prisonnières d’un système fermé.

3. Souveraineté opérationnelle

Il ne suffit pas que les données soient stockées en Europe. Il faut aussi que l’exploitation du service soit pilotée depuis l’Europe.

Cela comprend :

• Les infrastructures
• Les systèmes de gestion
• Les personnes ayant les accès sensibles

En clair : le service doit être réellement opéré depuis l’Europe, pas seulement hébergé sur son sol.

4. Souveraineté des données

Toutes les données, y compris les métadonnées et les sauvegardes, doivent rester en Europe et être protégées de manière vérifiable. L’idée est que personne ne puisse y accéder sans autorisation, pas même le fournisseur si les données sont correctement chiffrées.

En clair : la protection des données doit être réelle, pas seulement déclarative.

5. Souveraineté économique

L’argent public européen doit aider à développer l’industrie européenne, pas à renforcer celle d’autres puissances.

Cela veut dire que l’entreprise doit investir en Europe et en :

• Recherche
• Développement
• Emplois
• Innovation

En clair : si l’Europe paie, il faut que l’Europe en profite aussi.

Que propose concrètement EuroStack ?

EuroStack résume son plan en trois idées :

1. « Buy European » : acheter européen

L’idée est que les administrations et institutions publiques européennes réservent une part significative de leurs achats informatiques à des solutions européennes jugées souveraines.

Le raisonnement est simple : si les acteurs européens n’ont pas de clients : ils ne peuvent pas grandir, donc ils ne peuvent pas rivaliser avec les géants étrangers.

Les auteurs disent que ce n’est pas du protectionnisme « bête et méchant », mais une manière de faire émerger une base industrielle solide.

Ils estiment aussi qu’une partie importante de la commande publique part aujourd’hui vers des fournisseurs américains.
Réserver une partie de cette dépense à des acteurs européens donnerait un vrai coup d’accélérateur.

Ils ajoutent un point important : il faut aussi simplifier les marchés publics, car aujourd’hui ils sont souvent trop lourds pour les PME européennes.

2. « Sell European » : mieux organiser l’offre européenne

Le constat est assez lucide :
les géants américains ne gagnent pas seulement parce qu’ils sont grands, mais parce qu’ils proposent des offres simples, intégrées et faciles à acheter.

En face, l’Europe a souvent de bonnes briques techniques, de bonnes PME, de bons ingénieurs, mais une offre fragmentée.

En clair : l’Europe a les pièces, mais pas toujours le produit complet.

EuroStack dit clairement aux acteurs européens :

• Coopérez
• Assemblez vos solutions
• Créez des offres complètes
• Rendez-les lisibles pour les clients

L’objectif est que l’acheteur n’ait pas à faire lui-même le puzzle.

3. « Fund European » : financer européen

Troisième priorité : l’argent.

Selon l’article, l’Europe doit arrêter de subventionner indirectement des technologies non européennes quand elle veut renforcer sa propre souveraineté.

L’idée est donc de :

• Rediriger les financements
• Soutenir les projets stratégiques
• Aider les entreprises européennes à changer d’échelle
• Financer les briques open source essentielles

Les domaines jugés prioritaires sont notamment :

• Le cloud souverain
• L’edge computing
• l’IA de confiance
• La cybersécurité
• Les composants open source de base

Pourquoi l’open source est-il présenté comme central ?

L’article insiste beaucoup sur ce point.

L’open source est vu comme un outil clé pour la souveraineté numérique, parce qu’il permet :

• d’auditer le code
• de réduire la dépendance à un fournisseur unique
• de mieux coopérer
• de reprendre la main sur les technologies

L’idée est la suivante : si vous utilisez un logiciel fermé contrôlé par un acteur extérieur, vous dépendez de ses choix. Si vous utilisez des briques ouvertes, vous avez davantage de liberté pour comprendre, adapter, maintenir ou remplacer la solution.

Mais l’article dit aussi que l’open source, à lui seul, ne suffit pas. L’Europe doit encore progresser sur plusieurs points :

• Les standards communs
• L’interopérabilité
• Le financement durable
• La visibilité des solutions européennes
• La formation
• L’influence européenne dans la gouvernance des grands projets open source

Et maintenant, que veut faire EuroStack ?

Dans les prochains mois, EuroStack veut :

• Structurer son fonctionnement
• Élargir son réseau d’entreprises
• Travailler sur l’intégration des offres
• Aider à construire des cadres d’achat plus fiables
• Rapprocher les fournisseurs et les clients.

En clair : passer du discours à l’exécution.

Le rôle de HiPEAC dans tout ça

HiPEAC représente une communauté de recherche et d’innovation dans le domaine des systèmes informatiques.

L’article explique que HiPEAC pourrait aider sur trois plans :

• Contribuer à une vraie pile technologique européenne, du matériel jusqu’au logiciel
• Aider à repérer les dépendances critiques
• Former des ingénieurs et chercheurs capables de penser la souveraineté numérique de bout en bout

A mon avis, la conclusion à retenir

l’Europe a trop laissé d’autres acteurs contrôler ses infrastructures numériques essentielles. Et en faisant cela, elle a aussi laissé partir une partie de sa puissance économique, de sa capacité d’innovation, de sa sécurité et de son pouvoir politique

Mais les auteurs insistent aussi sur un point essentiel : il ne s’agit pas de fermer l’Europe au reste du monde, ni d’écarter par principe les entreprises américaines. L’enjeu, selon eux, est surtout de mettre fin à une dépendance excessive qui empêche l’Europe de garder la main sur ses infrastructures numériques les plus stratégiques.

Autrement dit : le but n’est pas l’autarcie, mais de ne plus être dépendant au point de subir.

Si l’Europe continue à utiliser massivement des technologies qu’elle ne contrôle pas, elle risque de ne plus vraiment maîtriser son économie, ses données, ses règles et son avenir numérique.

L’article L’Europe face à sa dépendance numérique : un enjeu de souveraineté est apparu en premier sur Souverain.

Qu’est-ce que la nouvelle loi européenne sur la cybersécurité change pour les logiciels, les entreprises du numérique, l’open source et le lien avec la souveraineté numérique ?

Le CRA est entré en vigueur le 10 décembre 2024, mais son application se fait par étapes. Les principales obligations s’appliqueront à partir du 11 décembre 2027. Certaines obligations de signalement, elles, entreront en vigueur plus tôt, dès le 11 septembre 2026. La Commission précise aussi qu’une autre étape intermédiaire est prévue au 11 juin 2026 pour les dispositions relatives aux organismes d’évaluation de conformité.

Le texte s’applique aux « produits avec éléments numériques« . Cette formule peut sembler floue, mais elle désigne en réalité les produits matériels et logiciels qui ont une fonction numérique et une connexion directe ou indirecte à un appareil ou à un réseau. Cela inclut donc non seulement les objets connectés les plus visibles, mais aussi des logiciels, des applications, des systèmes d’exploitation, des puces, des composants ou encore des briques techniques vendues séparément. Autrement dit, le CRA ne vise pas seulement les produits finis, il peut aussi concerner des composants mis sur le marché à part.

L’un des points les plus importants du texte : l’open source non commercial est, en principe, hors du champ. Ce n’est pas le simple fait de publier du code libre sur Internet qui déclenche les obligations du règlement. Ce qui compte, c’est la mise à disposition sur le marché dans le cadre d’une activité commerciale, y compris lorsqu’un produit est distribué gratuitement mais dans un contexte économique organisé. La frontière juridique n’est donc pas « open source ou non », mais bien « activité commerciale ou non ».

Concrètement, cela signifie qu’un développeur qui publie un projet open source ne devient pas automatiquement responsable de tous les usages futurs de son code. En revanche, si une entreprise reprend ce code, l’intègre à un produit et le commercialise sous son nom, c’est elle qui porte la responsabilité de la conformité. Ce point est essentiel, parce qu’il évite de faire peser d’emblée sur les contributeurs bénévoles et les petits projets communautaires le même poids réglementaire que sur un acteur qui vend effectivement un produit sur le marché européen.

Qui est concerné dans la chaîne d’approvisionnement ?

Le CRA distingue plusieurs acteurs. Le fabricant est celui qui développe ou fait développer un produit et le commercialise sous son nom ou sa marque. L’importateur est l’acteur établi dans l’Union qui met sur le marché européen un produit provenant d’un fabricant situé hors de l’UE. Le distributeur, lui, met le produit à disposition sans en modifier les caractéristiques. Enfin, le texte introduit une catégorie particulière : l’open-source software steward.

Ce steward open source mérite d’être expliqué simplement. Il ne s’agit pas d’un développeur isolé, mais d’une personne morale, par exemple une fondation, une association structurée ou une entreprise, qui soutient de manière durable le développement d’un logiciel libre destiné à des usages commerciaux et qui en assure la viabilité. Le règlement lui reconnaît donc un rôle particulier dans l’écosystème open source, sans le traiter exactement comme un fabricant. À mes yeux, ce concept reste encore flou et sujet à interprétation.

Cette distinction est importante parce que le CRA essaie justement de ne pas appliquer la même logique à un bénévole et à une structure qui joue un rôle organisé dans l’économie du logiciel. Les stewards open source doivent bien mettre en place une politique de cybersécurité, coopérer avec les autorités et, dans certains cas, signaler des vulnérabilités ou des incidents. En revanche, la Commission précise qu’ils ne sont pas soumis aux mêmes sanctions administratives que les fabricants.

Ce que le CRA impose réellement aux fabricants

Pour les fabricants, le règlement change profondément la donne. Il ne suffit plus de mettre un produit sur le marché puis de passer à autre chose. Le fabricant doit procéder à une évaluation des risques, concevoir son produit selon des exigences minimales de cybersécurité, documenter ses choix techniques, fournir des informations claires à l’utilisateur, organiser le traitement des vulnérabilités et démontrer la conformité du produit avant sa mise sur le marché. À l’issue de cette procédure, il doit établir une déclaration UE de conformité et, lorsque les conditions sont réunies, apposer le marquage CE.

Le CRA introduit aussi une logique de cycle de vie. La sécurité n’est plus pensée uniquement au lancement du produit : le fabricant doit prévoir une période de support pendant laquelle les vulnérabilités seront traitées. La Commission précise même que la date de fin de support, au moins le mois et l’année, doit être indiquée de manière claire et compréhensible au moment de l’achat. Pour le grand public, c’est un changement important : cela revient à rendre visible une question trop souvent laissée dans le flou, à savoir combien de temps un produit restera réellement maintenu.

Autre point central : le signalement des vulnérabilités et des incidents. Les fabricants devront notifier les vulnérabilités activement exploitées ainsi que les incidents graves affectant la sécurité de leurs produits. La Commission indique un calendrier précis : une alerte précoce sous 24 heures, une notification principale sous 72 heures, puis un rapport final dans les délais prévus selon qu’il s’agit d’une vulnérabilité exploitée ou d’un incident sévère. Ces obligations commenceront à s’appliquer à partir du 11 septembre 2026.

Ce que le texte change pour l’open source

Pour le monde de l’open source, le CRA peut produire un premier effet positif : il clarifie enfin la question de la responsabilité. Publier du code libre n’équivaut pas, en soi, à mettre un produit sur le marché. En revanche, une entreprise qui s’appuie sur ce code pour construire une offre commerciale ne peut plus se retrancher derrière le simple caractère « ouvert » du logiciel pour esquiver ses obligations. Le texte pousse donc vers une responsabilisation plus nette des acteurs économiques qui tirent parti de l’open source.

C’est là qu’apparaît le problème du contournement : des acteurs peuvent récupérer des briques open source, les intégrer à une offre commerciale, en tirer de la valeur, sans contribuer sérieusement à la sécurité ni assumer clairement la maintenance. Avec le CRA, cette position devient plus difficile à tenir, car celui qui met le produit sur le marché doit démontrer sa conformité, gérer les vulnérabilités et répondre aux autorités. En pratique, profiter du libre sans prendre ses responsabilités devient donc moins soutenable.

Le texte peut aussi renforcer la crédibilité de certaines offres open source auprès des clients publics et privés. Lorsqu’un produit libre est porté par un acteur identifié, capable d’assumer le support, la documentation, la conformité et la gestion des incidents, il devient plus lisible pour des acheteurs qui ont besoin d’un interlocuteur responsable. Le CRA peut donc, dans certains cas, jouer en faveur d’un open source plus structuré.

Mais il existe aussi un risque réel : la charge de conformité. Le règlement suppose des compétences en sécurité, en documentation, en gouvernance produit et en suivi réglementaire. La Commission elle-même a publié des mesures de soutien pour les petites entreprises et un projet de guide destiné à faciliter l’application du CRA, en particulier pour les microentreprises (MIC) et les PME, ce qui montre bien que la mise en conformité peut être lourde pour les structures modestes.

C’est aussi pour cette raison que des zones grises subsistent encore. La Commission a publié le 3 mars 2026 un projet de guide pour aider les entreprises à appliquer le CRA, ce document porte notamment sur le logiciel libre, les solutions de traitement de données à distance, la notion de période de support et l’articulation avec d’autres textes européens. Tant que ces lignes directrices ne sont pas stabilisées, une part d’incertitude demeure dans l’interprétation pratique du règlement.

Pourquoi il faut se préparer dès maintenant ?

Même si l’échéance principale est fixée à décembre 2027, le CRA n’est pas un sujet à repousser à la dernière minute. Pour les entreprises concernées, la bonne méthode consiste dès maintenant à cartographier les produits, identifier le rôle juridique occupé dans la chaîne de valeur, repérer les écarts de conformité, mettre à jour les processus internes, organiser la documentation technique et préparer les procédures de gestion des vulnérabilités et de réponse aux incidents. C’est exactement le sens des ressources publiées par la Commission sur les fabricants, l’implémentation du texte et le guide soumis à consultation.

Ce que cela veut dire pour le grand public

Vu de l’extérieur, le CRA peut sembler technique. En réalité, son objectif est très concret : faire en sorte que les produits numériques vendus en Europe soient plus sûrs, mieux suivis, mieux documentés, et qu’il soit plus facile de savoir qui est responsable lorsqu’un problème de sécurité apparaît. Ce n’est donc pas une loi réservée aux spécialistes, c’est aussi une loi qui vise à mieux protéger les particuliers, les entreprises clientes et les administrations qui dépendent chaque jour de logiciels, d’applications et d’équipements connectés.

Quel lien avec la souveraineté numérique ?

Le lien avec la souveraineté numérique est direct, même s’il n’est pas toujours formulé ainsi dans le texte juridique. Un écosystème numérique souverain ne repose pas seulement sur le fait de disposer de code ouvert ou de solutions européennes, il suppose aussi de maîtriser la maintenance, la sécurité, la gouvernance, la capacité de correction et la responsabilité tout au long de la chaîne. De ce point de vue, le CRA pousse vers une forme de maturité industrielle qui peut renforcer l’autonomie numérique européenne.

Le règlement peut ainsi avoir un effet positif : si l’Europe soutient des offres open source ou européennes capables d’assumer proprement ces nouvelles exigences, le CRA peut devenir un levier de souveraineté numérique. Cette lecture n’est pas théorique : la Commission affirme désormais explicitement que le secteur open source est important pour la souveraineté technologique européenne, et plusieurs initiatives récentes lient l’open source à la réduction des dépendances, à la flexibilité, à la sécurité et à la compétitivité.

Mais l’effet inverse est tout aussi possible. Si le CRA devient, dans les faits, une mécanique de conformité que seuls les très grands fournisseurs peuvent absorber facilement, alors les plus petits acteurs, y compris européens et open source, risquent d’être marginalisés.
Dans ce scénario, des organisations pourraient préférer des offres propriétaires déjà très structurées sur le plan administratif, non pas parce qu’elles seraient nécessairement meilleures, mais parce qu’elles paraîtraient plus simples à gérer du point de vue réglementaire. Le danger serait alors de remplacer une dépendance technique par une dépendance de conformité. Cette conclusion relève d’une lecture stratégique du texte, mais elle est cohérente avec le niveau d’exigence du CRA et avec le fait que la Commission a déjà dû prévoir des guides et des mécanismes de soutien pour les petites structures.

La vraie question stratégique

Au fond, la bonne question n’est pas de savoir s’il faut choisir entre le CRA et l’open source. La vraie question est de savoir si l’Europe saura financer, outiller et accompagner les acteurs open source et les entreprises européennes, pour qu’ils puissent satisfaire ces nouvelles obligations sans être écrasés par elles. Si cet accompagnement suit, le CRA peut devenir un outil de montée en gamme et un levier de souveraineté. S’il échoue, le texte risque surtout de consolider la position des acteurs déjà les plus puissants.

À ce stade, tout l’enjeu est donc moins dans l’existence du règlement que dans sa mise en œuvre concrète.

L’article Cyber Resilience Act : qu’est-ce que c’est ? est apparu en premier sur Souverain.

C’est là que se situe pour l’Europe l’épreuve concrète de sa souveraineté numérique, son Acid Test !

En 2005, au cœur de la « guerre des navigateurs »,  un petit collectif de designers et développeurs, réunis sous la bannière du Web Standards Project (WaSP), a trouvé une arme d’une efficacité redoutable : un simple test en ligne. Oui, un simple test : Acid2, proposé au départ par Håkon Wium Lie et codé par Ian Hickson.

Ce n’était pas un énième document technique : c’était un défi public lancé à Microsoft, dont le navigateur Internet Explorer fragmentait le Web. À l’époque, un même site pouvait s’afficher correctement dans un navigateur et se casser dans un autre, parce que chaque éditeur imposait ses propres règles d’interprétation du HTML/CSS : les langages qui structurent l’affichage des pages web..

Résultat : des coûts de développement qui explosèrent, des services inaccessibles pour une partie du public, et un Web qui se fissura. WaSP mit en action deux leviers décisifs :

• La prise de conscience du grand public : une image mal affichée, un problème visible par tous, devenu viral, légèrement humiliant pour l’éditeur, donc impossible à ignorer pour Microsoft.
• Un changement d’objectif commun: cesser d’optimiser « pour tel navigateur » et implémenter le standard, au bénéfice de tous.

En 2007, le WaSP annonce que Microsoft a enfin corrigé son navigateur : une version interne d’Internet Explorer 8 réussit Acid2, un test conçu pour montrer d’un coup d’œil, de façon compréhensible par tous, si un navigateur respecte les règles communes du Web. Ce signal n’arrive pas dans le vide : il survient à peine une semaine après la plainte antitrust déposée par Opera contre Microsoft auprès de la Commission européenne, dans une affaire qui prend précisément sa source dans la vente liée d’Internet Explorer avec Windows et, plus largement, dans la question du respect des standards du Web.

Autrement dit : sous la pression conjuguée des développeurs, des graphistes, des internautes, du WaSP, et désormais d’un front concurrentiel et réglementaire ouvert en Europe, Microsoft a dû se remettre en question. Et parce que le résultat était visible publiquement par chacun, cette remise en conformité ne pouvait plus être différée.

Pour le grand public, si le test s’affichait correctement, c’était le signe d’un navigateur plus respectueux des standards et, par conséquent, plus fidèle dans son rendu. Concrètement : moins de sites conçus pour un seul navigateur, moins de pages qui s’affichent de travers et, au bout du compte, un Web plus fiable, plus cohérent, plus accessible. 

Pour les organisations européennes : une dépendance quotidienne

Vingt ans plus tard, le champ de bataille a changé : les enjeux ne sont plus des moteurs de rendu HTML, mais des suites bureautiques, du cloud, des identités numériques, des formats propriétaires, du matériel et des habitudes profondément enracinées.

La dépendance quotidienne de millions d’organisations européennes envers Microsoft ou Google notamment, n’est plus un sujet de spécialistes : c’est une infrastructure invisible qui impose ses coûts, ses contraintes et ses verrouillages, et finit par réduire notre marge de manœuvre politique et économique.

Après l’électrochoc géopolitique provoqué par l’administration Trump qui bouscule l’Europe, il devient difficile de faire comme si la question pouvait encore attendre. D’où l’angle de cet article : Souveraineté numérique : l’Europe face à son Acid Test

Mais cette fois, le test n’est pas une page web affichant un smiley pour confirmer que tout fonctionne. Cette fois, c’est notre capacité collective à sortir d’une dépendance ignorée, niée ou résignée.

Sensibiliser le grand public et se protéger d’un Big Shift

Et comme en 2005, il y a probablement deux leviers à actionner pour que ça bouge vraiment.

D’abord, sensibiliser le grand public, non par une conférence d’initiés et d’experts, mais par des messages compréhensibles par tous et faciles à vérifier.
Expliquer pourquoi il est devenu si difficile de bâtir une souveraineté numérique en France et en Europe : coûts, verrouillage, exposition juridique, continuité d’activité, lobbying, pantouflage, soupçons de corruption, inculture numérique des responsables politiques, capacité à décider.
Montrer comment la dépendance s’installe, et ce qu’elle nous retire, jour après jour, sans bruit.

Ensuite, proposer un chemin de sortie lisible : quoi migrer, vers quoi, dans quel ordre, avec quelles garanties et quels gains concrets, pour que les entreprises, les administrations, les citoyens et les divers écosystèmes puissent faire de vrais choix, sans se mettre en danger et en se protégeant d’un Big Shift.

Parce qu’au fond, cet « Acid Test » européen, que nous sommes en train de vivre, teste notre capacité commune à transformer un sujet abstrait en évidence partagée, puis en plan d’action concret.
Soyons lucides : si l’Europe échoue à convertir ce moment historique en bifurcation rapide et ambitieuse, il se pourrait que ce soit, pour longtemps, la dernière fenêtre où l’histoire nous autorise encore à choisir.

Un enjeu fort : prendre des décisions visibles

Attention au piège bien connu des discours européens : celui des diagnostics impeccables et des plans qui s’empilent sans basculer dans le réel. L’enjeu n’est plus d’accepter la dépendance numérique en se résignant, mais de la réduire activement par des décisions visibles : continuité d’activité, coûts, sécurité, capacité à décider, détermination assumée, via des actes concrets et un horizon clair pour un retour de l’Europe dans la nouvelle industrie… tout doit converger vers un même objectif de visibilité et de lisibilité des actions.

Rappelons que des signaux d’alerte existaient déjà : en 2023, Tariq Krim tranchait avec une formule volontairement brutale : La souveraineté numérique est morte… Vive la résilience !, comme un avertissement : sans vision claire, concrète et robuste, l’Europe se condamne à gérer l’urgence plutôt qu’à choisir sa trajectoire.

Le décor est planté, le reste ne se joue plus dans les intentions, mais dans la compréhension de la mécanique. La souveraineté numérique n’est pas un concept abstrait : elle se mesure à une accumulation de dépendances concrètes, parfois discrètes, souvent routinières, mais toujours lourde de conséquences quand elle se referme comme un étau.

7 mécanismes qui freinent l’autonomie stratégique et numérique

J’ai identifié et regroupé les principaux freins à partir de sources disponibles par tous, en les synthétisant dans une grille de lecture consolidée. Cette synthèse citoyenne n’a pas prétention à être parfaite ni exhaustive : elle reflète un état de compréhension à un instant donné, avec ses limites, ses biais inévitables et des zones où l’information publique reste incomplète.

J’invite donc explicitement les acteurs du secteur, les administrations, les experts, les entreprises et tous les défenseurs de la souveraineté numérique à me corriger, me contredire ou me compléter si certains constats sont mal interprétés, insuffisamment étayés ou si des éléments importants m’ont échappé. Pour rendre l’analyse lisible, j’ai découpé ces difficultés en sept grandes catégories, chacune accompagnée d’une explication simple illustrant, point par point, comment ces mécanismes freinent l’autonomie stratégique et numérique.

1. Gouvernance, doctrine et exécution de l’État

Sans direction claire (qui décide, avec quels objectifs, et à quel rythme ?), les administrations avancent en ordre dispersé. La souveraineté numérique exige une exécution continue sur plusieurs années, pas seulement des annonces :

• Pas de cap national clair sur le numérique et ses risques géopolitiques :
  Sans doctrine stable et de stratégie à long terme, ce qu’on accepte, ce qu’on refuse, et pourquoi, alors les choix techniques se font par défaut et s’accumulent sans cohérence.
• Pas de plan de secours crédible quand ça casse : panne, crise, sanctions, rupture :
  La souveraineté n’est réelle que si les services essentiels peuvent continuer à fonctionner en mode dégradé. Sinon, nous obtenons une souveraineté de façade, qui s’effondrerait à la première crise.
• Cybersécurité : ambitions affichées, moyens et calendrier fragiles :
  Une stratégie cyber sans financement lisible et sans calendrier tenable devient un document de communication, pas un bouclier. Les retards réglementaires laissent les organisations seules face à des obligations qui arrivent trop tard.
• Trop d’instances, labels et « observatoires » : beaucoup de pilotage, peu de résultats :
  Multiplier les structures dilue la responsabilité et ralentit l’action. Les citoyens et les entreprises voient passer des logos, des slogans, des conférences et des communiqués de presse mais pas des services qui changent concrètement.
• Politiques, administrations et industriels reconnaissent le problème, mais les décisions concrètes sont constamment repoussées :
  Les mesures utiles demandent des arbitrages visibles : budget, formation, migration, donc un risque politique à court terme. Résultat : on repousse, on temporise, on optimise le statu quo.
  

2. Dynamiques de marché et intermédiation : ESN, partenaires, compétences

Même avec une bonne volonté politique, le marché pousse naturellement vers les solutions dominantes : compétences disponibles, habitudes, « personne ne se fait virer pour ça ». Comprendre ces incitations est indispensable pour les corriger.

• Les prestataires poussent ce qu’ils savent vendre et opérer :
  Quand une ESN est formée, outillée et « récompensée » via des témoignages clients, ou autres participation à des tables rondes, spécialement bien conçus par les #GAFAM ou autres acteurs de la Big Tech US, elle les recommande plus souvent, même si une alternative ferait mieux sur le long terme.
• Les compétences se concentrent sur quelques marques, pas sur des savoir-faire transférables :
  On construit des carrières autour de certifications, souvent délivrées par la Big Tech, ce qui rend les alternatives plus difficiles à doter en compétences et donc moins souvent choisies. À terme, ça appauvrit la capacité collective à changer de fournisseur.
• La commande publique ne crée pas assez de marché pour les alternatives :
  Sans commandes massives, les acteurs européens n’atteignent pas l’échelle, donc restent « petits », donc restent jugés « risqués » : cercle vicieux.

3. Verrouillage technico-économique et dépendances structurelles

La dépendance n’est pas qu’un choix politique : elle est comme « encodée » dans les outils : formats, API, licences, habitudes. Plus on attend assumer des risques et mettre en place des alternatives, plus sortir des dépendances coûte cher.

• Changer de fournisseur devient trop cher et trop long :
  Avec le temps, s’accumulent des formats, des automatisations, des habitudes et des engagements contractuels qui rendent toute sortie longue, coûteuse et délicate. On reste captif, même quand la volonté de changer est là.
• Des dépendances invisibles : OS, firmwares, télémétrie, licences :
  On peut héberger « en Europe » tout en dépendant d’éléments critiques : logiciels, mises à jour, licences, lois extraterritoriales, contrôlés ailleurs. Ce sont des dépendances difficiles à expliquer au grand public, donc souvent ignorées.
• Pas d’alternative bureautique « simple et complète » à grande échelle :
  Tant qu’il n’existe pas une suite réellement déployable partout : support, compatibilité, formation, la dépendance à Microsoft/Google reste mécaniquement forte.
• Pour les citoyens, migrer est pénible (et le support manque) :
  Si la transition demande trop d’efforts (changer d’habitudes, formats, outils, prix), la majorité ne suit pas, donc pas d’effet de masse. Or sans masse, pas d’écosystème.

4. Normes, certifications et cadres juridiques

Les règles peuvent protéger, mais elles peuvent aussi exclure ou ralentir si elles deviennent trop lourdes. L’enjeu est d’avoir des règles qui sécurisent et permettent à une offre européenne de grandir.

• SecNumCloud : une certification de sécurité qui, aujourd’hui, peut aussi décider « qui a le droit de jouer » sur le marché du cloud souverain :
  SecNumCloud reste un référentiel de sécurité très exigeant, mais la qualification SecNumCloud 3.2 de S3NS (Thales + technologie Google ) montre qu’il peut aussi devenir un mécanisme de réorganisation du marché : les acteurs capables de porter un montage industriel/juridique lourd (et d’absorber le coût de qualification) prennent mécaniquement l’avantage, y compris quand la technologie sous-jacente n’est pas européenne.
  En parallèle, au niveau européen, la trajectoire de l’EUCS (telle que rapportée) s’oriente vers une certification surtout « cybersécurité » sans critères de souveraineté juridique, ce qui risque de diluer l’avantage différenciant de SecNumCloud et de faciliter une légitimation « cloud de confiance » d’acteurs soumis à des lois extraterritoriales, au détriment des acteurs qui avaient investi dans une souveraineté plus stricte.

5. Écosystème d’innovation, culture et financement

Une politique d’innovation peut fabriquer… de la dépendance, si elle finance des entreprises construites sur des briques étrangères sans exigence de réversibilité. La souveraineté demande des critères simples dans les aides : où sont les données ? quelles dépendances ? et comment sortir ?

• L’argent public aide parfois des modèles… dépendants des Big Tech :
  Sans conditions minimales (réversibilité, alternatives, transparence), une partie des subventions finit indirectement dans les plateformes dominantes : cloud, IA, outils.
• « Syndrome de Stockholm » : on finit par admirer ce dont on dépend :
  Quand l’écosystème valorise « être compatible GAFAM » comme signe de modernité, on normalise la dépendance. Et on stigmatise l’alternative comme « idéologique » ou « solutions d’amateurs ».
• L’État n’est pas exemplaire dans ses propres choix :
  Quand l’État ou des plateformes publiques utilisent des solutions controversées, il envoie le message que « c’est acceptable », donc il fragilise la crédibilité du discours souverain.

6. Infrastructures critiques, IA et dépendance capacitaire

La souveraineté se joue aussi sur la capacité matérielle et industrielle : puces, centres de données, puissance de calcul, solutions cloud. Sans capacité, on dépend des conditions et des prix fixés ailleurs.

• IA : dépendance au calcul, aux modèles et aux plateformes :
  Si l’Europe ne dispose pas d’assez de capacité de calcul et de services numériques majeurs, elle se retrouve à payer durablement une « rente » à des acteurs étrangers et à subir leurs règles. Cela concerne autant les entreprises que les administrations donc aussi les citoyens : une part (trop) importante de la valeur technologique, intellectuelle, industrielle et financière est alors captée hors d’Europe, au lieu de renforcer notre autonomie stratégique.

7. Capture, conflits d’intérêts et coût de la prise de risque

Même une bonne politique peut être neutralisée si les règles sont écrites par/pour les plus puissants, ou si les décideurs et les acteurs privés ont des intérêts trop alignés. Et si entreprendre est jugé « trop risqué », personne ne tente l’alternative.

• Pantouflage : va-et-vient public/privé qui brouille l’intérêt général :
  Quand des décideurs ou ex-décideurs rejoignent des acteurs concernés, cela crée (au minimum) un soupçon d’alignement d’intérêts. Ce soupçon suffit à dégrader la confiance et à orienter les politiques.
• Capture réglementaire : des règles qui « trient » les gagnants :
  Quand la conformité devient un parcours long et cher, seuls quelques acteurs peuvent jouer et les autres sortent du marché. La souveraineté devient alors un marché fermé, pas un écosystème vivant.
• Le risque et surtout le coût de « l’échec » est trop élevé :
  Si les entreprises craignent plus l’échec et surtout ses coûts, que la dépendance, elles choisissent la voie la plus « sûre » : le standard « dominant le marché ». La souveraineté exige que prendre un risque raisonnable soit possible : financement, marché, droit du travail, commandes.
• Lobbying : compromis politiques qui favorisent des solutions « US sous emballage » :
  Quand le lobbying est massif, les textes finissent souvent par privilégier la « compatibilité marché » plutôt que l’autonomie réelle.
  Résultat : on régule… sans changer la dépendance.

Cette analyse procède d’une veille engagée depuis plusieurs années. Mais depuis 2025, elle s’est prolongée par un travail de curation de plus de 180 sources distinctes, sélectionnées pour leur intérêt et leur valeur d’éclairage : articles, rapports officiels, tribunes et études… Chaque argument et exemple présenté ici est le résultat d’une synthèse rigoureuse, alimentée par des sources variées et régulièrement mises à jour. Pour des raisons de lisibilité, il n’est pas possible d’intégrer une référence à chaque affirmation dans le texte. Cependant, l’intégralité des sources est accessible gratuitement pour celles et ceux qui souhaitent approfondir, vérifier ou explorer les documents originaux. Vous pouvez consulter l’ensemble de cette base documentaire, organisée et actualisée, sur mon espace de veille Flus.

Construire un récit compréhensible

On ne gagne pas en autonomie par décret. En revanche, il existe un champ immense des possibles, des voies techniques, juridiques, industrielles, éducatives, des scénarios graduels, des bifurcations réalistes. L’Europe ne manque pas d’intelligence et d’innovation. Elle manque d’une bascule. Et d’un signal collectif.
Ma conviction, forgée par des années de veille, est simple, mais pas simpliste : les professionnels et les acteurs du secteur constatent tous les jours les dépendances, les blocages, les angles morts, les budgets se faire siphonner en dehors de l’Europe, les compromis, les chaînes d’approvisionnement invisibles. Ce qui manque maintenant, ce n’est pas la lucidité dans les cercles techniques et d’experts, c’est sa traduction en décisions, puis en mouvement de masse.

Du côté politique, l’image est nettement plus trouble, pour utiliser un terme mesuré. Quelques élus s’en saisissent, pas toujours ceux qui tiennent les leviers, les budgets, les arbitrages, ni la capacité d’imposer une trajectoire sur dix ans. Et du côté du grand public, le sujet reste trop discret, trop abstrait, trop souvent relégué au rang d’inquiétude d’initiés. Or c’est précisément là que se joue l’issue : tant que la souveraineté numérique restera un langage réservé aux experts, elle restera une variable d’ajustement.

Source : Forum de Paris sur la paix

À l’inverse, le jour où notre dépendance devient une évidence partagée, elle peut se transformer en pression publique et démocratique. Le jour où citoyens, clients/utilisateurs finaux, collectivités comprennent, alors les décideurs n’ont plus l’alibi de l’ignorance, ni le confort du « flou« , « c’est trop compliqué« , « on n’y comprend rien », « de toute façon on achètera la techno aux Chinois ou ailleurs« .

En résumé, au moment où l’Europe affronte son Acid Test, elle ne passe pas seulement un test technique mais aussi et surtout un test de maturité collective. Rappelons-nous : dans la guerre des navigateurs, l’étincelle n’a pas été une commission interminable, mais une initiative concrète, lisible et virale. Au départ, ils n’étaient que trois : Maria Olsen, Glenn Davis, Jeffrey Zeldman et l’évidence a fini par faire plier un géant comme Microsoft.

Certes, je ne prétends pas que la souveraineté numérique réduit à une liste de critères : le monde d’aujourd’hui est plus vaste, plus systémique, plus complexe, plus politique voire même plus géopolitique. Mais je soutiens ceci : il faut, maintenant, parler autrement. Parler au-delà de nos cercles respectifs. Construire un récit compréhensible, des repères concrets, des signaux simples, des priorités assumées. Si le public ne comprend pas, il n’adhère pas, s’il n’adhère pas, il ne demande rien et s’il ne demande rien, alors rien ne bouge.

Des exemples inspirants en France et en Europe

Et pourtant, nous avons déjà su, en France, innover et faire muter des usages. Avant même que le mot « souveraineté numérique » ne s’impose, nous avions des services qui tenaient la comparaison : Dailymotion n’avait pas à rougir face à YouTube ; Caramail, avec ses lourdeurs et son Java à télécharger, déjà d’un autre âge, a pourtant été un des premiers réseaux sociaux avant l’heure. Mais ces exemples disent aussi autre chose : si le public peut adopter des alternatives locales ou européennes, celles-ci peinent à tenir dans la durée face à des géants mieux armés. Dailymotion a fini marginalisé puis contraint de se repositionner, Caramail a été vendu, dépecé, et n’a jamais retrouvé sa base d’utilisateurs. La leçon est donc plus exigeante que le simple constat d’une adhésion possible : le public n’est pas hostile « par nature » aux alternatives locales ou européennes, mais cette adhésion ne suffit pas. Il adopte ce qui est simple, fiable, désirable, soutenu et il faut précisément un soutien structurel pour que l’offre tienne, dure, et puisse réellement aller chercher une adoption de masse.

Et bien sûr, l’Europe n’est pas un désert. Elle compte des réussites et des leaders : Spotify, Leboncoin, BlaBlaCar, Deezer, Doctolib, Ledger, OVH, Back Market, Clever Cloud, Scaleway, Revolut, Heetch, Criteo et bien d’autres que j’oublie et j’espère qu’ils me pardonneront.

Briser la chaîne de dépendance

Mais la lucidité impose de nommer les manques : une messagerie et une suite bureautique « sans douleur » à l’échelle ; un réseau social européen digne de confiance ; un moteur de recherche crédible ; un concurrent logistique et marchand capable d’atteindre la masse critique et, en parallèle, une couche matérielle enfin reprise en main : puces, serveurs, équipements réseaux, terminaux. Car la chaîne de dépendance commence là, dans le silicium, les firmwares et les chaînes d’approvisionnement. Sans capacité industrielle, aucune souveraineté ne tient.
Sans ces piliers, la dépendance restera mécanique, et l’IA européenne comme Mistral et les autres, manquera durablement d’assise : données, infrastructures, capacités de calcul, briques matérielles maîtrisées, accords clairs avec les éditeurs et créateurs, conditions d’entraînement compatibles avec le droit européen. À cela s’ajoute une autre condition, souvent sous-estimée mais décisive : la capacité à bâtir une offre publicitaire concurrentielle et sainement régulée : éthique, fondée sur le consentement, conforme au RGPD et transparente, donc plus saine, plus soutenable et, in fine, plus valorisante pour les annonceurs.

Pacifier l’usage du terme « souveraineté numérique »

La souveraineté numérique n’est pas une mode passagère ni un énième concept bobo. Ce n’est ni un luxe, ni un hobby de spécialistes, ni une posture sociale. C’est un sujet d’intérêt général et c’est une nécessité : continuité des services, résilience économique, autonomie démocratique et stratégique, capacité industrielle, protection des libertés. Ce n’est ni de droite ni de gauche : c’est un commun. Et si certains préfèrent utiliser le terme autonomie stratégique, je peux comprendre mais nous n’avons pas à avoir honte de l’expression souveraineté numérique. À ne pas la confondre avec le souverainisme. Assumons le terme, et faisons en sorte qu’il appartienne à tout le monde, précisément parce qu’il concerne tout le monde.

Reste enfin une exigence morale et pratique : l’union. Il est temps que celles et ceux qui croient au concept de souveraineté numérique, cessent de reproduire les travers des partis, des « chapelles », des guerres d’ego. Ce projet est immense. Il y a de la place, mais il y a surtout une urgence. Mettons-nous autour de la table, échangeons, construisons des compromis, fixons des intérêts communs dès le départ, assez clairs pour dépasser les intérêts personnels, assez solides pour survivre aux alternances, assez concrets pour produire des résultats visibles par tous. Car pendant que nous nous divisons, ce sont les GAFAM qui gagnent, tranquillement, mécaniquement, par notre inertie.

Le problème, c’est qu’aujourd’hui, on a des hommes politiques qui délèguent trop de choses aux GAFAM. Parfois, ils délèguent aux plateformes de réseaux sociaux la modération. Ils délèguent aux créateurs de modèles d’IA l’éthique de l’intelligence artificielle, avec, vous le voyez, un pantouflage assez incroyable.

Et si vous voulez, à partir de là, vous entrez dans cette logique de soumission et de servitude, parce qu’en plus, vous déléguez là où, normalement, il faudrait contrôler.

Je ne suis pas forcément pour que l’Europe soit uniquement dans une position de contrôle. On doit revenir dans une logique de puissance.

Propos de Mehdi Medjaoui fondateur d’Olympe Legal via la chaîne Youtube de Yassine Chabli.

L’Europe ne réussira pas son Acid Test à coups d’incantations. Elle pourra l’aborder plus lucidement lorsque le public demandera à ses élus, avec clarté, de répondre à des enjeux désormais mieux compris et davantage débattus. Encore faut-il que les acteurs, en agissant de manière concertée, rendent ce choix réellement possible.

Alors, la souveraineté numérique pourra commencer à sortir du registre du slogan pour s’inscrire dans une démarche plus concrète.

Une trajectoire européenne originale pourra ainsi se dessiner, dans un esprit de construction plutôt que de rupture, c’est-à-dire comme une orientation politique construite, assumée et consolidée dans le temps.

Remerciements à Christophe Castro pour sa relecture et ses conseils éditoriaux.

L’article Souveraineté numérique : l’Europe face à son Acid Test est apparu en premier sur Souverain.

Je veux aussi revenir sur un changement important : celui du manifeste. Par honnêteté pour les lecteurs et lectrices, et par souci de transparence, j’ai choisi de mettre à disposition les différentes versions du texte, tout en conservant mon anonymat. La version actuelle, la 2.0, marque une rupture nette.

La précédente pouvait parfois tomber dans des réflexes trop abrupts : l’appel à l’unité sans démonstration suffisante, le goût des absolus, des injonctions, des oppositions trop binaires. Il a donc fallu reprendre le travail en profondeur, accepter la remise en cause, creuser davantage le fond pour faire émerger quelque chose de plus juste, de plus ouvert, de plus utile.

Non pas un texte qui somme, mais un texte qui invite. Non pas un texte qui impose, mais un texte qui donne envie de suivre, de comprendre, d’aider, de participer. Je remercie sincèrement celles et ceux qui m’ont critiqué, corrigé, alerté : leurs remarques étaient justes, et surtout, elles m’ont permis de mieux servir l’objectif réel de cette démarche : convaincre sans imposer, convaincre pour faire bouger les lignes, convaincre que c’est possible !

Je veux également vous rassurer sur un autre point. Ces derniers temps, j’ai beaucoup écrit sur la souveraineté numérique dans une approche plus frontale, plus structurelle, parfois davantage ancrée dans les enjeux d’intérêt général et de politique publique que dans le simple test de produits. Non pas dans une logique partisane, mais dans la volonté de faire avancer les choses en France et, plus largement, en Europe. Parce que nous sommes engagés sur une trajectoire très encourageante, et qu’il faut désormais tenir le cap. Beaucoup de fronts ont été ouverts, beaucoup de chantiers restent en cours, et le moment n’est plus à l’hésitation. Il faut avancer, et ne rien lâcher.

D’autant que, comme je l’ai détaillé dans un article, les forces d’inertie sont puissantes: le lobbying, en ce moment, travaille activement pour défendre des intérêts qui ne sont pas les nôtres et, trop souvent, pour s’assurer que rien ne change. C’est aussi pour cela que je prépare un long travail de fond sur ce qui dysfonctionne, en France, dans le domaine de la souveraineté numérique : une analyse approfondie, appuyée sur des exemples, des comparaisons et des cas concrets, afin de sensibiliser à la fois les décideurs et le grand public. Ce travail me prend du temps, et j’essaie de le rendre aussi complet que possible.

Mais aujourd’hui, revenons au concret. Revenons au test. Et, cette fois, je ne passerai pas par quatre chemins. Infomaniak n’est pas un nouvel entrant opportuniste : l’entreprise suisse existe depuis 1994, soit plus de trente ans d’activité, et son siège est situé aux Acacias, à Genève. Elle se présente comme une société indépendante, gérée par son personnel, qui développe ses logiciels en interne ou s’appuie sur des technologies open source, tout en hébergeant les données en Suisse. Sa ligne est claire : proposer un cloud souverain, éthique et pleinement conforme au RGPD, centré sur la protection des données personnelles, ancré dans l’économie locale, attaché à l’autonomie technologique et engagé dans la réduction de son empreinte carbone.

Et je peux déjà vous le dire, rapidement et sans détour : dans sa formule gratuite, my kSuite est, à ce stade, l’alternative la plus convaincante que j’aie trouvée pour amorcer un départ de Google. Oui, je pèse mes mots. Oui, c’est un avis tranché. Mais je ne suis pas ici pour prolonger artificiellement le suspense au fil d’un article conçu pour vous retenir jusqu’à la dernière ligne avant d’en livrer la conclusion. Mon but est d’aider, le plus clairement possible.

L’offre gratuite permet déjà de tester sérieusement la bascule : une adresse de courriel gratuite et « à vie », 20 Go de stockage pour la messagerie et 15 Go pour les fichiers et les photos, avec accès aux outils Mail, kDrive, kMeet, Calendar et Contacts. Autrement dit : de quoi mener de vrais essais, de vraies conclusions, et, pour beaucoup, de quoi constater qu’il devient enfin possible de quitter un des GAFAM sans appréhension.

Je concentrerai ce test sur ce qui me paraît essentiel pour une migration sérieuse : le courriel, l’agenda, les contacts, le traitement de texte, le tableur, la visioconférence et la gestion des fichiers. Infomaniak propose évidemment bien d’autres services, et j’y reviendrai avec une liste dédiée. Mais pour qu’un test soit utile, il faut aussi savoir choisir son périmètre. Mon objectif, ici, est simple : examiner ce qui compte vraiment pour celles et ceux qui veulent quitter les GAFAM sereinement, sans sacrifier l’usage quotidien.

Premiers pas

Commençons par l’inscription. Sur ce point, rien de véritablement déroutant : on reste dans un parcours classique, suffisamment balisé pour ne pas nécessiter de longs commentaires. Je ne m’y attarderai donc pas. Il y a toutefois une réserve que je souhaite formuler dès maintenant, parce qu’elle me semble pertinente sur le long terme : il serait intéressant de pouvoir créer un compte sans être tenu de créer simultanément une adresse de messagerie.

Je peux naturellement entendre qu’une telle évolution ne soit pas si simple à mettre en œuvre, notamment si l’architecture du compte repose en grande partie sur une logique de SSO. Je peux également comprendre la cohérence stratégique d’un tel choix : après tout, c’est aussi par ce biais : un compte mail d’abord, puis un écosystème complet ensuite que Google a, en son temps, construit une part essentielle de sa domination. Ce n’est donc pas, en soi, une critique disqualifiante. C’est davantage une piste d’amélioration, ou du moins un point de réflexion.

À cela s’ajoute une impression plus mineure, et je tiens à la présenter comme telle : les différents noms de domaine disponibles ne sont pas toujours les plus simples à retenir. Cela peut troubler légèrement au premier abord. Mais je le dis volontiers avec honnêteté : cet argument reste en grande partie subjectif, et il serait exagéré d’en faire un véritable grief.

Passons donc à l’étape suivante : celle de la première connexion, autrement dit l’arrivée dans l’espace d’accueil ou, si l’on préfère, dans le tableau de bord principal. Et c’est ici que l’exercice devient nettement plus intéressant. Car concevoir une telle interface est tout sauf simple. L’enjeu est de rendre de nombreux éléments accessibles sans verser dans l’encombrement, d’offrir une réelle profondeur fonctionnelle sans perdre l’utilisateur et, en somme, de faire tenir tout un écosystème dans un espace restreint, sans que celui-ci paraisse saturé.

Sur ce point, il faut le reconnaître sans détour : le travail est particulièrement bien mené. L’équipe est parvenue à intégrer l’essentiel, presque tout ce dont l’utilisateur peut avoir besoin au quotidien, sans jamais donner l’impression d’une interface surchargée. C’est précisément là que réside, à mes yeux, la réussite de ce tableau de bord : dans une forme de maîtrise du minimalisme. L’ensemble est simple, sobre, lisible, mais surtout efficace.

Dès l’arrivée sur l’interface, rien ne déstabilise véritablement. On retrouve des repères, des réflexes d’usage déjà connus, sans pour autant avoir le sentiment d’évoluer dans une copie sans relief de ce qui existe ailleurs. L’environnement inspire immédiatement une familiarité fonctionnelle, tout en conservant une identité propre. Et c’est un équilibre bien plus difficile à atteindre qu’il n’y paraît.

Concrètement, tout ce qui compte est accessible d’un seul regard. Sur la gauche, des raccourcis permettent de rejoindre rapidement les principales applications. En haut à droite, on retrouve l’accès aux paramètres, à la configuration et à la gestion du compte. Au centre, l’interface propose une synthèse claire des informations utiles : les rendez-vous à venir, les derniers courriels reçus, un espace dédié aux favoris (que je n’utiliserai pas dans le cadre de ce test) ainsi que plusieurs appels à l’action permettant, en un clic, de créer un document ou d’accéder rapidement à d’autres services.

En d’autres termes, cette première impression est bonne, et même très bonne. L’entrée en matière est fluide, intelligible et rassurante. Or, dans ce type d’outil, cela compte énormément : une suite bureautique peut multiplier les fonctionnalités, elle reste vaine si elle ne parvient pas d’abord à accueillir correctement son utilisateur. Ici, ce n’est pas le cas. Et c’est déjà un point fort.

Courriel

Passons maintenant au courriel. Ici encore, je ne vais pas inutilement allonger le propos, car l’essentiel peut se dire simplement : l’interface fait très bien ce qu’on attend d’elle. Elle est sobre, lisible, efficace. Rien de révolutionnaire, peut-être, mais rien de décevant non plus et, dans ce registre, c’est déjà beaucoup. Tout est à sa place, sans surcharge, sans effet inutile, avec cette qualité devenue rare : celle de laisser l’outil travailler sans chercher à se faire remarquer.

Je me suis toutefois interrogé sur la solution technique retenue. Au premier abord, j’ai cru reconnaître quelque chose de très proche de ce que j’avais déjà vu ailleurs, notamment dans des environnements comme Twake ou la messagerie de LaSuite (Open-Xchange). Ce n’aurait d’ailleurs nullement été un reproche. Mais après vérification auprès de l’équipe, il apparaît qu’il s’agit ici d’une application développée en interne. Et, là encore, cela mérite d’être dit franchement : c’est une réussite, et c’est une nouvelle fois un motif de féliciter celles et ceux qui ont conçu cette interface. J’en profite au passage pour rappeler qu’Infomaniak s’inscrit dans un écosystème technique largement nourri par l’open source, avec un ancrage revendiqué dans des briques et des communautés majeures du logiciel libre, comme OpenStack, Debian, ou encore la Free Software Foundation.

L’expérience mobile confirme d’ailleurs cette bonne impression. Une application existe sur iOS comme sur Android, et j’ai mené mes essais sur iPhone. L’ensemble se distingue par sa clarté, sa réactivité et sa facilité de prise en main. Pas de surcharge, pas de fioritures, pas de surenchère visuelle. L’exécution est propre, l’usage immédiat. En un mot : j’adore.

Il y a aussi, dans cette offre gratuite, un point que je n’avais pas encore assez souligné et qui mérite pourtant d’être mis en avant : ici, l’utilisateur n’est pas le produit. Infomaniak assume un modèle dans lequel la gratuité n’est pas financée par l’exploitation publicitaire ou par l’analyse des données personnelles, mais par la vente de services payants plus avancés. Dans le paysage numérique actuel, ce n’est pas un détail, c’est même un marqueur décisif. À cela s’ajoute un autre point important : la messagerie met en avant un chiffrement reposant sur ECC et OpenPGP, deux standards open source bien identifiés, ce qui renforce encore la cohérence d’ensemble sur le terrain de la confidentialité et de la sécurité.

La seule vraie contrainte, à ce stade, concerne la signature imposée dans les courriels envoyés depuis l’offre gratuite. Il n’est pas possible de la supprimer sans passer à une formule payante. Faut-il y voir une faute ? Honnêtement, non. Il faut aussi savoir juger un modèle économique avec équité. Nous sommes ici face à une solution gratuite, précisément conçue sans faire de l’utilisateur un produit. En contrepartie, une signature reste visible. C’est une forme de publicité, oui, mais une publicité assumée, limitée, compréhensible et, au fond, défendable. Si cette mention suscite la curiosité du destinataire et permet à Infomaniak de convertir de nouveaux utilisateurs (clients), alors l’équilibre me paraît parfaitement recevable.