↓

Développement Odoo sur mesure en Belgique, la méthode pour personnaliser sans vous enfermer

Le développement Odoo n’est pas un point de départ mais un dernier recours. Voici comment dosser paramétrage, Studio, modules existants et code, et comment choisir qui le réalise.

Mis à jour le 28 octobre 2026

Le développement Odoo est souvent la ligne la plus discutée d’un budget, et pourtant la plus évitable. Une PME de Charleroi, de Gand ou de la périphérie bruxelloise qui part du principe que « notre métier est particulier » finit parfois avec un logiciel que plus personne n’ose mettre à jour. La personnalisation d’Odoo a sa place, mais elle suit une échelle : on ne grimpe d’un barreau que si le précédent ne suffit pas.

Cette page vous donne cette échelle, les conséquences de chaque choix sur les mises à jour, et des critères concrets pour juger un développeur ou un intégrateur. Le prix de la licence lui-même est traité dans la page prix d’Odoo.

L’échelle de personnalisation : du paramétrage au code

Avant d’écrire une seule ligne, vérifiez ce que le produit sait déjà faire. Dans l’ordre, du moins risqué au plus risqué :

Niveau Ce que c’est Effet sur les mises à jour Qui l’exécute
Paramétrage Options, règles et documents prévus par l’éditeur Aucun Consultant fonctionnel
Studio Personnalisation sans code dans l’interface Faible, à contrôler Consultant ou utilisateur formé
Module existant Extension de l’écosystème ou de la communauté Dépend de son éditeur Intégrateur
Développement spécifique Module écrit pour vous Revue à chaque version Développeur Odoo

Cette hiérarchie évite l’erreur la plus fréquente : demander un développement pour un besoin que le standard couvrait déjà, faute de l’avoir exploré en atelier.

Paramétrage : la personnalisation la plus sûre

Le paramétrage couvre bien plus qu’on ne l’imagine : circuits de validation, conditions de paiement, taxes, structure des documents, droits d’accès, modèles de devis. Il se réalise dans l’interface, se documente facilement et traverse les changements de version sans intervention de code.

En Belgique, c’est là que se règle l’essentiel du local : régimes de TVA, plan comptable adapté aux habitudes de votre comptable, mentions obligatoires sur les factures. Si votre besoin relève de la comptabilité, la page comptabilité Odoo montre ce que le standard couvre avant d’envisager du sur mesure.

Odoo Studio : personnaliser sans code, avec une conséquence contractuelle

Odoo Studio permet de personnaliser sans code les champs, vues, modèles, applications, règles d’automatisation, webhooks, rapports PDF, règles d’approbation et règles de sécurité. Pour ajouter un champ « référence chantier » sur un devis ou une règle d’approbation sur les achats, c’est un outil adapté, rapide à mettre en œuvre.

Deux points à connaître avant de l’activer :

  • Studio est lié à la formule Custom. Installer Studio sur une base en formule Standard déclenche un passage automatique à la formule Custom : commande complémentaire avec un délai de 30 jours en contrat annuel, ou basculement au prochain cycle de facturation en contrat mensuel.
  • Une personnalisation sans code n’est pas sans dette. Sans règle de nommage ni documentation, une base remplie de champs ajoutés « au fil de l’eau » devient vite illisible.

Si votre budget a été calculé sur la formule Standard, intégrez ce basculement dès le départ.

Modules existants : un raccourci à auditer

L’écosystème Odoo est vaste. L’éditeur annonce 50 applications principales et une communauté ayant contribué à plus de 50 000 applications supplémentaires. Cette abondance rend la question inverse de celle qu’on croit : non pas « existe-t-il un module ? » mais « lequel est fiable ? ».

Avant d’installer une extension tierce, contrôlez :

  1. La version d’Odoo prise en charge, et la promesse de suivi sur les versions suivantes.
  2. Le périmètre des fonctions, qui doit correspondre à votre besoin et pas davantage.
  3. La licence, car les modules peuvent être distribués sous la licence de leur auteur, à condition qu’elle soit compatible avec celle de l’édition d’origine.
  4. La présence d’un responsable identifié capable de corriger une anomalie.

Un module abandonné par son auteur retombe à votre charge, avec les coûts d’un développement spécifique. Pour un panorama du standard, voyez la page modules Odoo.

Développement spécifique : quand il se justifie

Odoo est un logiciel extensible : des développeurs créent des modules fondés sur Odoo, qui s’ajoutent à l’application sans la remplacer. C’est de la programmation, dans un environnement où Python est le langage central de la logique serveur.

Un développement spécifique se justifie dans des cas précis :

  • un processus métier différenciant, qui fait votre avantage face à vos concurrents flamands, wallons ou bruxellois, et que le standard ne sait pas porter ;
  • une règle de gestion propre à votre secteur, par exemple dans la production ou la gestion des stocks et achats ;
  • un échange de données avec un outil métier sans connecteur disponible ;
  • un document ou flux réglementaire non couvert tel quel.

Il ne se justifie pas pour reproduire à l’identique l’écran de l’ancien logiciel. Le réflexe « on a toujours fait comme ça » est la première source de code inutile.

Connecter plutôt que recoder : l’API externe

Beaucoup de besoins qui semblent demander un module relèvent en réalité de l’interconnexion. La documentation d’Odoo présente JSON-2 comme l’API externe courante, avec clés d’API, droits d’accès, choix de la base et transactions ; XML-RPC et JSON-RPC y sont traités comme historiques, avec un guide de migration vers JSON-2. Si un prestataire vous propose de bâtir sur ces anciennes interfaces, posez la question de la migration.

L’accès à l’API externe fait partie des fonctions réservées à la formule Custom. Pour la mise en relation d’Odoo avec la boutique en ligne, les banques ou la facturation électronique, consultez la page connecteurs et intégrations Odoo. Sur la facturation électronique B2B, le sujet Peppol mérite d’être cadré avant tout développement : l’échange conforme est une exigence, pas une fantaisie.

Un exemple parlant : Odoo eCommerce gère déjà catalogue, variantes, comptes clients B2B et B2C, paniers abandonnés, modes de livraison, retours et facturation, et se connecte à plus de vingt fournisseurs de paiement dont Stripe, PayPal, Adyen ou Mollie. Il serait absurde de redévelopper ces briques ; le sur mesure ne devrait intervenir que pour une règle tarifaire ou logistique vraiment spécifique.

Impact sur les mises à jour : le vrai coût du sur mesure

Chaque ligne de code spécifique est une ligne à maintenir. Quand Odoo publie une nouvelle version majeure, les modules personnalisés doivent être relus, testés et souvent adaptés, ce qui pèse sur la migration d’Odoo et sur le choix de la version et de l’édition.

La licence compte aussi. Odoo 19 Community est sous licence LGPLv3 ; Odoo 19 Enterprise est sous la licence Odoo Enterprise Edition v1.0, utilisable seulement avec un abonnement Enterprise valide pour le bon nombre d’utilisateurs. Un module construit pour l’une des éditions doit rester compatible avec elle, ce qui oriente aussi le choix entre Community et Enterprise quand le projet est lourd en développement.

Trois facteurs déterminent le coût de maintenance d’un module :

  • sa taille : un petit module ciblé coûte peu à suivre ;
  • sa proximité avec le cœur : plus il modifie des mécanismes centraux, plus il casse facilement ;
  • la qualité de ses tests et de sa documentation, qui décide si la prochaine personne comprendra ce qu’il fait.

Bonnes pratiques pour un développement durable

Les projets qui vieillissent bien partagent les mêmes réflexes.

Rester au standard autant que possible

Adaptez d’abord vos processus au logiciel, ensuite le logiciel à vos processus. Une exigence qui ne survit pas à la question « que se passe-t-il si nous y renonçons ? » n’a probablement pas besoin de code. Tenez un registre des écarts au standard, chacun avec sa justification métier.

Documenter

Pour chaque module : son objectif, les modèles et champs qu’il touche, ses dépendances, la personne qui l’a validé côté métier. Cette documentation doit être livrée avec le code, pas promise après coup. Elle vous protège le jour où le développeur d’origine quitte le projet, ce qui arrive.

Tester

Exigez des tests automatisés pour la logique critique (calculs de prix, de TVA, règles de stock) et une phase de recette sur une base de test, avec des données réelles anonymisées, menée par vos utilisateurs clés. Votre comptable doit valider ce qui touche à la TVA belge avant la mise en production.

Maîtriser le code

Le code livré doit vous appartenir, ou à tout le moins être accessible, versionné et déployable sans le prestataire. Demandez où il est hébergé et qui y a accès. Cette exigence pèse aussi sur l’hébergement et le cloud : tous les modes de déploiement n’acceptent pas le code spécifique de la même manière, car Odoo Online, Odoo.sh et le sur site n’ont pas les mêmes règles.

Comment évaluer un développeur ou un intégrateur Odoo

Un bon prestataire se reconnaît à ses questions autant qu’à ses réponses. Posez-lui ces cinq épreuves.

  1. Comprend-il votre métier avant de coder ? Il doit demander à voir votre flux réel, pas seulement votre liste de souhaits.
  2. Propose-t-il d’abord le standard ? Un prestataire qui vend du développement à chaque demande a un intérêt qui n’est pas le vôtre.
  3. Peut-il montrer du code livré ? Une démonstration, une revue de code ou une référence que vous contactez vous-même vaut mieux qu’une présentation commerciale.
  4. Comment gère-t-il les mises à jour ? Il doit décrire une méthode : branche de test, relecture, recette, bascule.
  5. Que se passe-t-il s’il disparaît ? Documentation, accès au dépôt et formation d’une personne interne sont la réponse.

Pour approfondir cette sélection, la page choisir un intégrateur Odoo détaille les critères, et le guide choisir un intégrateur ERP élargit la comparaison. Si un projet existant dérive, un audit ou une reprise de projet permet de mesurer l’ampleur du code spécifique avant de décider d’en supprimer une partie.

Nous ne sommes affiliés à aucun éditeur et ne réalisons pas le projet : nous mettons en relation votre entreprise avec un intégrateur adapté à votre besoin, après un échange sur votre périmètre. Le principe est expliqué sur la page comment ça marche.

Par où commencer

Dressez la liste de vos besoins en trois colonnes : ce que le paramétrage couvre, ce que Studio ou un module existant couvre, ce qui exige vraiment du code. Cette liste sert de base à un cahier des charges et à une discussion honnête avec l’intégrateur. Le guide cahier des charges ERP vous aide à la structurer. Plus la troisième colonne est courte, plus votre projet restera simple à faire vivre.

Questions fréquentes

Quelle est la différence entre paramétrer et développer dans Odoo ?

Paramétrer, c’est utiliser les options prévues par l’éditeur : activer des fonctions, régler des règles, adapter des documents. Développer, c’est écrire du code qui ajoute ou modifie un comportement. Le paramétrage suit les mises à jour sans effort ; le code doit être relu et adapté à chaque changement de version.

Odoo Studio suffit-il pour personnaliser Odoo ?

Pour beaucoup de besoins, oui : champs, vues, modèles, règles d’automatisation, rapports PDF ou règles d’approbation se créent sans code. Studio a ses limites dès qu’une logique métier devient complexe. Il ajoute aussi une conséquence contractuelle : son installation fait basculer la base en formule Custom.

Un module sur mesure Odoo reste-t-il compatible avec les mises à jour ?

Pas automatiquement. Un module qui s’appuie sur les mécanismes d’extension d’Odoo et reste modeste se migre plus facilement qu’un module qui réécrit le cœur. Prévoyez que chaque changement de version demande de relire, tester et souvent d’ajuster le code spécifique.

Peut-on connecter Odoo à un autre logiciel sans développer un module ?

Souvent oui, via un connecteur existant ou l’API externe, réservée à la formule Custom. Un développement n’est alors nécessaire que pour la logique d’échange propre à votre situation, par exemple un flux avec votre comptable ou une plateforme Peppol.

Comment vérifier le sérieux d’un développeur Odoo ?

Demandez une démonstration de code déjà livré dans un contexte comparable, sa façon de tester et de documenter, et sa position face aux mises à jour. Un bon profil commence par vous demander si le besoin justifie du code, et sait expliquer comment il le maintiendra.

Sources

  1. Odoo, documentation Studio
  2. Odoo, tarifs
  3. Odoo, licences
  4. Odoo, documentation de l’API externe
  5. Odoo, présentation de l’entreprise

Les noms de logiciels cités sont des marques de leurs éditeurs respectifs, mentionnées à titre d’information. Ce site est indépendant et n’est affilié à aucun éditeur.