La question revient à chaque basse saison : peut-on vraiment livrer un outil métier avant que la production reprenne ? La réponse est oui, à condition de ne pas confondre « outil métier » avec « système complet ». Voici ce que huit semaines permettent vraiment, et ce qu'elles ne permettent pas.
Donatien Lefranc
Fondateur & Président, Leando
Chaque basse saison, la même conversation. Un dirigeant de PME industrielle ou événementielle arrive avec un problème concret qu'il a géré à la force des bras pendant les six derniers mois. Un processus manuel qui a absorbé du temps, des erreurs qui ont généré des retours, des équipes mobilisées sur des tâches sans valeur ajoutée. Et une question directe : si on s'y met maintenant, est-ce qu'on peut avoir quelque chose de fonctionnel avant la reprise ?
La réponse honnête est oui, avec une condition : le périmètre doit être verrouillé avant le premier jour de développement. Un outil métier sur un processus délimité se livre en huit semaines. Un projet qui s'étend en cours de route ne se livre jamais dans les délais, quelle que soit la durée prévue au départ.
La distinction entre les deux tient à une seule décision, prise en amont : qu'est-ce que ce premier outil fait exactement, et qu'est-ce qu'il ne fait pas encore ? Cette décision est plus difficile qu'il n'y paraît. Elle demande d'accepter que la première version soit volontairement incomplète.
Huit semaines couvrent quatre phases, et chacune a une durée qui ne compresse pas au-delà d'un certain seuil.
Deux à trois semaines de cadrage serré : comprendre le processus en détail avec les personnes qui l'exécutent, cartographier les cas nominaux et les exceptions fréquentes, valider le périmètre avec le dirigeant, définir ce que le système doit faire et les critères qui feront qu'on considère qu'il fonctionne. Ce travail ne peut pas être sauté ni compressé en deux réunions. Il conditionne la précision de tout ce qui vient après.
Deux semaines de développement sur le POC : construire la première version fonctionnelle. Pas la version définitive, pas la version qui couvre toutes les exceptions, mais une version qui fonctionne sur le cas nominal et les cas les plus fréquents. À la fin de ces deux semaines, il y a quelque chose qu'on peut utiliser.
Deux à trois semaines de tests en conditions réelles : utiliser le POC sur de vrais cas, identifier ce qui ne fonctionne pas comme prévu, corriger, ajuster. Cette phase révèle invariablement des situations que les ateliers de cadrage n'avaient pas anticipées. C'est normal. Elle est là pour ça.
Une semaine de mise en production et de formation : basculer vers le nouvel outil, former les équipes, documenter les gestes clés. La formation est une étape à part entière, pas une demi-journée annexée à la livraison.

Les projets d'outils métier qui dérivent ont presque toujours la même cause racine : l'une de ces trois conditions n'était pas réunie.
Le périmètre est verrouillé avant le démarrage. Chaque demande de fonctionnalité supplémentaire formulée en cours de construction est enregistrée dans un backlog et reportée à la prochaine basse saison. Elle n'est pas intégrée dans le sprint en cours. Cette discipline est inconfortable, parce que les bonnes idées arrivent souvent quand on voit le système prendre forme. Mais chaque ajout en cours de route décale la livraison d'autant.
Le décideur est disponible pour valider les arbitrages rapidement. En cours de développement, des questions émergent : comment gérer tel cas d'exception, quel comportement adopter quand telle donnée manque, quelle règle s'applique dans telle configuration. Ces questions ne peuvent pas attendre une semaine de réponse. Si le dirigeant ou le référent métier n'est pas disponible en 24 à 48 heures pour valider, le développement s'arrête en attendant. Les délais s'accumulent.
La phase de cadrage a identifié les scénarios non nominaux avant le développement. Pas tous, mais les plus fréquents. Un processus métier semble simple jusqu'au moment où on le décrit précisément. Les exceptions (le contrat modifié après signature, le client qui change de périmètre, le cas particulier que l'équipe gère « à la main depuis toujours ») surgissent en cadrage ou en développement. Mieux vaut qu'elles surgissent en cadrage.
Un comedy club, leader en France par nombre de soirées organisées chaque mois, avait un problème concret : six à huit contrats à générer par soirée, pour tous les artistes, avec des variables différentes à chaque fois. Un poste de freelance à mi-temps ne gérait que cette partie contractuelle. Le dirigeant voulait récupérer cette bande passante pour la concentrer sur le développement commercial et la relation avec les artistes.
Trois ateliers de cadrage pour comprendre le processus et ses exceptions. Deux semaines pour construire un POC fonctionnel en Google Apps Script et Python, volontairement simple, utilisable directement dans Google Workspace. Trois semaines de correctifs sur les cas non anticipés. Mise en production à J+35. ROI atteint en six à sept mois, avec élimination quasi totale du temps consacré à la génération de contrats.
La formule que le dirigeant a utilisée à l'issue de l'atelier de cadrage dit tout : « Moi ça me va très bien. Je suis prêt à investir quelque chose qui dans six-sept mois commencera à me rapporter de l'argent. » L'outil était modeste. Le ROI était lisible dès le départ.
Sur un registre différent, une PME agroalimentaire de produits de la mer a conduit une phase R&D de faisabilité pendant sa basse saison pour valider qu'un système de computer vision pouvait dépasser les performances de la machine de tri installée plusieurs années plus tôt.
« On voulait absolument présenter un investissement assez léger avant d'aller plus loin. C'était la première fois qu'on travaillait ensemble. »
Ce positionnement, léger au départ pour valider avant d'investir, a produit un résultat mesuré : passage de 50 à quasiment 95% de détection positive à l'issue de la phase R&D. La décision d'industrialiser s'est appuyée sur des mesures, pas sur des projections. Pour aller plus loin sur l'aspect ROI de ce type de projet : ROI de l'IA pour une PME : calcul réel sur trois projets.
Si votre haute saison reprend dans moins de seize semaines, il est encore possible de livrer quelque chose d'utile avant la reprise. La condition est de démarrer le cadrage maintenant, pas dans trois semaines.
Le point de départ est un exercice simple : décrivez le processus le plus pénible de votre dernière haute saison en une page. Qui l'exécute, combien de temps il prend, combien de personnes il mobilise, quelles erreurs il génère, et ce qui changerait concrètement si ce processus était automatisé ou outillé différemment. Pas un cahier des charges, pas une liste de fonctionnalités : une description honnête du problème réel.
Ce document est suffisant pour évaluer si un projet peut tenir dans votre fenêtre de basse saison, et pour définir un périmètre de POC réaliste. C'est aussi le document qui permet d'avoir une conversation précise avec un prestataire, sans projections ni promesses vagues dans les deux sens. Pour comprendre la méthode lean qui permet de cadrer ce type de projet en quelques semaines : la méthode lean appliquée aux projets tech PME.
Non, et c'est ce qui distingue un projet qui tient son délai d'un projet qui dérape. Les 8 semaines sont la phase de construction : développement, tests, correctifs, mise en production. La phase de cadrage (comprendre le processus, délimiter le périmètre, valider le budget) doit être conduite avant. Idéalement en fin de haute saison précédente ou dans les premières semaines de basse saison, pendant que la mémoire de ce qui était pénible est fraîche.
Décrivez-nous le processus qui vous a coûté le plus lors de la dernière saison. On évalue ensemble ce qui est réaliste de livrer avant la reprise, sans engagement.
Évaluer mon projet de basse saison