Les projets d’automatisation échouent rarement pour des raisons techniques. Ils échouent parce qu’on a automatisé un processus que personne ne savait décrire. Trois personnes le faisaient de trois façons différentes, chacune avec ses exceptions, et l’outil a figé la version d’une seule d’entre elles. Le résultat fonctionne en démonstration et se fait contourner en deux semaines.
Avant de choisir un outil, il faut donc trancher une question moins séduisante : ce processus est-il assez stable pour supporter d’être écrit noir sur blanc ? Voici la grille que nous appliquons, et les cas où nous recommandons de ne rien automatiser.
Un processus instable ne s’automatise pas, il se stabilise
Le test tient en une expérience de cinq minutes. Demandez séparément à deux personnes qui exécutent la tâche de décrire les étapes, puis comparez. Si les deux descriptions divergent au-delà du vocabulaire, vous n’avez pas un processus : vous avez deux pratiques cohabitantes.
Automatiser à ce stade produit toujours la même chose. L’outil impose la pratique de la personne qui a participé au projet. L’autre continue à faire à sa manière, en dehors de l’outil. Les deux flux divergent, les données se contredisent, et six mois plus tard personne ne sait laquelle des deux sources dit vrai.
L’ordre correct est donc : décrire, faire trancher les écarts par la personne responsable du résultat, exécuter deux semaines selon la version retenue, puis automatiser. Cette séquence paraît lente. Elle est plus rapide que la reprise d’un outil contourné.
Les quatre critères qui décident
Une tâche se prête à l’automatisation quand les quatre conditions suivantes sont réunies. Trois sur quatre ne suffisent pas : c’est celle qui manque qui fait le coût du projet.
- Le volume. Sous une dizaine d’occurrences par semaine, le temps de conception et de maintenance ne se rembourse pas. Une tâche pénible mais rare se traite par une meilleure procédure, pas par du code.
- La règle. Il faut pouvoir énoncer la décision sous forme de condition. « On relance au bout de dix jours ouvrés sauf si le client a répondu » est une règle. « On relance quand on sent que c’est le moment » n’en est pas une, et aucun modèle ne la devinera.
- La tolérance à l’erreur. Quelle est la conséquence d’une décision fausse une fois sur cent ? Un e-mail de relance envoyé à tort se rattrape. Une facture émise au mauvais montant, non.
- L’accès aux données. Si l’information vit dans une pièce jointe scannée, dans un tableur local ou dans la tête de quelqu’un, le projet commence par un chantier de données dont personne n’a chiffré le coût.
Ce qui s’automatise vraiment, ce qui résiste
| Tâche | Verdict | Pourquoi |
|---|---|---|
| Extraire les lignes d’une facture fournisseur vers l’outil comptable | Oui | Volume élevé, format répétitif, erreur visible immédiatement au rapprochement |
| Trier et router les demandes entrantes vers le bon service | Oui | Règle énonçable, erreur peu coûteuse, correction possible par l’équipe |
| Relancer les devis sans réponse | Oui | Condition de date claire, forte répétition, conséquence d’une erreur faible |
| Rédiger une première version de fiche produit à partir des caractéristiques techniques | Oui, avec relecture | Gain réel sur le temps de rédaction, mais publication jamais automatique |
| Répondre à une réclamation client | Non | Chaque cas dépend d’un historique commercial et d’un arbitrage humain |
| Décider d’une remise commerciale | Non | Décision engageante, données incomplètes, tolérance à l’erreur nulle |
| Qualifier un prospect de manière définitive | Partiellement | L’outil peut ordonner les priorités et les expliquer ; le classement final reste humain |
| Valider une pièce comptable | Non | Responsabilité légale non transférable à un automate |
La validation humaine n’est pas une roue de secours
Beaucoup de projets prévoient une validation humaine « au cas où ». Elle est alors placée en fin de chaîne, sur un écran que personne n’ouvre, et elle devient un tampon automatique au bout de trois semaines.
Une validation utile respecte trois conditions. Elle arrive là où l’erreur coûte cher, pas partout. Elle présente la raison de la proposition, pas seulement la proposition : sans le pourquoi, la personne ne peut rien vérifier. Et elle laisse une trace de la correction, qui sert ensuite à améliorer la règle. Une correction non tracée est une information perdue deux fois.
Les exceptions coûtent plus cher que le cas courant
Le cas normal représente en général quatre-vingts pour cent du volume et vingt pour cent du travail de conception. Les exceptions font l’inverse : le fournisseur qui envoie ses factures dans un format à lui, le client dont les conditions de paiement sont particulières, le mois de décembre qui ne ressemble à aucun autre.
Deux stratégies, et il faut choisir explicitement. Soit on traite les exceptions dans l’outil, et le budget double. Soit on les écarte proprement : l’automate détecte qu’il ne sait pas, s’arrête, et transmet le cas à un humain avec ce qu’il a compris. La seconde stratégie est presque toujours la bonne pour un premier projet. La faute à éviter est la troisième voie, celle où l’outil traite les exceptions comme si c’étaient des cas normaux, sans le dire.
Ce qu’il faut journaliser dès le premier jour
Un automate sans journal est impossible à corriger : on ne peut ni reproduire une erreur, ni prouver ce qui s’est passé, ni mesurer le gain réel. Quatre traces suffisent, et elles se posent au démarrage, pas après le premier incident.
- L’entrée : la donnée reçue, telle qu’elle est arrivée.
- La décision et sa raison : ce que l’outil a fait, et sur quelle règle ou quel passage il s’est appuyé.
- Les interventions humaines : qui a corrigé quoi, et quand.
- Les arrêts : les cas où l’outil a renoncé. Cette liste est la feuille de route des évolutions suivantes.
Le seul indicateur qui compte au bout de trois mois
Ni le nombre de tâches traitées, ni le temps de traitement : le temps humain réellement libéré, mesuré auprès des personnes concernées. Un automate qui traite deux mille documents par mois mais oblige quelqu’un à en vérifier chacun n’a rien libéré ; il a déplacé le travail de la saisie vers le contrôle, parfois pour le pire.
Posez la question directement à l’équipe, trois mois après la mise en service : qu’est-ce que vous ne faites plus ? Si personne ne trouve de réponse nette, le projet est à revoir, et la réponse dira où.
