Automatiser avec validation humaine, sans perdre la main

Préparer ou agir

Préparer, c’est produire quelque chose qu’une personne peut encore relire : classer un courriel, extraire les montants d’une facture, rédiger un brouillon. Agir, c’est changer quelque chose hors du flux : envoyer, modifier une fiche, payer, supprimer. Une automatisation qui ne fait que préparer peut déjà faire gagner du temps, sans rien exposer.

• Préparer : lire une facture et extraire fournisseur, numéro et total.
• Préparer : comparer la facture au bon de commande et signaler les écarts.
• Agir : envoyer un courriel au fournisseur.
• Agir : changer le statut de la facture dans le logiciel comptable.
• Agir : déclencher un paiement.

L’OWASP, référence reconnue en sécurité applicative, décrit un risque appelé « agence excessive » : un système qui dispose de trop de fonctions, de trop de permissions ou de trop d’autonomie. Parmi ses recommandations : limiter fonctions et permissions au strict nécessaire, et faire approuver par une personne les actions à fort impact avant leur exécution. Ces conseils visent les applications d’IA, mais la même logique nous semble valoir pour une automatisation par règles.

Classer chaque action

Deux questions suffisent pour placer une action. Quel est l’impact si elle se trompe ? Peut-on l’annuler facilement ? Le tableau propose un contrôle de départ, à ajuster selon votre activité.

Ce que l’approbation doit montrer

Un bouton « Approuver » sous un résumé ne permet pas de décider. La personne doit voir, au même endroit, ce qui a déclenché la demande, ce que le système propose, ce dont il n’est pas sûr et ce qui se passera exactement après son accord. Si elle doit ouvrir trois logiciels pour comprendre, le risque est qu’elle approuve sans regarder.

• La source : le document ou le message d’origine, ou un lien direct.
• La proposition : le texte complet, le montant ou la valeur exacte.
• Les incertitudes : écarts, champs manquants, éléments « à confirmer ».
• Le destinataire ou le dossier touché.
• L’effet exact : « En approuvant, ce courriel part à cette adresse. »
• Les choix : approuver cette version, corriger, refuser, demander un complément.

Certains outils intègrent ce principe. Dans n8n, un outil utilisé par un agent IA peut exiger une revue humaine : le flux s’interrompt, la personne voit quel outil l’IA veut utiliser et avec quels paramètres, puis approuve ou refuse. En cas de refus, l’action est annulée et l’IA en est informée. Vérifiez quand même que ce que voit la personne suffit pour décider : des paramètres techniques ne remplacent pas un résumé lisible.

Silence, changement, exception

Sans réponse, l’action reste en attente : pas d’approbation implicite après un délai. Attention aux réglages. Dans n8n, l’option « Limit Wait Time » d’une étape d’envoi avec attente de réponse fait reprendre le flux automatiquement après un délai. Si vous l’activez, vérifiez en test ce qui se passe à l’expiration et faites en sorte que ce chemin marque la demande « expirée » au lieu d’exécuter l’action.

Si le contenu change après l’accord, l’accord ne vaut plus. Un montant corrigé, un destinataire ajouté ou un texte réécrit exigent une nouvelle approbation. Une façon simple de l’appliquer : l’approbation porte sur une version numérotée, et l’exécution vérifie que c’est bien cette version qui part.

Une exception doit arriver chez une personne nommée, avec la raison en clair, plutôt que de disparaître dans un flux qui échoue en silence. Prévoyez aussi un remplaçant pour les absences. Dans n8n, par exemple, un flux d’erreur peut s’exécuter quand une exécution échoue et envoyer une alerte par courriel ou dans Slack.

Journaliser et tester

Le journal doit être proportionné au risque. Pour un brouillon, la date et le résultat suffisent. Pour un message client, un changement de fiche ou un paiement, gardez qui a approuvé, quand, quelle version et ce que le service connecté a répondu. L’OWASP recommande aussi de surveiller l’activité et de limiter le nombre d’actions possibles dans un délai donné, pour réduire les dégâts en cas de dérapage.

Avant la mise en service, testez ce qui dérange, pas seulement le cas qui marche, avec des données fictives ou autorisées. Dans n8n, le nœud « Stop And Error » permet de forcer un échec pour vérifier que votre flux d’erreur réagit.

1. Refus : l’action est annulée et rien ne part.
2. Expiration : la demande passe à « expirée » et le responsable est prévenu.
3. Doublon : la même facture reçue deux fois ne crée ni deux demandes ni deux paiements.
4. Modification : un contenu changé après l’accord redemande une approbation.
5. Panne d’un service connecté : l’erreur est visible et l’action n’est pas marquée comme faite.

Un exemple de bout en bout

Remarquez ce que l’automatisation n’a pas fait : elle n’a ni payé, ni contesté, ni choisi à la place de Chantal. Elle a fait la recherche et la comparaison, puis présenté une décision prête à prendre.

DEMANDE D’APPROBATION [identifiant], version [n]

DÉCLENCHEUR : [ex. facture 2318 reçue le JJ-MM]
SOURCE : [lien vers le document d’origine]

PROPOSITION : [texte complet, montant ou valeur exacte]
DESTINATAIRE OU DOSSIER TOUCHÉ : [adresse, fiche, compte]

INCERTITUDES :
- [écart détecté]
- [champ manquant ou « à confirmer »]

EN APPROUVANT : [effet exact, ex. ce courriel part à cette adresse]
CE QUI NE SE PASSERA PAS : [ex. aucun paiement]

CHOIX : Approuver cette version | Corriger | Refuser | Demander un complément
SANS RÉPONSE AVANT [date] : reste en attente, [remplaçant] est prévenu
SI LE CONTENU CHANGE : nouvelle approbation requise