La commande a changé après votre accord. Que va envoyer l'agent ?

Prenons un fabricant d'emballages qui prépare une expédition. Les cartons sont imprimés et conditionnés ; le service expédition attend le feu vert.

Le client a validé le visuel hier. La qualité l'a contrôlé. La commande attend son autorisation d'expédition. Un assistant IA prépare l'instruction, puis le responsable des opérations donne son accord.

Le commercial reçoit alors un nouveau fichier graphique du client, avec la demande de l'utiliser pour cette commande. Les cartons sur les palettes portent toujours la version précédemment validée.

L'assistant joint le nouveau fichier à la commande. L'autorisation d'expédition reste au vert. Personne n'a encore établi si les cartons préparés peuvent partir en l'état ou doivent être repris.

Quelle version va quitter l'entrepôt ?

La question mérite d'être posée pendant la démonstration d'un agent. Une personne a bien donné son accord. Reste à vérifier que l'action prévue correspond toujours à ce qu'elle a accepté.

Regardez précisément ce que la validation couvre

« Autoriser l'expédition de la commande 4821 » paraît suffisamment clair. Jusqu'à ce que la commande change.

Le responsable a autorisé le départ sur la base du visuel disponible à ce moment-là. Cela ne dit pas si le client accepte les cartons déjà imprimés, si la production peut les reprendre, ni qui paie cette reprise. La qualité peut comparer les fichiers ; le responsable commercial doit encore clarifier la demande du client et les frais éventuels. Un statut vert ne répond pas à toutes ces questions.

Dans cet exemple, l'écran de validation doit identifier l'expédition demandée et les éléments qui comptent pour l'autoriser. Le numéro de commande ne suffit pas. Il faut retrouver la version du visuel, la destination et les autres conditions convenues avec les responsables du processus. Les documents justificatifs doivent être accessibles depuis cet écran.

Les informations à présenter dépendent de l'action. Une autorisation d'expédition et la préparation d'une note interne n'appellent pas le même contrôle.

Le guide OWASP sur l'autorisation des transactions décrit le principe « What You See Is What You Sign » : l'utilisateur doit pouvoir identifier et accepter les données significatives de la transaction. Ce guide traite de transactions numériques, notamment financières. Il fournit une question utile pour notre cas : la personne voit-elle ce que le système va réellement exécuter ?

Une synthèse rédigée par l'agent peut faciliter la lecture. Gardez aussi les faits et les documents à portée de main. Il faut que le responsable puisse remarquer que la synthèse désigne le nouveau visuel alors que les cartons préparés portent l'ancienne version.

Une nouvelle pièce jointe peut rendre l'accord caduc

Revenons à l'expédition. La version 3 du visuel a été validée. La version 4 est arrivée ensuite.

Conserver l'accord précédent doit reposer sur une règle explicite de l'entreprise. Une modification purement administrative entre peut-être dans une délégation existante. Une autre impose une nouvelle validation de la qualité ou du client. Le système doit respecter cette distinction. L'assistant ne peut pas simplement conclure que le changement semble mineur.

Avant de lui donner accès à l'expédition, définissez les modifications qui invalident chaque accord. Quand un élément significatif change, l'action en attente s'arrête. La différence est présentée à la bonne personne, qui se prononce sur la nouvelle version.

Cela ne doit pas renvoyer toute la commande au dirigeant. Si la qualité est responsable du visuel, cette décision revient à la qualité. Les délégations existantes restent utiles. La mise en œuvre doit permettre aux équipes de les exercer, sans les élargir ou les supprimer au passage.

Le temps compte également. Un accord peut reposer sur un stock, une situation de crédit ou un créneau de livraison qui a changé depuis. Décidez quels éléments doivent être revérifiés et combien de temps l'autorisation reste utilisable. Une durée unique pour toutes les opérations n'aurait guère de sens.

OWASP recommande d'invalider l'autorisation lorsque les données de la transaction changent et de contrôler cette autorisation juste avant l'exécution. Ce dernier contrôle est nécessaire : une commande peut évoluer pendant que l'instruction attend dans une file.

Demandez où l'action est effectivement bloquée

« Nous avons demandé à l'agent de solliciter un accord » ne répond qu'à une partie de la question.

Demandez à l'équipe technique ce qui empêche l'expédition lorsque la validation manque, a expiré ou porte sur une autre version. L'application qui réalise l'action doit faire respecter la règle. Une consigne dans un prompt ne suffit pas à garantir ce contrôle.

Dans notre exemple, le mécanisme d'expédition comparerait la version autorisée avec celle qu'on lui demande de libérer. En cas d'écart, l'action resterait bloquée, avec un motif exploitable. L'agent peut préparer l'explication et transmettre le dossier. Il ne doit pas pouvoir contourner le contrôle en utilisant un autre outil capable de modifier la même commande.

OWASP identifie les permissions et l'autonomie excessives parmi les risques des systèmes fondés sur des modèles de langage. Limitez les fonctions et les accès au travail convenu. Examinez les autres chemins possibles, pas seulement le bouton présenté pendant la démonstration.

C'est aussi le moment de regarder ce qui se passe dans l'entrepôt. Inscrire « expédition suspendue » dans un logiciel ne prouve pas que les palettes ont été retenues. Le responsable des départs doit recevoir une instruction fiable et pouvoir confirmer son exécution. Si le processus touche une opération physique, cette étape fait partie du travail.

Modifiez un élément pendant la démonstration

Utilisez un environnement de test ou une simulation sans possibilité d'expédier une vraie commande. Demandez au prestataire de préparer l'expédition, d'obtenir l'accord, puis de modifier une donnée significative avant l'exécution.

Commencez par la version du visuel. L'ancien accord ne doit plus permettre d'expédier le nouveau visuel. Regardez la trace dans le système qui exécute l'action. Une réponse rassurante dans le chat ne suffit pas.

Essayez ensuite de retirer l'accord pendant que l'action attend. L'exécution s'arrête-t-elle ? L'opérateur comprend-il pourquoi ?

Enfin, simulez une absence de réponse alors que la demande a peut-être atteint le système destinataire. Comment l'équipe vérifie-t-elle si l'expédition a été autorisée avant de recommencer ? Répéter une action parce que l'assistant n'a pas reçu de réponse peut créer un problème supplémentaire. La reprise doit permettre de retrouver l'état réel dans le système de destination.

Ces essais ne certifient pas l'ensemble du dispositif. Ils permettent de voir si les contrôles annoncés existent et si les personnes qui les exploitent comprennent les situations d'échec. Ajoutez des cas représentatifs de votre fonctionnement avant d'accepter la mise en production.

Conservez les preuves du test : les éléments approuvés, la modification, le refus du système et la résolution par l'opérateur. Vous aurez un cas à rejouer lorsque les règles ou le logiciel évolueront.

Apportez une commande qui a changé

Il n'est pas nécessaire de recenser toutes les exceptions de l'entreprise pour commencer. Choisissez une action récurrente pour laquelle une modification tardive a des conséquences. Rassemblez la demande initiale, sa révision et le circuit de validation, en retirant les informations sensibles.

Examinez qui peut approuver chaque décision et ce qui rendrait son accord caduc. Demandez ensuite à l'équipe qui construit l'agent de démontrer le respect de ces limites.

Si vous envisagez ce type de mise en œuvre, demandez une Strategy Session. Apportez la commande modifiée, en plus de celle qui passe sans difficulté dans la démonstration.

Pour poursuivre

Les règles que personne n'a écrites aborde le travail plus large de clarification des règles et des responsabilités. Ici, nous avons examiné comment maintenir le lien entre un accord et l'action précise qu'il autorise.