Changer d'outil ne règle presque jamais le problème
La migration est un projet coûteux, souvent entrepris pour résoudre une difficulté qui n'est pas technique. Trois questions à se poser avant.
J'ai participé à plusieurs migrations d'outil de gestion de projet. Aucune n'a résolu le problème qui l'avait motivée, et je pense pouvoir dire pourquoi.
Les difficultés qui ressemblent à des problèmes d'outil
« On ne sait pas où en sont les choses. » C'est un problème de mise à jour, donc d'habitude, donc de décision sur qui met à jour et quand. Le nouvel outil sera aussi mal tenu que l'ancien.
« Il y a trop de choses en cours. » C'est un problème d'arbitrage. Aucun outil n'a d'avis sur ce qu'il faut arrêter.
« On se marche dessus. » C'est un problème de périmètre et de responsabilités.
Un outil rend visible une organisation. Il ne la remplace pas — et un outil sophistiqué rend seulement le désordre plus lisible.
Les trois questions avant de migrer
- Quelle décision l'outil actuel empêche-t-il ? S'il n'y en a pas, le problème est ailleurs.
- Qu'est-ce qui n'est pas tenu à jour aujourd'hui, et pourquoi ? Si la réponse est « personne n'a le temps », le nouvel outil ne créera pas ce temps.
- Qui portera la migration ? Reprise des données, reconstruction des vues, formation, période de double saisie : c'est un projet à part entière et il doit être budgété comme tel.
Quand une migration se justifie
Quand l'outil est réellement bloquant : limite technique atteinte, fin de support, coût disproportionné, impossibilité de faire quelque chose de nécessaire. Ce sont des motifs concrets et vérifiables.
Pas quand il est « vieux » ou moins agréable que ce qu'on a vu ailleurs. Ce sont de vraies raisons d'insatisfaction et de mauvaises raisons de migrer.
Ce que je conseille avant
Tenir l'outil actuel correctement pendant un mois — mise à jour disciplinée, périmètre clair, une seule source. Si la difficulté persiste, elle est réelle. Si elle disparaît, la migration aurait coûté cher pour rien.
