Odoo Studio vs développement custom : quand utiliser quoi ?

60-70% des projets ERP échouent à cause de sur-customisation. Guide pratique pour décider quand utiliser Studio, les Automated Actions, ou du code Python — et éviter la dette technique.

60 à 70% des projets ERP rencontrent des difficultés significatives. La cause est presque toujours organisationnelle, pas technique : sur-customisation, dette technique accumulée, et modules custom qui deviennent des freins à chaque mise à jour majeure. Avant d'écrire une ligne de Python, voici le cadre de décision que nous appliquons sur chaque projet.

La règle 80/20 : standard d'abord, toujours

Odoo couvre 80% des besoins métier en standard. La première question à poser n'est pas 'Comment développer ça ?' mais 'Est-ce que le standard ne suffit pas ?'. Les 'besoins spécifiques' disparaissent souvent quand les utilisateurs voient le workflow standard en fonctionnement. La philosophie : 80% standard, 20% configuration (pas customisation — configuration).

Niveau 1 : Odoo Studio (0 code)

Studio gère environ 80% des demandes 'on a besoin de ce champ'. Utilisez-le pour :

✓Ajouter des champs custom sur n'importe quel modèle (texte, sélection, calcul)
✓Modifier des vues liste, formulaire, kanban sans toucher au XML
✓Créer des rapports PDF personnalisés
✓Ajouter des onglets sur les fiches clients, opportunités, bons de commande
✓Configurer des pipelines et étapes custom
✓Ces changements migrent proprement entre versions — zéro coût de maintenance

Niveau 2 : Automated Actions (0 code)

Les Automated Actions remplacent environ 70% des demandes 'quand X se passe, faites Y'. Dans Paramètres → Technique → Automated Actions, vous pouvez déclencher des actions sur :

✓Création ou modification d'un enregistrement (trigger: record creation/update)
✓Changement d'un champ spécifique (ex: stage_id passe à 'Gagné')
✓Conditions temporelles (ex: relance si devis non signé après 7 jours)
✓Actions disponibles : envoyer un email, mettre à jour un champ, appeler un webhook, créer un enregistrement lié
✓Combiner plusieurs conditions avec des filtres de domaine Python-like

Niveau 3 : Modules custom Python (dernier recours)

Seulement quand Studio et Automated Actions ne peuvent genuinement pas résoudre le besoin. Les règles absolues pour un module custom maintenable :

✓Toujours un module séparé avec son manifest.py — jamais de modification des fichiers core
✓Utiliser _inherit sur les modèles existants, pas de création ex nihilo sauf si nécessaire
✓Utiliser uniquement l'ORM Odoo (models.Model, fields, api decorators) — jamais de SQL raw sauf performance justifiée
✓Références par XML ID (module_name.record_id), jamais par integer ID (ils changent entre environnements)
✓Documenter le module : pourquoi il existe, quels modèles il hérite, les décisions non évidentes
✓Avant de coder : documenter pourquoi Studio/Automated Actions ne suffisent pas

Le coût réel d'une customisation excessive

✓Migration standard (peu/pas custom) : 2-4 semaines, scriptée automatiquement par Odoo
✓Migration avec modules custom lourds : 3-6 mois, scripts manuels, 5 000-15 000€ par module complexe
✓Chaque customisation = coût caché à chaque version majeure (Odoo sort une version par an)
✓Les modules AppStore Odoo (4 000+ disponibles) migrent automatiquement — cherchez-y avant de coder

Checklist avant tout développement custom

✓1. Est-ce qu'un paramètre natif résout le besoin ?
✓2. Est-ce que Studio peut ajouter le champ/la vue manquante ?
✓3. Est-ce qu'une Automated Action peut automatiser ce workflow ?
✓4. Est-ce qu'un module AppStore existe déjà ?
✓5. Si développement custom : le module est-il séparé, _inherit utilisé, XML IDs partout ?
✓6. Le coût de migration v+1 a-t-il été estimé et documenté ?

La sur-customisation est le principal facteur d'échec des projets Odoo sur le long terme. Un ERP bien configuré en standard sera toujours plus performant, moins coûteux à maintenir, et plus facile à faire évoluer qu'un ERP surchargé de modules custom.