Automatiser sans perdre la main

L’automatisation a une propriété qu’on oublie de mentionner en la vendant : elle amplifie. Un processus sain traité automatiquement produit le même résultat plus vite ; un processus bancal produit ses erreurs plus vite, en plus grand nombre, et les rend visibles plus tard.

Le tri qui décide de tout tient en une question posée à chaque étape : si cette étape se trompe, est-ce que quelqu’un peut revenir en arrière ? Les étapes où la réponse est oui s’automatisent largement. Celles où la réponse est non attendent une main humaine, et aucun gain de temps ne justifie de déplacer cette frontière.

Cet article décrit comment faire ce tri, ce qui casse quand on ne le fait pas, et la mesure à quinze minutes qui vous dira si le projet vaut son coût avant que quiconque vous ait facturé quoi que ce soit.

Une automatisation utile est faite à quatre-vingts pour cent de plomberie ordinaire : brancher deux outils, déplacer un champ, écrire une règle, déclencher à une heure. Rien de tout cela ne demande un modèle, et tout cela existait bien avant qu’on parle d’IA.

Le modèle sert à un endroit précis : lire du texte libre écrit par un humain. Une demande en message privé, un e-mail sans structure, une facture reçue en photo. C’est là qu’il fait quelque chose qu’aucune règle ne fait, et c’est le seul endroit où il vaut son coût.

Ailleurs, il coûte sans rien apporter. Appeler un modèle pour comparer deux nombres, vérifier qu’un champ n’est pas vide ou recopier une valeur d’un tableau vers un autre, c’est payer en devises une opération que trois lignes de règle font gratuitement et sans jamais se tromper. Nous avons intérêt à ne pas vous le dire, et nous vous le disons.

Cette même distinction sépare aussi trois produits que le marché vend sous un seul mot, et agent, chatbot et automatisation ne se surveillent pas de la même façon — ce qui décide plus souvent un achat que le choix du modèle.

Cette distinction a une conséquence directe sur la facture, et elle est facile à vérifier. Demandez à voir, pour chaque étape de l’automatisation proposée, si elle appelle un modèle ou non, et combien de fois par exécution. Un enchaînement qui appelle un modèle à quatre étapes sur cinq est presque toujours mal conçu, et la correction — remplacer trois de ces appels par des règles — divise le coût mensuel sans rien retirer au résultat.

La frontière entre les deux colonnes se matérialise par une attente. À cette étape, le système prépare tout — le devis est rédigé, le message est écrit, la commande est complète — et s’arrête. Une personne regarde et valide, ou corrige.

Cette attente est souvent présentée comme le défaut du système, alors qu’elle en est la garantie. Un prestataire qui propose de la supprimer pour « gagner en fluidité » propose de déplacer la frontière, et il faut lui demander qui porte le coût quand l’étape se trompe. La réponse est toujours le client, jamais le prestataire.

Il y a une contrepartie honnête : la validation doit être rapide, sinon elle devient le goulot d’étranglement et quelqu’un finira par demander à la contourner. Une validation qui demande d’ouvrir trois écrans sera contournée dans le mois. Elle doit tenir sur un téléphone, en un geste, avec ce qu’il faut pour décider.

Il faut aussi décider ce qui se passe quand personne ne valide. Une validation qui reste en attente trois jours parce que la personne est en congé bloque tout ce qui suit, et le blocage est silencieux. La règle à poser est une échéance : au-delà d’un délai convenu, le dossier remonte à quelqu’un d’autre ou repart en traitement manuel, avec une notification. Sans cette règle, la file d’attente devient le nouvel endroit où les choses se perdent. Cet endroit se tient, et la file d’exceptions a ses propres règles de relevé.

La mesure honnête coûte une semaine et vous pouvez la faire seul : prenez la tâche qui agace le plus votre équipe, et notez chaque jour le temps réellement passé dessus. Pas l’estimation — le relevé. L’écart entre les deux est systématiquement dans le même sens, et il est grand.

Nous ne mettons pas de graphique dans cette section, et pas pour la raison habituelle. Le chiffre existe et il est solide chez chaque client ; il n’est simplement pas transportable. Une saisie de factures, un tri de demandes entrantes et un rapprochement de listes n’ont ni la même durée unitaire, ni la même fréquence, ni le même taux d’exception, et une moyenne entre eux ne décrit aucun des trois. Publier cette moyenne vous donnerait un chiffre que vous ne pourriez pas appliquer à votre cas.

Ce que le relevé permet, en revanche, c’est une décision. Si la tâche prend dix minutes par semaine, l’intégration ne se rentabilisera pas avant plusieurs années, et l’outil d’en face aura changé d’interface entre-temps. Si elle prend six heures, la question ne se pose pas. La frontière est quelque part au milieu et le relevé la trouve.

Le relevé a un second usage que personne n’anticipe : il montre la variance. Une tâche qui prend quarante minutes en moyenne mais entre dix minutes et trois heures selon les jours n’est pas la même tâche qu’une tâche stable à quarante minutes. La première contient des cas particuliers nombreux, et ce sont eux qui décideront du coût réel du projet — pas la moyenne, qui les dissout exactement comme elle dissout tout le reste.

Nous observons le processus, nous remplissons les deux colonnes avec vous, nous construisons une automatisation à la fois et nous la mettons en service avant de passer à la suivante. Un mois après, nous remesurons, et ce qui ne fait pas gagner de temps est retiré plutôt que maintenu par politesse.

Le chiffre que nous ne reprendrons pas est le gain constaté chez un autre client. Nous les avons, ils sont relevés proprement, et ils ne vous concernent pas : ils décrivent une tâche précise, dans une entreprise précise, avec un taux d’exception qui lui appartient. Un prestataire qui ouvre par « nos clients gagnent tant d’heures par semaine » vous a donné une information sur ses clients et aucune sur vous, et il le sait. Nous préférons vous faire faire le relevé d’une semaine, même si cela retarde la vente et même si le relevé conclut parfois qu’il n’y a rien à automatiser.

Nous avons aussi une limite de compétence à nommer. Si le tri révèle que le processus lui-même est le problème — qu’il a été empilé au fil des ans, que trois personnes font la même vérification, que l’étape quatre existe pour compenser l’étape deux — nous ne le refondons pas. C’est un travail d’organisation, pas d’intégration, et il se fait avec quelqu’un dont c’est le métier ou en interne avec les personnes concernées. Nous vous le dirons, nous vous rendrons la page du processus qui le montre, et nous arrêterons là. Automatiser un processus dans cet état revient à le graver.