Pourquoi ces neuf questions
Un projet ERP ne casse presque jamais d'un coup. Il dérive : une date glisse, puis une deuxième, la facturation passe en régie, un correctif en casse un autre, et l'équipe qui devra utiliser le système commence à s'en méfier. Chacun de ces signaux est supportable seul. Ensemble, ils composent un schéma que nous voyons dans presque tous les sauvetages.
Les six premières questions portent sur ce que vous voyez : les dates, l'argent, le code, les données, les gens. Les trois dernières portent sur votre capacité à le voir du tout. Un point hebdomadaire écrit, un outil de suivi que vous pouvez consulter et une feuille de route datée ne réparent aucun bug, mais sans eux personne ne peut dire si le projet est en retard, de combien, ni ce qui reste.
Comment le score est pondéré
Les signaux techniques et budgétaires pèsent plus lourd que la friction utilisateur : une équipe qui râle sur une nouvelle interface est normale, des workflows de base qui cassent après que le prestataire a dit « terminé » ne le sont pas. Le développement compte pour 29 % du total, le calendrier et le budget pour 26 %, le pilotage pour 24 %, les gens et l'adoption pour 20 %.
Le détail par section s'affiche avec votre résultat, sur les 172 points pondérés du barème. Un outil qui cache son arithmétique vous demande de le croire sur parole.
Ce que le score ne fait pas
C'est un indicateur, pas un audit. Il lit neuf réponses, pas votre base de données ni votre historique git. Un score élevé vous dit que le schéma est présent et qu'il vaut la peine de faire regarder le projet par un tiers ; il ne vous dit pas quelle ligne de code est en cause, ni combien coûtera la remise en état. Cela demande de lire le code.
Et un score faible est une réponse valable. Si vos réponses ne montrent aucun signal, n'achetez pas d'audit : la friction que vous vivez est normale pour un déploiement ERP.