L'inspection de l'environnement

Un principe sépare les agents qui fonctionnent de ceux qui déraillent, et il tient en une image : Claude opère de façon aveugle. Entre deux messages, il ne perçoit rien du monde — il doit pouvoir observer et comprendre les résultats de ses propres actions pour fonctionner efficacement. Ce principe, l’inspection de l’environnement, est la boucle de perception sans laquelle toute autonomie devient de la divination.

Pourquoi c’est essentiel

L’exemple le plus pur vient de Computer Use : chaque action de Claude déclenche immédiatement une capture d’écran. Ce n’est pas un nice-to-have — c’est fondamental. Un clic est parti : la page a-t-elle chargé ? un menu s’est-il ouvert ? une erreur s’est-elle affichée ? Sans retour d’information, Claude ne peut pas savoir si son action a réussi — et un agent qui enchaîne les actions sur la foi de ce qu’il croit avoir accompli contamine tout ce qui suit dès la première divergence entre croyance et réalité.

Lire avant d’écrire

Le même principe gouverne le travail sur les fichiers, en amont de l’action cette fois :

Claude doit ajouter une route à un fichier Python
        ↓
Claude lit d'abord le code existant (inspection)
        ↓
Claude comprend la structure actuelle
        ↓
Claude fait les modifications sans casser l'existant

C’est exactement le comportement observé chez Claude Code : la majorité de ses appels d’outils sont des lectures, pas des écritures. Lire d’abord permet de respecter les conventions en place, de repérer les dépendances, et d’insérer la modification au bon endroit — au lieu de plaquer du code générique sur une structure ignorée. Et la symétrie s’applique après l’écriture : relire, exécuter les tests, vérifier l’effet.

Guider via le prompt système

Ce comportement d’inspection se prescrit — le prompt système est le bon levier, avec des consignes qui associent chaque outil à son usage vérificateur :

Utilisez l'outil bash pour exécuter whisper.cpp et générer des fichiers de
sous-titres avec timestamps pour vérifier le placement des dialogues.

Utilisez FFmpeg pour extraire des captures d'écran de la vidéo à intervalles
réguliers pour inspecter visuellement le résultat.

Notez la construction de chaque consigne : un outil concret et l’objectif de vérification qu’on lui assigne. « Utilisez FFmpeg » seul produirait des extractions sans but ; « pour inspecter visuellement le résultat » transforme l’outil en instrument de perception. C’est ainsi qu’un agent vidéo vérifie ses propres productions — sous-titres alignés, images correctes — avant de les déclarer finies.

Bénéfices

Les quatre lignes racontent la même chose sous quatre angles : l’information de retour transforme une séquence d’actions en boucle de contrôle. L’agent sait où il en est, rattrape ses erreurs au moment où elles surviennent — pas trois étapes plus loin —, livre du vérifié, et change de stratégie quand l’observation contredit le plan.

Question à toujours poser : « Comment Claude saura-t-il si cette action a fonctionné ? » — posez-la pour chaque outil de votre agent au moment de la conception. Si un outil d’action n’a pas d’outil ou de mécanisme d’observation en face, votre agent a un angle mort ; et les angles morts des agents finissent toujours par coûter.

Points clés à retenir

• Claude n’a aucune perception implicite : sans observation, il agit sur des suppositions
• Computer Use capture l’écran après chaque action — la boucle perception-action, systématisée
• Fichiers : lire avant d’écrire pour s’intégrer, vérifier après pour confirmer l’effet
• Prescrivez l’inspection dans le prompt système : outil concret + objectif de vérification
• Question de conception pour chaque outil : « comment l’agent saura-t-il que ça a marché ? »