Après le focus sur la sécurité des accès et les enjeux de l'IA, place à la migration Odoo — mais vue sous un angle particulier : celle que le client peut réaliser tout seul, sans faire appel systématiquement à un intégrateur. Dans ce nouvel épisode du podcast Orbeet, Franck et Florent passent en revue les trois environnements possibles — Odoo Cloud, Odoo SH et On-Premise — et les points de vigilance propres à chacun.
Odoo Cloud : un bouton, mais méfiance sur Studio
En version cloud, la promesse de l'éditeur est tenue : vous appuyez sur un bouton et, la plupart du temps, tout se passe bien — au point qu'Odoo finit par vous migrer automatiquement. Pas de développement spécifique possible, donc pas de dette à traîner.
Le point de friction se cache dans Odoo Studio. Franck a récemment dépanné un client qui avait pourtant suivi les préconisations de l'éditeur, en personnalisant ses rapports en QWeb dans Studio. La migration était passée, mais le rapport — qui reste du code — référençait des champs du data model d'Odoo dont les noms avaient changé. Résultat : impossibilité de générer les devis, et un client perdu face à une erreur incompréhensible. Dépannage en cinq minutes pour qui connaît Odoo depuis quinze ans, mais surtout une leçon : avec Redner, la correction se fait dans le mapping, dans un tableau simple, et non au cœur du code du rapport — la méthode à privilégier pour éviter la dette technique, même en cloud.
Odoo SH : le vrai sujet, ce sont les modules complémentaires
Odoo SH, le PaaS de l'éditeur, introduit une dimension nouvelle : le développement spécifique, y compris pour des « super utilisateurs » non développeurs — avec, depuis peu, Claude AI intégré sur les branches de développement. La migration de la base se lance d'un bouton, avec livraison sur une branche de test.
Mais le vrai chantier se situe ailleurs : les modules complémentaires ajoutés au serveur — souvent issus de l'OCA, la communauté qui maintient une suite de modules open source pour Odoo. S'ils ont déjà été migrés par leur éditeur, tout va bien, moyennant un workflow particulier à respecter. Sinon, deux options : migrer le module soi-même, ou attendre. Florent en a fait l'expérience avec une cliente à qui quinze jours de travail étaient annoncés : ses modules OCA n'étaient tout simplement pas encore portés sur la nouvelle version. En open source, pas de date fixée. La solution intermédiaire, restrictive : revenir au pur standard d'Odoo. D'où l'importance de choisir avec précaution l'éditeur des modules dès l'installation.
L'autonomie encadrée : CI, code review et formation
C'est ici que l'épisode présente une approche originale, celle qu'Orbeet met en œuvre auprès de clients devenus autonomes : une offre d'accompagnement où ce sont les équipes du client qui font la migration — et plus largement le code — tandis qu'Orbeet assure la revue de code et le filet de sécurité.
Concrètement, l'intégrateur fournit un véritable atelier : une forge GitLab avec une chaîne de CI adaptée au projet, qui lance les tests à chaque ajout de code, valide, packager et build à partir d'images Odoo standardisées. Ces images permettent au développeur de travailler sur sa machine comme s'il était sur Odoo SH — ce qui lève l'un des principaux pain points, l'installation d'un environnement local complet. S'y ajoutent le conseil et la formation : « prenez n'importe quel développeur, on vous le forme, il sait faire du Odoo en deux, trois semaines ». Une ressource polyvalente en interne, appuyée par cette infrastructure et cette supervision, rend le développement à la portée de « quasiment toutes les bourses » — un choix d'autant plus pertinent qu'avec les IA actuelles, tout va plus vite.
On-Premise : la CVE devient votre responsabilité
En auto-hébergement, le calcul change : pas d'auto-upgrade de l'éditeur. Quand une CVE est découverte dans Odoo ou dans un composant Python ou JavaScript, c'est à vous de la détecter, de la corriger et de déployer. Orbeet propose là-dessus un service dédié : monitoring des failles de sécurité référencées et maintenance d'images système intégrant systématiquement tous les patchs, mises à disposition dans une registry, le rollout restant à la charge des exploitants du client.
Un argument de poids pour ne pas surestimer l'autonomie totale : en cloud, le correctif arrive tout seul — parfois avec quelques surprises au petit matin, mais il arrive.
L'effet bus : le risque caché de l'autonomie
Point le plus critique de l'épisode : l'autonomie appuyée sur une ressource unique, salariée ou indépendante, crée un « bus factor » — que se passe-t-il si cette personne passe sous un bus, se casse la jambe ou prend trois mois de vacances après trois ans sans en prendre ? Votre production s'arrête.
La réponse d'Orbeet : un accompagnement dans lequel l'intégrateur forme chaque nouvelle ressource lors du turnover, transmet les bonnes pratiques et les outils, et assure le support. Le client garde son autonomie avec une personne unique, mais sans l'épée de Damoclès de la dépendance.
Autre piège fréquent, l'indépendant « qui fait ça en deux jours » pour un coût apparent dérisoire. Sans documentation ni tests, ces deux jours par-ci par-là, accumulés pendant des années, se paient double au moment de la migration : chaque modification devra être repassée dans l'autre sens. Faire les choses bien dès le début paraît plus cher, mais génère des économies réelles sur les cycles de migration successifs.
Pourquoi migrer, d'ailleurs ?
Florent termine avec une question de fond : pourquoi est-on obligé de migrer avec Odoo, alors que d'autres logiciels, comme une suite mail, ne demandent jamais rien ? La question reste ouverte, mais elle pose le bon débat : à quel rythme vouloir migrer ? Suivre chaque nouvelle version immédiatement, ou laisser les autres essuyer les plâtres — sans jamais prendre deux ans de retard ?
Retrouvez l'intégralité de cet échange dans le podcast Orbeet :
https://www.youtube.com/watch?v=qEKpjXplL8M
Besoin d'engager une migration Odoo ?
Nos experts vous forment, outillent et sécurisent vos migrations, en cloud, SH ou On-Premise.