🧩 Odoo – Guide “Senior Odoo Developer” (Web & Dev)

Pourquoi les boîtes choisissent Odoo ?

• Remplacer des Excel/outils dispersés par un ERP unifié.
• Personnaliser vite (modules + UI) sans “réinventer” un CRM/ERP.
• Automatiser : facturation, stock, procurement, workflows, approvals.
• Intégrer : paiement, e-commerce, BI, data warehouse, EDI, marketplaces.

Ce qui fait gagner du temps au dev

- ORM + relations + computed fields
- UI générée via views (form/tree/kanban/search)
- Sécurité (groups, ACL, record rules)
- Mail/threading, activities, templates
- Scheduled actions (cron)
        

Odoo “dans le monde du web & dev”

Quand Odoo est un très bon choix

• PME/ETI : besoin ERP modulaire, rapide à déployer.
• Cas métier “standard” + quelques personnalisations.
• Besoin de centralisation données et workflows.

Quand il faut cadrer (ou éviter)

• Volonté de “tout customiser comme un produit sur mesure” → risque explosion coûts.
• Très haute charge web transactionnelle type marketplace géante → Odoo peut nécessiter architecture spécifique (cache, offload, microservices autour).
• Contraintes BI/temps réel très strictes → prévoir CDC/ETL/replication vers DWH.

Custom modules : bonnes pratiques

my_module/
- __manifest__.py
- models/*.py
- views/*.xml
- security/ir.model.access.csv
- data/*.xml (actions, sequences, emails)
- static/src/* (JS/CSS, widgets)
            

Website / eCommerce

• CMS + pages, templates QWeb, thèmes.
• eCommerce : produits, variantes, panier, checkout, paiement.
• Portail client : commandes, factures, tickets, documents.

Patterns:
- intégrer un PSP (Stripe/Adyen) via connecteur
- webhooks paiement -> update invoice/payment state
- anti-fraude / logging / monitoring
        

Enterprise & services

• Fonctionnalités additionnelles selon éditions et modules.
• SSO/LDAP, avancé reporting, apps “verticales”.
• Odoo.sh / hosting : pipelines, staging, backups (selon offre).

En entretien : savoir parler “trade-offs” entre on-prem, cloud managé et Odoo.sh.

Compétences attendues (tech)

Deliverables “senior” typiques

• Blueprint repo : structure addons, conventions, guidelines.
• Modules robustes + documentation + tests.
• Integration layer (API) + retries + idempotence + monitoring.
• Plan d’upgrade + check compat + rollout staging → prod.
• Dashboard perf + playbooks incidents (logs, slow queries).

Red flags (pour éviter les projets “painful”)

• Custom massif sans spec claire, sans tests, sans staging.
• Tout le monde admin (sécurité inexistante).
• DB non maintenue, pas de backups, pas d’ILM logs.
• Upgrades repoussés 3 ans → dette énorme.
• Pas de process PR, pas de code review.

Cycle d’une action utilisateur

1. L’utilisateur clique (UI) → action (open view / call method).
2. Le client envoie une requête (souvent JSON-RPC) au serveur.
3. Odoo exécute logique ORM (read/search/write + rules + constraints).
4. Réponse : dataset + view rendering / UI refresh.

Hotspots perf:
- search() sans index
- compute fields en cascade
- loops create/write (N+1)
- record rules coûteuses (domain complexes)
        

Modules : extension propre

• Inheritance : étendre modèles existants sans fork (idéal).
• Views : ajouter champs/onglets/boutons via XML.
• Data : sequences, mail templates, scheduled actions.

Patterns:
- _inherit = "res.partner" (extend)
- new model (business entity)
- server actions / automated actions (low-code)
        

Workers & scheduled jobs

• Cron jobs (scheduled actions) : sync, batch, exports.
• External integrations : retry, dead-letter, idempotence.
• Long tasks : éviter de bloquer les workers HTTP.

Senior tip:
- séparer "web workers" et "cron workers"
- batcher les traitements (commit chunked)
- log structuré + monitoring
        

Relations

Senior tip : comprendre l’impact SQL et éviter les boucles ORM sur des relations massives.

Computed fields : puissance & risques

• Compute : calcul auto, dépendances, store ou not.
• Risques : cascades (recompute), perf, locks, batch updates.

Perf rules:
- compute en batch (vectorisé sur recordset)
- minimiser queries à l'intérieur du compute
- store=True si utilisé en search/sort
        

Contraintes

• Python constraints : règles métier (cohérence)
• SQL constraints : unicité, check (plus robustes)
• Onchange : UX (pré-validation), pas une sécurité

Senior tip:
- "onchange" améliore UX
- "constraints" garantissent l'intégrité
- SQL constraints si possible (plus safe)
        

ACL : règles simples

• Donner le minimum : read par défaut, write limité.
• Créer des groupes métiers propres, éviter “everyone can write”.
• Documenter les exceptions.

Record rules : puissantes mais coûteuses

• Domain complexes → perf (car appliqués sur beaucoup de queries).
• Tester sur volume de données réaliste.
• Éviter les règles “trop globales” sur modèles massifs.

Senior tip:
- une record rule mal pensée peut "tuer" toutes les pages list view
- mesurer et simplifier les domains
        

Traps / anti-patterns

• Abuser de sudo() → contournement de la sécurité.
• Mettre des règles dans l’UI (onchange) au lieu de constraints.
• Exposer des endpoints sans auth forte.

ORM patterns (senior)

Perf quick win:
- regrouper opérations
- utiliser read_group() pour agrégations
- indexer les champs sur lesquels on filtre/trie
        

Controllers web (site / API)

• Endpoints pour portail client, webhooks, intégrations.
• Auth : session, tokens, API keys, signature HMAC selon cas.
• Idempotence : éviter doublons si webhook rejoué.

Integration rules:
- timeouts + retries
- idempotence keys
- logging structuré
- DLQ (dead-letter) pour erreurs non récupérables
        

Cron jobs

• Sync batch (import/export), facturation planifiée, rapprochement.
• Split en petits batches (commit chunked) pour limiter locks.
• Observabilité : logs, métriques, alertes si job échoue.

Actions, menus, context

• Actions = ouvrir une vue, lancer un wizard, rapport, server action.
• Context = valeurs par défaut, paramètres UI.
• Domains = filtrage (attention perf).

QWeb (templates / reporting / website)

• Rapports (invoices, delivery slips) : templates + variables.
• Website : layout, thèmes, composants réutilisables.
• Perf : limiter logique complexe dans templates.

JS / OWL (selon versions)

• Widgets custom, champs UI avancés, interactions.
• Composants OWL : state, props, services, actions.
• Qualité : tests, compat version, éviter hacks DOM.

Senior tip:
- isoler JS custom (widgets) avec API stable
- documenter dépendances version Odoo
- prévoir fallback UX
        

Idempotence (indispensable)

Si un webhook est rejoué:
- on ne doit pas créer 2 factures
- on doit détecter "déjà traité" via clé idempotente
Ex:
- event_id externe stocké dans Odoo
- unique constraint + catch duplicates
        

ETL / DWH / reporting

• Odoo DB ≠ DWH : pour BI lourde, extraire vers un warehouse.
• CDC / replication si near real-time requis.
• Modéliser : dimensions (clients, produits) + faits (ventes, paiements).

Sécurité API

• Auth forte : tokens, API keys, rotation, scopes.
• Validation payloads : schema, signature HMAC.
• Rate limiting & WAF si exposition internet.
• Logs audit (qui/quoi/quand), mais sans données sensibles.

Scaling

• Scale horizontal des workers (stateless si sessions/filestore maîtrisés).
• Séparer cron pour éviter saturation sur web.
• Limiter “long requests” : offload batch vers cron.

Observabilité

• Logs : erreurs, slow endpoints, cron failures.
• DB metrics : locks, slow queries, bloat, IO.
• Alerting : 5xx, latency, queue backlog, disk watermark.

Backups & DR

• Backup Postgres (snapshot + logical selon stratégie).
• Filestore/attachments : sauvegarde cohérente avec DB.
• RPO/RTO définis, test de restore régulier.

Senior rule:
Un backup non testé = pas un backup.
        

PostgreSQL : points clés

• Index sur champs filtrés/tris (et sur foreign keys critiques).
• Maintenance : vacuum/analyze (bloat).
• Locks : batch commits, éviter transactions longues.
• Plans : expliquer les queries lentes (EXPLAIN).

Senior habits:
- mesurer avant/après
- garder une "slow query list"
- corriger d'abord les top offenders (ROI)
        

ORM : règles d’or

• Batch : manipuler recordsets, pas record par record.
• read_group() pour agrégations plutôt que boucles Python.
• Limiter champs lus (read) si dataset énorme.
• Éviter compute non-store si utilisé en search/sort.

Playbook perf (rapide)

1. Identifier page lente (UI) + logs time.
2. Mesurer nombre de queries + top queries.
3. EXPLAIN sur top query → index / rewrite.
4. Optimiser record rules / domains.
5. Re-test sur dataset réaliste.

Data migration

• Transformations : champs renommés, types, relations.
• Scripts d’upgrade idempotents (rejouables).
• Vérifications : totals compta, stock valuation, documents.

Tests (ce qui compte)

• Flux critiques : sale → invoice → payment, purchase → receipt.
• Permissions : users non-admin (record rules).
• Perf : pages/listes principales.
• Intégrations : webhooks, exports, ETL.

Rollout & rollback

• Fenêtre de maintenance, freeze changes, backup avant.
• Plan rollback clair (snapshots + filestore + DB).
• Observabilité renforcée post-upgrade.

Senior rule:
upgrade sans rollback = pari dangereux.