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.

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 peut être utilisé avec ACME, mais la procédure n’a pas encore la même fluidité pour un utilisateur grand public. 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

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.