Changer un agent sans perdre le fil

Prenons un agent fictif qui prépare une réponse sur le délai de livraison. L’équipe commerciale veut qu’il tienne désormais compte du stock de deux entrepôts. Ce changement paraît petit. Il ajoute pourtant une source, une règle de choix et un cas nouveau : les deux entrepôts n’annoncent pas la même date. Commencez par décrire ces différences avant de toucher aux consignes de l’agent.

La demande de changement peut tenir sur une fiche : comportement actuel, comportement souhaité, données supplémentaires, personnes concernées et résultat attendu sur un exemple. Distinguez une correction d’erreur d’une nouvelle possibilité. Dans notre scénario, « ne plus utiliser un stock périmé » corrige le service ; « proposer un autre entrepôt » élargit ce qu’il fait. Les mêmes personnes peuvent intervenir, mais elles n’ont pas la même décision à prendre.

Nexus présente ses modèles comme interchangeables. Navinspire décrit des registres communs pour les modèles, les agents et les outils.^1,2

Ces fonctions rendent le changement envisageable ; elles ne disent pas quels agents seront affectés chez vous. Demandez la liste des usages qui partagent le modèle, la connexion ou la consigne modifiée. Une décision prise pour l’agent de livraison peut toucher un autre service qui utilise la même brique. Faites nommer les personnes qui devront relire ces résultats.^1,2

Avant la modification, choisissez des exemples que le service traite déjà correctement et conservez leurs résultats. Ajoutez les nouveaux cas qui motivent le changement. Pour notre agent, prévoyez un article disponible dans un seul entrepôt, un article absent des deux et deux dates contradictoires. Faites écrire au responsable métier ce qui serait une réponse acceptable, y compris le cas où l’agent doit demander de l’aide.

WiserBrand décrit des jeux de données et des scénarios d’évaluation, ainsi que des contrôles de mise en production et de retour arrière.^3,4

Demandez que l’équipe applique ces vérifications au changement précis, avec les mêmes données avant et après. Une comparaison utile montre les réponses qui s’améliorent, celles qui restent stables et celles qui se dégradent. Regardez aussi les actions effectuées dans les logiciels. Une réponse bien rédigée n’excuse pas une mauvaise date enregistrée dans la commande.^3,4

Fixez les raisons de refuser la nouvelle version avant de regarder les résultats. Une date inventée, un accès à un dossier interdit ou une modification non autorisée peuvent suffire à bloquer la reprise, même si les autres exemples passent. Ces exercices sont une préparation proposée à votre équipe ; ils ne constituent pas des résultats que Relevé Opéra aurait obtenus sur les produits comparés.

Conservez l’ancienne version et écrivez comment arrêter les nouvelles demandes. Demandez ce qui arrive aux tâches déjà en cours : se terminent-elles avec l’ancienne version, s’interrompent-elles ou attendent-elles une décision ? La réponse dépend du service. Elle doit être connue de la personne qui lance le changement, pas découverte lors du premier incident.

Navinspire indique accompagner chaque version de paquets et d’un manifeste. WiserBrand mentionne explicitement des contrôles de retour arrière dans son offre d’agents.^5,4

Ces éléments doivent déboucher sur une procédure que quelqu’un peut suivre. Revenir à l’ancienne version ne répare pas automatiquement les commandes déjà modifiées. Dans notre exemple, gardez la liste des dossiers traités depuis la bascule, puis attribuez leur examen à une personne. Elle doit pouvoir distinguer une simple réponse à refaire d’une date déjà communiquée au client.^5,4

Évitez de confondre urgence et absence de décision. Si une correction ne peut pas attendre la prochaine réunion, prévoyez qui peut l’autoriser, quelles vérifications restent indispensables et qui relit ensuite le résultat. Une procédure courte, connue à l’avance, aide davantage qu’une longue liste que personne ne consulte pendant l’incident.

Nexus annonce un indicateur métier associé à chaque agent. Navinspire décrit le suivi du coût des appels aux modèles. Ces mesures portent sur des sujets différents.^6,7

Après la reprise, regardez les réponses refusées, les demandes d’aide, les dossiers encore ouverts et la dépense. Comparez des périodes et des tâches semblables autant que possible. Un coût plus faible peut simplement signifier que moins de demandes ont été traitées. Une baisse des demandes d’aide peut être bonne ou révéler que l’agent continue quand il devrait s’arrêter. Relisez des exemples pour comprendre le chiffre.^6,7

Préparez une note de changement lisible par les utilisateurs : ce qui change, à partir de quand, ce qu’ils doivent vérifier et où signaler un problème. Dans notre scénario, elle préciserait que l’agent consulte désormais deux entrepôts et que les dates contradictoires demandent une vérification humaine. Cette note décrit un résultat observable, sans raconter tous les réglages internes.

Clôturez le changement lorsque la personne responsable a lu les résultats convenus et décidé de conserver la version, de la corriger ou de revenir en arrière. Rangez cette décision avec la fiche de départ et actualisez le dossier de reprise. L’équipe qui interviendra ensuite doit pouvoir retrouver pourquoi le changement a été fait, ce qui a été vérifié et les points encore surveillés.