Meilleur logiciel ERP agentique : ce qu'il faut rechercher.

Pourquoi il n'y a pas de classement ici

Imaginez la liste restreinte. Quatre fournisseurs, quatre propositions, et le mot agentique sur chaque couverture. L'un est une suite établie avec un assistant ajouté l'année dernière. L'un est un produit plus récent construit autour de son propre agent. L'un est une plateforme qui permet à tout agent de se connecter via un protocole ouvert. L'un est un outil de flux de travail avec un modèle linguistique au milieu. Les quatre se présentent bien. Deux d'entre eux s'attendront toujours à ce qu'une personne soit devant l'écran pour tout ce qui franchit une frontière de module, et vous ne découvrirez pas lesquels deux à partir des propositions.

Une liste classée ne peut pas vous aider, pour une raison qui n'a rien à voir avec la qualité des produits. L'agentic est une propriété de l'architecture, et le fait qu'une architecture donnée soit adaptée à vos besoins dépend des modules que vous utilisez, de l'agent que votre équipe utilise déjà, de vos seuils d'approbation et de la quantité d'informations que vous devez voir dans le journal. Ce sont vos faits, pas ceux d'un évaluateur. Ce qui circule entre les entreprises, c'est l'ensemble des tests, donc cette page vous fournit les tests et vous demande de faire le classement.

Test 1 : protocole ouvert, votre agent de l'extérieur

Le premier test est de savoir si un agent que le fournisseur n'a pas construit peut faire fonctionner le système. La norme ouverte pour cela est le Model Context Protocol, que les clients agents principaux utilisent : Claude ajoute un serveur MCP distant en tant que connecteur personnalisé avec une connexion OAuth ; ChatGPT fait de même en mode développeur avec un support complet en lecture et écriture ; les agents de codage et les agents internes construits sur les SDK du fournisseur se connectent de la même manière. Un produit qui parle MCP peut être utilisé par n'importe lequel d'entre eux. Un produit qui ne fonctionne qu'avec son propre assistant ne peut être utilisé par personne d'autre, et cette décision a été prise pour vous.

La preuve à demander est la réponse du serveur à une demande tools/list, qui, selon le protocole, est la liste lisible par machine de tout ce que l'agent peut faire. Cela devrait ressembler à ceci, répété pour chaque action dans le système.

{
  "tools": [
    {
      "name": "contacts.search",
      "description": "Find contacts by name, email or company.",
      "inputSchema": { "type": "object", "properties": { "query": { "type": "string" } }, "required": ["query"] }
    },
    {
      "name": "invoices.create",
      "description": "Create a draft invoice from billable lines. Fails if the caller cannot raise invoices.",
      "inputSchema": { "type": "object", "properties": { "customer_id": { "type": "string" }, "lines": { "type": "array" } }, "required": ["customer_id", "lines"] }
    },
    {
      "name": "purchase_orders.approve",
      "description": "Approve a purchase order within the caller's approval limit.",
      "inputSchema": { "type": "object", "properties": { "purchase_order_id": { "type": "string" } }, "required": ["purchase_order_id"] }
    }
  ]
}

Une réponse illustrative d'outils/liste dans la forme définie par la spécification MCP. Les noms et la couverture varieront selon le produit ; ce qui importe, c'est que la liste existe, soit typée et soit suffisamment longue pour couvrir les modules que vous utilisez.

Trois choses à vérifier dans la liste. Elle est longue, car un ERP a des centaines d'actions et une liste de vingt signifie que l'assistant atteint vingt fonctionnalités. Elle est typée, avec un schéma JSON pour chaque entrée, car c'est ce qui permet au serveur de valider les appels plutôt que d'interpréter du texte. Et elle change lorsqu'un utilisateur plus restreint se connecte, ce qui est le lien vers le deuxième test.

Test 2 : permissions par utilisateur sur chaque appel

An agent that can do more than the person it represents is a liability, not a feature. The second test is whether permissions are enforced per user and per call, not per product or per session. The protocol allows a server to vary the tool list by the authorisation presented and requires servers to implement proper access controls, but it cannot enforce either on the vendor's behalf. The good implementations filter the list before the agent sees it and then check again when each tool runs, because a filtered list is a courtesy and an execution-time check is a control.

La preuve est un refus en direct. Connectez-vous en tant qu'utilisateur qui ne peut pas approuver les commandes d'achat, demandez à son agent d'en approuver une et regardez ce qui se passe. La bonne réponse est un refus clair au moment de l'appel, enregistré, avec le reste de la demande qui se termine toujours. Les mauvaises réponses sont une approbation qui passe, une erreur qui révèle ce que l'outil aurait fait, ou une session qui échoue parce que la vérification n'était que sur l'écran.

Test 3 : transparence du budget et des coûts

Un agent qui raisonne sur les modèles du fournisseur consomme quelque chose chaque fois qu'il s'exécute, et le troisième test est de savoir si vous pouvez limiter cette dépense et voir où elle est allée. Le mécanisme spécifique importe moins que les deux propriétés : une limite fixée par intégration ou par clé que l'agent ne peut pas dépasser, et un enregistrement par action de ce que chaque exécution a coûté. Un produit qui ne peut vous indiquer le total mensuel qu'après coup n'a pas construit le compteur, et vous le découvrirez lorsqu'une boucle incontrôlée ou un nouvel utilisateur enthousiaste atteindra la facture.

Il y a une deuxième question de coût que les pages de classement omettent complètement. Si le produit vous permet d'apporter votre propre agent, alors lorsque cet agent fait le raisonnement, le fournisseur peut ne pas effectuer d'IA en votre nom du tout, et ne rien facturer pour cela. Pour une équipe qui paie déjà pour Claude ou ChatGPT, cela transforme le coût de l'agent en une ligne que vous contrôlez plutôt qu'une ligne fixée par le fournisseur. Demandez à chaque fournisseur ce qu'il facture lorsque votre propre agent fait le raisonnement, et notez la réponse.

Test 4 : audit qui se lit comme le journal d'une personne

Lorsque l'agent effectue le travail, le journal devient le principal moyen pour un manager de l'examiner, donc le quatrième test est de savoir si la piste de vérification enregistre les actions de l'agent aussi complètement que celles d'une personne. Le minimum est de savoir qui a demandé, quel agent a agi en son nom, quels outils ont été utilisés, avec quelles entrées, avec quel résultat, et quand. Les propres directives du protocole indiquent que les clients doivent enregistrer l'utilisation des outils pour l'audit ; le serveur doit faire de même de son côté, car c'est le serveur qui sait ce qui a réellement changé.

La preuve est le journal lui-même, après la demande de démonstration. Ouvrez-le et vérifiez quatre choses : attribution à une personne, et non à un utilisateur d'intégration générique ; la séquence d'appels d'outils, et non seulement les enregistrements qui ont été modifiés ; les entrées et les résultats, afin qu'une action incorrecte puisse être retracée à une entrée incorrecte ; et les refus, car un modèle de permission qui ne consigne pas ses refus ne peut pas être ajusté.

Test 5 : un marché, et ce qu'il vous dit

Le cinquième test est indirect mais révélateur. Si une plateforme a un marché d'applications créées par des personnes autres que le fournisseur, et que ces applications sont exploitées par des agents via la même interface d'outil que les modules principaux, alors l'interface d'outil est réelle, documentée et suffisamment stable pour que des tiers puissent s'y appuyer. Un marché est l'architecture propre du fournisseur testée par des étrangers chaque jour. Cela répond également à la question pratique de ce qui se passe lorsque vous avez besoin d'une capacité que le produit principal n'a pas : si vous attendez la feuille de route, payez pour un travail personnalisé, ou installez quelque chose qui existe déjà.

La preuve est une application publiée par un tiers, installée dans votre espace de travail d'essai, apparaissant dans la liste des outils de l'agent lors de la prochaine demande. Si le marché existe mais que les applications sont toutes celles du fournisseur, ou si l'installation d'une ne change pas ce que l'agent peut faire, le test n'est que partiellement réussi.

Le tableau de bord

Apportez cela à chaque démonstration et remplissez-le le jour même. Évaluez chaque test comme réussi, partiel ou échoué, et insistez pour voir la preuve plutôt que d'en entendre parler. Un produit qui échoue au premier test est un produit avec un assistant, peu importe ce que dit la couverture, et les quatre autres tests deviennent académiques.

Sois est une mise en œuvre contre laquelle vous pouvez effectuer ces tests, et comme nous l'avons construit, nous pouvons dire comment il répond. Un espace de travail est un serveur MCP ; tout client compatible se connecte en ajoutant l'adresse de l'espace de travail et en se connectant une fois via OAuth, sans token à coller. Les outils sont filtrés par le rôle de l'utilisateur avant d'être proposés et vérifiés à nouveau lorsqu'ils sont exécutés, et l'accès échoue en mode fermé. Les dépenses peuvent être plafonnées par intégration, chaque action est enregistrée, et lorsque votre propre agent effectue le raisonnement, la plateforme n'effectue aucune IA en votre nom et ne facture rien pour cela. Les développeurs créent des applications avec leur propre agent, valident localement gratuitement et publient sur un marché où chaque agent connecté peut les appeler. Effectuez les mêmes cinq tests contre lui que contre tous les autres ; c'est à cela qu'ils servent.

Questions que les gens posent

Cet article est révisé lorsque les produits qu'il décrit changent. Prochaine révision prévue : 4 décembre 2026.