Développement Agentic : Laisser Claude Piloter Toute la Boucle

En octobre dernier, j'ai confié à Claude une tâche plutôt banale : « Génère un wrapper pour l'API REST de WordPress en PHP, écris des tests PHPUnit pour lui, lance-les, corrige les dysfonctionnements. » Je lui ai donné accès à mon terminal via une configuration locale d'utilisation d'outils Claude et je suis parti me faire un thé. Je suis revenu douze minutes plus tard. Les tests étaient au vert. J'avais un wrapper fonctionnel avec 94 % de couverture et un petit commentaire inline où Claude avait détecté un cas limite que je n'avais pas mentionné dans le cahier des charges. Je suis resté là, dans ma cuisine à Bermondsey, véritablement déstabilisé.

C'est du développement agentic. Pas de l'autocomplétion, pas un Stack Overflow plus intelligent. Un modèle qui raisonne sur un objectif, choisit l'action suivante, l'exécute, observe le résultat, et boucle jusqu'à la fin. Et c'a changé comment j'orchestrais les projets chez Seahawk Media plus vite que presque n'importe quoi en mes neuf ans là-bas.

Ce que « Agentic » Signifie Vraiment (Et Ce Qu'il Ne Signifie Pas)

Soyons précis, parce que ce mot est jeté à la légère partout. Une boucle agentic IA a trois choses : un objectif, un ensemble d'outils, et la capacité de décider quoi faire ensuite en fonction de ce qui vient de se passer. Le modèle ne génère pas juste du texte. Il agit, observe et replanie.

Ce que ce n'est pas, c'est de la magie. Le modèle peut toujours halluciner une signature de fonction. Il peut se boucler dans un coin en faisant le même mauvais correctif sept fois. Il peut mal comprendre ton objectif à l'étape une et construire avec assurance dans la mauvaise direction pendant dix étapes. J'ai vu tout ça. Une fois, sur un projet de tableau de bord React, Claude a passé environ vingt minutes à ajouter des vérifications null de plus en plus baroques pour résoudre un problème qui était en réalité un await manquant. Celui-là, c'était de ma faute, je lui avais donné une spécification initiale vague.

La distinction qui compte pour les praticiens : les tâches agentiques étroitement ciblées battent les tâches ouvertes. « Écrire et tester une fonction de sanitisation de slug qui gère l'arabe, le japonais et les emoji » est une excellente tâche agentique. « Construis-moi un SaaS » n'en est pas une. Délimitez le champ étroitement, sinon vous passerez plus de temps à examiner les mauvais virages que vous n'auriez passé à écrire le code.

La Stack Réelle que j'utilise

Les outils comptent énormément ici. Sans le bon échafaudage, « Claude agentique » n'est qu'une fenêtre de chat.

Ma setup chez Seahawk :

• [Claude API](https://www.anthropic.com/api) avec utilisation d'outils, spécifiquement la bêta computer_use et des outils personnalisés bash/système de fichiers
• Cursor comme couche IDE, avec Claude 3.5 Sonnet configuré comme modèle backend
• pytest / PHPUnit / Jest selon le projet, parce que Claude a besoin d'un signal déterministe pour boucler dessus. Sans résultats de test, il vole à l'aveugle.
• Un court system prompt qui indique à Claude quelle est la structure du projet, quels sont les standards de codage, et, c'est important, d'arrêter et demander s'il est sur le point de créer un nouveau fichier en dehors du répertoire spécifié.

Cette dernière contrainte semble mineure. Ce ne l'est pas. Les modèles agentiques vont volontiers échafauder des modules entièrement nouveaux s'ils pensent que cela sert l'objectif. Les garde-fous sur le système de fichiers m'ont sauvé de plusieurs moments « d'où vient cela ? ».

Une chose que je n'utilise pas : les frameworks d'orchestration multi-agents pour la plupart du travail. LangChain, AutoGen, CrewAI, c'est véritablement intéressant, mais pour un développeur solo ou une petite agence, la surcharge de configuration d'agents qui se parlent n'en vaut généralement pas la peine. Une boucle Claude bien ciblée vaut mieux que trois agents mal ciblés qui se crient dessus.

Comment je structure une tâche qui vaut la peine d'être bouclée

Voici ce que j'ai finalisé après probablement 200+ sessions agentic cette année. Donnez au modèle un brief de tâche qui contient quatre choses :

1. L'objectif, spécifique, testable, assez petit pour être terminé en moins de 30 étapes
2. L'état de départ, quels fichiers existent, quels tests passent déjà
3. La condition de succès, généralement « tous les tests au vert » ou une signature de fonction spécifique qu'il doit produire
4. La condition d'arrêt, « si vous avez essayé le même correctif plus de trois fois, arrêtez et expliquez pourquoi vous êtes bloqué »

Celui-ci est sous-estimé. Sans lui, Claude va parfois boucler indéfiniment. Pas indéfiniment-indéfiniment, mais j'ai vu faire 18 tentatives sur un problème de regex épineux, chacune légèrement différente, aucune correcte, jamais s'arrêter pour dire « je ne suis pas sûr. » Le lui dire explicitement de mettre en avant la confusion est quelque chose que la spécification du modèle Anthropic aborde en termes d'approche du modèle face à l'incertitude, mais en pratique, vous avez quand même besoin de le demander en prompt.

En 2022, un client nous a confié un travail migrant 14 000 listes de produits d'une ancienne installation Magento vers WooCommerce. À ce moment-là, Claude ne faisait pas de boucles agentic, donc nous avons écrit les scripts de migration à la main sur deux semaines. Le même travail aujourd'hui ? J'écrirais un spec serré, le confierais à Claude avec accès lecture au schéma de la base Magento et accès écriture à une instance WooCommerce de test, et le laisserais tourner. Je pense sincèrement que nous aurions terminé en deux jours. C'est le delta.

Où Claude est étonnamment bon

Refactoriser du code existant

C'est là où j'ai été le plus impressionné. Donnez-lui une classe désordonnée de 400 lignes, dites-lui de refactoriser vers la responsabilité unique, et laissez-le exécuter ses propres tests unitaires comme points de contrôle. Il maintient le contexte sur tout le fichier mieux que je ne l'aurais prévu et il fait vraiment attention à ne pas casser les tests qui passent. Le résultat n'est pas toujours l'architecture que j'aurais choisie, mais c'est généralement défendable.

Écrire des tests pour du code que vous n'avez pas écrit

Seahawk faisait beaucoup d'audits et de sauvetages de sites. On héritait de bases de code tout le temps, souvent sans aucun test et sans le dev original en vue. J'ai commencé à utiliser Claude agentic spécifiquement pour écrire une suite de tests pour le code hérité avant qu'on y touche. Il lit la source, déduit l'intention à partir des noms de fonctions et des commentaires, écrit les tests, les lance, et ajuste quand quelque chose échoue inopinément. Une fois il a détecté un bug de corruption de données silencieuse dans un gestionnaire de commande WooCommerce personnalisé qui avait probablement trainé là depuis deux ans. Personne ne le savait.

Broyer la boîte à outils

Échafaudage de points de terminaison REST, migrations CRUD, formulaires de panneau d'administration. Le truc ennuyeux qui prend un après-midi à un développeur compétent et que personne n'aime. Claude est rapide et cohérent ici, et la cohérence est effectivement ce que vous voulez dans la boîte à outils, il ne devient pas créatif, il ne se fatigue pas, il fait juste de la correspondance de motifs sur votre code existant et l'étend.

Là où ça tourne mal

Honnêtement, les échecs sont instructifs. Voici ceux que j'ai rencontrés le plus souvent :

• Débordement de fenêtre de contexte sur les grandes bases de code. Claude 3.5 Sonnet a une fenêtre de contexte de 200k tokens, ce qui semble énorme jusqu'à ce que vous le nourrissiez avec un plugin WP complet avec 40 fichiers. Il commence à oublier les choses qu'il a vues au début de la session. Solution : diviser le travail en boucles plus petites avec des points de contrôle explicites.
• Confiance sur des choses sur lesquelles il ne devrait pas être confiant. Claude va corriger une requête de base de données, exécuter le test, il passe, et signaler le succès, mais la requête est maintenant subtilement moins efficace parce qu'il a échangé une clause WHERE adaptée aux index pour une sous-requête. Il a résolu le problème déclaré et en a créé un non déclaré. L'examen du code est toujours important.
• Augmentation des permissions des outils. Si vous lui donnez un accès bash sans le contraindre, il va exécuter npm install pour des paquets que vous n'avez pas demandés, ou pire, faire une requête réseau que vous n'avez pas autorisée. Ce n'est pas malveillant, c'est le modèle qui fait ce qui semble utile. Définissez vos permissions d'outils avant de commencer, pas après qu'un truc bizarre se produise.

Une note sur la sécurité : si vous exécutez des boucles d'agent contre quoi que ce soit connecté aux données de production, lisez les recommandations d'Anthropic sur la sécurité de l'utilisation d'outils. Ce n'est pas long, et ça vous évitera une mauvaise journée.

Prompting pour le comportement d'agent vs. le comportement de chat

Le modèle de prompting est différent et c'est ce qui trompe les gens. Dans un contexte de chat, vous êtes conversationnel, itératif, allez-retour. Dans un contexte d'agent, le prompt initial est un document de spécification. Vous ne serez pas là pour clarifier en cours de tâche.

Les choses qui font fonctionner les prompts d'agents :

1. Énoncez les contraintes en premier, pas en dernier. La plupart des gens les cachent.
2. Dites-lui ce qu'il ne faut pas faire. « Ne modifiez aucun fichier en dehors de /src/utils » est plus utile que dix lignes d'instructions positives.
3. Donnez-lui une échappatoire. « Si vous atteignez un point de décision où continuer nécessiterait de modifier le schéma de la base de données, arrêtez et rédigez un résumé du pourquoi. »
4. Référencez la commande du test runner explicitement. « Exécutez ./vendor/bin/phpunit tests/ après chaque modification et utilisez la sortie pour guider votre prochaine étape. »

Le changement de cadrage est : vous rédigez un cahier des charges pour un contractant très capable mais qui ne peut pas poser de questions. Alors écrivez comme on le ferait.

Le cadran d'autonomie : à quel point laisser tourner

C'est la question que je reçois le plus souvent d'autres agences. Est-ce qu'on le surveille ou on le laisse faire ?

Ma réponse après un an : ça dépend entièrement de la réversibilité des actions. Recherche en lecture seule, rédaction de tests, échafaudage dans un nouveau répertoire, laisse tourner. Tout ce qui touche à une base de données en production, modifie les manifestes de paquets, ou interagit avec des API externes, vérifiez tous les quelques étapes, ou au moins lisez le plan avant qu'il s'exécute.

Le motif de prompting ReAct (Reason + Act, tiré de l'article Yao et al. de 2022) vaut le coup d'être compris ici. C'est essentiellement ce que Claude fait en interne quand on lui donne des outils : ça réfléchit à voix haute sur ce qu'il faut faire, le fait, lit le résultat, réfléchit à nouveau. Rendre ce raisonnement visible, demander à Claude d'imprimer son plan avant chaque action, vous donne un point de contrôle naturel sans casser la boucle.

J'ai commencé à traiter la sortie de raisonnement étape par étape de Claude comme je traite une PR d'un développeur junior. Je la survole. Si quelque chose me semble bizarre, j'interviens. Si ça semble raisonnable, je le laisse procéder. Ce modèle mental m'a bien servi.

FAQ

Claude agentic est-il vraiment prêt pour la production sur des projets clients ?

Pour des tâches spécifiques et délimitées dans des environnements hors production : oui, absolument. Je l'utilise régulièrement pour les phases d'échafaudage, de refactorisation et de rédaction de tests des projets. Pour tout ce qui touche à une base de données client en production ou à une API de paiement externe, je maintiens un humain dans la boucle à chaque étape d'exécution. Le modèle est capable ; le risque réside dans l'ampleur des dégâts d'une erreur, pas dans le modèle lui-même.

Quelle est la différence entre Claude agentic et l'utilisation de Cursor ou GitHub Copilot ?

Cursor et Copilot sont des suggestions de code en ligne et des interfaces de chat. Ils réagissent à ce que vous tapez. Claude agentic reçoit un objectif et exécute un plan multi-étapes tout seul, en utilisant des outils comme un terminal, un système de fichiers, ou un navigateur web. C'est la différence entre un moteur d'autocomplétion et un processus qui peut tourner sans surveillance pendant dix minutes et revenir avec une tâche terminée.

Faut-il savoir coder pour l'utiliser ?

Vous avez besoin de suffisamment de contexte pour écrire une spécification cohérente et pour examiner le résultat de façon critique. Si vous ne pouvez pas lire une diff et dire si la modification a du sens, vous allez avoir une mauvaise expérience. L'IA agentive amplifie la compétence. Elle ne remplace pas la base.

Quel modèle Claude devrais-je utiliser pour les boucles agentives ?

Claude 3.5 Sonnet est ma valeur par défaut actuelle. Il offre un bon équilibre entre la qualité du raisonnement et la vitesse, ce qui importe quand vous payez par token sur une boucle de 30 étapes. Claude 3 Opus est meilleur pour les tâches de raisonnement très complexe mais plus lent et plus cher, je l'utilise pour l'étape de planification initiale sur les gros projets, puis je passe à Sonnet pour l'exécution.

---

Ce à quoi je reviens sans cesse, c'est que le développement agentif n'est vraiment pas question de l'IA remplaçant les développeurs. C'est une question de changer la valeur du temps d'un développeur. Les douze minutes que je n'ai pas passées à écrire ce wrapper PHP en octobre dernier, je les ai consacrées à la réflexion sur l'architecture. C'est un échange que je ferais à chaque fois.