Réponse courte. Un agent IA n'a jamais accès à votre base : il a accès à des outils, écrits un par un, chacun faisant une chose nommée avec des paramètres typés. Le modèle propose un appel ; c'est votre serveur qui l'exécute, après être passé par la même porte à chaque fois : le rôle de celui qui parle à l'agent autorise-t-il cet outil, les paramètres existent-ils dans vos données, le montant est-il sous le plafond, cet appel a-t-il déjà été exécuté. Les lectures passent seules ; les écritures passent sous plafond avec un aperçu ; au-dessus du plafond, elles deviennent une demande d'approbation sur le téléphone de celui qui peut dire oui ; ce que le rôle n'a pas n'existe pas pour l'agent. Chaque appel, exécuté ou refusé, a une ligne de journal. L'agent n'a jamais plus de droits que la personne qu'il assiste. Huit semaines, dont deux où il ne peut rien écrire.
Ce guide s'adresse au gérant qui veut que l'IA fasse enfin quelque chose dans son logiciel de gestion, au fondateur installé en France qui veut piloter son back-office par messages, et à la direction informatique qui doit dire oui ou non au branchement d'un agent sur la comptabilité. Il ne redit pas par où commencer ni quels usages paient, décrits dans le guide sur l'agent en entreprise, ni comment l'agent vit sur WhatsApp, décrit dans le guide dédié ; il décrit ce qui se construit entre le modèle et votre ERP, et il prolonge notre page sur les fonctions IA.
Ce que les chiffres disent
Le modèle propose, votre code exécute : c'est écrit chez les éditeurs eux-mêmes. La documentation d'Anthropic décrit l'usage d'outils ainsi : le modèle « détermine quand appeler un outil d'après la demande de l'utilisateur et la description de l'outil », puis « renvoie un appel structuré que votre application exécute » ; votre code fait l'opération et renvoie le résultat. Celle d'OpenAI dit la même chose : « quand le modèle appelle une fonction, vous devez l'exécuter et renvoyer le résultat ». Ce que cela impose : tout ce qui protège votre ERP se trouve dans votre code, entre la proposition du modèle et l'exécution, et aucun réglage du modèle ne remplace cette porte.
La forme de l'appel peut être garantie, pas son sens. Les deux éditeurs proposent un mode strict qui, selon OpenAI, « garantit que les appels de fonction respectent fidèlement le schéma de la fonction, au lieu d'être au mieux », et recommandent de l'activer toujours. Mais la documentation d'Anthropic prévient aussi que, lorsqu'un paramètre obligatoire manque dans la demande, le modèle peut « inférer une valeur raisonnable » plutôt que de la demander, et que ce comportement « n'est pas garanti ». Ce que cela impose : un montant d'avoir proposé par le modèle est au bon format, mais il peut être inventé ; la porte le vérifie contre la facture, et l'aperçu le montre avant d'écrire.
La liste d'outils a une taille raisonnable, écrite. OpenAI recommande « des noms de fonctions et des descriptions de paramètres clairs et détaillés », l'usage de valeurs énumérées « pour empêcher les états invalides », et de garder la liste « petite pour une meilleure exactitude », avec moins de vingt fonctions disponibles au début d'un tour ; sa règle pratique est le « test du stagiaire » : une personne qui ne verrait que la fiche de l'outil saurait-elle s'en servir correctement ? Ce que cela impose : pas d'outil « exécuter une requête » ni « modifier un champ », mais un outil par action métier, créer un avoir, envoyer une relance, et une liste par rôle. Ce que nous n'avons pas trouvé : une mesure publique des incidents causés par des agents dans des ERP ; ce que nous voyons, ce sont les six pièges décrits plus bas, et nous les disons comme une observation.
Une demande devient quatre appels d'outils
L'agent ne se comprend pas sur un schéma mais sur une demande réelle du gérant, et sur ce que chacun de ses appels devient.
La demande arrive à 9 h 12 avec le nom et le rôle du gérant : relancer les clients en retard de plus de trente jours, préparer les avoirs des retours de la semaine. L'agent la découpe en appels. Le premier lit les clients en retard : lecture autorisée pour ce rôle, vingt-trois clients, et la lecture elle-même est écrite au journal. Le deuxième envoie les relances : une écriture, mais sous plafond, vingt-trois envois pour une limite de cinquante par jour, avec un gabarit approuvé et aucun texte libre, et une clé d'idempotence pour que l'appel renvoyé après une coupure n'envoie pas deux fois ; exécuté.
Le troisième crée un avoir de 12 400 dinars : la facture existe et appartient au bon client, le montant se retrouve dans la facture, mais il dépasse le plafond de 10 000 dinars écrit pour ce rôle ; l'appel devient un aperçu envoyé au gérant sur son téléphone par la notification décrite dans le guide sur les notifications, et l'avoir n'existe pas tant qu'il n'a pas approuvé d'une touche. Le quatrième veut supprimer une facture : cet outil n'est pas dans la liste du rôle « agent », il n'existe pas pour lui, aucun paramètre n'est même lu, et la tentative est écrite. Quatre appels, quatre lignes de journal, une seule décision humaine, et aucune action que le gérant n'aurait pas pu faire lui-même.
Un agent dans le back-office, en cinq couches
Derrière ces quatre appels, cinq couches, et celle du milieu est la seule qui dit non.
Le canal : le gérant parle à l'agent depuis WhatsApp, le back-office ou un bouton dans l'écran ; la demande arrive avec son nom et son rôle, et l'agent n'a jamais plus de droits que lui, selon les règles décrites dans le guide sur les rôles. L'agent : le modèle lit la demande, choisit les outils, propose les paramètres et explique ce qu'il va faire ; il propose, il n'exécute pas, et ses instructions et ses limites sont versionnées dans votre dépôt. Les outils et la porte : une fiche par outil, lecture ou écriture, schéma strict ; la porte vérifie le rôle, les paramètres contre vos données, le plafond, l'idempotence, puis journalise ; c'est la couche qui vous appartient et qui ne dépend d'aucun éditeur.
L'ERP et les données : votre logiciel de gestion ou votre comptabilité, appelés par leur API ou leur connecteur, jamais par la base en direct, avec les mêmes règles métier que pour un humain, stock, crédit, numérotation ; la manière de les brancher est celle du guide sur l'intégration. La supervision : le journal des appels, les approbations en attente, les refus, le coût par tâche, et le jeu d'évaluation rejoué à chaque changement, selon le guide sur la mesure ; un écran lu chaque semaine qui dit ce que l'agent a fait, ce qu'on lui a refusé, et ce qu'il a coûté.
«Le modèle propose ; le serveur dispose. Un paramètre deviné est arrêté à la porte, pas chez le client.»
Un outil, vu par l'agent et vérifié par le serveur
La fiche d'un outil est tout ce que le modèle sait ; la porte est tout ce que le serveur fait, quoi que le modèle envoie.
Ce que le modèle lit : un nom, créer un avoir ; une description qui dit quand s'en servir et quand ne pas le faire, « seulement pour un retour ou une erreur de prix constatés, ne jamais deviner le montant » ; et trois paramètres typés, le numéro de facture, le montant en dinars, le motif parmi trois valeurs et rien d'autre. Le schéma est strict : l'appel aura toujours cette forme. Ce que le serveur vérifie, quoi que le modèle envoie : le rôle « agent » a-t-il cet outil ; la facture existe-t-elle, pour ce client ; le montant est-il bien une ligne de la facture et est-il sous le plafond ; cet appel a-t-il déjà été exécuté, par sa clé ; l'aperçu a-t-il été montré ; la ligne de journal est-elle écrite.
La troisième vérification est celle qui répond à l'avertissement des éditeurs : un modèle peut inventer un montant plausible quand il manque ; la porte refuse tout montant qui n'est pas dans la facture, et l'agent demande au lieu d'exécuter. La cinquième est celle qui rassure le gérant : rien ne s'écrit dans la comptabilité avant qu'un aperçu ait été montré, et au-dessus du plafond, approuvé. Le modèle propose ; le serveur dispose. Un paramètre deviné est arrêté ici, pas chez le client.
Six demandes d'un gérant, et les outils qu'elles deviennent
Six demandes que nous entendons, et pour chacune les outils, les plafonds et l'approbation qu'elle devient.
Relancer les retards : lecture des soldes, puis envoi par gabarit approuvé, sous plafond quotidien, jamais de texte libre, et la liste des envoyés en retour. Créer un avoir : écriture sous plafond, montant pris dans la facture et jamais saisi, aperçu et approbation au-dessus. Passer une commande fournisseur : lecture du stock et des ventes, proposition, et création en brouillon seulement, validée par un humain, parce qu'une commande engage de l'argent qui sort.
Modifier un prix : écriture sous plafond par rôle, approbation au-delà, ancienne valeur gardée, effet daté ; c'est la règle du portail B2B. Répondre à un client : lecture de la commande et de la tournée, réponse sourcée, et jamais une promesse qui n'est pas dans les données. Sortir un état : lecture des agrégats déjà définis pour le tableau de bord, aucun calcul inventé, pour que le chiffre de l'agent et celui de l'écran soient le même. Aucune de ces lignes ne contient un outil générique : chaque outil fait une chose nommée, et c'est ce qui rend l'agent prévisible.
«L'agent n'a jamais plus de droits que la personne qu'il assiste, et ce que son rôle n'a pas n'existe pas pour lui.»
Six pièges d'un agent dans l'ERP
Six pièges que nous voyons sur les agents que nous reprenons, et ce que l'architecture fait contre chacun.
L'outil trop large : « exécuter une requête », « modifier n'importe quel champ » ; l'agent fait ce qu'il comprend, et personne ne peut dire d'avance quoi ; un outil par action métier, paramètres typés, valeurs énumérées, moins de vingt outils par agent. Le paramètre deviné : le gérant n'a pas dit le montant, le modèle en invente un plausible ; paramètre vérifié contre la donnée source, et s'il n'y est pas, l'agent demande. La double exécution : la connexion coupe, l'appel est renvoyé, deux avoirs ; clé d'idempotence par appel, la seconde exécution renvoie le résultat de la première, sur le principe décrit dans le guide sur le mode hors ligne.
L'écriture sans aperçu : l'agent écrit dans la comptabilité avant que quiconque ait vu quoi ; aperçu systématique, approbation au-dessus du plafond. L'agent plus puissant que l'humain : un compte administrateur « pour simplifier », et le commercial lui fait faire ce qu'il ne peut pas ; l'agent hérite du rôle de celui qui lui parle, jamais plus, avec un rôle « agent » propre et plus étroit. L'action sans trace : personne ne sait que c'est l'agent qui a changé ce prix ; ligne de journal par appel, qui a demandé, quel outil, quels paramètres, avant, après, refus compris. Les deux premiers viennent de la fiche d'outil, les quatre autres de la porte, et tous se décident la première semaine.
Vu ailleurs : les documentations d'outils des éditeurs, et ce qui se transpose
Deux sources disent l'essentiel. Les documentations d'Anthropic et d'OpenAI disent que le modèle propose un appel structuré et que votre code l'exécute, que le mode strict garantit la forme de l'appel, et qu'un paramètre manquant peut être inféré plutôt que demandé ; ce qui se transpose, c'est que la sécurité d'un agent est une question de code côté serveur, pas de modèle, et que la forme garantie n'exempte pas de vérifier le sens. OpenAI dit encore de garder moins de vingt outils, avec des noms clairs et des valeurs énumérées ; ce qui se transpose, c'est une liste courte d'outils métier par rôle, pas un outil générique.
Ce que ces sources ne disent pas : quelles actions votre gérant veut déléguer, quels plafonds il accepte, et qui approuve au-dessus ; la première semaine du projet y répond, avec les dix demandes qu'il fait vraiment.
Les règles d'un agent qu'on peut brancher sur l'ERP
Six règles, écrites la première semaine. L'agent ne voit que des outils, jamais la base. Un outil fait une chose nommée, avec des paramètres typés et des valeurs énumérées ; moins de vingt par rôle. La lecture avant l'écriture, et chaque écriture a un plafond et un aperçu. Au-dessus du plafond, une approbation, sur le téléphone de celui qui peut dire oui. Une clé par appel : rien ne s'exécute deux fois. Une ligne de journal par appel, refus compris, et l'agent n'a jamais plus de droits que la personne qu'il assiste.
Une septième règle porte sur le devis : « agent IA connecté à l'ERP » n'est pas une exigence, c'est une phrase ; l'exigence s'écrit « liste des outils par rôle, lecture ou écriture, schéma strict et description par outil ; porte côté serveur vérifiant rôle, paramètres contre les données, plafonds, idempotence ; aperçu avant écriture ; approbation sur téléphone au-dessus du plafond ; journal par appel avec avant et après ; jeu d'évaluation de soixante demandes réelles incluant paramètres manquants, hors droits et doublons ; deux semaines de lecture seule avant la première écriture », et elle se vérifie comme le guide sur le cahier des charges le recommande. Un devis qui chiffre « l'accès de l'IA à la base » a chiffré le piège numéro un.
Six entreprises, et le premier outil d'écriture qu'on ouvre
Six entreprises que nous équipons souvent, et pour chacune le premier outil d'écriture ouvert après les deux semaines de lecture.
- Le distributeur et son portail, décrit dans le guide dédié. La relance des retards par gabarit, sous plafond quotidien ; les avoirs restent en approbation plusieurs semaines.
- Le cabinet comptable. Le classement des pièces lues dans le bon dossier client ; aucune écriture comptable par l'agent avant le deuxième mois.
- La clinique. La prise de rendez-vous dans les créneaux libres ; jamais le dossier médical en écriture.
- L'agence immobilière. La génération des quittances du mois en brouillon, validées en lot par le gérant.
- L'école privée. Les rappels d'échéance aux parents par gabarit ; les remises sur frais de scolarité en approbation.
- L'entreprise pilotée depuis la France. L'état du jour par agence en lecture ; l'approbation des avoirs et des remises sur le téléphone du fondateur, où qu'il soit.
Le calendrier 2027
Le calendrier est celui d'un agent branché sur le back-office en huit semaines, dont deux où il ne peut rien écrire.
La semaine 0 à 1 écrit les demandes et les outils : les dix demandes que le gérant fait vraiment, la liste des outils avec lecture ou écriture, plafond et approbateur ; signée. La semaine 1 à 2 écrit le jeu d'évaluation : soixante demandes réelles avec les appels attendus, et les pièges, paramètre manquant, demande hors droits, doublon. Les semaines 2 à 4 construisent les outils de lecture et la porte : fiches, schémas stricts, vérification du rôle et des paramètres, journal ; l'agent répond et explique ce qu'il ferait, et n'écrit rien.
Les semaines 4 à 6 ouvrent les outils d'écriture, un à la fois : plafonds, idempotence, aperçu, approbation sur le téléphone. Les semaines 6 à 8 sont le pilote avec le gérant et deux personnes : chaque refus et chaque approbation lus chaque jour, le coût par tâche mesuré, et chaque erreur ajoutée au jeu. Chaque lot est démontré comme le guide sur la livraison le décrit ; et quand les demandes contiennent des documents sensibles, le modèle tourne là où le guide sur le déploiement privé le prévoit.
Ce qui fait échouer un agent dans l'ERP
Les agents que nous reprenons ont presque toujours échoué pour l'une de ces raisons.
- L'accès direct à la base. Le modèle écrit des requêtes ; personne ne sait lesquelles à l'avance.
- L'écriture dès le premier jour. Pas de période de lecture seule ; la confiance n'a jamais été construite.
- Pas de plafond. Une remise de 40 % accordée parce que le client a insisté.
- Pas de clé d'idempotence. Une coupure réseau, et trois factures identiques.
- L'agent administrateur. Il fait pour le commercial ce que le commercial n'a pas le droit de faire.
- Des outils génériques. « Modifier un enregistrement » : l'agent a modifié le mauvais.
- Pas de journal des refus. On ne sait pas ce que l'agent a essayé, ni qui le lui a demandé.
Questions fréquentes
Les questions que nous recevons de gérants, de fondateurs et de directions informatiques.
- L’agent peut-il écrire dans notre comptabilité ou notre ERP ?
- Oui, par des outils que nous écrivons un par un, jamais par la base : chaque outil fait une action nommée, créer un avoir, envoyer une relance, avec des paramètres typés. Le modèle propose l'appel ; votre serveur le vérifie, rôle, paramètres contre vos données, plafond, doublon, et l'exécute ou le refuse. Au-dessus d'un plafond, l'action devient une demande d'approbation sur le téléphone de celui qui peut dire oui.
- Que se passe-t-il si l’agent se trompe de montant ou de client ?
- La porte l'arrête avant l'écriture : un montant qui n'est pas une ligne de la facture est refusé, une facture qui n'appartient pas au client aussi, et un paramètre manquant fait que l'agent demande au lieu de deviner. Pour les écritures, un aperçu est montré avant d'écrire, et au-dessus du plafond, rien ne s'écrit sans approbation. Chaque refus est dans le journal.
- Et si la même action est exécutée deux fois ?
- Chaque appel porte une clé d'idempotence ; si la connexion coupe et que l'appel est renvoyé, la seconde exécution renvoie le résultat de la première au lieu de créer un deuxième avoir ou de renvoyer vingt-trois relances. C'est la même mécanique que pour une application hors ligne qui se resynchronise.
- L’agent a-t-il plus de droits que mes employés ?
- Jamais. Il hérite du rôle de la personne qui lui parle, et il a en plus un rôle « agent » propre, plus étroit : lecture du nécessaire, écritures sous plafond, pas de suppression, pas d'export. Un commercial ne peut pas lui faire faire ce qu'il n'a pas le droit de faire lui-même, et chaque action porte les deux noms dans le journal.
- Comment savoir ce que l’agent a fait ?
- Par le journal : une ligne par appel, qui a demandé, quel outil, quels paramètres, la valeur avant et après, et le résultat, exécuté, en attente ou refusé. Un écran hebdomadaire résume ce qu'il a fait, ce qu'on lui a refusé, ce qu'il a coûté, et le jeu d'évaluation est rejoué à chaque changement d'outil ou de modèle.
- Combien de temps pour brancher un agent ?
- Huit semaines : une pour écrire les demandes et la liste des outils, une pour le jeu d'évaluation, deux pour les outils de lecture et la porte, pendant lesquelles l'agent explique sans écrire, deux pour ouvrir les outils d'écriture un à un avec leurs plafonds, deux de pilote avec le gérant. L'agent n'écrit rien avant la cinquième semaine.