Mesurez les progrès utiles
Mesurez le travail terminé, l’effort de revue et les reprises. Ne confondez pas volume de code généré et valeur.
Publié par TaigaNotre méthode de rédaction
Ce que vous apprendrez
- Distinguer l’activité d’un résultat utile.
- Inclure la préparation, la revue et la correction dans une comparaison de temps.
- Reconnaître les limites d’une affirmation sur la productivité.
Définissez le résultat avant la mesure
Un outil d’IA peut produire du code rapidement. Le résultat utile est une modification qui répond à un besoin utilisateur avec le niveau de qualité requis. Ce sont deux mesures différentes.
Les lignes générées, les suggestions acceptées et les exécutions d’agents décrivent une activité. Elles peuvent aider à comprendre l’usage de l’outil. Elles ne prouvent pas qu’un service s’est amélioré ni que l’équipe a livré plus tôt un travail utile.
Commencez par une question. Par exemple : « Ce workflow réduit-il l’effort total nécessaire pour terminer une petite tâche de maintenance ? » Définissez ce que signifie terminer avant de recueillir les résultats. Incluez les tests, la revue et la documentation nécessaires.
Comptez toute la tâche
Prenons une modification fictive du filtre d’un rapport. Sans IA, l’implémentation prend 60 minutes et la revue 10 minutes. Avec l’IA, l’implémentation prend 30 minutes et la revue 45 minutes.
L’implémentation est plus rapide. L’effort mesuré pour ces phases passe de 70 à 75 minutes. Aucun résultat n’inclut la préparation, les corrections ultérieures ou les défauts après livraison. Gardez ces limites visibles.
| Phase | Exemple sans IA | Exemple avec IA |
|---|---|---|
| Implémentation | 60 minutes | 30 minutes |
| Revue | 10 minutes | 45 minutes |
| Total mesuré | 70 minutes | 75 minutes |
Ces chiffres illustrent un calcul. Ce ne sont ni des résultats de recherche ni une prévision pour votre équipe. La hausse du temps de revue peut venir d’un diff plus important, d’un code peu familier ou d’une exigence manquante. Analysez la cause avant de modifier la politique d’usage des outils.
Distinguez l’effort du temps écoulé
L’effort mesure le temps consacré au travail par les personnes. Le temps écoulé inclut l’attente. Un agent peut exécuter des contrôles pendant qu’un développeur effectue une autre tâche. Ne comptez pas deux fois le même temps humain. Notez aussi l’attente d’une revue ou d’un environnement.
Un workflow peut réduire l’effort sans raccourcir le délai de livraison. Cela peut arriver lorsqu’une file d’approbation détermine la date de fin. L’effort économisé peut garder de la valeur, mais l’organisation doit décider séparément comment l’utiliser.
Demandez aux développeurs si le workflow les aide à comprendre le système et à rester concentrés. Traitez ces réponses comme des retours d’expérience. Ne transformez pas une impression de vitesse en pourcentage d’amélioration vérifié.
Lisez les études en tenant compte de leurs limites
METR a constaté un ralentissement dans une étude précise menée début 2025 auprès de développeurs open source expérimentés. L’étude n’a pas établi un effet pour tous les développeurs ou toutes les tâches. La mise à jour de février 2026 décrit des effets de sélection et des difficultés de mesure dans une expérience ultérieure.
La leçon utile porte sur la mesure. Les versions des outils, le choix des tâches, les exigences de qualité et le comportement des participants peuvent changer le résultat. Ne faites pas d’un pourcentage historique une règle permanente du développement avec l’IA.
Les travaux DORA de 2025 attirent aussi l’attention sur l’organisation autour des outils. Une équipe a besoin de pratiques de développement efficaces pour transformer les capacités des outils en résultats de livraison utiles.
Faites une petite comparaison reproductible
Utilisez des tâches représentatives et les mêmes critères de fin. Notez les versions des modèles et des outils. Incluez les tentatives infructueuses et l’effort de revue. Comparez plusieurs tâches au lieu de retenir la meilleure démonstration.
Présentez l’étendue des résultats et les principales limites. Si une modification réduit l’effort mais augmente les défauts, analysez-la avant de la généraliser. Si les résultats sont contrastés, limitez la recommandation aux types de tâches pour lesquels les preuves sont utiles.
Une bonne mesure soutient une prochaine décision précise. Elle n’a pas à prouver que l’IA est universellement bonne ou mauvaise.
Faire l’exercice
Choisissez cinq tâches terminées comparables. Notez les temps de préparation, d’implémentation, de revue, de correction et d’attente. Consignez les défauts séparément. Comparez l’effort total et le temps écoulé. Avant de conclure, notez les différences de difficulté, de personnes et de versions des outils.
Télécharger la fiche d’exercice (Markdown)Vérifier votre compréhension
Sources et lectures complémentaires
- METR: Early-2025 developer productivity study ↗
- METR: February 2026 study update and measurement limitations ↗
- DORA: 2025 research report ↗
Lectures Taiga sur le sujet
Désactiver cette option supprime toute la progression enregistrée dans ce navigateur.
Votre progression reste dans ce navigateur. Sans compte ni suivi.