EvoTeam : faire évoluer l'équipe d'agents plutôt que l'agent lui-même

EvoTeam : faire évoluer l'équipe d'agents plutôt que l'agent lui-même

🔎 Les agents sont brillants. Les équipes, elles, restent médiocres.

Les modèles n'ont jamais été aussi forts en mode agent. GPT-5.5 culmine à 98,2 sur l'indice agentic de référence, Gemini 3 Pro Deep Think suit à 95,4, Claude Opus 4.7 (Adaptive) complète le podium à 94,3. Et pourtant, les systèmes multi-agents continuent d'échouer sur des choses presque triviales : deux agents qui refont le même travail, un contexte qui diverge entre collègues virtuels, une tâche qui tombe entre les mailles des rôles.

Le 29 octobre 2026, une équipe liée à l'Université du Jilin a publié sur arXiv un papier qui attaque ce mur par un angle inhabituel. EvoTeam ne cherche pas à rendre chaque agent meilleur : il fait évoluer l'équipe elle-même — ses rôles, sa topologie de communication, ses règles d'interaction — en s'appuyant sur l'expérience d'exécution, avec à la clé une bibliothèque d'équipes réutilisables.

Pourquoi maintenant ? Parce que la course aux capacités individuelles rapporte de moins en moins sur les tâches réelles, tandis que les échecs de coordination restent le premier poste de défaillance des systèmes multi-agents. L'optimisation de prompts et de workflows a préparé le terrain. Personne n'avait encore systématisé l'évolution de l'organigramme. C'est fait — et le code est open source.

L'essentiel

• La thèse : améliorer chaque agent individuellement ne produit pas la meilleure équipe. Le vrai levier, c'est l'organisation : rôles, topologie de communication, règles d'interaction.
• La méthode : EvoTeam traite l'organisation comme un génome évolutif, sélectionné par l'expérience d'exécution — réussite, coût, qualité des échanges.
• La capitalisation : une bibliothèque d'équipes stocke les organisations gagnantes et les réadapte à de nouvelles tâches, avec environ 40 % de budget d'évolution économisé sur des tâches proches (chiffres du papier).
• Les résultats : de +4,6 à +8,6 points sur quatre benchmarks (GAIA, SWE-bench Verified, WebArena, MATH-500) face à une équipe figée — et surtout mieux que des équipes aux agents individuellement optimisés.
• Les limites : coût de l'évolution, risque de surapprentissage sur les benchmarks, portabilité inter-modèles encore à confirmer.

Outils recommandés

Pour expérimenter EvoTeam ou construire des équipes d'agents comparables, voici la boîte à outils minimale. EvoTeam est le seul outil ici qui touche à l'organisation ; les autres servent à l'exécution.

Le goulot d'étranglement, c'est l'organisation, pas le QI des agents

Si vos systèmes multi-agents échouent, le coupable n'est presque jamais le modèle. C'est la manière dont les agents se parlent.

Les capacités individuelles progressent à une vitesse déconcertante. Selon METR (2025), l'horizon des tâches que les IA parviennent à compléter double tous les sept mois environ. À ce rythme, le modèle « le plus intelligent du monde » de cette année sera banal l'an prochain.

Or les échecs, eux, ne bougent pas à la même vitesse. Une étude de référence menée par des chercheurs de Berkeley et de ses partenaires (« Why Do Multi-Agent LLM Systems Fail? », 2025) a passé au crible des centaines de traces d'exécution de systèmes multi-agents et en a tiré une taxonomie de 14 modes de défaillance. La catégorie la plus peuplée ? Le désalignement inter-agents, avec plus de 40 % des cas. Pas le raisonnement du modèle. Les échanges entre modèles.

Cognition avait frappé fort dès juin 2025 avec son manifeste « Don't Build Multi-Agents » : quand le contexte se fragmente entre agents, les décisions implicites se perdent et l'équipe s'autodétruit en silence. Anthropic, la même année, a chiffré l'autre face du problème : son système de recherche multi-agents consomme environ 15 fois plus de tokens qu'une conversation simple. La coordination, c'est cher — quand elle fonctionne.

L'optimisation existante vise la mauvaise cible

Regardez d'où vient le progrès de l'ingénierie d'agents ces trois dernières années : OPRO (DeepMind, 2023) optimise des prompts, DSPy industrialise cette approche, GEPA (Berkeley/Databricks, 2025) fait évoluer des prompts par réflexion sur les échecs, AFlow (ICLR 2025) cherche le meilleur workflow, ADAS (CMU, 2024) génère du code d'agents. Tout cela est utile. Tout cela optimise l'unité ou le chemin — jamais l'organisation.

J'en faisais déjà le constat dans notre dossier sur la collaboration multi-agents : la coordination est le coût caché du domaine. EvoTeam est la première réponse systématique à ce coût précis.

Ce qu'EvoTeam fait différemment : évoluer l'organigramme

EvoTeam traite l'organisation d'une équipe d'agents comme un organisme évolutif, et l'expérience d'exécution comme le signal de sélection.

Concrètement, le « génome » d'une équipe chez EvoTeam décrit : le nombre d'agents, leurs rôles, la topologie de communication (hiérarchique, pair-à-pair, débat, pipeline), les protocoles d'échange — qui parle à qui, quand, sous quel format, qui arbitre les désaccords — et l'affectation des modèles à chaque rôle.

La boucle d'évolution est classique dans sa forme, originale dans son objet. On part d'une population d'organisations, on exécute chaque équipe sur un lot de tâches, on score (réussite, coût en tokens, latence, qualité des sorties), puis sélection, mutation et croisement produisent la génération suivante. Rien de magique. Mais le niveau d'abstraction change tout.

Le détail qui distingue EvoTeam d'une simple recherche d'architecture : le signal ne se réduit pas à succès/échec. Les traces d'exécution sont exploitées finement. Un vérificateur qui laisse passer des erreurs déclenche une mutation du protocole — par exemple une boucle de relecture croisée entre pairs. Un planificateur saturé de messages voit ses prérogatives redistribuées. L'équipe apprend de ses dysfonctionnements de communication, pas seulement de ses échecs de tâche.

Trois leviers, un seul signal

• La structure : créer, fusionner ou supprimer des rôles. L'évolution peut réduire une équipe autant que l'agrandir.
• Le protocole : les règles d'interaction — séquencement des tours de parole, formats de sortie, mécanismes de validation, gestion des désaccords.
• L'affectation : quel modèle pour quel rôle. Un planificateur exigeant justifie un GPT-5.5 ; un rôle d'exécution volumique se satisfait d'un self-host comme Kimi K2.6 (88,1) ou GLM-5 Reasoning (82).

Ces trois leviers mutent sous la même pression de sélection : l'expérience d'exécution réelle, pas l'intuition d'un ingénieur.

La bibliothèque d'équipes : la vraie innovation

À mes yeux, c'est ici que le papier dépasse le statut d'exercice académique. Chaque organisation performante est archivée dans une bibliothèque avec ses métadonnées : type de tâche, profil de coût, configuration de modèles, protocoles. Face à une nouvelle tâche, le système récupère les équipes les plus similaires et démarre l'évolution à partir d'elles — un warm start qui, selon les auteurs, économise environ 40 % du budget d'évolution sur des tâches proches de celles déjà rencontrées.

Pensez à une équipe sportive : recruter onze talents ne garantit rien si le placement est mauvais. EvoTeam ne cherche pas de meilleurs joueurs. Il cherche le placement, puis le conserve dans un playbook.

C'est le passage d'une logique de projet à une logique de patrimoine. Vos organisations d'agents deviennent un actif qui s'apprécie avec les runs, au lieu d'être reconstruites à la main à chaque projet.

Les chiffres : des gains réels, à lire avec les notes de bas de page

Sur les quatre benchmarks évalués, EvoTeam gagne de 4,6 à 8,6 points contre une équipe figée — et surtout, il domine des équipes dont chaque agent a été optimisé individuellement.

Voici les résultats principaux rapportés par le papier (sous-ensembles de validation, chiffres des auteurs) :

La lecture qui compte n'est pas la colonne de droite, c'est l'écart entre les deux dernières. Optimiser les prompts de chaque membre rapporte environ 2 points. Optimiser l'organisation en rapporte 5 à 9. C'est, chiffré, tout l'argument du papier : la meilleure équipe n'est pas la somme des meilleurs agents.

Deux nuances honnêtes. D'abord, les gains se concentrent sur les tâches à forte coordination — GAIA, dont l'écart historique entre humains (~92 %) et agents outillés (~30 % en 2023) avait frappé la communauté, et WebArena. Sur MATH-500, plus linéaire, l'écart se resserre. Logique : moins d'interactions, moins de dividendes organisationnels.

Ensuite, ces chiffres sont auto-évalués par les auteurs, sur des sous-ensembles de validation, avec une variance non négligeable entre exécutions. Le code et les configurations sont publiés, ce qui permet la réplication — c'est le minimum. Mais traitez les +8,6 points de GAIA comme une tendance, pas comme un contrat.

L'effet secondaire que personne n'attendait : l'évolution amincit

Le résultat le plus intéressant du papier n'est pas un score. Sur MATH-500, la majorité des campagnes d'évolution ont réduit la taille des équipes — rôles fusionnés, intermédiaires supprimés — pour un coût d'exécution en baisse d'environ un tiers à qualité constante. L'évolution ne grossit pas les équipes : elle les affine.

Et les organisations convergentes ressemblent à ce que les humains ont mis des décennies à inventer : un vérificateur dédié et indépendant, un débat structuré avant tout engagement coûteux, une mémoire partagée sélective plutôt qu'un canal unique saturé. Quand l'évolution redécouvre les bonnes pratiques managériales, c'est bon signe pour la méthode.

Ce n'est pas non plus un coup isolé. Nous avions documenté un signal similaire avec cinq Qwen3.8-27B orchestrés via un dossier partagé qui battent Claude Fable 5 : une organisation simple et disciplinée peut compenser une matière première modèle inférieure. EvoTeam systématise cette intuition.

Face à ADAS, AFlow ou GEPA : ce que « organisation » change vraiment

La différence n'est pas cosmétique. ADAS et AFlow optimisent ce que les agents font ; EvoTeam optimise qui parle à qui, quand et sous quelle autorité.

Ce tableau mérite une lecture de travers : toutes ces approches sont complémentaires, pas concurrentes. Rien n'interdit de faire évoluer une équipe dont les membres sont eux-mêmes optimisés par DSPy. EvoTeam opère un niveau au-dessus — et c'est précisément ce niveau qui était vide.

La bibliothèque change aussi la nature de l'investissement. Les artefacts produits par ADAS ou AFlow servent essentiellement à la tâche pour laquelle ils ont été cherchés. Une organisation évoluée, elle, se capitalise, se versionne, se réadapte. Mon pari : d'ici dix-huit mois, les frameworks sérieux exposeront une couche « organisation » versionnable exactement comme on versionne des prompts aujourd'hui. Ceux qui construisent cette couche tôt prendront de l'avance.

Les limites : ce que le papier règle moins bien

EvoTeam ne résout ni le coût de l'évolution, ni la portabilité des équipes entre modèles, ni la question épineuse de la responsabilité.

Le coût, d'abord. L'expérience principale repose sur environ 1 500 exécutions par benchmark. Avec des modèles premium, la note se chiffre en centaines, voire en milliers de dollars selon la longueur des tâches — souvenez du ratio de 15× en tokens documenté par Anthropic en 2025. Avec des modèles self-host, la facture devient du temps de GPU, ce qui est plus digeste mais pas gratuit.

Le surapprentissage, ensuite. Les organisations évoluent sur les distributions de leurs benchmarks. Le papier démontre le transfert de la bibliothèque vers des tâches proches, pas vers des domaines radicalement différents. La bibliothèque n'est pas — encore — une solution universelle, et les auteurs ne prétendent pas le contraire.

La dépendance aux modèles, enfin. Une organisation calibrée avec Claude Opus 4.7 (Adaptive) peut se dégrader avec Gemini 3.1 Pro : les protocoles fins de communication sont sensibles au style de sortie des modèles. Chaque changement de configuration impose une revalidation. Prometteur, pas acquis.

Il reste l'angle mort gouvernance, et il n'est pas théorique. Quand une équipe réécrit ses propres règles d'interaction au fil des générations, qui a validé le protocole émergent ? Comment l'auditer après incident ? Le débat législatif américain va droit vers cette question : le AI Agent Accountability Act, porté par Hawley et Murphy, veut faire payer les développeurs quand leurs agents causent des dégâts. Une organisation évolutive brouille encore davantage la chaîne de responsabilité. Si vous déployez ce genre de système en production, exigez une revue humaine de tout protocole évolué avant exposition au monde réel.

Intégrer EvoTeam dans une stack réelle (sans se ruiner)

Ne faites pas tout évoluer. Faites évoluer là où la coordination coûte cher, et gelez le reste.

La séquence que je recommande, après lecture du papier et de ses configurations :

1. Construisez d'abord votre harnais d'évaluation. Sans métrique fiable, l'évolution optimise le bruit. C'est 80 % du travail, et c'est la partie que personne ne veut faire.
2. Mesurez une équipe figée en baseline. Le motif canonique « orchestrateur + trois spécialistes » fait l'affaire.
3. Plafonnez le budget d'évolution : nombre de runs, tokens, dollars. Sans garde-fou, une boucle évolutive peut brûler un budget API en un week-end.
4. Versionnez votre bibliothèque d'équipes dans git, avec métadonnées de coût et de domaine. C'est votre actif.
5. Revalidez à chaque changement de modèle, même mineur.

Côté affectation des modèles, la stratégie économique est évidente : réservez GPT-5.5 ou Gemini 3 Pro Deep Think pour les rôles de planification et d'arbitrage, et confiez l'exécution volumique à des modèles self-host comme Kimi K2.6 ou GLM-5 Reasoning. Notre comparatif des meilleurs LLM pour les agents IA détaille ces arbitrages. Pour une équipe 100 % locale, Ollama fait le travail — nous avons un guide complet sur les agents IA open source en local avec Ollama — et un VPS dédié suffit largement pour démarrer ; Hostinger propose des VPS dès environ 5 $/mois (novembre 2026, vérifiez sur hostinger.com).

Un dernier point que le papier élude : une organisation évoluée ne vaut rien sans contexte riche à transmettre. La mémoire et la connaissance persistante de l'utilisateur restent votre responsabilité — notre article sur OpenHuman, l'agent IA open source qui connaît votre vie avant même de lui parler explore ce volet.

Pour lancer une première campagne :

git clone https://github.com/DEEP-JLU/EvoTeam
cd EvoTeam
pip install -e .
python evoteam/run.py --benchmark gaia --population 12 --generations 8 \
  --budget-tokens 5000000 --library ./teams

Et si vous partez de zéro, commencez par notre guide pour créer un agent IA : inutile de faire évoluer une équipe avant de savoir faire exécuter un agent.

❌ Erreurs courantes

Trois pièges reviennent dans tous les déploiements multi-agents — EvoTeam en corrige un, pas les autres.

Erreur 1 : optimiser les agents quand le problème est organisationnel

Vous passez des semaines à peaufiner des prompts pendant que vos agents se doublonnent et se contredisent. La solution : auditez d'abord les dysfonctionnements inter-agents — la taxonomie MAST de 2025 sert de liste de contrôle — et ne touchez aux prompts qu'après avoir fixé la structure.

Erreur 2 : lancer une évolution sans budget ni garde-fous

Une boucle évolutive mal bornée consomme des tokens sans fin et peut dégrader les équipes en suroptimisant une métrique bruitée. La solution : plafonnez runs et coûts, faites évoluer les premières générations sur des modèles bon marché, et ne réservez les modèles premium qu'aux finalistes.

Erreur 3 : copier une équipe évoluée sans la revalider

Une équipe brillante sur GAIA peut s'effondrer sur votre domaine métier. Traitez chaque entrée de la bibliothèque comme une hypothèse, pas comme une vérité : revalidez systématiquement sur votre propre jeu d'évaluation avant tout déploiement.

❓ Questions fréquentes

Les réponses courtes aux questions qui reviennent le plus sur EvoTeam.

EvoTeam remplace-t-il AutoGen ou CrewAI ?

Non. EvoTeam conçoit l'organisation, les frameworks l'exécutent. Le papier lui-même s'appuie sur des briques d'orchestration existantes pour instancier les équipes. Comptez sur EvoTeam pour décider de la structure et sur AutoGen, CrewAI ou LangGraph pour l'exécution : les deux couches sont complémentaires.

Combien coûte une campagne d'évolution ?

L'expérience principale du papier repose sur environ 1 500 exécutions par benchmark. Avec des modèles premium, comptez plusieurs centaines à quelques milliers de dollars selon la longueur des tâches ; en self-host, c'est du temps GPU. La bibliothèque réduit d'environ 40 % le budget des campagnes suivantes sur des tâches proches.

Peut-on faire évoluer une équipe de modèles open source en local ?

Oui, et c'est le scénario le plus rationnel économiquement : l'évolution exige beaucoup d'exécutions, donc des coûts par appel faibles. Kimi K2.6 (88,1) ou GLM-5 Reasoning (82) en self-host couvrent la majorité des rôles, un modèle premium n'étant réservé qu'aux évaluations finales.

La bibliothèque d'équipes est-elle transférable d'un modèle à l'autre ?

Partiellement. Les organisations — rôles et topologies — se transfèrent mieux que les protocoles fins, sensibles au style de sortie de chaque modèle. Le papier recommande une revalidation après tout changement de configuration. Considérez chaque entrée de la bibliothèque comme liée à une combinaison de modèles donnée.

Faut-il un labo de recherche pour s'en servir ?

Non, mais il faut un socle d'ingénierie : harnais d'évaluation fiable, traçabilité complète, budget maîtrisé. Le code est open source et la prise en main tient en une soirée pour qui a déjà orchestré des agents. La difficulté n'est pas l'algorithme d'évolution, c'est l'évaluation.

✅ Conclusion

La prochaine percée des agents IA viendra peut-être moins d'un meilleur modèle que d'une meilleure organisation — EvoTeam en apporte la première démonstration systématique, bibliothèque d'équipes à l'appui. Pour choisir les modèles qui composeront vos équipes, commencez par notre comparatif des meilleurs agents IA autonomes.