Tout le monde utilise l’IA pour coder plus vite. Ce que personne ne dit, c’est que chaque prompt te rajoute deux fois plus de travail. C’est précisément ce travail-là qui te rend irremplaçable.
Depuis décembre 2025, le rapport s’est inversé : environ 80 % du code est écrit par des agents, et la relecture humaine représente les 20 % restants. Si tu es développeur junior ou intermédiaire, c’est un vrai problème : les tâches qui m’ont permis d’apprendre ce métier sont aujourd’hui faites par des agents. Cet article prolonge la vidéo ci-dessous avec la stratégie pour t’adapter à ce nouveau paradigme.
Le piège du prompt gambling
Copier-coller des tickets Jira dans un agent de code donne l’impression d’avoir une longueur d’avance. C’est faux : tout le monde utilise déjà des agents pour les tâches bien définies. Tout le monde avance à un rythme « voiture ». L’outil en lui-même n’est plus un avantage concurrentiel.
Le piège le plus sournois, je l’appelle le prompt gambling. Dès qu’une tâche se présente, on se dit qu’on pourrait la déléguer à l’IA. Un ticket pas clair ? Je demande à l’IA de le reformuler. Et pendant que j’écris ce prompt, je me dis que je pourrais demander à l’IA d’écrire le prompt. On n’arrive plus jamais à rallumer le cerveau. L’IA coche toutes les cases d’une machine à sous : aucun coût à l’entrée, récompense aléatoire à chaque tirage, et toujours plus simple de commencer par un prompt que de commencer à réfléchir.
Ma parade : une méthodologie hors IA. Des tâches où je m’interdis l’IA, des créneaux de réflexion dans mon calendrier avant de mettre les agents au travail, et une journée entière sans IA par semaine. Mes meilleures idées de déblocage viennent de ces temps de recul, souvent loin de l’ordinateur.
La technique du sandwich
Le principe qui structure tout le reste : à chaque fois que tu mets une IA au travail, tu crées deux nouvelles tâches humaines.
- En amont : définir précisément ce que l’agent doit faire, avec quel contexte.
- En aval : être capable de vérifier que son travail est réellement correct.
L’objectif est de devenir l’expert dont l’IA a besoin, pas celui qu’elle remplace. Voyons la méthode complète sur un cas réel : deux bugs « froids » trouvés en production, sur du code livré il y a des mois, donc sans contexte métier ni technique au départ.
Étape 1 : Comprendre le problème à haut niveau (0 % d’IA)
Mes deux bugs : une mise en page cassée sur MacBook 13 pouces (trois éléments dont un passe sous la ligne de flottaison), et un formulaire dont le bouton « soumettre » ne fait rien.
Instinctivement, le formulaire bloqué semble plus grave. En prenant de la hauteur : le bug responsive concerne une release lancée la semaine suivante, 80 % des clients du produit utilisent un MacBook 13 pouces, et l’élément masqué déclenche une décision de conversion. Le formulaire bloqué, lui, ne touche que 5 % d’utilisateurs sur une ancienne version, avec un contournement possible via le support.
Le bug « bénin » était le plus urgent pour le business. Ce contexte, tu dois le construire toi-même : aucun prompt ne peut le faire à ta place, et c’est exactement l’ownership qui te rend indispensable. Demain, avec 5 ou 10 tickets par jour, celui qui n’a pas fait cet effort priorisera mal. Il ne saura ni expliquer ni vendre la valeur de son travail.
Étape 2 : Reproduire le bug (0 % d’IA)
Tant que tu n’as pas reproduit le bug en local, tu ne peux pas vérifier le correctif de l’agent. Le prompt « installe mon environnement et reproduis le bug devant moi » n’existe pas encore.
C’est l’une des seules étapes où l’on est content d’avoir le problème : si tu reproduis le bug, l’étape est validée. Pour mes deux bugs, il a fallu simuler un écran 13 pouces depuis un poste Windows, et recréer des données de production absentes de mon environnement local. C’est du vrai travail et il est à toi.
Newsletter Codeur Senior
Passez de l'exécution au produit.
Recevez les prochaines analyses pour sortir de la régie, piloter des agents sous vos standards et construire une preuve qu'une boîte produit peut évaluer.
Étape 3 : Identifier la root cause (avec l’agent, enfin)
Maintenant que tu as le contexte métier et la reproduction, l’agent devient redoutablement efficace. Les agents fonctionnent autour de trois grandes instructions : chercher largement, planifier, exécuter. Donne des instructions directes et claires sur la page, le composant et le comportement attendu. Demande ensuite à l’agent de prendre le temps de la réflexion avec le mode de raisonnement renforcé de ton outil.
Dans au moins 80 % des cas, avec les étapes préliminaires faites et des instructions claires, l’agent identifie la root cause quelle que soit la taille de la codebase. Ici, il a montré qu’une équipe contributrice externe avait introduit le bug en livrant une fonctionnalité récente. Cela correspond à mon hypothèse : un bug aussi visible aurait été signalé depuis longtemps. En quelques minutes, j’ai obtenu ce qui m’aurait autrefois coûté des heures de debugger.
Étape 4 : Make it work (l’agent corrige)
Résiste encore à l’envie de foncer dans l’implémentation. Deux prompts suffisent : « planifie le fix », puis, après relecture du plan, « implémente ». L’agent fait ici 80 % du travail. Tu as tout ce qu’il faut pour le vérifier : la root cause, le contexte métier et la reproduction locale.
Étape 5 : Make it right (passer la CI, livrer, tracer)
Un correctif sur ton PC ne produit aucune valeur. Il faut passer la CI, déployer en préproduction puis en production, et assurer la traçabilité du ticket auprès des équipes produit.
C’est aussi le moment de challenger le fix : le premier correctif proposé par l’agent ajoutait une balise style directement dans le HTML. J’ai préféré appliquer la règle au niveau du composant hôte dans Angular, via host dans le décorateur @Component. Demande-toi si le fix crée de la dette technique ou s’il s’aligne avec les standards de l’équipe.
Étape 6 : Make it fast (la root cause de la root cause)
Le bug est livré, mais il reste la question systémique : qu’est-ce qui, dans la codebase, a rendu ce bug possible ? Une règle de linter aurait-elle pu l’empêcher définitivement ? Des tests auraient-ils protégé cette zone ?
Sur mon cas, deux découvertes : un temps de démarrage anormal de plus de 137 secondes à investiguer, et le fait que les styles inline dans le HTML rendent ces bugs de responsive faciles à introduire. Une règle de linter permettrait de les interdire. C’est ainsi qu’on élève la barre pour toute l’équipe au lieu de corriger des bugs à la chaîne.
Rester l’écrivain, pas le copiste
Cette méthode a un fil rouge : l’IA fait l’essentiel de l’exécution aux étapes 3 et 4, mais les étapes qui créent ta valeur restent humaines : le contexte business, la reproduction, la revue critique et l’amélioration systémique. C’est la technique du sandwich appliquée de bout en bout.