Avant d'automatiser, normalisez : pourquoi la V0 ne doit rien automatiser
La plupart des projets d'automatisation échouent parce qu'on saute l'étape de normalisation. La V0, c'est zéro automatisation — c'est construire la fondation qui rend l'automatisation possible.
Donatien Lefranc
Fondateur & Président, Leando
55 tâches. Zéro automatisation en V0.
Une organisation dans le secteur de l'énergie demande un projet de digitalisation de son back-office. Le périmètre est précis : tout ce qui concerne la vie des contrats clients, depuis les demandes de raccordement jusqu'au suivi des interventions en cours. En cataloguant les activités opérationnelles, on arrive à 55 types de tâches différentes. Des tâches de quelques minutes, d'autres de plusieurs jours. Des tâches solo, d'autres qui impliquent trois équipes. Des flux standard et des cas particuliers qui n'ont pas de procédure écrite.
La demande initiale est claire : automatiser. Moins de saisie manuelle, moins de mails de coordination, moins de risques d'oubli. La décision prise avant de toucher au moindre outil : la V0 n'automatise rien. Elle centralise.
Ce n'est pas une décision de confort. C'est une décision d'efficacité. Automatiser 55 types de tâches hétérogènes sans les avoir d'abord normalisées, c'est construire sur du sable. Les premières semaines fonctionnent sur les cas préparés. Ensuite arrivent les exceptions, les cas limites, les situations que personne n'avait anticipées. Et chaque exception force soit une intervention manuelle, soit une modification du code, soit les deux.
La tentation de l'interface sur mesure pour chaque cas
Quand on présente 55 types de tâches à un product designer, la réponse naturelle est de concevoir une interface adaptée à chaque cas. Une vue pour les demandes de raccordement, une autre pour les résiliations, une autre pour les interventions techniques, une autre pour les réclamations. Chacune avec ses champs spécifiques, son workflow propre, sa logique de statuts.
Cette approche produit un projet ingérable. Cinquante-cinq interfaces à concevoir, à développer, à tester, à maintenir. Cinquante-cinq logiques de workflow à documenter. Et au moment où une tâche change de nature en cours de route — ce qui arrive constamment dans un back-office opérationnel — il faut modifier l'interface correspondante, migrer les données, re-former les équipes.
La bonne question n'est pas : « Comment je conçois une interface pour chaque type de tâche ? » Elle est : « Quelle est la structure commune à toutes ces tâches ? »
« Face à un backlog de 55 tâches hétérogènes, ne cherche pas à concevoir 55 interfaces différentes — cherche le système commun sous-jacent. La complexité apparente masque souvent une structure répétable : inputs, trigger, outputs. »
Dans ce projet, la structure commune est apparue rapidement : toutes les tâches ont un déclencheur (une demande entrante, un événement calendaire, un état atteint par un contrat), des données d'entrée (informations client, contexte contrat, paramètres de la demande) et un résultat attendu (action réalisée, statut mis à jour, communication envoyée). La différence entre les 55 types n'est pas structurelle. Elle est dans les valeurs — les types de données, les étapes intermédiaires, les règles métier spécifiques à chaque cas.
Ce que la normalisation manuelle révèle
La V0 est un outil de centralisation manuelle. Les équipes continuent de faire leur travail comme avant, mais elles le tracent dans un endroit commun. Pas d'automatisation, pas de workflow imposé, pas de règles de validation. Juste une vue partagée de ce qui entre, de ce qui est en cours, de ce qui est terminé.
Cette étape révèle ce qu'aucun atelier de recueil de besoins ne fait apparaître. Les vraies transformations de données : qu'est-ce qui entre dans une tâche, sous quelle forme, et qu'est-ce qui en sort ? Les cas limites récurrents : les situations qui ne rentrent dans aucune case et que les équipes gèrent au cas par cas. La charge cognitive réelle : où les équipes perdent du temps, où elles font des erreurs, où elles cherchent des informations éparpillées.
« Avant d'automatiser un processus, construis d'abord la couche de normalisation humaine. Les tâches manuelles standardisées révèlent les transformations de données nécessaires et les cas limites — c'est cette matière qui rend l'automatisation possible, pas l'inverse. »
Un autre point que la V0 révèle : la différence entre les équipes qui planifient et les équipes qui réagissent. Un consultant crée son agenda le matin — il sait à l'avance ce qu'il va faire dans la journée. Un gestionnaire opérationnel le subit toute la journée — les demandes arrivent en flux continu et viennent perturber les tâches prévues. Ces deux modes de travail ne demandent pas la même interface, pas la même logique de workflow, pas les mêmes automatisations. La V0 fait apparaître cette distinction avant qu'elle ne devienne un problème de conception coûteux.
Enfin, la V0 réduit immédiatement la charge cognitive des équipes, même sans automatisation. Quand les tâches sont centralisées et visibles, les managers passent moins de temps à demander où en est tel dossier. Les équipes passent moins de temps à chercher le dernier échange sur une demande particulière. Ce gain concret, même avant la moindre automatisation, est ce qui fait que les équipes utilisent la V0 — et donc la font vivre jusqu'à la V0.5.
V0 → V0.5 → automatisation : pourquoi l'ordre est non-négociable
La progression en trois étapes n'est pas une convention arbitraire. Chaque étape prépare la suivante de façon concrète.
La V0 (centralisation) produit les données réelles du processus : les vrais volumes, les vraies durées, les vraies distributions de cas. Sans ces données, les choix de V0.5 sont des hypothèses. Avec ces données, ce sont des décisions.
La V0.5 (workflow) structure le processus normalisé : les étapes sont définies, les responsabilités sont claires, les règles de transition entre statuts sont explicites. Sans cette structure, les automatisations de la V1 opèrent sur un processus flou. Avec cette structure, elles opèrent sur quelque chose de stable.
L'automatisation complète (V1) remplace les actions manuelles répétitives par des déclencheurs automatiques, des intégrations avec les systèmes tiers, des notifications sans intervention humaine. Elle est fiable parce qu'elle s'appuie sur un processus que deux étapes précédentes ont rendu observable, stable et documenté.
Sauter la V0 pour aller directement à l'automatisation, c'est automatiser un processus qui n'a jamais été observé dans ses conditions réelles. Les résultats sont prévisibles : les cas standards fonctionnent, les exceptions cassent tout, les équipes trouvent des contournements, et six mois plus tard on refait le diagnostic qu'on aurait dû faire au départ.
Comment la V0 accélère paradoxalement le projet
La V0 ressemble à un délai. En réalité, elle compresse l'ensemble du projet.
Sans V0, la conception de la V1 se fait sur des hypothèses. Les premières semaines de développement produisent quelque chose qui couvre les cas préparés. Puis les équipes commencent à utiliser l'outil en conditions réelles et font remonter les cas non couverts. Chaque retour implique une modification de la conception, un ajustement du code, un re-test, une redéployement. Ce cycle de correction est coûteux en temps et en énergie — pour les développeurs, pour les équipes produit, et pour les utilisateurs qui perdent confiance dans un outil qui change constamment.
Avec V0, les cas réels sont connus avant la conception de la V0.5. Les modifications de conception se font sur du papier, pas sur du code. Le développement de la V0.5 puis de la V1 s'appuie sur une base stable. Les corrections post-lancement sont rares parce que les cas limites ont déjà été traités dans les étapes précédentes.
« Quand un dirigeant demande de l'automatisation, commence par réduire la friction de l'exécution manuelle. L'outil de suivi bien conçu révèle ce qui mérite vraiment d'être automatisé — et soulage immédiatement la charge cognitive. »
Il y a aussi un effet sur la relation avec les équipes. Quand la V0 leur simplifie quelque chose de concret dès les premières semaines, elles deviennent parties prenantes du projet. Elles signalent les problèmes, elles proposent des ajustements, elles anticipent ce dont elles auront besoin en V0.5. C'est l'opposé d'un outil imposé que personne n'utilise et que tout le monde contourne discrètement.
La V0 n'est pas une étape de plus. C'est l'étape qui fait tenir toutes les autres.
Ça dépend de la complexité des processus, pas du volume. Pour une organisation avec une dizaine de types de tâches bien définis, une V0 utile peut tenir en trois à quatre semaines. Pour des organisations avec 40 ou 50 types de tâches hétérogènes, comptez plutôt six à huit semaines. L'objectif de la V0 n'est pas d'être exhaustive, mais de centraliser suffisamment pour que les équipes commencent à travailler d'une façon homogène — ce qui révèle les patterns et les cas limites à couvrir en V0.5 avant l'automatisation.
Votre projet d'automatisation démarre par une question simple.
Qu'est-ce qui doit d'abord être normalisé ? On peut répondre à cette question ensemble avant de toucher au moindre outil.
Cadrer mon projet d'automatisation