Qui fait quoi une fois l'agent en place : redessiner les responsabilités d'un processus augmenté

Six mois après la mise en production d'un agent de traitement des demandes clients, un directeur des opérations nous posait une question simple : « Quand l'agent se trompe, qui rappelle le client ? » Personne n'avait la réponse. Pas parce que le sujet avait été mal traité, mais parce qu'il n'avait jamais été traité du tout. L'architecture technique était documentée sur quarante pages. La répartition des responsabilités tenait dans une phrase du compte rendu de cadrage : « l'équipe support reste dans la boucle ».

C'est le point aveugle le plus fréquent des projets d'automatisation en ETI. On investit dans la fiabilité du système et on laisse informelle la partie humaine. Résultat : au premier incident, chacun regarde son voisin.

Un agent ne supprime pas les responsabilités, il les déplace

Avant automatisation, une décision opérationnelle est portée par une personne identifiable. Elle instruit le dossier, elle tranche, elle assume. La chaîne est courte et lisible, même quand elle n'est écrite nulle part : tout le monde sait que c'est Sophie au crédit client qui débloque les commandes au-dessus de 15 000 €.

Quand un agent prend en charge l'instruction et propose — voire exécute — une décision, cette chaîne ne disparaît pas. Elle se fragmente. Il y a désormais :

• celui qui définit la règle que l'agent applique ;
• celui qui valide les cas que l'agent remonte ;
• celui qui arbitre les exceptions que l'agent ne sait pas classer ;
• celui qui répond au client ou au fournisseur si la décision est contestée ;
• celui qui constate une dérive et décide de suspendre l'agent.

Ces cinq rôles étaient autrefois concentrés sur une ou deux personnes. Ils sont maintenant répartis, et rien ne garantit qu'ils soient attribués. Une zone grise entre l'agent et les équipes ne se révèle jamais en phase de test : elle se révèle le jour où un client conteste, où un montant passe mal, où un dossier sort du cadre prévu.

Les quatre questions qui doivent avoir une réponse nommée

Nous formalisons dans chaque mission un document de répartition des responsabilités, au même niveau d'exigence que le schéma d'architecture. Il répond à quatre questions, et les réponses sont des noms de fonctions, pas des équipes.

Qui valide ? Sur quels critères l'agent agit-il seul, et à partir de quel seuil une validation humaine est-elle requise ? Le seuil doit être chiffré et explicite. « Les cas complexes » n'est pas un critère. « Toute remise supérieure à 8 % ou tout client dont l'encours dépasse 30 jours » en est un.

Qui arbitre une exception ? L'agent rencontrera des situations non prévues. La question n'est pas de les éviter mais de savoir où elles atterrissent, dans quel délai elles doivent être traitées, et ce qui se passe si le délai est dépassé. Une file d'exceptions sans propriétaire se transforme en dette opérationnelle silencieuse.

Qui répond si la décision est contestée ? C'est la question la plus négligée et la plus exposée. Un client à qui l'on refuse un geste commercial ne veut pas savoir qu'un agent a décidé. Il veut un interlocuteur qui assume la décision, sait pourquoi elle a été prise et peut la réexaminer. Cela suppose que cet interlocuteur ait accès à la trace de décision — d'où la nécessité que le processus soit requêtable et pas seulement automatisé.

Qui peut arrêter l'agent ? Une automatisation qui ne peut être suspendue que par le prestataire est une automatisation que l'entreprise ne contrôle pas. Le pouvoir d'arrêt doit être interne, documenté, testé au moins une fois.

L'exemple d'un processus de recouvrement

Une ETI industrielle de 320 personnes a déployé un agent de relance client : détection des échéances dépassées, qualification du retard, envoi de relances graduées, escalade vers le commercial concerné.

La répartition formalisée tenait sur une page. Le DAF définit les seuils de relance et les valide trimestriellement. Le comptable clients valide toute mise en demeure et tout dossier supérieur à 25 000 €. Le commercial de la zone arbitre les cas où le retard est lié à un litige technique — l'agent les identifie par la présence d'un avoir en cours et les lui route directement. Le responsable ADV est l'interlocuteur en cas de contestation et dispose d'un accès à l'historique complet des actions de l'agent sur le compte. Le DAF et le DSI peuvent tous deux suspendre le système.

Neuf mois plus tard, le comptable clients est parti en retraite. Son remplaçant a repris les mêmes prérogatives en trois jours, parce qu'elles étaient écrites. C'est précisément le test qui compte : une automatisation ne tient pas parce qu'elle fonctionne, elle tient parce qu'elle survit au changement de titulaire.

Pourquoi cela relève du livrable, pas de la conduite du changement

On objecte souvent que ce sujet relève du management interne et non du prestataire technique. C'est une erreur d'aiguillage. La répartition des responsabilités détermine directement des choix de conception : les points de validation à instrumenter, les données à exposer dans l'interface d'arbitrage, la granularité des traces, les notifications à router. Décider a posteriori qui valide quoi oblige à reprendre le système.

Nous traitons donc cette matrice comme un livrable de mission : rédigée en atelier avec les opérationnels concernés, validée par la direction, versionnée, et révisée à chaque évolution du périmètre de l'agent. Sans cela, on n'automatise pas un processus : on empile une couche technique sur une ambiguïté organisationnelle. Et on ne peut pas automatiser le chaos.