Qu'est-ce qu'un agent de développement ?

Agent, chatbot, compléteur : les trois profils

Un agent de développement combine un modèle de langage (LLM), des outils (lire/écrire des fichiers, exécuter des commandes) et une boucle autonome. C’est la présence simultanée de ces trois éléments qui le distingue d’un chatbot ou d’un compléteur inline.

Point clé : Sans outils, un LLM ne peut rien faire. Sans boucle, il ne peut pas itérer. Ce n’est plus un agent.

Dans les outils concrets

• Claude Code est un agent complet : system prompt riche (~10k tokens), 15+ outils intégrés (Read, Write, Edit, Bash, Glob, Grep, Task), hooks, sub-agents, MCP natif.
• Pi (pi.dev) est un agent CLI open-source, minimaliste : 4 outils core (read, write, edit, bash), system prompt court (~200 tokens), multi-modèles, extensible via npm.
• GitHub Copilot (inline) est un compléteur : il prédit la suite du code, sans boucle.

La boucle agentique

À chaque tour de boucle :

1. Le modèle reçoit le contexte complet (instructions + historique + résultats d’outils précédents).
2. Il décide : répondre directement, ou appeler un outil.
3. Si outil : le runtime exécute et renvoie le résultat.
4. Le modèle observe le résultat et décide du prochain pas.
5. La boucle s’arrête quand le modèle répond sans appeler d’outil, ou quand une limite est atteinte.

Point clé : Le LLM ne modifie jamais tes fichiers directement. Il demande au runtime de le faire via un appel d’outil structuré (function calling). C’est cette séparation décision/exécution qui permet de contrôler ce que l’agent fait.

Pourquoi ça compte

L’agent peut se corriger : un test rouge déclenche un nouveau tour. La qualité dépend autant du runtime (gestion d’erreurs, parsing) que du modèle. Si l’agent tourne en rond, c’est souvent un problème de contexte ou de prompt — pas du modèle.

Le Core Four : Model, Prompt, Context, Tools

Quatre leviers déterminent la qualité du résultat d’un agent :

• Model — le LLM utilisé. Compromis capacité / coût / vitesse.
• Prompt — ce que tu demandes. Plus c’est clair et contraint, meilleur est le résultat.
• Context — les informations visibles par l’agent (fichiers lus, historique, instructions persistantes).
• Tools — les outils dont l’agent dispose. Un agent sans outils de vérification ne peut pas valider son propre travail.

Règle de diagnostic : quand l’agent se trompe, vérifier dans l’ordre Prompt → Context → Tools → Model. Le prompt est le levier le moins cher. Changer de modèle est le dernier recours.

Le choix d’outils par le modèle

Chaque outil est décrit par un nom et une description en langage naturel. À chaque tour, le modèle choisit l’outil dont la description correspond le mieux à l’action nécessaire. La qualité des descriptions d’outils est donc déterminante.

Quand utiliser un agent — et quand ne pas

Un agent est puissant mais pas gratuit : chaque tour consomme des tokens, coûte de l’argent et prend du temps. Pour une tâche triviale (renommer une variable dans 20 lignes), un Find & Replace dans l’IDE suffit. L’agent a de la valeur quand la tâche nécessite itération, vérification, ou coordination entre plusieurs fichiers.

C’est le même principe qu’en architecture logicielle : ne pas ajouter d’abstraction quand la complexité ne le justifie pas.