Vous avez ouvert un ticket de bug hier. Un problème de marge dans le moteur de rendu de document, quinze lignes de contexte, deux captures d’écran. Vous l’avez signé de votre vrai nom. Votre profil GitHub l’affiche ; le projet, une initiative européenne de souveraineté, vous a semblé exactement le type de travail qui mérite une signature.

Ce matin, votre carte bancaire ne fonctionne plus.

La séquence n’est pas, aujourd’hui, documentée. C’est la forme d’une séquence que les dix-huit derniers mois ont rendue progressivement plus plausible. Le 5 mai 2025, le compte Microsoft 365 de Karim Khan, procureur en chef de la Cour pénale internationale, a cessé de fonctionner après que l’administration Trump l’a désigné nominativement au titre du décret exécutif 14203. En mai 2026, Microsoft a remis les données personnelles et les communications de fonctionnaires néerlandais — des régulateurs chargés d’appliquer le règlement européen sur les services numériques — à une assignation du Congrès américain. Dans les deux cas, les personnes concernées avaient choisi un prestataire domicilié aux États-Unis des années plus tôt, sur la base d’un achat institutionnel raisonnable. La conséquence politique était une propriété de la chaîne d’approvisionnement qu’elles n’avaient pas auditée.

Aujourd’hui, une alliance d’entreprises européennes lance une alternative à Microsoft 365. Le communiqué parle d’un jalon pour la souveraineté numérique européenne. Le code source est hébergé par Microsoft. Le pipeline de build tourne sur les serveurs de Microsoft. Les images de conteneurs sont distribuées via le registre de conteneurs de Microsoft. Chaque contribution est consignée dans la base de Microsoft à l’instant où elle est faite — sous votre vrai nom.

Ce n’est ni une fuite, ni un scandale, ni un oubli. Les dépôts Euro-Office à github.com/euro-office sont publiquement observables. L’alliance derrière ce lancement — IONOS, Nextcloud, EuroStack, Open-Xchange, XWiki, OpenProject et six autres organisations européennes respectées de l’OSS — a choisi cet hébergement délibérément, et continue de le juger approprié. La couverture de la presse spécialisée du lancement n’en parle pas. Les communications de lancement n’en parlent pas. Le paquet souveraineté tech de la Commission européenne, rédigé en parallèle, ne l’aborde pas.

Il faut le dire sans détour : c’est absurde. Pas au sens courant de surprenant — à lecture posée de la documentation publique, c’est exactement ce à quoi on devait s’attendre — mais au sens où toute définition standard de souveraineté numérique que le discours européen a produite ces quatre dernières années est incompatible avec ce qui vient de se passer. Soit Euro-Office n’est pas un produit de souveraineté, soit les définitions de souveraineté en circulation ne sont pas cohérentes. Le lancement impose un choix.

La version utile de cet article n’est pas l’indignation, qui s’écrit toute seule. C’est l’audit, le recadrage, et la question d’achat public qui découlent de l’acceptation du fait que le discours actuel sur la souveraineté comporte une erreur portante en son centre — et que le ticket de bug que vous avez ouvert hier fait, à échéance suffisamment longue, partie de la piste d’audit.

Ce qui démarre

Euro-Office publie sa v1.0 le mardi 9 juin 2026. L’alliance qui le porte est techniquement cohérente : IONOS héberge la variante cloud managé depuis Karlsruhe, Nextcloud intègre la suite dans Hub 26 comme remplaçante par défaut de Collabora, Open-Xchange apporte l’héritage groupware, et XWiki, OpenProject, Soverin, Abilian, BTactic et Office.eu contribuent aux couches adjacentes de collaboration et d’hébergement.

Les quatre dépôts principaux à github.com/euro-office — eurooffice-nextcloud (PHP, AGPL-3.0), server (JavaScript, AGPL-3.0), sdkjs-forms (JavaScript, AGPL-3.0) et document-templates (Apache-2.0) — adoptent la posture de licence défensive qui convient à un logiciel hébergé comme service : tout fournisseur commercial proposant un Euro-Office hébergé doit publier ses modifications. L’Apache-2.0 sur les modèles est le bon choix pour du contenu. C’est la combinaison de licences la plus forte du marché européen des suites bureautiques OSS, matériellement plus forte que la MPL-2.0 de Collabora Online ou que l’AGPL mono-éditeur d’OnlyOffice.

La compatibilité avec Office Open XML tient sur les charges de travail qui faisaient historiquement échouer les migrations bureautiques OSS européennes : classeurs Excel multi-feuilles avec tableaux croisés dynamiques, documents Word avec suivi des modifications et commentaires, PowerPoint avec animations intégrées. Les options de déploiement disponibles couvrent le cloud managé, l’hybride et l’auto-hébergement Docker ou Kubernetes, sur le Proxmox ou le VMware du client. L’histoire de souveraineté à l’exécution est réelle : données dans des centres allemands, licence protégée contre tout fork propriétaire, indépendance des formats vis-à-vis du calendrier de release de Microsoft.

Il n’y a pas d’astérisque sur cette partie. Le produit est bon. La décision d’achat en tant que décision produit est défendable.

L’audit

La décision d’achat en tant que décision de souveraineté est l’endroit où l’architecture cesse de coopérer.

Chaque commit sur chaque dépôt Euro-Office, chaque ticket, chaque pull request, chaque exécution de pipeline CI/CD, chaque build d’image de conteneur et chaque artefact de release transite par github.com. GitHub est une filiale à 100 % de Microsoft depuis juin 2018. Les communications de lancement n’abordent pas ce point. La couverture de la presse spécialisée du lancement non plus. L’alliance ne s’est pas engagée sur un miroir Codeberg ou Forgejo, et n’a pas annoncé son intention d’opérer un pipeline de build hors des États-Unis.

Ce n’est pas un problème contractuel — la licence AGPL préserve le droit de mettre en miroir, de forker et de reconstruire — c’est un problème opérationnel. Le droit de mettre en miroir ne vaut rien tant que le miroir n’existe pas.

Le précédent d’application est documenté et précis. En juillet 2019, GitHub a restreint l’accès aux dépôts privés et aux comptes d’organisation payants des développeurs en Iran, en Syrie et en Crimée, en conformité avec les sanctions de l’OFAC. Les projets privés ont disparu du jour au lendemain. Les dépôts publics sont restés accessibles en lecture seule, mais l’infrastructure de travail — suivi des tickets, pull requests, GitHub Actions, images de conteneurs, distribution des paquets — était indisponible pour les comptes concernés jusqu’à ce que GitHub obtienne une licence OFAC pour rétablir le service aux développeurs iraniens en janvier 2021. En mars et avril 2022, le même mécanisme s’est appliqué aux entités russes et aux parties occupées de l’Ukraine sous désignation OFAC. Les comptes liés à des entités sanctionnées ont perdu leur accès ; les comptes d’organisation payants situés en Crimée, à Donetsk et à Louhansk sont restés restreints. Les politiques d’utilisation acceptable de GitHub citent toujours la conformité au contrôle américain des exportations comme règle de gouvernance.

La probabilité que ce mécanisme d’application s’applique à un Stadtwerke allemand ou à un établissement public français au cours d’un trimestre donné est faible. La probabilité sur un horizon d’achat public de cinq ans, contre une stack Euro-Office comportant plusieurs centaines de dépendances OSS amont maintenues à l’échelle mondiale, est matériellement supérieure à zéro. Le taux de base pertinent n’est pas celui des cas médiatisés — Iran, Russie, Crimée — mais la longue traîne : une seule dépendance critique, hébergée par un seul développeur dans une seule juridiction qui devient pertinente pour l’OFAC pour l’une parmi des dizaines de raisons plausibles en cinq ans. La plupart de ces événements n’affecteront pas les adoptants d’Euro-Office. Certains, si.

Il existe une seconde catégorie d’exposition de la chaîne d’approvisionnement, opérationnellement plus probable que l’application des sanctions : la pression politique sur l’opérateur de la plateforme qui produit une conformité volontaire. Le schéma de conformité Microsoft 2025-2026 — la suspension du courriel du procureur de la CPI en mai 2025 après les sanctions américaines, la transmission volontaire des noms du régulateur néerlandais au Congrès américain en mai 2026 — relève de cette colonne. Quand un fournisseur de services domicilié aux États-Unis fait face à une pression politique américaine, la réponse est la conformité, pas la résistance. GitHub, c’est la même architecture. Une future administration américaine qui déciderait que les projets de souveraineté européens méritent son attention n’aurait pas besoin de l’OFAC. Les politiques d’utilisation acceptable de GitHub suffisent comme motif de restriction, à la discrétion de la plateforme elle-même.

La conclusion de l’audit est simple et peu flatteuse : une adoption d’Euro-Office sans SBOM, sans infrastructure de miroir et sans plan de continuité n’est pas architecturalement plus souveraine que le déploiement M365 qu’elle remplace. Elle est contractuellement plus souveraine — les données sont à Karlsruhe, la licence est AGPL — mais la chaîne d’approvisionnement aboutit à la même plateforme de dépôts détenue par Microsoft que ne le ferait la distribution du code source de M365, si ce code source était disponible — ce qui n’est pas le cas.

Les personnes dans l’audit

L’argument architectural jusqu’ici a traité le risque de manière institutionnelle — ce qui arrive à un Stadtwerke, ce qui arrive à une décision d’achat. Le même argument prend une autre allure quand on part de personnes dont les noms sont documentés.

Prenons Khan d’abord. La CPI est une institution internationale permanente dont le siège est à La Haye, hors juridiction américaine. Les communications de son procureur en chef étaient sur Microsoft 365 parce que la Cour avait pris la même décision d’achat que tout autre grand acheteur public européen à la même époque, sur les mêmes bases raisonnables-à-l’époque. Quand l’administration Trump a désigné Khan au titre du décret exécutif 14203 en février 2025, ni le procureur ni la Cour n’avaient d’option opérationnelle digne de ce nom : Microsoft est une entreprise domiciliée aux États-Unis, l’obligation OFAC est contraignante, la suspension a suivi. La décision d’achat avait été prise des années plus tôt ; la conséquence est arrivée en mai, nominative et personnelle.

Le cas ACM/AP diffère de celui de Khan sur un point. Il n’y avait pas de décret exécutif. L’assignation est venue de la sous-commission Weaponization du Comité judiciaire de la Chambre, présidée par Jim Jordan, dont le mandat affiché est d’examiner ce qu’elle appelle « foreign censorship of American speech » — une formulation qui, par son propre cadrage, englobe le règlement européen sur les services numériques et le travail des fonctionnaires de l’Autorité néerlandaise pour les consommateurs et les marchés (ACM) et de l’Autoriteit Persoonsgegevens (AP), dont Microsoft a remis les noms. La secrétaire d’État néerlandaise à la souveraineté numérique, Willemijn Aerdts, a convoqué l’ambassadeur américain le vendredi où la divulgation est devenue publique. Les données étaient déjà en route. La conformité de Microsoft était volontaire au sens juridique — l’entreprise répondait à une assignation, pas à un ordre de l’OFAC — et opérationnellement inévitable de la manière dont le serait la conformité de n’importe quel prestataire domicilié aux États-Unis sous la même pression politique.

Ni Khan, ni les agents de l’ACM et de l’AP n’ont choisi de se retrouver à la surface d’une pression politique américaine. Ils ont choisi Microsoft comme prestataire, des années plus tôt, sur la base d’un achat institutionnel parfaitement raisonnable. La surface politique était une propriété de la chaîne d’approvisionnement qu’ils n’avaient pas auditée.

C’est la couche sur laquelle les contributeurs et adoptants d’Euro-Office se trouvent désormais.

Chaque développeur qui ouvre une pull request contre github.com/euro-office crée un enregistrement dans la base de données de Microsoft qui lie son identité personnelle — nom légal sur la plupart des comptes, adresse de courriel réelle, adresse IP par session, motifs temporels de contribution — à une participation active à un projet européen de souveraineté numérique que des éléments du Congrès américain ont publiquement présenté comme adverse aux intérêts commerciaux américains. L’emploi quotidien du contributeur, son employeur, son pays de résidence et son affiliation politique sont inférables de l’historique public des commits. Aujourd’hui, ce cadrage est rhétorique. Le cas Khan et le cas ACM/AP démontrent que l’écart entre cadrage rhétorique et conséquence personnelle est, au plus, de la largeur d’un décret exécutif.

Chaque administration publique qui adopte Euro-Office hérite, par transitivité, de la même chaîne de journalisation. Chaque responsable informatique qui commente un ticket amont voit sa position professionnelle publiquement liée au projet. Chaque développeur d’un Stadtwerke qui ouvre un ticket de bug voit son identité enregistrée dans la piste d’audit de Microsoft. Le RSSI municipal qui écrit à l’alliance pour une clarification sécurité, le délégué à la protection des données qui pose une question sur un cas limite de conformité à l’export — chaque interaction est enregistrée sous un vrai nom, sur une infrastructure détenue par l’entreprise dont le projet est censé l’éloigner.

Rien de tout cela n’est malveillant de la part de Microsoft. C’est la mécanique de base d’un service d’hébergement de code. C’est aussi la mécanique de base d’une future assignation. Le cas Khan montre ce qui arrive quand un décret exécutif américain nomme un individu. Le cas ACM/AP montre ce qui arrive quand une assignation du Congrès américain nomme une catégorie. Dans les deux cas, les personnes concernées l’ont appris après que Microsoft s’était déjà mis en conformité.

L’implication stratégique est sans sentimentalisme. Quiconque — individuellement ou institutionnellement — participe au projet européen de souveraineté au niveau contributeur ou adoptant pendant qu’il est hébergé sur l’infrastructure de Microsoft crée une piste d’audit sous son propre nom, sur la plateforme de la partie dont le projet est censé réduire la dépendance. La piste est en train d’être créée aujourd’hui, en temps réel, à chaque commit et à chaque commentaire de ticket. La partie qui a accès à la piste n’a pas besoin d’agir sur elle pour qu’elle soit porteuse — il suffit qu’elle existe.

Orwell aurait apprécié l’architecture. Un mouvement s’organise pour réduire sa dépendance à une entité. Pour y parvenir, chaque participant signe sa contribution, sous son vrai nom, sur une plateforme détenue par cette entité. L’entité conserve les signatures indéfiniment, indexables, exportables sur demande légale. Que l’entité agisse un jour sur elles est, à moyen terme, secondaire ; que l’architecture lui permette d’agir sur elles est, à moyen terme, décidé. C’est décidé maintenant, à chaque ticket, par tous ceux qui cliquent sur envoyer.

La souveraineté n’est pas ce que l’on achète

C’est le recadrage que le lancement rend difficile à éviter.

L’industrie des marchés publics a entraîné la question à devenir un problème de sélection de fournisseur. Le RGPD, le CLOUD Act, le paquet souveraineté tech, l’amendement §58 VgV, le modèle de maturité ES³ — tous ces instruments acceptent l’hypothèse que la souveraineté est une propriété que l’acheteur acquiert en choisissant le bon fournisseur. ES³ certifie des fournisseurs. CADA classe des fournisseurs. Le §58 VgV permet aux acheteurs de préférer certains fournisseurs. Les instruments sont cohérents à l’intérieur de l’hypothèse.

Le lancement d’Euro-Office est le cas le plus net où l’hypothèse échoue visiblement. Le produit est la meilleure réponse disponible à la question fournisseur. L’adopter sans travail architectural change le fournisseur sur la ligne du marché public et laisse la dépendance réelle inchangée. Le fournisseur sur la ligne est désormais européen ; la chaîne d’approvisionnement dont il dépend ne l’est pas. L’acheteur a acquis l’apparence de la souveraineté sans la substance, et la substance — la continuité de la chaîne d’approvisionnement — n’a jamais été à vendre dans le contrat d’achat.

La souveraineté, au sens qui compte pour la question que les acheteurs publics et privés régulés cherchent effectivement à résoudre, n’est pas une propriété des fournisseurs. C’est une propriété des architectures. Une organisation est numériquement souveraine dans la mesure où elle peut continuer à fonctionner quand n’importe quel maillon de sa chaîne d’approvisionnement logicielle devient indisponible. Cette propriété se construit, elle ne s’achète pas. La décision fournisseur est en amont ; le travail pour devenir souverain est en aval. Sauter le travail en aval et appeler la décision en amont une réponse de souveraineté, voilà l’erreur que le lancement d’Euro-Office rend impossible à ignorer.

La conséquence pratique : la stack Microsoft 365 et la stack Euro-Office ne sont pas structurellement différentes sur la dimension chaîne d’approvisionnement. Elles diffèrent sur la dimension d’exécution (localisation des données, juridiction de l’opérateur) et elles diffèrent sur l’option de construire une indépendance de la chaîne d’approvisionnement. M365 ferme l’option ; Euro-Office la préserve. Mais préserver une option, ce n’est pas l’exercer. L’exercice, c’est le travail.

La question d’achat qui compte vraiment

Si la question de la souveraineté est correctement architecturale, la question d’achat suit. Il ne s’agit plus de à quel fournisseur achetons-nous ? mais de : quelle est notre architecture d’indépendance, et où se situe-t-elle dans notre compte de résultat ?

Trois chantiers répondent à la question recadrée. Ils ne sont pas optionnels, ils ne sont pas « confortables à avoir », et tout achat public au nom de la souveraineté qui les omet est une performance d’achat, pas une décision d’achat.

Un : l’inventaire. Un audit Software Bill of Materials des composants OSS actuellement en production, étendu à tout système avec une exposition à l’exécution à internet ou aux données client. Sortie par composant : point de distribution principal, licence, profondeur de l’arbre de dépendances, juridiction du mainteneur. Pour une organisation de taille moyenne exploitant 50 à 80 composants OSS distincts en production, l’audit prend 6 à 10 semaines et coûte 25 000 à 55 000 € auprès d’un spécialiste externe. Le livrable est une liste, pas un plan ; le plan se déduit de la liste. La plupart des organisations découvrent que 80 % de leur exposition de chaîne d’approvisionnement se concentre dans 15 % de leurs composants, et que la concentration n’est pas là où elles l’attendaient.

Deux : l’infrastructure de miroir. Une instance auto-hébergée de Forgejo, synchronisée de manière bidirectionnelle avec GitHub pour les composants critiques identifiés dans le chantier un. Hébergée sur l’infrastructure existante (Proxmox, VMware ou une VM Hetzner), deux VM, séparées de la production. Le coût en trésorerie est négligeable ; le travail représente 8 à 15 jours-personne d’architecte sur douze semaines, selon le nombre de dépôts. Le miroir ne remplace pas GitHub pour le développement quotidien ; il survit à GitHub pour la continuité. Codeberg peut se substituer là où l’auto-hébergement de Forgejo ne se justifie pas.

Trois : le pilote. Un pilote Euro-Office cadré sur un flux de travail sans exposition au public — finance, RH internes, groupware contrôlé — couvrant 6 à 12 mois avec des critères go/no-go explicites liés à l’atteinte par l’infrastructure de miroir d’une fiabilité de qualité production. Coût : 8 000 à 20 000 € en support de mise en place auprès d’un partenaire Nextcloud, plus le temps interne. Le pilote valide le produit ; les chantiers un et deux valident la souveraineté.

Un acheteur qui mène les trois a acheté Euro-Office et construit la souveraineté. Un acheteur qui ne mène que le chantier trois a acheté un fournisseur différent. La décision d’achat est la même dans les deux cas. La décision d’architecture ne l’est pas.

La question du positionnement stratégique pour les douze prochains mois n’est pas de savoir si Euro-Office est le bon produit. C’est de savoir si votre organisation est prête à traiter la souveraineté comme une architecture plutôt que comme un achat public — et si votre conseil, vos auditeurs et votre régulateur accepteront la réponse architecturale comme réponse de souveraineté. Ils le feront, de plus en plus. Le paquet souveraineté tech propose une classification de niveau CADA d’ici 2027. ES³ certifie déjà la méthodologie plutôt que les produits. Les signaux de la couche réglementaire convergent vers l’architecture, pas vers le logo du fournisseur. Le logo du fournisseur est l’indicateur retardé ; l’architecture est l’indicateur avancé.

Ce que cet article n’est pas

Ce n’est pas l’affirmation qu’Euro-Office est le mauvais choix. Le produit est la plus solide alternative open source à M365 sur le marché européen. Ce n’est pas l’affirmation que GitHub bloquera les développeurs de l’UE. C’est l’affirmation que la souveraineté en tant que catégorie d’achat est le mauvais cadre, que le lancement d’Euro-Office en est l’exemple le plus net disponible, et que le travail que ce cadre a masqué est la réponse réelle à la question que les acheteurs publics et privés régulés cherchent à poser.

Sources

Aperçu thématique : Souveraineté numérique en Europe Articles connexes : Paquet souveraineté tech UE, Microsoft livre des noms néerlandais