CoreAgent plutôt qu’essaim : un bon agent travaille seul

Presque chaque semaine, un nouvel agent open source promet de tout faire. PI Agent, Hermes, des essaims entiers de sous-agents « spécialisés » qui se renvoient des tâches. En démo, c'est impressionnant. Dans le quotidien d'une entreprise, avec de vraies données et de vraies conséquences, c'est une autre histoire.

Nous avons conçu Vectoryon AI — notre CoreAgent — délibérément autrement. Cet article explique ce qui le distingue, quels éléments comptent vraiment en 2026, et pourquoi un montage multi-agents est aujourd'hui le mauvais choix pour la plupart des entreprises. Avec des sources, pour que vous n'ayez rien à croire sur parole.

Ce qu'est notre CoreAgent

Vectoryon AI est un agent central doté d'une mémoire continue. Il lit, planifie, agit et rédige dans une boucle — et non un assemblage flou de nombreux agents égaux qui se pilotent les uns les autres.

Des sous-agents, il y en a bel et bien chez nous. Pour une recherche d'envergure, le Core peut détacher un assistant qui traite une partie en parallèle et renvoie son résultat condensé. La différence, c'est l'architecture : un Core qui garde le contrôle, plutôt que de multiples agents autonomes qui négocient entre eux. Ce n'est pas seulement plus propre — c'est aussi ce qui rend l'agent exploitable dans la durée. Améliorer une capacité, c'est modifier un Core, pas cent variantes d'agents qu'il faudrait tester, versionner et maintenir séparément. Cent chantiers deviennent un seul.

Trois propriétés le distinguent d'un agent open source standard :

Du code plutôt que clic après clic. Au lieu d'appeler un outil isolé à chaque étape, l'agent écrit un peu de code qui orchestre plusieurs outils d'un coup. La recherche est sans ambiguïté : dans les travaux CodeAct (Wang et al., ICML 2024), cette approche atteint jusqu'à 20 % de réussite en plus et demande environ 30 % d'étapes en moins que le schéma appel-par-appel. Moins d'étapes, c'est moins de sources d'erreur et des coûts plus bas.

Des autorisations plutôt qu'une confiance aveugle. Pour chaque requête, l'agent ne voit que les outils et les données débloqués pour l'utilisateur concerné — dérivés de la base de données, pas codés en dur. Si quelqu'un n'a pas accès à un système, son agent ne le connaît même pas. L'isolation des locataires est intégrée à chaque appel, pas un réglage qu'on peut oublier.

Chaque étape est traçable. Dans un système qui ne répond pas deux fois à l'identique, la trace est le produit, pas un sous-produit. Chaque décision, chaque appel d'outil, chaque résultat intermédiaire est consigné dans un journal continu. Quand l'agent fait quelque chose, on peut reconstituer pourquoi.

Pourquoi cela convient mieux à une entreprise que PI Agent ou Hermes

PI Agent et Hermes sont de corrects projets open source. Mais ce sont des kits, pas une solution prête à l'emploi pour une entreprise. Trois choses sont à ajouter soi-même — et ce sont justement les plus difficiles :

Le contexte du locataire. Garantir que le collaborateur A ne voie pas les données du collaborateur B doit être imposé de façon fiable — sur chaque outil, chaque accès aux données. C'est là que naissent les fuites coûteuses. Chez nous, cette couche est le cœur, pas un plugin ajouté après coup.

Un garde-fou pour les actions sensibles. Notre agent ne peut pas tout faire en même temps : traiter des entrées non fiables, toucher des systèmes sensibles et modifier un état externe. Si trop d'éléments se combinent, il s'arrête et demande à un humain. Une entrée venant d'un e-mail ou d'un document reste marquée durablement « non fiable » et n'est jamais exécutée comme une instruction — la protection la plus efficace contre l'injection de prompt.

La traçabilité. Sans trace complète, un agent est une boîte noire. Pour un outil qui envoie de vrais e-mails ou crée de vraies écritures, ce n'est pas une option dans la réalité d'une entreprise.

Les éléments essentiels pour de bons agents en 2026

Indépendamment du fournisseur — qui construit en 2026 un agent digne de la confiance d'une entreprise a besoin, au cœur, de ces éléments :

1. Le code-mode. Orchestrer les outils par du code plutôt que par appels isolés. Moins d'étapes, meilleur taux de réussite (CodeAct, ICML 2024).

2. Des autorisations par requête. Ce que l'agent peut faire est dérivé à l'exécution de l'identité de l'utilisateur — pas global, pas statique.

3. Une trace complète. Un journal continu comme vérité de l'exécution, pas un log a posteriori. On en reconstitue chaque exécution.

4. Une reprise robuste. La progression vit dans le journal. En cas de panne, on reprend à la dernière étape propre — sans exécuter deux fois la même action.

5. L'humain dans la boucle. Pour les actions sensibles, l'agent se met en pause et demande une validation au lieu de deviner.

6. La discipline du contexte. Le contexte est limité et coûteux. Anthropic le dit aussi : agrandir la fenêtre ne règle pas le problème, il faut condenser et résumer activement (Effective context engineering for AI agents, 2025). Un bon agent n'inonde pas sa fenêtre de bruit.

Pourquoi un montage multi-agents convient rarement à une entreprise aujourd'hui

L'idée séduisante : un « agent de recherche », un « agent de rédaction », un « agent de contrôle », tous autonomes, tous égaux. Avant de construire cela, il vaut la peine d'écouter les équipes qui s'y sont essayées.

Cognition — une entreprise dont le produit est lui-même un agent — l'a publiquement déconseillé en juin 2025 (« Don't Build Multi-Agents », cognition.com/blog). Leur constat : dès que plusieurs agents prennent en parallèle leurs propres décisions, ils le font sur la base d'hypothèses tacites, parfois contradictoires. Le résultat, ce sont des systèmes fragiles. Leur recommandation est un fil unique avec un modèle séparé pour condenser le contexte — soit exactement l'architecture que nous suivons.

Même Anthropic, qui utilise activement le multi-agents, pose une limite claire. Dans « How we built our multi-agent research system » (juin 2025), ils rapportent : le multi-agents ne l'emporte que sur des tâches qui se décomposent proprement en fils indépendants — et coûte alors environ 15 fois plus de tokens qu'un chat normal. Pour un travail étroitement imbriqué, où chaque étape s'appuie sur la précédente — le cas normal en entreprise — l'approche est moins adaptée.

Et les benchmarks confirment. Sur des tests d'outils sérieux (M3ToolEval, ICML 2024), ce sont les systèmes mono-agent qui livrent les meilleurs résultats, pas les essaims.

En bref : le multi-agents est un outil spécialisé pour la recherche parallèle à gros budget — pas le socle des flux quotidiens, imbriqués et sensibles aux coûts d'une entreprise. Plus d'agents, cela sonne comme plus de puissance. En pratique, ici, cela signifie plus de friction, des coûts plus élevés et moins de contrôle.

Notre conclusion

Un agent d'entreprise ne se juge pas à son brio en démo, mais à la possibilité de lui confier au quotidien de vraies tâches sur de vraies données. Cela exige une architecture claire : un Core qui garde le contrôle, des autorisations dans chaque appel, un garde-fou pour les actions sensibles et une trace complète. C'est exactement ainsi que nous avons construit Vectoryon AI.

Sources : Wang et al., « Executable Code Actions Elicit Better LLM Agents » (CodeAct), ICML 2024, arXiv:2402.01030 · Cognition, « Don't Build Multi-Agents », juin 2025 · Anthropic, « How we built our multi-agent research system », juin 2025 · Anthropic, « Effective context engineering for AI agents », 2025.