05 — Travailler avec un agent coding

@diagram:lesson-contract
duration :: 11 min lecture
deliverable :: Une délégation réussie à un agent coding (ajout de l'historique local)
outcome :: Savoir construire un prompt structuré en 6 éléments et limiter le rayon d'action de l'agent

Déléguer à un agent coding, c’est passer une commande à un sous-traitant rapide mais zélé. Si ton cahier des charges est flou, il livre autre chose que ce que tu voulais. Si tu ne vérifies pas la livraison, tu signes les yeux fermés. Cette leçon te donne les deux gestes qui comptent : cadrer en amont, vérifier en aval.

À quoi sert un agent coding

Un agent coding lit plusieurs fichiers, propose un plan, modifie le code, lance des commandes et corrige ses erreurs. Voici cinq usages concrets où il fait gagner du temps :

• créer une fonctionnalité cadrée ;
• refactorer une partie du projet ;
• analyser une base de code ;
• corriger un bug avec logs ;
• écrire une documentation technique.

Ce qu’il ne fait pas à ta place : décider de ton produit. Le quoi et le pourquoi restent tes décisions.

Choisir la bonne catégorie d’outil

Tu as trois familles d’agents, chacune taillée pour un usage différent :

• éditeur IA (Cursor, VS Code + Copilot ou autre extension) : confortable pour lire, sélectionner du code, faire des modifications locales ;
• agent CLI (Claude Code, Codex, OpenCode…) : pratique pour tâches longues, multi-fichiers, tests, Git ;
• outil no-code/agent app (Dify, Flowise…) : utile pour RAG, workflows ou prototypes métier.

Ne prends pas le plus puissant. Prends celui qui te laisse vérifier vite ce qu’il a fait.

Écrire le cahier des charges en 6 éléments

Une demande exploitable tient en six points. Aucun n’est facultatif : retire-en un et l’agent comble le vide à sa façon.

1. contexte ;
2. objectif ;
3. fichiers concernés ;
4. contraintes ;
5. validation attendue ;
6. format de retour.

@diagram:prompt-generator

Modèle :

Contexte : application Vite + React de génération de fiches produit.
Fichiers concernés : commence par analyser src/App.jsx et src/App.css.
Contraintes : pas de backend, pas de dépendance externe, localStorage autorisé.
Validation : npm run dev doit démarrer, et un résultat sauvegardé doit rester après refresh.
Retour attendu : liste des fichiers modifiés + comment tester.

Demander un plan avant le moindre fichier touché

Dès qu’une tâche dépasse 15 minutes de travail, ne lâche pas l’agent directement dans le code. Fais-le d’abord parler :

Analyse le projet et propose un plan. Ne modifie aucun fichier pour l'instant.

Tu lis le plan, tu repères ce qui dérape, puis tu cadres ce qu’il a le droit d’exécuter :

OK pour le plan. Implémente uniquement les étapes 1 à 3. Arrête-toi avant tout refactor global.

Poser les bornes du rayon d’action

Laissé libre, un agent en fait plus que demandé : il renomme, il ajoute, il « range ». Écris les interdits noir sur blanc :

Ne change pas la stack.
Ne renomme pas les fichiers existants.
N'ajoute pas de dépendance sans accord.
Ne modifie pas le design sauf si nécessaire à la fonctionnalité.

Récupérer une trace de la livraison

En fin de tâche, exige un compte rendu. C’est ta preuve de ce qui a changé :

Résume :
- fichiers modifiés
- comportement ajouté
- commande de validation
- limites restantes

Colle ce résumé dans NOTES.md. La prochaine session de l’agent partira d’une base claire.

Exercice pratique

Délègue l’ajout de l’historique local sur le projet de fiches :

Ajoute un historique local des 5 dernières fiches générées.
Contraintes : utiliser localStorage, pas de backend, pas de nouvelle dépendance.
L'utilisateur doit pouvoir cliquer sur un ancien résultat pour le revoir.
Après modification, explique comment tester.

Pour valider : génère 2 fiches avec des données différentes, recharge la page, clique sur une fiche ancienne. Si l’ancienne fiche revient telle quelle, c’est bon.

Cas de référence du parcours : Gourde inox 750 ml, public cible randonneurs occasionnels, bénéfices garde fraîche / solide / facile à nettoyer.

Check-list de validation

@diagram:checklist
item-1 :: Tu as demandé un plan avant modification.
item-2 :: Tu as limité le périmètre.
item-3 :: L'agent a listé les fichiers modifiés.
item-4 :: Tu as lancé la commande de validation.
item-5 :: Tu as testé le comportement dans le navigateur.
item-6 :: Tu as noté les changements dans NOTES.md.

Pièges fréquents

• Prompt trop vague. « Améliore l’app » ouvre la porte aux changements inutiles.
• Tâche trop grosse. Découpe-la : interface, logique, persistance, puis tests.
• Confiance sans vérification. Un agent peut annoncer que ça marche sans avoir lancé la bonne commande.
• Pas de point de retour. Commit avant les gros changements.

Suite conseillée

Passe au module 6 pour apprendre à debugger avec méthode quand l’agent ou toi cassez quelque chose.