Laisser un agent IA écrire dans votre ERP : les cinq garde-fous à exiger

Pourquoi un agent change la question

Un assistant conversationnel produit du texte que quelqu’un relit avant d’en faire quoi que ce soit. Un agent, lui, enchaîne les étapes seul : il lit une facture, retrouve le fournisseur dans l’ERP, puis propose l’écriture comptable. Le gain de temps vient précisément de là. Le risque aussi : entre la lecture et l’écriture, plus personne ne regarde, sauf si l’on a prévu le contraire.

Le droit suisse le prévoit déjà en partie. La nLPD impose d’informer la personne concernée d’une décision prise exclusivement de manière automatisée lorsqu’elle a des effets juridiques pour elle ou l’affecte de manière significative, et de lui permettre de demander qu’une personne physique la réexamine (art. 21). Côté européen, le règlement sur l’IA exige une surveillance humaine effective des systèmes à haut risque (art. 14), une obligation repoussée au 2 décembre 2027 pour la plupart d’entre eux. Un agent qui saisit des factures fournisseurs n’entre généralement pas dans ces catégories. Mais le principe est le même, et il est simplement de bon sens : quelqu’un doit pouvoir comprendre, corriger et arrêter.

Les cinq garde-fous

Ce sont les contrôles que nous exigerions de n’importe quel fournisseur, nous compris, avant de laisser un agent toucher à un logiciel métier.

1. Aucune écriture sans décision. L’agent propose, il n’écrit pas. Ses écritures attendent dans une file où une personne valide, refuse avec un motif ou corrige avant de valider. Pour les cas répétitifs, une règle écrite à l’avance peut valider à sa place, mais dans des limites précises : un agent, un outil, un montant maximal par écriture, un plafond par jour. Le meilleur indice qu’un dispositif est sérieux : ce n’est pas l’agent qui écrit dans l’ERP, mais une passerelle, et seulement après la décision.
2. Un registre par agent. Avant d’activer un agent, on doit pouvoir dire pourquoi il traite des données : finalité, base légale, personnes concernées, durée de conservation. Ce sont des rubriques du registre des activités de traitement prévu par la nLPD (art. 12). Un agent sans fiche ne devrait pas pouvoir démarrer.
3. Un journal qui prouve sans copier. Chaque exécution doit laisser une trace : quel agent, quelles étapes, quelles catégories de données, quelle destination (modèle interne, logiciel métier, service externe), combien de temps, quel coût. Mais si le journal conserve aussi le texte des factures et les réponses du modèle, il devient une deuxième copie de vos données sensibles, à protéger à son tour. Le bon compromis : enregistrer le type, la taille et une empreinte du contenu, pas le contenu.
4. Un plafond qui agit. Un rapport de consommation en fin de mois ne protège de rien. Uber a reconnu en 2026 avoir consommé en quatre mois tout son budget annuel d’outils de code IA. Le plafond doit être vérifié avant chaque exécution : plus de budget, pas d’exécution, l’agent est mis en pause et une alerte part. Un modèle externe dont le prix n’est pas déclaré ne doit jamais être compté comme gratuit.
5. Un arrêt qui fonctionne. Mettre un agent en pause, l’arrêter en urgence en gelant ses écritures en attente, couper tous les agents d’un coup : ces gestes doivent être disponibles en un clic, journalisés, et réservés à des personnes identifiées. Un arrêt qu’il faut demander par ticket au fournisseur n’en est pas un.

Le monitoring, ou comment voir une panne silencieuse

Une panne d’agent est rarement franche. Le plus souvent, l’agent continue de tourner en produisant des erreurs, ou il cesse simplement de donner des nouvelles. Nous avons décrit ce scénario ici : la panne est découverte trois jours plus tard, par une collaboratrice qui s’étonne qu’une demande n’ait pas été traitée.

Trois réflexes de monitoring changent la donne. D’abord, compter comme un échec un run resté sans nouvelles, et pas seulement ceux qui renvoient une erreur. Ensuite, une alerte par problème, quel que soit le nombre de répétitions : cinquante notifications pour la même panne finissent ignorées. Enfin, suivre chaque agent dans la durée (taux d’échec sur 24 heures et sur 7 jours, durée médiane des exécutions) pour qu’une dérive se voie avant de devenir un incident.

Cinq questions à poser à votre fournisseur

1. Qui écrit dans mon ERP : l’agent lui-même, ou une passerelle après décision ?
2. Que contient votre journal : la trace de ce qui s’est passé, ou une copie de mes documents ?
3. Que se passe-t-il quand le budget est atteint : une alerte, ou un arrêt ?
4. Puis-je tout arrêter moi-même, et qui peut relancer ?
5. Où tourne la console de supervision : chez vous, ou chez moi ?

Si les réponses sont vagues, le projet risque de rejoindre les 40 % que Gartner voit abandonnés, non parce que l’IA ne fonctionne pas, mais parce que personne ne peut garantir ce qu’elle fait.

Ce que nous en avons fait

Ces cinq garde-fous sont ceux que nous avons intégrés à AgentHub Connect, la console qui encadre nos agents sur l’infrastructure du client : validation des écritures, registre par agent, journal sans conservation du contenu, plafonds en francs et arrêt d’urgence. La page Gouvernance et monitoring détaille chaque écran.