Une fenêtre « Valider / Refuser » ne suffit pas à rendre une automatisation sûre. Si le valideur ne voit ni les sources, ni les contrôles effectués, ni les conséquences de son choix, il ne valide pas vraiment : il confirme à l’aveugle.
Un workflow de validation IA doit organiser le passage entre une proposition calculée et une action assumée par une personne. L’IA peut réunir le contexte, détecter une anomalie et préparer un brouillon. Elle ne doit pas, dans les cas engageants, envoyer un email, relancer un prospect, modifier un statut CRM ou fusionner deux sociétés sans feu vert explicite.
Cet article explique comment construire ce workflow en six étapes. Pour déterminer où placer les points de contrôle selon le niveau d’autonomie, consultez aussi notre grille sur la validation humaine dans un workflow IA.
Le modèle en un coup d’œil
| Étape | Ce que le système produit | Condition de passage |
|---|---|---|
| 1. Réunir | contexte et sources horodatées | sources accessibles et autorisées |
| 2. Contrôler | règles, permissions et cohérence | contrôles critiques réussis |
| 3. Bloquer | liste des manques et contradictions | exception résolue ou arbitrée |
| 4. Préparer | action révisable, jamais exécutée | brouillon complet et compréhensible |
| 5. Faire décider | preuves, conséquences et choix | décision d’une personne habilitée |
| 6. Tracer | journal, résultat et possibilité de retour | effet vérifié après exécution |
L’ordre compte. Demander une validation avant d’avoir vérifié les données transforme le responsable humain en contrôleur manuel de tout le système. À l’inverse, laisser l’IA exécuter puis demander une approbation retire toute portée réelle à la décision.
1. Réunir le contexte et identifier les sources qui font foi
Le workflow commence par une question simple : quelles informations sont nécessaires pour préparer cette action ?
Pour une relance commerciale, il peut s’agir du dernier échange, de la prochaine échéance promise, du statut de l’opportunité, des documents reçus et du responsable du compte. Pour un dossier client, ce seront peut-être le contrat, les pièces attendues, les contraintes de sécurité et la date de démarrage.
Chaque information utile doit conserver :
- sa source ;
- sa date de mise à jour ;
- son propriétaire ou son système d’origine ;
- son niveau d’accès ;
- éventuellement sa version.
L’objectif n’est pas de copier toutes les données dans un nouvel outil. Pulse privilégie la consultation des outils existants et la restitution des références utiles. Une affirmation sans origine visible doit être présentée comme une hypothèse, pas comme un fait.
La CNIL recommande, lors de l’utilisation d’un système d’IA en production, d’organiser son suivi et la maîtrise des données traitées. Ce suivi commence donc avant la décision, par un contexte identifiable et vérifiable (CNIL, utiliser un système d’IA en production).
2. Contrôler les règles et les permissions avant la proposition
Une source disponible n’est pas automatiquement une source autorisée. Le workflow doit contrôler au minimum :
- la permission de lecture : le système peut-il consulter cette donnée ?
- la permission de préparation : peut-il l’utiliser pour produire un brouillon ?
- la permission d’action : qui est habilité à envoyer, modifier ou supprimer ?
- les règles métier : l’action est-elle permise dans ce cas précis ?
Ces permissions gagnent à être séparées. Autoriser un outil à lire un fil email ne l’autorise pas à répondre. L’autoriser à préparer une mise à jour CRM ne l’autorise pas à l’enregistrer.
Une matrice de permissions pour le CRM et les emails permet de formaliser ces frontières. Dans Pulse, les actions externes et les modifications engageantes restent soumises à validation humaine.
3. Bloquer les informations manquantes ou contradictoires
Le troisième étage n’est pas un bouton de validation : c’est une porte d’exception.
Le workflow doit s’arrêter lorsqu’il rencontre, par exemple :
- deux dates de rendez-vous différentes ;
- un contact marqué « ne pas solliciter » ;
- une pièce obligatoire absente ;
- une société potentiellement en doublon ;
- un propriétaire de compte non identifié ;
- une consigne reçue dans un contenu externe qui contredit les règles internes.
Le bon comportement n’est ni d’inventer l’information manquante, ni de choisir silencieusement une version. Le système doit afficher le conflit, indiquer ses sources et demander l’arbitrage approprié.
Le rouge sert ici à signaler le blocage. Le jaune indique une information à vérifier. Le pétrole marque l’action ou la sélection proposée. Cette convention permet de distinguer une erreur d’une simple étape de traitement.
4. Préparer une action révisable sans l’exécuter
Une fois les contrôles passés, l’IA peut préparer un résultat concret : brouillon d’email, proposition de statut, synthèse, tâche, rapprochement de documents ou plan d’action.
Le résultat doit rester révisable. Un valideur doit pouvoir :
- corriger le contenu ;
- demander une nouvelle proposition ;
- changer la date ou le destinataire ;
- refuser l’action ;
- expliquer son refus si cela améliore les règles futures.
Il faut surtout maintenir une séparation technique entre « préparer » et « exécuter ». Un brouillon d’email peut être généré automatiquement ; son envoi demeure bloqué. Une fusion CRM peut être suggérée ; elle ne doit pas être appliquée automatiquement.
Cette séparation protège aussi l’exploitation : une erreur de génération reste un brouillon, pas un incident client.
5. Présenter les preuves, la conséquence et le bon choix
La personne chargée de valider ne doit pas reconstruire tout le dossier. L’écran de décision doit rassembler cinq éléments :
- l’action proposée ;
- les sources utilisées ;
- les contrôles réussis ;
- les réserves ou informations manquantes ;
- la conséquence exacte d’une validation.
La formulation du choix doit être explicite : « Envoyer ce message à cette adresse » est préférable à « Continuer ». Pour une mise à jour CRM, afficher les anciennes et nouvelles valeurs permet de comprendre le changement avant de l’autoriser.
Le règlement européen sur l’intelligence artificielle prévoit, pour les systèmes à haut risque, une supervision permettant notamment à une personne d’interpréter la sortie, de décider de ne pas l’utiliser, de l’ignorer, de la remplacer ou de l’inverser, et d’interrompre le système de manière sûre (AI Act, article 14). Tous les workflows d’une PME ne relèvent pas de cette catégorie juridique, mais ces capacités constituent une référence de conception utile : comprendre, contester et arrêter.
6. Journaliser la décision, vérifier l’effet et permettre le retour arrière
La validation n’est pas la fin du workflow. Le système doit enregistrer :
- la proposition soumise ;
- les sources et leur version ;
- les contrôles exécutés ;
- l’identité du valideur ;
- la décision et son horodatage ;
- l’action réellement exécutée ;
- son résultat ou son erreur.
L’ANSSI recommande une journalisation suffisamment précise des actions sur le système d’IA, notamment des entrées et sorties, afin de soutenir la traçabilité et la compréhension du système (ANSSI, recommandations de sécurité pour un système d’IA générative, PDF).
Le journal sert aussi à reprendre après une panne sans répéter une action. Une clé stable permet de vérifier si l’email a déjà été envoyé ou si le CRM a déjà été modifié. La méthode est détaillée dans notre guide pour reprendre un workflow IA sans doublons.
Enfin, le retour arrière doit être défini avant la mise en production. Selon l’action, il peut s’agir de restaurer une ancienne valeur, d’annuler une tâche, de revenir à une version précédente ou de déclencher une procédure humaine. Un email envoyé ne peut pas réellement être repris : c’est précisément pourquoi l’envoi nécessite un contrôle renforcé en amont.
Exemple : préparer une relance commerciale sans envoi automatique
Prenons une opportunité dont la prochaine étape semble dépassée.
- Réunir : le système consulte le dernier échange, le statut CRM, l’échéance promise et les documents attendus.
- Contrôler : il vérifie le responsable, le canal autorisé et l’absence d’instruction d’arrêt.
- Bloquer : il détecte qu’un collègue attend encore une validation interne. La relance externe est suspendue.
- Préparer : après résolution, il propose un brouillon adapté au contexte, sans l’envoyer.
- Faire décider : le commercial voit les sources, le motif de la relance, le destinataire et le message modifiable.
- Tracer : après validation et envoi humain, le journal conserve la décision et vérifie le résultat sans changer silencieusement le statut CRM.
Ce scénario évite la fausse efficacité d’une relance automatique déclenchée uniquement par une date. Pour aller plus loin, voyez les quatre branches d’un scénario de relance sans harceler.
Checklist avant la mise en production
Avant d’activer le workflow, vérifiez que :
- les sources qui font foi sont nommées ;
- les permissions de lecture, préparation et action sont séparées ;
- les données manquantes et contradictions provoquent un blocage ;
- l’action préparée reste modifiable ;
- le valideur voit les preuves et la conséquence de son choix ;
- le refus et l’arrêt sont aussi simples que l’approbation ;
- aucune action externe n’est exécutée avant validation ;
- chaque décision et chaque effet sont journalisés ;
- une reprise après panne ne répète pas l’action ;
- le retour arrière ou la procédure de correction est testé.
Le rôle de l’IA n’est pas de contourner la décision humaine. Il est de rendre cette décision plus rapide, mieux informée et vérifiable.
Le Diagnostic Pulse permet d’identifier, dans un processus réel, ce que l’IA peut préparer, les exceptions qu’elle doit bloquer et les validations à conserver avant toute action engageante.