Client PME santé, 100+ documents manuels / dossier. Cadre réglementaire strict. Voici comment j’ai attaqué le sujet : (no bullshit) 1/ Faire émerger les points de friction invisibles au quotidien Je commence par analyser les documents un par un : 1- Listing des variables à numériser 2- Cartographie des dépendances entre documents Je pose tout sur un Whimsical. → Ça me donne une vision métier claire → Et rapidement, on voit qu’on peut factoriser des éléments communs entre plusieurs docs Résultat, 2 types de docs : - les simples - les complexes ➡️ Toujours commencer par les plus simples. Une intuition de système se dessine : Base de données variables → Injection → Doc généré automatiquement Problème : certains docs ont une logique récursive à +3 niveaux → Donc, il faut tester. Pas juste modéliser. - 2/ Tester le système en conditions réelles (mini-poc) Dans ce genre de contexte, la complexité ne se voit pas sur papier. Sans POC, on découvre les edge cases trop tard! Je découpe le projet en deux blocs : 1. Le moteur de génération 2. L’interface Pour chaque partie, je relève plusieurs critères : - le coût - la performance - la maturité (scalabilité) - la compatibilité avec le SI existant - la complexité → Objectifs : - focus sur la faisabilité dans un 1er temps - proposer une approche itérative pour maximiser le ROI - 3/ Décomposer le problème en briques actionnables Un projet comme celui-ci ne se résout pas “en une fois”. Il faut avancer, étape par étape, brique par brique. 1 brique = un premier ROI pour le client Je décide de découper le projet en 3 briques opérationnelles : 1/ automatiser les documents simples → test sur un échantillon représentatif → dérisquage technique ✅ Gains concrets palpables, visibles par le client 2/ Structurer les documents complexes → logique métier avancée, récursivité, cas tordus → validation terrain sur des vrais cas ✅  ROI le + preuve que le système tient la route 3/ : Plugger une IHM simple → pour améliorer la prise en main par les équipes → rendre le système + accessible et améliorer l’adoption ✅  réduire la friction et fluidifier le process - Vous noterez qu’à aucun moment je ne parle de : - rédiger un cahier des charges ultra-détaillé (que personne ne lit) - proposer de tout basculer sur un “nouvel outil” - démarrer par les documents les plus tordus “parce que c’est intéressant” Chaque problème vient au bon moment. Mon rôle ici n’est pas de rajouter une couche de complexité. C’est de clarifier, tester, et structurer ce qui marche (Je ne rentre pas ici dans le détail des outils utilisés — le vrai sujet, c’était la méthode pour cadrer et structurer efficacement.)