Compétences
Le développement Odoo consiste à étendre un ERP sans rompre la cohérence de son modèle métier, de ses droits et de ses mécanismes internes. Un module peut ajouter des modèles Python, des champs, des vues XML, des rapports QWeb, des actions planifiées, des contrôleurs API, des données de configuration et des scripts de migration. La difficulté n'est pas seulement de faire fonctionner chaque composant : il faut comprendre l'ORM, les héritages, le contexte d'exécution, les dépendances entre modules et les conventions du framework afin qu'une personnalisation reste installable, testable et compatible avec les versions suivantes.
La compétence inclut également la traduction du besoin. Dans un ERP, une règle technique représente souvent une décision comptable, commerciale, logistique ou de sécurité. Je dois identifier les données fiables, les utilisateurs autorisés, les exceptions et les effets sur les autres applications. Les ACL accordent des opérations au niveau d'un modèle, les record rules limitent les enregistrements accessibles et les groupes se combinent pour définir les privilèges d'un utilisateur ; masquer un écran n'est donc jamais une protection suffisante.
Enfin, développer pour Odoo implique de savoir choisir entre le standard, la configuration, Studio et un module versionné. Je privilégie le standard lorsqu'il répond au besoin, la configuration lorsque la règle doit rester pilotable par les utilisateurs et le code lorsque le comportement exige une logique durable, révisable et déployable. Cette frontière réduit la dette technique et facilite les migrations.
Les notes de version d'Odoo 19 recensent des évolutions transversales dans les activités, documents clients, interfaces et applications métier. Pour un développeur Odoo, chaque nouvelle version implique de comprendre les nouveautés natives avant d'adapter les modules et personnalisations existants.
Consulter la source : OdooJ'ai pris en charge la migration successive d'Odoo 16 vers 17, 18 puis 19 pour un ERP utilisé par 20 utilisateurs internes directs. Le projet comprenait 16 modules sur mesure, des extensions tierces et de nombreuses personnalisations Studio. Pour chaque étape, j'ai adapté les modèles, méthodes Python, vues XML et XPath devenus incompatibles, recherché les changements dans le code source, récupéré ou corrigé les modules tiers et contrôlé les données PostgreSQL ainsi que le filestore. La recette couvrait les processus métier, les droits et les intégrations externes, avec une sauvegarde complète comme point de retour arrière.
Résultat — Odoo 19 a été mis en production sans perte définitive de données signalée. Les fonctions utiles ont été conservées, des personnalisations Studio obsolètes supprimées et les intégrations principales modernisées ; la durée d'interruption n'a pas été mesurée de façon publiable.
J'ai développé et maintenu seize modules qui complètent l'ERP pour la comptabilité, les ventes, l'inventaire, la logistique et l'administration des ventes. Le module de relance des impayés illustre la démarche complète : recueil du besoin, matrice de décision, paramètres, modèles Python, vues XML, droits, action planifiée, modèles de courriel, rapport joint, tests en staging, validation métier, déploiement Odoo.sh et formation. D'autres modules enrichissent les produits, les rapports QWeb, les marges de facture ou les documents logistiques. Je sélectionne uniquement les dossiers et composants utiles au besoin au lieu de reproduire mécaniquement une structure complète.
Résultat — Ces modules automatisent des tâches quotidiennes, rendent les documents plus complets et mettent des indicateurs de pilotage à disposition pendant l'exercice. Le module de relance automatise notamment le contrôle des factures et les étapes de relance ; son gain de temps reste à mesurer.
Le site B2B et le hub d'intégration dépendent des clients, produits, stocks et commandes conservés dans Odoo. J'ai créé des routes API ciblées lorsque les mécanismes standard ne répondaient pas au contrat d'échange et j'ai participé à l'adaptation vers l'API JSON-2 d'Odoo 19. Pour éviter qu'une solution d'interface n'expose des données, je raisonne séparément sur les ACL, les groupes, les record rules et les champs sensibles. Lorsqu'un comportement paraît incohérent, je lis les logs, suis l'héritage des méthodes et consulte le code source plutôt que de multiplier les contournements dans les vues.
Résultat — Les systèmes externes ont retrouvé leurs échanges principaux après la migration et les modules internes restent maîtrisés dans le dépôt versionné. Cette capacité à descendre jusqu'au framework me permet de corriger la cause d'un défaut et pas seulement son affichage.
Pilotage actuel des tâches Odoo dans Jira
Capture du 17 septembre 2026. Le tableau regroupe les demandes Odoo par état, de l'analyse à la revue puis à l'attente de mise en production. Il illustre mon workflow quotidien actuel et non l'historique du projet de migration.
Les éléments de preuve décrivent des épisodes précis. Cette synthèse les replace dans les études de cas complètes : le contexte, ma contribution et le résultat permettent d'observer ce que cette compétence a rendu possible, avec le niveau de prudence nécessaire sur chaque résultat.
J'estime avoir un niveau avancé. Je peux concevoir, migrer, sécuriser, déployer et maintenir des modules couvrant plusieurs services, et je sais rechercher un comportement dans le code source. Je ne me considère pas expert : le moteur comptable, les optimisations profondes de l'ORM et certaines interactions internes restent des domaines où je dois encore mesurer davantage avant de modifier.
C'est la compétence technique la plus importante de mon profil actuel. Elle combine Python, PostgreSQL, XML, API, sécurité, déploiement et compréhension des processus d'entreprise. Elle correspond aussi à mon objectif de devenir développeur confirmé et référent technique Odoo.
J'ai appris Odoo à partir de zéro en alternance, en étant rapidement le seul développeur interne chargé des demandes. Les modules, incidents et migrations m'ont fait progresser plus vite qu'un parcours uniquement théorique, mais cette vitesse explique aussi certaines premières implémentations trop dépendantes de valeurs figées.
Je conseille de commencer par le processus métier et les fonctions standard avant d'écrire un module. Ensuite, il faut séparer configuration et algorithme, tester avec des comptes et des données représentatifs, puis lire le code source dès que le comportement réel contredit l'hypothèse. Studio est utile pour une modification légère, mais le code versionné devient préférable lorsque la logique est critique ou durable.
Consolider un niveau avancé jusqu'à pouvoir définir l'architecture d'un ensemble de modules, préparer les migrations en amont et accompagner d'autres développeurs sur les choix de sécurité, performance et maintenabilité.
Je poursuis la lecture du code source et de la documentation officielle, l'étude des scripts de migration et l'automatisation des tests Odoo. Les prochains axes pratiques sont la performance du calcul de marge, les intégrations JSON-2 et la future architecture de Business Intelligence connectée à l'ERP.
