Limites de l'indépendance numérique

En janvier 2022, une administration de district allemande — environ 800 agents, deux informaticiens à temps plein — a migré sa messagerie de Microsoft 365 vers une installation auto-hébergée d’Open-Xchange. La migration s’est déroulée sans accroc technique. Six mois plus tard, un certificat TLS a expiré sans que personne ne s’en aperçoive — l’équipe IT gérait simultanément une panne de stockage. Les e-mails sortants ont échoué silencieusement pendant trois jours. Des contrats sont restés non signés. Un délai d’appel d’offres est passé. Personne ne le savait, jusqu’à ce qu’un fournisseur appelle pour demander pourquoi l’offre n’était pas arrivée.

L’administration avait atteint la souveraineté sur sa messagerie. Elle avait aussi atteint la souveraineté sur ses pannes.

Ce schéma — migration techniquement réussie, suivie d’une défaillance opérationnelle par sous-investissement — se répète dans les études de cas de ce site. Le Schleswig-Holstein a investi 9 millions d’euros et une équipe dédiée. La Gendarmerie française a construit une organisation IT interne sur deux décennies. L’administration ci-dessus a investi dans une migration, mais pas dans l’exploitation nécessaire pour la pérenniser. La différence de résultat n’était pas le logiciel — c’était les effectifs.

Chaque autre article de ce site plaide pour la réduction de la dépendance envers les fournisseurs non européens. Celui-ci pose la question que cet argument laisse ouverte : jusqu’où faut-il aller ?

La réponse n’est pas « aussi loin que possible ». C’est un calcul — valeur de souveraineté contre coût opérationnel, risque de sécurité en cas de sous-investissement, et coût d’opportunité de détourner l’expertise de votre mission réelle. Parfois, ce calcul favorise la souveraineté. Parfois non. Connaître la différence, c’est ce qui sépare la stratégie de l’idéologie.

La prime de souveraineté

Chaque système que vous exploitez vous-même coûte plus cher qu’un service managé — pas en frais de licence, mais en attention. C’est la prime de souveraineté, et elle est systématiquement sous-estimée.

Une base de données managée sur AWS (RDS) signifie qu’Amazon gère les correctifs, les sauvegardes, le basculement, la surveillance et la mise à l’échelle. Une instance PostgreSQL auto-hébergée chez Hetzner signifie que vous gérez tout cela — ou plus précisément, que votre équipe le gère, en plus de tout ce qu’elle fait déjà. La facture mensuelle est plus basse. Le coût total de possession ne l’est peut-être pas.

Prenons un scénario concret : une organisation de 200 personnes auto-hébergeant cinq services essentiels — messagerie (Open-Xchange), synchronisation de fichiers (Nextcloud), identité (Keycloak), une base PostgreSQL et un cluster Kubernetes.

• Coût d’hébergement : environ 800 €/mois sur des serveurs dédiés Hetzner. L’équivalent sur AWS : 3 000 à 4 000 €/mois. Les économies de 3 à 5 fois sont réelles.
• Coût opérationnel : chaque service nécessite surveillance, correctifs, vérification des sauvegardes, planification de capacité et réponse aux incidents. À raison de 6 heures par service et par mois, cela fait 30 heures — environ 20 % de la capacité d’un ingénieur senior. À 80 €/heure charges comprises : 2 400 €/mois de coûts de personnel.
• Coût des pannes : quand AWS RDS tombe, l’équipe d’astreinte d’Amazon réagit en minutes. Quand votre PostgreSQL auto-hébergé tombe un samedi à 2 h du matin, votre équipe réagit — si vous avez une astreinte le week-end. Une seule panne de 8 heures coûte plus en productivité perdue qu’un mois d’économies d’hébergement.
• Coût d’opportunité : l’ingénieur senior qui maintient cinq services d’infrastructure ne construit pas le produit, n’améliore pas les processus et ne forme pas l’équipe.

Le calcul net : 800 €/mois d’hébergement + 2 400 €/mois de personnel = 3 200 €/mois — comparable à la facture hyperscaler à laquelle vous tentiez d’échapper, mais avec le risque opérationnel de votre côté. Les économies ne sont réelles que si vous avez déjà l’équipe. Si vous devez recruter pour cela, les deux premières années sont une perte nette.

Rien de tout cela ne signifie que l’auto-hébergement est une erreur. Cela signifie que l’auto-hébergement est un investissement, et que les investissements ne rapportent que lorsqu’ils sont correctement financés. Un serveur de messagerie auto-hébergé exploité par une équipe compétente avec une surveillance professionnelle est plus souverain et potentiellement plus sûr qu’un service managé. Un serveur de messagerie auto-hébergé exploité par une équipe en sous-effectif qui gère aussi le pare-feu, le parc de postes de travail et la file d’impression est un incident de sécurité en attente.

La question de la souveraineté n’est pas « devrions-nous contrôler cela ? » C’est : « pouvons-nous exploiter cela au niveau de fiabilité et de sécurité que le cas d’usage exige ? » Si la réponse est non, la souveraineté n’est pas un avantage — c’est un passif.

Où les solutions propriétaires sont réellement meilleures

Il existe une version de l’argument souverainiste qui dit : « chaque alternative open source est suffisante ; il suffit de faire plus d’efforts. » Ce n’est pas vrai, et faire semblant coûte en crédibilité. Certaines solutions propriétaires sont, aujourd’hui, mesurément meilleures que leurs équivalents open source — non pas parce que l’open source est fondamentalement inférieur, mais parce que certains problèmes récompensent le type d’investissement concentré et soutenu que des chiffres d’affaires de plusieurs milliards permettent.

L’édition collaborative de documents

C’est l’écart le plus visible. Collabora Online et OnlyOffice sont fonctionnels et s’améliorent, mais la co-rédaction en temps réel — l’expérience de plusieurs personnes tapant dans le même document avec suivi instantané du curseur, commentaires en direct et résolution transparente des conflits — reste plus fluide dans Google Docs et Microsoft 365. Pour les équipes où la collaboration en temps réel est le flux de travail central (rédactions, rédaction juridique, communications de direction), cet écart n’est pas théorique. C’est une friction quotidienne.

La recommandation honnête : pour la création de documents — rédaction, mise en forme, travail individuel — LibreOffice est pleinement compétitif. Pour la collaboration en temps réel, évaluez Collabora ou OnlyOffice par rapport à votre flux de travail réel. Si l’écart est important pour votre équipe, reconnaissez-le — ne faites pas semblant qu’il n’existe pas.

La visioconférence à grande échelle

Jitsi fonctionne bien pour des réunions de 30 à 50 participants. Pour les grands événements — réunions plénières de 500 personnes, webinaires avec partage d’écran et salles de sous-groupes, événements hybrides avec streaming de qualité studio — Teams, Zoom et Google Meet ont investi des centaines de millions de dollars dans une infrastructure qu’aucun projet open source n’a encore égalée. L’écart de qualité pour les petites réunions s’est considérablement réduit. L’écart pour les événements à grande échelle, non.

Les modèles IA de pointe

La pile IA souveraine est réelle et pratique pour la plupart des cas d’usage. Mais la frontière — les modèles de raisonnement les plus performants, les fenêtres de contexte les plus grandes, les capacités multimodales les plus avancées — reste le domaine d’OpenAI, Anthropic et Google. Les modèles open-weight rattrapent rapidement leur retard, et pour 90 % des cas d’usage métier, un déploiement Mistral ou LLaMA sur infrastructure européenne suffit. Mais pour les 10 % restants — recherche de pointe, tâches de raisonnement complexes en plusieurs étapes, génération de code avancée — les modèles propriétaires de pointe sont mesurément meilleurs.

Les écosystèmes de services managés

C’est l’avantage structurel, pas un produit individuel. AWS propose plus de 200 services managés. Chacun élimine une catégorie de travail opérationnel. Une startup construisant sur Lambda, API Gateway, DynamoDB, Cognito et CloudFront a, en fait, externalisé les opérations de cinq catégories d’infrastructure. L’équivalent chez les fournisseurs européens nécessite cinq outils distincts, cinq efforts de configuration, cinq dispositifs de surveillance. Les outils individuels existent. L’écosystème intégré, non.

Le constat honnête : pour les organisations profondément ancrées dans les écosystèmes hyperscaler, le coût de migration n’est pas seulement financier — il est architectural. Prétendre le contraire n’aide personne.

Le piège de l’auto-hébergement

L’auto-hébergement est l’expression la plus aiguë de l’indépendance numérique — et celle qui a le plus de chances de mal tourner sans ressources adéquates.

Déployer un logiciel est un projet. Exploiter un logiciel est un engagement. Le schéma se répète dans tous les secteurs : une organisation auto-héberge un service, célèbre la mise en production, puis découvre — des mois ou des années plus tard — qu’exploiter le service de manière fiable est plus difficile que l’installer.

La dimension sécurité

Un fournisseur de services managés emploie des équipes de sécurité dédiées, gère des programmes de bug bounty, déploie des correctifs en quelques heures et surveille les intrusions en permanence. Une installation auto-hébergée est exactement aussi sûre que l’équipe qui l’exploite — ni plus ni moins.

Considérez Keycloak, le fournisseur d’identité open source recommandé pour la gestion souveraine des identités. Keycloak est un excellent logiciel. Mais une instance Keycloak en retard de trois versions mineures sur les correctifs de sécurité, parce que l’équipe avait d’autres priorités, est pire qu’Okta — non pas parce qu’Okta est plus souverain, mais parce qu’Okta est corrigé par une équipe dont le seul travail est de le corriger.

Ce n’est pas un argument contre l’auto-hébergement de Keycloak. C’est un argument pour financer la capacité opérationnelle de le faire correctement. Si le budget existe pour embaucher ou mandater une équipe qui maintient l’instance à jour, surveillée et sauvegardée — Keycloak auto-hébergé est le meilleur choix, point final. Si le budget n’existe pas, le gain de souveraineté est compensé par la perte de sécurité.

L’angle mort de la surveillance

Les crashs sont visibles. La dégradation silencieuse ne l’est pas — et c’est le mode de défaillance le plus dangereux. Un service managé alerte quelqu’un quand le temps de réponse de la base de données double, quand un certificat approche de l’expiration, quand l’utilisation du disque dépasse 80 %. Les systèmes auto-hébergés n’ont d’alertes que si quelqu’un les a construites, testées et maintient l’infrastructure d’alerte elle-même. Le monitoring est de l’infrastructure. Il nécessite sa propre maintenance.

L’administration de district de l’introduction n’a pas perdu sa messagerie parce que le serveur a planté. Elle l’a perdue parce qu’un certificat a expiré et personne ne regardait. Pas un problème technologique — un problème de ressources. Et les problèmes de ressources ne disparaissent pas parce que le logiciel est open source.

Un cadre de décision

L’administration de district de l’introduction et la Gendarmerie française exploitent la même catégorie de logiciels. L’une a perdu sa messagerie pendant trois jours ; l’autre fait fonctionner 103 000 postes Linux depuis deux décennies avec un TCO inférieur de 40 % à l’équivalent Windows. La différence n’est pas la technologie. Ce n’est même pas le budget. C’est l’adéquation entre l’ambition et la capacité opérationnelle — et la volonté d’être honnête sur l’écart.

La matrice suivante propose une méthode structurée pour cette évaluation : où la souveraineté apporte de la valeur et où elle apporte du risque.

Axe 1 : valeur de souveraineté

Dans quelle mesure le contrôle de ce système réduit-il votre risque de concentration ?

• Élevée : gestion des identités, messagerie, stockage de données central. Ces systèmes contiennent vos données les plus sensibles et sont les plus dangereux sous une juridiction étrangère. Une perturbation ici est existentielle.
• Moyenne : suite bureautique, synchronisation de fichiers, messagerie instantanée interne. Important, mais une perturbation temporaire est survivable. La sensibilité des données varie selon le cas d’usage.
• Faible : CDN, hébergement de site web public, outils de surveillance, pipelines CI/CD. Ces systèmes traitent peu de données sensibles et peuvent être remplacés rapidement.

Axe 2 : complexité opérationnelle

À quel point est-il difficile d’exploiter ce système de manière fiable ?

• Élevée : messagerie (délivrabilité), clusters Kubernetes, bases de données avec des exigences strictes de disponibilité, gestion des identités à grande échelle. Nécessitent une expertise dédiée et une surveillance 24h/24.
• Moyenne : synchronisation de fichiers (Nextcloud), hébergement de sites statiques, serveurs applicatifs de base. Nécessitent de l’attention mais sont gérables avec une équipe compétente.
• Faible : applications de bureau (LibreOffice), choix de format de document (ODF), choix de navigateur. Surcoût opérationnel quasi nul.

La matrice

Le coin supérieur gauche (valeur élevée, complexité faible) est le point de départ pour chaque organisation. Passer aux formats de documents ouverts ne coûte rien et crée de l’optionalité. Déployer des clés FIDO2 matérielles améliore la sécurité et la souveraineté. Installer LibreOffice ne nécessite aucune infrastructure.

Le coin inférieur droit (valeur faible, complexité élevée) est l’endroit où les efforts de souveraineté gaspillent des ressources. Exploiter son propre CDN pour un site web public est opérationnellement coûteux et ne rapporte rien — aucune donnée sensible n’est en jeu, et les CDN sont trivialement remplaçables. Utiliser une API IA hébergée aux États-Unis pour des tâches non sensibles (résumer des documents publics, générer des textes marketing) est un choix pragmatique quand l’alternative consiste à déployer et maintenir un cluster GPU pour du travail à faible enjeu.

Les décisions difficiles se trouvent au milieu et en haut à droite : des systèmes dont le contrôle a une forte valeur mais qui sont opérationnellement complexes. Ici, la décision dépend des ressources, pas des principes. Si vous avez l’équipe et le budget, auto-hébergez. Sinon, utilisez un fournisseur managé européen. Si aucun fournisseur managé européen adéquat n’existe, un fournisseur américain avec un contrat soucieux de la souveraineté (résidence des données, clauses de sortie, conformité au Data Act) est un meilleur choix qu’une installation auto-hébergée sous-financée.

Cinq règles pour une souveraineté rationnelle

En tirant les enseignements des schémas présentés sur ce site — les succès et échecs des migrations du secteur public, le fossé des services managés dans le cloud, la réalité TCO des postes de travail souverains — cinq règles émergent :

1. Récolter d’abord les gains gratuits

Formats de documents ouverts. Clés FIDO2 matérielles. LibreOffice. Standards ouverts. Coût nul, aucune infrastructure requise, zéro risque opérationnel — et pourtant ils créent plus d’optionalité que n’importe quelle migration de serveur. ODF au lieu de .docx signifie que vos documents survivent à un changement de fournisseur. Une clé FIDO2 à 50 € élimine le vecteur d’attaque le plus courant. Si votre organisation ne l’a pas encore fait, tout le reste est prématuré.

2. Ne jamais auto-héberger ce que vous ne pouvez pas opérer

Une Nextcloud auto-hébergée sans sauvegarde est pire que Dropbox. Un Keycloak auto-hébergé sans correctifs est pire qu’Okta. Chaque service non surveillé que vous exploitez n’est pas un gain de souveraineté — c’est une surface d’attaque non surveillée. La règle est simple : si vous ne pouvez pas financer une astreinte pour un service, vous ne pouvez pas l’auto-héberger. Utilisez un fournisseur managé européen — Keycloak managé, Nextcloud managé, Matrix managé, tout cela existe. La souveraineté n’exige pas d’exploiter le serveur soi-même ; elle exige de garder les données sous une juridiction que vous contrôlez.

3. Distinguer la souveraineté des données de la souveraineté logicielle

Ce sont des problèmes différents avec des solutions différentes. La souveraineté des données — s’assurer que vos données restent sous une juridiction que vous pouvez faire appliquer — est réalisable même avec des logiciels propriétaires. Le modèle français Bleu (logiciel Microsoft sur infrastructure contrôlée par la France) le démontre. La souveraineté logicielle — s’assurer que vous ne dépendez pas de la feuille de route d’un seul fournisseur — nécessite l’open source. Vous pouvez avoir besoin de l’une, de l’autre, ou des deux, selon votre modèle de menace. Les confondre mène à de mauvaises décisions.

4. L’hybride est l’architecture cible, pas un compromis

Aucune migration réussie sur ce site n’a atteint 100 % de souveraineté — et aucune n’a essayé. La Gendarmerie a conservé 3 % sous Windows. Le Schleswig-Holstein reconnaît des exceptions permanentes. L’Autriche a conservé Teams pour les réunions externes. Ce ne sont pas des concessions ; ce sont des choix d’architecture.

Une architecture hybride avec des critères documentés — « ces systèmes sont souverains, ceux-là sont managés, voici pourquoi » — est plus résiliente que la dépendance totale ou l’indépendance totale sous-financée. L’objectif n’est pas zéro logiciel américain. L’objectif est aucun point de défaillance unique : aucun fournisseur dont la disparition arrête vos opérations.

5. Mesurer la souveraineté par la résilience, pas par la pureté

Le test d’une stratégie de souveraineté n’est pas « utilisons-nous un logiciel américain ? » C’est : « que se passe-t-il si notre plus gros fournisseur devient indisponible demain ? » Si la réponse est « nous basculons vers une alternative documentée en quelques jours ou semaines », votre stratégie de souveraineté fonctionne — même si vous utilisez actuellement des services hyperscaler. Si la réponse est « l’administration s’arrête », votre stratégie de souveraineté a échoué — même si chaque serveur tourne sous Linux.

La résilience est l’objectif. La souveraineté est la méthode. Ne confondez pas les deux.

Les cinq modes d’échec de la souveraineté

L’argument pour la réduction de la dépendance envers les fournisseurs non européens est solide — le risque de concentration est réel, la dépendance économique est mesurable, et les alternatives sont de plus en plus viables. Mais le mouvement pour la souveraineté a des modes d’échec récurrents qui sapent ses propres objectifs. Cinq méritent d’être nommés :

Le théâtre de la souveraineté. Déployer un outil open source et déclarer victoire, sans financer l’équipe d’exploitation qui le maintient en fonctionnement. L’outil est là, non corrigé, non surveillé, et moins sûr que le service propriétaire qu’il a remplacé. La case est cochée. Le risque a augmenté.

La pureté à 100 % comme objectif. Refuser d’utiliser tout service basé aux États-Unis, quel que soit le coût opérationnel, ce qui conduit à des alternatives sous-financées pour chaque système au lieu d’alternatives bien financées pour les systèmes qui comptent. Le parfait est l’ennemi du bien — et en infrastructure, le parfait est souvent l’ennemi du fonctionnel.

Ignorer l’utilisateur. Le retournement de LiMux à Munich était politique, mais le cas politique s’est construit sur de vraies plaintes d’utilisateurs. La souveraineté qui dégrade l’expérience quotidienne des personnes qui utilisent les systèmes génère de la résistance — et cette résistance trouvera tôt ou tard un véhicule politique. L’expérience utilisateur n’est pas un luxe ; c’est un prérequis de durabilité.

Supposer qu’européen signifie digne de confiance. Une entreprise européenne est soumise au droit européen — ce qui est un véritable avantage structurel pour la souveraineté des données. Mais « européen » n’est pas un label de qualité. Les logiciels européens peuvent être mal maintenus. Les fournisseurs européens peuvent avoir une sécurité inadéquate. Les startups européennes peuvent être rachetées par des entreprises non européennes, comme l’a démontré l’affaire DigiD/Solvinity. Évaluez les fournisseurs sur leurs compétences et leur gouvernance, pas seulement sur leur juridiction.

Sous-estimer les coûts de transition. Chaque article de ce site comporte une dimension « honnête sur les compromis ». Mais les coûts de transition agrégés — migrer cloud, bureautique, messagerie, identité, système d’exploitation et IA simultanément — sont énormes. Les organisations qui tentent de tout faire en même temps ne font typiquement rien de bien. La Gendarmerie a mis vingt ans. Le Schleswig-Holstein prévoit cinq à sept ans. Ces délais ne sont pas des signes de lenteur ; ce sont des signes de sérieux.

Ce qui suit

L’indépendance numérique est une stratégie de gestion des risques. Comme toute gestion des risques, elle implique des compromis. Éliminer un risque (la dépendance fournisseur) peut en introduire un autre (la fragilité opérationnelle). Les organisations qui naviguent avec succès ne sont pas celles qui poursuivent la souveraineté de la manière la plus agressive — ce sont celles qui la poursuivent de la manière la plus intelligente.

La séquence pratique, intégrant les limites ci-dessus :

Commencer immédiatement (coût nul, risque nul) :

• Passer aux formats de documents ouverts. Enregistrer en ODF, pas en .docx. C’est l’étape de souveraineté la plus impactante, et elle ne coûte rien. Chaque migration ultérieure devient plus facile quand vos données sont en formats ouverts.
• Déployer des clés FIDO2 matérielles pour les administrateurs et les dirigeants. 50 € par clé. Améliore la sécurité et la souveraineté. Aucun surcoût opérationnel.
• Auditer vos dépendances fournisseurs. Associer chaque système critique à son fournisseur, sa juridiction et son alternative. Vous ne pouvez pas gérer un risque que vous n’avez pas mesuré.

Commencer ce trimestre (risque faible, retour élevé) :

• Déployer LibreOffice dans toute l’organisation. Le Schleswig-Holstein et l’armée italienne ont commencé par là. Aucune infrastructure requise. L’écart de compatibilité documentaire est gérable avec de la planification.
• Évaluer un fournisseur cloud européen pour les nouveaux workloads. Ne migrez pas les systèmes existants. Déployez le prochain nouveau projet chez Hetzner, Scaleway ou un fournisseur certifié SCS. Construisez l’expérience avant d’en avoir besoin.

Planifier en mois (effort modéré, investissement en équipe nécessaire) :

• Piloter Nextcloud, Element ou Keycloak — mais uniquement si vous pouvez engager la capacité opérationnelle. Un pilote qui meurt de négligence ne vous apprend rien. Budgétez le temps du personnel avant de déployer le logiciel.
• Si l’auto-hébergement n’est pas réaliste, utilisez un fournisseur managé européen. Keycloak managé, Nextcloud managé, Matrix managé — cela existe, et ce sont des choix de souveraineté légitimes. Vous n’avez pas besoin d’exploiter le serveur vous-même pour garder les données sous juridiction européenne.

Accepter et gérer (en continu) :

• Certains systèmes resteront chez l’hyperscaler. CDN global, API IA de pointe pour des tâches non sensibles, services managés spécialisés sans équivalent européen — ce sont des choix rationnels, pas des échecs de souveraineté. Documentez-les. Assurez des clauses de sortie. Réévaluez annuellement.
• L’hybride est l’état stable. L’objectif n’est pas 100 % de souveraineté — c’est suffisamment de souveraineté pour qu’aucune perturbation isolée ne soit catastrophique. Une stratégie hybride consciente et documentée est plus résiliente que la dépendance totale ou l’indépendance totale sous-financée.

Les organisations qui surmonteront la prochaine disruption — qu’il s’agisse d’un changement de licence, d’une extension de sanctions, d’une hausse de prix ou d’une acquisition — ne sont pas celles qui ont remplacé chaque service américain. Ce sont celles qui ont réduit leur dépendance au point où toute perturbation isolée est un désagrément, pas une catastrophe. Elles y sont parvenues en investissant là où cela comptait le plus — pas en étalant les ressources sur tout.

L’administration de district de l’introduction a appris cela à ses dépens : la souveraineté sans investissement opérationnel n’est qu’une autre forme de fragilité. La Gendarmerie l’a appris en vingt ans : la souveraineté avec investissement se capitalise en véritable indépendance. La différence entre les deux n’est pas la conviction — c’est la capacité.

L’indépendance numérique n’est pas une destination. C’est une capacité — la capacité de changer, de s’adapter, d’absorber une disruption sans que vos opérations s’arrêtent. Construisez cette capacité là où elle compte. Louez le reste. Et soyez honnête sur ce qui est quoi.

Commencez par notre aperçu : Pourquoi digital-independence.org ?