GitLab sous IA : quand nos outils de développement deviennent des territoires étrangers

# GitLab sous IA : quand nos outils de développement deviennent des territoires étrangers

Il y a quelque chose de particulièrement révélateur dans la manière dont GitLab a pivoté ces dix-huit derniers mois. La plateforme, longtemps présentée comme l'alternative respectable à GitHub — racheté par Microsoft en 2018 —, est en train d'opérer une transformation qui mérite qu'on s'y arrête sérieusement. Pas pour célébrer l'innovation. Pour mesurer ce que cela signifie concrètement pour les équipes de développement européennes qui ont misé sur elle.

En 2026, GitLab n'est plus seulement un outil de gestion de code et de CI/CD. C'est désormais une plateforme d'IA intégrée, où les fonctionnalités d'assistance au développement — complétion de code, revue automatisée, génération de tests, analyse de sécurité — sont profondément enchevêtrées dans l'expérience produit. Le problème n'est pas que l'IA soit là. Le problème est *où* elle tourne, *sur quelles données* elle s'entraîne, et *quel modèle contractuel* l'accompagne.

Le verrou qui ne dit pas son nom

Lorsqu'une plateforme intègre de l'IA générative au cœur de ses workflows, elle ne fait pas qu'ajouter une fonctionnalité. Elle reconfigure la nature même de la dépendance. Avant, migrer d'un outil de DevOps à un autre était complexe mais faisable : exports de repos, migration de pipelines, réécriture de configurations. Douloureux, mais balisé. Aujourd'hui, la question change de nature : comment migrer les *habitudes de travail* d'une équipe qui a intégré l'assistance IA dans chaque étape de son cycle de développement ? Comment transférer le contexte accumulé, les suggestions affinées, les intégrations IDE qui ont reconfiguré les réflexes des développeurs ?

C'est ce qu'on appelle un verrou cognitif et opérationnel. Il est plus insidieux que les verrous contractuels classiques parce qu'il ne figure dans aucun contrat. Il s'installe progressivement, sans friction apparente, dans les pratiques quotidiennes.

Et GitLab n'est pas une entreprise européenne. C'est une société américaine cotée au Nasdaq, soumise au droit américain, aux injonctions des agences fédérales, au Cloud Act. Peu importe que vous hébergiez votre instance GitLab sur vos propres serveurs en Allemagne : si les fonctionnalités IA que vous utilisez font transiter vos données de code vers des infrastructures cloud américaines pour inférence, vous avez perdu la maîtrise de quelque chose d'essentiel — votre code propriétaire, vos algorithmes, vos avantages compétitifs.

Ce que « open-source » ne résout pas seul

On entend souvent cet argument rassurant : GitLab est open-source, donc on peut toujours s'en emparer et le faire tourner soi-même. C'est vrai, et ce n'est pas suffisant.

L'open-source résout le problème de l'accès au code source. Il ne résout pas le problème du *modèle d'IA* qui tourne derrière les fonctionnalités intelligentes. Il ne résout pas la question des mises à jour continues, de la maintenance, de l'intégration des nouveaux modèles. Et surtout, il ne résout pas la réalité économique : une PME ou une ETI européenne n'a pas les ressources pour maintenir un fork complet d'une plateforme DevOps complète tout en suivant le rythme d'intégration IA que GitLab impose à son offre commerciale.

L'open-source est une condition nécessaire. Ce n'est pas une condition suffisante pour parler de souveraineté.

C'est là qu'il faut regarder du côté des acteurs qui construisent différemment. Gitea, par exemple — ou son fork Forgejo, maintenu sous gouvernance communautaire européenne depuis la scission de 2022 — propose une approche radicalement plus sobre. Pas d'IA intégrée par défaut, une empreinte opérationnelle légère, une communauté qui a explicitement refusé la logique de plateforme tout-en-un. Ce n'est pas la même proposition de valeur. Mais c'est précisément le point : la sobriété fonctionnelle peut être une posture souveraine, à condition qu'elle soit choisie et non subie.

L'autre piste sérieuse, pour les organisations qui veulent le meilleur des deux mondes — fonctionnalités avancées *et* contrôle —, passe par une réflexion sur la couche IA elle-même. Quelle différence cela fait-il d'utiliser une instance self-hostée de GitLab si l'on couple son assistance IA à un modèle de langage hébergé en Europe, sous juridiction européenne, avec des garanties contractuelles alignées sur le RGPD et les futures exigences de l'AI Act ? La question n'est plus « quelle plateforme DevOps », mais « quelle architecture d'ensemble ».

Le signal structurel derrière l'annonce produit

Je veux insister sur ce point parce qu'il est souvent mal lu : la restructuration de GitLab autour de l'IA n'est pas d'abord un événement produit. C'est un signal sur la direction du marché des outils de développement dans son ensemble.

Tous les acteurs dominants de ce segment — et GitLab n'est pas le seul concerné — convergent vers le même modèle : une plateforme intégrée, enrichie par l'IA, qui rend chaque couche du cycle de développement dépendante de la couche suivante. Le code review assisté dépend du modèle. Le modèle dépend de l'infrastructure cloud. L'infrastructure cloud dépend du contrat. Et le contrat, in fine, dépend d'une juridiction qui n'est pas la nôtre.

Ce mouvement de fond crée une fenêtre d'opportunité étroite pour les organisations européennes. Pas pour rejeter l'IA dans le développement — ce serait une posture aussi stérile qu'irréaliste. Mais pour définir maintenant, avant que les habitudes ne soient trop ancrées, quelle architecture de dépendance elles acceptent.

Ce que cela exige concrètement des DSI européens

La question qui se pose aujourd'hui n'est pas technique au sens étroit. Elle est de gouvernance. Quand un DSI ou un CTO évalue sa chaîne DevOps en 2026, il ne peut plus se contenter de regarder les fonctionnalités, les benchmarks de performance, le coût de licence. Il doit cartographier les flux de données liés à l'IA : quelles données quittent le périmètre de l'organisation, vers quels serveurs, sous quelle juridiction, pour quel usage.

Cette cartographie n'est pas optionnelle. Elle est une obligation de diligence, renforcée par les textes européens en cours de déploiement. Et elle peut conduire à des choix que la seule logique fonctionnelle ne commanderait pas — choisir une solution légèrement moins riche en fonctionnalités IA pour conserver une maîtrise réelle sur ce qui se passe avec le code source de l'entreprise.

Nous ne sommes pas en train de parler d'un sacrifice. Nous sommes en train de parler d'un arbitrage lucide entre confort immédiat et résilience durable.

GitLab restructure autour de l'IA. C'est son droit et probablement sa survie commerciale. Notre responsabilité, en tant qu'acteurs du numérique européen, est de ne pas laisser cette restructuration définir à notre place où s'arrête notre SI et où commence le territoire d'un acteur étranger.