Pilote IA : conçois la preuve d'abord
TL;DR
Fixe la référence, le critère de qualité et les temps à relever avant de lancer ton pilote IA. Compare des tâches comparables et compte la correction comme la relecture. Le protocole présenté ici reste une méthode proposée, sans résultat de comparaison contrôlée ni ROI métier démontré.
Le 5 août 2026, j’ai abandonné un protocole avant/après : la référence était perdue, les usages avaient déjà changé. J’ai proposé une comparaison côte à côte. La relecture du 10 septembre a confirmé le statut du dossier : un protocole et des relevés historiques, aucune comparaison contrôlée réalisée. Aucun gain de temps ni ROI métier démontré à ce stade.
Un pilote d’AI enablement doit pouvoir produire une réponse défavorable à l’outil. Sinon, tu organises une démonstration. La preuve se prépare avant les premiers retours enthousiastes : travail comparable, qualité attendue, coût humain complet, limites de la comparaison.
Une référence qui répond à ta question
Écris d’abord ce que tu compares. Un agent de code face au travail sans IA mesure une autre question que deux environnements IA entre eux. Dans le second cas, un avantage relatif ne prouve aucun gain par rapport au travail sans IA.
Choisis une famille de tâches représentative du travail réel, bornée à quelques heures. Définis les exigences communes : tests attendus, documentation, critères de revue et périmètre livré. Les règles d’équipe pour les agents donnent un cadre utile pour garder les mêmes obligations des deux côtés.
Si tu disposes d’une référence antérieure fiable, conserve son contexte. Si elle manque, une ancienne facture ou un souvenir de vitesse ne la reconstitue pas. Le remplacement proposé ici : la même personne, dans la même période, réalise deux tâches comparables sous deux conditions. Leur complexité, leur familiarité et leurs dépendances doivent être décrites avant l’exécution.
Refaire exactement la même tâche donne à la seconde exécution les connaissances acquises pendant la première. Répartis les conditions entre les tâches avant de commencer, par tirage au sort quand c’est possible, puis contrebalance l’ordre sur les paires suivantes. Certaines démarrent avec A, d’autres avec B. Cela réduit des biais ; l’apprentissage, la fatigue et les différences entre tâches restent possibles.
Mesurer jusqu’au travail accepté
Le chronomètre s’arrête au critère de livraison convenu. Une première génération réussie peut encore demander des corrections et une revue longue. Note séparément le temps actif de préparation, d’exécution, de correction et de relecture, puis additionne ces postes humains sans compter deux fois un intervalle.
Garde aussi le délai écoulé et les interruptions : une attente machine peut allonger la livraison sans occuper la personne. À l’inverse, relire pendant cette attente consomme du temps humain. Quand un autre relecteur intervient, son temps rejoint le total. Les reprises après revue restent rattachées à la tâche initiale.
Voici une fiche à renseigner à chaque exécution, sans résultat prérempli :
| Champ | Ce que tu consignes |
|---|---|
| Référence | Paire de tâches, condition, ordre, personne, date, outil et version du modèle |
| Comparabilité | Complexité estimée, familiarité, dépendances et exigences communes |
| Temps | Préparation, exécution active, correction, revue, attente et interruptions séparées |
| Qualité | Critères satisfaits, défauts trouvés, reprises nécessaires et décision d’acceptation |
| Coûts et frictions | Dépense imputable, convention d’allocation, blocages et abandons |
Applique la même grille de qualité aux deux livrables. Si possible, fais relire sans indiquer la condition utilisée. Conserve les échecs et les abandons dans la restitution : exclure les tâches où l’outil bloque améliore artificiellement son bilan.
L’enthousiasme reste une donnée subjective
Dans son étude publiée le 10 juillet 2025, METR a réparti aléatoirement 246 tâches entre conditions avec et sans IA, auprès de 16 développeurs expérimentés sur leurs propres dépôts. Les outils étaient principalement Cursor avec Claude 3.5/3.7 Sonnet. Le temps observé augmentait de 19 %, alors que les participants estimaient encore après l’expérience avoir gagné 20 %.
Ce résultat historique concerne ce contexte et ces outils. METR indique désormais qu’il ne reflète plus l’impact actuel des modèles. Il ne permet donc pas de conclure sur les modèles de 2026. Le décalage documenté entre perception et durée justifie de relever les deux séparément dans ton pilote.
Le volontariat sélectionne aussi les participants. Décris leur expérience initiale et les profils absents ; documenter les frictions ne supprime pas ce biais. Le protocole de départ proposait quatre à six semaines avant rotation pour laisser une place à l’apprentissage. Cette durée est un choix pratique du protocole, aucun seuil scientifique universel. Sépare découverte et usage plus stabilisé, et garde les changements d’outil ou de modèle visibles.
La valeur API s’arrête avant le ROI métier
Une consommation valorisée au tarif API décrit un équivalent d’usage. Elle ne mesure ni une facture effectivement payée ni la valeur du travail livré. Un pourcentage de quota reste également une indication de consommation, sans conversion automatique en euros.
Pour le bilan, distingue dépenses imputables, installation, formation, entretien et temps humain par tâche acceptée. Toute répartition d’un coût partagé porte sa convention. Un éventuel temps libéré devient un bénéfice métier seulement si son usage et sa valorisation sont défendables ; quelques tâches ne prouvent pas une capacité annuelle supplémentaire.
À la restitution, présente les écarts par paire, leur dispersion, la qualité et les cas défavorables. Une comparaison courte et hétérogène peut rester inconclusive. Les principes du workflow agentique aident à borner le travail ; ce protocole sert à mesurer son apport humain, sans couvrir les évaluations automatisées en CI ni le déploiement à l’échelle. Tu peux arrêter, prolonger ou restreindre le pilote. Le résultat reste à obtenir.