« Nous perdons trop de temps sur cette tâche, il faut l’automatiser. » Le constat semble évident. Pourtant, beaucoup de projets commencent par automatiser l’étape la plus visible alors que le vrai problème se trouve ailleurs : une règle commerciale ambiguë, une information saisie trop tard ou une validation dont personne n’est réellement responsable.
Le bon point de départ n’est donc pas la technologie. C’est une décision sur le processus.
Un bon candidat à l’automatisation n’est pas seulement répétitif. Il est suffisamment compris pour que l’on sache ce que le système doit faire lorsque la situation n’est pas normale.
1. Décrire un flux réel, pas une procédure théorique
Prenez un cas récent et suivez-le de son déclenchement jusqu’au résultat final. Pour une commande, cela peut aller de la demande du client à la livraison et au rapprochement de la facture. Notez chaque transfert : qui reçoit quoi, dans quel format, quelle décision est prise et où l’information est enregistrée.
Il faut distinguer trois durées :
- le temps actif, pendant lequel une personne travaille réellement sur le dossier ;
- le temps d’attente, entre deux actions ou validations ;
- le temps de reprise, consacré aux corrections, recherches et doubles saisies.
Une opération peut demander seulement vingt minutes de travail mais rester bloquée trois jours. Dans ce cas, accélérer la saisie ne traite pas forcément le problème principal. Une notification, une règle de responsabilité ou la suppression d’une validation peut avoir plus de valeur qu’une automatisation complexe.
2. Noter six signaux avant de parler d’outil
J’utilise une grille simple. Chaque signal est noté de 0 à 2 : absent, moyen ou fort.
- Volume : combien de dossiers passent réellement par ce flux chaque semaine ou chaque mois ?
- Coût unitaire : combien de minutes et combien de rôles mobilise un dossier normal ?
- Coût des erreurs : une erreur crée-t-elle seulement une gêne, ou bien un retard client, un avoir, un risque juridique ?
- Stabilité des règles : deux personnes expérimentées prennent-elles la même décision avec les mêmes informations ?
- Qualité des entrées : les données nécessaires existent-elles, et peut-on les obtenir dans un format exploitable ?
- Capacité d’action : une personne est-elle responsable du flux et disponible pour arbitrer les exceptions ?
Un score élevé ne donne pas automatiquement le feu vert. Il indique qu’un diagnostic court mérite d’être mené. À l’inverse, un volume faible, des règles instables et aucun responsable produit sont trois raisons de ne pas construire trop tôt.
3. Commencer par les exceptions
Une démonstration suit presque toujours le chemin idéal. Le produit quotidien vit dans les cas incomplets : référence inconnue, prix négocié hors catalogue, document illisible, doublon, approbateur absent, client bloqué ou informations contradictoires.
Pour chaque exception fréquente, posez quatre questions :
- comment la détecter ?
- qui décide ?
- quelle information permet de décider ?
- comment reprendre le flux sans perdre la trace de ce qui s’est passé ?
Cette liste détermine une grande partie de l’interface et de l’architecture. Si aucune réponse claire n’existe, le premier livrable peut être une nouvelle règle métier, pas du code.
4. Choisir le bon niveau d’automatisation
Toutes les étapes ne doivent pas devenir autonomes. Il existe au moins quatre réponses possibles.
Supprimer
Une saisie ou une validation qui n’est utilisée par personne doit disparaître. C’est l’automatisation la moins coûteuse et souvent la plus rentable.
Simplifier
Un formulaire unique, une nomenclature commune ou une meilleure vue de suivi peut éliminer la majorité des frictions sans créer de moteur complexe.
Automatiser par des règles
Lorsque les entrées sont structurées et la décision explicite, des règles déterministes sont préférables : elles coûtent peu, se testent facilement et restent compréhensibles.
Assister avec l’IA
L’IA devient intéressante quand l’entrée est variable : e-mails, contrats, photographies, descriptions libres ou documents hétérogènes. Elle peut extraire, classer, rapprocher ou proposer une synthèse. Une règle classique doit ensuite contrôler ce qui peut l’être, et une personne doit rester dans la boucle lorsque le coût d’une erreur est important.
5. Chiffrer sans inventer un ROI
Une estimation utile repose sur des hypothèses visibles :
gain mensuel brut = volume × temps économisé par dossier × coût horaire chargé
Ajoutez ensuite les coûts qui sont souvent oubliés : exploitation, surveillance, corrections, évolution des règles et accompagnement des utilisateurs. Le projet doit aussi être comparé à une alternative simple. Si un changement de procédure récupère 70 % du gain en deux jours, cette option mérite d’être testée avant un développement sur mesure.
Il faut enfin mesurer autre chose que le temps : délai de traitement, nombre de reprises, dossiers sans statut, erreurs détectées après livraison et part des cas nécessitant une intervention manuelle.
6. Tester le risque principal avec une tranche verticale
Un prototype isolé peut prouver qu’une API fonctionne sans prouver que le produit sera utilisé. Je préfère une tranche verticale : un seul type de dossier, un petit groupe d’utilisateurs, mais le flux entier jusqu’au résultat réel.
Par exemple, pour une commande reçue par e-mail : réception, extraction, contrôle des champs obligatoires, demande de correction, validation, création dans le système cible et journal d’audit. Le périmètre est étroit, mais toutes les couches difficiles sont présentes.
À la fin du test, la décision doit être explicite : étendre, corriger l’organisation, changer d’approche ou arrêter. Arrêter un mauvais projet après deux semaines est un résultat utile.
Le livrable attendu avant de construire
Un diagnostic sérieux peut tenir sur quelques pages : carte du flux actuel, mesures de départ, dix exceptions principales, règles de décision, systèmes concernés, risques et proposition d’un premier périmètre. Ce document permet à une direction de comparer le coût du statu quo, une amélioration légère et un produit sur mesure.
Chez AI7, c’est cette étape qui relie analyse produit et réalisation technique. Elle évite de vendre de l’IA à un problème de responsabilité, ou de développer un SaaS complet lorsqu’un outil métier ciblé suffit.