« Nous avons toujours travaillé comme cela, peut-on reproduire exactement ce fonctionnement dans Odoo ? » La question revient dans presque tous les cadrages de projet ERP. Techniquement, la réponse est souvent oui : Odoo est modulaire, ouvert, et un intégrateur saura reproduire à peu près n’importe quelle règle de gestion. Mais la vraie question du chef de projet n’est pas « est-ce possible ? », c’est « est-ce pertinent ? ». Une étude Gartner publiée en 2026 auprès de 400 entreprises montre qu’au-delà de 20 % de fonctions personnalisées, le risque de dépassement budgétaire grimpe de 14,5 points. Dans cet article, nous allons voir comment arbitrer, demande par demande, entre standard, paramétrage et développement spécifique.
Pourquoi privilégier le standard lorsque c’est possible ?
Le standard, c’est tout ce que l’ERP sait déjà faire sans écrire une ligne de code : les applications natives, leurs champs, leurs workflows et leurs options de paramétrage. Rester dans ce périmètre présente des avantages très concrets :
- moins de développements à financer au démarrage ;
- un budget projet nettement plus prévisible ;
- des montées de version simplifiées ;
- une dette technique limitée ;
- le bénéfice automatique des évolutions natives du logiciel ;
- une maintenance moins coûteuse et moins dépendante d’un prestataire unique.
Encore faut-il vérifier que le standard couvre réellement le besoin, et pas seulement en apparence. Cette réflexion gagne à être menée dès le cadrage du projet : un accompagnement spécialisé en intégration Odoo permet notamment de confronter les besoins métiers aux possibilités standards de l’ERP avant d’engager des développements spécifiques.
Le rythme de l’éditeur explique une bonne partie de ces avantages. Odoo publie une version majeure par an (la version 19 est sortie en septembre 2025) et assure trois ans de support standard par version. Autrement dit, tout code spécifique doit être retesté, parfois réécrit, à intervalle régulier. Une base restée proche du standard suit ce rythme sans effort particulier : la mise à niveau des applications natives est comprise dans l’abonnement Enterprise.
L’écart se lit aussi sur la facture. En France, en facturation annuelle, le plan Standard est affiché à 19,90 € HT par utilisateur et par mois la première année puis 24,90 €, contre 29,90 € puis 37,40 € pour le plan Personnalisé. Or c’est bien ce dernier, le plus cher, qui conditionne l’accès à Odoo Studio, aux API externes et à l’installation de modules développés.
Décider de personnaliser n’engage donc pas seulement un budget de prestation, cela fait aussi changer de niveau d’abonnement pour l’ensemble des utilisateurs.
Un point mérite d’être souligné : rester dans le standard ne signifie pas imposer aveuglément le fonctionnement du logiciel aux collaborateurs. Le projet part toujours des besoins métier. Simplement, il les traduit d’abord dans le vocabulaire de l’outil avant d’envisager de modifier l’outil lui-même.
Dans quels cas le sur-mesure devient-il pertinent ?
Le développement spécifique n’est pas une faute en soi, et le présenter comme tel serait une erreur de cadrage. Il devient légitime dès qu’une demande relève de l’une de ces situations :
- un processus métier réellement spécifique, sans équivalent dans le standard ;
- une contrainte réglementaire ou normative propre à votre secteur ;
- une règle de gestion structurante, par exemple un mode de calcul de prix maison ;
- une connexion avec un système externe : machine, marketplace, logiciel métier historique ;
- une automatisation dont le gain opérationnel est chiffrable ;
- une fonctionnalité déterminante, qui fait partie de ce que l’entreprise vend.
Prenons un exemple simple. Un industriel dont la tarification repose sur un barème de matières croisé avec des coefficients négociés client par client ne trouvera pas d’équivalent natif. Contourner le problème avec des tableurs annulerait une partie du bénéfice de l’ERP : ici, le spécifique se justifie pleinement.
Le contre-exemple est tout aussi parlant. Reproduire un écran de saisie à l’identique de l’ancien logiciel parce que « les équipes ont toujours fait comme cela » ne constitue pas une justification suffisante. Le besoin sous-jacent est réel, les utilisateurs doivent retrouver leurs repères, mais la bonne réponse relève de la formation et de l’accompagnement, pas du code.
Les ordres de grandeur aident à trancher. En France, un petit ajout (champ, vue, rapport) se négocie généralement entre 800 et 2 000 €, un module métier courant entre 4 000 et 15 000 € HT, et un développement lourd (portail client, logique comptable dédiée, connecteur complexe) dépasse fréquemment 15 000 €. À ce niveau d’engagement, une demande doit être défendue comme un investissement, pas comme une préférence.
Comment arbitrer entre standard et personnalisation ?
C’est le cœur du travail du chef de projet. Avant de transmettre la moindre demande spécifique à l’intégrateur, la même série de questions doit être déroulée :
- quel problème métier cherche-t-on réellement à résoudre, au-delà de la solution proposée par l’utilisateur ?
- le standard permet-il déjà d’y répondre autrement, même imparfaitement ?
- peut-on faire légèrement évoluer le processus interne plutôt que le logiciel ?
- quelle valeur, chiffrée si possible, apporte le développement demandé ?
- quel sera son coût de maintenance sur cinq ans ?
- peut-il compliquer les futures montées de version, voire les bloquer ?
Ces questions ne sont pas rhétoriques : elles servent à séparer ce qui relève de l’habitude de ce qui relève du métier. Dans la pratique, quatre cas de figure reviennent en boucle pendant les ateliers de cadrage.
| Ce que dit l’utilisateur | Ce que cela révèle | Réponse à privilégier |
|---|---|---|
| « On a toujours fait comme cela » | Une habitude de travail | Standard, accompagné d’un vrai effort de formation |
| « La réglementation nous impose… » | Une contrainte externe non négociable | Paramétrage d’abord, spécifique si le standard ne couvre pas |
| « C’est ce qui nous différencie de nos concurrents » | Un avantage concurrentiel | Spécifique assumé, documenté et budgété dans la durée |
| « L’écran serait plus lisible autrement » | Un besoin de confort d’utilisation | Paramétrage ou Studio, jamais un module développé |
Les référentiels du marché convergent vers un ordre de grandeur utile à garder en tête : viser 80 à 90 % de standard et de paramétrage, et plafonner le spécifique autour de 10 à 20 % du périmètre fonctionnel. Au-delà, le projet cesse progressivement d’être un déploiement d’ERP pour devenir un développement logiciel qui en porte le nom. Encore faut-il s’entendre sur ce que recouvre exactement le mot « personnalisation », car tout n’est pas du développement.
Studio, module existant ou développement : les degrés de personnalisation
Entre « on garde le standard » et « on développe », il existe plusieurs marches intermédiaires. Les franchir dans l’ordre évite beaucoup de dépenses inutiles :
- utiliser le standard tel quel ;
- adapter légèrement le processus interne ;
- paramétrer : règles de gestion, droits, séquences, modèles de documents ;
- passer par Odoo Studio pour les ajustements simples ;
- installer un module existant, sur la place de marché Odoo ou du côté de la communauté OCA ;
- développer un module spécifique, en dernier recours.
Le périmètre natif est déjà large, comme le détaille notre avis complet sur Odoo : la plupart des demandes formulées en atelier trouvent leur réponse dans les quatre premières marches.
Odoo Studio mérite une mention particulière, car il couvre sans code une part réelle des besoins : ajout de champs et de modèles, réorganisation des formulaires et des vues liste, kanban ou calendrier, règles d’automatisation, étapes d’approbation, personnalisation des rapports PDF. Ses limites sont tout aussi nettes : pas d’algorithme Python complexe, pas de surcharge des méthodes du cœur, pas de widget JavaScript, pas de traitement de masse performant, pas de tests automatisés. Dès qu’un besoin touche à la logique transactionnelle ou à la performance, on bascule vers un module versionné.
Un avantage est souvent ignoré : les personnalisations réalisées avec Studio sont reprises lors des montées de version tant que Studio reste installé et l’abonnement actif. Un module développé, lui, devra être porté par celui qui le maintient. Attention toutefois à ne pas remplacer une dette de code par une dette de règles : trente automatisations Studio imbriquées deviennent aussi difficiles à diagnostiquer qu’un module mal documenté. Le raisonnement reste le même que sur n’importe quel projet d’amélioration des processus : on simplifie le processus avant d’outiller sa complexité.
Le vrai coût d’un spécifique, c’est sa durée de vie
Un module ne coûte pas seulement son prix de fabrication, il coûte son entretien, année après année. Trois postes sont systématiquement sous-estimés au moment du chiffrage :
- le portage à chaque montée de version : de 8 à 15 heures pour un module simple, de 30 à 60 heures pour un module complexe, et cela à chaque saut de version ;
- la recette métier qui suit ce portage, à la charge de l’entreprise et non du prestataire ;
- la maintenance du code, facturée par Odoo 16 € par mois et par tranche de 100 lignes, soit 9 600 € par an pour 5 000 lignes.
Avec un taux journalier d’intégrateur qui va de 650 à 1 400 € selon le niveau de certification, un module complexe représente donc plusieurs milliers d’euros à chaque version, sans apporter la moindre fonctionnalité nouvelle. Plus gênant encore : tant qu’un module spécifique n’existe pas dans une version compatible avec la version cible, la base ne peut pas être mise à niveau, comme le rappelle la documentation officielle d’Odoo. Un seul module mal maintenu suffit à immobiliser toute la plateforme.
D’où une règle simple à poser dès le départ : aucun développement n’est validé sans son coût de possession. Chaque demande retenue doit être décrite dans les spécifications fonctionnelles, chiffrée en construction comme en maintenance, et couverte par un jeu de tests intégré au cahier de recette. Cette discipline n’a rien de propre à Odoo : notre comparatif des ERP du marché montre que les écarts de réussite tiennent bien plus à la gouvernance qu’à la solution retenue.
Le rôle du chef de projet : rechercher le bon compromis
Le chef de projet n’est ni le porte-parole des utilisateurs ni le garde-fou de l’intégrateur. Il fait le lien entre six réalités qui ne s’accordent jamais spontanément : les besoins des utilisateurs, les objectifs de l’entreprise, les possibilités de l’ERP, les contraintes techniques, le budget et le planning.
Sa mission n’est donc pas d’accepter ou de refuser systématiquement les demandes de personnalisation, mais d’en évaluer la valeur et les conséquences à moyen terme. Une demande refusée doit être expliquée, une demande acceptée doit être tracée. C’est d’ailleurs ce qui distingue le rôle du chef de projet ERP de celui d’un simple coordinateur de déploiement.
Concrètement, ces arbitrages se documentent : dans le backlog pour les projets menés en itérations, dans le cahier des charges ou les spécifications pour les projets plus structurés. Chaque ligne mentionne la demande d’origine, la décision prise, sa justification et son coût estimé. Ce registre a une vertu inattendue : il désamorce les débats qui reviennent six mois plus tard, quand plus personne ne se souvient des raisons du choix. Et lorsque la décision consiste à rester dans le standard, elle doit être accompagnée : les outils de conduite du changement font souvent davantage pour l’adoption qu’un module sur-mesure.
En bref : personnaliser, mais jamais par défaut
La règle tient en une phrase : personnaliser lorsque cela apporte une valeur métier réelle, rester dans le standard lorsque la différence porte surtout sur des habitudes de travail. Entre ces deux extrêmes, la marge de manœuvre est large : paramétrage, Studio, modules existants.
Un projet Odoo performant est celui qui trouve l’équilibre entre l’adaptation aux processus de l’entreprise, la simplicité technique et la capacité à évoluer dans le temps. C’est aussi ce qui sépare un déploiement réussi d’un déploiement subi.
