Options de déploiement Odoo : Online, Odoo.sh ou self-hosted
L'endroit où vous faites tourner Odoo façonne le quotidien de votre équipe IT, de vos développeurs et de votre directeur financier. Nous opérons les trois modèles — Odoo Online, Odoo.sh et self-hosted — et chacun gagne pour un type d'entreprise différent.
Il n'y a pas de réponse universellement juste. Le bon choix dépend de l'appétence Ops de votre équipe, de la profondeur de vos customisations, de vos règles de résidence des données, et de la prévisibilité que vous attendez de la facture.
Nous parcourrons les trois options, les arbitrages qui comptent en pratique, les erreurs les plus fréquentes, et comment nous aidons les clients à choisir le modèle qui tiendra encore deux ans plus tard. Version honnête, pas version brochure.
Si vous dimensionnez ce choix pour la première fois, attendez-vous à le réviser. Les entreprises grandissent et sortent des modèles de déploiement, et changer est faisable — mais jamais aussi peu cher que de bien choisir au départ.
Odoo Online — chemin le plus rapide, extension la plus étroite
Odoo Online est l'option SaaS opérée par Odoo S.A. C'est la façon la plus rapide de démarrer et la plus simple à opérer : pas de serveurs, pas de patches, pas de DevOps. L'arbitrage est réel mais borné : pas de code custom, pas de SSH, profondeur d'intégration limitée.
Nous recommandons Online quand le client veut Odoo standard, point final. Les PME en services, retail et industrie légère y sont à l'aise. Les clients avec besoins forts en modules custom ne devraient pas choisir Online — ils heurteront le mur en moins d'un an.
- Hébergé par Odoo, zéro infrastructure pour le client
- Patches et migrations gérés par Odoo à cadence fixe
- Pas de modules Python custom — uniquement Studio et apps standard
- SLA et baseline sécurité solides out of the box
- Idéal : PME sur Odoo standard sans modules custom
Odoo.sh — plateforme managée avec code custom
Odoo.sh est l'offre PaaS : infrastructure managée, mais vous gardez la capacité de livrer des modules custom. Branches intégrées, environnements de staging, sauvegardes automatiques, workflow Git propre que toute équipe moderne apprécie.
C'est notre recommandation par défaut pour le mid-market avec quelques modules custom et un partenaire qui fait l'ingénierie. Le coût par fonctionnalité est le plus bas des trois et la charge opérationnelle reste gérable.
- Infrastructure managée avec modules Python custom supportés
- Branches, staging et prod out of the box
- Sauvegardes automatiques et restore en un clic
- Workflow Git serré — code review et CI intégrés
- Idéal : mid-market avec partenaire livrant du code custom
Self-hosted — contrôle total, responsabilité totale
Self-hosted veut dire tourner Odoo sur votre propre infrastructure : vos serveurs, vos patches, votre monitoring, vos sauvegardes. Vous obtenez le contrôle total — sur l'OS, la base, le réseau, la résidence — et prenez la responsabilité totale de garder l'ensemble en santé.
Self-hosted est la bonne réponse pour des règles de résidence fortes, du custom très lourd, ou une équipe Ops interne qui opère déjà des charges sérieuses. C'est la mauvaise réponse pour une PME sans capacité DevOps réelle.
- Contrôle complet de l'infra, OS, base et réseau
- N'importe quel module custom, intégration, politique de version
- Responsabilité totale de sauvegardes, patches et sécurité
- Résidence des données où vous voulez
- Idéal : grands clients avec Ops fort ou résidence stricte
Coût — prévisible, variable et caché
Chaque modèle a une forme de coût différente. Online est le plus prévisible : par utilisateur par mois, presque sans surprises. Odoo.sh est prévisible mais scale avec workers et stockage. Self-hosted a le coût de licence le plus bas et le coût opérationnel le plus haut — incluant les salaires des personnes qui l'opèrent.
Nous modélisons le TCO sur trois ans avant tout choix. L'option 'la moins chère' à un an est rarement la moins chère à trois ans. Self-hosted en particulier est attractif l'année 1 et coûte cher l'année 2 quand la facture Ops arrive.
- Online — totalement prévisible, scale linéairement par utilisateur
- Odoo.sh — abonnement prévisible plus workers et stockage
- Self-hosted — licence basse, Ops haut ; demande un TCO honnête
- Les trois — LLM et intégrations sont en plus en 19.x
- Réserver du budget pour les migrations — annuel sur Online, planifié ailleurs
Comment choisir — les questions que nous posons d'abord
Nous ne recommandons jamais un modèle depuis une brochure. Nous posons sept questions, dans cet ordre, et les réponses réduisent généralement le choix à une ou deux options.
Si un client ne sait pas répondre, la décision de déploiement est prématurée. Nous mettons en pause, obtenons les réponses, puis reprenons. Un mauvais choix ici coûte cher à inverser.
- Avez-vous besoin de modules Python custom maintenant ou dans 12 mois ?
- Avez-vous des règles spécifiques de résidence des données ?
- Votre équipe a-t-elle une vraie capacité DevOps pour opérer Odoo ?
- Quelle prévisibilité demandez-vous à la facture mensuelle ?
- Quelle est l'importance de votre autonomie de migration ?
Erreurs de choix de déploiement que nous voyons sans cesse
Cinq schémas qui transforment un bon modèle en mauvais fit.
- Choisir Online puis tenter de glisser des modules custom par contournement.
- Choisir self-hosted sans capacité Ops réelle — le système se dégrade.
- Choisir sur le coût année 1 au lieu du TCO 3 ans.
- Sous-estimer la dépense LLM et intégrations en plus des licences Odoo.
- Ignorer la cadence de migration — Online livre souvent, self-hosted quand vous livrez.
Indicateurs montrant que votre déploiement est sain
Quel que soit le modèle, surveiller mensuellement.
- Uptime sur 30 jours roulants — viser 99,9%.
- Taux de restore réussi depuis la dernière sauvegarde — doit être 100%.
- Délai de patch — jours entre disponibilité et application.
- Tendance du coût total par utilisateur actif — stable ou en baisse.
- Temps moyen de récupération sur incidents — minutes, pas heures.
Comment Flydoo orchestre les choix de déploiement
Nous tenons un atelier d'une demi-journée avec les leads IT, finance et opérations du client. Nous parcourons les sept questions, modélisons le TCO trois ans pour les deux options les plus probables, et écrivons une recommandation d'une page avec son raisonnement. Le client signe le modèle avant le démarrage du build.
Nous reprenons la décision après un an d'opération. Parfois la croissance ou de nouvelles obligations bougent la bonne réponse. Changer de modèle est un projet — faisable, mais planifié, jamais improvisé.
- Atelier d'une demi-journée IT/finance/ops sur les sept questions
- Modèle TCO trois ans pour les deux options les plus probables
- Recommandation d'une page avec raisonnement explicite
- Revue annuelle du fit déploiement après go-live
- Plan de migration prêt si la bonne réponse change
Checklist avant de figer le modèle de déploiement
Cocher la majorité = décision qui tient dans le temps.
- Roadmap modules custom à 12 mois convenue
- Règles de résidence vérifiées avec juridique et conformité
- Capacité Ops interne évaluée honnêtement
- TCO trois ans modélisé pour les deux options finalistes
- SLA de sauvegarde et restore documentés et acceptés
- Cadence et propriété de la migration définies par modèle
- Chemin de migration entre modèles documenté en cas de bascule
Choisir le modèle qui collera à l'entreprise que vous serez dans deux ans
Il n'y a pas de meilleur modèle — seulement le meilleur fit pour votre situation aujourd'hui et dans deux ans. Online gagne sur la simplicité. Odoo.sh gagne sur le coût par fonctionnalité avec du code custom. Self-hosted gagne sur le contrôle et la résidence.
Quelle que soit l'option, écrivez pourquoi. Quand la croissance ou la régulation vous oblige à reprendre la décision, le raisonnement rend la conversation plus rapide et la migration plus courte.
Si vous voulez un deuxième avis structuré avant de vous engager, nous menons volontiers l'atelier avec votre équipe et vous remettons la recommandation d'une page.
Questions fréquentes
Quel modèle est le moins cher ?
À un an, Odoo Online est généralement le moins cher. Sur trois ans cela dépend de la profondeur de customisation et de la capacité Ops — Odoo.sh est souvent le meilleur coût par fonctionnalité pour le mid-market, et self-hosted peut gagner pour de très grandes organisations avec Ops. Toujours modéliser le TCO avant de décider.
Puis-je migrer d'Online vers Odoo.sh plus tard ?
Oui. La migration d'Online vers Odoo.sh est un chemin bien balisé que nous avons fait pour plusieurs clients ayant dépassé Online quand leurs besoins custom ont grandi. Compter quelques semaines de projet — ce n'est pas un clic mais ce n'est pas héroïque non plus.
Où sont hébergées mes données sur Online et Odoo.sh ?
Odoo opère des régions en UE et aux US (et quelques autres). Vous pouvez demander un hébergement UE à l'inscription. Pour des règles strictes — uniquement ce pays, uniquement ce provider — le self-hosted est généralement la seule option qui satisfait l'auditeur.
Qui est responsable des sauvegardes et de la sécurité par modèle ?
Sur Online et Odoo.sh, Odoo gère sauvegardes, patches et sécurité plateforme ; vous gérez les accès utilisateurs et votre code custom (Odoo.sh seulement). En self-hosted vous possédez tout : sauvegardes, patches, sécurité réseau, monitoring, gestion d'incidents. Traitez cette responsabilité comme un vrai workstream.
Comment diffèrent les migrations selon le modèle ?
Online migre à la cadence d'Odoo — prévisible mais pas toujours le moment que vous auriez choisi. Odoo.sh migre quand vous le déclenchez avec outillage managé. Self-hosted migre quand vous livrez — autonomie totale, responsabilité totale. L'autonomie est réelle, le coût de sauter des versions aussi.
Envie d'en discuter pour votre propre projet Odoo ? Parlons-en.