Il existe une version du projet ERP qui ne se termine jamais. Elle commence par une estimation raisonnable, un lancement convivial et un taux horaire. Un an plus tard, les factures continuent d'arriver, la date de mise en production a été repoussée trois fois, et plus personne ne sait dire ce que terminé veut dire. Si vous avez déjà vécu ce genre de projet, vous savez déjà pourquoi nous refusons d'en vendre.
Nous travaillons à périmètre fixe et à prix fixe. Chaque implémentation que nous acceptons est chiffrée après une phase de cadrage, livrée conformément à un périmètre écrit, et facturée comme un montant — pas comme un taux. Lorsqu'un prospect demande plutôt une régie ouverte en temps et matériel, nous disons non. Ce n'est pas de l'entêtement de notre part. La question est de savoir qui porte le risque, et nous pensons que la réponse doit être nous.
Pourquoi les projets T&M sans limite dérivent
Le temps et matériel semble équitable sur le papier : vous payez exactement le travail effectué. En pratique, cela supprime la seule force qui maintient un projet ERP convergent — une définition du terminé partagée et contraignante. Un ERP touche tous les services d'une entreprise. Dès que le périmètre est ouvert, chaque service découvre quelque chose qu'il aimerait aussi avoir, chaque ambiguïté se résout en faisant plus, et chaque heure supplémentaire est facturable. Rien de tout cela n'exige de la mauvaise foi. C'est simplement ce que la structure récompense.
Cela transfère aussi discrètement tout le risque d'estimation sur le client. Si le prestataire a sous-estimé la migration comptable, le client paie l'erreur, heure après heure. La partie qui dispose du moins d'informations sur la durée réelle des travaux ERP finit par assurer celle qui en sait le plus. Nous pensons que c'est l'inverse qui devrait prévaloir. Avec un prix fixe, une estimation erronée est une perte que nous absorbons — c'est précisément pourquoi nous estimons avec soin, et pourquoi nous exigeons une véritable phase de cadrage avant de chiffrer quoi que ce soit.
Ce que produit une véritable phase de cadrage
Le cadrage n'est pas un rendez-vous commercial avec une présentation. C'est un travail structuré avec des livrables concrets, et chaque élément du devis final s'y rattache :
- Une liste de modules — quels modules Odoo Community et OCA couvrent chaque processus métier en standard, et où un écart nécessite réellement un développement spécifique. Nous privilégions par principe Community et OCA : moins de code spécifique signifie moins de maintenance et moins de casse lors des mises à niveau.
- Un inventaire des données — quels systèmes existants détiennent des données, quels volumes sont en jeu, quels objets migrent, et quels rapports de rapprochement prouveront que la migration est complète.
- Le niveau de spécifique, écart par écart — selon que la réponse est un paramétrage, une extension d'un module existant ou un nouveau module. Tout ce que nous construisons est développé au niveau d'exigence d'un module et versionné dans Git, afin de résister aux mises à niveau et aux audits.
- Un plan de bascule — des migrations à blanc avant la vraie, des contrôles de rapprochement après, et un plan de retour arrière que nous espérons ne jamais utiliser.
- Rôles et formation — qui utilise quels écrans, et la formation par rôle qui en découle, afin que l'adoption soit planifiée plutôt qu'espérée.
Le résultat est un document de périmètre suffisamment précis pour y adosser un montant fixe. Ce montant couvre les modules listés, les données listées, les développements listés et les formations listées — rien de plus vague que cela. Si notre estimation s'avère erronée après signature, c'est notre problème, pas le vôtre.
Des demandes de changement sans dérive horaire
Périmètre fixe ne signifie pas que votre activité se fige. Les besoins évoluent ; c'est normal. Ce qui change, c'est la manière dont le changement entre dans le projet. Un nouveau besoin devient une demande de changement : décrite par écrit, confrontée au document de périmètre, chiffrée avec son propre prix fixe, et acceptée ou refusée avant tout démarrage des travaux. Il n'y a ni goutte-à-goutte horaire ni ligne surprise sur la facture du mois suivant.
C'est le document de périmètre qui rend ce fonctionnement équitable dans les deux sens. Si un élément que nous avons livré ne fonctionne pas comme prévu au périmètre, c'est un défaut et nous le corrigeons à nos frais. S'il n'a jamais figuré dans le périmètre, c'est une demande de changement avec son propre prix. Dans les deux cas, la limite se discute à partir d'un document écrit, pas de mémoire lors d'une réunion de suivi.
La même philosophie se poursuit après la mise en production. Le support repose sur des SLA à plusieurs niveaux — réponse en 24 heures, 4 heures ou 1 heure selon le niveau choisi — les sauvegardes sont testées en restauration plutôt que présumées fiables, et les mises à niveau sont testées contre vos développements spécifiques avant de toucher la production. Des engagements définis, partout, parce que c'est dans le flou que la confiance s'érode.
Dire non aux missions sans limite nous coûte quelques affaires, et nous l'assumons. Les projets que nous acceptons se terminent, atterrissent sur un montant convenu par les deux parties, et laissent derrière eux un système que quelqu'un peut réellement maintenir. Si vous envisagez un projet ERP et souhaitez voir comment une phase de cadrage structurerait le vôtre, notre page de services d'implémentation détaille le processus étape par étape.