Claude Code en production : retour d'expérience

Claude Code n'est pas un remplaçant d'ingénieur. C'est un multiplicateur très particulier.

J'utilise Claude Code sur de vrais projets clients, pas dans des repos de démo construits pour flatter l'outil. Mon retour d'expérience est donc assez simple : ce n'est pas un avis de produit, c'est un rapport de terrain. Dans le bon contexte, Claude Code est vraiment utile. Dans le mauvais, il produit surtout une illusion de vitesse. Comme agent de code, il n'est pas intéressant parce qu'il écrit du code à votre place. Il devient intéressant quand il absorbe une partie de l'exécution concrète qui ralentit un ingénieur déjà capable de prendre les bonnes décisions.

C'est une différence importante pour qui travaille sur de l'IA en production. Beaucoup de discussions sur le développement assisté par IA restent prisonnières d'une question théâtrale : est-ce que l'outil peut shipper tout seul ? Ce n'est pas la bonne barre. La bonne question est plutôt : sur quelles classes de tâches cet outil réduit-il vraiment le temps entre intention, implémentation et vérification, sans augmenter le risque de manière stupide ? C'est sous cet angle que Claude Code me paraît utile, et c'est aussi sous cet angle qu'il expose vite ses limites.

Là où il est franchement bon : prendre en charge le milieu du travail

Claude Code n'est pas ce que je préfère pour définir une architecture à partir d'une page blanche ou pour arbitrer un problème produit encore flou. En revanche, il est très bon dans ce que j'appelle le milieu du travail : suivre une trace d'erreur, comprendre une convention déjà en place, appliquer un pattern sur plusieurs fichiers, corriger une batterie de types, mettre à jour des tests, ou préparer un refactor localisé sans se perdre. Sur ces sujets, l'agent de code va souvent plus vite que moi sur la mécanique pure, à condition que le repo soit lisible et que le critère de succès soit clair.

La qualité la plus sous-estimée de Claude Code est sa persistance. Si je lui donne les bons chemins, les contraintes, les commandes de vérification et les non-objectifs, il tient la boucle d'exécution de manière assez fiable. Il lit, propose, modifie, teste, puis revient avec quelque chose d'auditable. Pour moi, la vraie promesse du développement assisté par IA n'est donc pas de remplacer l'ingénieur senior. C'est de compresser la zone la plus répétitive entre une décision déjà prise et un changement vraiment mergeable.

Là où il casse : ambiguïté, faux contexte et jugement surestimé

La contrepartie est nette. Claude Code casse dès que le contexte utile n'est pas explicite. Si les vraies règles vivent dans la tête d'un PM, dans un Slack oublié, dans un ticket contradictoire ou dans une branche sale, il improvise. Et quand un système de ce type improvise, il le fait avec beaucoup trop d'assurance. J'ai vu Claude Code corriger proprement le symptôme local d'un problème tout en passant à côté de la cause systémique. Si le prompt dit seulement "fixe le build", il peut très bien choisir la manière la plus courte de faire taire l'erreur plutôt que la bonne manière de réparer le système.

Autre mode d'échec : le contexte excessif. Beaucoup pensent qu'il suffit de donner plus de fichiers, plus de logs, plus d'historique. En pratique, un contexte bruyant dégrade vite la qualité du tri. Claude Code devient moins bon quand on lui verse le repo sur la tête sans signal de priorité. En ingénierie IA, je traite donc le contexte comme une ressource rare. Je préfère un dossier compact avec objectif, fichiers sources de vérité, invariants, commandes de validation et conditions d'arrêt. Moins de bruit, plus de cadre.

Les prompts qui marchent ressemblent à des tickets d'exécution

Les meilleurs prompts que j'écris pour Claude Code ne ressemblent presque jamais à une conversation libre. Ils ressemblent à un ticket d'exécution bien cadré. J'y mets cinq choses : le résultat attendu, où regarder en premier, ce qui ne doit pas être cassé, comment vérifier, et ce qu'il n'a pas le droit de toucher. Ce formalisme change tout. Il force l'humain à clarifier la tâche, et il donne à l'outil une structure exploitable. Quand le sujet est plus large, je découpe en boucles courtes : lecture, plan, tranche d'exécution, vérification. Claude Code travaille nettement mieux ainsi.

Ce que cela change dans mon workflow d'ingénieur IA

Le changement le plus profond n'est pas que j'écris moins. C'est que je cadre beaucoup plus explicitement. Je documente mieux les repères du repo, je rends les critères d'acceptation plus concrets, et je transforme davantage de connaissance tacite en checklists. Mon workflow d'ingénierie IA devient plus proche d'un pilotage de contexte et de vérification que d'un simple exercice de frappe rapide. Je ne confierais pas à Claude Code un arbitrage d'architecture critique sans supervision, mais je l'utilise volontiers chaque semaine parce qu'il est déjà rentable sur une grande partie du travail d'exécution.