Sortir de Microsoft : ce que le pilote danois aurait dû nous apprendre
L'arrêt du pilote danois de remplacement de Microsoft Office ne prouve pas l'absence d'alternative : faute de bilan public, la dépendance n'a pas été mesurée.
Quand le Danemark a interrompu son pilote de remplacement de Microsoft Office, certains y ont vu la preuve qu'aucune alternative crédible n'existe. Le pilote livre une autre leçon : une dépendance se mesure aussi quand une migration échoue, à condition d'en tirer un bilan.
Un pilote court, interrompu par les élections
Le 19 juin 2025, le ministère danois de la Numérisation lançait un pilote : trente-huit agents devaient remplacer Word par Collabora, une suite libre fondée sur LibreOffice, intégrée à F2, l'application de gestion des dossiers de l'éditeur danois cBrain. Il s'agissait d'éprouver la compatibilité des modèles de documents, le suivi des modifications, les tableaux et la conversion des fichiers Word.
Les utilisateurs ont signalé des problèmes de mise en forme, des pages blanches à l'ouverture de certains documents et des dysfonctionnements du suivi des modifications. Selon un porte-parole du ministère, le projet a été abandonné lorsque des élections ont été convoquées début 2026 ; rien n'établit que les difficultés signalées en soient la cause. La presse danoise l'a révélé en octobre : aucune reprise n'est prévue et l'évaluation initialement envisagée n'a pas eu lieu.
Cette lecture me paraît prématurée. La ministre présentait ce pilote comme un premier pas ; son périmètre restait étroit : le remplacement des outils Office au sein d'un seul outil métier, F2.
La dépendance se cache dans les usages ordinaires
Les incidents signalés touchent précisément les fonctions que le ministère avait désignées comme critiques dès le lancement. Une suite bureautique peut permettre de rédiger un document tout en restant difficile à substituer dans les processus administratifs.
Techniquement, F2 avait pu intégrer Collabora en remplacement des outils Office. Cette possibilité n'a pourtant pas suffi à garantir la continuité des usages. Disposer d'une alternative relève de l'architecture ; pouvoir l'utiliser se démontre dans les processus métiers.
Modèles accumulés depuis des années, styles, polices, macros, circuits de validation : ces dépendances ne figurent dans aucun inventaire logiciel. Un format normalisé ne garantit pas, à lui seul, la fidélité des documents d'une application à l'autre.
C'est là que se loge le coût de sortie. Il ne se limite pas aux licences et à la formation : il comprend l'adaptation des documents, la révision des processus, les développements nécessaires et le risque de perturbation. Pour un DSI, ces obstacles ne sont pas un motif d'abandon mais des éléments d'arbitrage. Encore faut-il les mesurer.
Un pilote sans bilan public produit peu de maîtrise
Une expérimentation de réversibilité ne se juge pas seulement à son résultat. Si elle réussit, elle prouve qu'une substitution est possible dans les conditions testées. Si elle échoue, elle doit révéler les obstacles, estimer l'effort nécessaire et distinguer ce qui se corrige de ce qui est structurel.
On objectera que le pilote a rendu son verdict : les fonctions testées, suivi des modifications et conversion, ont posé problème. C'est une information utile, mais ce n'est pas un bilan. Elle ne dit ni si ces défauts étaient corrigeables, ni ce que coûterait de les contourner, ni quels usages restaient substituables.
Ici, aucune évaluation n'a été publiée. Mikkel Flyverbom, professeur à la Copenhagen Business School, regrette que le ministère ne consigne pas ces enseignements pour les partager avec le reste du secteur public.
Dans mes travaux sur le capital de maîtrise, je distingue trois niveaux :
déclaré : la volonté politique de réduire une dépendance ;
mobilisable : une alternative disponible, intégrée, susceptible de répondre aux besoins ;
vérifié : la démonstration, en conditions réelles, qu'elle assure les usages indispensables.
Le Danemark a posé le niveau déclaré, et, selon mon analyse, l'intégration de Collabora dans F2 rendait l'alternative en partie mobilisable. Le pilote devait démontrer le niveau vérifié : la continuité des usages en conditions réelles. Les raisons du choix exclusif de Collabora restent inconnues et aucune comparaison n'a été publiée. Faute de bilan, la distance restant à parcourir demeure inconnue.
SIA Open : un autre projet, distinct et encore limité
Il serait inexact d'y voir un abandon général. Un projet distinct se poursuit : SIA Open, un poste de travail fondé sur des logiciels libres, développé par l'agence publique Statens IT. Depuis décembre 2025, moins de dix agents de l'autorité danoise de sécurité routière l'utilisent, et 30 à 50 autres doivent les rejoindre. Une fois la troisième version publiée en février 2027, les 166 organisations clientes de Statens IT pourront le commander.
Ce n'est ni le même périmètre, ni le même dispositif, et ce n'est pas un succès démontré à grande échelle. Mais cela montre qu'une souveraineté se construit par étapes, à condition que chacune produise des résultats exploitables.
Faire de la réversibilité une capacité vérifiable
Le point décisif est le bilan : il doit être exigé même quand un pilote s'arrête pour des raisons politiques ou budgétaires. Un pilote de sortie devrait suivre quatre temps :
Avant : définir les usages essentiels à préserver, les niveaux de service attendus, les critères d'acceptation et ce qui rend une incompatibilité bloquante.
Pendant : documenter chaque difficulté, mesurer son impact et évaluer les solutions possibles.
À l'arrêt, quelle qu'en soit la cause (élections, budget, échec) : un bilan obligatoire, rédigé avant la dissolution de l'équipe. Quels usages sont substituables ? Lesquels exigent des adaptations, à quel coût, dans quels délais, avec quels risques résiduels ?
Après : conserver ce bilan et, lorsque c'est possible, le partager avec les autres administrations.
Maintenir provisoirement la solution existante peut rester un arbitrage légitime : la souveraineté ne consiste pas à imposer une migration quelles qu'en soient les conséquences.
Le cas danois pose une question qu'il ne résout pas : qui décide d'arrêter un pilote, sur quels critères, et avec quelle obligation de restituer ses enseignements ? Je défendrais une règle simple : toute décision d'arrêt s'accompagne d'un bilan daté et publié, ou d'une justification publique de son absence. Un changement de gouvernement ne devrait pas suffire à effacer ce qu'une expérimentation a appris.
Le droit d'échouer, à condition de savoir pourquoi
Les administrations doivent pouvoir expérimenter, se tromper et parfois renoncer. L'erreur serait de voir dans chaque pilote interrompu la preuve de l'inutilité des alternatives libres. L'erreur inverse serait de minimiser les problèmes rencontrés au nom de la légitimité de l'objectif.
Le Danemark n'a pas démontré qu'il était impossible de se passer de Microsoft. Il a laissé une expérimentation sans le bilan qui aurait permis de conclure. La réversibilité ne se décrète pas : elle se prépare, se mesure et se vérifie.
Un pilote qui échoue peut renforcer le capital de maîtrise d'une organisation. Un pilote interrompu sans bilan public laisse sa dépendance intacte.
Sources
cBrain, communiqué du lancement du pilote (juin 2025)
Xenospectrum, bilan du pilote et SIA Open
Clubic, choix exclusif de Collabora
Observatoire européen de l'open source, SIA Open
Amoledo, propos du professeur de la CBS
Ministère danois de la Numérisation, communiqué du 19 juin 2025