Quand une ETI industrielle a cessé de confier ses développeurs à l'outillage américain

# Quand une ETI industrielle a cessé de confier ses développeurs à l'outillage américain

Le déclencheur ne fut pas idéologique. Il fut financier — et brutal.

En 2025, une ETI industrielle de 800 salariés, fabricant d'équipements spécialisés implanté en France avec des filiales en Allemagne et en Pologne, reçoit une notification de renouvellement de licences pour son environnement de développement. La hausse est significative. Pas catastrophique sur le papier, mais suffisante pour que le DSI pose enfin la question qu'il évitait depuis des années : *pourquoi notre capacité à produire du code dépend-elle à ce point de décisions tarifaires prises à des milliers de kilomètres d'ici ?*

C'est ce moment — pas une conviction souverainiste abstraite, mais une ligne budgétaire qui dérape — qui a ouvert la brèche. Dix-huit mois plus tard, l'équipe IT de cette ETI a restructuré une partie significative de son outillage développeur. Ce retour terrain tente d'en tirer les enseignements honnêtes, sans euphémisme.

L'illusion de la productivité clé en main

Pendant des années, l'argument était simple : les outils américains dominent parce qu'ils sont les meilleurs. Les développeurs les connaissent, les intégrations sont nombreuses, l'écosystème est riche. Remettre en question cet écosystème, c'est s'exposer à une perte de productivité immédiate.

Ce raisonnement mérite d'être déconstruit sérieusement, parce qu'il repose sur une confusion entre *familiarité* et *performance réelle*. L'équipe de développement de cette ETI — une dizaine de développeurs, un lead architect, un RSSI à mi-temps sur les sujets applicatifs — n'avait jamais formellement mesuré sa productivité. Elle estimait. Elle ressentait. Elle comparait avec ce qu'elle avait toujours connu.

Quand le DSI a demandé un audit honnête des frictions quotidiennes, le tableau était moins flatteur qu'attendu. Des pipelines CI/CD hébergés sur des infrastructures dont la localisation des données n'avait jamais été questionnée. Des environnements de revue de code intégrés à des plateformes américaines avec des clauses d'utilisation des données que personne n'avait relues depuis la signature initiale. Des assistants de génération de code branchés sur des modèles dont les conditions d'entraînement restaient opaques.

La productivité était là, oui. Mais à quel prix en termes de maîtrise ?

Le vrai coût de la dépendance : ce qu'on ne calcule jamais

Voilà la question qui dérange : les équipes IT de PME et ETI calculent-elles réellement le coût total de leur dépendance aux acteurs américains, ou se contentent-elles de comparer des lignes de facture ?

Dans le cas de cette ETI, l'exercice a été révélateur. Personne n'avait intégré dans le calcul le temps passé à gérer les changements d'API non prévenus, les migrations forcées vers de nouvelles versions, les réorganisations de plans tarifaires imposées sans négociation possible. Personne n'avait non plus valorisé le risque juridique lié au transfert de propriété intellectuelle implicite dans certaines conditions d'utilisation des outils d'assistance au code.

Ce dernier point mérite qu'on s'y arrête. Lorsqu'un développeur utilise un assistant de codage alimenté par un modèle entraîné sur des bases de données dont la provenance est incertaine, et que les suggestions générées concernent du code métier sensible — des algorithmes de calibration propres à l'activité industrielle de l'entreprise, par exemple —, qui peut garantir que ce code ne contribue pas, d'une façon ou d'une autre, à enrichir le modèle sous-jacent ? Les CGU sont longues. Les équipes juridiques des ETI ne sont pas dimensionnées pour les analyser exhaustivement. Et les éditeurs américains ne simplifient pas volontairement la lecture.

Ce que le changement a réellement impliqué

Il serait malhonnête de présenter la transition comme fluide. Elle ne l'a pas été.

La première résistance est venue des développeurs eux-mêmes. Non pas par mauvaise volonté, mais parce que changer d'outillage en milieu de projet a un coût réel en attention et en énergie cognitive. Le lead architect l'a nommé clairement : *on leur demandait de réapprendre des gestes devenus automatiques*. C'est un effort légitime, qui mérite d'être planifié et non minimisé.

L'ETI a choisi une approche progressive. Elle n'a pas basculé en bloc. Elle a identifié deux ou trois points de friction prioritaires — la gestion des dépôts de code et l'intégration continue en tête — et elle a commencé par là, en maintenant temporairement l'existant sur le reste. Cette prudence a évité le syndrome du grand soir technologique qui se termine en désastre opérationnel.

Sur la forge logicielle, l'équipe a migré vers une instance auto-hébergée de GitLab, déployée sur une infrastructure certifiée SecNumCloud. Ce n'est pas un choix anodin : GitLab est une entreprise américaine cotée à Wall Street. Mais auto-hébergé, sur une infrastructure souveraine, avec une équipe qui maîtrise la configuration et les données, le rapport de force change. La donnée ne quitte pas le périmètre européen. Les mises à jour sont choisies, pas imposées. L'équipe reprend une forme de contrôle opérationnel que le mode SaaS avait progressivement érodé.

Sur l'assistance au développement par IA — le sujet le plus sensible politiquement en interne —, l'ETI a fait un choix plus radical : elle a déployé localement un modèle open source de taille intermédiaire, capable de tourner sur son infrastructure existante sans nécessiter des ressources GPU démesurées. Ce n'est pas la solution la plus performante en absolu. Les développeurs l'ont dit sans détour. Mais c'est une solution dont l'ETI comprend les limites, contrôle les données d'entrée, et peut auditer le comportement. Pour du code métier sensible, ce compromis est devenu acceptable — voire préférable.

Les questions qui restent ouvertes

Dix-huit mois après, le DSI est honnête sur ce qui n'a pas fonctionné comme prévu.

La courbe d'apprentissage a été sous-estimée. Pas sur les outils eux-mêmes, mais sur la charge d'administration. Auto-héberger une forge logicielle, ça veut dire maintenir une forge logicielle. Patches de sécurité, montées de version, sauvegardes, gestion des incidents. L'équipe infrastructure, déjà sollicitée, a absorbé une charge supplémentaire qui n'avait pas été budgétée en temps homme. C'est le prix réel de la souveraineté opérationnelle : elle ne se décrète pas, elle s'administre.

Il y a aussi la question de l'écosystème. Certains outils tiers que les développeurs utilisaient s'intégraient nativement avec les plateformes américaines précédentes et nécessitent désormais des adaptations. Rien d'insurmontable, mais rien de gratuit non plus.

Enfin — et c'est peut-être la question la plus inconfortable —, l'ETI n'a pas résolu le problème de fond. Elle a réduit certaines dépendances, pas toutes. Son ERP, son CRM, sa messagerie restent largement dans des mains américaines. La chaîne de dépendance est longue, et on ne la coupe pas en dix-huit mois sur un seul chantier.

Ce que ça dit à tous les autres

Le cas de cette ETI industrielle illustre quelque chose que les discours sur la souveraineté numérique peinent parfois à formuler concrètement : la question n'est pas de choisir entre performance et indépendance comme si les deux étaient mutuellement exclusifs. Elle est de décider *où* on accepte de dépendre, *pourquoi*, et avec quelle capacité de sortie si les conditions changent.

Les acteurs américains dominent l'outillage développeur parce qu'ils ont investi massivement et tôt. Mais 2025-2026 a montré que cette domination crée des vulnérabilités réelles pour les entreprises européennes : vulnérabilités tarifaires, vulnérabilités juridiques, vulnérabilités de continuité quand un acteur pivote ou disparaît.

La vraie question que devrait se poser tout DSI ou CTO d'ETI européenne n'est pas *« est-ce que mon outillage est le meilleur du marché ? »* C'est : *« est-ce que je suis capable de le remplacer si demain les règles du jeu changent — et qui décide de ces règles ? »*

Pour cette ETI industrielle, la réponse n'était pas satisfaisante. Alors elle a commencé à changer les règles elle-même. Imparfaitement, progressivement, à un coût réel. Mais délibérément.