Agent vocal IA : gérer les demandes hors périmètre

Réponse directe : Un agent vocal IA fiable n’essaie pas de répondre à tout. Il reconnaît les sujets couverts, les questions incomplètes et les demandes qui nécessitent une personne. Gérer le hors périmètre signifie écrire une réponse courte, proposer une prochaine étape et conserver la frontière entre ce qui est connu et ce qui ne l’est pas.

Les guides publics sur la recherche augmentée montrent comment relier une question à des connaissances ; ils ne disent pas quoi faire quand aucun passage ne convient. Les évaluations d’agents de Microsoft fournissent un cadre pour tester la limite comme une capacité. Les repères publics utiles sont DGE — guide RAG et Microsoft Learn — évaluation des agents ; ils servent à vérifier le cadre, pas à inventer des résultats.

Une limite de réponse fiable commence par une base de connaissances dont la portée est connue. Quand aucune réponse ne convient, appliquez la règle de passage vers une personne.

Définir un périmètre opérationnel

Périmètre recommandé : un domaine précis avec ses sujets autorisés, partiels, interdits et sorties de repli.

Un refus utile est une issue de qualité lorsque la source ou l’autorisation manque. Pour la gestion des demandes hors périmètre, le premier livrable est une fiche qui relie intention, donnée nécessaire, action autorisée, sortie attendue et personne responsable. Cette fiche des limites de réponse et les refus utiles évite qu’un agent vocal soit évalué sur une promesse vague ou qu’un article mélange plusieurs sujets.

1. Tracer la frontière

L’objectif est de Tracer la frontière de façon observable pour la gestion des demandes hors périmètre. La question à résoudre est la suivante : Les sujets autorisés et limités ? Décrivez le point de départ, la décision autorisée, la limite à ne pas franchir et la sortie attendue pour « tracer la frontière ». Une autre personne doit pouvoir rejouer ce scénario de la gestion des demandes hors périmètre sans interpréter une consigne implicite propre à l’étape « tracer la frontière ».

Dans la pratique, écrivez exemples d’intention et sorties. Pour éprouver l’étape « tracer la frontière » de la gestion des demandes hors périmètre, préparez un cas nominal, une formulation ambiguë et une interruption. Ajoutez, pour « tracer la frontière », un exemple hors périmètre et vérifiez que l’agent demande une confirmation, refuse proprement ou passe la main quand la preuve manque. Pour « tracer la frontière », notez séparément ce qui a été dit, ce qui a été compris et l’action réellement exécutée dans ce scénario de la gestion des demandes hors périmètre.

La preuve recherchée est une limite par situation. La preuve attendue pour « tracer la frontière » est une limite par situation. Pour la gestion des demandes hors périmètre, reliez cette preuve de « tracer la frontière » à la version du scénario, à la donnée utilisée et à l’état final de l’outil. Une correction n’est acceptée qu’après avoir rejoué le cas initial et deux variantes voisines de « tracer la frontière » ; cette discipline évite de déplacer l’erreur vers une autre étape de la gestion des demandes hors périmètre.

2. Reconnaître doute

L’objectif est de Reconnaître doute de façon observable pour la gestion des demandes hors périmètre. La question à résoudre est la suivante : La clarification qui sépare les chemins ? Décrivez le point de départ, la décision autorisée, la limite à ne pas franchir et la sortie attendue pour « reconnaître doute ». Une autre personne doit pouvoir rejouer ce scénario de la gestion des demandes hors périmètre sans interpréter une consigne implicite propre à l’étape « reconnaître doute ».

Sur le terrain, proposez choix courts et compréhensibles. Pour éprouver l’étape « reconnaître doute » de la gestion des demandes hors périmètre, préparez un cas nominal, une formulation ambiguë et une interruption. Ajoutez, pour « reconnaître doute », un exemple hors périmètre et vérifiez que l’agent demande une confirmation, refuse proprement ou passe la main quand la preuve manque. Pour « reconnaître doute », notez séparément ce qui a été dit, ce qui a été compris et l’action réellement exécutée dans ce scénario de la gestion des demandes hors périmètre.

Le signal de réussite est une intention confirmée. La preuve attendue pour « reconnaître doute » est une intention confirmée. Pour la gestion des demandes hors périmètre, reliez cette preuve de « reconnaître doute » à la version du scénario, à la donnée utilisée et à l’état final de l’outil. Une correction n’est acceptée qu’après avoir rejoué le cas initial et deux variantes voisines de « reconnaître doute » ; cette discipline évite de déplacer l’erreur vers une autre étape de la gestion des demandes hors périmètre.

3. Répondre sans inventer

L’objectif est de Répondre sans inventer de façon observable pour la gestion des demandes hors périmètre. La question à résoudre est la suivante : La source ou la capacité réelle ? Décrivez le point de départ, la décision autorisée, la limite à ne pas franchir et la sortie attendue pour « répondre sans inventer ». Une autre personne doit pouvoir rejouer ce scénario de la gestion des demandes hors périmètre sans interpréter une consigne implicite propre à l’étape « répondre sans inventer ».

Pour le premier essai, dites ce qui est possible et l’alternative. Pour éprouver l’étape « répondre sans inventer » de la gestion des demandes hors périmètre, préparez un cas nominal, une formulation ambiguë et une interruption. Ajoutez, pour « répondre sans inventer », un exemple hors périmètre et vérifiez que l’agent demande une confirmation, refuse proprement ou passe la main quand la preuve manque. Pour « répondre sans inventer », notez séparément ce qui a été dit, ce qui a été compris et l’action réellement exécutée dans ce scénario de la gestion des demandes hors périmètre.

Considérez comme preuve un refus utile. La preuve attendue pour « répondre sans inventer » est un refus utile. Pour la gestion des demandes hors périmètre, reliez cette preuve de « répondre sans inventer » à la version du scénario, à la donnée utilisée et à l’état final de l’outil. Une correction n’est acceptée qu’après avoir rejoué le cas initial et deux variantes voisines de « répondre sans inventer » ; cette discipline évite de déplacer l’erreur vers une autre étape de la gestion des demandes hors périmètre.

4. Orienter

L’objectif est d’Orienter de façon observable pour la gestion des demandes hors périmètre. La question à résoudre est la suivante : La prochaine étape existante ? Décrivez le point de départ, la décision autorisée, la limite à ne pas franchir et la sortie attendue pour « orienter ». Une autre personne doit pouvoir rejouer ce scénario de la gestion des demandes hors périmètre sans interpréter une consigne implicite propre à l’étape « orienter ».

Au moment du pilote, proposez un humain, une page ou un canal valide. Pour éprouver l’étape « orienter » de la gestion des demandes hors périmètre, préparez un cas nominal, une formulation ambiguë et une interruption. Ajoutez, pour « orienter », un exemple hors périmètre et vérifiez que l’agent demande une confirmation, refuse proprement ou passe la main quand la preuve manque. Pour « orienter », notez séparément ce qui a été dit, ce qui a été compris et l’action réellement exécutée dans ce scénario de la gestion des demandes hors périmètre.

La vérification utile porte sur une orientation testée. La preuve attendue pour « orienter » est une orientation testée. Pour la gestion des demandes hors périmètre, reliez cette preuve de « orienter » à la version du scénario, à la donnée utilisée et à l’état final de l’outil. Une correction n’est acceptée qu’après avoir rejoué le cas initial et deux variantes voisines de « orienter » ; cette discipline évite de déplacer l’erreur vers une autre étape de la gestion des demandes hors périmètre.

5. Protéger action

L’objectif est de Protéger action de façon observable pour la gestion des demandes hors périmètre. La question à résoudre est la suivante : La frontière entre information et exécution ? Décrivez le point de départ, la décision autorisée, la limite à ne pas franchir et la sortie attendue pour « protéger action ». Une autre personne doit pouvoir rejouer ce scénario de la gestion des demandes hors périmètre sans interpréter une consigne implicite propre à l’étape « protéger action ».

Dans la séquence de test, refusez l’effet non autorisé. Pour éprouver l’étape « protéger action » de la gestion des demandes hors périmètre, préparez un cas nominal, une formulation ambiguë et une interruption. Ajoutez, pour « protéger action », un exemple hors périmètre et vérifiez que l’agent demande une confirmation, refuse proprement ou passe la main quand la preuve manque. Pour « protéger action », notez séparément ce qui a été dit, ce qui a été compris et l’action réellement exécutée dans ce scénario de la gestion des demandes hors périmètre.

Le résultat doit se voir dans aucun état métier indu. La preuve attendue pour « protéger action » est aucun état métier indu. Pour la gestion des demandes hors périmètre, reliez cette preuve de « protéger action » à la version du scénario, à la donnée utilisée et à l’état final de l’outil. Une correction n’est acceptée qu’après avoir rejoué le cas initial et deux variantes voisines de « protéger action » ; cette discipline évite de déplacer l’erreur vers une autre étape de la gestion des demandes hors périmètre.

6. Mesurer lacunes

L’objectif est de Mesurer lacunes de façon observable pour la gestion des demandes hors périmètre. La question à résoudre est la suivante : Les catégories hors base ? Décrivez le point de départ, la décision autorisée, la limite à ne pas franchir et la sortie attendue pour « mesurer lacunes ». Une autre personne doit pouvoir rejouer ce scénario de la gestion des demandes hors périmètre sans interpréter une consigne implicite propre à l’étape « mesurer lacunes ».

Lors de la revue, classez couverture, orientation, transfert et refus. Pour éprouver l’étape « mesurer lacunes » de la gestion des demandes hors périmètre, préparez un cas nominal, une formulation ambiguë et une interruption. Ajoutez, pour « mesurer lacunes », un exemple hors périmètre et vérifiez que l’agent demande une confirmation, refuse proprement ou passe la main quand la preuve manque. Pour « mesurer lacunes », notez séparément ce qui a été dit, ce qui a été compris et l’action réellement exécutée dans ce scénario de la gestion des demandes hors périmètre.

L’équipe peut confirmer ce point par une décision de couverture. La preuve attendue pour « mesurer lacunes » est une décision de couverture. Pour la gestion des demandes hors périmètre, reliez cette preuve de « mesurer lacunes » à la version du scénario, à la donnée utilisée et à l’état final de l’outil. Une correction n’est acceptée qu’après avoir rejoué le cas initial et deux variantes voisines de « mesurer lacunes » ; cette discipline évite de déplacer l’erreur vers une autre étape de la gestion des demandes hors périmètre.

7. Étendre

L’objectif est de Étendre de façon observable pour la gestion des demandes hors périmètre. La question à résoudre est la suivante : Comment étendre sans élargir le périmètre ? Décrivez le point de départ, la décision autorisée, la limite à ne pas franchir et la sortie attendue pour « étendre ». Une autre personne doit pouvoir rejouer ce scénario de la gestion des demandes hors périmètre sans interpréter une consigne implicite propre à l’étape « étendre ».

Pour la version contrôlée, ajoutez source, propriétaire et tests voisins. Pour éprouver l’étape « étendre » de la gestion des demandes hors périmètre, préparez un cas nominal, une formulation ambiguë et une interruption. Ajoutez, pour « étendre », un exemple hors périmètre et vérifiez que l’agent demande une confirmation, refuse proprement ou passe la main quand la preuve manque. Pour « étendre », notez séparément ce qui a été dit, ce qui a été compris et l’action réellement exécutée dans ce scénario de la gestion des demandes hors périmètre.

Le contrôle final consiste à observer un retour arrière possible. La preuve attendue pour « étendre » est une décision vérifiable et une trace exploitable. Pour la gestion des demandes hors périmètre, reliez cette preuve de « étendre » à la version du scénario, à la donnée utilisée et à l’état final de l’outil. Une correction n’est acceptée qu’après avoir rejoué le cas initial et deux variantes voisines de « étendre » ; cette discipline évite de déplacer l’erreur vers une autre étape de la gestion des demandes hors périmètre.

8. Revoir limites

L’objectif est de Revoir limites de façon observable pour la gestion des demandes hors périmètre. La question à résoudre est la suivante : Comment revoir limites sans élargir le périmètre ? Décrivez le point de départ, la décision autorisée, la limite à ne pas franchir et la sortie attendue pour « revoir limites ». Une autre personne doit pouvoir rejouer ce scénario de la gestion des demandes hors périmètre sans interpréter une consigne implicite propre à l’étape « revoir limites ».

Dans un cas représentatif, relisez exemples indirects et exceptions. Pour éprouver l’étape « revoir limites » de la gestion des demandes hors périmètre, préparez un cas nominal, une formulation ambiguë et une interruption. Ajoutez, pour « revoir limites », un exemple hors périmètre et vérifiez que l’agent demande une confirmation, refuse proprement ou passe la main quand la preuve manque. Pour « revoir limites », notez séparément ce qui a été dit, ce qui a été compris et l’action réellement exécutée dans ce scénario de la gestion des demandes hors périmètre.

La décision s’appuie sur une règle expliquée. La preuve attendue pour « revoir limites » est une décision vérifiable et une trace exploitable. Pour la gestion des demandes hors périmètre, reliez cette preuve de « revoir limites » à la version du scénario, à la donnée utilisée et à l’état final de l’outil. Une correction n’est acceptée qu’après avoir rejoué le cas initial et deux variantes voisines de « revoir limites » ; cette discipline évite de déplacer l’erreur vers une autre étape de la gestion des demandes hors périmètre.

Cas de terrain à faire relire

Une question est simplement ambiguë

L’agent doit demander ce qui sépare les deux parcours plutôt que choisir au hasard.

Proposez deux options courtes et vérifiez la formulation orale.

Un document ressemble à la question

Un passage proche ne suffit pas à répondre à la demande exacte.

Testez un cas où la source voisine est volontairement insuffisante.

L’appelant insiste

La limite doit rester stable et offrir une alternative réelle.

Essayez une demande directe, indirecte et pressante.

Un lien est proposé

Une orientation doit exister et être testée dans le checkout.

Vérifiez le chemin depuis le mobile et le retour possible vers un humain.

Une action est incluse dans la demande

Information et exécution doivent être séparées par les droits et le dialogue.

Contrôlez qu’un refus ne déclenche aucun état métier.

Une nouvelle couverture est demandée

L’ajout doit avoir source, propriétaire, tests et retour arrière.

Rejouez les scénarios voisins avant activation.

Les erreurs qui donnent une fausse impression de qualité

Répondre pour être agréable

Une phrase plausible mais non fondée est difficile à corriger.

Utiliser une liste de mots

Le hors périmètre se formule par de nombreuses intentions.

Proposer un lien mort

Une alternative non disponible abîme la confiance.

Étendre une source proche

La proximité lexicale ne garantit pas la réponse.

Couvrir sans test

Chaque extension doit comporter des variantes.

Punir tous les refus

Une limite correcte protège le parcours.

Revue après le pilote

Classez les demandes hors périmètre par cause et issue. Décidez ensuite couvrir, orienter, transférer ou maintenir la limite.

Pour relire les limites de réponse et les refus utiles, regroupez les appels par issue plutôt que par durée. Pour les limites de réponse et les refus utiles, séparez compréhension, règle appliquée, action éventuelle, trace créée et sortie proposée. Une reprise ou une réponse peut être correcte seulement si elle respecte un domaine précis avec ses sujets autorisés, partiels, interdits et sorties de repli et si la donnée reste vérifiable. Utilisez un échantillon contrôlé propre à ce guide sur les demandes hors périmètre, avec des identifiants de scénario et des données fictives lorsque le détail n’est pas nécessaire.

La correction doit rester liée à l’objectif suivant : Concevoir des refus et clarifications qui protègent la confiance. pour les limites de réponse et les refus utiles, il peut s’agir d’une source à mettre à jour, d’une question à raccourcir, d’une confirmation à ajouter, d’un droit à retirer, d’une limite à expliciter ou d’une reprise à déclencher plus tôt. Après modification, rejouez le cas initial des limites de réponse et les refus utiles et deux variantes voisines. Cette boucle rend la version ce guide sur les demandes hors périmètre explicable sans transformer l’incident en règle isolée.

Checklist finale

1. Une intention principale et une sortie métier sont écrites pour les limites de réponse et les refus utiles.
2. Les limites et la reprise humaine sont compréhensibles dans ce guide sur les demandes hors périmètre.
3. Les données demandées ont une finalité et un accès définis pour ce guide sur les demandes hors périmètre.
4. Les cas nominaux, ambigus, interrompus et hors périmètre sont testés pour les limites de réponse et les refus utiles.
5. Les sources ou outils ont un propriétaire et une version.
6. Les échecs sont relus avec une méthode et une décision de correction.

Fiche de décision à remettre à l’équipe

Pour mettre cette méthode en œuvre sur les limites de réponse et les refus utiles, réunissez les personnes concernées et demandez-leur de décrire un appel réel, une exception et une sortie acceptable. La fiche consacrée aux limites de réponse et les refus utiles doit permettre à quelqu’un d’autre de rejouer ce parcours avec des données fictives et de reconnaître le résultat attendu. Écrivez les mots de l’appelant, la question posée, la donnée utilisée, l’action éventuelle et la phrase de fin pour ce guide sur les demandes hors périmètre.

Ajoutez ensuite les conditions de confiance propres à ce guide sur les demandes hors périmètre. Qu’est-ce qui est suffisamment certain pour répondre ? Qu’est-ce qui doit être confirmé ? Quel événement provoque une reprise ? Quel rôle valide la source ou l’action ? Ces questions rendent visible la frontière entre assistance et décision pour les limites de réponse et les refus utiles. Elles évitent aussi de corriger le système à partir d’un seul exemple dans ce guide sur les demandes hors périmètre, sans regarder les cas voisins.

Enfin, choisissez un rituel de contrôle compatible avec Concevoir des refus et clarifications qui protègent la confiance. Une personne relit les traces minimisées pour les limites de réponse et les refus utiles, une autre vérifie l’état métier et le responsable du parcours décide de la correction. Pour ce guide, n’acceptez la prochaine version que si le scénario initial et ses variantes restent cohérents. Si la preuve manque, réduisez le périmètre, expliquez la limite ou transférez. Dans le guide ce guide sur les demandes hors périmètre, cette prudence protège la qualité du parcours sans retarder une décision utile.

Gardez enfin une question simple pour chaque étape des limites de réponse et les refus utiles. Elle sert de repère lors d’une reprise, d’une nouvelle version ou d’un contrôle qualité propre à ce guide sur les demandes hors périmètre. Si l’équipe de ce guide sur les demandes hors périmètre ne peut pas répondre avec les sources et journaux disponibles, le parcours reste trop large. Pour ce guide, réduire une promesse, demander une confirmation ou passer la main constitue une décision opérationnelle claire. Cette règle protège l’appelant et facilite la maintenance.