L’agent a compris la demande, récupéré le dossier CRM, préparé le devis et proposé une remise de 8 % liée au volume. Le texte est propre. Le calcul paraît cohérent. Il ne reste qu’à cliquer sur « Envoyer ».
Ce dernier geste change pourtant tout. Jusque-là, l’agent a préparé du travail. Dès l’envoi, l’entreprise communique un prix réel à un client réel.
Le « human-in-the-loop » est souvent mal dessiné dans les petites structures : soit un collaborateur doit valider chaque micro-action, soit on lui demande vaguement de surveiller un agent déjà autonome. Un modèle plus concret consiste à séparer brouillon → validation → exécution. L’agent prépare une transaction précise, une personne autorisée contrôle ce qui compte, puis le système exécute.
Il s’agit d’une recommandation d’architecture et de gouvernance, pas d’une obligation légale universelle. L’intérêt est de placer une vraie décision avant l’effet.
Le schéma Draft Approve Execute sépare préparation et autorité
Un modèle peut très bien assembler des données, rédiger et proposer. L’autorité de promettre un prix, d’effectuer un remboursement, de supprimer un dossier ou de confirmer une réservation appartient à une autre couche.
Le cadre AI RMF de NIST insiste sur la gouvernance et la gestion continue des risques. La Convention-cadre du Conseil de l’Europe sur l’IA comporte des principes de responsabilité, supervision, transparence et fiabilité. Ces textes ne signifient pas qu’une PME doit faire approuver manuellement chaque opération banale. Ils renforcent plutôt l’idée que les contrôles doivent suivre les conséquences et la responsabilité.
Un bon brouillon doit donc montrer sa base de décision : faits client, règle appliquée, calcul, éventuelle déviation et action prévue.
Le collaborateur ne devrait pas devoir refaire tout le raisonnement depuis zéro.
La validation doit se trouver à la frontière de l’engagement
Valider chaque correction grammaticale crée une procédure inutile. Recevoir une notification après l’envoi d’une offre n’est plus une validation.
La bonne frontière se trouve généralement juste avant une action qui produit un effet client, financier, contractuel ou difficile à annuler.
Un tag interne peut être automatisé sous des règles étroites. Une proposition de créneau peut rester en brouillon. Une remise hors barème, un remboursement, un export de données ou une confirmation ferme mérite davantage de contrôle.
Recommandation : classez les actions en trois groupes pratiques : faible risque et réversible ; conséquence notable mais maîtrisable ; engagement ou action difficilement réversible. Adaptez les seuils à votre métier.
Exemple : dans un garage, l’agent peut confirmer la réception d’une demande. Il peut proposer un créneau. Il ne devrait pas transformer une photo et un message vocal en promesse ferme de prix sans intervention d’un professionnel.
Un bouton « approuver » sans contexte n’est pas un contrôle
L’interface la plus dangereuse affiche simplement : « L’agent souhaite agir. Approuver ? » Après une série de cas normaux, le clic devient automatique.
Une carte de validation utile montre l’action exacte, les données déterminantes, l’écart par rapport à la règle habituelle, le destinataire et la réversibilité.
Pour un devis : prix standard CHF 4'800 ; proposition CHF 4'416 ; justification : règle de volume ; seuil autonome : 5 % ; réduction actuelle : 8 % ; validation requise.
Le commercial peut alors vérifier la décision, plutôt que relire vingt champs CRM.
Il doit aussi disposer de plusieurs sorties : approuver, modifier et exécuter, refuser, escalader. Sans cela, les exceptions repartent dans des canaux parallèles et l’entreprise perd la traçabilité.
Une mise en place suffisamment petite pour être utilisée
Commencez par une seule transaction.
- Choisissez l’action. Envoi d’un devis, confirmation d’un rendez-vous ou changement de statut suffit.
- Séparez techniquement brouillon et commit. Générer la proposition ne doit pas déclencher automatiquement l’action réelle.
- Définissez les déclencheurs. Montant, données sensibles, déviation, type de client ou difficulté d’annulation.
- Réduisez le contexte de validation. Montrez ce qui est nécessaire pour décider, pas tout le trace technique.
- Journalisez la décision. Qui a validé, modifié, refusé ou escaladé ?
- Vérifiez l’exécution. Le système cible doit confirmer le résultat après la validation.
Cette dernière étape évite un faux « terminé ». Si l’API échoue après l’approbation, le dossier doit rester visible comme ouvert ou en erreur.
Quand retirer volontairement l’humain
L’objectif n’est pas de garder toutes les validations éternellement. Une classe d’actions peut, après tests et exploitation réelle, s’avérer stable, réversible et peu risquée. On peut alors automatiser uniquement ce segment.
Le tagging interne est un bon exemple. Une nouvelle coordonnée bancaire, une suppression, un engagement contractuel ou un prix inhabituel n’appartiennent pas à la même catégorie.
Mesurez taux de validation, taux de modification avant exécution, refus/escalades, temps entre brouillon et décision, erreurs après exécution validée et cas où le reviewer signale un contexte insuffisant.
Un taux de validation proche de 100 % peut être excellent — ou révéler que plus personne ne lit. Échantillonnez donc les décisions et observez les modifications utiles.
La conclusion est pratique : mettre « un humain dans la boucle » ne suffit pas. Placez-le au moment où un brouillon devient un engagement, donnez-lui les informations qui comptent et une vraie capacité à modifier ou arrêter. L’agent peut alors absorber beaucoup d’administration sans recevoir silencieusement le pouvoir de décider pour l’entreprise.
Les permissions et journaux bornent l'action. Un arrêt d'urgence avec retour arrière protège le fonctionnement.
Sources
- NIST — AI Risk Management Framework 1.0
- NIST — Generative AI Profile
- Conseil de l’Europe — Convention-cadre sur l’IA
FAQ
Chaque action doit-elle être validée ?
Non. Les actions étroites, réversibles et peu risquées peuvent être automatiques. La validation sert surtout aux conséquences importantes.
Que doit afficher l’écran de validation ?
Action prévue, faits déterminants, écart aux règles, conséquence et justification essentielle.
Est-ce une obligation légale ?
Pas comme règle universelle pour toute automation IA. C’est un pattern de contrôle ; des obligations spécifiques peuvent exister selon le cas.
Que faire si l’API échoue après validation ?
Le dossier reste ouvert ou en erreur et doit être vérifié dans le système cible avant toute nouvelle tentative.
Quand peut-on supprimer la validation ?
Quand une catégorie d’action très précise a montré en exploitation qu’elle est prévisible, réversible et à faible conséquence.