Lorsque la souveraineté numérique est évoquée, le débat se concentre volontiers sur les infrastructures visibles : cloud, centres de données, semi-conducteurs, réseaux, cybersécurité. Ces dimensions sont évidemment structurantes. Elles laissent pourtant dans l’ombre une autre couche, plus discrète et tout aussi décisive : les outils avec lesquels le logiciel lui-même est produit.

Cette question mérite d’être posée sans dramatisation et sans faux procès. Il ne s’agit ni de contester la qualité des outils dominants ni de plaider pour une rupture artificielle avec des écosystèmes devenus, pour beaucoup de développeurs, des évidences professionnelles.

Le couple formé par GitHub et Visual Studio Code appartient aujourd’hui à cette catégorie rare d’outils qui ont dépassé leur fonction première. GitHub n’est plus seulement une plateforme d’hébergement de code, ce que le monde open source désigne parfois comme une plateforme de développement. C’est un lieu de collaboration, un standard de fait, parfois une vitrine professionnelle, souvent un maillon central dans les chaînes modernes de développement. De son côté, Visual Studio Code est devenu bien davantage qu’un éditeur ; il constitue pour beaucoup un environnement complet, enrichi d’extensions, d’automatisations, d’intégrations cloud et désormais d’assistants génératifs.

Il serait artificiel de feindre que cette position dominante relève d’un simple accident de marché. Ces outils se sont imposés parce qu’ils sont efficaces, parce qu’ils répondent à des besoins réels et parce qu’ils bénéficient d’effets d’écosystème considérables. Leur succès n’appelle ni caricature ni procès d’intention.

Mais précisément parce qu’ils sont devenus des évidences, ils méritent d’être interrogés.

Les outils de développement ne sont pas neutres au sens stratégique du terme. Ils organisent des flux, structurent des pratiques, concentrent des communautés, façonnent des standards implicites. Ils influencent aussi, plus discrètement, les trajectoires techniques que suivent ensuite les organisations publiques et privées.

Sous cet angle, la question posée dépasse largement GitHub et concerne la chaîne de production logicielle dans son ensemble.

La manière dont le code est écrit, partagé, versionné, testé et distribué participe elle aussi d’une architecture de dépendance ou, à l’inverse, d’autonomie.

Pour l’Europe, cette réflexion n’a rien de théorique. Elle touche directement à la capacité de préserver des options.

C’est ici que le débat gagne en maturité. Il ne s’agit pas de poser une injonction irréaliste consistant à “sortir de GitHub” ou à remplacer du jour au lendemain Visual Studio Code. Une telle approche relèverait davantage du symbole que d’une stratégie.

La question est plus simple et plus exigeante : existe-t-il des alternatives crédibles lorsque davantage de maîtrise est recherchée ?

Dans le domaine des plateformes de développement collaboratif, Forgejo constitue l’une des initiatives les plus intéressantes apparues ces dernières années. Son intérêt ne tient pas seulement à ses qualités techniques. Il réside aussi dans une gouvernance ouverte et dans une logique plus fédérée du développement collaboratif. Ce point compte dans un débat sur la souveraineté, où la question du contrôle institutionnel importe autant que la performance.

Autour de cette dynamique gravite Codeberg, souvent cité comme exemple d’alternative européenne crédible. Son intérêt est aussi politique au sens noble du terme : montrer que des infrastructures de collaboration peuvent relever d’autres logiques de gouvernance que celles des grandes plateformes centralisées.

Dans un registre différent, GitLab, en particulier dans ses déploiements auto-hébergés, représente pour de nombreuses administrations et organisations une option sérieuse lorsqu’une plus grande maîtrise sur les chaînes DevOps est recherchée. Pour les acteurs publics, cette dimension est loin d’être marginale.

Du côté des environnements de développement, VSCodium apparaît comme une transition pragmatique pour celles et ceux qui souhaitent conserver les atouts de l’univers VS Code tout en limitant certaines dépendances.

De son côté, Eclipse Theia, porté notamment par l’Eclipse Foundation, ouvre des perspectives particulièrement intéressantes. Le fait qu’une partie de cet écosystème s’inscrive dans une tradition européenne de gouvernance open source n’est pas anecdotique dans une réflexion sur l’autonomie technologique.

Aucune de ces options ne prétend remplacer à elle seule l’hégémonie des acteurs dominants. Ce n’est d’ailleurs pas leur fonction.

Leur importance tient au fait qu’elles existent, qu’elles sont techniquement sérieuses et qu’elles maintiennent ouverte la possibilité d’autres trajectoires.

Cette pluralité n’a rien d’accessoire. En matière stratégique, disposer d’alternatives viables constitue déjà une forme de sécurité.

Cette réflexion peut d’ailleurs être élargie. Les dépendances des développeurs ne s’arrêtent ni aux plateformes ni aux éditeurs de code. Elles concernent aussi les registres de paquets, les chaînes CI/CD, les outils d’automatisation, les assistants de génération de code, parfois même les espaces où se forme la connaissance technique collective.

Sous cet angle, la question posée dépasse largement GitHub. Elle concerne la chaîne de production logicielle dans son ensemble.

Pour les responsables publics, les dirigeants et les décideurs, ce point mérite attention. Les politiques de souveraineté sont généralement pensées au niveau des infrastructures critiques. Elles gagneraient à intégrer davantage cette couche amont où se fabriquent certaines dépendances futures.

Car une dépendance technologique se crée rarement au moment où elle devient visible. Elle s’installe plus tôt, dans les outils adoptés par usage, dans les standards devenus implicites, dans les environnements que l’on cesse peu à peu d’interroger.

Reconnaître cette question ne revient ni à opposer l’Europe à des plateformes américaines ni à transformer un débat technique en posture idéologique. Il s’agit plus simplement de considérer que l’autonomie stratégique suppose aussi de préserver des capacités de choix.

Ces alternatives n’ont pas vocation à reproduire immédiatement l’échelle des plateformes dominantes. Leur intérêt réside ailleurs : maintenir des marges d’autonomie, réduire certains effets de verrouillage et préserver des options dans la chaîne de production logicielle.

La souveraineté n’exige pas toujours de quitter les plateformes dominantes. Elle peut commencer plus modestement, mais plus concrètement, par la capacité à disposer d’alternatives crédibles.

Et vous, qu'en pensez-vous ?
On en discute sur LinkedIn avant de se retrouver ici la semaine prochaine ?
Merci d'avoir lu cette édition jusqu'au bout.
— Fabrice | LinkedIn | Fabrice.Willot.eu

Plateformes de développement collaboratif

• Forgejo — open source, gouvernance communautaire marquée par une dynamique européenne : https://forgejo.org/

• Codeberg — organisation européenne à but non lucratif, basée en Allemagne, forge open source opérée avec Forgejo : https://codeberg.org/

• Gitea — open source, projet international, solution auto-hébergeable largement adoptée : https://about.gitea.com/

• GitLab — open core, entreprise fondée en Europe, aujourd’hui acteur international majeur du self-hosted et du DevSecOps : https://about.gitlab.com/

• SourceHut — open source, plateforme distribuée et minimaliste, projet indépendant : https://sourcehut.org/

Environnements de développement

• VSCodium — distribution open source de VS Code, sans couche propriétaire Microsoft : https://vscodium.com/

• Eclipse Theia — open source, gouvernance portée par la Fondation Eclipse, fort ancrage européen : https://theia-ide.org/

• Neovim — open source, projet communautaire international : https://neovim.io/

• Emacs — logiciel libre historique porté par le projet GNU : https://www.gnu.org/software/emacs/

Références complémentaires

• Eclipse Foundation — gouvernance open source et projets industriels : https://www.eclipse.org/

• European Commission Open Source Software Strategy (“Think Open”) : https://commission.europa.eu/about/departments-and-executive-agencies/digital-services/open-source-software-strategy_en

• Open Source Observatory (OSOR) — études et ressources sur l’open source européen : https://interoperable-europe.ec.europa.eu/collection/open-source-observatory-osor

• European Commission Open Source Programme Office (EC OSPO) — initiatives institutionnelles autour de la gouvernance open source : https://interoperable-europe.ec.europa.eu/collection/ec-ospo

...