Parlons deux minutes des workflows d’agents.
L’une des plus grosses erreurs qu’on voit en ce moment, c’est de bâtir des boucles fermées dans les systèmes d’agents. OpenManus est un excellent exemple de ce qu’il ne faut pas faire.
Voilà ce qui cloche :
🔹 Le prompting vague.
Dire à une IA « tu es un programmeur autonome », c’est comme dire « tu es médecin, maintenant va opérer un cerveau ».
Sans précision, on n’obtient pas de résultats prévisibles.
Si vous demandez à une IA de raisonner pour générer du code, définissez ce qu’est un « bon code ».
Quels sont les patterns critiques pour que votre projet réussisse ? Besoin de SOLID/DI/MVC et de Singletons ? Super — écrivez-le dans le system prompt.
Fixez vos attentes pour la documentation, les commentaires, la modularité et la gestion des erreurs.
Partez du principe que vous travaillez avec un parfait inconnu — parce que c’est le cas.
Conseil de pro : intégrer des influences littéraires qui traitent de concepts de récursion peut aider à éviter les boucles de débogage foireuses. Je ne plaisante pas.
🔹 Des agents mono-tâche qui ne communiquent pas.
Je ne suis pas contre les agents focalisés sur une seule tâche.
Mais si vous avez besoin de plusieurs agents concurrents focalisés sur des tâches différentes, alors il vous faut une dynamique d’équipe.
Une équipe organisée est une machine à communiquer.
Mais là ?
On a un planificateur qui ne sait pas coder. Un navigateur qui ne sait pas planifier. Un codeur qui ne sait pas naviguer.
Et aucun d’entre eux ne se parle.
Pourquoi concevoir ça comme ça ?
Comme dans la vraie vie, des équipes cloisonnées mènent à l’incohérence, aux impasses et à des boucles qui bouffent des cycles sans rien produire.
Si votre agent peut exécuter un processus en 20 étapes, il peut aussi varier son system prompt et sa température à chaque étape sans perdre tout votre contexte.
C’est pas sorcier.
Si chaque étape est gérée par un agent rigide, sans contexte ni adaptabilité, vous allez tomber sur des catégories entières de tâches où ils seront incapables de raisonner sur l’espace du problème.
Voici la solution :
Au lieu de :
Étape 1 : <l’agent de code implémente>
Étape 2 : <l’agent de code débogue>
Étape 3 : Répéter l’étape 1, en espérant que ça marche à l’étape 20...
Vous voulez :
Étape 1 : <l’agent implémente>
Étape 2 : <l’agent débogue>
Étape 3 : <un agent alternatif observe + intervient avec du contexte>
« On dirait que tu bloques avec npx. Tu veux essayer npm à la place ? »
Arrêtez de penser à la vitesse par tâche.
Pensez plutôt à l’élan et à l’intégrité du processus.
Les boucles ouvertes, qui permettent la variation, le feedback et l’adaptation contextuelle, seront toujours plus performantes que des pipelines rigides.
C’est sûr, une tâche peut prendre une heure.
Mais une boucle bien structurée finit par s’arrêter.
Une mauvaise boucle, elle, bouffe des tokens dans une spirale de la mort récursive.
Besoin d’aide pour concevoir des systèmes d’IA et des workflows d’agents qui ne s’autodétruisent pas ?
J’en construis tous les jours.
C’est quoi vos projets d’IA complètement dingues en ce moment ?