Un projet Odoo qui ne se déroule pas comme prévu est une situation plus courante qu'il n'y paraît, et elle n'a rien d'exceptionnel dans le déploiement d'un logiciel de gestion. Vous avez engagé du temps et des ressources, et le résultat ne correspond pas à ce qui était attendu. Avant de proposer quoi que ce soit, il faut reconnaître cette situation pour ce qu'elle est : un projet échoue rarement à cause d'une seule partie, et nous n'avons pas connaissance du contexte complet — délais, budget, communication, contraintes des deux côtés — dans lequel les décisions ont été prises. Ce document décrit comment reprendre un projet Odoo en difficulté de façon posée, sans opportunisme.
Il n'y a pas lieu de chercher un responsable avant d'agir. Un déploiement Odoo implique plusieurs parties — le prestataire, l'entreprise cliente, parfois des tiers comme un hébergeur ou un autre éditeur logiciel connecté — et chacune influence le résultat final. Ce qui compte à ce stade n'est pas de reconstituer l'historique des décisions, mais de comprendre l'état réel du système aujourd'hui et de décider en connaissance de cause de la suite à lui donner.
Les situations typiques
Plusieurs scénarios reviennent régulièrement chez les entreprises qui cherchent à reprendre un projet Odoo existant.
- Le prestataire précédent est injoignable ou a cessé son activité. Plus de réponse aux demandes, plus de suivi, parfois plus d'entreprise du tout.
- Le projet s'est arrêté en cours de route. Une partie de la configuration existe, mais le déploiement n'a jamais été finalisé.
- Le budget a été dépassé sans mise en production. Des ressources ont été investies, mais l'outil n'est toujours pas utilisable au quotidien.
- L'instance est en production, mais inutilisable. Les équipes contournent l'outil, reviennent à Excel ou à d'anciens systèmes, faute de configuration adaptée à leurs processus réels.
- La comptabilité produite est fausse. Écarts, décomptes TVA incohérents, rapprochements bancaires qui ne se font jamais.
- Des développements non documentés. Du code spécifique tourne en production sans que personne ne sache exactement ce qu'il fait ni pourquoi il a été écrit ainsi.
- Personne, en interne, ne sait comment fonctionne l'instance. La dépendance à une seule personne — souvent le prestataire lui-même — s'est installée sans que l'entreprise s'en rende compte.
La première étape : reprendre la main sur vos accès, votre code et vos données
Avant tout diagnostic ou toute décision sur la suite, il faut s'assurer que l'entreprise contrôle réellement ses propres actifs. C'est une étape à traiter en priorité, souvent avant même de chercher un nouveau prestataire, parce qu'un accès perdu peut devenir très difficile à récupérer une fois le lien avec le prestataire précédent définitivement rompu.
- L'accès administrateur à l'instance Odoo, pas seulement un compte utilisateur.
- L'accès à l'hébergement sur lequel tourne l'instance, ou au moins la connaissance de qui l'héberge et sous quel contrat.
- La propriété du nom de domaine associé, s'il y en a un, et de sa gestion DNS.
- Le code des développements spécifiques, dans un dépôt que l'entreprise contrôle, pas seulement sur la machine du prestataire.
- Les sauvegardes existantes et un export des données à jour, indépendamment de ce qui se passe ensuite.
Tant que ces éléments ne sont pas sécurisés du côté de l'entreprise, toute discussion sur la suite du projet reste fragile : on ne décide pas sereinement de l'avenir d'un système sur lequel on n'a pas la main. Dans les cas les plus tendus, où le contact avec le prestataire précédent est rompu, cette étape peut demander de solliciter l'hébergeur directement, de vérifier les conditions contractuelles de propriété des données, ou de faire valoir un droit de récupération prévu dans le contrat initial. C'est une démarche parfois inconfortable, mais elle conditionne tout le reste.
L'état des lieux technique et comptable
Une fois les accès sécurisés, l'étape suivante est un diagnostic complet, proche dans sa méthode d'un audit d'instance Odoo classique, mais orienté vers une décision de reprise plutôt que vers une simple photographie. Il porte sur la configuration comptable et TVA, le paramétrage de paie s'il existe, les modules actifs, les développements spécifiques et leur niveau de documentation, la qualité des données, les droits d'accès, et l'état des sauvegardes. La dimension comptable est examinée avec la même rigueur que la dimension technique : une instance qui tourne sans erreur visible peut malgré tout produire des chiffres faux, et c'est souvent ce point précis qui a motivé la recherche d'un nouvel accompagnement.
Ce diagnostic répond à des questions très concrètes. Les écritures comptables générées jusqu'ici sont-elles exploitables, ou faut-il revenir sur une période pour les corriger ? Le décompte TVA transmis aux autorités correspond-il réellement à l'activité de l'entreprise ? Les développements spécifiques en production posent-ils un risque immédiat, ou peuvent-ils attendre une prochaine étape ? Les réponses à ces questions déterminent l'urgence de chaque action, et évitent de traiter comme prioritaire un point secondaire pendant qu'un problème plus grave reste ignoré.
Décider : réparer, reconstruire, ou remettre au standard
L'état des lieux débouche sur un choix entre trois options, et ce choix doit reposer sur des critères concrets plutôt que sur une impression générale de la situation.
- Réparer l'existant a du sens quand la base est globalement saine : la configuration correspond aux besoins réels, les développements spécifiques sont de qualité correcte, et les problèmes constatés sont localisés et identifiables.
- Repartir d'une base propre se justifie quand la configuration s'éloigne trop des processus réels de l'entreprise, quand les développements sont trop fragiles ou trop nombreux pour être fiabilisés un par un, ou quand la qualité des données est trop dégradée pour être corrigée de façon fiable.
- Remettre l'instance au standard Odoo consiste à retirer les personnalisations les plus risquées et à revenir autant que possible aux fonctionnalités natives, notamment lorsque les développements spécifiques ne sont pas documentés et compliquent chaque montée de version. C'est souvent la voie la plus soutenable à moyen terme.
Le critère déterminant n'est pas l'ampleur apparente des dégâts, mais la soutenabilité de chaque option dans le temps : une réparation rapide qui laisse les mêmes causes en place n'aura fait que reporter le problème. Une instance techniquement instable mais dont la configuration métier est pertinente n'a pas besoin d'être reconstruite ; à l'inverse, une instance stable mais bâtie sur des processus qui ne correspondent plus à l'activité réelle de l'entreprise restera un boulet quels que soient les correctifs techniques apportés.
La remise en état
Une fois l'option choisie, la remise en état suit les priorités identifiées lors de l'état des lieux : correction de la configuration comptable et TVA en premier, puisqu'elle a un impact direct et immédiat sur les obligations légales de l'entreprise, puis fiabilisation des données, puis reprise ou remplacement des développements les plus fragiles. Selon les besoins, cela peut mobiliser nos pages dédiées à Odoo Comptabilité, à la paie, ou au développement spécifique. Quand la situation s'apparente davantage à un nouveau déploiement qu'à une correction, elle rejoint notre page implémentation Odoo.
Documentation et transfert de connaissances
Une reprise de projet qui se limite à corriger les symptômes reproduit la dépendance qui a mené à la situation initiale. La documentation n'est donc pas une étape annexe : chaque choix de configuration, chaque développement spécifique, chaque règle métier paramétrée dans Odoo doit être écrit quelque part de façon compréhensible par une personne qui n'a pas participé au projet. Cette documentation n'a pas besoin d'être exhaustive au sens d'un manuel technique complet : elle doit surtout répondre aux questions qu'une personne extérieure se poserait en découvrant l'instance — pourquoi ce champ existe, à quoi sert cette automatisation, quelle règle métier justifie ce paramétrage plutôt qu'un autre.
Ce travail s'accompagne d'un transfert de connaissances vers vos équipes, pour que l'utilisation quotidienne de l'outil ne repose plus sur une seule personne, interne ou externe. Voir notre page formation Odoo pour cet accompagnement, et support Odoo pour la suite du suivi une fois l'instance remise en état.
Éviter de se retrouver dans cette situation avec le prestataire suivant
Certaines précautions, posées dès le début d'une nouvelle collaboration, réduisent nettement le risque de revivre une situation similaire :
- La réversibilité : la possibilité concrète de changer de prestataire sans repartir de zéro, prévue dès le départ plutôt que négociée en urgence.
- Les accès : l'entreprise conserve en permanence les accès administrateur à son instance, à son hébergement et à son nom de domaine.
- La documentation : exigée comme un livrable du projet, pas comme une option laissée à l'appréciation du prestataire.
- La propriété du code : les développements spécifiques réalisés pour l'entreprise lui appartiennent, dans un dépôt qu'elle contrôle.
Ces quatre points ne garantissent pas qu'un projet se déroule sans accroc, mais ils garantissent qu'un accroc reste réparable. Pour situer cette démarche dans l'ensemble de nos prestations, voir Odoo ERP à Genève et Odoo à Genève. Si le doute porte davantage sur l'état général d'une instance que sur un projet clairement arrêté, notre page audit d'instance Odoo peut être le point de départ le plus adapté.