Sommaire
Il existe une catégorie d'appels qu'on reçoit toutes les semaines chez Drakkar, et qui commence toujours à peu près pareil : « On est sur Odoo depuis trois ans, notre intégrateur ne répond plus vraiment, on est bloqués sur une vieille version, et on ne sait même pas où est notre code. »
La suite de la conversation est souvent plus tendue que prévu. Parce qu'entre le moment où un dirigeant décide de changer de prestataire et le moment où il reprend réellement la main sur son ERP, il y a une série d'étapes techniques et contractuelles que personne ne lui a expliquées au démarrage. Certaines se règlent en trente minutes. D'autres coûtent plusieurs dizaines de milliers d'euros.
Cet article est la retranscription structurée d'un échange avec François Pascal Sene, expert Odoo chez Drakkar, qui gère ces reprises d'environnement au quotidien. On y explique concrètement quoi faire dans quelle situation : comment identifier votre type de déploiement, comment récupérer vos accès, que faire quand un prestataire refuse de rendre le code, comment arbitrer entre repartir à zéro et migrer l'existant, et surtout comment savoir qui est responsable quand ça bugue après une migration.
Les cas clients cités sont anonymisés, les chiffres et les situations sont réels.
Vous êtes dans quelle situation ?
Avant de rentrer dans le détail, identifiez votre symptôme. Vous saurez directement quelle section vous concerne.
Étape 1 : identifier votre type de déploiement
C'est le point de départ obligatoire, et c'est aussi celui que la plupart des dirigeants ne maîtrisent pas. Selon la façon dont votre Odoo a été déployé, vos droits, vos leviers et votre marge de manœuvre ne sont pas du tout les mêmes. Si vous découvrez l'écosystème, notre guide complet sur l'ERP Odoo pose les bases avant d'aller plus loin.
Il existe trois cas de figure.
Odoo Online (SaaS)
C'est la version hébergée directement par Odoo, sans accès au code. Vous configurez, vous paramétrez, mais vous ne développez pas.
Ce que ça change pour vous : tout se joue sur les identifiants. Si vous voulez sortir un intégrateur de votre environnement, vous supprimez son accès utilisateur, vous changez votre mot de passe, et c'est terminé. Il n'y a pas de dépôt de code à récupérer, pas de serveur à transférer, pas de module spécifique à rapatrier.
C'est de très loin le scénario le plus simple. Une reprise sur Odoo Online se règle en une demi-journée dans le pire des cas.
Odoo.sh (PaaS)
C'est la plateforme d'hébergement d'Odoo qui autorise le développement spécifique. Votre environnement est relié à un compte de code, généralement GitHub, et c'est là que ça devient intéressant.
Ce que ça change pour vous : votre projet Odoo.sh est branché sur un dépôt Git qui appartient à une organisation. Cette organisation a des administrateurs. Et si vous n'êtes pas administrateur de cette organisation, vous n'êtes pas propriétaire de votre code, même si vous payez les licences depuis trois ans.
C'est le point le plus mal compris du marché, et c'est la source de la grande majorité des conflits qu'on observe lors des changements de prestataire. On y revient en détail plus bas.
Serveur dédié ou hébergement propre (on-premise)
Votre Odoo tourne sur un serveur que vous louez chez un hébergeur, ou que votre intégrateur héberge pour vous.
Ce que ça change pour vous : il faut distinguer deux situations. Si le serveur est chez votre prestataire, vous devrez soit lui demander de continuer à héberger sans intervenir, ce qui se passe rarement bien quand la relation est dégradée, soit exiger l'export complet de l'environnement pour le remonter ailleurs. Si vous avez votre propre contrat d'hébergement chez un OVH ou équivalent, on vous transmet les accès et le prestataire sortant perd la main.
Ce mode apporte le plus de liberté, mais aussi le plus de responsabilité. Comme le résume François Pascal : « Sur un serveur dédié, si demain le serveur tombe, le client appelle qui ? Il n'appelle pas Odoo, il vous appelle vous. La sécurité, la disponibilité, les sauvegardes, tout ça devient votre sujet. C'est un autre métier et il faut le savoir avant de signer. »
Si la reprise est aussi l'occasion de rebattre les cartes sur ce point, on a détaillé les critères de choix dans notre article Où héberger Odoo sans se tromper de porte d'entrée.
Étape 2 : récupérer vos accès concrètement
Une fois votre déploiement identifié, la procédure de reprise diffère.
Sur Odoo Online : suppression des utilisateurs du prestataire sortant, changement des mots de passe administrateur, ajout du nouvel intégrateur. Il n'y a rien d'autre à faire.
Sur Odoo.sh : il faut nettoyer deux endroits, et c'est là que beaucoup d'entreprises se plantent. Vous devez retirer les accès sur la plateforme Odoo.sh et sur le dépôt Git. Les deux sont connectés mais gérés séparément. Un intégrateur retiré d'Odoo.sh mais resté membre de l'organisation GitHub conserve un accès au code de votre entreprise.
« On le fait systématiquement, même quand il n'y a pas de développement spécifique, insiste François Pascal. À chaque reprise, on vérifie les deux côtés. Ça prend dix minutes et ça évite des situations très inconfortables six mois plus tard. »
Sur serveur dédié : transfert des accès serveur, régénération des clés SSH, révocation des anciens comptes, et vérification que le prestataire sortant n'a pas conservé un accès de secours quelque part.
Cas Drakkar n°1 : une reprise propre bouclée en moins de 30 minutes
Le contexte : Une entreprise de produits techniques, environ 40 utilisateurs Odoo, hébergée sur Odoo.sh avec plusieurs modules développés sur mesure par un intégrateur précédent. Elle souhaite reprendre la pleine propriété de son environnement et confier la suite à Drakkar.
Le problème : Le dépôt Git appartenait à l'organisation de l'ancien prestataire. Le client était utilisateur, pas propriétaire.
Ce qu'on a fait : On a créé un dépôt dédié au client, sur lequel il détient les droits d'administration. Le prestataire sortant a transféré les modules spécifiques vers ce nouveau dépôt, qu'on a ensuite rebranché sur l'environnement Odoo.sh existant. L'interface Odoo.sh ne change pas, seul le dépôt sous-jacent est différent.
Le résultat : L'opération complète a pris moins de trente minutes. Le client est aujourd'hui administrateur de son propre code, et il ajoute ou retire lui-même les intégrateurs qui travaillent dessus.
Ce qu'il faut retenir : Quand le prestataire sortant joue le jeu et que le contrat était clair, une reprise d'environnement Odoo n'est pas un projet, c'est une formalité. Toute la difficulté vient des cas où ce n'est pas le cas.
Votre intégrateur refuse de vous rendre le code : que faire ?
Voici la situation qui met le plus de projets à l'arrêt, et celle sur laquelle on a le plus de retours terrain.
Comment c'est techniquement possible
Reprenons le mécanisme d'Odoo.sh. Votre environnement est relié à un dépôt Git, hébergé dans une organisation. Cette organisation est gérée par un ou plusieurs administrateurs, qui décident qui a le droit d'y accéder. Les autres membres voient uniquement les projets auxquels on les a explicitement ajoutés.
L'analogie utilisée par François Pascal est parlante : « C'est exactement comme un Slack. Si vous êtes admin de l'espace, vous ajoutez et vous retirez qui vous voulez. Si vous êtes juste membre d'un canal, l'admin peut vous sortir du jour au lendemain et vous n'avez plus rien. La question n'est pas de savoir qui utilise le code, c'est de savoir qui est admin. »
Résultat : si votre intégrateur a créé le dépôt dans sa propre organisation, il peut techniquement vous laisser utiliser votre Odoo tout en refusant de vous transférer les modules. Vous êtes utilisateur de votre système, vous n'êtes pas propriétaire de ce qui le fait fonctionner.
Pourquoi c'est souvent légal
C'est la partie que les dirigeants encaissent mal, mais elle est simple : en l'absence de clause explicite dans le contrat, rien n'oblige un prestataire à céder le code qu'il a développé.
« Tout est contractuel, rappelle François Pascal. Si le contrat ne dit pas que les modules développés appartiennent au client, alors ils n'appartiennent pas au client. Nous, dans nos contrats, c'est écrit noir sur blanc : les développements réalisés pour un client lui reviennent, et on ne peut pas aller les réinstaller ailleurs. Mais tous les intégrateurs ne travaillent pas comme ça. »
C'est précisément le genre de point qu'il faut vérifier en amont, et qu'on a listé dans notre guide pour choisir son intégrateur Odoo sans se tromper.
Cas Drakkar n°2 : quand le code devient un moyen de pression
Le contexte : Une entreprise bloquée en V14, qui souhaite passer sur une version récente et changer d'intégrateur. Une dizaine de modules spécifiques développés par le prestataire historique, indispensables au fonctionnement quotidien de sa base.
Le problème : Le prestataire sortant a refusé de transférer le dépôt Git tant qu'il n'était pas payé pour le faire (rançon demandée de + 100 000€). Aucune clause de propriété intellectuelle n'avait été prévue au contrat initial, il était donc dans son droit. Le client se retrouvait avec une base qui tournait, mais dont il ne pouvait ni modifier ni migrer les modules. Et avec une contrainte supplémentaire : désinstaller ces modules pour s'en libérer aurait supprimé toutes les données stockées dans les champs qu'ils avaient créés.
Ce qu'on a fait : On a posé les trois options sur la table de façon transparente. Payer et récupérer le code. Rester bloqué. Ou repartir sur une base neuve en migrant uniquement les données essentielles. Le client a choisi la troisième voie. On a construit un nouveau cahier des charges, reconstruit l'environnement sur une version récente, et migré les données structurantes : comptabilité, balance, journaux, clients, produits, catégories, stock.
Le résultat : Un projet de reconstruction scénarisé sur environ 120 jours. Soit très largement plus que ce qu'aurait coûté une clause contractuelle correctement rédigée trois ans plus tôt.
Ce qu'il faut retenir : La propriété du code ne se négocie pas au moment du divorce, elle se sécurise au moment du mariage. Si vous êtes en train de choisir un intégrateur Odoo aujourd'hui, la clause de cession des développements spécifiques est probablement la ligne la plus rentable de votre contrat.
Comment savoir si votre Odoo a été mal développé
Avant de décider quoi que ce soit sur une migration, il faut savoir dans quel état est réellement votre environnement. Voici les cinq points qu'on vérifie systématiquement lors d'un audit de reprise.
1. Le cœur d'Odoo a été modifié directement.
C'est la faute la plus grave, et elle n'est pas rare. Odoo laisse des portes ouvertes qui permettent d'aller modifier le code standard depuis l'interface, notamment sur les vues. Ça fonctionne le jour même, et ça casse à la première migration. « Quand je vois ça sur un projet repris, je sais qu'on va passer du temps avant de pouvoir toucher à quoi que ce soit d'autre », résume François Pascal. Un développement propre passe par des modules qui héritent du standard, jamais par une réécriture du standard lui-même.
2. Odoo Studio a été utilisé comme outil de développement en production.
Studio est très pratique pour du paramétrage léger. Utilisé pour construire des fonctionnalités structurantes, il génère une couche difficile à maintenir, mal versionnée, et souvent invisible pour l'intégrateur suivant.
3. Des contournements ont été mis en place pour obtenir des fonctionnalités qu'Odoo ne propose pas nativement.
Ils fonctionnent tant qu'Odoo ne referme pas la porte. Quand la porte se referme dans une version ultérieure, la fonctionnalité disparaît et il n'y a pas de solution de repli.
4. Il n'existe pas de dépôt de code propre et documenté.
Si personne ne sait dire précisément quels modules tournent sur votre base, ce qu'ils font et qui les a écrits, vous avez un problème d'inventaire avant d'avoir un problème de migration.
5. Il n'y a pas d'environnement de test.
Si toutes les modifications sont poussées directement en production, ce n'est pas une méthode de travail, c'est un pari répété.
Si vous cochez deux cases ou plus, la conclusion est la même : la dette technique doit être traitée avant la migration, pas pendant. « Il faut corriger proprement les faiblesses avant de migrer, sinon on migre les problèmes en même temps que le reste », précise François Pascal. Sur les projets qu'il a repris, cette phase de nettoyage a représenté à elle seule plusieurs semaines de travail.
Un dernier point de vigilance sur ce chapitre : un environnement mal développé s'accompagne presque toujours d'équipes mal formées, qui ont pris des habitudes de contournement dans l'outil. Notre article sur la formation Odoo pendant l'intégration explique pourquoi les deux sujets se traitent ensemble.
Étape 3 : choisir votre stratégie de reprise
Il existe trois chemins, et le bon dépend de l'état de votre existant, de votre budget et de votre tolérance à la perte de données. Voici comment on les arbitre.
Le chemin médian est souvent le plus pertinent, et c'est aussi celui qu'on propose le plus rarement dans le marché parce qu'il oblige à annoncer une facture en deux temps. Corriger d'abord, migrer ensuite. C'est moins vendeur qu'un forfait unique, c'est nettement plus sûr.
Sur la partie budgétaire, deux ressources vous aideront à cadrer vos ordres de grandeur : notre analyse du tarif réel d'Odoo pour la partie licences et intégration, et notre guide sur le budget à prévoir pour un projet ERP si vous repartez sur un projet complet.
Précision importante sur le premier scénario : quand vous repartez sur une base neuve, vous récupérez vos données par des exports et des imports, essentiellement au format tableur, parfois via des scripts pour les volumes importants. Et ça ne fonctionne que si les champs existent des deux côtés. Si votre ancien intégrateur avait créé des champs spécifiques qui n'ont pas d'équivalent dans le nouvel environnement, il n'y a rien à mapper et la donnée est perdue.
Ce que vous perdez si vous repartez sur une base vierge
C'est la conversation la plus importante à avoir avant de valider cette option, et elle doit être menée honnêtement. Voici ce qui ne se récupère pas, ou très difficilement.
- La traçabilité produit. C'est le point le plus critique et le plus souvent négligé. Si vous vendez des produits sous garantie longue, si vous devez pouvoir remonter un numéro de série ou un numéro de lot plusieurs années en arrière, une base neuve vous fait perdre cette chaîne.
- Les mouvements de stock historiques. Vous récupérez un état de stock à date, pas l'historique complet des mouvements qui y ont conduit.
- Les soldes et l'historique détaillé des commandes. On récupère la comptabilité, la balance, les journaux, les factures. Les commandes en cours et leur historique fin sont beaucoup plus compliqués à reconstituer.
- Tout ce qui vivait dans un champ développé sur mesure. Si le champ n'existe pas dans le nouvel environnement, la donnée qu'il contenait n'a nulle part où aller.
- Les données liées à des fonctionnalités spécifiques. Les points de fidélité, les compteurs, les scorings maison et autres mécaniques développées pour vous font partie des grands oubliés des reprises rapides.
« Si vous avez une garantie de quinze ans sur un produit, vous avez intérêt à pouvoir tracer, rappelle François Pascal. C'est exactement le genre de sujet qu'on découvre trop tard si personne ne pose la question au démarrage. »
Sur le volet comptable, qui est presque toujours celui qu'on parvient à reprendre le plus proprement, notre présentation du module Comptabilité d'Odoo 19 détaille ce que la version actuelle sait absorber en import.
Notre position là-dessus est constante : ces pertes ne sont pas rédhibitoires, mais elles doivent être listées, chiffrées et validées par écrit avant le démarrage. Un client qui découvre après coup qu'il a perdu sa traçabilité ne se souviendra pas d'avoir dit oui.
Étape 4 : migrer de version sans tout casser
Passons à la migration proprement dite, c'est-à-dire le passage d'une version d'Odoo à une autre. Trois règles structurent le travail. Pour le détail complet de la méthode, étape par étape, on lui a consacré un guide entier : Migration Odoo, guide complet et conseils d'experts. Et si votre sujet dépasse Odoo, notre article sur la migration d'ERP en général pose le cadre méthodologique.
Règle 1 : ne jamais migrer immédiatement vers une version qui vient de sortir
Odoo publie une nouvelle version majeure chaque année, mais le script de migration qui permet d'y accéder ne sort pas en même temps. Il arrive plus tard, et il n'est pas mature immédiatement (Janvier/Février de l'année suivante, soit environ 5/6 mois après la sortie de la nouvelle version).
« Odoo travaille en permanence sur ces scripts, et je dis bien en permanence, explique François Pascal. On parle de millions de lignes de code. Qui dit millions de lignes de code dit sources d'erreurs. Plus une version prend du temps, plus elle devient stable. C'est pour ça qu'on déconseille systématiquement de migrer sur une version qui vient d'être publiée. »
En pratique, comptez plusieurs mois après la sortie d'une version majeure avant qu'une migration soit confortable. C'est exactement le raisonnement qu'on applique dans nos deux analyses de versions : ce que change réellement Odoo 19, et surtout faut-il migrer sur Odoo 20, où l'on explique pourquoi la réponse dépend beaucoup plus de votre calendrier que de la feuille de route de l'éditeur.
Règle 2 : tester sur une base dédiée, jamais en production
Odoo permet de disposer de bases de test. Une base est généralement incluse dans un projet, les suivantes s'achètent au mois ou à l'année. On y duplique la production, on y lance le script de migration, on y vérifie ce qui casse.
Cette étape n'est pas optionnelle. C'est elle qui vous dit si votre migration prendra trois jours ou trois mois.
Règle 3 : vos modules spécifiques ne migrent pas tout seuls
C'est le point qui fait exploser les budgets. Le script d'Odoo migre Odoo. Il ne migre pas ce que votre intégrateur a développé pour vous. Chaque module spécifique doit être repris, compris, comparé au nouveau standard et réécrit.
Et la difficulté n'est pas seulement technique. Sur une base développée il y a plusieurs années, une partie des développements ne sert plus à rien parce qu'Odoo a intégré la fonctionnalité nativement depuis. Il faut donc trier : ce qu'on garde, ce qu'on abandonne, et ce qu'on remplace par du standard. Un inventaire des modules natifs les plus structurants aide souvent à faire ce tri plus vite qu'on ne le pense.
Cas Drakkar n°3 : une migration à plus de 20 modules spécifiques
Le contexte : Un client multi-sociétés avec plus de vingt modules développés sur mesure sur une version ancienne d'Odoo, et une forte pression pour passer sur une version récente.
Le problème : Trois difficultés cumulées. Une partie des développements était devenue obsolète, remplacée par du standard Odoo. Une autre partie avait été mal réalisée à l'origine et devait être corrigée avant même d'envisager la migration. Et surtout, l'une des fonctionnalités clés reposait sur un contournement de la gestion multi-sociétés d'Odoo, permettant à chaque boutique de consulter les ventes des autres. Cette porte a été refermée par Odoo dans les versions suivantes : le cloisonnement des données entre sociétés y est devenu strict.
Ce qu'on a fait : On a d'abord challengé le client sur la nécessité réelle de cette fonctionnalité, en expliquant qu'elle allait à l'encontre de la logique de cloisonnement d'Odoo. Il a maintenu son besoin. On a donc repris chaque module un par un : lecture du code existant, analyse du nouveau standard, réécriture, puis optimisation. La fonctionnalité multi-sociétés a fini par être reconstruite, au prix d'un travail de développement lourd.
Le résultat : Un budget de migration de l'ordre de 55 000 €, et deux à trois mois de travail. La migration est passée, mais avec des points de friction résiduels.
Ce qu'il faut retenir : Deux enseignements. D'abord, le coût d'une migration est proportionnel au volume de spécifique, pas au nombre d'utilisateurs. Ensuite, une fonctionnalité obtenue par contournement est une dette à retardement : le jour où l'éditeur referme la porte, vous payez la reconstruction complète, ou vous perdez la fonctionnalité.
Qui est responsable quand ça bugue après la migration ?
C'est le sujet le plus mal traité du marché, et celui qui génère le plus de conflits. Il mérite d'être posé clairement.
Après une migration, il existe deux familles de bugs, avec deux responsables différents.
Les bugs qui viennent de vos modules spécifiques
Si un module développé pour vous a été mal migré, c'est la responsabilité de l'intégrateur qui a réalisé la migration. C'est net, c'est assumable, et ça se corrige.
Les bugs qui viennent du script natif d'Odoo
Le script de migration appartient à Odoo. Aucun intégrateur, aussi bon soit-il, n'y a accès et ne peut le corriger. Quand le bug vient de là, la seule chose à faire est d'ouvrir un ticket auprès d'Odoo et d'attendre leur correction. Le délai dépend entièrement de leur disponibilité.
« On ne peut pas corriger le script d'Odoo, Odoo ne nous donne pas accès à ce script, rappelle François Pascal. On peut auditer, documenter, isoler le problème et démontrer qu'il ne vient pas de nos modules. Ensuite c'est un ticket auprès de Odoo, et on attend. »
Comment on tranche entre les deux
La méthode est toujours la même : on audite jusqu'à identifier la source exacte de l'erreur. Concrètement, on isole les modules spécifiques, on désactive, on rejoue, on compare avec un environnement standard. C'est long, c'est fastidieux, et c'est la seule façon d'établir un fait plutôt qu'une opinion.
Et c'est aussi là que la transparence de l'intégrateur se joue. « Un intégrateur peu scrupuleux peut très bien accuser Odoo pour couvrir ses propres erreurs, reconnaît François Pascal. Si le client n'est pas technique, il ne peut pas vérifier. C'est exactement pour ça qu'il faut documenter chaque audit et pouvoir montrer le raisonnement. »
Pourquoi ça doit être écrit avant de commencer
Le vrai enseignement de ces situations n'est pas technique, il est contractuel et il est humain. Un client qui perd des données après une migration considère par défaut que c'est la faute de l'intégrateur, et aucune explication a posteriori ne le convaincra vraiment.
La seule parade est d'annoncer la répartition des responsabilités avant le démarrage, par écrit :
- ce qui relève de l'intégrateur : la migration des modules spécifiques, les corrections préalables, les tests
- ce qui relève d'Odoo : le script de migration natif et les régressions du standard
- ce qui va probablement être perdu ou dégradé, avec la liste précise
- le processus prévu quand un bug survient : qui audite, qui ouvre le ticket, sous quel délai
C'est moins confortable à vendre. C'est la seule façon de terminer une migration avec un client qui vous fait encore confiance.
FAQ : les cas particuliers qu'on nous pose le plus souvent
Peut-on passer d'Odoo Community à Odoo Enterprise ?
Oui, et techniquement c'est plus simple qu'on ne l'imagine. Enterprise n'est pas un autre logiciel, c'est une couche de modules supplémentaires qui héritent du Community et ajoutent des fonctionnalités. L'image qu'utilise François Pascal : « Community, c'est vous en normal. Enterprise, c'est vous avec la cape. Vous êtes la même personne, vous avez juste des super-pouvoirs en plus. » La migration est simple s'il n'y a pas de développement spécifique. Elle se complique dès qu'il y en a, parce que les entreprises qui ont choisi Community pour éviter les licences ont souvent développé elles-mêmes des fonctionnalités que l'Enterprise fournit nativement. Il faut alors trier entre ce qu'on remplace par du standard et ce qu'on conserve. Le détail des différences fonctionnelles est dans notre comparatif Odoo Community vs Odoo Enterprise.
Pourquoi partir sur Community peut être un mauvais calcul ?
Ce n'est pas systématiquement un mauvais calcul, mais il faut regarder ce qu'on n'a pas. Certains sujets réglementaires ou structurants ne sont disponibles que sur Enterprise : facturation électronique, synchronisation bancaire, PLM, certaines exigences de conformité comptable comme l'inaltérabilité des factures. Économiser des licences pour redévelopper ensuite ces briques revient presque toujours plus cher. Si l'open source reste votre piste, notre sélection des meilleurs ERP open source pour PME et ETI vous donnera les points de comparaison.
Peut-on passer d'Odoo.sh à Odoo Online ?
Uniquement si vous n'avez aucun module spécifique. Odoo Online n'accepte pas de code personnalisé, uniquement de la configuration et du Studio. Le mouvement inverse, d'Online vers Odoo.sh, est en revanche très fréquent : une entreprise démarre en Online en se disant qu'elle ne fera jamais de développement, puis découvre un besoin qu'Odoo ne couvre pas nativement.
Sur Odoo Online, on ne peut vraiment rien corriger soi-même ?
Sur du bug natif, non. La seule voie est le ticket auprès d'Odoo. C'est le compromis assumé du SaaS : moins de responsabilité, moins de liberté.
Qui est responsable de la sécurité selon l'hébergement ?
Sur Online et Odoo.sh, l'infrastructure est gérée par Odoo. Sur un serveur dédié, la sécurité, les sauvegardes et la disponibilité relèvent de celui qui administre le serveur. Et une fois que vous avez validé un accès, vous en portez la responsabilité. La comparaison de François Pascal vaut ce qu'elle vaut mais elle est juste : « C'est comme votre carte bancaire. Si vous avez cliqué sur le bouton de validation, vous n'irez pas demander un remboursement en disant que vous ne saviez pas. »
Combien de temps met Odoo à corriger un ticket bloquant ?
Il n'y a pas de règle. Ça peut aller de quelques jours à beaucoup plus selon leur charge et la criticité du sujet. C'est un paramètre à intégrer dans votre planning de migration, pas à découvrir en cours de route.
Et si la reprise était l'occasion de changer d'ERP ?
C'est une question légitime, et on préfère qu'elle soit posée franchement plutôt qu'esquivée. Si vous voulez remettre Odoo en concurrence avant de réinvestir dessus, nos comparatifs Odoo vs Sage et Odoo vs EBP, ainsi que notre guide pour choisir le meilleur ERP pour votre PME, vous donneront une base de comparaison honnête.
Checklist : les 7 clauses à exiger dans votre contrat d'intégration Odoo
Si vous ne deviez retenir qu'une seule chose de cet article, ce serait celle-ci. La quasi-totalité des situations bloquantes qu'on reprend aurait été évitée par un contrat correctement rédigé au départ.
- La propriété des développements spécifiques. Écrivez explicitement que les modules développés pour votre entreprise vous appartiennent, et que le prestataire ne peut pas les réutiliser ailleurs.
- La localisation et la propriété du dépôt de code. Exigez que le dépôt Git soit hébergé dans une organisation dont vous êtes administrateur, dès le premier jour. Pas au moment du départ.
- La procédure de réversibilité. Décrivez ce qui se passe le jour où vous changez de prestataire : quels accès sont transférés, dans quel délai, avec quel niveau de documentation.
- La documentation technique attendue. Liste des modules, description de leur fonction, dépendances, et environnements existants. Sans ça, votre prochain intégrateur repart d'une page blanche à vos frais.
- La répartition des responsabilités en cas de bug. Distinguez noir sur blanc ce qui relève du standard Odoo et ce qui relève des développements spécifiques.
- L'interdiction de modifier le cœur d'Odoo. Formulez-le comme un engagement de qualité : les développements passent par des modules héritant du standard, jamais par une modification directe du code natif.
- Les conditions de migration de version. Prévoyez qui prend en charge la migration des modules spécifiques, sur quelle base de coût, et avec quel préavis.
Ces sept lignes coûtent une relecture d'avocat. Le cas n°2 de cet article a coûté environ 100 000 €. Pour la partie sélection du prestataire lui-même, tout est dans notre guide Choisir son intégrateur Odoo.
En conclusion
Reprendre un projet Odoo mal géré n'est jamais un sujet purement technique. Sur le plan technique, tout se règle : on sait migrer des modules, reconstruire un environnement, importer des données, isoler un bug natif. Ce qui bloque réellement, c'est ce qui n'a pas été écrit au démarrage.
Les trois cas présentés ici racontent la même histoire à trois budgets différents. Une reprise où tout était clair : trente minutes. Une reprise avec du spécifique à migrer : 55 000 €. Une reprise où le code était retenu faute de clause contractuelle : un projet complet de reconstruction à six chiffres.
Si vous êtes aujourd'hui dans une situation dégradée, la bonne séquence est toujours la même. Identifiez votre type de déploiement. Vérifiez qui est administrateur de votre dépôt de code. Faites auditer l'état réel de vos développements. Et seulement ensuite, décidez entre repartir à neuf, nettoyer puis migrer, ou migrer tel quel.
Et si vous êtes en train de choisir un intégrateur, relisez la checklist ci-dessus avant de signer. C'est le meilleur investissement que vous ferez sur votre projet ERP.
Cet article vous a été utile ? Partagez-le avec un dirigeant ou un DSI qui se demande comment reprendre la main sur son ERP. Notre équipe nantaise de 23 experts en ERP, développement sur-mesure et IA est disponible pour en discuter.
