Commencer par une tâche étroite et une sortie vérifiable
Choisissez une seule tâche que vous pouvez juger sans débat interminable. Par exemple : lire un courriel de demande de service, repérer le sujet, proposer une priorité et rédiger un brouillon de réponse. Évitez un objectif comme améliorer le service à la clientèle, trop large pour être testé. Définissez plutôt quatre sorties attendues : une catégorie parmi une liste fermée, un niveau de priorité, les faits extraits du message et un brouillon qui ne promet rien sans autorisation. Écrivez aussi les limites avant l’essai. L’agent peut préparer une réponse, mais il ne doit pas l’envoyer. Il peut suggérer une date, mais il ne doit pas réserver une ressource. Il doit signaler les renseignements manquants au lieu de les inventer. Ces règles transforment une démonstration séduisante en expérience mesurable. Si vous ne pouvez pas dire ce qui constitue une réussite, une erreur et un cas à transmettre à une personne, l’automatisation est encore trop floue.
Construire douze cas qui ressemblent au vrai travail
Prenez quatre demandes ordinaires tirées de situations déjà résolues, puis retirez les noms et les renseignements personnels. Ajoutez quatre cas difficiles : une date ambiguë, deux demandes dans le même message, une pièce jointe manquante et une formulation très courte. Terminez avec quatre cas à risque : un paiement contesté, une menace, une demande contenant des données sensibles et une action qui exige l’approbation d’un gestionnaire. Vous obtenez ainsi un petit jeu de douze cas, assez varié pour révéler les faiblesses évidentes sans prétendre couvrir tout le monde réel. Pour chaque fiche, inscrivez la sortie acceptable et le comportement interdit. Un cas peut avoir plusieurs bonnes formulations, mais une seule règle de fond : ne jamais confirmer un remboursement avant vérification. Faites valider ces attentes par la personne qui exécute réellement la tâche. Le but n’est pas de fabriquer un examen que l’agent peut réussir facilement. Il faut représenter les décisions, les exceptions et les conséquences que l’équipe rencontre déjà.
Exécuter le test deux fois sans changer les règles
Utilisez le même modèle, les mêmes instructions, les mêmes outils et les mêmes documents pour les douze cas. Notez la version et la date. Lancez ensuite le jeu une deuxième fois, car une réponse correcte au premier passage peut varier au suivant. Ne corrigez pas les instructions au milieu de la série : vous perdriez la comparaison. Si un problème apparaît, inscrivez-le, terminez la ronde, puis préparez une nouvelle version pour un autre essai complet. Conservez cinq éléments pour chaque exécution : la réponse, l’action proposée, les sources consultées, le temps pris et l’intervention humaine requise. Si l’agent utilise des outils, vérifiez aussi ce qu’il a tenté de lire ou de modifier. Une belle réponse peut cacher une mauvaise sélection de dossier. Pour un agent qui agit, la trace des étapes compte autant que le texte final. Travaillez d’abord dans un environnement de démonstration avec des données fictives et des droits limités.
Compter les erreurs graves séparément des retouches
Créez quatre colonnes simples : réussi, retouche mineure, intervention nécessaire et erreur grave. Une retouche mineure corrige le ton ou raccourcit une phrase. Une intervention nécessaire ajoute un fait absent ou choisit entre deux options. Une erreur grave envoie au mauvais destinataire, divulgue une donnée, invente une politique, contourne une approbation ou exécute une action irréversible. Ne transformez pas ces catégories en une seule moyenne : onze réponses élégantes ne compensent pas une divulgation de renseignements personnels. Calculez ensuite trois mesures. Le taux de réussite est le nombre de cas utilisables sans modification divisé par douze. Le taux d’escalade indique combien de cas ont été correctement remis à une personne. Le temps humain restant additionne la vérification et les corrections. Exemple : si neuf cas réussissent, deux sont bien escaladés et un produit une erreur grave, le projet n’est pas prêt pour agir seul. Même sans erreur grave, économiser deux minutes tout en exigeant trois minutes de vérification n’est pas un gain.
Déployer par paliers et garder le jeu vivant
Commencez en mode observation : l’agent traite une copie du travail, mais son résultat ne touche aucun système. Passez ensuite au mode brouillon, où une personne approuve chaque sortie. L’étape suivante peut autoriser seulement les cas ordinaires qui respectent des conditions précises, avec un bouton d’arrêt, un journal et une limite de volume. Les cas à risque demeurent toujours soumis à une approbation explicite. Définissez avant le lancement le seuil qui ramène l’agent au mode brouillon, par exemple une erreur grave ou trois interventions imprévues dans une semaine. Après le pilote, ajoutez au jeu chaque nouveau type d’échec rencontré. Remplacez les cas devenus trop faciles et testez de nouveau après un changement de modèle, d’instructions, de document ou d’outil. Douze cas ne certifient pas un agent et ne remplacent pas un audit de sécurité. Ils créent une discipline de départ compréhensible par une petite équipe. En une heure, vous pouvez voir si l’agent sait réussir, demander de l’aide et s’arrêter. Ces trois comportements valent plus qu’une démonstration parfaite choisie à l’avance.
