L’automatisation est souvent vendue comme une évidence : moins de tâches répétitives, plus de valeur, moins d’erreurs. Sur le papier, c’est du bon sens. Mais sur le terrain, la réalité est souvent différente : des projets plus longs que prévu, des coûts qui explosent, du stress, des utilisateurs frustrés et des équipes qui s’épuisent.
Le problème ? Ce n’est presque jamais la technologie. Derrière la promesse de fluidité se cachent des pièges liés à la conception et aux décisions prises en amont. Et au cœur de tout : l’oubli de la question la plus simple qui soit. Pour qui ? Pour quoi faire ?
1. Pourquoi l'automatisation échoue souvent dès le début
Un projet d’automatisation échoue rarement à cause d’un bug ou d’un mauvais outil. Le problème prend racine bien avant : dans la phase de conception. Et plus précisément, dans l’absence de réponse à une question fondamentale : quelle valeur cela apporte-t-il à ceux qui vivent ce processus au quotidien ?
1.1 On automatise sans comprendre l'usage réel
Vouloir automatiser sans avoir observé, questionné, compris en profondeur comment les gens font vraiment leur travail, c’est multiplier les points de défaillance.
Ce n’est pas parce qu’un processus est documenté qu’il est compris. Les documentations décrivent ce qui devrait se passer. Les utilisateurs, eux, décrivent ce qui se passe vraiment : les contournements, les étapes inutiles héritées du passé, les frustrations silencieuses.
Les conséquences d’un déficit de compréhension des usages sont immédiates : une phase d’étude interminable, des cas critiques découverts trop tard, des surprises en production et, au final, un processus partiellement automatisé, livré en retard, et plus cher que prévu.
1.2 On cherche à tout automatiser d'un coup
Vouloir automatiser tout, en une fois, c’est séduisant… mais dangereux. Plus le périmètre est large, plus la complexité explose, les dépendances s’accumulent, et les risques augmentent. Et finalement, c’est tout le projet qui ralentit, voire bloque. Et souvent aucun utilisateur ne reçoit de valeur concrète avant des mois.
2. Ce que l'expérience nous apprend
2.1 Investir dans la Discovery, vraiment
La Discovery n’est pas une case à cocher avant de « passer en dev ». C’est le travail le plus important du projet.
L’objectif est de comprendre :
- Qui vit ce processus au quotidien, et dans quelles conditions réelles ?
- Quels problèmes ce processus leur crée-t-il ? Temps perdu, erreurs, frustration, manque de visibilité ?
- Quel serait le signal concret que l’automatisation a amélioré leur situation ?
Cela implique des référents métiers impliqués dès le premier jour, pas comme valideurs en fin de sprint, mais comme co-concepteurs. Ce sont eux qui permettent d’éviter de « survoler » le sujet fonctionnellement. Ils deviennent les ambassadeurs du projet parce qu’ils y ont contribué. L’adoption finale est beaucoup plus fluide.
2.2 Prioriser par impact utilisateur, pas par complexité technique
Faut-il traiter un processus complexe qui arrive rarement, mais dont chaque occurrence est critique pour l’utilisateur ? Ou s’attaquer à un processus fréquent, source de friction quotidienne, même si le gain unitaire paraît faible ?
Cette question n’est pas qu’une question de ROI financier. C’est une question de valeur perçue par ceux qui utilisent le processus.
Les données aident à sortir des intuitions :
- « Peu » ou « fréquent » se traduit par des volumes réels
- « Facile » ou « complexe » se traduit par des durées et des taux d’erreur
- « Important » se traduit par l’impact sur l’expérience utilisateur et sur les objectifs métier
À partir de là, ce n’est plus une intuition : c’est une décision stratégique éclairée, pas seulement une optimisation de charge technique.
2.3 Piloter par les outcomes, pas par les livrables
Automatiser sans objectif clair sur la valeur attendue, c’est comme livrer un produit sans savoir à quoi il sert.
La vraie question n’est pas « avons-nous livré l’automatisation ? » mais : est-ce que les utilisateurs vivent mieux ce processus qu’avant ?
Définissez des outcomes clairs avant de commencer :
- Le temps de traitement pour l’utilisateur final a-t-il diminué ?
- Le taux d’erreurs humaines a-t-il baissé ?
- Le niveau de frustration exprimé par les équipes terrain a-t-il évolué ?
Ces outcomes orientent les décisions tout au long du projet : à 40 % d’automatisation, si la valeur est déjà là pour l’utilisateur, il peut être contre-productif de viser 100 % si la complexité explose. Une automatisation doit être utile avant d’être parfaite.
Transformez ces outcomes en KPIs de suivi accessibles en continu. Une automatisation évolue, dérive, se dégrade parfois. Elle doit être pilotée comme n’importe quel produit vivant.
2.4 Découper pour livrer de la valeur tôt
Livrer brique par brique, c’est autant un principe d’agilité qu’un principe de valeur produit : chaque incrément doit apporter quelque chose de concret et mesurable à ceux qui l’utilisent.
Cela implique d’assumer en toute transparence avec le métier et les développeurs :
- Des étapes temporaires (parfois manuelles)
- Des solutions transitoires
- Une dette technique ou organisationnelle à maîtriser
Ce n’est pas un aveu d’échec. C’est une stratégie de livraison de valeur progressive, qui sécurise l’investissement et réduit le risque.
3. Les pièges de conception
3.1 Reproduire les défauts existants
On fait souvent bien le travail de documentation (customer journey, user flow…). Mais cette documentation n’explique pas toujours pourquoi ça existe.
Si on s’arrête là et qu’on reproduit à l’identique, on n’automatise pas un processus : on automatise des habitudes, avec tous leurs défauts.
Or, derrière chaque étape, il y a une raison. Encore faut-il vérifier qu’elle a toujours une utilité pour l’utilisateur aujourd’hui.
Exemple : un accusé de réception manuel destiné à rassurer un client en attente devient une notification parasite si l’automate répond en 3 secondes. Ce qui était une attention devient une pollution.
Pour chaque étape du processus, posez-vous trois questions :
- Pourquoi existe-t-elle ?
- Quelle valeur apporte-t-elle à l’utilisateur ?
- Que se passe-t-il pour lui si on la supprime ?
3.2 Sous-estimer la place de l'humain
L’automatisation vise souvent à exclure totalement l’humain. C’est une erreur.
Un processus automatisé vit : incidents, évolutions, situations exceptionnelles. Si aucune place n’est prévue pour l’intervention humaine, on finit en mode pompier, avec des développeurs qui déboguent en production sous pression. Les gains attendus côté métier deviennent des pertes côté digital.
C’est ce qu’on appelle le « Human in the loop » : garder un humain capable d’intervenir sans tout casser. Concrètement, le processus doit pouvoir être interrompu, reprendre là où il s’est arrêté, et réintégrer une intervention humaine si nécessaire.
L’objectif n’est pas une automatisation hermétique. C’est un processus résilient, qui reste sous contrôle.
4. Les pièges techniques
4.1 Sous-estimer l'intégration et les dépendances
Un processus automatisé ne vit jamais en vase clos. Il dépend d’autres produits, d’autres équipes, d’autres sources de données. C’est souvent là que ça casse : une évolution d’une source tierce casse votre automatisme, ou pire, dégrade une partie de votre SI.
Le travail d’architecture en amont (« sprint 0 ») n’est pas du luxe. Son objectif : identifier les règles existantes, les flux de données, les impacts en cascade. Sans cela, on finit à bricoler des rustines en production.
Documentez vos décisions d’architecture (ADR, Architecture Decision Records) : pourquoi ce choix, sur quelles hypothèses. Le jour où ça évolue, vous serez content de comprendre le raisonnement d’origine.
4.2 Oublier la volumétrie
Un automate censé faire gagner du temps qui devient plus lent qu’un humain : c’est un classique. Structure non adaptée, volumétrie mal anticipée, montée en charge ignorée. L’automatisation doit absorber la charge, pas devenir le nouveau goulot d’étranglement.
Attention aussi à l’effet inverse : l’excès d’ingénierie. On peut passer un an à anticiper une scalabilité pour des volumes qui n’arriveront peut-être jamais. Trouver le bon équilibre, c’est aussi ça le travail.
4.3 Sacrifier la traçabilité et le monitoring
Sous la pression, les délais, la repriorisation, les « should have » finissent souvent sacrifiés. Parmi eux : la traçabilité et le monitoring.
Ce n’est pas qu’une affaire de beaux tableaux de bord. C’est un enjeu de résilience et de pilotage par la valeur.
Résilience : quand ça casse (et ça cassera), êtes-vous capable de reprendre exactement là où ça s’est arrêté ? Sans traçabilité fine, vous relancez tout, vous créez des doublons, vous faites de la chirurgie SQL en production sous pression.
Pilotage : en production, vous aurez besoin de comprendre ce qui marche, ce qui bloque, ce qui revient souvent. Pas besoin d’un outil complexe. Une table de logs bien structurée peut suffire pour :
- Analyser rapidement un incident
- Comprendre les usages réels des utilisateurs
- Arbitrer les prochaines évolutions en fonction de la valeur produite
Ce ne sont plus des intuitions. C’est du pilotage par les données, au service des utilisateurs.
5. En résumé : les 7 règles d'or
- Commencez par les utilisateurs : observez, questionnez, comprenez les usages réels avant de concevoir quoi que ce soit
- Définissez vos outcomes avant vos outputs : quelle valeur mesurable pour qui ?
- Impliquez les référents métiers dès le premier jour, pas comme valideurs mais comme co-concepteurs
- Priorisez par impact utilisateur, éclairé par les données (volumes, durées, fréquences)
- Découpez pour livrer de la valeur tôt : chaque incrément doit être utile, pas seulement livrable
- Gardez l’humain dans la boucle : un processus résilient est un processus piloté
- Pilotez en continu : une automatisation se dégrade, évolue, dérive. Traitez-la comme un produit vivant
FAQ : L'automatisation des processus
Par où commencer avant de lancer un projet d'automatisatiton ?
Avant tout développement, la première étape est la Discovery : comprendre qui utilise réellement le processus, dans quelles conditions, et quels problèmes concrets il génère. Ce travail d’exploration (entretiens, observations, analyse des usages réels) conditionne la pertinence de toute la suite. Automatiser sans Discovery, c’est souvent automatiser les mauvaises choses, au mauvais endroit.
Comment choisir quel processus automatiser en priorité ?
La priorisation doit s’appuyer sur deux axes : la fréquence d’usage (combien de fois ce processus est-il exécuté ?) et l’impact utilisateur (quel niveau de friction, d’erreur ou de perte de temps génère-t-il ?). Un processus fréquent et source de frustration quotidienne prime sur un processus rare, même s’il semble plus “spectaculaire” à automatiser. Les données (volumes, durées, taux d’erreur) permettent de sortir des intuitions et d’arbitrer objectivement.
Quelle différence entre un output et un outcome dans un projet d'automatisation ?
Un output, c’est ce qui est livré : l’automatisme est en production, le flux tourne. Un outcome, c’est ce qui change pour les utilisateurs : le temps de traitement a diminué, les erreurs ont baissé, la charge mentale des équipes terrain s’est allégée. Piloter par l’outcome, c’est se donner les moyens de vérifier que l’automatisation a réellement créé de la valeur, et pas seulement été livrée.
Pourquoi ne pas tout automatiser d'un coup ?
Un périmètre trop large multiplie les dépendances, allonge les délais et retarde la livraison de valeur. En découpant le projet en incréments, chaque étape peut être testée, validée et ajustée avec les utilisateurs réels. Cette approche réduit le risque, améliore l’adoption et permet de corriger le tir avant d’avoir tout construit.
Qu'est-ce que le "Human in the loop" et pourquoi est-ce important ?
Le “Human in the loop” désigne la capacité à intégrer une intervention humaine dans un processus automatisé, sans tout casser. Un automate rencontre des situations exceptionnelles, des erreurs, des évolutions. Si aucun mécanisme ne permet à un humain de reprendre la main, on se retrouve en mode pompier. Un bon processus automatisé est un processus qui peut être interrompu, repris et supervisé à tout moment.
Comment mesurer le succès d'un projet d'automatisation ?
Le succès se mesure par les outcomes définis avant le lancement : réduction du temps de traitement, baisse du taux d’erreurs, diminution des sollicitations manuelles, amélioration de la satisfaction des équipes concernées. Ces indicateurs doivent être suivis en continu, pas seulement à la mise en production. Une automatisation se dégrade dans le temps : sans monitoring, on ne détecte les problèmes qu’après qu’ils ont impacté les utilisateurs.
Pourquoi impliquer les métiers dès le début d'un projet d'automatisation ?
Les référents métiers sont les seuls à connaître les usages réels : les contournements, les exceptions, les étapes qui n’ont plus de sens. Sans eux, on automatise une vision théorique du processus. Avec eux impliqués dès la Discovery, on réduit les surprises en production, on améliore la pertinence des choix de conception et on facilite l’adoption finale, car ils deviennent des ambassadeurs du projet plutôt que des résistants au changement.
Faut-il automatiser un processus à 100 % ?
Pas nécessairement. Le taux d’automatisation optimal dépend du rapport entre la valeur apportée à l’utilisateur et la complexité à implémenter. Une automatisation à 70 % qui résout les cas les plus fréquents peut déjà apporter l’essentiel de la valeur. Vouloir couvrir les 30 % restants (souvent des cas rares et complexes) peut tripler le coût et le délai pour un gain marginal. Une automatisation doit être utile avant d’être parfaite.
Product Owner
Product Manager
