Odoo standard ou développements spécifiques : éviter une personnalisation coûteuse à maintenir

Comprendre ce que la demande cherche à préserver

Un utilisateur demande un écran identique à son tableur. Il peut vouloir conserver une vue indispensable, ou simplement éviter d’apprendre une autre navigation. Les deux méritent une réponse, mais pas nécessairement un développement. Reformulez la demande en résultat : quelle décision doit être prise, avec quelles données et à quelle fréquence ?

Faites essayer la solution standard sur un dossier réel. Une démonstration abstraite ne montre pas la charge quotidienne. Si le résultat reste difficile à obtenir, documentez précisément l’écart. Cela permet de comparer configuration, formation, extension existante et développement spécifique.

Distinguer l’exception utile du confort local

Une règle de calcul propre à une offre peut justifier une adaptation. Une couleur préférée ou un ordre de colonnes n’a pas forcément le même poids. Évaluez fréquence, conséquence et nombre de personnes concernées. Les petites demandes accumulées peuvent créer une maintenance importante sans améliorer le service client.

Demandez ce qui se passerait si l’entreprise adoptait le fonctionnement standard. Un changement interne raisonnable peut coûter moins cher que la conservation de chaque particularité. À l’inverse, simplifier un contrôle réellement nécessaire pour éviter du code constitue une mauvaise économie.

Prévoir la vie de l’adaptation

Un développement doit être testé, documenté et maintenu à chaque évolution pertinente. La documentation Odoo sur les mises à niveau précise que les modules personnalisés doivent disposer d’une version compatible avec la version cible. Le coût ne s’arrête donc pas à la livraison initiale.

Faites identifier le propriétaire du code, ses dépendances et les scénarios de test. Conservez une description métier compréhensible sans le développeur initial. Un module qui fonctionne aujourd’hui mais dont personne ne sait expliquer la règle peut bloquer une évolution future.

Pour approfondir : Upgrade — Odoo 19.0 documentation

Organiser la décision et la suppression

Tenez un registre des adaptations avec leur motif, leur coût de maintien et leur usage. Lorsqu’une version standard couvre le besoin, examinez le retrait du code spécifique. Supprimer une adaptation devenue inutile est une amélioration, pas un échec du projet initial.

Prévoyez aussi les tests sur une copie de la base. Une migration technique réussie ne prouve pas que les montants, droits et documents restent corrects. La validation doit être portée par les personnes qui utilisent ces fonctions et par les responsables des données concernées.

Notre avis : exiger une justification durable

Nous conseillons de demander, pour chaque adaptation, la décision qu’elle améliore et le coût de son absence. Cette discipline ne bloque pas l’innovation ; elle évite de transformer Odoo en reproduction coûteuse d’un ancien système.

Si vous deviez réinstaller votre entreprise demain, garderiez-vous cette règle ? Si oui, expliquez pourquoi. Si non, le projet peut être l’occasion de simplifier le fonctionnement. La centralisation crée de la valeur lorsqu’elle réduit les incohérences, pas lorsqu’elle rassemble toutes les anciennes complications au même endroit.

Pour approfondir : Upgrade — Odoo 19.0 documentation