Développeur Odoo : ORM, record rules, OWL et passage de version

Odoo sort une version majeure par an. La 19 date de septembre 2025, la 20 de septembre 2026, et beaucoup de bases tournent encore en 16 ou en 17. Le développeur passe donc une bonne partie de son temps à porter des modules spécifiques d'une version à l'autre, à côté des développements neufs demandés par les consultants fonctionnels. Le poste se trouve chez les intégrateurs partenaires d'Odoo comme chez les entreprises qui ont internalisé leur ERP.

Un développeur Python généraliste n'est pas productif tout de suite. L'ORM d'Odoo a ses propres règles : un champ calculé reçoit un ensemble d'enregistrements, une méthode héritée doit appeler super(), un onchange ne se déclenche pas lors d'un import. Les droits se posent sur deux niveaux, les droits d'accès par modèle et les record rules par enregistrement. Odoo 20 change d'ailleurs ce second niveau, en plaçant un domaine directement sur le droit d'accès.

Demandez au candidat sur quelles versions il a travaillé et ce qu'il a dû changer en portant un module, par exemple la disparition d'attrs dans les vues en 17 ou le renommage des vues tree en list en 18. Un profil qui a mené une migration en parle avec précision. Le PDF contient l'entretien complet sur six axes et un cas de 20 minutes.

Le framework Odoo vu du développeur

ORM et modèles Python

Chaque objet métier (client, commande, facture) est une classe Python qui hérite de models.Model. L'ORM traduit les opérations en SQL pour PostgreSQL et manipule des ensembles d'enregistrements, jamais une ligne isolée. Les champs calculés, leurs dépendances et leur stockage en base sont la première source de lenteur dans un module spécifique.

Héritage de modèles et de vues

On étend un modèle existant avec _inherit, on en crée un nouveau à partir d'un autre avec _name et _inherit, ou on le relie par délégation avec _inherits. Les vues XML s'étendent de la même façon, par des vues héritées qui ajoutent ou masquent des éléments avec xpath. Modifier directement le code standard est la faute qui bloque les montées de version.

Modules et manifeste

Un développement se livre sous forme de module, décrit par un fichier __manifest__.py qui liste ses dépendances, ses fichiers de données et ses ressources front. Une dépendance oubliée passe inaperçue sur la base de développement et casse l'installation sur une base neuve.

OWL et client web

OWL est le framework JavaScript à composants d'Odoo, utilisé dans le client web et le point de vente. Le développeur s'en sert pour créer un widget de champ, une vue particulière ou un écran de saisie. Les versions récentes ont abandonné l'ancien système de widgets, un CV qui s'arrête à Odoo 14 n'a pas forcément pratiqué OWL.

QWeb et rapports PDF

QWeb est le moteur de templates XML d'Odoo. Il sert aux rapports PDF (factures, bons de livraison), générés avec wkhtmltopdf, et aux pages du site web. La plupart des demandes portent sur un rapport standard à adapter par héritage, avec un bloc différent selon la société ou la langue du client.

Droits d'accès et record rules

Les droits d'accès, déclarés dans ir.model.access.csv, disent quel groupe peut lire, créer, modifier ou supprimer un modèle. Les record rules filtrent ensuite les enregistrements visibles, par exemple les seules opportunités d'un commercial. Les notes de version d'Odoo 20 annoncent leur remplacement par un domaine posé sur le droit d'accès, vérifiez la version de votre base.

API externe JSON-2

Les connecteurs (site e-commerce, logiciel métier, outil de paie) appellent Odoo depuis l'extérieur. XML-RPC et JSON-RPC sont dépréciés et leur retrait est annoncé pour Odoo 22, à l'automne 2028. L'API JSON-2 les remplace, avec un appel par modèle et par méthode et une clé API passée en jeton bearer.

Migrations, Odoo.sh et tests

La base standard se migre avec le service d'upgrade d'Odoo pour l'édition Enterprise, ou avec OpenUpgrade de l'OCA en Community. Les modules spécifiques se portent à la main, avec des scripts de migration. Odoo.sh fournit des branches de développement, de préproduction et de production, et les tests s'écrivent en Python avec TransactionCase ou HttpCase.

Deux éditions coexistent. Community est open source, Enterprise ajoute des applications sous licence comme Studio, la comptabilité complète ou le service d'upgrade. Un module spécifique doit dire de laquelle il dépend. L'hébergement change aussi le travail : sur Odoo Online, le code Python spécifique n'est pas autorisé, sur Odoo.sh et sur un serveur propre il l'est. Le développeur dialogue en continu avec les consultants fonctionnels, qui écrivent le besoin, et doit comprendre assez la vente, le stock ou la comptabilité pour poser les bonnes questions. La certification Odoo existe par version et porte surtout sur le fonctionnel. Le niveau technique se vérifie en entretien, sur du code.

Six sujets techniques à noter pour un développeur Odoo

• ORM, recordsets et performance
• Héritage de modèles et de vues
• Front-end OWL et rapports QWeb
• Droits d'accès et multi-société
• Intégrations, API et traitements planifiés
• Migrations de versions et tests

Questions Odoo sur l'ORM, les vues, les droits et les migrations

Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.

1. Question 1 · confirmé

   Une vue liste de 50 000 commandes met dix secondes à s'afficher depuis que vous avez ajouté un champ calculé. Que regardez-vous ?

   Une bonne réponseLe compute du champ, qui tourne pour chaque ligne affichée s'il n'est pas stocké. Le cas typique est une boucle qui lance un search() par enregistrement, donc autant de requêtes SQL que de lignes. Il confirme avec le log SQL ou le profileur du mode développeur, puis calcule sur tout l'ensemble en une requête groupée (_read_group, mapped), ou stocke le champ avec store=True et des dépendances @api.depends exactes. Il ajoute un index si le champ sert de filtre.

   Signal d'alerte« J'ajoute un cache » sans avoir mesuré, ou store=True posé sans vérifier les dépendances, ce qui donne des valeurs fausses qui ne se recalculent jamais. Ignorer que le compute reçoit plusieurs enregistrements à la fois.

2. Question 2 · junior à confirmé

   Héritage classique, par prototype, par délégation : lequel prenez-vous pour ajouter un champ aux contacts, et lequel pour créer un modèle à partir d'un modèle existant ?

   Une bonne réponsePour ajouter un champ à res.partner, _inherit seul : le modèle existant est étendu, dans la même table. Pour un nouveau modèle qui reprend la structure d'un autre, _name nouveau avec _inherit : c'est l'héritage par prototype, avec sa propre table. La délégation (_inherits) crée un modèle lié au parent par un many2one obligatoire, dont les champs restent accessibles, comme res.users avec res.partner.

   Signal d'alerteCopier le module standard pour le modifier, ou toucher directement aux fichiers d'Odoo. Confondre _inherit et _inherits.

3. Question 3 · confirmé

   Vous devez ajouter un widget de champ dans le client web. Comment construisez-vous et déclarez-vous le composant OWL ?

   Une bonne réponseUne classe qui hérite de Component, avec son template XML (t-name) et les props standard des champs. Il l'enregistre dans le registre des champs (registry.category("fields")), déclare les fichiers JS et XML dans la section assets du manifeste, sous web.assets_backend, puis l'utilise dans la vue avec widget="...". Pour parler au serveur, il passe par le service orm avec useService, appelé dans onWillStart.

   Signal d'alerteUne réponse en jQuery ou en widget.extend, c'est-à-dire le front d'Odoo 14 et avant. Du JavaScript injecté dans un template à la main.

4. Question 4 · confirmé

   Les commerciaux ne doivent voir que leurs opportunités, les managers celles de leur équipe. Comment le mettez-vous en place ?

   Une bonne réponseDes groupes hiérarchisés (implied_ids), des droits d'accès par groupe pour la lecture et l'écriture, puis des record rules : un domaine sur user_id pour le groupe commercial, un domaine plus large pour le groupe manager. Il sait que les règles de groupes différents s'additionnent (OU) et que les règles globales s'appliquent en plus (ET). Il teste avec un vrai utilisateur commercial, jamais avec l'administrateur. Sur Odoo 20, il vérifie le nouveau modèle de domaine sur les droits d'accès.

   Signal d'alerteCacher des menus ou des champs avec groups= dans la vue et considérer que c'est sécurisé. Tester uniquement en administrateur, qui passe outre les règles.

5. Question 5 · confirmé

   Un site e-commerce externe crée des commandes dans Odoo par XML-RPC. Que changez-vous pour les versions à venir ?

   Une bonne réponseIl sait que XML-RPC et JSON-RPC sont dépréciés, avec un retrait annoncé pour Odoo 22 (automne 2028). Il prévoit le passage à l'API JSON-2, sur /json/2/<modèle>/<méthode>, avec une clé API en jeton bearer et un utilisateur technique aux droits limités. Il protège aussi l'intégration contre les doublons : une référence externe unique pour chaque commande, vérifiée avant création.

   Signal d'alerte« XML-RPC fonctionne, on garde. » Un connecteur qui utilise le compte administrateur avec son mot de passe en clair dans la configuration du site.

Odoo, versions et test technique : vos questions

Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.