Le réflexe est presque universel : dès qu'une tâche est perçue comme répétitive, quelqu'un dans l'organisation suggère de l'automatiser. C'est compréhensible. Mais cette précipitation conduit souvent à automatiser des processus mal conçus, à accélérer des dysfonctionnements existants, ou à investir dans des outils qui ne seront jamais vraiment adoptés.
Avant de toucher à un seul outil d'automatisation, il faut passer par une étape que beaucoup sautent : comprendre ce qui se passe réellement.
1. Cartographier avant d'automatiser
Un audit de processus commence par une question simple : comment ça marche vraiment ? Pas comment ça devrait marcher selon la procédure officielle, mais comment les équipes le font concrètement, au quotidien, avec leurs contournements, leurs raccourcis et leurs compensations informelles.
Pour cartographier efficacement un processus, je travaille en trois temps :
- L'observation directe — shadowing des équipes opérationnelles, pas de réunions de cadrage.
- Les entretiens ciblés — on pose la question à ceux qui exécutent, pas seulement à ceux qui supervisent.
- La modélisation par flux — chaque étape, chaque acteur, chaque point de décision est mis à plat sur un schéma lisible.
Cette cartographie révèle presque toujours des surprises : des étapes fantômes qui existent depuis des années sans que personne n'en connaisse l'origine, des doubles saisies dues à une incompatibilité entre deux outils, des validations intermédiaires devenues inutiles après une réorganisation.
Lors d'un audit organisationnel à la Commune Urbaine d'Antananarivo, la cartographie des circuits de traitement des demandes a révélé que certains documents transitaient par 7 services différents pour une décision qui relevait d'un seul. L'automatisation sans cette étape préalable aurait simplement accéléré un circuit inefficace.
2. Qualifier les tâches : valeur ajoutée ou charge administrative ?
Une fois le processus cartographié, chaque tâche doit être qualifiée. Je distingue trois catégories :
- Tâches à valeur ajoutée — elles produisent un résultat utile pour le client ou l'organisation. Ce sont elles qu'on veut protéger et faciliter.
- Tâches de contrôle nécessaires — elles assurent la conformité, la traçabilité, la qualité. Elles sont contraignantes mais justifiées.
- Tâches sans valeur ajoutée — ressaisie d'informations déjà disponibles ailleurs, validations purement formelles, rapports que personne ne lit. Ce sont les premières candidates à l'élimination ou à l'automatisation.
Cette classification demande de l'honnêteté organisationnelle. Certaines tâches sans valeur existent parce qu'elles correspondent au périmètre d'un poste ou à une habitude héritée d'une contrainte disparue. Les identifier nécessite du tact, mais aussi de la rigueur.
3. Prioriser par le produit : fréquence × pénibilité × risque d'erreur
Toutes les tâches identifiées comme automatisables ne méritent pas le même niveau d'investissement. Pour prioriser, j'applique un critère simple :
Priorité = Fréquence × Pénibilité × Risque d'erreur
Une tâche qui se répète 50 fois par jour, mobilise 20 minutes à chaque occurrence et génère régulièrement des erreurs de ressaisie est une cible prioritaire. Une tâche mensuelle de 5 minutes peut attendre.
Ce calcul évite de tomber dans le piège des automatisations spectaculaires mais peu impactantes — celles qui font une belle démonstration mais ne libèrent personne.
4. Quand ne pas automatiser
L'automatisation n'est pas la réponse à tout. Il y a des situations où elle est contre-productive :
- Quand le processus est encore instable — automatiser un processus en cours de redéfinition est une perte d'investissement.
- Quand la variabilité est trop forte — certaines situations requièrent un jugement humain que les règles métier ne peuvent pas capturer.
- Quand le volume est trop faible — le coût de conception et de maintenance d'une automatisation doit être rapporté au gain réel dans le temps.
- Quand l'organisation n'est pas prête — une automatisation rejetée par les équipes ne sera pas utilisée, aussi bien conçue soit-elle.
5. L'automatisation comme résultat, pas comme objectif
Ce qui distingue une automatisation réussie d'un projet technique qui finit dans un tiroir, c'est la façon dont on a formulé le problème au départ.
Si le point de départ est "on veut automatiser X", on part de la solution. Si le point de départ est "on perd trop de temps sur X, comment réduire ça ?", on part du problème — et la réponse pourrait être une automatisation, une simplification du processus, ou une clarification des responsabilités.
L'audit de processus sert précisément à s'assurer qu'on répond au bon problème, avec le bon niveau d'intervention, au bon moment.
C'est cette discipline — comprendre avant d'agir — qui fait la différence entre une transformation digitale qui tient dans le temps et un empilement d'outils qui crée plus de complexité qu'il n'en résout.
Anjarahasina Raobelina
Consultant en digitalisation