Cartographier un système métier avant d'automatiser

Beaucoup d'équipes arrivent avec une liste de problèmes : "notre pricing est manuel", "on perd du temps à consolider des données", "personne ne sait qui fait quoi". Le problème, ce n'est pas le manque de solutions disponibles. C'est qu'on passe directement de la liste de problèmes au choix d'outil, en sautant l'étape qui rend tout le reste cohérent : cartographier le système métier tel qu'il est, puis définir ce qu'il doit devenir.

Sans cette cartographie, vous automatisez du chaos. Vous le rendez juste plus rapide.

Pourquoi cartographier un système métier avant d'automatiser

La cartographie n'est pas une formalité de consultant. C'est le seul moyen de savoir ce que vous construisez vraiment avant de dépenser du temps et de l'argent à le construire.

Quand on démarre sans plan clair, trois choses arrivent systématiquement :

• On automatise des étapes qui auraient dû être supprimées, pas accélérées
• On découvre les dépendances critiques en cours de build, ce qui force des allers-retours coûteux
• On livre un outil que personne n'adopte parce qu'il ne colle pas aux vrais flux de travail

L'article sur les erreurs classiques à éviter quand on automatise avec l'IA recense exactement ces mêmes pièges, terrain après terrain. La cartographie en amont est la réponse structurelle à presque tous.

La phase Map : ce qu'elle contient concrètement

Chez Lucid-Lab, on appelle cette phase la "Map". Elle précède systématiquement toute décision d'architecture ou de développement. Elle se décompose en trois livrables distincts.

1. Le diagramme état actuel (As-Is)

L'objectif est simple : mettre à plat ce qui existe, sans jugement, sans correction immédiate.

On documente :

• Les acteurs impliqués (humains, outils, systèmes tiers)
• Les flux de données : qui produit quoi, où ça va, sous quel format
• Les points de décision : qui valide, sur quelle base, avec quel délai
• Les frictions visibles : saisies manuelles, doublons, boucles email, étapes bloquantes

Le diagramme As-Is ne cherche pas à être beau. Il cherche à être honnête. Si le pricing d'un client se fait via un fichier Excel partagé sur un drive, avec trois versions nommées "final", "final2" et "finalV3", c'est ça qu'on dessine.

Exemple concret : un dashboard de pricing

Un client dans le secteur des services B2B nous arrive avec ce constat : "notre pricing prend deux heures par semaine et on fait des erreurs". En faisant le diagramme As-Is, on découvre six étapes :

1. Export manuel depuis le CRM (CSV, chaque lundi)
2. Copier-coller dans un tableur de calcul des marges
3. Validation par le directeur commercial par email
4. Re-saisie dans l'outil de devis
5. Envoi du devis au client
6. Mise à jour manuelle du CRM avec le montant validé

Six étapes, quatre outils distincts, deux points de validation humaine, zéro traçabilité automatique. Le problème n'est pas "on n'a pas de dashboard". Le problème est que le système entier repose sur des transferts manuels entre des silos.

2. Le diagramme état cible (To-Be)

L'état cible, c'est la version du système que vous voulez mettre en production. Pas la version idéale théorique dans 5 ans. La version réaliste, déployable dans 8 à 12 semaines, qui résout les frictions identifiées.

Pour chaque étape du As-Is, on pose trois questions :

• Cette étape doit-elle exister dans la version cible ?
• Si oui, peut-elle être automatisée ? Partiellement ou totalement ?
• Quelles intégrations sont nécessaires pour ça ?

Sur le cas pricing ci-dessus, l'état cible ressemble à ça :

Résultat attendu : deux heures par semaine deviennent 15 minutes de validation humaine, avec une traçabilité complète de chaque décision de prix. Pour aller plus loin sur la méthode de calcul du ROI associé, l'article sur comment évaluer le retour sur investissement d'un projet d'automatisation donne un framework directement applicable.

3. Les intégrations clés et le chemin critique

Une fois le To-Be dessiné, on identifie les intégrations indispensables. Pas toutes les connexions possibles : celles sans lesquelles le système ne peut pas fonctionner.

Sur l'exemple pricing, les intégrations critiques sont :

• CRM : lecture des données prospect/client, écriture du montant validé
• Outil de devis : génération et envoi
• Source des données de coûts (ERP ou tableur de référence)

Le chemin critique, c'est la séquence d'intégrations qui conditionne tout le reste. Si le CRM n'expose pas d'API propre, ou si les données de coûts sont dans un format non structuré, tout le reste bloque. Identifier ça en semaine 1 évite de le découvrir en semaine 6.

C'est précisément pour ça que le livrable d'une Roadmap d'Exécution Lucid-Lab inclut systématiquement une cartographie des intégrations avant tout engagement de développement.

Comment transformer la carte en jalons exécutables

La cartographie seule ne suffit pas. Elle doit se traduire en séquence de livraison. Voici comment on structure les jalons sur un projet type de 10 semaines :

Semaines 1-2 : Phase Map Entretiens, diagrammes As-Is et To-Be, identification des intégrations critiques, validation avec les parties prenantes.

Semaines 3-4 : Mise en place des fondations Connexion aux sources de données, vérification de la qualité des données existantes, environnement de développement.

Semaines 5-7 : Build du coeur fonctionnel Logique métier principale, règles de pricing ou de traitement, interface de validation humaine.

Semaines 8-9 : Intégrations et tests Connexion aux outils cibles, tests avec données réelles, ajustements des règles métier.

Semaine 10 : Déploiement et transfert Mise en production, formation des utilisateurs, documentation des règles de maintenance.

Ce qui rend cette séquence réaliste, c'est la cartographie initiale. Sans elle, chaque semaine contient des surprises. Avec elle, les surprises arrivent pendant la phase Map, quand elles coûtent une heure de discussion plutôt qu'une semaine de refactoring.

Ce que la cartographie révèle que vous n'attendez pas

Sur trois projets sur cinq, la phase Map révèle au moins une chose que le client n'avait pas anticipée. Les plus fréquentes :

• Une étape entière à supprimer : souvent une validation intermédiaire qui n'apporte plus de valeur mais que personne n'a remise en question
• Une dépendance bloquante : un outil tiers qui n'a pas d'API, ou une donnée qui n'existe pas en format utilisable
• Un périmètre trop large : le "dashboard de pricing" était en réalité trois problèmes distincts, et on ne peut pas tout traiter en même temps

Dans le cas du projet Périscope, le monitoring qu'on a construit s'appuyait sur une phase Map qui avait identifié trois sources de données hétérogènes. Sans cartographier ce point précis, le build aurait démarré sur une architecture qui n'aurait pas tenu à l'échelle.

La cartographie n'est pas un ralentisseur. C'est ce qui permet de démarrer le build avec confiance plutôt qu'avec des hypothèses non vérifiées.

Conclusion

Un plan d'action IA solide commence toujours par une image claire de ce qui existe, de ce qu'on veut construire, et de ce qui dépend de quoi. Sans ces trois éléments documentés, vous démarrez un projet avec des inconnues que vous paierez plus tard, à un coût bien supérieur.

Si vous avez une liste de problèmes opérationnels et que vous voulez savoir ce que donnerait une cartographie concrète de votre système, c'est exactement ce qu'on fait lors d'un premier échange de diagnostic avec les équipes Lucid-Lab.

Questions fréquentes

Combien de temps prend la cartographie d'un système métier avant d'automatiser ? Pour un système métier de complexité moyenne (3 à 6 acteurs, 4 à 8 outils impliqués), la phase Map prend entre 5 et 10 jours ouvrés. Cela inclut les entretiens avec les parties prenantes, la production des diagrammes As-Is et To-Be, et la validation des choix d'architecture avec le client. Ce délai est incompressible : aller plus vite sur cette phase, c'est déplacer les problèmes vers le build.

Peut-on cartographier un processus métier sans compétences techniques ? La description du système existant (As-Is) peut être faite par des opérationnels non techniques, à condition d'avoir une méthode structurée. La définition de l'état cible (To-Be) et l'identification des intégrations critiques nécessitent en revanche une expertise technique pour évaluer la faisabilité et les contraintes réelles. C'est pourquoi la phase Map est idéalement menée en binôme : un expert métier et un architecte ou ingénieur.

Cartographier un système métier, c'est différent du process mapping ? Le process mapping documente les étapes d'un flux de travail humain. La cartographie d'un système métier est plus large : elle inclut les flux de données entre outils, les dépendances techniques, les points d'intégration, et la logique de décision. Pour un projet d'automatisation, le process mapping seul ne suffit pas, parce qu'il ne capture pas les contraintes systèmes qui conditionneront l'architecture.

Que se passe-t-il si on démarre le développement sans cartographie ? Les équipes qui démarrent le build sans cartographie préalable rencontrent systématiquement les mêmes problèmes : des intégrations bloquantes découvertes en cours de route, des allers-retours sur le périmètre fonctionnel, et des livraisons qui ne correspondent pas aux vrais besoins métier. En pratique, l'absence de cartographie rallonge les projets de 30 à 60% par rapport à l'estimation initiale, selon notre retour d'expérience sur des missions comparables.