Ces derniers mois, j'ai vu passer une avalanche d'« ultimate prompts » pour Claude Code, des collections de 30 MCP indispensables et des skills qu'il « faut » installer pour être productif avec l'IA. J'ai voulu tester l'hypothèse inverse sur mes propres données : vous n'avez besoin d'aucun d'entre eux. Vous avez besoin de traiter l'IA exactement comme vous traiteriez une équipe d'ingénieurs.
J'ai donc fait quelque chose de légèrement méta : j'ai demandé à Claude Code de lire sa propre histoire. Chaque session Claude Code est enregistrée localement, en JSONL, dans ~/.claude/projects/. J'ai fait analyser à l'IA tout le mois de juillet — chaque prompt que je lui ai écrit, chaque appel d'outil qu'elle a fait, chaque erreur — et je lui ai demandé de m'évaluer. Sans ménagement.
Le résultat : 107 sessions en 22 jours ouvrés, 599 prompts réels, 14 608 appels d'outils, 312 Mo de transcript. Le travail d'une seule personne — moi — pour le client principal de la société, un produit e-commerce américain, plus les projets internes.
Et le verdict court : la stratégie fonctionne. Voici les chiffres, les principes qui les sous-tendent et — parce qu'un audit qui ne trouve que du bon n'est pas un audit — les endroits où je me trompe exactement comme un mauvais manager.
Les chiffres qui comptent
Sur 107 sessions, environ 95% se sont closes avec le résultat livré et vérifié — commit, déploiement, vérification sur l'environnement réel, ticket avancé. Seules 4 à 5 sessions ont été réellement abandonnées, la plupart pour des raisons banales (l'une parce que je l'avais glorieusement lancée dans le mauvais projet).
Le taux de correction — le nombre de fois où j'ai dû dire « ça ne marche pas », « faux », « refais » — a été de 8% de tous les messages de suivi. Le maximum absolu dans une seule session : 4 corrections. Zéro boucle de frustration, zéro session où l'IA m'a fait tourner en rond. Ce récit existe, mais pas dans mes données.
Et peut-être mon chiffre préféré, parce qu'il ne parle pas d'IA mais de vie : tout ce mois s'est déroulé entre 9h et 19h, zéro session le week-end, deux sessions après 21h dans tout le mois. Le volume d'une petite équipe, livré par une seule personne, sur un horaire humain normal.
D'où viennent ces résultats ? Pas de prompts spéciaux. De trois principes que tout ingénieur expérimenté connaît déjà — parce que ce sont les principes avec lesquels on travaille avec des humains.
Principe 1 : un bon prompt est un bon ticket
La découverte la plus nette de l'audit concerne la longueur et la structure du premier message d'une session. La distribution est bimodale, et l'écart de résultat est brutal :
- Les prompts de moins de 120 caractères — du genre « allons voir ça aussi » — ont systématiquement produit 2 à 4 allers-retours de clarification et des appels d'outils à l'aveugle où l'IA devine ce que je veux.
- Les prompts de plus de 700 caractères — 19 dans tout le mois — ont eu une médiane d'un seul prompt par tâche close. Vous écrivez la spec, vous partez, la tâche est faite.
Qu'ont en commun ces 19 ? Aucune formule magique. Ils ont exactement la structure d'un ticket bien écrit : le fichier et la ligne, le comportement actuel, une preuve concrète (un numéro de commande, un request ID, une ligne de log), le comportement souhaité et le critère d'acceptation. La tâche la plus efficace du mois — un bug d'e-mails perdus dans un handler Lambda — a été résolue à partir d'un seul prompt de ~900 caractères contenant tout ce qui précède : un prompt, 75 appels d'outils, zéro correction, correctif en production.
À l'inverse, l'incident le plus coûteux du mois est parti d'un « ici » non défini : j'ai demandé une modification « ici », l'IA a compris « partout », a mis à jour tous les enregistrements en production, et quelques échanges plus tard j'ai reconnu dans le chat : « c'est moi qui ai mal lu la spec ». Avec un ingénieur humain, le même ticket vague aurait produit les mêmes dégâts — sauf que je l'aurais appris à la démo, pas en dix minutes.
Distillée, la règle que j'applique désormais tient en trois lignes, pas en 700 caractères :
OÙ : fichier / page / URL exacts — pas « ici », pas « ça »
ACTUEL : ce qui se passe + une preuve — ID, log, capture
VEUX : le critère d'acceptation — comment on sait que c'est fini
Ce n'est pas du prompt engineering. C'est ce qu'un lead exige de n'importe quel ticket depuis 15 ans. La compétence existe déjà dans le métier ; il suffit de l'appliquer aussi à la machine.
Principe 2 : un processus minimal, pas une collection d'outils
Ma pile d'« AI tooling » est d'une brièveté gênante : le terminal, un navigateur piloté par le MCP Chrome et le task tracker. C'est tout. Je n'ai pas 15 MCP installés, je n'ai pas de bibliothèque de skills téléchargés depuis GitHub. J'ai écrit sur mon flux de travail Claude Code dans le terminal et, pour l'essentiel, presque rien n'a changé depuis.
Les données confirment qu'il ne manque rien : 50% de tous les appels d'outils de juillet sont du Bash simple — grep, git, curl, cat. L'IA travaille avec les mêmes outils primitifs que n'importe quel ingénieur dans un terminal, et ça suffit.
Le seul MCP qui compte vraiment, c'est le navigateur — et pas parce qu'il est sophistiqué, mais à cause de son rôle dans le processus : la vérification sur l'environnement réel. L'instruction qui revient de façon obsessionnelle dans mes sessions, c'est « vérifie avec Chrome sur l'environnement réel, pas en preview ». L'audit l'identifie comme la raison directe du taux d'aboutissement de 95% : rien n'est déclaré fini tant que ça n'a pas été vu fonctionner là où ça tourne vraiment.
Autrement dit : ce ne sont pas les outils qui vous manquent. C'est une « definition of done » que vous appliquez sans exception.
Principe 3 : traitez l'IA comme une équipe d'ingénieurs
C'est le cœur du sujet. En regardant mes propres sessions, tout ce qui fonctionne est une vieille pratique de management d'équipe, appliquée à une « équipe » qui répond en quelques secondes :
Design review avant le code. « Fais-moi un plan d'implémentation et dis-moi » apparaît dans ~20 sessions en juillet. Nombre de corrections dans ces sessions : zéro. Ce n'est pas un hasard — c'est la même raison pour laquelle on ne laisse pas un nouveau collègue écrire du code dans un système inconnu sans avoir d'abord discuté de l'approche.
Accès limité tant que le problème n'est pas compris. « READ-ONLY, on analyse seulement, on ne modifie rien » — utilisé systématiquement pour les investigations. Accidents en production causés par des sessions d'analyse : zéro.
Relecture avant toute sortie publique. « Montre-moi le commentaire avant de le poster sur le ticket. » Exactement ce qu'on demande à un junior avant qu'il réponde au client.
Discipline de déploiement. Commit → push → build → vérification sur l'environnement réel → ticket déplacé en Verify avec un court commentaire. Répété de façon constante sur ~60 sessions de tickets.
Et la découverte la plus intéressante de l'audit, celle qui m'a le plus amusé : les meilleurs prompts de juillet, ce n'est pas moi qui les ai écrits. C'est la machine. Quand une session délègue une tâche à une nouvelle session (en lançant des tâches dans des worktrees séparés), la spec générée automatiquement fait ~900 caractères en médiane et présente la structure complète d'un ticket — et ces 12 sessions déléguées se sont toutes closes avec une médiane d'un prompt par tâche. L'IA a appris le format à partir de mon processus et l'applique plus rigoureusement que moi. Cela ne fragilise pas ma thèse — cela la confirme : c'est le processus qui est transférable, pas un quelconque talent de « prompteur ».
Là où je me trompe — et pourquoi c'est rassurant
Un audit qui ne trouve rien de mauvais est de la propagande. Le mien en a trouvé pas mal, et la partie vraiment rassurante, c'est que toutes mes erreurs avec l'IA sont des erreurs classiques de management humain :
Micromanagement. 31% de mes tours comptent moins de 3 appels d'outils — donc un tiers des interactions se résument à « fais exactement cette petite étape ». J'ai répété la même consigne de processus (« quand tu as fini : commit, push, build, vérifie ») plus de 25 fois en un mois, au lieu de l'écrire une seule fois dans CLAUDE.md — l'équivalent d'un onboarding écrit une fois, pas récité à chaque tâche. Pendant ce temps, la vraie délégation (agents, tâches lancées en parallèle) n'a été utilisée que 34 fois sur 107 sessions.
Tickets vagues. « on a ça ? » — 14 caractères, faute de frappe comprise — a généré 156 appels d'outils pendant lesquels l'IA a cherché toute seule ce que je voulais dire. Elle a trouvé, mais j'ai payé en temps et en tokens. Avec un humain, le même message sur Slack aurait produit un « tu parles de quoi ? » et dix minutes perdues.
Réunions marathon. Une session du 13 juillet : 15 tickets différents, 41 prompts, 547 appels d'outils, presque 18 Mo de contexte. Au ticket 12, le contexte des 11 premiers n'est que du lest — l'audit montre que 17% des lectures de fichiers de juillet sont des relectures du même fichier dans la même session, signe direct d'un contexte gonflé. La bonne règle est la même qu'avec les humains : un sujet, une réunion. Un ticket, une session.
Vérification coûteuse. 1 405 captures d'écran de navigateur en un mois — 41% de tout le volume de données des sessions — dont la plupart « lisaient » du texte qui aurait pu être extrait dix fois moins cher depuis le DOM. Dans une seule session : 127 captures. La leçon, valable aussi pour les rapports qu'on demande aux humains : demandez le format le moins cher qui répond à la question.
Précision : ça reste automatique — seul le canal change
Après la publication, on m'a posé une bonne question : « la recommandation sur les captures d'écran veut-elle dire plus de vérification manuelle ? » Non — et ça mérite d'être dit explicitement, parce que la distinction est facile à manquer.
La vérification automatique sur l'environnement réel ne se négocie pas : c'est la raison directe du taux d'aboutissement de 95% et exactement ce qui me permet de déléguer une tâche et de partir. La recommandation ne porte que sur le canal. Une capture d'écran et une lecture du DOM (read_page, console, réseau) sont tout aussi automatiques — elles ne diffèrent que par leur coût. Quand la vérification est en fait textuelle (« le message X apparaît », « la requête renvoie 200 »), le DOM répond à la même question pour une fraction du contexte. Les captures restent pour ce qui se vérifie à l'œil : mise en page, images, style.
Et la partie contre-intuitive : un contexte gonflé est l'ennemi du parallélisme, pas son ami. Une session avec 127 captures remplit sa fenêtre, se met à relire des fichiers (d'où les 17% de relectures) et meurt plus vite. La même session, en vérifiant par le DOM quand c'est possible, vit plus longtemps et laisse de la place pour lancer plus de sessions en parallèle. Vous vérifiez autant, tout aussi automatiquement — vous ne payez le prix de l'image que là où une image voit vraiment quelque chose.
Aucun de ces problèmes n'est « l'IA hallucine » ou « l'IA n'en est pas capable ». Tous portent sur la façon dont je la dirige. La seule différence avec une équipe humaine, c'est la vitesse de la boucle de retour : mes erreurs de management se voient en minutes, pas au bout d'un sprint. Ce qui, à bien y réfléchir, est la formation au management la plus rapide que j'aie jamais suivie.
Ce que je change en août
L'audit s'est terminé sur cinq actions concrètes, que je laisse ici parce qu'elles s'appliquent à tout le monde :
- Le processus répété va dans CLAUDE.md, pas dans le prompt. Écrit une fois, toujours appliqué, sans variation accidentelle.
- La règle des trois lignes (OÙ / ACTUEL / VEUX) pour tout prompt initial. Pas de « ici », pas de « ça ».
- Un ticket = une session. Et le corollaire inverse : quatre petites tâches liées font un seul prompt avec une liste, pas quatre sessions.
- Le repo explicitement en première ligne du prompt — j'ai eu 11 sessions lancées depuis le mauvais répertoire, dont une entièrement perdue à cause de ça.
- Des captures uniquement pour ce qui se vérifie à l'œil (mise en page, contraste, images). Pour le texte et la structure, l'extraction depuis la page est dix fois moins chère. Bonus sécurité : jamais de capture sur des interfaces d'admin contenant des secrets.
Dans un mois, je relance le même audit sur août et on verra si les chiffres bougent. C'est, au fond, l'avantage du fait que tout soit journalisé : le management de votre équipe d'IA est le premier management de l'histoire à être entièrement mesurable.
Comme d'habitude, mon avertissement : je crois que l'IA est l'avenir de notre métier et que les problèmes d'aujourd'hui — le contexte qui gonfle, la vérification coûteuse, le besoin de supervision — seront résolus. Mais l'état actuel mérite d'être discuté exactement tel qu'il est, avec des données, pas avec de l'enthousiasme ou de la panique. Les chiffres de cet article proviennent de l'audit de mes propres sessions Claude Code sur juillet 2026 ; la méthode est décrite dans l'article et peut être répliquée par quiconque dispose d'un répertoire ~/.claude/projects/ et d'une heure de libre.