« On a automatisé cette tâche. On gagne 20 heures par mois. »
Sur le papier, c’est une réussite.
Mais une question est rarement posée : pourquoi cette tâche existe-t-elle encore ?
L’automatisation des processus est souvent abordée par le gain de temps, le ROI ou la réduction des erreurs. J’ai voulu partir de l’autre côté : comprendre pourquoi des entreprises capables d’investir dans un ERP, un workflow, une RPA, du low-code ou de l’IA peuvent automatiser des étapes qu’elles auraient peut-être dû supprimer, simplifier ou repenser.
La réponse facile serait : elles ne prennent pas assez de recul.
La réalité est plus intéressante.
1. Chaque décision locale peut être parfaitement rationnelle
Une équipe finance perd du temps sur un contrôle. Elle l’automatise.
Le commerce ressaisit des informations. Il crée un workflow.
La logistique gère une exception récurrente. Elle développe une règle.
Chaque décision peut produire un vrai gain.
Le problème apparaît lorsqu’on regarde le flux complet.
Une optimisation locale peut créer une nouvelle interface, une dépendance, une exception ou une règle que les autres fonctions devront désormais respecter.
On peut donc construire progressivement une organisation globalement complexe avec une succession de décisions localement rationnelles.
Le principal risque de l’automatisation n’est pas d’accélérer un mauvais processus. Il est de rendre durable une optimisation locale sans avoir revalidé la contrainte ni le flux de bout en bout.
2. « C’est notre particularité »
C’est une phrase que l’on entend souvent lorsqu’on challenge un processus.
« Chez nous, ça fonctionne comme ça. »
« Notre métier est particulier. »
« On a toujours eu besoin de cette validation. »
Et parfois, c’est parfaitement vrai.
Une spécificité peut protéger un avantage métier, une obligation réglementaire, un risque ou une qualité de service essentielle.
Mais une particularité peut aussi être une solution créée dix ans plus tôt pour répondre à une contrainte qui n’existe plus.
Le problème n’est donc pas la spécificité. Il commence lorsque personne n’est capable de relier la règle actuelle à une contrainte actuelle.
Une solution peut survivre au problème qu’elle avait été créée pour résoudre.
3. L’automatisation peut rendre le problème moins visible
Un processus manuel inutile fait mal.
Il consomme du temps. Les équipes se plaignent. Les erreurs sont visibles.
Cette douleur crée une pression pour agir.
Puis on automatise.
Le coût visible chute. La plainte disparaît. Le processus devient supportable.
Mais sa raison d’être n’a pas nécessairement été revalidée. L’automatisation peut alors supprimer le symptôme qui poussait l’organisation à remettre la règle en question.
Ce mécanisme n’est pas systématique. Automatiser un processus imparfait peut être parfaitement rationnel : pour absorber une urgence, apprendre, révéler les exceptions ou produire les données nécessaires à une transformation plus profonde.
Le problème apparaît lorsque cette étape provisoire devient la solution définitive sans que personne ne repose la question.
Une automatisation n’est donc pas nécessairement une fin. Elle peut être une décision de transition qui devra être revalidée.
4. Le problème est souvent dans les frontières entre silos
La plupart des organisations sont structurées par fonctions.
Les processus, eux, traversent ces fonctions.
Une commande peut traverser commerce, finance, approvisionnement, logistique, service client et SI.
Chaque fonction connaît très bien son morceau.
Mais qui possède réellement le flux complet ?
C’est là qu’apparaît le paradoxe. La friction est locale. Le sponsor est local. Le budget est souvent local. L’outil aussi.
Supprimer ou redessiner la règle demande au contraire d’aligner plusieurs fonctions, de redistribuer des responsabilités, d’assumer des risques et parfois de remettre en cause des territoires établis.
Automatiser demande un budget. Supprimer demande du pouvoir.
Une automatisation peut ainsi améliorer un silo tout en rendant plus difficile la transformation future du flux complet.
5. Comment une bonne décision devient l’héritage de demain
Le mécanisme se répète souvent de manière presque invisible.
- Une contrainte réelle apparaît.
- Une fonction crée une règle, un contrôle ou une étape pour y répondre.
- L’organisation évolue. La contrainte change, mais la solution reste.
- Une friction locale devient visible.
- Un workflow, un ERP, une RPA, une Power App ou une automatisation IA réduit cette friction.
- La douleur diminue, mais la règle est désormais davantage encodée dans le système.
- Quelques années plus tard, cette solution devient l’héritage de la transformation suivante.
Ce qui était une bonne réponse locale à une contrainte d’hier peut devenir l’infrastructure invisible d’un problème global demain.
Le problème n’est donc pas nécessairement une mauvaise décision. C’est l’absence de revalidation lorsque le contexte change.
6. Faut-il alors tout cartographier ?
Probablement pas.
Pour une PME ou une ETI, maintenir une modélisation détaillée de tous les processus risque rapidement de devenir un projet en soi. Et une carte qui n’évolue plus finit par décrire l’organisation d’hier.
Une approche plus légère paraît plus réaliste : conserver une architecture simple des grands flux, identifier qui en porte la responsabilité, approfondir les processus critiques au moment d’une transformation importante et confronter le processus déclaré au processus réellement exécuté lorsque les données le permettent.
L’objectif n’est pas de tout connaître en permanence.
C’est d’être capable de reconstruire suffisamment le système avant une décision qui va le figer pour plusieurs années.
7. Cinq questions avant d’automatiser
Avant un workflow, une personnalisation ERP, une RPA, une Power App ou une automatisation IA, cinq questions suffisent souvent à introduire le doute nécessaire.
- Pourquoi ça existe ? Quelle contrainte, quel risque ou quelle valeur justifie encore cette étape aujourd’hui ?
- Qu’est-ce qui casse si on l’enlève ? Rien, ou déplace-t-on simplement le travail ailleurs ?
- Est-ce local ou transverse ? L’amélioration de cette étape améliore-t-elle réellement le flux complet ?
- Peut-on faire plus simple ? Supprimer, simplifier ou standardiser avant de choisir l’automatisation — sans en faire un dogme.
- Quand le revalide-t-on ? Qu’est-ce qui nous dira demain que cette automatisation n’a plus besoin d’exister ?
La sortie doit être une décision explicite : supprimer, simplifier, standardiser, automatiser ou conserver.
8. Ce que cela change pour une PME ou une ETI
L’enjeu n’est pas de lancer un grand programme BPM.
Il est d’introduire un moment de doute avant de transformer une règle métier en code.
Lorsqu’un projet promet 100 heures économisées, le ROI ne devrait pas être la première conclusion. Il devrait déclencher une question supplémentaire : ces 100 heures correspondent-elles à un travail nécessaire ?
Lorsqu’un métier demande de reproduire une particularité dans un nouvel ERP : quelle contrainte actuelle justifie cette particularité ?
Lorsqu’une Power App ou une automatisation résout une friction locale : qu’ajoute-t-elle au flux global ?
Et lorsqu’une automatisation fonctionne parfaitement depuis trois ans : qui a la responsabilité de demander si elle doit encore exister ?
Conclusion
L’automatisation est souvent présentée comme une manière de retirer du travail.
Elle peut aussi rendre extrêmement efficace la conservation du passé.
La question n’est donc pas seulement : « Peut-on automatiser ce processus ? »
Mais : « Quelle contrainte actuelle justifie encore son existence — et à quel niveau du système sommes-nous en train de résoudre le problème ? »
Une bonne automatisation ne devrait pas seulement avoir un ROI.
Elle devrait avoir une raison d’exister aujourd’hui — et un moment prévu pour vérifier qu’elle en aura encore une demain.
Sources et repères
Cette enquête s’appuie notamment sur les travaux et méthodes liés au Lean et au Value Stream Mapping, au Business Process Management et au process ownership, au Business Process Reengineering, à la sélection de processus RPA, au process mining et à la gouvernance low-code.
Enquête #02 — Laboratoire de la décision.
