Avec le recul : ce que j'aurais fait différemment dès le premier jour

Sept épisodes plus tard, je voulais refermer cette série différemment. Moins parler du client, plus parler de moi. De ce que je referais autrement aujourd'hui — et qui, mis bout à bout, explique pourquoi je travaille autrement depuis.

Quand j'ai démarré cette mission, je venais d'être freelance depuis quelques semaines. J'avais l'expertise technique. J'avais la posture conseil dans les neurones, sans encore l'avoir tout à fait dans les réflexes. Et j'ai accepté ce qui semblait être une demande simple : "il nous faut un logiciel pour mieux gérer les stocks".

Avec le recul, c'est précisément à ce moment-là que j'aurais dû ralentir. Pas parce que la demande était mauvaise, mais parce qu'elle n'était pas le sujet. En tout cas pas la source du problème à corriger.

Voici les cinq choses que je referais autrement aujourd'hui.

1. Je n'aurais pas répondu à la question posée

Le client me demandait un outil SaaS de gestion de stocks. Le vrai problème : un ERP installé cinq ans plus tôt, qui ne suivait plus la croissance de l'entreprise. Mais je ne l'ai compris qu'après plusieurs semaines de travail.

Dans l'absolu, j'ai bien fait : j'ai livré un SaaS qui a soulagé l'opérationnel, fait gagner du temps réel, permis à l'équipe de respirer. Mais j'ai aussi conforté un statu quo. Tant que la douleur restait gérable, la vraie décision — changer d'ERP — pouvait continuer à être repoussée.

Ce que je fais maintenant : avant de proposer quoi que ce soit, je passe deux ou trois rendez-vous à reformuler la demande. Pas pour la disqualifier. Pour la replacer dans le SI complet. La phrase "il nous faut un outil pour X" est presque toujours le symptôme d'une question plus large que personne n'a osé formuler. C'est mon job de la poser à voix haute, même quand c'est inconfortable.

2. J'aurais chiffré le coût du statu quo dès la première semaine

Quand j'ai compris l'ampleur du temps perdu ( 385 heures par an juste pour reconstituer une vision de stocks ) c'était plusieurs semaines après mon arrivée. Avec ce chiffre posé sur la table dès le début, on aurait pu avoir une conversation différente, beaucoup plus tôt. On aurait pu mettre face à face le coût d'un changement d'ERP et le coût de continuer comme avant. L'arbitrage aurait été évident.

Ce que je fais maintenant : dès la phase de cadrage, je calcule explicitement le coût du statu quo. Pas le coût de l'outil défaillant, mais le coût des contournements, des décisions prises en retard, des heures non facturables qui s'accumulent. Ce chiffre, formulé en clair, est l'argument le plus puissant pour débloquer une décision structurelle. Il n'est pas toujours demandé. Il est presque toujours décisif.

3. J'aurais audité l'infrastructure avant tout le reste

J'ai consacré un épisode entier à l'infrastructure parce que c'est l'angle mort que je retrouve dans la plupart des projets. Et pourtant, sur cette mission, je n'ai pas commencé par là. J'ai supposé que les bases étaient saines. Cette supposition m'a coûté quelques longues semaines de travail sur ce projet. Temps de travail qui aurait pu être évité si j'avais anticipé ce point.

Ce que je fais maintenant : de simples questions, posées avant la signature du devis.

• Sites uniques ou multisites ? Quelle qualité de connexion par site ?
• Le client a-t-il connaissance de son infrastructure SI actuelle ? Si oui, comment se structure-t-elle ?
• Si des sauvegardes existent, ont-elles déjà été testées en conditions réelles ?
• Qui est l'interlocuteur technique en cas de souci ? Une personne précise, joignable, identifiée ? Si je n'ai pas de réponse claire sur ces trois points, je ne propose pas de roadmap. Je propose d'abord un audit d'infrastructure. C'est moins glamour à vendre. Mais ça évite de construire sur du sable. Et ça évite au client de dépenser plus

4. J'aurais cessé de croire que le problème était technique

Pendant longtemps, j'ai cherché la solution dans le bon outil. Le bon SaaS, le bon paramétrage, les bonnes requêtes SQL, le bon design. La vraie nature du problème, je l'ai mise en mots tardivement : ce n'était pas un problème d'outil. C'était une organisation entière qui avait évolué sans que son SI suive. Plusieurs canaux de remontée d'informations, plusieurs sources de vérité, des Excel manuels qui s'imposaient comme référence parce qu'ils étaient les seuls à donner une vision globale.

Aucun outil ne corrige ça. Il faut revoir les flux, les rôles, les règles de saisie, la hiérarchie des sources. C'est un travail d'organisation, pas de développement ou de paramétrage.

Ce que je fais maintenant : je n'attaque jamais un projet sans cartographier les flux d'information existants, même grossièrement. Qui saisit quoi ? Qui décide à partir de quoi ? Où sont les Excel-pansements qui tournent en parallèle ? Si je ne pose pas ces questions, je vais empiler une couche supplémentaire sur un problème qui n'est pas technique. Et la couche d'après non plus.

5. J'aurais posé une deadline et des seuils de décision dès le départ

L'effet tunnel, j'en ai parlé dans l'épisode 5 : on continue un projet par inertie, parce qu'on a déjà investi, parce que personne ne veut être celui qui dit stop. La parade, c'est de définir à l'avance ce qui validerait, ou invaliderait, la trajectoire choisie. Des indicateurs, des seuils, une date.

Sur cette mission, je ne l'ai pas fait. Le SaaS pansement est resté en place plus longtemps qu'il aurait dû, parce qu'aucun de nous deux n'avait posé en clair : "on bascule sur autre chose si à telle date, on n'a toujours pas X et Y". Au final, le choix a été prit après plusieurs incidents techniques qui ont fait comprendre au client que mes recommandations étaient à leurs avantages sur du court terme. Finalement ne pas mettre de date sur des points aussi stratégiques, et attendre ce n'est pas du conseil. C'est de l'attentisme.

Ce que je fais maintenant : à la fin de chaque cadrage, je formule un point de bascule écrit. À telle date, ou si tel indicateur passe tel seuil, on rouvre la décision. Court. Posé. Partagé. Ça évite à tout le monde, moi compris, de s'enfoncer poliment dans une solution qui ne tient plus.

La leçon qui résume les autres

Ces cinq erreurs ont toutes la même racine : j'ai répondu à la demande du client au lieu de poser les questions qui auraient permis de la formuler correctement. J'avais l'expertise. Il me manquait la rigueur de la phase amont.

C'est exactement la zone où je vois le plus de TPE et de PME se planter aujourd'hui. Pas parce que les éditeurs sont mauvais. Pas parce que les équipes sont incompétentes. Parce que le moment où il faut être lent et exigeant — celui où on choisit ce dans quoi on va vivre cinq ans — est presque toujours expédié en deux réunions. Et un une suite de logiciel est choisit en ne prenant pas en compte tout les paramètres nécessaires pour bien choisir.

Si je devais résumer cette série en une phrase, ce serait celle-là : le bon moment pour appeler quelqu'un de l'extérieur, ce n'est pas quand le projet ne tient plus. C'est avant qu'il commence.

Et si on en parlait ?

Si vous vous reconnaissez dans une partie de cette série — l'ERP qu'on aurait dû changer il y a deux ans, le SI qui retarde toutes vos décisions, le projet de digitalisation que vous repoussez parce que vous ne savez pas par où commencer — c'est précisément le moment où je peux vous être utile.

Je propose un diagnostic gratuit de 30 minutes. Vous m'expliquez votre contexte. Je vous renvoie une vision claire : où sont les vrais leviers, où sont les angles morts, par quoi commencer. Sans engagement, sans devis caché. Une conversation honnête entre quelqu'un qui a fait les erreurs racontées dans cette série, et quelqu'un qui peut éviter de les refaire.

➡️ Réserver 30 minutes →

Merci d'avoir suivi ces sept épisodes. La technique, c'est jamais le plus dur. Le plus dur, c'est de poser les bonnes questions au bon moment. Et c'est précisément à ça que je sers.