--- title: "Un agent qui écrit dans l'ERP : la frontière entre lire et écrire" url: "https://hurukan.com/fr/blog/un-agent-qui-ecrit-dans-l-erp" description: "Lire un système d'enregistrement ne coûte rien. C'est à l'écriture que les intégrations échouent. Ce qu'il faut avant qu'un agent écrive, et où Hurukan trace sa ligne." --- # Un agent qui écrit dans l'ERP : la frontière entre lire et écrire 20 octobre 2026·5 min de lecture·La rédaction Un comptable vu de profil à un bureau avec deux écrans, l'un affichant un grand livre abstrait en bleu et gris, une main posée sur la souris et un document imprimé tenu contre l'écran pour comparaison, lumière de bureau froide Une équipe achats mène un pilote. Un agent lit les besoins ouverts, les stocks et les délais fournisseurs, et pendant trois semaines il fait exactement ce que tout le monde espérait : il propose des commandes, les acheteurs les vérifient, les acheteurs les saisissent dans l’ERP. Puis quelqu’un pose la question évidente. Pourquoi retaper ce que l’agent a déjà préparé ? Donnez-lui l’accès en écriture. Un lundi matin, l’ERP affiche deux commandes pour le même fournisseur, mêmes lignes, à deux minutes d’intervalle. L’une porte la confirmation du fournisseur en pièce jointe. L’autre est vide sous l’en-tête. Le connecteur avait expiré à la première tentative et avait réessayé ; l’ERP a accepté les deux moitiés de l’histoire. Le fournisseur a déjà commencé à préparer l’une des deux, et personne dans la salle ne sait dire laquelle. Le raisonnement de l’agent n’avait rien de faux. Ce qui a échoué, c’est l’écriture, et c’est à l’écriture que toutes les intégrations échouent depuis vingt ans. Lire un système d’enregistrement est un problème résolu et presque sans risque : une lecture peut être répétée, mise en cache, comparée et jetée. Une écriture modifie l’enregistrement que le reste de l’entreprise tient pour la vérité, et l’enregistrement n’a aucun moyen de savoir si le changement était voulu une fois ou deux. ## Pourquoi écrire en retour est un autre problème **Une lecture se répète, une écriture non.** Si une lecture échoue à mi-chemin, on relit. Si une écriture échoue à mi-chemin, on a un document qui existe en partie, et la tentative suivante soit duplique la partie arrivée, soit saute la partie manquante. Chaque travail de rapprochement en fin de mois existe à cause de cette asymétrie. **Une écriture partielle est pire que pas d’écriture.** Une commande avec un en-tête et sans lignes passe la validation de l’ERP. Elle bloque aussi le numéro chez le fournisseur, apparaît dans les engagements ouverts et sera reprise par le prochain rapport. La défaillance est invisible exactement là où elle compte. **Il n’y a pas d’annulation dans un système d’enregistrement.** Un logiciel comptable est conçu pour que rien ne soit supprimé. Une écriture erronée se corrige par une contre-passation, une facture erronée par un avoir. Chaque correction est un nouveau document avec son propre numéro et sa propre piste d’audit, si bien qu’une erreur commise à la vitesse d’une machine laisse des débris à la vitesse d’une machine, qu’une personne doit nettoyer à la main. **Un délai dépassé transforme une intention en deux actions.** Le connecteur ne sait pas si le système a reçu la requête et a tardé à répondre, ou s’il ne l’a jamais reçue. Sans moyen de dire « c’est la même requête que tout à l’heure », le choix sûr et le choix correct pointent dans des directions opposées. **L’écriture contourne le sens.** L’ERP vérifie que les champs sont remplis et que les codes existent. Il ne sait pas que ce client est sous blocage de crédit décidé en réunion, ni que ce fournisseur ne peut servir qu’une seule usine. Ces règles vivent dans les personnes, et une écriture directe passe tout droit à côté. **Personne ne sait dire qui l’a écrit.** L’utilisateur d’intégration qui a créé la commande est un compte technique partagé par tous les traitements qui passent par lui. La question « qui a décidé cela » n’a pas de réponse dans l’enregistrement, et c’est le sujet de [une identité pour les personnes et les agents](https://hurukan.com/fr/blog/une-identite-pour-les-personnes-et-les-agents). ## Ce qui doit exister avant qu’un agent écrive **Des propositions idempotentes.** Chaque changement voulu porte un identifiant unique, créé avant la première tentative. L’envoyer deux fois doit produire un seul résultat, et le côté récepteur doit pouvoir répondre « déjà fait » plutôt que recommencer. Si le système cible ne sait pas l’honorer, la couche placée devant lui doit le faire, en vérifiant avant d’envoyer et en consignant ce qu’elle a envoyé. **Une étape de validation dont une personne est responsable.** Pas une notification, une décision : la proposition, les éléments qui la fondent et le risque qu’elle porte, approuvés, modifiés ou rejetés par quelqu’un dont le nom entre dans l’enregistrement. Quelles écritures l’exigent n’est pas une affaire de goût ; c’est écrit action par action, et l’argent qui sort ou un engagement pris figurent toujours sur la liste. **Un journal rejouable.** Ce que l’agent a vu, ce qu’il en a conclu, ce qui a été proposé, qui l’a approuvé, ce qui a été envoyé, ce qui est revenu. Écrit de sorte que des mois plus tard une personne puisse suivre la chaîne, et structuré de sorte que la chaîne puisse être rejouée sur une copie du système quand il faut reconstituer quelque chose. **Une frontière que l’ontologie rend explicite.** Les actions qui existent sur chaque objet métier, les états que chaque objet peut prendre, les règles qu’un changement doit respecter et les actions qui comptent comme critiques. Un agent qui n’agit que dans ces termes ne peut rien écrire que le modèle n’autorise pas, et une personne qui lit le modèle voit exactement ce que l’agent a le droit de faire. **Un rapprochement après l’écriture.** Relire ce qui est arrivé et le comparer à ce qui a été envoyé. La plupart des doublons sont découverts par le fournisseur ou par l’auditeur ; ils devraient l’être par le système qui les a produits, en quelques minutes. ## Un test à faire dès aujourd’hui Prenez l’intégration la plus récente qui écrit dans votre ERP ou votre logiciel comptable. Il n’est pas nécessaire qu’un agent soit impliqué ; un connecteur de boutique en ligne ou un import de tableur suffit. Posez trois questions aux personnes qui l’ont construite et notez les réponses. Que se passe-t-il si le même message arrive deux fois ? Que se passe-t-il si le transfert échoue après la troisième ligne sur sept ? Où est consigné qui a approuvé le document écrit, et sur quels éléments ? Ensuite, si vous disposez d’un environnement de test, essayez les deux premiers cas et comptez les corrections nécessaires pour ramener l’enregistrement à la vérité. Si l’une des réponses est « le fournisseur nous le dirait » ou « on le verrait en fin de mois », l’intégration n’est pas prête pour un agent, quoi que l’agent sache lire. L’écart n’est pas dans le modèle ; il est dans le chemin d’écriture, et c’est le même écart pour une personne et pour un logiciel. Hurukan trace ici sa propre ligne. Les agents préparent, rédigent et proposent dans des limites écrites, et ils n’agissent que dans les termes que définit l’ontologie. Ce qui part vers le logiciel comptable, ou vers un système existant maintenu en parallèle, part après qu’une personne l’a approuvé, par un connecteur, avec la proposition, la décision et le résultat dans un seul journal. Les opérations critiques attendent une personne, quelle que soit la configuration. Pourquoi on ne peut pas confier à un système d’enregistrement le soin d’agir seul est développé dans [un système d’enregistrement ne sait pas agir](https://hurukan.com/fr/blog/le-systeme-d-enregistrement-ne-sait-pas-agir) ; le chemin d’écriture est là où [Hurukan](https://hurukan.com/fr) commence. - système d'enregistrement - ERP - agents - idempotence - validations ## À lire aussi - [Une identité pour les personnes et les agents : qui peut quoi](https://hurukan.com/fr/blog/une-identite-pour-les-personnes-et-les-agents) - [L'état courant et le registre : les deux mémoires d'un système d'exploitation d'entreprise](https://hurukan.com/fr/blog/l-etat-courant-et-le-registre-deux-memoires)