La plupart des projets Odoo échouent. Voici pourquoi les nôtres non.
Après avoir livré Odoo dans l'électronique industrielle, la mode luxe, l'assurance suisse, l'énergie solaire hors réseau et le BTP — nous avons identifié les causes exactes des échecs projets. Cette page explique comment nous les prévenons.
La vérité qui dérange sur les implémentations Odoo
Nous en avons sauvé plus d'une nous-mêmes.
La cause n'est presque jamais Odoo. Le logiciel fonctionne. La cause est toujours la même : un consultant qui a commencé à configurer avant de comprendre le métier, qui a sauté le staging pour gagner du temps, qui a écrit du code custom que personne ne pourra maintenir, et qui a disparu après le go-live quand les vrais problèmes sont apparus. Nous avons construit notre méthode pour éliminer chacun de ces modes d'échec — un par un.
5 principes. Non-négociables. Sur chaque projet.
On comprend le métier avant d'ouvrir Odoo.
Tous les consultants savent configurer Odoo. Très peu comprennent pourquoi un plasturgiste pilote son MRP différemment d'un industriel agroalimentaire. Pourquoi la logique de prix d'une marque de luxe ne peut pas être gérée avec les listes de prix standard d'Odoo. Pourquoi la marge d'une entreprise BTP disparaît entre le devis et la clôture.
Avant d'écrire la moindre configuration, on cartographie votre process métier sur papier. On interroge votre responsable des opérations, votre comptable, et la personne qui utilise le système au quotidien. On identifie les trois points qui feront rater votre go-live si on ne les traite pas.
Cette étape prend du temps. C'est aussi la seule raison pour laquelle nos go-lives fonctionnent.
Natif d'abord. Custom uniquement quand il n'y a pas d'autre réponse honnête.
Le code custom est une dette. Chaque ligne écrite aujourd'hui doit être maintenue, testée, migrée et documentée à chaque version Odoo qui suit. La plupart des consultants écrivent du custom parce que c'est plus rapide que d'expliquer au client pourquoi son process doit évoluer. Nous ne faisons pas ça.
Notre règle : si le module Odoo standard couvre 80% du besoin, on configure et on forme l'équipe sur les 20% qui nécessitent un changement de process. Si les 20% manquants cassent vraiment le métier, on construit un module custom ciblé — avec documentation complète, tests unitaires et une note de migration qui rendra le prochain upgrade moins coûteux.
Nous avons dit à des clients que leur demande de custom était inutile. Certains ont insisté. Ils ont tous été reconnaissants à la prochaine migration.
Rien n'atteint la production avant que le staging soit validé.
Le staging n'est pas optionnel. Ce n'est pas un luxe. C'est le seul moyen de savoir si votre go-live va fonctionner avant de miser vos données de production dessus.
Chaque projet AldenSync a un environnement staging qui est le miroir exact de la production — même base, mêmes specs serveur, mêmes modules, même volume de données. On répète le go-live sur le staging avant de toucher la production. On le chronomètre. On documente chaque étape. On teste le rollback.
Quand votre équipe signe le PV de recette sur le staging, ils savent déjà à quoi ressemblera le lundi matin. Pas de surprise. Les surprises dans les go-lives ERP coûtent des semaines de perturbation opérationnelle aux entreprises. On n'accepte pas ce risque au nom de nos clients.
On forme les personnes qui vont vraiment l'utiliser — pas seulement l'équipe IT.
Le déploiement Odoo techniquement le plus parfait échoue si le responsable de production imprime des ordres de fabrication sur papier parce que l'interface tablette l'a perturbé le premier jour. Si la DAF refait la clôture mensuelle dans Excel parce qu'elle ne fait pas confiance aux chiffres Odoo. Si le magasinier scanne le mauvais code-barres parce que personne ne lui a montré le workflow de gestion des exceptions.
On forme en contexte. On forme le chef d'équipe au poste de travail, pas dans une salle de réunion. On forme la DAF sur son vrai workflow de clôture mensuelle, pas sur un scénario de démonstration. On ne part pas tant que les personnes qui utilisent Odoo chaque jour ne sont pas confiantes — pas seulement celles qui seront là pour répondre aux questions en semaine 2.
Le go-live n'est pas la fin. C'est le début des seules données qui comptent vraiment.
Tous les projets Odoo sont beaux en démonstration. Le vrai test, c'est la troisième semaine de production — quand le MRP tourne sur une demande réelle, quand la première réclamation client arrive dans le helpdesk, quand la clôture mensuelle se fait pour la première fois sous le nouveau système.
On reste. Trente jours après chaque go-live, on s'assoit avec votre équipe et on analyse les premières données opérationnelles réelles dans Odoo. On mesure ce qu'on avait promis contre ce qui s'est passé. On identifie les trois optimisations qui feront la plus grande différence au mois 2. On livre ça sous forme de rapport écrit. Ce n'est pas une vente additionnelle. C'est inclus.
Parce que la question n'est jamais de savoir si le go-live a fonctionné. La question est de savoir si Odoo fonctionne encore trois ans après.
Comment chaque projet avance — du premier appel au go-live.
La même séquence. À chaque fois. Pour chaque client.
Appel découverte (gratuit)
30 minutes. Consultant senior uniquement — pas un commercial. On vous pose des questions sur votre métier, votre système actuel, votre contrainte de go-live et les trois choses qui vous empêchent de dormir concernant ce projet. Vous nous posez n'importe quelle question. À la fin, on vous dit honnêtement si c'est un bon fit avec notre façon de travailler. Si ce n'est pas le cas, on le dit.
Audit payant
Avant d'écrire une proposition, on audite. Pour les implémentations : 2 jours sur site à cartographier votre process. Pour les migrations : 72 heures à faire tourner notre script d'audit technique. Vous recevez un rapport écrit. Cet audit est payant — parce que les audits gratuits produisent des propositions génériques. Les audits payants produisent des propositions précises. Les honoraires sont déduits du projet si vous continuez.
Proposition cadrée
Une proposition à prix fixe basée sur les conclusions de l'audit — pas sur ce que vous nous avez dit lors du premier appel. Chaque ligne justifiée. Risques nommés. Planning engagé. Process d'avenant expliqué avant que vous signiez. On ne fait pas de projets en régie ouverte pour les implémentations — parce qu'on ne peut pas budgéter ce qui n'a pas de plafond.
Build en staging
On construit et configure sur le staging — jamais en production. Vous avez accès tout au long. Points écrits hebdomadaires. Validation client requise à chaque jalon avant de passer au suivant. Chaque module custom livré avec documentation et tests avant d'aller en staging.
Validation métier
Votre équipe teste sur le staging avec un script de tests de régression qu'on prépare ensemble. Typiquement 40 à 60 scénarios couvrant vos flux critiques. On corrige les anomalies en temps réel. Le go-live n'est pas déclenché tant que votre équipe n'a pas signé le PV de recette. Pas un jour avant.
Go-live & bilan 30 jours
Go-live le vendredi soir. On monitore 48 heures. Vous démarrez le lundi sur le nouveau système avec nous au téléphone pendant les 3 premières heures. 30 jours après : bilan écrit, données réelles, trois actions. Inclus. Pas une option.
Ce qu'on ne fait jamais — et pourquoi ça vous protège.
On ne commence jamais à configurer avant que l'audit soit terminé.
Un consultant qui ouvre Odoo le premier jour d'un projet configure ses hypothèses, pas votre métier. On a audité des implémentations ratées où le consultant a passé trois mois à construire la mauvaise chose parce qu'il n'a jamais demandé au responsable entrepôt comment les retours fonctionnent réellement.
On ne saute jamais le staging pour accélérer la livraison.
Chaque semaine gagnée en sautant le staging coûte trois semaines de firefighting post-go-live. On a nettoyé après des projets où le staging a été sauté 'pour gagner du temps'. Le temps n'a pas été gagné. Il a été emprunté — à 300% d'intérêts.
On n'écrit jamais de code custom non documenté.
Le code custom non documenté est une bombe à retardement à fusible variable. Elle explose à la prochaine migration de version, quand le consultant qui l'a écrit est injoignable et que personne ne sait ce que ça fait. Chaque ligne de code custom qu'on écrit a un commentaire, une note de migration, et au minimum un test de smoke. Sans exception.
On ne disparaît jamais après le go-live.
La plainte la plus fréquente qu'on entend de clients qui viennent nous voir après une mauvaise expérience ne concerne pas la configuration. C'est : 'Ils étaient excellents jusqu'au go-live. Après, on n'a plus jamais eu de nouvelles.' Le bilan 30 jours post go-live est obligatoire sur chaque projet. Il est dans le contrat.
Ce qui se passe quand le périmètre change — parce que c'est toujours le cas.
Chaque projet découvre quelque chose que l'audit n'avait pas capté. Un module avec 14 formats d'export au lieu d'un seul. Un process métier que trois personnes décrivent de trois façons différentes. Un registre sous-traitants tenu dans un tableur dont personne n'avait parlé.
Quand ça arrive, on fait deux choses. On documente exactement ce qui a été découvert et pourquoi ça change le périmètre. Puis on présente un avenant écrit avec l'impact sur le planning et le budget — avant de faire une seule heure de travail sur le nouveau périmètre.
Vous signez l'avenant. On exécute le travail. Personne n'est surpris par la facture finale.
On a eu des clients qui ont contesté des avenants qu'ils trouvaient injustifiés. On leur a montré les preuves de l'audit. La plupart ont accepté. Quelques-uns non. Dans ces cas, on a négocié — et toujours trouvé un accord juste. Mais on n'a jamais absorbé un dépassement en silence pour le facturer plus tard. C'est comme ça que la confiance se brise.
Les clients avec qui on travaille le mieux — et ceux qu'on oriente ailleurs.
Vous êtes probablement un bon fit si...
- Vous avez un vrai problème opérationnel qu'Odoo peut résoudre — pas juste une envie vague de "digitaliser l'entreprise"
- Vous comprenez qu'une bonne implémentation demande du temps de votre équipe, pas seulement de la nôtre
- Vous êtes prêt à adapter certains process à Odoo plutôt que de customiser Odoo à chaque process existant
- Vous voulez un consultant qui vous dit quand vous avez tort — pas un qui acquiesce à tout ce que vous dites
- Vous prenez une décision pour les 5 à 10 prochaines années, pas pour les 6 prochains mois
On n'est probablement pas le bon partenaire si...
- Votre principal critère de sélection est le prix — pas le résultat. Il y a des consultants Odoo moins chers. Ils vous coûteront plus cher au final.
- Vous avez besoin d'un go-live en moins de 4 semaines depuis le démarrage. On ne peut pas livrer en sécurité à ce rythme. Personne ne peut.
- Vous voulez Odoo configuré exactement comme votre système actuel — avec tous ses contournements et exceptions manuelles. L'objectif d'Odoo est de faire mieux, pas de reproduire ce que vous avez.
- Vous n'êtes pas disponible pour participer au projet. Si on ne peut pas accéder à votre équipe opérationnelle pendant les phases d'audit et de validation, on ne peut pas garantir le résultat.
Notre garantie — écrite dans chaque contrat.
Maximum 4 heures de downtime production sur toute migration.
Si on dépasse par notre faute, on travaille sans frais jusqu'à ce que l'instance soit live.
Prix fixe sur chaque implémentation cadrée.
Si on découvre du périmètre supplémentaire par nos propres lacunes d'audit, on l'absorbe. Si vous le découvrez, on présente un avenant avant de faire le travail.
Bilan 30 jours post go-live inclus dans chaque projet.
Pas une vente additionnelle. Pas un supplément optionnel. Un livrable contractuel avec un rapport écrit.
Nos standards techniques — appliqués sur chaque ligne de code.
Code conforme OCA
Chaque module custom suit les standards de l'Odoo Community Association — structure, nommage, patterns d'héritage. Du code que tout développeur Odoo compétent peut lire, maintenir et étendre. Pas une boîte noire que seul nous comprenons.
Tests avant livraison
Chaque module custom est livré avec des tests unitaires couvrant ses chemins critiques. Vous recevez la suite de tests avec le code. Le prochain consultant qui travaillera sur votre instance nous remerciera — et vous aussi à la prochaine migration.
Documentation à la clôture
Chaque décision technique est documentée. Pourquoi cette approche et pas une autre. Ce que le module fait et ce qu'il ne fait pas. Ce qui nécessitera de l'attention au prochain upgrade de version. Livré en PDF à la clôture du projet.
Architecture pensée migration
On construit en pensant à la prochaine migration. Pas de noms de champs hardcodés. Pas d'appels directs à la DB. Pas de widgets OWL v1 quand v2 est disponible. Les choix techniques qu'on fait aujourd'hui déterminent le coût de votre prochain upgrade. On choisit en conséquence.
La méthode n'a de valeur que si le projet est le bon.
Commencez par un appel de 30 minutes. Consultant senior. Pas de pitch commercial. On vous dira si AldenSync est le bon fit pour votre projet — et sinon, on vous dira qui l'est.
On prend un nombre limité de nouveaux projets par trimestre. Si vous avez une contrainte de délai, mentionnez-la lors du premier appel.