Cohere propose de mettre en concurrence les agents IA en doublon pour mériter leur place en entreprise

Le 15 octobre 2026, Cohere a publié sur son blog d'entreprise un article consacré à ce qui se passe quand des employés se mettent à créer eux-mêmes des agents IA, sans équipe centrale pour les superviser. Son auteur, Kasim Patel, architecte de solutions senior, décrit un tableau classique : les agents se multiplient, personne n'en connaît la liste complète, les équipes ne trouvent pas ce qui existe déjà, et l'accès aux données et aux systèmes de l'entreprise devient de plus en plus difficile à contrôler. Il nomme cet état agent sprawl. La recette de l'entreprise : ne pas chercher à réprimer les doublons, mais les mettre en concurrence.

L'article sert aussi de vitrine à North 2, la plateforme d'agents sécurisée de Cohere, qui fonctionne au plus près des données du client. Le texte ne fournit aucun chiffre à l'appui, par exemple la part d'agents en doublon ou les économies réalisées. Il s'agit davantage d'un cadre de réflexion que d'une étude.

La hausse du nombre d'agents n'est pas encore un problème

Patel écarte d'emblée la principale crainte. Les plateformes à l'origine du sprawl rendent l'expérimentation peu coûteuse. Les employés n'ont pas besoin de passer à chaque fois par l'équipe centrale d'IA ou de développement : ceux qui sont les plus proches d'un processus voient mieux ce qu'on peut y automatiser. Un agent réussi dans une équipe peut convenir à une autre, et la diffusion des agents montre alors que les gens cherchent activement des cas d'usage.

La question des coûts est traitée à part. Un agent que personne n'utilise ne consomme pas de tokens du simple fait d'exister. La multiplication des agents n'alourdit donc pas forcément la facture d'inférence. La charge apparaît quand les processus de gouvernance ne suivent pas le nombre d'agents. C'est à ce moment que la proliferation se transforme en sprawl.

Trois modèles et un registre

Aujourd'hui, les entreprises choisissent principalement entre trois schémas :

• centralisé : une équipe centrale construit les agents et en répond. Le contrôle est plus strict, mais le rythme d'innovation est plus lent ;
• fédéré : les unités métier assurent le développement et l'exploitation, tandis que le centre fournit l'infrastructure, les standards et les modèles de gouvernance ;
• hybride : la responsabilité est partagée entre le centre et les métiers, sous des standards communs.

Dans les trois cas, un registre d'agents apparaît de plus en plus souvent. Il enregistre le propriétaire, l'usage et les droits d'accès, et aide les employés à retrouver ce qui a déjà été construit. La logique est claire : réutiliser d'abord, créer ensuite. Moins de variantes qui se recoupent à choisir, moins d'agents à surveiller et à auditer.

Mais le principe « aucun doublon » a un prix. Si l'existence même d'un agent opérationnel ferme la porte aux alternatives, l'organisation ne saura pas qu'on pourrait faire moins cher, plus fiable ou plus précis pour une tâche donnée.

Le challenger contre l'agent en place

Cohere propose de considérer le doublon comme temporaire. Si une équipe a de solides raisons de penser qu'elle peut améliorer l'agent « en place », elle est autorisée à construire un « challenger ». Mais celui-ci ne reste en production que s'il présente un avantage mesurable. Cela suppose une comparaison limitée dans le temps et fondée sur des données. L'ensemble des métriques dépend du scénario ; l'article cite en exemple :

• la fiabilité ;
• la consommation de tokens ;
• la latence de réponse.

Dans l'extrait du texte dont nous disposons, la liste s'interrompt : la liste complète des critères et les détails de la procédure ne sont donc pas connus ici.

Comment l'appliquer en pratique

L'idée se teste sans acheter de plateforme. Premièrement, créez un registre indiquant, pour chaque agent, le propriétaire, les droits d'accès et les statistiques d'usage. Sans lui, il n'y a rien à comparer. Deuxièmement, définissez à l'avance ce qui compte comme un avantage : par exemple, moins de tokens par tâche à fiabilité égale. Troisièmement, fixez une échéance : un pilote sans date limite devient vite un agent permanent de plus. Quatrièmement, décidez du sort du perdant : on le désactive, on l'archive ou on le fusionne avec le gagnant.

L'article laisse de côté une question distincte : qui paie pour le fonctionnement en parallèle des deux agents pendant le test, et comment les comparer sur des données réelles plutôt que commodes. Ces détails détermineront si ce modèle devient un outil de sélection ou une couche de bureaucratie de plus.