Dix personnalisations qui ont leur place chez un manufacturier à culture d'ingénierie
Les manufacturiers à culture d'ingénierie — ceux où le CTO est assis à côté du COO et où la base de code est traitée comme un produit, pas un palliatif — ont une exigence différente envers les travaux Odoo. Les correctifs rapides et le monkey-patching ne survivent pas à une mise à niveau. Les dix personnalisations ci-dessous reposent sur une approche propre et modulaire : configurer d'abord, étendre via composants OWL ou actions serveur ensuite, et ne livrer un module sur mesure que lorsque le périmètre métier vit réellement en dehors d'Odoo standard. Les dix fonctionnent sur Odoo 19 et survivent à une migration de version lorsqu'elles sont écrites ainsi.
Octura livre cela en ingénierie de modules sur mesure à prix fixe, avec des ingénieurs seniors sur chaque projet — pas de consultants juniors facturés au tarif senior.
Pile de personnalisation par couches — configurer, OWL, puis module sur mesure
La personnalisation la plus précieuse qu'une usine à culture d'ingénierie adopte est une discipline, pas une fonctionnalité : une pile par couches. Couche un : configuration — champs Studio, actions automatisées, actions serveur dans la base. Couche deux : présentation — composants OWL 3, vues personnalisées, widgets JS dans un fin module frontend. Couche trois, et seulement trois : module Python complet avec nouveaux modèles, sécurité et logique ORM. La règle : ne jamais monter d'un cran quand un cran plus bas suffit. Le coût de mise à niveau d'un module couche trois vaut 10× celui d'un widget couche deux ; le coût d'un widget couche deux vaut 10× celui d'une action serveur. Documentez la pile dans le wiki interne et imposez-la en revue de code.
Actions serveur pilotées par IA pour les règles métier non triviales
Quand une règle est trop complexe pour une action automatisée mais trop petite pour un module — tarification dépendant de trois attributs client, calcul de délai à travers un graphe de gammes, retenue de crédit qui croise quatre signaux — utilisez une action serveur pilotée par IA. Un snippet Python tourne dans l'environnement Odoo avec accès ORM complet ; l'appel LLM (Claude, GPT ou local) est réservé à la part réellement floue (classer cet e-mail, résumer cet historique d'OF, rédiger cette note client). Gardez la logique déterministe en Python, cantonnez l'IA à un signal, journalisez chaque prompt et réponse. C'est ici que les équipes à culture d'ingénierie cessent d'écrire des arbres if/elif de 200 lignes.
Pilotes IoT pour le matériel d'atelier
L'usine a des capteurs, des balances, des scanners, des imprimantes d'étiquettes, des clés dynamométriques, des systèmes de vision — la plupart parlent Modbus, OPC-UA ou série. Le cadre IoT Box d'Odoo gère la couche de connexion ; la personnalisation est le pilote au-dessus : une petite classe Python qui traduit le protocole en événements Odoo. Une fois le pilote dans votre module, l'appareil devient citoyen de première classe sur l'ordre de fabrication — captures de poids sur l'ordre de travail, valeurs de couple sur le point qualité, lectures scanner qui font avancer l'opération. C'est la personnalisation atelier à plus fort levier qu'une entreprise d'ingénierie livre.
Tableaux de bord personnalisés avec OWL + module Feuilles de calcul
Le COO veut un tableau de bord. La réponse par défaut est un module sur mesure avec graphiques. La bonne réponse est le module Feuilles de calcul plus un petit composant OWL 3. Feuilles de calcul fournit une source Odoo en direct avec formules, tableaux croisés et mise en forme conditionnelle qu'un utilisateur finance peut éditer. OWL apporte le widget sur mesure dont vous avez réellement besoin — une tuile temps réel d'utilisation des centres, une jauge de rendement première pièce qualité, un suiveur de conversion de trésorerie. Les câbler dans une vue kiosque. Pas de module Python, pas de coût de mise à niveau, et le COO édite lui-même le tableau.
Intégrations aux systèmes internes via API REST + webhooks
Les entreprises à culture d'ingénierie ont déjà une pile — un coffre CAO, un PLM, une appli atelier maison, un entrepôt de données, un portail sur mesure. L'intégration appartient à la couche API REST et webhooks, pas à un ETL parallèle. Odoo expose XML-RPC et JSON-RPC par défaut ; superposez un contrôleur REST propre avec routes versionnées, validation de schéma et jetons OAuth2. Couplez à des webhooks sortants sur les événements clés (OF confirmé, lot expédié, facture comptabilisée) pour que les systèmes en aval réagissent au lieu de scruter. C'est le seul motif d'intégration qui ne casse pas aux mises à niveau Odoo.
Scripts de migration à chaque version
La raison pour laquelle la plupart des personnalisations Odoo cassent à la mise à niveau n'est pas la personnalisation — c'est la dérive de schéma. La parade est d'embarquer un script de migration dans chaque module sur mesure : un dossier migrations/<version>/ avec du Python pré et post-migration qui traite chaque renommage de champ, chaque scission de modèle et chaque remplissage de données introduit par la release. Exécutez-le en CI contre une copie de prod. Les entreprises à culture d'ingénierie traitent le script de migration comme partie intégrante de la définition de fini — pas de script, pas de merge. Dès la première release sous cette discipline, le coût de mise à niveau chute d'un ordre de grandeur.
CI/CD avec GitHub Actions contre un vrai PostgreSQL
Les modules sur mesure méritent la même chaîne qu'un produit : CI/CD avec GitHub Actions exécutant les tests contre une vraie instance PostgreSQL, pas SQLite ni un mock. Le workflow installe le module sur un conteneur Odoo neuf, lance la suite de tests, exécute le script de migration et publie la couverture sur la PR. Ajoutez un déploiement staging miroir de la production à chaque merge sur main, et une promotion production manuelle conditionnée par un tag. L'investissement se rembourse la première fois qu'un ingénieur junior livre une régression et que la chaîne l'attrape avant la revue. Walk-through dans CI/CD avec GitHub Actions.
Audit des modules OCA avant tirage
L'Odoo Community Association publie des centaines de modules utiles. Ils ne se valent pas tous. Avant qu'un module tiers entre dans votre dépôt, lancez un audit OCA : lisez le code pour les odeurs de sécurité (SQL brut, règles d'accès manquantes, sudo dangereux), vérifiez la compatibilité avec votre version d'Odoo, le rythme du mainteneur, l'existence de tests. Un module OCA est du code amont que vous possédez désormais — traitez-le comme une dépendance, pas comme un cadeau. Les cinq heures d'audit par module sont l'assurance la moins chère qu'une équipe à culture d'ingénierie achète.
Discipline de développement : modèles, vues, sécurité
Quand un module couche trois est réellement justifié, scaffoldez-le correctement du premier coup : __manifest__.py propre, modèles dans models/, vues dans views/ séparées par type de record, sécurité dans security/ir.model.access.csv plus règles d'enregistrement, données dans data/, démos dans demo/, tests dans tests/. Chaque modèle reçoit _description, _order, _sql_constraints au besoin, et au minimum un test unitaire sur la contrainte. Les équipes à culture d'ingénierie livrent des modules qui se lisent comme ceux d'Odoo — parce que c'est la base contre laquelle ils seront migrés. Pattern dans développement de modules sur mesure.
Performance — maîtrise du planificateur de requêtes et stratégie d'indexation
Les modules sur mesure deviennent des problèmes de performance précisément quand les données dépassent le dev. La parade n'est pas de jeter du matériel dessus — c'est la maîtrise du planificateur PostgreSQL. Exécutez EXPLAIN ANALYZE sur chaque appel ORM lent ; ajoutez index=True sur chaque champ qui filtre ou joint ; créez des index composites pour les WHERE multi-champs générés par l'ORM ; profilez avec le log SQL Odoo en production. L'usine à culture d'ingénierie livre un module avec deux index B-tree pensés en amont ; l'usine moyenne livre le même module et ajoute trois index un an plus tard sous pression. Walk-through dans maîtriser le planificateur de requêtes Odoo 19.
Comment évaluer un partenaire Odoo sans se faire avoir
Les fonctionnalités comptent ; le partenaire qui les livre compte davantage. Huit vérifications séparent les partenaires qui livrent de ceux qui apprennent sur votre budget :
- Certification Odoo officielle (Ready, Silver ou Gold) — pas seulement « nous travaillons avec Odoo ».
- La personne de la découverte est celle qui construit. Les passages de relais perdent le périmètre.
- Prix fixe après découverte. La régie est un aspirateur à budget en ERP.
- Ingénieurs seniors sur le projet. Octura ne livre qu'avec des seniors — demandez à tout partenaire potentiel qui écrit votre code.
- Deux clients de référence prêts à un appel. « Beaucoup de clients » sans nom est un signal d'alerte.
- Spécialité verticale en fabrication. Un généraliste qui livre une usine par trimestre n'est pas le partenaire.
- Méthodologie documentée multi-phases. Découverte → configuration → personnalisation → migration → mise en production → hyper-care.
- Tarifs publiés en toute transparence. « Devis sur mesure » est acceptable ; refuser un chiffre de départ ne l'est pas.
La version longue est dans l'audit partenaire Odoo.