Dans cette vague d’IA pour la programmation, les concepts fusent, les outils changent de peau tous les jours, mais le fond n’a rien de si ésotérique.
Un Agent n’est pas de la magie : au fond, c’est une couche de « contrainte structurée » (Harness) qu’on met autour d’un LLM instable, pour rendre ses sorties plus contrôlables. Claude Code, Codex suivent tous cette approche.
1）D’abord, percer le LLM : il ne fait que deviner le prochain token
Une fois compris, beaucoup de « problèmes mystiques » ne le sont plus.
Selon la manière dont tu lui donnes le contexte, il dévie ; selon la manière dont tu le guides, il va dans cette direction.
Donc, passer des prompts du « culte du format » vers une « expression naturelle » est inévitable, mais savoir poser des questions reste une compétence dure.
2）Le prompt n’est pas mort : il faut « moins induire, plus de feedback »
- Ne bourre pas un plan dès le départ : décris d’abord l’état actuel et l’objectif, et laisse le modèle te donner des angles de vue ;
- Itération orientée problème : voir le résultat → pointer l’erreur → réécrire l’instruction → valider via une nouvelle conversation ;
- Des mots-clés trop figés, au contraire, entraînent facilement le modèle dans le fossé.
En une phrase : moins contrôler le chemin, plus vérifier le résultat.
3）AGENTS.md est très important, mais ne l’écris pas comme un « compendium de menottes »
Dans la communauté, beaucoup de listes interminables de « il faut / interdit / principes » sont surtout du bruit.
Si tu bourres le modèle de trop de contraintes, en général il n’est pas plus stable, il est juste plus émoussé.
Les instructions globales doivent poser des limites et expliquer les outils, pas dompter le style.
4）Ne te laisse pas tirer par le « marketing des nouveaux mots »
RAG, Context Engineering, MCP, Skills…
Beaucoup de choses sont au fond un ancien problème reconditionné, ou une normalisation du prompt.
Ce qu’il faut poursuivre, ce n’est pas le « terme », c’est : est-ce que ça réduit réellement tes frictions et raccourcit le chemin vers la livraison.
5）Le développement en parallèle a une limite : deux tâches, c’est le plafond de la plupart des gens
Lancer trois ou quatre Agents a l’air très efficace ; en pratique, c’est le cerveau qui explose le cache.
Les notifications qui sonnent en boucle ne font qu’interrompre le flow et fabriquer l’illusion « je suis très occupé ».
Conseil : coupe les notifications, va toi-même consulter l’avancement.
Répondre passivement aux notifications = se faire dicter le rythme ; inspecter activement les tâches = c’est toi qui contrôles le rythme.
6）Le fichier comme mémoire : déplacer le contexte de la « tête » vers le « système de fichiers »
Un Agent en CLI dépend encore plus de la logique de recherche textuelle.
Pour qu’un Agent soit stable, ce n’est pas la prière : c’est une documentation projet consultable et réutilisable.
Les fichiers doivent être orientés vers l’exécution finale, pas remplis de déchets de process.
Au fond, il s’agit de combler les faiblesses natives du modèle en contexte et en attention.
7）Simplifier le flux : d’abord planifier, puis coder
Ta méthode en deux étapes est très pratique :
- Discuter à répétition et figer le plan (PLAN / dossier plans)
- Implémenter le code selon le plan final, et capitaliser la doc d’implémentation (dossier docs)
Le fichier de plan est l’ancre, le code est le livrable.
8）Orienté résultat : moins s’obséder d’un « processus élégant », plus viser une « livraison vérifiable »
Passer de « j’apprends à l’Agent à écrire du code pas à pas » à « je gère la solution et les critères de recette ».
Les petites erreurs au milieu, ne les chipote pas tout de suite : regroupe-les et corrige-les en phase de revue.
La qualité du code ne se juge pas à l’émotion : elle se juge par les tests et une structure traçable.
L’objectif central n’est qu’un seul : It just works.
9）Mise à niveau de mentalité : de l’exécutant au manager
Utilise Codex comme « cerveau externe + canard en plastique » : toi, tu découpes le problème, tu fixes les standards, tu fais les arbitrages ;
lui, il exécute à grande échelle.
Ne prends pas l’Agent pour un dieu, ni pour un jouet — c’est un amplificateur : il amplifie ton jugement, et il amplifie aussi ton chaos.
10）Leçons des mauvaises pratiques
- Courir aveuglément après un « fonctionnement autonome de longue durée » a peu de sens ;
- La vraie valeur, c’est réduire l’intervention humaine et augmenter la probabilité de livraisons stables ;
- Copier-coller le Prompt/Skills des autres fait démarrer vite, mais ce n’est pas forcément adapté à ton projet ;
- Le chemin de progression le plus efficace : surveiller l’exécution, trouver la cause racine des échecs, itérer ta propre méthodologie.
