Le premier processus à automatiser n’est pas forcément le plus pénible ni le plus visible : c’est celui qui combine un vrai coût récurrent et de bonnes chances de réussite. Concrètement, on cherche un processus fréquent, qui consomme du temps qualifié, dont les règles sont stables, les exceptions limitées, les données accessibles et les erreurs rattrapables. Cet article propose une grille de notation simple, à appliquer à trois à cinq candidats, et dit quels processus il vaut mieux garder pour plus tard.
Pourquoi le premier projet compte plus que les suivants
Un premier projet d’automatisation ne sert pas seulement à gagner du temps sur une tâche. Il sert aussi à vérifier que l’entreprise sait décrire un processus, donner accès à ses données, valider un résultat et faire vivre un système après sa livraison. S’il échoue, l’échec est rarement attribué au processus choisi : il est attribué à « l’automatisation » ou à « l’IA » en général, et le sujet est enterré pour un moment.
Le premier projet doit donc être gagnable et mesurable.
- Gagnable : les règles peuvent être formalisées, les données existent et sont accessibles, les personnes qui connaissent le processus sont disponibles pour l’expliquer, et une erreur ne provoque pas de dommage irréversible.
- Mesurable : on sait combien de temps, de délai ou de reprises le processus coûte aujourd’hui, et on pourra comparer après la mise en service. Sans point de départ chiffré, même un projet réussi reste une impression.
Cela ne veut pas dire choisir un processus anecdotique. Un projet trop petit ne prouve rien et ne finance pas les suivants. Le bon premier candidat se situe entre les deux : assez important pour que le résultat compte, assez maîtrisable pour que le résultat arrive.
Les critères qui départagent les candidats
On peut regrouper les critères en deux familles : ce que le processus coûte aujourd’hui (la valeur à aller chercher) et ce qui rend son automatisation réaliste (la faisabilité).
Valeur
Fréquence. Un traitement répété chaque jour ou chaque semaine rembourse plus vite l’effort de formalisation qu’un traitement annuel. La fréquence donne aussi plus de cas réels pour tester et ajuster le système.
Temps qualifié consommé. Le critère n’est pas le nombre d’heures en soi, mais qui les passe. Une heure de collecte et de copier-coller réalisée par un contrôleur de gestion, un acheteur ou un responsable ADV est une heure retirée à l’analyse, à la négociation ou à la relation client. C’est souvent là que se trouve la vraie valeur.
Dépendance à une personne. Quand le processus ne fonctionne que parce qu’une personne « sait comment faire », l’automatiser réduit un risque de continuité : absence, départ, surcharge. Ce critère augmente l’intérêt du projet, à une condition : que cette personne ait le temps d’expliquer ses règles. Sans elle, la formalisation devient une reconstitution.
Faisabilité
Stabilité des règles. Si la manière de faire change tous les trimestres, ou si elle dépend de la personne qui traite le dossier ce jour-là, il faut d’abord stabiliser le processus. Automatiser des règles mouvantes revient à automatiser un désaccord.
Volume d’exceptions. Tout processus a des exceptions. La question est leur proportion et leur nature. Quelques cas particuliers bien identifiés peuvent être routés vers une validation humaine. Une majorité de cas « particuliers » signale que la règle réelle n’a pas encore été trouvée.
Risque en cas d’erreur. Une erreur détectée avant envoi, corrigée en quelques minutes, n’a pas le même poids qu’un paiement parti au mauvais fournisseur ou qu’un document transmis à l’administration. Pour un premier projet, on préfère un processus où le système prépare et où un humain valide avant l’effet irréversible. L’article sur le partage entre code, IA et validation humaine détaille ce découpage.
Accès aux données. Les données nécessaires sont-elles disponibles dans un outil interrogeable (ERP, CRM, base, dossier partagé structuré), ou dispersées dans des boîtes e-mail personnelles et des fichiers locaux ? Un accès qui demande des mois de négociation avec un éditeur ou la DSI peut suffire à disqualifier un candidat pour un premier projet.
Une grille de notation à appliquer à vos candidats
Listez trois à cinq processus candidats. Pour chacun, notez chaque critère de 1 à 3, où 3 est toujours la situation la plus favorable à un premier projet.
| Critère | 1 | 2 | 3 |
|---|---|---|---|
| Fréquence | Mensuelle ou plus rare | Hebdomadaire | Quotidienne ou continue |
| Temps qualifié consommé | Faible, tâche d’exécution rapide | Quelques heures par semaine | Une part visible du temps d’une ou plusieurs personnes qualifiées |
| Dépendance à une personne | Plusieurs personnes savent faire, procédure écrite | Une ou deux personnes clés, en partie documenté | Une seule personne sait vraiment faire, et elle est disponible pour l’expliquer |
| Stabilité des règles | Règles qui changent souvent ou varient selon la personne | Règles connues mais avec des variantes non écrites | Règles stables, formulables en quelques pages |
| Volume d’exceptions | La majorité des cas sont « particuliers » | Une part notable de cas à traiter à part | Exceptions rares et identifiables |
| Risque en cas d’erreur | Effet immédiat et difficile à rattraper | Effet rattrapable mais coûteux | Erreur détectable et corrigible avant tout effet |
| Accès aux données | Données dispersées ou inaccessibles | Accessibles avec un travail d’extraction | Disponibles dans un outil interrogeable |
Deux règles de lecture, plus utiles qu’un total :
- Un 1 sur un critère de faisabilité (stabilité, exceptions, risque, accès aux données) écarte le candidat comme premier projet, quel que soit son score de valeur. Il ne disparaît pas de la liste : il attend que ce point soit traité.
- Parmi les candidats restants, on choisit celui qui a le meilleur score de valeur (fréquence, temps qualifié, dépendance). En cas d’égalité, on retient celui dont le résultat se mesure le plus simplement.
Le total sur 21 peut servir à trier une liste plus longue, mais il ne doit pas masquer un point bloquant : un processus très coûteux dont les données sont inaccessibles restera un mauvais premier projet.
Un exemple illustratif sur quatre fonctions
Prenons un exemple fictif : une PME industrielle hésite entre quatre candidats. Les notes ci-dessous sont illustratives et servent seulement à montrer le raisonnement.
- ADV : saisie des commandes clients reçues par e-mail. Les commandes arrivent en PDF ou dans le corps du message, sont ressaisies dans l’ERP, puis confirmées au client.
- Achats : choix entre devis fournisseurs. Les acheteurs comparent des offres hétérogènes et arbitrent selon le prix, les délais et la relation avec chaque fournisseur.
- Finance : rapprochement des factures fournisseurs avec les commandes et les réceptions. Les écarts sont signalés à l’acheteur ou au magasin avant mise en paiement.
- Contrôle de gestion : construction du budget annuel. Un fichier Excel consolidé à partir des contributions de chaque service.
| Critère | Saisie des commandes (ADV) | Choix des devis (achats) | Rapprochement factures (finance) | Budget annuel (contrôle de gestion) |
|---|---|---|---|---|
| Fréquence | 3 | 2 | 3 | 1 |
| Temps qualifié | 3 | 2 | 3 | 3 |
| Dépendance à une personne | 2 | 2 | 3 | 3 |
| Stabilité des règles | 3 | 1 | 3 | 2 |
| Exceptions | 2 | 1 | 2 | 2 |
| Risque en cas d’erreur | 2 | 2 | 3 | 2 |
| Accès aux données | 3 | 2 | 2 | 2 |
| Lecture | Candidat solide | Écarté pour l’instant | Premier choix | Écarté comme premier projet |
Le choix des devis est écarté parce que l’arbitrage repose sur du jugement et sur une relation fournisseur difficile à formaliser : on peut automatiser la mise en forme comparative des offres plus tard, pas la décision. Le budget annuel coûte beaucoup de temps qualifié, mais il n’a lieu qu’une fois par an : le système serait peu testé et le résultat ne serait mesurable qu’un an après.
Entre les deux candidats restants, le rapprochement des factures l’emporte ici parce que l’erreur est rattrapable avant le paiement (le système signale les écarts, un humain valide) et que les règles de tolérance sont déjà connues du service. La saisie des commandes reste un très bon deuxième projet. Dans une autre entreprise, avec d’autres notes, l’ordre serait inversé : c’est tout l’intérêt de noter vos propres candidats plutôt que de copier une liste.
Les processus à éviter en premier
Certains processus sont de bons sujets à terme, mais de mauvais premiers projets.
- Les processus trop instables. Une réorganisation en cours, un changement d’ERP prévu dans six mois, des règles redéfinies à chaque trimestre : il vaut mieux attendre que le terrain se stabilise, ou commencer par formaliser le processus sans l’automatiser.
- Les processus trop rares. Un traitement annuel ou exceptionnel donne peu de cas pour tester et ne permet pas de mesurer vite. Le temps de formalisation n’est pas amorti.
- Les processus trop politiques. Quand le processus arbitre entre des services, touche à la répartition des budgets ou fait l’objet d’un désaccord sur « la bonne façon de faire », l’automatisation ne tranchera pas ce désaccord. Elle le déplacera dans le projet.
- Les processus dont les données sont inaccessibles. Données dans des boîtes e-mail personnelles, outil fermé sans export, droits d’accès impossibles à obtenir : le projet s’enlisera dans l’accès avant d’avoir produit quoi que ce soit.
- Les processus où l’erreur est grave et immédiate. Paiements, déclarations, engagements contractuels : on peut les outiller, mais pas comme première expérience, et jamais sans validation humaine avant l’effet.
Il existe aussi des cas où l’automatisation sur mesure n’est pas la bonne réponse. Si votre ERP ou votre logiciel métier propose déjà la fonction dont vous avez besoin, commencez par l’activer et la paramétrer. Si aucun de vos candidats ne passe la grille, le premier chantier n’est probablement pas technique : il consiste à stabiliser le processus ou à remettre de l’ordre dans les données.
Rendre le premier projet mesurable dès le départ
Une fois le candidat choisi, fixez le point de départ avant de construire quoi que ce soit. Trois questions suffisent souvent :
- Combien de temps ce processus consomme-t-il aujourd’hui, et par qui ? Une estimation honnête sur quelques semaines vaut mieux qu’un chiffre rond donné de mémoire.
- Quel délai ou quelle qualité voulez-vous améliorer ? Délai de confirmation d’une commande, nombre de factures bloquées, nombre de reprises manuelles.
- Qui validera le résultat, et sur quelle période ? Un indicateur n’a de valeur que si quelqu’un s’engage à le regarder.
L’article sur la mesure du résultat d’une automatisation détaille comment choisir l’indicateur, la période de mesure et les effets secondaires à surveiller. Pour estimer l’effort à mettre en face de la valeur attendue, voyez aussi ce qui fait varier le coût de l’automatisation d’un processus métier.
Quand les candidats restent difficiles à départager
Si la grille donne un gagnant clair et que le processus est simple, un premier échange suffit souvent pour passer à un devis. Si plusieurs candidats restent au coude-à-coude, si personne ne sait vraiment combien de temps ils coûtent, ou si les outils en jeu sont mal connus, une cartographie de processus permet d’observer le travail réel, de noter les candidats sur des faits et de définir le périmètre du premier projet avant de l’engager.