Assistants de code en entreprise : ce qui marche vraiment

Dans la plupart des organisations que nous croisons, la question « faut-il autoriser les assistants de code ? » arrive trop tard. Les développeurs les utilisent déjà. Parfois via un compte d'entreprise, souvent via un compte personnel, occasionnellement en copiant du code métier dans une fenêtre de navigateur que personne n'a validée.

Le débat utile n'est donc pas d'autoriser ou d'interdire. Il est de savoir ce que ces outils changent réellement, et à quelles conditions le gain survit au passage à l'échelle.

Ce qui change, et ce qui ne change pas

Un assistant de code est très bon sur une catégorie précise de travail : le code que vous auriez su écrire, mais qui vous aurait pris du temps. Un test unitaire supplémentaire, une migration répétitive, un script d'analyse jetable, la première version d'un composant, la documentation d'une fonction existante.

Il est nettement moins bon dès que la difficulté n'est pas d'écrire du code, mais de décider quel code écrire. Comprendre pourquoi une règle métier existe depuis 2014, arbitrer entre deux modèles de données, deviner ce que le client voulait dire : rien de tout cela ne s'améliore parce qu'un modèle complète vos lignes plus vite.

C'est pour cette raison que les gains annoncés varient autant d'une équipe à l'autre. Une équipe qui passe l'essentiel de son temps à produire du code standard voit une différence immédiate. Une équipe qui passe l'essentiel de son temps à comprendre un système existant en voit beaucoup moins — et parfois pas du tout.

Avant de mesurer l'accélération, mesurez la proportion de votre temps réellement passée à écrire du code. C'est le plafond de ce que l'outil peut vous apporter.

Les trois façons dont un déploiement échoue

Le code arrive plus vite que la revue. C'est l'échec le plus fréquent, et le plus coûteux. La production de code augmente de 30 %, la capacité de relecture reste identique, et l'écart s'accumule dans les branches en attente. Vous n'avez pas accéléré la livraison : vous avez déplacé le goulot d'étranglement, et il est maintenant humain.

Personne ne sait ce qui a été généré. Six mois plus tard, une anomalie apparaît dans un module que personne ne revendique. Ce n'est pas un problème de qualité du modèle, c'est un problème de traçabilité : sans convention de revue, la responsabilité du code généré se dilue.

L'outil est configuré par défaut. Un assistant sans contexte sur votre dépôt propose du code plausible mais étranger à vos conventions, à votre architecture, à vos bibliothèques internes. Les développeurs corrigent, se lassent, puis désactivent. L'outil n'a pas échoué : il n'a jamais été branché sur quoi que ce soit.

Le contexte fait plus que le modèle

La différence entre un assistant utile et un assistant agaçant tient rarement au modèle sous-jacent. Elle tient à ce qu'il sait de vous.

Un assistant qui a accès à vos conventions de nommage, à votre schéma de base de données, à vos tickets et à votre bibliothèque de composants produit un travail exploitable. Le même modèle, sans rien de tout cela, produit du code générique qu'il faudra réécrire.

C'est précisément le rôle du Model Context Protocol : au lieu de coller manuellement du contexte dans une fenêtre de discussion, vous exposez vos outils — dépôt, base de données, gestionnaire de tickets, documentation interne — derrière une interface que l'assistant peut interroger lui-même. Nous écrivons ces serveurs pour nos clients, et nous les utilisons sur nos propres projets.

Une règle simple : si vous vous surprenez à réexpliquer la même chose à l'assistant chaque semaine, cette chose doit devenir une règle du dépôt ou un serveur MCP.

Encadrer sans étouffer

La gouvernance des assistants de code se résume à quatre décisions, et elles se prennent en une réunion :

Le point sensible est presque toujours l'hébergement. Pour du code métier sensible, un tenant privé — Azure OpenAI, par exemple — ou des agents exécutés localement change la conversation avec votre DPO et votre RSSI. Ce n'est pas une contrainte marginale : c'est souvent ce qui décide si le projet existe.

L'AI Act, lui, classe la plupart des usages de développement assisté dans les risques limités. L'obligation principale est la transparence interne : vos équipes doivent savoir qu'elles utilisent un système d'IA et dans quelles limites. C'est une politique écrite d'une page, pas un chantier de conformité.

Mesurer autre chose que la sensation de vitesse

Tous les développeurs à qui vous demanderez vous diront qu'ils vont plus vite. C'est sincère, et ce n'est pas une mesure.

Les indicateurs qui tiennent sont ceux que vous suiviez déjà : délai entre l'ouverture d'une branche et sa mise en production, proportion de correctifs après livraison, temps passé en revue. Si ces trois chiffres ne bougent pas au bout d'un trimestre, l'outil n'a pas changé votre capacité de livraison, quelle que soit l'impression des équipes.

Prenez ces mesures avant le déploiement. Après, vous n'aurez plus de point de comparaison, et la discussion deviendra une affaire d'opinions.

Par où commencer

Choisissez une équipe volontaire et un dépôt réel — pas un projet pilote artificiel. Relevez vos trois indicateurs. Configurez l'assistant sur ce dépôt : conventions, règles, accès aux outils dont il a besoin. Écrivez la page de politique d'usage. Laissez tourner six semaines. Comparez.

Ce qui sort de cet exercice est rarement « l'outil est bon » ou « l'outil est mauvais ». C'est une liste précise des endroits où il aide, et de ceux où il ne sert à rien. Cette liste est ce qui vous permet de décider pour le reste de l'organisation.

Nous faisons exactement ce parcours avec nos clients, et nous utilisons ces outils tous les jours sur nos propres projets — c'est l'objet de notre service Copilotes & assistants IA et de la formation Coder avec l'IA.

Vous vous demandez si vos équipes utilisent déjà ces outils, et dans quelles conditions ? C'est souvent la première chose à établir. Parlons-en.