Claude Code marche du premier coup. C'est exactement ce qui piège. On lui confie une refonte de composant, elle sort en trois minutes, et on en déduit qu'il est prêt pour la production. Les semaines suivantes servent à découvrir que non — pas parce qu'il code mal, mais parce qu'une démonstration et un run quotidien ne cassent pas aux mêmes endroits.
Ce qui suit vient de nos propres runs, y compris celui qui a produit cet article. Aucun conseil ici ne sort d'une documentation : ce sont des pannes qu'on a eues, et le montage qu'on a gardé après.
Claude Code en production : de quoi on parle exactement
Derrière la requête « claude code production » se cachent trois régimes d'usage régulièrement confondus. Ils n'ont ni les mêmes risques ni le même coût.
L'usage assisté. Un développeur, un terminal, Claude Code ouvert à côté. Quelqu'un lit chaque diff avant qu'il existe ailleurs que sur son disque. C'est le régime le plus répandu, et le seul où une erreur ne coûte rien : elle est vue tout de suite.
L'usage délégué. On lance une tâche longue, on part faire autre chose, on relit le résultat entier au retour. L'erreur coûte du temps de relecture, rien de plus.
L'usage autonome. Claude Code tourne sans terminal, déclenché par une intégration continue, un cron ou un webhook. Personne ne regarde pendant. Le résultat existe avant que quiconque l'ait lu.
Le mot « production » ne devrait désigner que le troisième. Notre agent éditorial est dans ce régime : il se réveille une fois par jour dans une CI, prend une cible dans un cockpit, écrit un article, et l'article part en ligne. Personne ne valide entre les deux. Tout ce qui suit décrit ce qui casse quand on franchit cette ligne.
Ce qui casse en premier : le contexte
La panne la plus fréquente n'est pas une erreur de code. C'est un agent qui respecte parfaitement la consigne pendant vingt minutes, puis dérive.
La cause est mécanique. La fenêtre de contexte est finie. Sur un run long, l'historique dépasse cette fenêtre, il est compacté, et le début de la conversation devient un résumé. Or c'est au début qu'on a mis les consignes. L'agent ne les a pas oubliées par négligence : elles ne sont plus là sous la forme où on les a écrites. Le symptôme classique, c'est une règle scrupuleusement suivie au premier fichier et ignorée au douzième.
Trois choses corrigent ça, dans cet ordre d'efficacité.
Mettre les consignes dans un fichier, pas dans le prompt. Un fichier d'instructions à la racine du projet est relu à chaque session, et il est versionné : on peut le corriger quand on constate une dérive, et la correction tient au run suivant. Un prompt initial de trois cents lignes, lui, est perdu dès la première compaction.
Découper. Un run, une tâche, un livrable. Notre agent éditorial a l'interdiction explicite d'écrire deux articles dans le même run, même quand la file en contient dix. Ce n'est pas une limite de débit, c'est une limite de contexte : le deuxième article serait écrit par un agent qui ne se souvient plus bien de la commande du premier.
Ne pas le laisser explorer. Un agent lâché dans une base de code va lire quarante fichiers pour trouver un champ. Chaque lecture entre dans le contexte, et le contexte est ce qu'on essaie d'économiser. La bonne réponse est de lui donner un outil qui rend la donnée déjà mâchée. Le nôtre reçoit son brief sous forme d'un seul JSON — cibles, articles déjà publiés, catégories, slugs vers lesquels il a le droit de pointer. Il n'a aucune raison de fouiller la base.
Ce qui casse ensuite : les droits
Un agent qui a un shell libre finira par lancer une commande qu'on ne voulait pas. Jamais par malice : parce que cette commande était le chemin le plus court vers le problème posé. Annuler des modifications locales pour repartir propre, supprimer un fichier de sortie qui gêne, committer sur la branche principale, pousser. Chacune de ces actions est raisonnable prise isolément. Aucune n'est acceptable sans témoin.
On peut se défendre à trois niveaux, et ils ne se valent pas.
Le premier, c'est la liste de commandes autorisées, avec confirmation pour le reste. Utile en usage assisté, inopérant en autonome : il n'y a personne pour confirmer, donc soit ça bloque le run, soit on a tout autorisé d'avance.
Le deuxième, ce sont les hooks — du code à soi qui s'exécute avant ou après un appel d'outil et qui peut opposer un veto. C'est le bon endroit pour interdire une catégorie entière d'actions plutôt qu'une commande précise, et ça marche vraiment. C'est aussi du code à maintenir, avec ses propres angles morts.
Le troisième est le seul qui nous ait vraiment tranquillisés : réduire la surface. Pas de shell libre du tout. Notre agent éditorial dispose de sept scripts et de rien d'autre. Il peut lire, écrire dans un dossier temporaire, et appeler ces sept scripts. Pas de commandes git, pas de requêtes réseau libres, aucune écriture dans le dépôt. Il n'a pas besoin de se retenir de pousser sur la branche principale : il ne peut pas. La différence entre « on lui a demandé de ne pas le faire » et « il ne peut pas le faire » est toute la différence entre un prototype et une production.
Ce raisonnement n'est pas propre aux agents de code. C'est le même que pour n'importe quel automate qui écrit dans vos systèmes, et il rejoint directement les questions de gouvernance des données quand on automatise tout.
Un agent sans relecteur écrit ce que personne ne relira
C'est le point qui change tout quand on passe de la démo au run quotidien : il n'y a plus d'œil humain entre la sortie et le monde. Donc tout ce qui peut se vérifier par une règle doit se vérifier par une règle.
Nos garde-fous sur la publication sont volontairement bêtes et non contournables. Une seule porte d'écriture, un script. Un plancher de longueur, sinon on refuse. Au moins trois sections de niveau deux, parce qu'elles font le sommaire. Les liens internes relus dans le markdown et confrontés à la liste des pages réellement publiées : un lien inventé ou vers un brouillon fait échouer la publication. Les URL de remplissage refusées. Les marqueurs de brouillon oubliés dans le texte refusés. Le mot-clé visé doit apparaître dans le titre ou dans le corps, et il doit correspondre à la commande reçue — un article hors sujet ne passe pas.
Ce qu'un validateur ne sait pas faire, il faut le savoir aussi : il vérifie la forme, les liens, la cohérence avec la consigne. Il ne juge pas si le texte est vrai. C'est la limite réelle du montage, et elle impose deux choses.
D'abord, une porte de sortie honorable. Notre agent peut enregistrer un brouillon au lieu de publier, en laissant la cible ouverte et en expliquant ce qu'il n'a pas pu vérifier. Un agent qui n'a que le choix entre publier et échouer publiera.
Ensuite, une règle explicite sur les faits. Aucun chiffre qu'il ne peut pas attribuer, aucun numéro de version, aucun prix affiché. Pas parce que le modèle mentirait, mais parce qu'un fait daté est exactement le type d'information qu'il produit avec assurance et sans source. Sur ces sujets, on écrit la mécanique plutôt que la statistique.
Où part l'argent
Le coût d'un agent de code ne se lit pas sur une grille tarifaire, il se calcule. Le nombre de runs, le nombre d'appels au modèle par run, les tokens envoyés à chaque appel, les tokens produits. C'est tout, et c'est la même arithmétique que pour n'importe quel agent — nous l'avons détaillée dans notre article sur ce que coûte vraiment un agent en production.
Ce qui fait déraper une facture d'agent de code, en revanche, lui est spécifique.
L'exploration à l'aveugle. Un agent qui cherche dans la base de code paie chaque fichier lu, à chaque appel où ce fichier reste dans le contexte. C'est le premier poste, et celui qu'on réduit le plus vite en lui donnant des outils qui répondent à sa place.
La boucle sans plafond. Un agent autorisé à réessayer jusqu'à réussir tournera très longtemps sur le cas qu'il ne sait pas traiter. Un plafond d'itérations et un plafond de dépense sont deux réglages, et ils évitent la facture absurde sur un run bloqué.
Le run qui recommence de zéro. Relancer un run échoué coûte le prix du run entier. D'où l'intérêt d'un état persistant hors du contexte : notre agent retrouve un brouillon commencé la veille au lieu de le réécrire.
L'indicateur à suivre n'est pas la facture mensuelle, c'est le coût par run réussi. C'est le seul qui vous dira dans trois mois que quelque chose a dérivé.
Le montage qu'on garde
Six règles, dans l'ordre où elles nous ont servi.
- Un run, une tâche, un livrable. Le reste attend demain.
- Les consignes dans un fichier versionné, pas dans le prompt. Une dérive constatée se corrige par un commit.
- Des outils, pas un shell. L'agent n'explore pas, il appelle.
- Une porte d'écriture unique et validée. Tout ce qui se vérifie mécaniquement est vérifié là, et nulle part ailleurs.
- Une porte de sortie honorable. Le brouillon, l'abandon documenté, le « je n'ai pas pu vérifier ». Sinon l'agent force.
- Un rapport de fin de run lisible en trente secondes. Ce qu'il a fait, ce qu'il a volontairement omis, ce qu'un humain devrait relire en priorité. C'est ce rapport qui rend l'autonomie supportable.
Ce montage est le même que celui d'un workflow d'automatisation classique, avec une différence : la partie qui décide est non déterministe. Tout le reste doit l'être. C'est pour ça que la plupart du travail de mise en production de Claude Code n'est pas du prompt engineering, mais de la plomberie ordinaire — des scripts, des validateurs, des journaux.
Ce qu'on ne lui confie pas
Quatre catégories, aujourd'hui, restent hors du régime autonome chez nous.
Tout ce qui touche à de l'argent ou à un client. Un devis, une facture, un mail sortant. Le coût d'une erreur y est immédiat et public.
Les migrations de base destructives. Un agent qui se trompe sur une suppression de colonne ou de ligne ne laisse rien à réparer. Il propose la migration, un humain l'applique.
Les faits datés sans source. Prix, versions, noms de fonctionnalités récentes. On lui interdit d'en écrire plutôt que de les corriger après.
Les décisions d'architecture. Non par principe, mais parce qu'elles se paient sur des mois et qu'un run de vingt minutes n'a pas le contexte pour les prendre.
Le reste — le contenu, la revue de code, la préparation de tâches, le travail répétitif sur une base connue — tourne, et tourne bien. Si vous voulez monter ce genre de dispositif chez vous, c'est exactement ce qu'on outille dans nos accompagnements Claude Code : le périmètre, les garde-fous, et le rapport de run avant la première ligne de code.
