GitHub orchestre l'IA propriétaire sur vos dépôts : un DSI européen tire la sonnette d'alarme

# GitHub orchestre l'IA propriétaire sur vos dépôts : un DSI européen tire la sonnette d'alarme

*En 2026, l'intégration de l'IA dans les outils de développement n'est plus une promesse — c'est un fait installé dans les habitudes des équipes. GitHub, propriété de Microsoft, a systématiquement tissé ses modèles propriétaires au cœur des workflows de développement. Résultat : des dépendances profondes, souvent invisibles, qui posent des questions concrètes sur la maîtrise réelle du SI. Nous avons interrogé un DSI d'une ETI industrielle française, qui pilote une équipe de développement interne d'une vingtaine de personnes et a engagé depuis dix-huit mois un chantier de désengagement progressif des outils américains.*

Concrètement, qu'est-ce qui vous a alerté dans l'évolution de GitHub ces deux dernières années ?

Ce n'est pas un événement unique. C'est une accumulation. GitHub Copilot est passé d'un outil optionnel à une fonctionnalité omniprésente dans l'interface. Chaque suggestion de code, chaque résumé automatique de pull request, chaque explication de bug — tout cela transite désormais par des modèles hébergés sur l'infrastructure de l'acteur américain. Mes développeurs ont commencé à l'utiliser presque sans s'en rendre compte, parce que c'était là, intégré, fluide. Et puis un jour on réalise que nos patterns de code, nos conventions internes, nos choix d'architecture — tout cela a servi à entraîner ou à affiner des suggestions. Qui garantit que ces données ne servent pas à autre chose ? Personne, clairement.

Mais ce qui m'a vraiment décidé à agir, c'est quand j'ai compris que le problème n'était pas seulement la confidentialité des données. C'est la dépendance comportementale. Mes équipes pensent désormais *avec* l'outil. Retirer Copilot aujourd'hui, ce n'est plus juste changer un abonnement — c'est désorienter des développeurs qui ont externalisé une partie de leur réflexion vers un système opaque.

Ce n'est pas un peu excessif ? Après tout, tout outil crée une forme d'habitude.

Oui, tout outil crée des habitudes. Mais il y a une différence fondamentale entre un outil qui vous assiste et un outil qui vous enferme dans un écosystème dont vous ne contrôlez ni les règles, ni les évolutions, ni même les conditions tarifaires futures. Quand l'acteur américain décide demain de faire évoluer ses CGU, de modifier ce qui est transmis à ses modèles, ou simplement d'augmenter ses prix — vous n'avez aucun levier. Vous subissez.

Je pense que beaucoup de DSI d'ETI ont ce raisonnement : *on verra bien le moment venu*. C'est une erreur. Plus vous attendez, plus le coût de sortie augmente. La dépendance se construit lentement, puis très vite.

Qu'est-ce que ça change concrètement dans le quotidien des équipes IT quand on décide de reprendre la main ?

La première chose, c'est d'accepter une friction temporaire. Quand vous passez d'un environnement intégré et ultra-fluide à une solution que vous devez configurer, héberger, maintenir — il y a un coût opérationnel réel. Ce serait malhonnête de le nier. Mes développeurs ont mis plusieurs semaines à retrouver un rythme équivalent.

Mais ce que personne ne dit assez, c'est ce que vous gagnez en retour. On a déployé une instance auto-hébergée de Gitea pour la gestion de nos dépôts, couplée à Continue.dev — un client d'assistance au code open-source — connecté à un modèle que nous faisons tourner localement. Le code ne sort plus de notre infrastructure. Les suggestions sont paramétrables. Et surtout : mes développeurs ont recommencé à comprendre ce qu'ils font. L'IA locale est moins magique, donc elle force à penser davantage. C'est une vertu cachée.

Gitea, Continue.dev — ces outils sont-ils vraiment à la hauteur pour une équipe de production ?

Honnêtement ? En 2024, j'aurais dit non sans hésiter. En 2026, la réponse est plus nuancée. Gitea a considérablement mûri. Pour des équipes de taille comparable à la mienne — moins de cinquante développeurs — il couvre parfaitement les besoins : gestion des dépôts, pull requests, CI/CD via des intégrations tierces, gestion des accès. Ce n'est pas GitHub en termes d'ergonomie sur certains cas avancés, je ne vais pas mentir. Mais l'écart s'est réduit.

Ce que je défends, ce n'est pas la perfection fonctionnelle immédiate. C'est la trajectoire. Je préfère un outil qui progresse sous gouvernance ouverte, que je peux auditer, contribuer, fork si nécessaire — plutôt qu'une solution parfaite dont je suis tributaire à cent pour cent.

Et pour l'IA elle-même ? L'inférence locale, c'est réaliste à l'échelle d'une PME/ETI ?

C'est la question centrale. Et la réponse a changé. Il y a deux ans, faire tourner un modèle capable d'assistance au code en local nécessitait une infrastructure significative. Aujourd'hui, des modèles suffisamment performants pour la complétion de code et l'explication de fonctions tournent sur du matériel raisonnable. La vraie variable, c'est d'avoir quelqu'un en interne capable de piloter ça — un profil MLOps ou un DevOps senior avec appétit pour le sujet.

Je tiens à être précis : ce n'est pas trivial. Ça demande un investissement en compétences. Mais c'est exactement ce type d'investissement qui crée de la résilience. Et franchement, j'aime mieux former un développeur sur des technologies ouvertes que de payer indéfiniment un abonnement à un acteur américain qui peut changer ses règles du jeu du jour au lendemain.

Un message pour les DSI qui lisent cet article et qui se disent : 'c'est bien beau, mais j'ai d'autres priorités' ?

Je comprends. On a tous d'autres priorités. Mais je leur poserais cette question : est-ce que vous savez précisément ce que vos développeurs transmettent à l'infrastructure Microsoft à chaque session de travail ? Pas en théorie — concrètement, aujourd'hui ?

Si la réponse est non — et c'est la réponse honnête de la majorité — alors vous n'avez pas la maîtrise de votre SI. Vous avez l'illusion de la maîtrise. Et dans un contexte géopolitique où les règles du jeu transatlantiques peuvent se renverser rapidement, cette illusion a un prix.

Je ne dis pas qu'il faut tout changer en six mois. Je dis qu'il faut commencer. Identifier un périmètre, un projet, une équipe. Tester une alternative souveraine sur un cas réel. Acquérir de l'expérience avant que la nécessité ne vous force à migrer dans l'urgence. Le vrai luxe, en matière de souveraineté numérique, c'est d'avoir le temps de choisir — et ce luxe se préserve en anticipant.

*Cet entretien a été réalisé dans le cadre de notre série sur la reconquête de l'autonomie du SI par les ETI européennes. Les outils cités reflètent l'expérience personnelle de notre interlocuteur et ne constituent pas une recommandation générale de RiffLab Media.*