Quand une entreprise se consolide sur Odoo, le réflexe est de tout remplacer. Un seul système, un seul login, une seule source de vérité. Cela fait un beau récit en comité de pilotage. C'est aussi, très souvent, la décision la plus coûteuse du projet.
Sur une intégration récente — un installateur solaire qui pilotait toute son activité sur quatre systèmes déconnectés — nous en avons remplacé trois et délibérément conservé le quatrième. Cette seule décision a fait gagner plusieurs semaines et beaucoup de capital de confiance avec les équipes. Voici le raisonnement que j'applique, et pourquoi « tout remplacer » est un moins bon réflexe qu'il n'y paraît.
Les quatre questions
Avant de décider du sort d'un outil existant, je pose quatre questions dans cet ordre. L'ordre compte, parce que les deux premières portent sur votre activité et les deux dernières sur la technique — et la technique ne doit pas voter en premier.
1. Cet outil est-il le référentiel de quelque chose ?
Si un outil détient des données que personne d'autre ne détient, et que d'autres processus en dépendent, le remplacer est un projet de migration à part entière, pas une ligne de devis. Ce n'est pas une raison de le garder. C'est une raison de le chiffrer honnêtement.
2. Les équipes aiment-elles réellement s'en servir ?
On balaie cette question comme étant « molle ». Elle ne l'est pas. Un déploiement ERP dépense déjà l'essentiel de son capital politique à demander aux gens de changer leur façon de travailler. Chaque outil que vous remplacez puise dans la même réserve. Si un système fonctionne bien et que les équipes y tiennent, le supprimer vous achète un combat dont vous n'aviez pas besoin, sur un terrain que vous n'avez pas choisi.
3. Combien coûte l'intégration — à construire et à maintenir ?
Les équipes chiffrent la construction et oublient la maintenance. Une intégration API n'est pas un coût ponctuel : c'est une petite taxe permanente, payée à chaque montée de version des deux côtés. Chiffrez trois ans, pas trois semaines.
4. Le remplacement débloque-t-il quelque chose que l'intégration ne peut pas ?
Parfois oui, et la réponse est alors évidente. Rapatrier les devis dans Odoo signifiait que devis, commandes et factures partageaient enfin un seul modèle de données — aucune intégration n'aurait produit cela. Mais si la réponse honnête est « ce serait plus propre », ce n'est pas un argument métier. C'est une préférence esthétique avec un budget accroché.
Ce que cela a donné concrètement
L'installateur solaire utilisait HubSpot pour le CRM, Notion pour la documentation, Vista pour les devis, et Allo pour la téléphonie.
Les trois premiers sont partis. HubSpot détenait des données client que le CRM d'Odoo gère nativement, et garder les deux garantissait deux versions de la vérité. Notion détenait une documentation qui avait sa place à côté des processus qu'elle décrivait. Vista produisait des devis qui devaient devenir des commandes puis des factures — exactement la chaîne pour laquelle Odoo est construit. Dans les trois cas, le remplacement débloquait quelque chose que l'intégration ne pouvait pas.
Allo est resté. La téléphonie fonctionnait. Les équipes étaient à l'aise avec. Rien en aval ne dépendait du fait qu'Odoo possède l'appel lui-même — seulement du fait qu'Odoo sache que l'appel avait eu lieu, ce qu'une API livre parfaitement. Le remplacer aurait coûté du budget et de la confiance pour un schéma d'architecture marginalement plus propre.
Nous l'avons donc intégré : les appels remontent dans Odoo via l'API Allo, une opportunité est créée lorsque les critères de qualification sont remplis, et la téléphonie reste où elle était. Personne n'a eu à réapprendre à passer un appel au beau milieu d'une migration ERP.
Le piège inverse
L'erreur symétrique est tout aussi fréquente et plus difficile à repérer : tout intégrer. Chaque outil conservé est une interface à construire, à surveiller et à migrer. Gardez-en six et vous n'avez pas déployé un ERP — vous avez construit une couche de middleware avec un logo Odoo dessus, et elle vous appartient pour toujours.
Le signal que la ligne est franchie est presque toujours le même : il vous faut un schéma pour expliquer où vit une fiche client. Si personne ne peut répondre en une phrase, vous avez trop de systèmes, quelle que soit la qualité de chaque intégration.
Une règle empirique
Remplacez les outils qui portent vos objets métier. Intégrez les outils qui exécutent une action.
Clients, devis, commandes, factures, projets, stock : ce sont des objets métier, et leur place est au même endroit, parce que leur valeur vient de leurs liens entre eux. Téléphonie, signature électronique, exports comptables, étiquettes de transport : ceux-là exécutent une action et rendent un résultat. Ils peuvent rester où ils sont, tant que le résultat atterrit de façon fiable dans Odoo.
Ce n'est pas une loi universelle. Mais c'est un bien meilleur point de départ que « tout remplacer », et cela résiste mieux au contact d'un budget réel.
Un dernier point
Quoi que vous décidiez, décidez-le pendant le cadrage et écrivez-le. La version coûteuse de cette conversation est celle qui arrive au quatrième mois, quand quelqu'un découvre que l'outil que tout le monde croyait remplacé tourne toujours, détient toujours des données, et compte désormais trois mois d'enregistrements que personne n'avait prévu de reprendre.