Munich et l’open source : la stratégie sans Linux
Munich relance l’open source sans revenir à Linux : logiciels, économies, souveraineté et leçons pour les collectivités. Découvrez sa stratégie.
À Munich, l'open source revient par les infrastructures, pas par les PC
Pendant des années, Munich a été citée comme la ville qui aurait remplacé Windows par Linux à grande échelle. Puis la municipalité a changé de cap. Pour beaucoup, l'histoire s'est résumée à une idée simple : Linux n'aurait pas tenu la route dans l'administration. À mon avis, c'est une lecture trop courte. Selon Laura Dornheim, directrice du numérique de la ville, le retour à Windows ne vient pas d'un blocage technique. Il s'explique par un changement politique.
Aujourd'hui, Munich remet l'open source sur la table - sans relancer LiMux, et sans imposer une nouvelle migration générale des postes de travail. La stratégie est plus ciblée : remplacer certains logiciels propriétaires là où une alternative libre apporte un bénéfice clair, puis partager les outils développés grâce à des fonds publics. Autrement dit, l'enjeu ne se limite plus au système d'exploitation. Il porte sur les coûts, la maîtrise des dépendances et la capacité des collectivités à réutiliser ce qui existe déjà.
Cette approche mérite l'attention des administrations françaises et européennes. Elle montre qu'on peut faire avancer l'open source sans transformer un choix technique en bataille idéologique - et que, pour que ça tienne, le soutien politique compte autant que la qualité du code.
Munich ne relance pas LiMux : elle change de méthode
La nouvelle stratégie de Munich ne vise pas à réinstaller Linux sur tous les ordinateurs municipaux. La ville privilégie plutôt des briques d'infrastructure et de collaboration, là où elle peut comparer les solutions, chiffrer les coûts et organiser une transition sans bouleverser d'un coup les habitudes des agents.
Dans les changements annoncés, on retrouve le remplacement de VMware par Proxmox, de Jira et Confluence par OpenProject et XWiki, et l'adoption de PostgreSQL à la place d'Oracle pour les bases de données. Ces choix ne se valent pas : certains touchent à la virtualisation, d'autres à la gestion de projets, à la documentation ou aux bases de données. Mais ils se rejoignent sur un point concret : réduire la dépendance à des plateformes propriétaires quand une autre solution répond aux besoins de la ville.
Pourquoi commencer par l'infrastructure ?
Un poste de travail, c'est visible. Et c'est surtout étroitement lié au quotidien des utilisateurs : suite bureautique, formats de fichiers, raccourcis, support, formation. Une migration générale de Windows vers Linux, ce n'est donc pas seulement changer un système. Ça peut aussi impacter les processus administratifs, la compatibilité documentaire et des applications anciennes, dont personne ne connaît toujours toutes les dépendances.
L'infrastructure, elle, permet plus facilement de cadrer le périmètre. Ce n'est pas « facile » pour autant : une plateforme de virtualisation ou une base de données reste souvent au centre de plusieurs services. En revanche, on peut définir les critères de réussite projet par projet, prévoir un plan de coexistence, tester la compatibilité, mesurer les coûts et généraliser seulement après validation.
C'est une différence importante avec une transformation pensée comme un grand basculement. Changer une brique à la fois ne supprime pas le risque : ça le rend plus visible et plus facile à piloter. Si une solution ne convient pas, l'organisation le découvre sur un périmètre limité plutôt qu'après une migration généralisée.
Les économies comptent, mais elles ne racontent pas toute l'histoire
Les deux migrations annoncées sur les outils d'infrastructure et de collaboration devraient permettre d'économiser environ 1,5 million d'euros ou davantage par an, selon les estimations rapportées. Laura Dornheim parle aussi d'économies annuelles autour d'un million d'euros. Les ordres de grandeur sont proches, mais ils peuvent refléter des périmètres ou des calculs différents - donc, sans les hypothèses, il ne faut pas additionner ces chiffres « au doigt mouillé ».
Dans tous les cas, une licence n'est qu'une ligne dans le budget. Une comparaison sérieuse doit intégrer la migration des données, l'intégration, la formation, l'assistance, l'hébergement, la sécurité et le maintien en conditions opérationnelles. Une solution libre peut réduire certaines dépenses récurrentes, mais elle ne rend pas l'exploitation gratuite. Il faut des équipes pour l'administrer (ou un prestataire), et un budget de maintenance réaliste.
Du coup, la question utile n'est pas seulement « combien coûte la licence ? ». Elle ressemble plutôt à : « combien coûte le service sur plusieurs années, et qu'est-ce qu'on obtient en échange ? ». La même logique vaut pour une grande métropole comme pour une mairie - même si, évidemment, les capacités et les moyens ne sont pas les mêmes.
Pourquoi la première migration a été annulée
L'histoire de LiMux commence en 2003 : le conseil municipal de Munich vote le passage à une distribution Linux adaptée aux besoins de la ville. Le projet prend de l'ampleur à partir de 2006. En décembre 2013, plus de 14 800 postes utilisent LiMux. À l'époque, une étude de l'Observatoire européen des logiciels libres de la Commission européenne estimait les économies liées à l'abandon de Windows à environ 11 millions d'euros.
Cette expérience a montré qu'une grande administration pouvait déployer Linux et des logiciels de bureautique libres à grande échelle. Elle a aussi mis en évidence la difficulté concrète d'un changement dans un environnement informatique ancien, avec des documents Microsoft Office, des applications métiers, des habitudes d'utilisateurs, des formats PDF et des procédures construites autour des outils existants.
Après les élections municipales de 2014, le contexte politique évolue. En novembre 2017, le conseil vote le retour à Windows, avec un objectif de migration fixé à 2020. Le remplacement de LibreOffice par Microsoft Office prend plus de temps et n'est achevé qu'en 2023.
Une décision technique peut être renversée par une décision politique
La lecture de Laura Dornheim est directe : LiMux n'a pas été abandonné parce que Linux « ne marchait pas ». Elle attribue le retour à Windows à la politique et aux priorités municipales qui changent. Elle cite notamment le fait que la nouvelle équipe a obtenu de Microsoft l'implantation du siège allemand de l'entreprise à Munich.
Au passage, il faut séparer deux questions qu'on confond souvent. La première est technique : le logiciel fonctionne-t-il réellement dans l'environnement visé ? La seconde est institutionnelle : l'organisation a-t-elle les moyens et la volonté de tenir dans la durée ? Une migration peut réussir opérationnellement et rester fragile si la majorité, la direction ou les budgets bougent.
C'est particulièrement utile pour les collectivités françaises. Si un projet de logiciel libre est présenté surtout comme une amélioration technique, il risque de perdre ses soutiens dès que les responsables changent. Pour durer, il doit aussi répondre à des priorités lisibles pour les élus et les directions : maîtrise des dépenses, continuité du service public, réutilisation des outils, sécurité et capacité à faire évoluer les applications.
Et non, ce n'est pas forcément « tout » ramener à la rentabilité immédiate. La maîtrise des données et la réduction d'une dépendance fournisseur ont de la valeur, même si ce n'est pas toujours facile à transformer en économies annuelles chiffrées. Mais il faut l'expliquer clairement, plutôt que compter sur l'étiquette « open source » pour faire le reste.
Une stratégie fondée sur des remplacements ciblés
La démarche actuelle s'inscrit dans un plan informatique plus large. Munich défend le principe « argent public, code public » : lorsqu'un logiciel est développé avec des financements publics, il devrait, quand c'est pertinent, pouvoir être consulté, utilisé et amélioré par d'autres. Bien sûr, ça ne veut pas dire que tout le code doit être publié sans exception. L'idée, c'est surtout de traiter la réutilisation comme une option à envisager dès la conception et l'achat.
En 2024, la ville a créé un bureau dédié aux programmes open source, l'Open Source Program Office. Son rôle est de structurer et de coordonner les initiatives. Munich présente son action autour de trois axes : utiliser des logiciels libres existants, contribuer à leur amélioration et publier les logiciels qu'elle développe elle-même.
Relier le choix technique aux objectifs de l'administration
Pour obtenir un soutien politique durable, Laura Dornheim recommande de rattacher l'open source aux sujets qui parlent aux élus : budgets, qualité des services publics et capacité à déployer des outils à l'échelle de l'administration. Le raisonnement est pragmatique : un logiciel libre n'est pas une fin en soi. Il doit résoudre un problème, et son modèle d'exploitation doit être soutenable.
Pour une collectivité qui envisage une migration, une grille d'analyse simple peut aider :
- Définir le besoin réel. Quels usages le logiciel doit-il couvrir ? Quelles contraintes métiers, réglementaires et d'accessibilité s'appliquent ?
- Cartographier les dépendances. Quels systèmes, formats, prestataires et processus s'appuient aujourd'hui sur l'outil actuel ?
- Comparer le coût complet. Inclure les licences, la migration, l'hébergement, l'assistance, la formation et la maintenance sur plusieurs années.
- Tester sur un périmètre maîtrisé. Vérifier les fonctions essentielles avec des utilisateurs représentatifs avant d'élargir.
- Organiser la continuité. Clarifier le support, les mises à jour de sécurité, la réversibilité et le financement des contributions.
- Présenter le résultat aux décideurs. Montrer les gains, les risques et les limites à partir de critères liés aux services rendus.
Ce cadre évite deux pièges classiques : migrer juste pour afficher une préférence technologique, ou rejeter une solution libre parce qu'elle ne reproduit pas exactement le parcours utilisateur d'un produit installé depuis quinze ans. Le vrai sujet reste le même : l'alternative répond-elle suffisamment bien au besoin, à un niveau de risque acceptable, pour un coût cohérent ?
Souveraineté numérique : une contrainte concrète, pas un slogan
La souveraineté numérique, c'est aussi une question de conformité et de contrôle. Munich a notamment évoqué des interrogations liées à un passage vers Azure sans garanties suffisantes sur la conformité au RGPD. Si les assurances contractuelles et opérationnelles ne sont pas satisfaisantes, la ville doit regarder plus finement : quels utilisateurs accèdent à quels outils, et avec quelles conditions.
Évidemment, ce type de précaution ajoute de la complexité. Il faut gérer les droits, évaluer les traitements de données et clarifier les responsabilités. Mais ça rappelle une réalité simple : choisir un service cloud, ce n'est pas seulement choisir des fonctionnalités ou un prix. Il faut aussi analyser les données, les accès, les obligations réglementaires et les conditions pour changer de fournisseur.
Pour les administrations européennes, la souveraineté ne se limite donc pas à « tout héberger dans un data center local ». Elle dépend aussi de la maîtrise des contrats, des identités, des opérations et des conditions de sortie. L'open source peut aider à reprendre la main, mais il ne garantit pas tout. In fine, la gouvernance et l'exploitation restent déterminantes.
Du logiciel utilisé au logiciel partagé
La nouvelle approche de Munich ne tourne pas seulement autour du changement de licences. La ville cherche aussi à devenir productrice et contributrice de logiciels publics. Ça implique un changement de posture : une administration n'est plus seulement « acheteuse » d'un outil. Elle peut financer du développement, améliorer ce qui existe, et permettre à d'autres organisations de s'en emparer.
DAVe, une application municipale pour documenter et analyser les données de circulation, illustre bien cette logique. Utilisé depuis 2021 à Munich, le logiciel a aussi été adopté par Wolfsburg. Le bénéfice peut alors dépasser la première collectivité : les coûts de développement peuvent être mutualisés, et des améliorations faites par une autre ville peuvent profiter à tout le projet.
Passer du partage opportuniste à une coopération organisée
Le partage ne se fait pas tout seul. Une autre ville doit découvrir le logiciel, vérifier qu'il correspond à ses besoins, comprendre comment l'installer, et disposer des ressources pour l'exploiter. Sans documentation, sans gouvernance claire et sans support identifié, publier du code ne suffit pas à créer une solution réellement réutilisable.
Laura Dornheim veut que les rapprochements entre collectivités deviennent plus systématiques, plutôt que de dépendre d'une rencontre « par hasard ». L'objectif est logique : si plusieurs administrations développent séparément des outils proches, elles financent potentiellement plusieurs fois la même brique. À l'inverse, une mutualisation mal organisée peut produire un projet sans responsable clair - et donc sans financement durable de la maintenance.
Pour éviter ces deux situations, un projet public partagé doit préciser au minimum : qui décide de la feuille de route, qui maintient le logiciel, comment sont traités les sujets de sécurité, quels types de contributions sont acceptés, et comment les utilisateurs financent les évolutions. Publier le code est une étape. La vraie question, c'est la capacité à maintenir le service.
L'IA municipale et le soutien aux mainteneurs
Munich travaille aussi sur MUCGPT, une application d'intelligence artificielle destinée aux agents municipaux, notamment pour utiliser des modèles de langage afin de rédiger ou relire des courriels. Cet exemple rappelle que l'open source ne reste pas cantonné aux outils « historiques ». Il peut aussi s'inscrire dans des usages plus récents - à condition que l'administration maîtrise les données, les conditions d'utilisation et les risques associés.
La ville soutient aussi l'écosystème via son programme Open Source Sabbatical, qui aide des développeurs à travailler sur des projets libres. Ce type d'initiative répond à un problème moins visible que le coût des licences : beaucoup de services dépendent de composants dont la maintenance repose sur des ressources limitées. Financer du temps de développement peut renforcer ces briques communes, au bénéfice direct des services municipaux qui les utilisent.
Les collectivités françaises peuvent s'inspirer de ces principes sans copier à l'identique les projets munichois. Une solution adaptée à une grande ville allemande ne répondra pas forcément aux contraintes d'une commune française, d'un département ou d'un opérateur public. Mais la méthode, elle, est transposable : repérer des besoins partagés, cartographier les logiciels existants et organiser la réutilisation dès le départ.
Conclusion : faire de l'open source un choix durable
Le retour de Munich vers l'open source n'est pas une revanche de LiMux. C'est une stratégie différente, fondée sur des remplacements ciblés, des économies attendues et des logiciels publics réutilisables. Et elle reconnaît une contrainte souvent sous-estimée : une décision technique ne dure que si elle bénéficie d'un soutien politique et d'un modèle d'exploitation crédible.
Pour une collectivité, la bonne question n'est donc pas « faut-il passer à l'open source ? », mais « quelles dépendances peut-on réduire, avec quels bénéfices, et qui finance la maintenance après le déploiement ? ». Commencez par un service précis, chiffrez le coût complet et associez dès le début les équipes techniques, les utilisateurs et les décideurs. C'est moins spectaculaire qu'un basculement général, mais c'est souvent plus simple à évaluer - et, surtout, plus facile à tenir.
Pour aller plus loin, consultez l'analyse de ZDNET sur la stratégie de Munich, puis identifiez un logiciel de votre organisation dont le coût, la dépendance fournisseur ou le potentiel de mutualisation mérite une étude.