Une démonstration réussie ne prouve pas qu'un assistant de code améliore le travail d'une équipe. Elle montre seulement que l'outil sait produire une réponse convaincante dans un environnement choisi. L'adoption, elle, engage des dépôts réels, des règles métier, des secrets, une chaîne CI et du temps de revue.
Les résultats publiés invitent à la prudence. Une étude contrôlée de GitHub sur une tâche Python a mesuré de meilleurs résultats fonctionnels et de qualité avec Copilot. À l'inverse, l'essai randomisé de METR mené auprès de développeurs expérimentés sur leurs propres grands dépôts open source a observé un temps de réalisation supérieur de 19 % avec les outils du début 2025. Ces travaux n'étudient ni les mêmes personnes, ni les mêmes tâches, ni les mêmes produits. Ils ne s'annulent pas : ils montrent pourquoi chaque équipe doit évaluer l'outil dans son contexte.
Ce protocole permet de comparer une complétion dans l'IDE, un chat contextualisé, un agent en ligne de commande ou un bot de revue sans confondre vitesse de génération et valeur livrée.
La décision à prendre avant de lancer le pilote
Une évaluation utile commence par une décision explicite. « Tester l'IA » est trop vague. Écrivez plutôt : « décider si l'outil peut être autorisé pour les corrections et petites évolutions sur les dépôts internes non sensibles, avec un budget de 40 euros par développeur et par mois ».
Précisez également la catégorie évaluée, car les risques diffèrent fortement :
| Type d'outil | Travail principal | Accès typique | Risque dominant |
|---|---|---|---|
| Complétion IDE | compléter quelques lignes localement | fichier ouvert | suggestion plausible acceptée trop vite |
| Chat de dépôt | expliquer et proposer des modifications | plusieurs fichiers indexés | contexte sensible transmis au fournisseur |
| Agent de code | modifier, exécuter et itérer | dépôt, shell, réseau | action trop large ou commande destructive |
| Bot de revue | commenter une pull request | diff et historique | faux sentiment de contrôle ou bruit en revue |
Ne comparez pas un agent autonome à une complétion uniquement sur le prix de la licence. Comparez-les sur les tâches qu'ils doivent réellement résoudre et sur les permissions nécessaires à ce travail.
Étape 1 : établir une référence sans IA
Pendant une à deux semaines, mesurez le flux actuel sur les catégories de tâches retenues. La référence doit utiliser les mêmes dépôts, outils de CI, exigences de revue et profils de développeurs que le pilote. Sans cette période, une amélioration apparente peut simplement venir de tâches plus faciles ou d'une équipe plus disponible.
Pour chaque tâche, conservez :
- l'heure de début et celle où le changement est accepté ;
- le résultat du premier passage de CI ;
- le nombre d'allers-retours en revue ;
- les défauts découverts avant et après fusion ;
- le temps actif du développeur et du reviewer ;
- une estimation courte de la difficulté et de la familiarité avec le module.
Le point d'arrivée n'est pas le premier diff généré. C'est une modification comprise, validée et acceptable pour la production. Ce choix intègre le temps parfois déplacé vers le débogage et la revue.
Étape 2 : construire un banc de tâches représentatif
Un bon banc d'essai couvre le quotidien et les zones où l'outil pourrait échouer. Utilisez de vrais tickets déjà résolus ou des tâches à faible risque encore ouvertes, puis retirez les informations qui révéleraient la solution.
Préparez au moins deux exemples dans chacune des familles pertinentes :
- corriger un bug et ajouter un test de non-régression ;
- faire évoluer une API sans casser les consommateurs ;
- refactorer un module en conservant son comportement ;
- mettre à jour une dépendance et traiter les incompatibilités ;
- diagnostiquer un test flaky ou un échec de CI ;
- modifier une interface et vérifier le rendu responsive ;
- expliquer une zone peu documentée avant de la modifier ;
- traiter une entrée hostile, une erreur ou un cas de droits.
Une douzaine de tâches suffit pour un premier signal, mais elle doit varier en langage, ancienneté, surface du dépôt et ambiguïté. Écartez les exercices artificiels dont la solution tient dans une fonction isolée si ce n'est pas le travail habituel de l'équipe.
SWE-bench fournit un cadre reproductible où un modèle corrige des issues GitHub et où les tests valident les patches. C'est un indicateur de capacité intéressant, pas un substitut à ce banc interne : il ne connaît ni votre architecture, ni vos conventions, ni le coût de votre revue.
Étape 3 : utiliser un protocole croisé
L'expérience des développeurs et la difficulté des tickets créent plus de variation que l'outil lui-même. Pour limiter ce biais, chaque participant réalise des tâches avec et sans assistant. Répartissez aléatoirement les tickets comparables entre les deux conditions, puis inversez les conditions sur la seconde moitié.
Prévoyez une phase d'apprentissage avant de chronométrer. Un outil agentique demande de comprendre ses commandes, ses limites et la manière de lui fournir du contexte. Mesurer ses deux premières heures pénaliserait artificiellement le produit ; laisser des utilisateurs experts choisir toutes les tâches assistées le favoriserait.
Un pilote pragmatique peut durer trois à quatre semaines avec quatre à huit développeurs volontaires. Ce volume ne produira pas une vérité scientifique universelle. Il suffit toutefois à repérer un gain cohérent, un usage limité à certains travaux ou un problème bloquant. Conservez les résultats par type de tâche au lieu de ne publier qu'une moyenne.
La grille de score pondérée
Attribuez chaque note de 0 à 5 à partir d'éléments observables, puis appliquez les poids définis avant l'essai. Cette proposition privilégie la qualité et la sécurité ; une équipe peut ajuster les poids, mais pas après avoir vu quel outil gagne.
| Dimension | Poids | Mesures observables | Note bloquante |
|---|---|---|---|
| Qualité fonctionnelle | 25 % | tests, cas limites, défauts échappés, rollback | moins de 3/5 |
| Sécurité et données | 20 % | permissions, secrets, dépendances, auditabilité | tout échec critique |
| Vitesse de livraison | 20 % | temps jusqu'au changement accepté, p50 et p90 | aucune amélioration ciblée |
| Maintenabilité | 15 % | lisibilité, complexité, conventions, capacité à expliquer | moins de 3/5 |
| Coût total | 10 % | licence, requêtes, CI, temps de revue et support | budget dépassé |
| Expérience équipe | 10 % | charge cognitive, interruptions, accessibilité, satisfaction | abandon fréquent |
Le score total facilite la comparaison, mais ne doit jamais compenser une fuite de secret, une violation de licence, l'absence de journal d'audit ou une permission de production injustifiée. Ces éléments sont des portes de sortie, pas des points négatifs dilués dans une moyenne.
Mesurer ce qui arrive après la génération
Les lignes produites, les suggestions acceptées et le nombre de prompts décrivent l'usage de l'outil. Elles ne prouvent pas sa valeur. Les mesures principales doivent suivre le changement jusqu'à son acceptation :
- temps jusqu'au diff accepté : du début de la tâche à l'approbation technique ;
- taux de CI verte au premier passage : sans correction après le premier push ;
- itérations de revue : nombre de cycles et temps cumulé des reviewers ;
- défauts échappés : régressions, incidents ou correctifs liés après fusion ;
- taux d'abandon : recours final à une réécriture humaine ;
- capacité d'explication : le développeur peut justifier le comportement et les compromis.
Ajoutez p50 et p90. Une moyenne favorable peut masquer quelques tâches où l'agent s'enferme dans une boucle coûteuse. Segmentez aussi entre travail familier et dépôt inconnu : l'étude METR rappelle qu'un développeur expérimenté sur son propre projet ne répond pas nécessairement comme un utilisateur découvrant le code.
Notre guide sur les outils de développement et l'IA replace ces mesures dans le système de livraison. L'article sur les tests flaky aide à stabiliser la CI avant de lui confier un rôle de juge.
Calculer le coût réellement supporté
Le coût mensuel n'est pas seulement le nombre de licences. Pour chaque tâche terminée, additionnez :
- l'abonnement et les requêtes premium consommées ;
- les appels de modèle ou tokens facturés séparément ;
- les minutes de CI supplémentaires ;
- le temps de revue et de correction ;
- la formation, l'administration et le support ;
- le coût d'un contrôle de sécurité ou d'une offre entreprise imposée par les données.
Rapportez ce total au changement accepté, pas à la suggestion. Un agent cher peut rester rentable s'il retire plusieurs heures sur une migration vérifiable. Une complétion peu coûteuse peut devenir négative si elle augmente les reprises. Notre analyse des budgets IA pour les développeurs détaille les limites de consommation à mettre en place.
Tester les permissions comme une fonctionnalité
OWASP décrit l'« excessive agency » comme la combinaison d'une autonomie, de fonctions ou de permissions trop larges. Pour un agent de code, la sécurité ne se limite donc pas à la qualité du patch. Il faut tester ce que l'outil peut lire, exécuter et publier.
| Capacité | Réglage initial | Test à effectuer |
|---|---|---|
| Lecture du dépôt | périmètre explicite | vérifier l'exclusion des secrets et fichiers voisins |
| Écriture | branche ou worktree isolé | tenter une modification hors périmètre |
| Shell | sandbox sans privilège | bloquer commandes destructives et accès système |
| Réseau | désactivé ou liste autorisée | contrôler exfiltration et téléchargement de scripts |
| Identifiants | jetons courts et minimaux | confirmer qu'aucun secret n'entre dans le contexte |
| Publication | approbation humaine obligatoire | empêcher push protégé, fusion et déploiement directs |
Introduisez aussi une instruction malveillante dans un ticket, un fichier de documentation ou la sortie d'un outil de test. L'agent doit traiter ce texte comme une donnée non fiable et ne pas élargir sa mission. Les pratiques du SSDF du NIST restent applicables : exigences de sécurité, protection de l'environnement de développement, vérification et réponse aux vulnérabilités ne disparaissent pas parce que le code a été proposé par un modèle.
Organiser une revue aveugle sur un échantillon
Sur quelques changements comparables, masquez si possible l'outil utilisé et demandez à des reviewers qui n'ont pas participé à la tâche de noter correction, simplicité, conventions et risques. Cette étape limite l'effet de réputation du fournisseur et le biais du développeur qui souhaite défendre son choix.
Les mêmes portes de qualité s'appliquent aux deux groupes : compilation, formatage, analyse statique, tests, scan de dépendances et revue humaine. Un test écrit par l'assistant ne valide pas seul son implémentation ; vérifiez qu'il échoue bien sans le correctif et qu'il couvre le comportement attendu.
Notre article sur les assistants de code et la revue humaine propose les contrôles à renforcer lorsque le volume de modifications augmente.
Trois décisions possibles à la fin du pilote
Une évaluation sérieuse ne doit pas forcer un déploiement global. Elle peut aboutir à trois décisions :
Adopter
L'outil améliore le temps jusqu'au changement accepté sur les usages ciblés, la qualité reste au moins équivalente à la référence, aucun contrôle de sécurité ne bloque et le coût par tâche respecte le budget. Documentez les usages recommandés, formez les équipes et continuez la mesure après déploiement.
Limiter
Le gain est net sur les tests, la documentation ou les migrations mécaniques, mais absent sur le code métier ou les grands refactorings. Autorisez uniquement les tâches et dépôts démontrés, avec les permissions correspondantes. C'est souvent une meilleure décision qu'une licence ouverte sans cadre.
Refuser ou reporter
Un défaut critique de confidentialité, l'impossibilité d'auditer les actions, une hausse des défauts ou un coût total supérieur au gain suffit à arrêter. Conservez le protocole et les résultats : une nouvelle version du produit pourra être réévaluée sur le même banc plutôt que repartir d'une démonstration commerciale.
La fiche de pilote à conserver
Avant le démarrage, le document doit tenir sur une page : décision attendue, outil et version, dépôts autorisés, participants, tâches, période de référence, métriques, poids, seuils bloquants, budget et responsable de l'arrêt. À la fin, ajoutez les résultats par type de tâche, les incidents observés et la décision signée.
DORA présente l'IA comme un amplificateur des forces et faiblesses existantes. Ce cadre en tire une conséquence concrète : l'assistant ne doit pas être évalué isolément, mais avec le dépôt, la CI, la revue, les permissions et le coût humain dont dépend chaque changement livré.
