Passer au contenu principal

Plateforme ECOSIRE

Qu'est-ce que l'ERP agentique ?

L'ERP agentique est un ERP dans lequel les agents IA sont des comptes à part entière, et non une fenêtre de chat. Un agent ECOSIRE possède sa propre fiche : la liste explicite des outils qu'il peut appeler, le niveau de risque maximal auquel il peut agir sans humain, et une limite d'actions par heure. Chaque action tentée suit un seul chemin — proposition, contrôle de politique, validation lorsque nécessaire, exécution durable, écriture au journal — et aucune écriture d'agent ne peut le contourner. Les actions notées critiques, comme comptabiliser une écriture ou enregistrer un paiement, exigent une personne à tous les niveaux d'autonomie, y compris le plus élevé.

Réserver une évaluation ERP agentique
Politique
110
low · medium · high · critical
L'échelle d'autonomie
3
L0 · L1 · L2
Connectez vos propres agents via MCP
POST /api/mcp
eco_live_…

Le chemin unique que suit toute action d'agent

Il n'existe pas de second itinéraire. Un agent ne peut pas écrire directement en base, et un outil ne peut pas être appelé hors circuit : la passerelle est la seule porte, et c'est elle qui écrit le journal.

  1. Proposer

    L'agent nomme un outil et fournit ses arguments. Un nom d'outil inconnu, ou des arguments qui échouent au schéma, sont rejetés d'emblée, avant qu'aucune entrée de journal n'existe : le journal consigne des décisions sur des propositions valides, pas des appels mal formés.

  2. Politique

    Trois contrôles peuvent refuser d'emblée : l'agent est-il actif, cet outil figure-t-il sur sa liste blanche, et reste-t-il dans son budget d'actions horaire. Un refus sur l'un d'eux est écrit au journal avec son motif. Un quatrième contrôle n'est pas un refus : si la note de risque de l'outil dépasse le plafond de l'agent, ou qu'elle est critique, la proposition est acheminée vers une personne plutôt que rejetée.

  3. Valider

    Tout ce qui dépasse le plafond de l'agent — et tout ce qui est noté critique, toujours — atterrit dans une boîte de validation en tant que proposition en attente et laisse une note sur la chronologie de l'enregistrement concerné. Une personne valide ou refuse, et son identité est conservée avec la décision.

  4. Exécuter

    Le travail validé rejoint une file durable sous un identifiant dérivé de l'action, de sorte qu'une nouvelle tentative ne peut pas l'exécuter deux fois. Le worker revérifie que l'agent est toujours actif et que l'outil existe encore avant de toucher à quoi que ce soit, et un job qui meurt en vol est récupéré plutôt que laissé bloqué.

  5. Journal

    Succès ou échec, le résultat est stocké avec le motif de la décision — et, lorsqu'un modèle est intervenu, avec le modèle et la version de prompt, les jetons consommés et le coût en micro-dollars entiers, jamais un flottant. Les entrées ne sont ni modifiées ni supprimées logiquement en fonctionnement normal ; supprimer un compte d'agent supprime son historique avec lui. Exportez en JSON pour l'enregistrement complet, ou en CSV pour les champs de décision. La chronologie de l'enregistrement reçoit également le résultat, si bien que les personnes qui travaillent dessus voient ce qu'a fait l'agent sans ouvrir un écran d'administration.

L'échelle d'autonomie

Un curseur par agent, trois positions. Ce que le curseur règle réellement, c'est un seul nombre : le niveau de risque au-dessus duquel une personne doit valider. Démarrez chaque agent en L0, lisez son journal pendant une semaine, puis décidez de le relever ou non.

L'échelle d'autonomieValider
L0 Suggestexécute seul jusqu'à none
L1 Assistexécute seul jusqu'à low
L2 Operateexécute seul jusqu'à high

Aucun niveau ne correspond à un plafond critique, car le critique ne s'exécute jamais seul. Le niveau maximal sélectionnable est L2 : relever le curseur élargit ce qui tourne sans surveillance, cela ne supprime jamais l'obligation de validation sur les actions critiques.

Connectez vos propres agents via MCP

Connectez vos propres agents via MCP

POST /api/mcp implémente le Model Context Protocol sur HTTP streamable sans état. Authentifiez-vous avec une clé d'agent émise depuis la console d'administration — la clé en clair n'est affichée qu'une fois — et le serveur liste les outils métier de la liste blanche de cet agent, plus quatre contrôles intégrés pour lire l'état des actions et piloter les exécutions de boucle. Rien en dehors de la liste blanche n'est proposé. Un tools/call entre dans la même passerelle que nos propres agents : mêmes contrôles de politique, même boîte de validation, même journal. GET répond 405 volontairement ; ici, MCP se fait uniquement en POST.

Un exemple concret : l'agent de recouvrement

Il s'active par organisation : pas de compte d'agent de recouvrement, pas d'analyse. Chaque matin, il passe en revue les factures échues et propose une relance par facture à 7, 14 ou 30 jours, avec une clé qui empêche une seconde passe le même jour de la dupliquer. En dessous de L2, il ne peut pas envoyer du tout : la proposition reste dans la boîte de validation. L'envoi est conditionné à la liste de suppression, et une erreur dans ce contrôle signifie ne pas envoyer. Proposer un lettrage de paiement est noté critique, donc cela reste une proposition pour toujours, à tous les niveaux.

Ce qui empêche un agent de déraper

Une clé d'agent est cloisonnée de tous les chemins de clés utilisateur : elle ne peut donc jamais agir en tant que personne. Chaque requête est cantonnée à votre organisation dans le code applicatif — c'est le contrôle principal ; la sécurité au niveau des lignes en base est provisionnée sur les tables métier centrales et fonctionne encore en mode permissif pendant son déploiement, considérez-la donc comme une défense en profondeur, pas comme ce qui tient la ligne. Suspendre un agent l'arrête à la porte et en plein vol : l'exécuteur revérifie qu'il est toujours actif avant de lancer une action déjà validée. Les envois échouent en position fermée face à la liste de suppression. Les exécutions de boucle non surveillées disposent en plus d'un coupe-circuit : un drapeau pour toute la flotte, un champ par agent.

Envie de le voir sur vos propres données ?

Dites-nous sur quel processus vous mettriez un agent en premier, et nous le parcourrons avec vous le long de l'échelle — en partant de L0, où il propose et n'exécute rien.