Human in the loop : automatiser la création, pas l'exécution
Le human in the loop n'est pas une posture de prudence. C'est un principe de conception. Il détermine où l'automatisation apporte de la valeur sans créer de risque, et où un point de contrôle humain protège le système contre des erreurs dont le coût de correction dépasse le gain de l'automatisation.
Donatien Lefranc
Fondateur & Président, Leando
Imaginez un collaborateur qui doit envoyer une demande de mise en service à un opérateur réseau. L'outil peut automatiquement rassembler les données nécessaires , numéro de point de livraison, coordonnées du client, date de mise en service souhaitée, accord de rattachement , et les présenter dans un écran de validation. L'opérateur vérifie, corrige si besoin, puis clique pour déclencher. L'exécution est humaine. La préparation est automatique.
Ce découpage peut sembler anodin. Il ne l'est pas. C'est lui qui détermine si une automatisation renforce les équipes ou les met en difficulté.
La distinction qui structure tout : création vs exécution
Automatiser la création d'une tâche et automatiser son exécution sont deux décisions de nature différente. La création recouvre tout ce qui précède l'action : identifier que la tâche doit être faite, rassembler les données nécessaires, la présenter à la bonne personne au bon moment. L'exécution, c'est l'action elle-même : envoyer la demande, modifier une donnée dans un système externe, déclencher un paiement.
Automatiser la création sans automatiser l'exécution, c'est faire gagner du temps à l'opérateur sur la partie la moins intéressante de son travail , la recherche et la compilation d'information , tout en lui conservant le contrôle sur la partie qui a des conséquences réelles. Cette partition est la plus efficace en début de projet d'automatisation, parce qu'elle délivre de la valeur immédiatement tout en limitant la surface de risque.
Automatiser directement l'exécution suppose une maturité de données et une connaissance des cas d'exception que peu de PME ont au moment où elles démarrent. Cela suppose que les données disponibles dans le système sont fiables à 95%, que le scénario nominal couvre la quasi-totalité des cas, et que l'erreur d'exécution automatique n'a pas de conséquence irréversible. Ces conditions s'obtiennent progressivement, pas au premier sprint.
Pourquoi aller trop vite dans l'automatisation produit l'effet inverse
Une automatisation qui produit des erreurs coûte plus qu'un processus manuel. L'erreur manuelle est localisée, visible, et corrigible immédiatement. L'erreur automatisée peut se répliquer sur des centaines de cas avant d'être détectée. Sur un système connecté à des opérateurs réseau, des plateformes de paiement ou des systèmes de facturation client, une erreur d'exécution automatique génère des corrections en cascade, des rappels clients, des avoirs, et une méfiance durable des équipes vis-à-vis de l'outil.
« Ils avaient une volonté parce qu'ils avaient des contraintes de la direction d'avancer très vite dans le code. On a été un petit peu là-dessus l'élément qui avait tendance à freiner parce qu'on anticipait que aller trop vite dans le code allait aussi avoir ses limites. »
Cette posture de frein assumé n'est pas confortable. La pression de la direction pour aller vite dans l'automatisation est légitime : elle répond à une vraie douleur opérationnelle. Mais aller trop vite produit une automatisation fragile que les équipes contournent, et des corrections qui effacent les gains attendus. Le frein n'est pas une résistance au changement , c'est une protection de l'investissement.
Ce que le human in the loop produit comme données
Le point de contrôle humain a un second rôle, moins visible mais aussi stratégique : il produit de l'information sur ce qui ne fonctionne pas encore bien dans l'automatisation. Quand un opérateur complète manuellement une donnée que le système n'a pas réussi à récupérer, cela génère un signal : ce champ a une lacune dans la chaîne de données. Quand il corrige une valeur pré-remplie, cela signale une règle métier que l'automatisation n'a pas encore capturée.
Ces signaux, consolidés sur plusieurs semaines d'utilisation, produisent une cartographie précise des données manquantes et des cas d'exception. C'est exactement la matière nécessaire pour construire l'automatisation complète de la version suivante , sur des fondations documentées, pas sur des hypothèses. Pour comprendre comment cette progression en versions protège le budget global, retrouvez pourquoi centraliser manuellement avant d'automatiser est une étape stratégique.
La confiance des équipes comme condition de l'automatisation complète
Une automatisation que les équipes ne font pas confiance n'est pas une automatisation , c'est un outil qu'on contourne. La confiance se construit progressivement, à partir de preuves. Une V0 où l'information est pré-remplie de façon fiable, une V1 où les déclencheurs automatiques sont justes dans 95% des cas, une V2 où l'exécution automatique ne produit pas d'erreurs : chaque version augmente le niveau de confiance des équipes dans le système.
Brûler ces étapes pour arriver directement à la V2 prive le projet de la base de confiance sur laquelle l'automatisation complète doit reposer. Si les équipes n'ont pas vu le système faire ses preuves progressivement, elles ne lui feront pas confiance pour l'exécution automatique. Et si elles ne lui font pas confiance, elles créeront des processus parallèles pour vérifier , ce qui efface le gain de l'automatisation.
Le human in the loop n'est pas une étape vers l'automatisation complète. C'est la méthode par laquelle l'automatisation complète devient possible. Pour aller plus loin sur la supervision humaine dans les projets IA, retrouvez pourquoi l'IA représente 5% d'un projet et le reste c'est du processus.
Quand passer à l'automatisation complète de l'exécution
Trois conditions suffisent pour décider du passage à l'exécution automatique sur une tâche. La première : les données nécessaires à l'exécution sont récupérées de façon fiable depuis le système, sans saisie manuelle résiduelle sur au moins deux mois d'utilisation. La seconde : le scénario nominal couvre plus de 95% des cas réels observés. La troisième : l'erreur d'exécution automatique est détectable rapidement et corrigeable sans conséquence irréversible.
Ces trois conditions sont rarement réunies simultanément sur l'ensemble des tâches d'un processus. Sur certaines tâches simples et bien bornées, elles peuvent l'être après quelques semaines de V1. Sur des tâches complexes avec de nombreux cas d'exception , comme les demandes de mise en service dans le secteur de l'énergie , cela peut prendre plusieurs mois. La décision se prend tâche par tâche, pas sur l'ensemble du processus d'un coup.
Prochaine action concrète : identifiez une tâche de votre équipe que vous souhaitez automatiser. Posez-vous la question : les données nécessaires à son exécution sont-elles disponibles de façon fiable dans votre SI aujourd'hui, sans que l'opérateur ait à en compléter manuellement une partie ? Si la réponse n'est pas clairement oui, la prochaine étape est de combler ce manque de données , pas d'automatiser l'exécution. Pour comprendre comment structurer le cadrage avant tout développement, retrouvez pourquoi le cadrage est crucial à l'ère de l'IA.
C'est le principe qui consiste à automatiser ce qui peut l'être , la recherche d'information, le déclenchement d'une tâche, le pré-remplissage des données , tout en maintenant un point de validation humain avant toute action irréversible. Dans un contexte PME, cela se traduit concrètement par : l'outil prépare la tâche et ses données, l'opérateur vérifie et valide, puis déclenche l'exécution. Le gain de temps est réel, le risque d'erreur est contenu.
Vous voulez automatiser sans risquer de créer plus de problèmes que vous n'en résolvez ?
On conçoit avec vous la progression V0 / V1 / V2 adaptée à votre contexte, en identifiant tâche par tâche où le human in the loop protège et où l'automatisation complète est possible. Échange de 30 minutes, sans engagement.
Structurer mon automatisation