Plurai lève 13 millions de dollars pour un simulateur qui détecte les erreurs des agents IA

L’agent sait réserver des déplacements professionnels, jusqu’au moment où un salarié lui demande de faire une exception et d’acheter un billet dépassant le plafond autorisé. La démonstration était convaincante ; dans le système de production, une dépense supplémentaire est apparue. La startup Plurai propose de reproduire ces situations à l’avance dans un simulateur de systèmes d’entreprise. Pour les développeurs, la question est concrète : comment tester le comportement d’un agent avant de lui donner accès à des opérations réelles ?

Selon TechCrunch, l’entreprise a levé 13 millions de dollars en amorçage. Le tour de table a été mené par Team8, avec la participation de U&I, Velocity et Mercer. Les fondateurs, Ilan Kadar et Elad Levi, travaillaient auparavant chez Nexar, et Kadar a travaillé avec Waymo sur la simulation et l’évaluation de logiciels de conduite autonome. L’équipe applique désormais cette expérience aux agents logiciels.

Comment fonctionne le banc d’essai

Plurai crée une réplique numérique de l’environnement dans lequel l’agent doit travailler : les bases de connaissances et les outils auxquels il a accès. La plateforme construit ensuite un graphe des actions possibles et s’en sert pour préparer des tests de scénarios complexes. Selon l’entreprise, cette approche permet de détecter et de corriger les erreurs avant le déploiement.

Reprenons l’assistant chargé des déplacements professionnels. Un test classique indiquera s’il sait trouver un vol et effectuer une réservation. Une simulation permet de tester un enchaînement plus délicat : le billet qui convient dépasse le budget, l’utilisateur insiste pour l’acheter et la règle relative aux exceptions figure dans un document distinct. La réussite signifie ici que l’agent a correctement géré la contrainte, et pas simplement finalisé la réservation. Il s’agit d’une illustration de l’approche, et non d’un résultat de test publié par Plurai.

Un problème similaire se pose dans le traitement des données. Répondre à une question à partir d’une seule base est plus simple que de recouper des informations issues de plusieurs systèmes et de choisir la bonne action. Un long échange avec un client ajoute une difficulté : l’agent doit conserver les contraintes de la tâche malgré l’accumulation du contexte.

Pourquoi miser sur de petits modèles

Les tests constituent le premier volet du projet. Le second consiste à utiliser les données synthétiques obtenues pour affiner de petits modèles à poids ouverts en fonction des tâches d’un client donné. Selon TechCrunch, la plateforme fonctionne aux côtés des outils existants, notamment Claude Code, Codex, Copilot et Cursor.

La logique est claire : si un agent effectue un ensemble limité d’opérations, l’entreprise peut avoir intérêt à entraîner un modèle spécifiquement pour celles-ci. Le simulateur doit alors aider à décomposer une tâche importante en tâches plus petites et à vérifier que le niveau de qualité requis est maintenu après le remplacement du modèle.

Kadar affirme qu’il est possible de diviser les coûts par 10 à 100, avec une qualité comparable ou supérieure à celle des grands modèles. L’article mentionne également des essais menés avec Nvidia et Nebius, au cours desquels les modèles de Plurai auraient, selon l’entreprise, dépassé certains modèles de pointe de taille intermédiaire, à moindre coût.

Mais le texte fourni ne présente ni méthodologie détaillée, ni composition des tâches, ni noms des modèles comparés, ni calcul complet des coûts. Ces chiffres doivent donc être considérés comme des déclarations du fournisseur. Ils ne permettent pas encore d’estimer les économies réalisables pour un autre produit.

Que vérifier avant le déploiement

La principale limite de cette approche tient à la fidélité avec laquelle le simulateur reproduit l’environnement de production. S’il ne prend pas en compte les restrictions d’accès réelles, les documents obsolètes ou les défaillances des outils, de bons résultats aux tests peuvent donner un faux sentiment de confiance. Il est également difficile de tester littéralement toutes les actions possibles d’un agent dans un système complexe ; un graphe de scénarios ne garantit pas, à lui seul, une couverture exhaustive.

La question économique se pose aussi. Un appel de modèle moins cher ne signifie pas nécessairement qu’une tâche menée à bien coûte moins cher. Il faut tenir compte des nouvelles tentatives, des interventions humaines, de la maintenance du simulateur et de la mise à jour de l’entraînement après toute modification des règles de l’entreprise.

Pour une équipe qui déploie déjà des agents, une démarche utile consiste à rassembler ses propres cas d’échec et à les transformer en tests reproductibles. Par exemple, en mesurant séparément l’achèvement de la tâche, le respect des règles internes et le besoin de corrections manuelles. Plurai propose de combiner ces tests avec la préparation de données d’entraînement. L’intérêt réside dans la possibilité de détecter systématiquement les erreurs d’un processus de travail précis ; les économies promises devront être confirmées sur les tâches propres à chaque entreprise.