Politique d'escalade
Des règles écrites pour décider quand un agent IA cesse d'essayer et remet le cas à un humain — pour que le transfert soit constant, expliqué et ajustable, plutôt qu'une humeur.
Pensez à une nouvelle recrue avec un livre de règles clair : réglez ces situations vous-même, et allez chercher le gérant pour celles-là — tout remboursement au-dessus de tel montant, tout client aussi fâché. Sans le livre de règles, elle dérange le gérant sans arrêt, ou elle force des choses qu'elle ne devrait pas. Une politique d'escalade, c'est ce livre de règles, pour un agent IA.
Le problème, en mots simples
Un agent sans règles de transfert claires échoue dans une de deux directions. Ou bien il escalade tout, et votre file de révision se noie — des humains passent la journée à revérifier du travail que l'agent aurait pu finir seul. Ou bien il escalade trop peu, et des réponses fragiles sortent en douce — vous l'apprenez par les clients. Pire : sans règles écrites, le moment du transfert varie d'un cas à l'autre, et personne dans l'équipe ne peut dire pourquoi ce billet-ci a atteint un humain et pas celui-là.
Ce que nous mettons en place
Une politique écrite par workflow, appliquée par le système qui fait rouler l'agent (le runtime) — pas laissée au jugement de l'agent sur le moment. Le livre de règles a quatre sortes de règles : un plancher de confiance (sous ce niveau de certitude, on arrête et on transfère), des classes de risque (certaines actions — argent, légal, changements de compte — exigent toujours un humain, peu importe la confiance de l'agent), un budget d'essais (tant de tentatives, puis on cesse d'essayer et on escalade), et la pression d'échéance (quand un délai de réponse promis, un SLA, est sur le point d'expirer, on transfère tôt plutôt que tard). Chaque escalade consigne quelle règle a déclenché. Et changer le livre de règles est une modification versionnée et révisée — jamais une retouche en douce.
Comment ça fonctionne, étape par étape
- Les règles sont écrites par workflow
Plancher de confiance, catégories à risque, budget d'essais, pression d'échéance — chaque workflow reçoit des seuils à la mesure de ses enjeux.
- Le système les applique
Le runtime applique la politique sur chaque cas. L'agent ne peut pas sauter le livre de règles un jour où il se sent en confiance.
- Confiant et sans risque : l'agent continue
Les cas routiniers, à l'intérieur des lignes, se terminent sans déranger personne.
- Incertain ou risqué : un humain reçoit le cas
Le transfert arrive avec le contexte attaché — ce qui a été tenté, ce que l'agent a trouvé — pas un simple appel à l'aide.
- Chaque transfert dit pourquoi
La trace consigne quelle règle a déclenché : confiance basse, classe de risque, essais épuisés ou échéance qui approche.
- Le livre de règles évolue par la preuve
Vous voyez quels workflows escaladent trop ou trop peu, et vous ajustez les seuils par une modification versionnée et révisée.
Ce qui change pour vous
Avant : le volume d'escalade était du bruit — une pile de transferts que personne ne pouvait interpréter, venant d'un agent parfois trop timide et parfois trop hardi. Après : chaque transfert porte sa raison, la pile se trie d'elle-même en motifs sur lesquels agir, et resserrer ou desserrer un seuil devient une petite modification révisée plutôt qu'un débat philosophique. Ce qu'il ne fera pas : la politique décide quand un cas atteint un humain, pas de la qualité de la réponse humaine. Les cas difficiles ont encore besoin du jugement de votre équipe — la politique s'assure juste qu'ils arrivent à temps, avec une explication attachée.