Déployer un produit dans vingt et un cabinets : méthode, échecs, learnings

Construire un logiciel est une chose. Le déployer dans des cabinets qui ont chacun leur organisation, leurs habitudes et leur histoire en est une autre, souvent plus difficile. Nous en sommes à seize cabinets intégrés et cinq en cours. Je veux raconter ce déploiement honnêtement, échecs compris, parce que c'est là qu'on apprend le plus.

Première leçon : un déploiement n'est jamais d'abord un sujet technique. La technique, on la maîtrise. Ce qui résiste, c'est l'humain et l'habitude. Une équipe qui travaille d'une certaine façon depuis dix ans ne change pas parce qu'un outil est meilleur. Elle change si on respecte sa manière de faire, si on l'accompagne, et si elle constate par elle-même le bénéfice. Les déploiements qui ont buté, chez nous, ont presque toujours buté là : on avait sous-estimé le poids des habitudes, pas la difficulté du logiciel.

Deuxième leçon : la reprise des données est le moment de vérité, et le plus piégeux. Chaque cabinet arrive avec son historique, ses conventions, ses approximations accumulées au fil des années. Migrer ces données proprement est un travail ingrat, invisible, et déterminant. Un déploiement où la reprise est bâclée démarre avec une dette de confiance qu'on ne rattrape jamais vraiment : si l'utilisateur ne retrouve pas ses dossiers tels qu'il les connaît, il rejette l'outil, même excellent. Nous avons appris à ne jamais accélérer sur cette étape, quitte à décaler une mise en service.

Troisième leçon : le rythme affiché ment toujours un peu. Sur un slide, un déploiement est une ligne droite. Dans la réalité, c'est seize histoires différentes et cinq en cours, chacune avec son tempo. Vouloir imposer un calendrier uniforme est le meilleur moyen de tout abîmer. Nous avons cessé de promettre des délais identiques pour tous ; nous nous adaptons au point de départ de chaque cabinet. C'est moins satisfaisant à présenter, mais bien plus solide dans les faits.

Je veux aussi parler des échecs sans les déguiser. Nous avons connu des mises en service trop rapides, où l'enthousiasme l'a emporté sur la préparation. Des fonctions pensées pour un cabinet qui ne convenaient pas au suivant. Des moments où nous avons confondu « le logiciel marche » et « les gens s'en servent » — deux choses très différentes. Chacune de ces erreurs a nourri la méthode : préparer plus, promettre moins, mesurer l'usage réel et pas seulement la mise en production.

Ce qui marche, à l'inverse, tient en peu de mots : avancer cabinet par cabinet, soigner la reprise, accompagner les personnes autant que paramétrer l'outil, et accepter que l'adoption se gagne dans la durée, pas le jour du lancement. Le signe qu'un déploiement a réussi n'est pas la signature ; c'est le moment, quelques semaines plus tard, où l'équipe ne pourrait plus revenir en arrière.

Si je devais ne retenir qu'une chose : un déploiement réussi se mesure à l'usage, jamais à la mise en service. Le reste n'est que de l'affichage.