Les Pays-Bas lancent leur plateforme GitHub indépendante pour se libérer de la dépendance à Microsoft

Le 24 avril 2026, les Pays-Bas ont mis en ligne code.overheid.nl, une forge Git auto-hébergée destinée aux administrations, avec une promesse simple : reprendre la main sur l’hébergement du code source public et réduire l’exposition à des acteurs soumis au droit américain. L’information, attribuée à Interoperable Europe, met en avant une stratégie de souveraineté numérique qui dépasse le symbole : dans un État moderne, le dépôt Git est devenu une brique d’infrastructure au même titre qu’un annuaire, une messagerie ou un service d’identité. La démarche vient de l’Open Source Program Office du ministère de l’Intérieur néerlandais (MinBZK) et s’inscrit dans un mouvement européen qui, depuis plusieurs années, cherche à encadrer la supply-chain logicielle des services publics.

Le choix de Forgejo, un projet open source entièrement libre, tranche avec une logique “open-core” souvent retenue pour accélérer le déploiement. Le sujet n’est pas uniquement idéologique : l’industrialisation du développement (CI/CD, signatures, revue de code, gestion des vulnérabilités) transforme l’outil de forge en point névralgique. Les Pays-Bas envoient donc un signal concret, au moment où GitHub, propriété de Microsoft depuis 2018 pour 7,5 milliards de dollars, consolide sa place dans l’écosystème du géant américain, notamment via l’IA et les services cloud.

Pourquoi les Pays-Bas considèrent GitHub comme un risque souverain et technique

La rationalité d’un État face à GitHub tient à deux plans : le droit applicable et la surface d’attaque. Sur le plan juridique, le gouvernement néerlandais pointe des textes américains régulièrement cités dans les politiques de souveraineté numérique : la FISA Section 702, qui encadre certains accès aux données par les agences de renseignement américaines, et le CLOUD Act, qui étend la portée d’injonctions à des données sous contrôle d’entreprises américaines, y compris si les serveurs sont situés hors des États-Unis. Dans une lecture “risque” (et non “intention”), l’enjeu n’est pas de présumer un accès systématique, mais d’admettre qu’une contrainte légale extraterritoriale peut exister.

Dans ce contexte, l’hébergement d’un dépôt de code public paraît anodin, jusqu’au moment où il ne l’est plus. Les dépôts contiennent des historiques, des discussions, des tickets, parfois des chemins d’intégration (pipelines, scripts, dépendances) qui révèlent des structures internes. Même en open source, l’agrégation de ces signaux constitue une cartographie utile pour un attaquant, ou un tiers cherchant à reconstituer une chaîne de dépendances. Pour un gouvernement, le “risque souverain” devient très concret quand la forge est aussi le point d’entrée des contributions, des audits et du suivi de sécurité.

Un deuxième argument, plus moderne, concerne l’IA. Le code public hébergé sur GitHub sert de matière première à l’entraînement et à l’amélioration de services comme GitHub Copilot, produit de Microsoft. La question n’est pas de contester l’existence de licences open source, mais de rappeler qu’un État peut juger inacceptable que son patrimoine logiciel, même publié, alimente indirectement une offre commerciale sous contrôle d’un acteur unique. Le débat est particulièrement sensible quand le logiciel en question touche à des mécanismes d’identité, à des connecteurs administratifs, ou à des briques d’échange inter-agences.

Techniquement, la dépendance se manifeste aussi par des intégrations devenues “collantes” : Actions, issues, modèles de sécurité, politiques d’organisation, gestion des secrets, et liens avec des services cloud. Migrer un dépôt Git est simple, mais migrer l’écosystème d’automatisation et de conformité l’est beaucoup moins. Le geste néerlandais vise justement à reprendre la maîtrise de ces couches, là où une plateforme centralisée, même très pratique, finit par structurer les procédures internes autour de ses propres conventions. L’insight final, côté infrastructure, est qu’une forge n’est plus un simple site web, mais un système de production.

Code.overheid.nl et Forgejo : architecture, gouvernance open source et choix du logiciel libre

Code.overheid.nl a été conçu comme une forge Git auto-hébergée, destinée à centraliser des dépôts et des contributions dans un cadre maîtrisé par l’État. Dans les éléments rendus publics autour du lancement du 24 avril 2026, l’hébergement via SSC-ICT est mis en avant : c’est un point important, car le “self-hosting” gouvernemental impose des contraintes de réseau, d’identité (SSO), de segmentation et de supervision, bien différentes d’un projet associatif. Le projet s’inscrit dans un modèle où l’administration ne consomme pas seulement un service, mais opère une plateforme, avec des exigences de patching, d’astreinte et de continuité.

Le choix de Forgejo est l’autre cœur du signal. Forgejo est un fork né en octobre 2022, après le transfert du projet Gitea à une structure à but lucratif, événement qui a cristallisé des inquiétudes communautaires sur la trajectoire du produit. Forgejo est hébergé par Codeberg e.V., association allemande à but non lucratif, et le projet se présente comme un logiciel libre, avec une gouvernance visant à limiter le risque de capture par un acteur commercial. Pour un gouvernement, cette gouvernance compte autant que les fonctionnalités : l’outil doit rester auditable, modifiable et pérenne, même si un prestataire change.

Ce que la version Forgejo 15.0 LTS change pour un déploiement public

La version 15.0 LTS de Forgejo, publiée le 16 avril 2026, est annoncée comme supportée jusqu’en juillet 2027. Ce détail a un intérêt très “ops” : une LTS permet de stabiliser une base pendant un cycle budgétaire et de sécurité, avec des correctifs sans bascule permanente de version majeure. Dans un contexte gouvernemental, où chaque mise à jour peut exiger tests, homologation interne et fenêtres de déploiement, la disponibilité d’une LTS est un argument opérationnel.

En pratique, une forge moderne ne se limite pas au Git. Elle doit couvrir la gestion de comptes, la revue de code, la modération, la traçabilité et l’intégration avec des outils de build. Dans un setup de type code.overheid.nl, les équipes recherchent aussi des garde-fous : politiques de branches, workflows d’approbation, protections contre la fuite de secrets, et mécanismes d’export. L’intérêt d’un logiciel libre est de pouvoir prioriser ces chantiers au bon endroit : dans le code, et pas seulement via une option de licence.

Un exemple concret de bénéfice concerne l’alignement “public money, public code”, slogan popularisé par la Free Software Foundation Europe : quand des fonds publics financent des améliorations, celles-ci peuvent revenir à l’écosystème open source au lieu de devenir un avantage fermé. Cela crée un retour sur investissement collectif, notamment sur des sujets transverses comme l’accessibilité, l’authentification ou les fonctionnalités d’audit. L’insight final est que la souveraineté passe par la capacité à faire évoluer l’outil sans permission commerciale.

Pour situer les options, voici une comparaison factuelle de forges souvent citées dans les administrations et les équipes d’ingénierie.

Solution	Type de licence	Modèle	Hébergement typique	Repère daté
Forgejo	Logiciel libre	Communautaire	Auto-hébergé / associatif / public	15.0 LTS publiée le 16 avril 2026, support annoncée jusqu’en juillet 2027
GitLab Community Edition	Open source (édition CE) avec modèle open-core	Éditeur + offres propriétaires	Auto-hébergé, avec options payantes	Utilisé comme base de certaines plateformes publiques, dont des catalogues gouvernementaux
GitHub	Propriétaire (service)	Plateforme centralisée	SaaS (cloud)	Acquis par Microsoft en 2018 pour 7,5 milliards de dollars
Radicle	Open source	Collaboration P2P	Décentralisé, orienté développeurs	Projet cité comme alternative aux forges centralisées, notamment après 2018

Libération de la dépendance à Microsoft : impacts concrets sur la supply-chain, l’IA et les pratiques DevSecOps

Parler de libération et de dépendance à Microsoft ne renvoie pas seulement à un logo sur une page de dépôt. Cela touche la chaîne de production logicielle : qui peut publier, qui valide, qui signe, et comment sont suivies les vulnérabilités. Les attaques de supply-chain ont rappelé à quel point un maillon “outillage” peut contaminer un grand nombre de services. Dans une administration, le dépôt, la CI et la gestion des artefacts sont des points où l’on peut imposer des politiques, générer des preuves et auditer des changements.

La démarche néerlandaise suggère une priorité : re-centraliser les preuves de conformité sous une autorité publique. Un scénario concret : un dépôt de connecteur utilisé par plusieurs agences peut exiger des règles de revue de code, des signatures de tags, et une publication d’artefacts contrôlée. Une forge auto-hébergée permet d’adosser ces règles à une identité gouvernementale, plutôt qu’à un compte dépendant d’un service externe. Elle facilite aussi la conservation des logs dans un périmètre soumis aux règles nationales, sans négociation contractuelle complexe sur la localisation et l’accès.

Exemples d’exigences techniques qu’une forge souveraine peut mieux absorber

• Intégration avec un SSO interne et des annuaires d’administration, pour maîtriser la création et la révocation de comptes.
• Politiques de branches obligatoires (revues, approbations), avec conservation des traces pour l’audit.
• Gestion des secrets et rotation, alignée sur des coffres internes plutôt que sur une option SaaS.
• Mirroring entre environnements (dev, préprod, prod) avec contrôle des flux réseau inter-agences.
• Archivage long terme des dépôts et des tickets pour répondre à des obligations de conservation.

La couche IA ajoute un débat spécifique. GitHub Copilot illustre la valeur économique dérivée du code public, et la question devient : un État accepte-t-il que des contributions financées par des budgets publics améliorent indirectement un assistant de programmation propriétaire, intégré à des offres cloud et à des suites d’entreprise ? Une forge basée sur un logiciel libre ne supprime pas l’existence de l’IA, mais elle redonne un choix : publier où l’État décide, avec des politiques de contribution et de duplication maîtrisées.

Pour les équipes de développement, l’impact doit rester praticable. Une plateforme indépendante réussit si elle ne dégrade pas la vélocité : temps de réponse, disponibilité, ergonomie des revues, et intégration CI. Le chantier devient alors très hardware et ops : dimensionnement CPU/RAM/stockage, latences réseau, sauvegardes, et capacité à absorber des pics lors de gros merges ou de scans de sécurité. L’insight final est que la souveraineté se gagne aussi sur des métriques de performance et de fiabilité.

Les vidéos ci-dessous aident à visualiser les enjeux techniques autour des alternatives à GitHub et de l’auto-hébergement.

Pour compléter, une seconde ressource vidéo utile porte sur les alternatives décentralisées et leurs limites dans un cadre institutionnel.

Panorama européen et comparaison avec la France : code.gouv.fr, DINUM, opencode.de et code.europa.eu

Le mouvement des Pays-Bas s’inscrit dans une Europe déjà active sur les forges publiques. L’Allemagne dispose d’opencode.de, et la Commission européenne héberge code.europa.eu, deux points de ralliement pour des projets ouverts et des briques mutualisables. La nouveauté, côté néerlandais, est le choix d’une base entièrement logiciel libre, revendiquée comme telle, sans composante propriétaire à activer pour atteindre un niveau “entreprise”. Cette nuance compte dans un achat public : elle déplace la valeur vers l’intégration et l’exploitation, plutôt que vers une licence.

La France a une approche différente, souvent plus “catalogue” que “forge souveraine unique”. La DINUM maintient code.gouv.fr comme inventaire des codes ouverts des administrations françaises. C’est un outil utile pour retrouver des dépôts, des licences et des projets, et pour soutenir une politique de publication. La limite pointée par certains acteurs du logiciel libre tient à l’outillage sous-jacent : des plateformes s’appuient sur GitLab Community Edition, qui reste une base open source mais s’inscrit dans un modèle open-core, où une partie des fonctions avancées (audit, sécurité, CI/CD premium) relève d’offres propriétaires payantes.

Ce que change un modèle open-core dans une stratégie gouvernementale

Le modèle open-core produit une dépendance qui ne ressemble pas à celle de GitHub, mais elle existe. Les équipes peuvent bâtir des workflows sur des modules premium, puis se retrouver contraintes lors d’un renouvellement, d’un changement de contrat ou d’une évolution de la feuille de route de l’éditeur. La différence, pour un État, se mesure en capacité de continuité : une fonctionnalité cruciale de conformité ne devrait pas dépendre d’un SKU. C’est une logique d’architecture, pas une posture.

Le rapport Bothorel de 2020, remis au gouvernement français, recommandait de renforcer l’ouverture et la mutualisation du code public. Six ans plus tard, la trajectoire européenne montre qu’une forge opérée par un acteur public, sur un socle libre, devient une option crédible. Les Pays-Bas apparaissent parmi les premiers États à formaliser ce choix de bout en bout, en privilégiant une gouvernance communautaire (Forgejo/Codeberg e.V.) et un hébergement public. L’insight final est que la normalisation européenne passe par des plateformes capables d’être copiées et adaptées, pas seulement consultées.

Déploiement, performances et coûts : ce qu’implique une plateforme indépendante à l’échelle d’un État

Passer d’un usage opportuniste de GitHub à une plateforme indépendante opérée par l’État impose un plan de déploiement réaliste. Code.overheid.nl est présenté comme étant en phase pilote, avec “quelques institutions”, et une extension attendue dans l’année suivant le lancement du 24 avril 2026. Un pilote est logique : il permet de valider l’authentification, les règles de contribution, les sauvegardes, la supervision et la qualité de service. Une forge devient rapidement un “outil de production” pour des centaines d’équipes, avec des pics d’activité liés à des releases, des audits ou des incidents.

Le sujet est aussi très matériel. Une forge moderne consomme du CPU pour les indexations, du stockage pour les dépôts et les pièces jointes, et de l’I/O pour les opérations Git lourdes. La CI/CD, si elle est intégrée, ajoute une dimension compute souvent supérieure au dépôt lui-même. Les États qui opèrent ces outils doivent prévoir des architectures redondées, des sauvegardes isolées, des mécanismes de restauration testés, et une segmentation réseau pour éviter qu’un incident sur un projet ne devienne un incident transversal.

Un scénario de migration typique, sans arrêt de service

Une migration réussie ressemble rarement à un “big bang”. Un schéma courant consiste à créer un miroir en lecture seule, puis à déplacer progressivement les contributions, en conservant des redirections et une synchronisation pendant une période de transition. Les tickets et les merge requests sont les éléments les plus douloureux à migrer, car ils contiennent du contexte opérationnel. Une stratégie de conservation peut combiner export, archivage et gel de certains historiques, pour éviter que la migration ne devienne une réécriture.

Le volet sécurité est indissociable : scans de dépendances, gestion des clés, et validation des modèles de permissions. Dans le monde public, il faut aussi une politique de publication : quels dépôts doivent être publics, lesquels doivent rester internes, et comment documenter les choix. Une forge souveraine n’interdit pas l’ouverture, elle permet de la cadrer avec des règles homogènes et des revues. L’insight final est que la réussite se joue dans l’exploitation quotidienne, pas dans le jour du lancement.

On en dit quoi ?

Les Pays-Bas font un choix rationnel : traiter la forge Git comme une infrastructure critique et réduire une dépendance à Microsoft qui n’est plus seulement technique, mais aussi juridique et stratégique. Le pari Forgejo, logiciel libre avec une LTS datée (15.0 publiée le 16 avril 2026), paraît cohérent pour un État qui veut financer des briques réutilisables plutôt que des options sous licence. Le point de vigilance est opérationnel : une plateforme indépendante n’est crédible que si elle tient la charge, l’astreinte et la sécurité, au même niveau qu’un grand SaaS. Le scénario le plus probable en Europe est une multiplication d’instances souveraines interopérables, avec des ponts entre forges publiques, plutôt qu’un retour massif vers une plateforme unique centralisée.

Code.overheid.nl remplace-t-il complètement GitHub pour l’État néerlandais ?

Code.overheid.nl est présenté comme une plateforme auto-hébergée lancée le 24 avril 2026 et encore en phase pilote, avec une extension prévue dans l’année. Dans ce type de trajectoire, la bascule est généralement progressive : certains dépôts et équipes migrent d’abord, puis les pratiques (revue, CI, archivage) sont harmonisées avant une généralisation.

Pourquoi Forgejo est-il mis en avant plutôt qu’une solution open-core ?

Forgejo est présenté comme un logiciel libre, forké en octobre 2022, et hébergé par Codeberg e.V. Cette gouvernance est recherchée pour limiter la dépendance à des options propriétaires. Pour un gouvernement, cela facilite la continuité : les évolutions financées peuvent revenir à l’écosystème open source, et les fonctions critiques ne dépendent pas d’un module premium.

En quoi le CLOUD Act et la FISA Section 702 préoccupent-ils un gouvernement européen ?

Ces cadres juridiques américains sont souvent cités dans les politiques de souveraineté car ils peuvent créer un risque de contrainte extraterritoriale sur des entreprises américaines. L’enjeu, pour une administration, est de réduire l’exposition à une obligation potentielle de transmission de données, même si les serveurs sont situés hors des États-Unis.

La France a-t-elle un équivalent à code.overheid.nl ?

La France dispose de code.gouv.fr, maintenu par la DINUM, qui sert de catalogue pour retrouver les codes ouverts des administrations françaises. Selon les cas, l’outillage peut s’appuyer sur GitLab Community Edition, une base open source dans un modèle open-core. La philosophie est donc proche sur l’ouverture, mais différente sur le choix d’un socle présenté comme entièrement logiciel libre.

Quels sont les pièges techniques d’une forge souveraine auto-hébergée ?

Les points sensibles concernent la performance (I/O stockage, indexations), la disponibilité (redondance, sauvegardes testées), et la sécurité (permissions, secrets, logs, scans). Les migrations d’issues et de merge requests sont aussi complexes, car elles portent l’historique opérationnel. Une approche par pilote, comme indiqué pour code.overheid.nl, limite ces risques.