Pourquoi ne pas acheter un ERP vertical spécialisé ?

Pour la plupart des niches, un ERP vertical reste la bonne réponse : périmètre plus étroit, démarrage plus rapide, risque plus faible. La voie du sur-mesure sur Odoo prend son sens une fois que l’outil vertical cesse de couvrir votre vrai processus cœur, ou qu’il a vieilli vers un verrou fournisseur dont vous ne pouvez plus sortir. Nous vous dirons honnêtement dans quel cas vous vous trouvez pendant la découverte, y compris en disant « achetez l’outil vertical » quand c’est la bonne réponse.

Possédons-nous le code source ?

Oui, chaque ligne, dès le premier jour. Le code vit dans votre organisation GitHub ou GitLab, vous contrôlez la licence et la roadmap, et vous pouvez embaucher n’importe quel développeur Odoo pour la maintenance. Nous ne détenons pas les clés, et nous ne voulons pas les détenir.

Que se passe-t-il à la prochaine montée de version majeure d’Odoo ?

C’est la première question que pose tout acheteur technique senior, et celle qui sépare un ERP sur mesure d’un ERP forké. Nous étendons Odoo par héritage, héritage de vues XPath, _inherit sur les modèles, _inherits pour les tables déléguées, et nous ne forkons jamais. Chaque module sur mesure est livré avec un script de migration versé juste à côté du code du modèle. Comme le cadre absorbe le plus gros du travail, les montées de version majeure restent des projets cadrés, quatre à dix semaines en général pour un build sur mesure conséquent, plutôt que des réécritures.

Combien de temps prend un build d’ERP sur mesure réaliste ?

Pour une seule unité métier, comptez six à douze mois entre la découverte et la première mise en production ; les déploiements multi-entités ou multi-pays s’étendent sur douze à vingt mois. La découverte et la modélisation du domaine occupent seules huit à douze semaines de ce total, plus que ce qu’on imagine, parce que les erreurs de modélisation qu’elles rattrapent épargnent des mois plus tard. Le budget total se situe en général entre 80 K$ et 400 K$, sur devis uniquement après la découverte.

Quand nous direz-vous de ne pas faire ce build ?

Nous vous le dirons dès que l’écart avec Odoo standard est assez faible pour qu’un à trois modules sur mesure le comblent, c’est notre service Personnalisation, ou dès qu’un outil de niche fonctionnel avec une API ouverte est déjà disponible pour que nous l’intégrions à la place, ou dès que le vrai problème est la clarté des processus plutôt que le logiciel. Perdre le build et gagner votre confiance vaut mieux que vous vendre quelque chose dont vous n’avez pas besoin.

ERP sur mesure · Odoo comme cadre

Quand aucun ERP standard ne convient, construisez-en un sur mesure avec Odoo

Pour les entreprises dont les processus cœur n’ont jamais vécu dans un ERP et ne le feront jamais. Nous utilisons Odoo comme cadre, en nous appuyant sur son ORM Python, son architecture modulaire et son moteur comptable, puis nous écrivons les modules qui n’appartiennent qu’à vous.

Voir ce que nous construisons

Certaines entreprises ont des processus qui n’existent dans aucun ERP du marché. Plutôt que de partir d’une page blanche, nous utilisons Odoo comme cadre, son ORM Python, son architecture modulaire, son modèle de sécurité, sa clôture comptable, et écrivons les modules qui vous sont propres. Vous obtenez un ERP sur mesure, sans réécrire les fondations qu’Odoo a déjà solidifiées sur des millions d’installations.

Cette approche n’est pas pour tout le monde. Nous recommandons Odoo standard, ou de la personnalisation légère, pour la grande majorité des PME. Voyez quand un ERP sur mesure est le bon choix avant de cadrer un engagement.

Ce que veut dire « Odoo comme cadre »

Six capacités qui distinguent un build sur cadre d’un déploiement standard.

Modélisation du domaine

Avant d’écrire la moindre UI, nous modélisons votre activité en objets, relations et contraintes dans l’ORM d’Odoo. Ce modèle de données est le socle ; tout le reste en hérite.

Modules sur mesure

Chaque workflow unique reçoit son propre module installable, avec un graphe de dépendances propre et des tests isolés, pour pouvoir être retiré ou remplacé plus tard sans toucher au reste.

Moteurs de workflow

Machines à états multi-étapes, routage conditionnel, chaînes d’approbation et jobs planifiés, tous avec piste d’audit, construits sur les server actions et mail flows d’Odoo plutôt qu’ajoutés après coup.

Sécurité et ACL

Accès contrôlé par enregistrement, par champ et par action, avec des règles d’accès alignées sur votre organigramme réel, et un journal d’audit de chaque lecture et écriture partout où la réglementation l’exige.

Rapports et tableaux de bord

Les PDF QWeb couvrent les documents, les Spreadsheets couvrent l’analyse, et des contrôleurs sur mesure prennent en charge ce que les outils de reporting standard n’expriment pas, avec des chiffres puisés en direct dans Odoo plutôt que dans un export.

Intégrations et API

REST, JSON-RPC, webhooks, connecteurs en file d’attente et ponts EDI, tous bidirectionnels et idempotents, avec des logs rejouables pour le jour où quelque chose casse en aval.

Quand cette voie a du sens, et quand elle n’en a pas

Nous refusons les mauvais départs, ce qui rend cette page plus utile.

Construisez un ERP sur mesure sur Odoo quand

Aucun ERP standard ne contient votre workflow cœur, et votre équipe le maintient en vie dans des tableurs depuis des années.
Un outil vertical spécialisé est devenu trop petit pour vous, mais un Odoo générique laisserait encore un tiers du quotidien dans des systèmes annexes.
Vous voulez le code source entre vos mains et une roadmap qui suit votre propre rythme plutôt que celui d’un éditeur SaaS.
Vous prévoyez de faire évoluer le modèle pendant cinq ans ou plus, ce qui appelle un cadre plutôt qu’un produit figé.

Restez sur Odoo standard quand

Avec moins de 25 utilisateurs, l’écart avec Odoo standard reste en général assez faible pour qu’un ou deux modules sur mesure le comblent, et c’est notre service Personnalisation, pas celui-ci.
Si vous avez déjà un outil de niche avec une API ouverte, une refonte se rentabilise rarement ; le brancher à Odoo via l’Intégration est la meilleure voie.
Partir sur cette voie vous laisserait seul sur la version que vous auriez déployée. Un build sur cadre exige un budget de maintenance que vous continuerez réellement à financer.
Quand le vrai problème est la clarté des processus plutôt que le logiciel, une mission de Conseil avant tout code est la solution la moins chère et la plus honnête.

Comment se déroule un build d’ERP sur mesure

Six phases, conçues pour que vous puissiez marquer une pause à chaque frontière si la situation change.

Étape 01

Découverte

Deux à quatre semaines d’ateliers avec les personnes qui font vraiment le travail. Nous cartographions les workflows, identifions ce qui correspond à Odoo standard, et isolons ce qui exigera des modules sur mesure, pour aboutir à un document d’architecture et une proposition à prix fixe.

Étape 02

Modélisation du domaine

Nous traduisons vos processus en objets, relations et machines à états Odoo, et vos experts métier les révisent avant le moindre travail d’UI. Une erreur de modélisation rattrapée ici coûte des jours ; la même erreur rattrapée après le build coûte des semaines.

Étape 03

Spécification des modules

Chaque module sur mesure reçoit une spec d’une page couvrant son modèle de données, ses flux clés, sa matrice d’accès, ses points d’intégration et ses cas de test, et votre validation de cette spec est ce qui débloque le build.

Étape 04

Build itératif

Sprints de deux semaines, chacun se terminant par une démo de logiciel fonctionnel que vous pouvez tester sur une instance de pré-prod. Tout changement de périmètre passe par un change order écrit, donc pas de facturation cachée.

Étape 05

Durcissement

Profilage de performance, tests aux cas limites, revue de sécurité et scripts de migration de données : les deux mois peu spectaculaires qui séparent « ça démontre bien » de « ça fait tourner l’activité à la clôture ».

Étape 06

Déploiement et passation

Un go-live par paliers, trente à quatre-vingt-dix jours d’hypercare, une formation pour vos utilisateurs avancés internes, et une documentation complète de chaque module sur mesure. Dès le premier jour, vous restez libre d’embaucher un développeur pour en assurer la maintenance.

Ce que nous promettons sur le code

Quatre habitudes qui séparent un ERP sur mesure d’un ERP forké.

Héritage upgrade-safe

Nous étendons Odoo plutôt que de le forker, via l’héritage de vues XPath, _inherit sur les modèles, et des scripts de migration correctement cadrés. Passer d’Odoo 19 à 20 devient un projet, pas une réécriture.

Propriété du code source

Chaque ligne de code sur mesure vous appartient dès le premier jour, hébergée sur votre GitHub ou GitLab, sous licence BSL quand cela a du sens et MIT pour ce que vous pourriez open-sourcer plus tard. Aucune clause de lock-in nulle part.

Livraison soutenue par les tests

Des tests unitaires couvrant sa surface publique accompagnent chaque module sur mesure, avec en plus des tests d’intégration pour les workflows qui comptent vraiment, et l’ensemble de la suite tourne en CI à chaque commit.

Style aligné OCA

Nous écrivons selon les conventions de code de l’Odoo Community Association, si bien que n’importe quel développeur OCA peut lire votre code dès le premier jour, et le bassin de recrutement pour la maintenance reste large plutôt qu’enfermé chez un seul fournisseur.

Patrons issus d’engagements réels

Tous nos clients n’ont pas eu besoin d’un ERP sur mesure construit de zéro. Ce que nous avons livré de façon répétée, c’est une personnalisation lourde sur le cadre d’Odoo, avec les mêmes techniques qu’un build sur mesure utiliserait dès le premier jour. Voici les deux engagements qui ont le plus sollicité ce cadre :

MFG · MODULES CUSTOM

De SAP B1 à Odoo, MRP et qualité sur mesure

Une migration hors de SAP Business One, associée à des modules sur mesure pour l’atelier, des points de contrôle qualité et des workflows de maintenance, illustre le travail de modélisation qu’un build d’ERP sur mesure réalise à travers les domaines Manufacturing, Qualité et Maintenance.

Lire l’étude de cas →DISTRIB · MULTI-ENTREPÔTS

Quatre centres de distribution, code-barres et logique de stock

Routage multi-entrepôts, flux code-barres sur mesure, comptages cycliques en direct et ponts EDI vers les plus grandes enseignes, tout cela construit sur Odoo Inventory, illustre la plomberie de routage, d’ACL et de moteur d’opérations sur laquelle repose un ERP de distribution sur mesure.

Lire l’étude de cas →

Prêt à cadrer un build sur mesure ?

Réservez un appel d’architecture gratuit de 30 minutes : nous identifions les workflows qui exigent des modules sur mesure face à ce qu’Odoo standard gère déjà, puis vous disons honnêtement quelle voie convient.

Réserver un appel d’architecture gratuit

ERP sur mesure sur Odoo, questions fréquentes

Pourquoi ne pas acheter un ERP vertical spécialisé ?
Pour la plupart des niches, un ERP vertical reste la bonne réponse : périmètre plus étroit, démarrage plus rapide, risque plus faible. La voie du sur-mesure sur Odoo prend son sens une fois que l’outil vertical cesse de couvrir votre vrai processus cœur, ou qu’il a vieilli vers un verrou fournisseur dont vous ne pouvez plus sortir. Nous vous dirons honnêtement dans quel cas vous vous trouvez pendant la découverte, y compris en disant « achetez l’outil vertical » quand c’est la bonne réponse.
Possédons-nous le code source ?
Oui, chaque ligne, dès le premier jour. Le code vit dans votre organisation GitHub ou GitLab, vous contrôlez la licence et la roadmap, et vous pouvez embaucher n’importe quel développeur Odoo pour la maintenance. Nous ne détenons pas les clés, et nous ne voulons pas les détenir.
Que se passe-t-il à la prochaine montée de version majeure d’Odoo ?
C’est la première question que pose tout acheteur technique senior, et celle qui sépare un ERP sur mesure d’un ERP forké. Nous étendons Odoo par héritage, héritage de vues XPath, _inherit sur les modèles, _inherits pour les tables déléguées, et nous ne forkons jamais. Chaque module sur mesure est livré avec un script de migration versé juste à côté du code du modèle. Comme le cadre absorbe le plus gros du travail, les montées de version majeure restent des projets cadrés, quatre à dix semaines en général pour un build sur mesure conséquent, plutôt que des réécritures.
Combien de temps prend un build d’ERP sur mesure réaliste ?
Pour une seule unité métier, comptez six à douze mois entre la découverte et la première mise en production ; les déploiements multi-entités ou multi-pays s’étendent sur douze à vingt mois. La découverte et la modélisation du domaine occupent seules huit à douze semaines de ce total, plus que ce qu’on imagine, parce que les erreurs de modélisation qu’elles rattrapent épargnent des mois plus tard. Le budget total se situe en général entre 80 K$ et 400 K$, sur devis uniquement après la découverte.
Quand nous direz-vous de ne pas faire ce build ?
Nous vous le dirons dès que l’écart avec Odoo standard est assez faible pour qu’un à trois modules sur mesure le comblent, c’est notre service Personnalisation, ou dès qu’un outil de niche fonctionnel avec une API ouverte est déjà disponible pour que nous l’intégrions à la place, ou dès que le vrai problème est la clarté des processus plutôt que le logiciel. Perdre le build et gagner votre confiance vaut mieux que vous vendre quelque chose dont vous n’avez pas besoin.