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.
Wood est un fournisseur français d'équipement de piscines. Leur plateforme Odoo 11 fait tourner le catalogue et la chaîne de commande — et en son cœur, 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.
Le configurateur, c'est la partie intéressante. `product.abstract` est le template de tête ; `config.block`, `config.fieldset`, `config.question` et `config.question.value` décrivent la forme du formulaire ; les lignes `config.condition.*` portent les règles de visibilité et de validation sous forme de chaînes, évaluées au runtime ; `config.controller` câble les questions entre elles ; `config.global.value` porte les valeurs calculées au niveau du formulaire. `product.abstract.extract()` sérialise tout l'arbre en JSON ; un widget jQuery reconstruit le formulaire côté front ; `sale.order.create_from_vals()` relit les réponses.
L'arrangement donne à Wood un configurateur qu'ils peuvent faire grandir sans nous — nouvelles questions, nouvelles conditions, nouvelles valeurs calculées, tout côté admin. Il concentre aussi la logique métier dans des chaînes évaluées par `eval()`, ce qui devient l'endroit qui tire à mesure que le formulaire s'étend. Nous avons documenté un plan en huit phases dans `docs/configurator.md` pour passer du pilotage par métadonnées au pilotage par code ; le plan est là pour quand le travail sera prêt.
Nous sommes sur la plateforme depuis 2021. La cadence est légère — une poignée de commits par an, principalement des extensions du configurateur, du travail occasionnel sur la facturation et le stock, l'intégration Dropbox pour les sauvegardes. Odoo 11 est largement hors support mainstream ; le choix de Wood d'y rester est délibéré, et notre travail est de garder la plateforme stable sur une version que le reste du monde a dépassée.
Cœur : modèle de données du configurateur, logique devis / commande, prix par formules de composition.
Extensions de base partagées par tous les addons nembia_*.
Personnalisations de la facturation avec localisation française.
Gestion de stock avec notifications SMS sur événements.
Service après-vente : tickets, suivi, historique.
Extensions des controllers web qui portent les pages publiques.
Sauvegardes nocturnes vers Dropbox (identifiants gitignored).
`product.abstract.extract()` sérialise l'arbre du formulaire ; le widget jQuery reconstruit l'UI ; `sale.order.create_from_vals()` relit les réponses.
Plan de migration en huit phases pour passer du métadonnées vers le code — écrit quand on a touché le plafond de l'architecture, conservé dans le repo pour le jour où ça deviendra le travail.
Le questionnaire de spécification piscine, ce sont des lignes en base, pas des lignes de code. Nouvelles questions, nouvelles conditions de visibilité, nouvelles valeurs calculées — tout côté admin. On paie cette souplesse en chaînes évaluées par `eval()` ; on la récupère par un configurateur que Wood fait grandir sans nous.
Wood tourne sur Odoo 11, bien au-delà du support mainstream. Le choix du client d'y rester est délibéré — pour le configurateur et la logique métier bâtie autour. Notre travail est de garder la plateforme stable sur une version que le reste du monde a dépassée. La cadence est petite ; la plateforme est toujours joignable.
Nous savons que la complexité du configurateur a un plafond. `docs/configurator.md` pose un plan en huit phases pour passer du pilotage par métadonnées au pilotage par code — ce qu'on changerait, dans quel ordre, et ce qu'on validerait à chaque étape. Le plan existe pour quand le travail sera prêt, pas avant.
Visibilité des questions et validation de champs vivent comme des chaînes dans les lignes `config.condition.*`, évaluées par `eval()` au runtime. La souplesse est l'objectif ; l'évaluateur est sandboxé aux noms connus pour qu'une condition mal formée ne casse pas le formulaire.
`product.abstract.extract()` sérialise tout l'arbre du configurateur en JSON. Le front jQuery reconstruit l'UI depuis ce payload — visibilité, dépendances, totaux calculés. Le back reste la source de vérité ; le front reste jetable.
Le prix sort de `product.abstract.composer` — des formules de composition qui lisent les réponses du client et produisent les lignes de commande. Les nouvelles variantes produit ne demandent pas de code ; elles demandent quelques lignes dans le modèle composer.