Six plateformes en production, d'Odoo 11 à Odoo 19. Des modules personnalisés allant de onze à quatre-vingt-quinze par plateforme. Des modules du core que nous avons rétroportés, d'autres portés vers l'avant, et une poignée de mixins dont nous héritons partout où nous passons.
Odoo est la colonne vertébrale de l'atelier. Quand un client arrive avec un métier déjà partiellement modélisé — clients, contrats, comptabilité, CRM, RH, facturation — c'est là que nous déposons la logique métier et que nous laissons le reste de l'équipe travailler vraiment. Ce qu'il reste à construire, c'est la part qui leur appartient vraiment.
Nous écrivons du Odoo personnalisé depuis 2016, en production chaque année depuis. Six plateformes en main aujourd'hui, entre onze et quarante-cinq modules chacune sur le bas de la fourchette, quatre-vingt-quinze sur le haut. Versions onze à dix-neuf. Nous avons migré des plateformes vers l'avant (Odoo 8 → 16 via un pipeline ETL sur mesure), rétroporté des fonctionnalités depuis des versions plus récentes (Peppol d'Odoo 19 vers 16), et tenu des politiques de déploiement à deux environnements qui n'ont pas produit d'incident destructeur en quatre ans.
Les parties intéressantes d'une mission Odoo ne sont jamais où les plaquettes commerciales le promettent. Elles vivent dans les coutures — l'endroit où un receveur Peppol belge et un module Odoo 16 ne sont pas d'accord sur l'EAS à mettre sur le partenaire ; l'endroit où une facture remplie par OCR perd silencieusement son drapeau « importable » parce qu'une écriture a eu lieu sans le bon contexte ; l'endroit où `requests` se fait monkey-patcher par une transitive du SDK Knock et casse la gestion d'exceptions des moyens de paiement, jusqu'à ce qu'on inverse le patch à l'import. Nous nommons ces endroits, nous les réparons, et nous écrivons ce que nous avons appris — pour que le prochain ingénieur ne revive pas la même histoire.
De onze à quatre-vingt-quinze modules par plateforme. Mixins, règles de sécurité, champs calculés, composants OWL, wizards, scripts de migration versionnés par module. La forme qui survit aux upgrades.
D'Odoo 11 (Wood, intendance d'un legacy) à Odoo 19 (Rebound, en production). À l'aise pour rétroporter une fonctionnalité depuis une version plus récente, porter une plateforme vers l'avant à travers des versions majeures, et lire le code source quand la doc se tarit.
E-facturation Peppol (conformité belge, rétroportée 19 → 16), téléphonie Vonage (portée depuis Salesforce), bus d'événements RabbitMQ, gateway FastAPI, suivi d'expédition UPS, synchronisation Brevo, notifications Knock + Slack, Microsoft Calendar, Mapbox.
Modèles abstraits Odoo — flag.mixin, audit.model, knock.model, AvataqDocumentS3Sync — dont héritent les modules métier. On paie une fois, chaque nouveau module récolte les dividendes.
Odoo + Django sur un seul Postgres (Avataq, MySpecialist) ; Odoo + gateway FastAPI et bus RabbitMQ (DISH BSS) ; Odoo + AWS Lambdas + GCP Cloud Run (Procell). La bonne stack pour chaque couche, et les coutures tenues.
Odoo 8 → 16 via ETL sur mesure, schéma par schéma (MySpecialist). Symfony rebâti en Django propre à côté d'Odoo (MySpecialist également). Salesforce → Odoo, plus de quatre-vingt-dix modules, licence à plusieurs millions d'euros retirée (DISH BSS).
Suites Playwright qui pilotent les écrans Odoo en direct. Une régression nocturne à 2h UTC (Rebound) qui nous prévient des défaillances avant un utilisateur. Pipelines end-to-end couvrant devis → facture → paiement → satisfaction (MySpecialist).
Workflow à deux environnements, staging-first, prod sur demande explicite. Mises à jour de modules via XML-RPC. Quatre ans de production MySpecialist sans incident destructeur.
account_peppol ré-implémenté contre l'ancien wizard d'envoi (account.invoice.send au lieu d'account.move.send en Odoo 19). XML régénéré avant ré-envoi car l'attachment stocké peut dériver. EAS belge overridé pour que les partenaires postent réellement — le core livre COUNTRY_EAS['BE'] = 9925, mais les receveurs utilisent 0208. Les factures bloquées ont un bouton de revalidation au lieu d'un archivage silencieux.
requests.models.complexjson inversé à l'import du module (knockapi importe simplejson qui le monkey-patch, ce qui casse les exceptions des moyens de paiement Odoo). is_manually_modified respecté via contexte pour que les factures remplies par OCR restent importables. _import_retrieve_and_fill_partner_bank_details cherche par sanitized_acc_number pour que 'BE55 7350' ne percute pas la contrainte d'unicité. Chaque piège du mainline documenté à côté du fix.
Champs domain toujours invisibles, templates OWL des boutons de liste, is_manually_modified sur account.move, t-foreach keyé par app.name, fieldDependencies par défaut à readonly: true. Une vingtaine de pièges Odoo 19 catalogués dans le CLAUDE.md du module pour que le prochain ne les revive pas.
Trois modèles abstraits — flag.mixin (n'importe quel enregistrement flaggable avec une raison), audit.model (champs d'audit invisibles côté RH), knock.model (les transitions d'état déclenchent automatiquement les workflows Knock). Les 45 modules métier de Rebound en héritent ; les nouveaux modules récoltent les dividendes gratuitement.
L'explorateur de documents Django d'Avataq et Odoo partagent une seule base. Des URL S3 présignées à soixante secondes gardent les binaires hors mémoire. Un mixin AvataqDocumentS3Sync rend un nouvel uploader affaire d'un seul inherit. Odoo écrit ; Django indexe et lit ; personne ne croise.
Chaque module suit le versioning 19.0.X.Y.Z. Quand des données doivent bouger, on incrémente la version et on dépose migrations/19.0.X.Y.Z/pre-migrate.py ou post-migrate.py avec une fonction migrate(cr, version). La pipeline les ramasse ; les données bougent avec le code ; rien à la main sur la prod.
Plateforme SaaS belge qui met en relation des clients avec des prestataires indépendants vérifiés, en Belgique et en Suisse. Reprise en 2022 sous forme d'une couche Symfony branchée sur Odoo 8 — rebâtie en Django propre sur Odoo 16, et tenue depuis par les mêmes trois ingénieurs.
Une plateforme Odoo 19 qui fait tourner l'entreprise de bout en bout — ventes, CRM, RH, projets, treatment, cashflow, audit GAAP. Une quarantaine de modules personnalisés, une régression Playwright nocturne sur AWS, et le premier projet où nous tenons les trois sièges en parallèle : Dan à l'architecture et au DevOps, Dina aux modules Odoo, Hasina à l'automatisation des tests.
Une plateforme multi-stack pour une entreprise américaine d'esthétique et de traitements — un ERP Odoo 18, un site Next.js sur AWS, des Lambdas pour le suivi des expéditions UPS et la vérification de liens, des services GCP Cloud Run pour des pipelines de vérification OpenAI. Nous tenons les coutures : l'estate Terraform AWS, les intégrations serverless, et le QA load testing.
Une stack Salesforce à plusieurs millions d'euros, rebâtie sur Odoo 16 pour la branche restauration-tech de METRO — le back-office commercial qui propulse DISH pour des dizaines de milliers de restaurants indépendants en Europe. Nous avons mené la recréation fonctionnelle : passerelle FastAPI, bus d'événements RabbitMQ, téléphonie Vonage, flux de vente et catalogue produit.
Une plateforme hybride Odoo 16 + Django pour la gestion de bourses d'études autochtones, des inscriptions, de la facturation et de la documentation. Deux stacks sur une seule base Postgres, avec les documents dans S3 derrière des URL de téléchargement S3 présignées de courte durée.
Une plateforme Odoo 11 française pour Wood, fournisseur d'équipement de piscines — bâtie autour d'un configurateur produit piloté par métadonnées qui laisse les clients spécifier leur piscine via un questionnaire dynamique dont toute la forme tient en lignes de base de données.