Construire des agents d'IA efficaces : trois idées qui font l'essentiel du travail
Les recommandations d'Anthropic sur les agents efficaces en trois idées : ne construisez pas des agents pour tout, gardez-les simples, et raisonnez du point de vue de votre agent. Ce que chacune signifie en pratique.
Guillaume Rufenacht
Product Manager IA · Lisbonne
Le moyen le plus rapide de gaspiller de l’argent sur l’IA, c’est de construire un agent pour une tâche qui n’en avait pas besoin. Les recommandations d’Anthropic pour construire des agents efficaces tiennent en trois idées peu spectaculaires : ne construisez pas des agents pour tout, gardez-les aussi simples que possible, et raisonnez du point de vue de votre agent. Après avoir livré moi-même bon nombre d’agents, je dirais que ces trois idées constituent l’essentiel du jeu.
Voici ce que chacune signifie en pratique, et comment je les applique aux pipelines de production derrière Geonimo.
Key takeaways
- Ne construisez pas des agents pour tout. Utilisez un workflow quand vous pouvez cartographier l'arbre de décision ; réservez les agents aux tâches ambiguës et à forte valeur.
- Un agent n'est qu'un modèle qui utilise des outils en boucle, défini par son environnement, ses outils et son system prompt. Gardez ces trois éléments simples avant d'optimiser.
- Raisonnez du point de vue de votre agent : tout ce qu'il sait, ce sont les ~10-20k tokens de sa fenêtre de contexte. La plupart des erreurs « bêtes » sont du contexte manquant.
- Les agents ajoutent de l'autonomie, et avec elle du coût, de la latence et les conséquences des erreurs. Méritez ce compromis de façon délibérée.
Ne construisez pas des agents pour tout
Un agent décide lui-même de son chemin ; un workflow suit celui que vous avez défini. Les agents sont la manière de passer à l’échelle des tâches complexes, précieuses et ambiguës, pas une amélioration prête à l’emploi pour chaque fonctionnalité. Avant d’en saisir un, parcourez la checklist :
Complexité
Valeur
Capacités critiques
Coût de l'erreur
Le code est le cas idéal classique : ambigu (du document de conception à la PR), réellement précieux, et facilement vérifiable via les tests et la CI. Cette dernière propriété, la vérifiabilité, joue un rôle déterminant, et c’est exactement pourquoi je m’appuie sur la même discipline dans mon système d’outbound : une étape qui vérifie le travail avant qu’il ne parte.
Gardez-le aussi simple que possible
Retirez le mystère et un agent n’est qu’un modèle qui utilise des outils en boucle. Trois composants le définissent : l’environnement dans lequel il opère, les outils qu’il peut appeler, et le system prompt qui fixe ses objectifs et ses contraintes. Des agents radicalement différents partagent presque la même colonne vertébrale ; les seules vraies décisions de conception sont quels outils proposer et quoi mettre dans le prompt. Itérez d’abord sur ces trois éléments, car la complexité en amont tue la vitesse d’itération. Les optimisations, mettre en cache les trajectoires, paralléliser les appels d’outils, viennent après que le comportement est correct. C’est la même leçon que je traite dans l’autre sens dans outil, skill ou sous-agent ?.
Raisonnez du point de vue de votre agent
Quand un agent fait quelque chose de déroutant, le réflexe est de traiter le modèle de bête. En général, le vrai problème est que nous avons conçu l’agent depuis notre perspective, pas la sienne. Tout ce que le modèle sait à chaque étape, ce sont les quelque 10-20k tokens de sa fenêtre de contexte. Mettez-vous dans cette fenêtre : l’information est-elle réellement suffisante et cohérente pour prendre la décision suivante ? Faites l’exercice d’exécuter une tâche avec seulement ce que l’agent peut voir, c’est inconfortable et éclairant.
Le raccourci, c’est que ces systèmes parlent notre langue, vous pouvez donc demander à Claude de comprendre Claude : collez votre system prompt et demandez si quelque chose est ambigu, ou donnez-lui une trajectoire et demandez pourquoi il a pris une décision donnée et ce qui aurait aidé. Cela ne remplace pas votre propre compréhension, mais cela comble l’écart rapidement.
À retenir
Des agents fiables en production, c’est le travail que je fais. Voyez comment je pense le context engineering, ce que j’ai construit, ou contactez-moi.
Questions fréquentes
Quand dois-je construire un agent plutôt qu'un workflow ?
Utilisez un workflow quand vous pouvez cartographier l'arbre de décision explicitement ; utilisez un agent pour des tâches réellement ambiguës et à forte valeur, où l'exploration justifie le coût en tokens. Ne construisez pas des agents pour tout.
Qu'est-ce qu'un agent, simplement ?
Un modèle qui utilise des outils en boucle, défini par trois choses : l'environnement dans lequel il opère, les outils qu'il peut appeler, et le system prompt qui fixe ses objectifs et ses contraintes. Gardez ces éléments simples avant d'optimiser.
Pourquoi mes agents font-ils des erreurs déroutantes ?
En général parce que leur contexte est insuffisant. Mettez-vous dans la fenêtre de contexte de l'agent, tout ce qu'il sait, ce sont les ~10-20k tokens qu'il peut voir, et vérifiez si c'est réellement suffisant pour prendre la décision.
Travailler avec moi
Vous voulez un système comme celui-ci pour votre pipeline ?
J'aide les équipes à faire passer l'IA d'un prototype malin à une production fiable : moteurs d'outbound, intelligence des leads et les pipelines LLM en dessous. Voyez ce que j'ai livré ou écrivez-moi.