Quand une personne doit-elle valider une action de l’IA ?

Nommez la décision que la personne prend.

Un bouton « Valider » ne dit pas à la personne ce qu’elle autorise. Accepte-t-elle une ébauche, confirme-t-elle une classification, autorise-t-elle un message externe ou approuve-t-elle la modification d’un enregistrement métier ? Ces décisions ont des conséquences différentes et peuvent relever de personnes différentes.

Commencez par séparer la préparation de l’exécution. Un workflow peut rassembler des documents, contrôler les champs obligatoires et ébaucher une recommandation avant que quiconque valide une action à conséquences. La validation doit se placer immédiatement avant l’action qu’elle contrôle, les autres contrôles exigés par le système destinataire restant en place.

Pour une offre, la décision peut être : valider cette version pour envoi à ce destinataire à ces conditions. Pour l’intelligence documentaire, ce peut être : accepter ce dossier de comparaison comme prêt pour la revue juridique. Accepter un dossier ne doit pas devenir tacitement la signature d’un contrat. Pour l’intelligence des processus, valider un guide confirme son contenu relu ; cela ne donne pas au lecteur un pouvoir d’engagement de dépenses ni un accès à un système ERP.

Donnez à la personne chargée de la revue un dossier de preuves.

Un écran de revue utile réduit l’effort de vérification sans masquer l’incertitude. Placez l’action proposée à côté des preuves qui la soutiennent. Montrez l’entrée d’origine, les références de sources pertinentes, les changements par rapport à la version précédente et les contrôles échoués.

Le dossier doit répondre à ces questions :

• Que se passera-t-il exactement si je valide ?
• Quel enregistrement, document, destinataire ou période de reporting est concerné ?
• Quelles versions des sources ont été utilisées, et sont-elles assez récentes pour cette décision ?
• Qu’a calculé le workflow, et qu’a déduit ou ébauché l’IA ?
• Quelles limites, quels cas particuliers ou quels conflits non résolus subsistent ?
• Que se passe-t-il si je refuse ou demande des modifications ?

Ne faites pas du score de confiance d’un modèle la seule preuve. Une réponse assurée peut quand même utiliser la mauvaise source ou se méprendre sur l’action prévue. Si la personne doit fouiller plusieurs systèmes pour reconstituer le fondement de chaque suggestion, l’interface de validation a déplacé le travail au lieu de le faciliter.

Dans la démo Document Intelligence, la comparaison identifie les clauses sources et les contrôles de règles avant la revue. C’est un exemple synthétique de dossier, pas un avis juridique ni l’affirmation qu’un contrat réel a été vérifié.

Liez la validation à la personne, à la version et à l’action.

Un enregistrement de validation a besoin d’assez de contexte pour ne pas être appliqué plus tard à une autre action. Dans une implémentation réelle, définissez le rôle autorisé, l’action proposée exacte, la version d’entrée ou de sortie et une éventuelle expiration. Utilisez la gestion des identités et des accès du client pour établir qui peut valider ; posséder un lien ne doit pas à lui seul conférer le droit de valider.

Si l’offre change après validation, l’ancienne décision ne couvre plus l’offre modifiée. Si un destinataire change, vérifiez à nouveau. Si les données sources sont actualisées, décidez si ce changement invalide la revue précédente. Ces règles doivent être explicites et non déduites par une étape d’IA.

L’exécution a aussi besoin de son propre contrôle. Un événement de validation et une action réussie sont deux enregistrements différents. Un délai réseau dépassé après l’envoi d’un message ne prouve pas que le message n’est pas parti. Utilisez un identifiant d’opération et le mécanisme de rapprochement ou d’idempotence pris en charge par le système destinataire pour éviter de répéter à l’aveugle une action à conséquences.

Décidez ce qui se passe quand personne ne valide.

Une demande sans réponse doit rester en attente ou expirer selon la règle convenue. Elle ne doit pas se transformer en validation à l’échéance d’un délai. Une action refusée doit avoir un motif et une prochaine étape claire : réviser, transmettre à un autre rôle responsable ou arrêter.

L’escalade demande autant de soin. Envoyer un rappel n’est pas transmettre le droit de valider. Si une personne suppléante est admise, définissez ce rôle à l’avance. Conservez le contexte d’origine quand un cas passe d’une personne à l’autre, pour que la nouvelle personne voie les mêmes points non résolus.

En cas de service de validation indisponible ou de réponse invalide, arrêtez l’action contrôlée et conservez assez d’état pour reprendre. Évitez de demander à quelqu’un de valider un ancien dossier alors que des entrées plus récentes sont déjà arrivées. Distinguez clairement l’attente d’une personne, la nouvelle tentative d’une étape technique et l’investigation d’un résultat d’exécution incertain.

Testez les tentatives de contourner la validation.

Le cas nominal n’est qu’un cas parmi d’autres. Les tests de réception doivent couvrir les situations où le workflow doit refuser de continuer :

1. Une personne refuse l’action ; l’exécution reste bloquée.
2. La validation expire avant l’exécution ; une nouvelle décision est requise.
3. L’entrée change après la revue ; la validation précédente ne peut pas être réutilisée.
4. Le même message de validation arrive deux fois ; l’action n’est pas dupliquée.
5. Une personne sans le rôle approprié tente de valider ; la tentative est rejetée.
6. Un système dépasse le délai après une tentative d’action ; la reprise vérifie le résultat avant de réessayer.
7. Le workflow est rejoué ; l’ancien état de validation n’est pas repris dans la nouvelle exécution.

Les démos locales testent la pause, la validation et la réinitialisation. Elles n’authentifient pas de vraies personnes habilitées et n’exercent pas le modèle d’autorisations d’un client. Cela exige des tests d’intégration avec les systèmes choisis et le fournisseur d’identité. Gardez cette distinction dans les preuves qui servent à décider du lancement.

Rendez la revue proportionnée et digne de l’attention de la personne.

Exiger une validation pour chaque étape de mise en forme anodine crée une file de clics. N’en exiger aucune pour les actions visibles de l’extérieur crée un autre problème. Regroupez le travail de préparation à faible conséquence, puis placez une étape de validation claire avant la décision qui compte.

Mesurez la durée de la revue, la fréquence des modifications de l’ébauche et le nombre de cas escaladés. Un taux de validation élevé ne prouve pas à lui seul que le processus fonctionne : les gens valident peut-être sans preuves suffisantes. Échantillonnez la qualité des décisions autant que le débit.

Dans les grandes entreprises, des responsabilités de revue distinctes peuvent être appropriées. Une personne experte du domaine confirme l’exactitude tandis qu’un responsable métier habilité autorise la diffusion. Dans les petites équipes, la même personne peut tenir les deux rôles, mais les deux décisions doivent rester compréhensibles.

L’objectif est une interface qui montre clairement qui peut valider quoi. Consultez les principes d’ingénierie, l’ exemple Process Intelligence ou utilisez le Workflow Fit Checker pour repérer où votre propre étape de validation reste floue.