L'inspection de l'environnement
Mis à jour le 30 juillet 2026
Un agent qui agit sans regarder est un agent qui déraille. Claude opère fondamentalement en aveugle : entre deux messages, il ne perçoit rien du monde — il doit pouvoir observer son environnement pour comprendre les résultats de ses propres actions. Ce principe, l’inspection de l’environnement, est l’un des facteurs qui séparent les agents efficaces des agents erratiques : sans lui, le modèle enchaîne les actions sur la foi de ce qu’il croit avoir accompli, et la première divergence entre croyance et réalité contamine tout ce qui suit.
Pourquoi c’est essentiel
L’exemple le plus parlant vient du computer use. Quand Claude pilote une interface et clique sur un bouton, l’écran change — mais Claude, lui, n’en sait rien : son action est partie, aucun retour n’est venu. A-t-il cliqué au bon endroit ? Une boîte de dialogue s’est-elle ouverte ? Une erreur s’est-elle affichée ? C’est précisément pourquoi les outils de computer use retournent automatiquement des captures d’écran après chaque action : la capture referme la boucle perception-action, et le modèle décide de l’étape suivante sur l’état réel de l’interface, pas sur son état supposé.
Lire avant d’écrire
Le même principe s’applique aux opérations sur les fichiers, dans les deux sens. Avant de modifier du code, Claude doit lire ce qui existe déjà dans le fichier : comprendre les conventions en place, repérer les dépendances, situer l’endroit exact de la modification. Cela prévient les erreurs grossières — réécrire une fonction utilisée ailleurs, dupliquer un import — et garantit que les modifications s’intègrent au lieu de se plaquer. Et après l’écriture, l’inspection reprend : relire le fichier modifié, lancer les tests, vérifier que le changement produit l’effet attendu. Lire avant d’écrire, vérifier après avoir écrit — la symétrie est la règle.
Applications pratiques
Voyez comment le principe se déploie sur un agent réel — un système qui crée et publie des vidéos :
- Générer le contenu vidéo
- Vérifier la qualité et le timing
- Contrôler l’alignement audio/visuel
- Confirmer la publication réussie
Une seule étape de production, trois étapes d’inspection : la proportion n’a rien d’exceptionnel dans un agent bien conçu. Chaque vérification intercepte une classe d’échec silencieux — une vidéo corrompue, un doublage désynchronisé, un upload qui a échoué sans bruit — avant qu’elle n’atteigne l’étape suivante ou, pire, le public.
Prompts système pour l’inspection
Reste à obtenir ce comportement. Le levier principal est le prompt système : on y prescrit explicitement les gestes d’inspection, outils à l’appui.
- Utilise bash avec whisper.cpp pour generer les sous-titres
et verifier le placement des dialogues
- Utilise FFmpeg pour extraire des captures a intervalles reguliers
et confirmer la qualite visuelle
- Verifie les tailles et formats de fichiers avant tout upload
Notez la construction de chaque consigne : un outil concret, et l’usage vérificateur qu’on en attend. « Utilise FFmpeg » seul produirait des extractions sans but ; « pour confirmer la qualité visuelle » transforme l’outil en instrument d’inspection. La règle générale à retenir : chaque action d’un agent devrait être suivie d’une forme de vérification qui confirme que le résultat attendu a été obtenu — c’est le prix, modeste, d’un agent qui détecte ses propres erreurs au lieu de les empiler.
Points clés à retenir
- Claude n’a aucune perception implicite : sans observation, il agit sur des suppositions
- La boucle perception-action doit être fermée — les captures d’écran du computer use en sont l’exemple type
- Fichiers : lire avant d’écrire pour s’intégrer, vérifier après pour confirmer l’effet
- Dans un agent mûr, les étapes de vérification dépassent souvent en nombre les étapes de production
- Prescrivez l’inspection dans le prompt système : outil concret + objectif de vérification explicite