Le Problème du « Béni-Oui-Oui » dans l'ERP
Voici un secret inavouable de l'industrie ERP : beaucoup d'intégrateurs gagnent plus d'argent en disant « oui » à chaque demande de personnalisation qu'en disant « non ». Le développement spécifique se facture à des taux premium. La maintenance génère des revenus récurrents. Et quand les migrations cassent, quelqu'un doit les réparer — moyennant finance.
J'ai passé 15 ans à implémenter Odoo, et j'ai vu ce pattern détruire des entreprises. Une société commence avec « juste quelques ajustements », puis ajoute « un module de plus », puis construit « une petite intégration ». Cinq ans plus tard, ils sont piégés : incapables de mettre à jour, payant 30 000 €/an pour maintenir du code qui réplique des fonctionnalités qu'Odoo a ajoutées au produit standard trois versions plus tôt.
Odoo peut être codé pour faire presque n'importe quoi. La question est : le devrait-il ? Cet article plaide pour la philosophie « Standard d'Abord » — et met en garde contre les sables mouvants de la personnalisation illimitée.
Le Mythe du « Sur-Mesure Parfait »
« Nous voulons qu'Odoo fonctionne exactement comme notre système actuel. » J'entends cela dans presque chaque consultation initiale. Et c'est presque toujours le mauvais objectif.
Réfléchissez à ce que vous demandez réellement : vous voulez prendre un ERP moderne et éprouvé, utilisé par plus de 12 millions d'utilisateurs, et le forcer à répliquer les workflows de votre logiciel legacy — un logiciel que vous remplacez parce qu'il ne vous sert plus.
Les workflows standard d'Odoo ne sont pas arbitraires. Ils sont la distillation de milliers d'implémentations, affinés sur plus de 15 ans. Ils encodent les meilleures pratiques pour la gestion des stocks, la conformité comptable, les pipelines commerciaux et les opérations de production. Quand vous les contournez, vous ne construisez pas seulement du code — vous rejetez la sagesse accumulée.
La métaphore que j'utilise : Imaginez acheter une maison neuve conçue par un architecte primé, puis immédiatement casser des murs pour recréer l'agencement de votre ancien appartement. Vous avez détruit l'intégrité de la conception, créé des problèmes structurels, et vous paierez pour ça à chaque rénovation.
Avant d'approuver toute personnalisation, demandez-vous : « Ce processus est-il réellement meilleur que le standard Odoo, ou sommes-nous juste habitués à lui ? » Le confort n'est pas un argument commercial.
Qu'est-ce que la Dette Technique ? (En termes simples)
La dette technique est le coût futur des raccourcis pris aujourd'hui. En termes Odoo : chaque module spécifique que vous construisez est un prêt sur votre futur vous-même. Et le taux d'intérêt est brutal.
Voici ce qui se passe quand Odoo sort une nouvelle version (v18 → v19 → v20) :
- Bases de données standard : La migration est largement automatisée. Odoo fournit des scripts de mise à niveau officiels. La plupart des entreprises migrent en 2-4 semaines avec un support consulting minimal.
- Bases de données personnalisées : Chaque module spécifique doit être analysé, refactorisé et testé sur la nouvelle version. Les scripts de migration doivent être écrits manuellement. Les dépendances cassent. Des conflits émergent. Une mise à jour « simple » devient un projet de 3-6 mois.
Les chiffres sont brutaux : les bases de données fortement personnalisées coûtent 5x plus cher à migrer et prennent 3x plus de temps. J'ai vu des entreprises sauter trois versions majeures d'Odoo parce qu'elles ne pouvaient pas se permettre la migration — puis faire face à une facture encore plus lourde quand elles ont finalement dû bouger.
Les modules spécifiques stockent souvent les données de façon non standard. Quand le modèle de données d'Odoo change (et il change, à chaque version), vous avez besoin de « scripts de migration » sur mesure. Écrire et tester ces scripts peut coûter 5 000-15 000 € par module majeur.
Les APIs internes d'Odoo évoluent. Des méthodes sont dépréciées, renommées ou restructurées. Le code spécifique qui « s'accroche » au cœur d'Odoo cassera. À. Chaque. Mise. À. Jour.
L'ironie la plus cruelle : les fonctionnalités que vous avez payées pour construire apparaissent souvent dans Odoo standard 2-3 versions plus tard. Maintenant vous maintenez du code legacy qui concurrence des fonctionnalités natives.
La Règle 80/20 d'Odoo
Ma philosophie : 80% Standard, 20% Configuration. Notez que je dis configuration, pas personnalisation. Ce sont des choses fondamentalement différentes :
Utiliser les outils intégrés d'Odoo pour adapter le comportement : Odoo Studio pour les ajustements UI et champs simples, Actions Automatisées pour les déclencheurs de workflow, Actions Serveur pour la logique métier, Modifications de rapports, et Paramètres/Réglages. La configuration voyage proprement entre les versions.
Écrire de nouveaux modules Python, surcharger les méthodes cœur d'Odoo, créer des modèles de données personnalisés, ou construire des intégrations externes. La personnalisation crée des obligations de maintenance permanentes.
L'objectif : Épuiser chaque option de configuration avant d'envisager la personnalisation. Odoo Studio peut gérer 80% des demandes « nous avons besoin de ce champ ». Les Actions Automatisées peuvent remplacer 70% des demandes « quand X arrive, faire Y ». Ce n'est que quand ces outils ne peuvent véritablement pas résoudre le problème que vous devriez recourir au code spécifique.
Avant tout développement spécifique, exigez de votre partenaire qu'il documente : (1) Pourquoi Studio/Actions Automatisées ne peuvent pas résoudre ce problème, et (2) Le coût de migration estimé pour les 3 prochaines versions Odoo. S'il ne peut pas répondre, il n'a pas fait ses devoirs.
Quand la Personnalisation EST Nécessaire
Je ne suis pas absolutiste. Il existe des raisons légitimes de construire du code spécifique. Mais elles sont plus rares que la plupart des entreprises ne le pensent :
Si un processus est véritablement votre « recette secrète » — ce qui vous différencie de vos concurrents — il peut justifier un développement spécifique. Mais soyez honnête : votre workflow d'approbation en trois étapes est-il vraiment un avantage concurrentiel, ou juste une habitude organisationnelle ?
Certaines industries ont des exigences véritablement uniques : algorithmes de tarification spécialisés, calculs de conformité réglementaire, ou protocoles de contrôle qualité spécifiques au domaine. Si Odoo ne sert pas votre verticale, le code spécifique peut être inévitable.
Connecter Odoo à des équipements de production propriétaires, des systèmes de codes-barres spécialisés, ou des appareils IoT spécifiques à l'industrie nécessite souvent des connecteurs spécifiques. Ce sont des nécessités techniques légitimes.
Le test : Si vous supprimiez cette personnalisation, perdriez-vous des clients ou des parts de marché ? Si la réponse est non, vous n'en avez probablement pas besoin.
La Question Qui Change Tout
Voici le défi que je lance à chaque client avant de discuter personnalisation :
« Votre processus actuel est-il réellement meilleur que le workflow standard d'Odoo, ou y êtes-vous simplement habitué ? »
C'est inconfortable. Cela force les gens à justifier des habitudes qu'ils n'ont jamais remises en question. Mais c'est la différence entre implémenter un ERP qui transforme votre entreprise et construire une réplique coûteuse de votre dysfonctionnement existant.
J'ai vu des responsables d'entrepôt insister sur des workflows de préparation personnalisés, pour découvrir ensuite que la préparation par vagues standard d'Odoo réduisait leurs coûts de main-d'œuvre de 20%. J'ai vu des comptables exiger des chaînes d'approbation personnalisées, puis réaliser que le rapprochement à trois voies standard d'Odoo détectait des erreurs que leur processus manuel manquait depuis des années.
Le « pivot processus » ne consiste pas à vous forcer dans un moule. Il s'agit de mériter le droit de personnaliser. Prouvez que votre façon de faire est véritablement supérieure, avec des données, avant de demander du code.
Notre Engagement pour Votre Avenir
Voici ce que nous promettons à chaque client :
« Nous vous dirons toujours 'Non' si une personnalisation va nuire à vos futures mises à jour — même si cela signifie que nous facturons moins d'heures de développement aujourd'hui. Nous remettrons en question vos hypothèses, protégerons votre chemin de migration, et recommanderons les fonctionnalités standard Odoo plutôt que du code spécifique chaque fois que possible. Votre succès à long terme vaut plus que nos revenus à court terme. »
Ce n'est pas du marketing. C'est une question de survie. Notre réputation dépend de clients qui utilisent toujours Odoo avec bonheur cinq ans plus tard — pas de clients piégés dans des systèmes inmaintenables qui nous blâment pour leur souffrance.
Coût de Migration : Standard vs. Personnalisé
Voici la réalité sur 5 ans pour une entreprise de 30 utilisateurs, en supposant une mise à jour majeure Odoo tous les 2 ans :
| Catégorie de Coût | Base Standard (Configuration uniquement) | Fortement Personnalisée (15+ modules spécifiques) |
|---|---|---|
| Implémentation Initiale | 25 000 € | 55 000 € |
| Migration 1 (Année 2) | 4 000 € | 22 000 € |
| Migration 2 (Année 4) | 4 500 € | 28 000 € |
| Maintenance Annuelle | 3 000 €/an (15 000 € total) | 12 000 €/an (60 000 € total) |
| Corrections Bugs & Patchs | 2 000 € total | 18 000 € total |
| TOTAL 5 ANS | 50 500 € | 183 000 € |
| Multiplicateur de Coût | 1x (référence) | 3,6x |
La base personnalisée coûte 132 500 € de plus sur 5 ans. Sans compter la perturbation business des migrations plus longues, le coût d'opportunité des fonctionnalités retardées, ou l'éventuel « tout casser et recommencer » quand la dette technique devient insurmontable.