Claude Code agit dans un environnement de travail
Claude Code ne se limite pas à répondre dans une conversation. Il peut explorer un dépôt, lire les instructions du projet, modifier des fichiers, exécuter des commandes et utiliser des outils autorisés. Cette capacité rend le résultat plus concret, mais augmente aussi le besoin de contrôle.
La documentation Anthropic présente un cycle où l'agent rassemble le contexte, agit, puis vérifie son travail. Une formation utile doit donc apprendre ce cycle complet. Copier une liste de prompts ne prépare ni aux conflits de fichiers, ni aux tests qui échouent, ni à une permission trop large.
Lire le plan, comprendre les fichiers touchés et tester le résultat.
Choisir le contexte, les limites, les preuves et la condition d'arrêt.
Les prérequis ne sont pas seulement techniques
Il faut savoir localiser un projet, reconnaître un fichier sensible, lire une différence avant/après et distinguer une commande de lecture d'une commande qui modifie l'état. Pour un non-développeur, ces notions s'apprennent sur un espace de test, sans données client et avec un retour arrière.
- Un projet de formation séparé des systèmes de production.
- Une sauvegarde ou un historique de versions fonctionnel.
- Des données factices ou anonymisées.
- Une liste explicite des actions autorisées.
- Une définition observable du résultat attendu.
Le terminal n'est pas un rite de passage. C'est une surface d'action. On apprend les quelques commandes nécessaires pour comprendre ce que l'agent fait, puis on automatise les vérifications répétitives.
Sept blocs pour passer d'une demande à une livraison
| Bloc | Compétence | Exercice vérifiable |
|---|---|---|
| 1. Environnement | Projet, terminal, historique et fichiers | Retrouver puis annuler une modification |
| 2. Contexte | Instructions, sources et règles locales | Faire respecter trois contraintes du projet |
| 3. Cadrage | Mission, critères et interdits | Obtenir un plan avant toute écriture |
| 4. Exécution | Outils, modifications et journal | Livrer une petite fonctionnalité |
| 5. Vérification | Tests, rendu visuel et preuves | Faire échouer puis réussir une porte |
| 6. Délégation | Sous-tâches spécialisées et synthèse | Séparer recherche et implémentation |
| 7. Reprise | État, corrections et passage de relais | Reprendre le projet dans une nouvelle session |
Chaque bloc produit une trace : un brief, un diff, une commande de test, une capture ou un journal. La personne formée ne dit pas seulement que « ça marche ». Elle montre pourquoi elle peut le conclure.
Un projet assez petit pour être fini
Le meilleur projet de formation possède une entrée réelle, une sortie visible et peu de dépendances. Par exemple : créer une page ressource dans une direction artistique existante, ajouter un contrôle automatique, ou transformer un dossier de sources en brief structuré.
Objectif : ajouter une page guide au site de test. Sources : charte, page de référence, brief validé. Autorisations : lire le projet et modifier le dossier preview. Interdits : aucune publication, aucun secret, aucune dépendance. Preuves : HTML valide, liens internes, test mobile et desktop. Fin : la preview passe les contrôles et peut être relue.
Le formateur injecte ensuite deux incidents : une source contradictoire et un test qui échoue. L'objectif est de vérifier que l'apprenant sait suspendre l'action, retrouver l'autorité et corriger sans écraser le reste.
Les permissions font partie du programme
Anthropic documente plusieurs couches de protection : permissions, hooks, sandbox et isolation de l'environnement. Leur disponibilité dépend de la configuration. Une formation doit expliquer ce qui est réellement actif au lieu de supposer que l'agent travaille dans une boîte étanche.
- Donnez l'accès minimal nécessaire à la mission.
- Ne placez jamais une clé ou un secret dans un prompt ou un fichier de formation.
- Relisez les commandes qui installent, publient, envoient ou suppriment.
- Testez dans une branche ou un répertoire réversible.
- Gardez une validation humaine pour toute action externe.
Une instruction écrite ne remplace pas une limitation technique. Pour une action risquée, la meilleure protection est souvent l'absence de connecteur ou de permission.
Évaluer une capacité, pas une impression
| Critère | Preuve attendue |
|---|---|
| Cadrage | Le résultat, les limites et la fin sont observables |
| Contexte | Les sources utiles sont citées et les conflits signalés |
| Exécution | Les modifications restent dans le périmètre |
| Contrôle | Les tests couvrent le risque principal |
| Sécurité | Aucun secret ni action externe non autorisée |
| Reprise | Une autre session peut comprendre l'état et continuer |
La sortie finale peut être une page, un petit outil ou un workflow. Ce qui compte est la capacité à expliquer la chaîne de preuve. Pour préparer le contexte d'un tel système, consultez le guide context engineering en entreprise.
Se former à Claude Code
Faut-il savoir coder ?
Pas pour toutes les missions, mais il faut comprendre les fichiers, les commandes, les permissions et la façon de vérifier une modification avant de l'accepter.
Combien de temps faut-il pour apprendre ?
Une première mission encadrée peut être menée rapidement. L'autonomie dépend ensuite de la complexité des projets et de la capacité à contrôler les sorties.
Quel projet choisir ?
Un projet réel, réversible, avec un résultat observable et des données non sensibles.