Odoo hébergé avec votre intégrateur : qui fait quoi entre l'hébergeur, l'intégrateur et le client

La première demande d'un intégrateur, c'est souvent un accès SSH « pour être autonome ». Dans les faits, beaucoup y renoncent dès que la question se pose sérieusement. Un accès shell sur une plateforme Kubernetes qu'on ne pratique pas tous les jours, c'est le meilleur moyen de commettre une erreur de manipulation. Et quand quelque chose casse, plus personne ne sait qui est responsable : l'hébergeur qui opère la plateforme, ou l'intégrateur qui y a tapé une commande.

Personne n'a envie de copier-coller des commandes Kubernetes générées par une IA sur une technologie qu'il ne maîtrise pas, en production, un vendredi soir. L'intégrateur veut garder la main sur ce qu'il connaît (le code Odoo, les modules, les données métier) et ne pas subir la complexité de l'infrastructure.

Pas d'accès SSH, donc : moins d'erreurs de manipulation, et une frontière nette entre ce que fait l'hébergeur et ce que fait l'intégrateur.

Renoncer au SSH ne veut pas dire travailler à l'aveugle. L'intégrateur a besoin de quelques gestes précis, et de rien d'autre :

• Redémarrer l'instance Odoo après un déploiement ou un changement de configuration.
• Lire les journaux applicatifs, pour savoir si un problème vient du code ou de l'infrastructure avant d'ouvrir un ticket.
• Gérer les sauvegardes : en demander une avant une opération sensible, récupérer une copie pour la recette.

Dans l'offre infogérée, France Nuage cadre ces actions avec l'intégrateur au moment du devis : lesquelles sont ouvertes, sur quel environnement, par qui. Les accès sont nominatifs et tracés. On sait qui a redémarré quoi, et quand.

Le RACI est le document qui évite les débats en pleine panne. Il se lit ligne par ligne : pour chaque sujet, qui le réalise (R), qui décide et valide (A), qui est consulté avant (C), qui est informé après (I). Voici le modèle que nous proposons de reprendre, puis d'ajuster au contrat.

Trois lignes demandent un mot de plus.

Les deux montées de version sont distinctes. Passer d'une version d'Odoo à la suivante est un projet applicatif : migration des données, adaptation des modules, recette, validation par le client. C'est le travail de l'intégrateur. Mettre à jour PostgreSQL, Kubernetes ou le système, c'est le travail de l'hébergeur. Chacun consulte l'autre avant d'agir, parce qu'une montée de version d'un côté peut avoir des effets de l'autre.

On qualifie avant d'ouvrir un ticket. Quand Odoo ralentit ou renvoie une erreur, l'intégrateur lit les journaux et l'hébergeur regarde ses métriques. Le ticket part vers la bonne équipe, avec toutes les parties en copie. On évite ainsi la panne qui rebondit d'un prestataire à l'autre pendant une matinée.

La production ne se restaure qu'avec l'accord du client. Nous y revenons plus bas.

Un intégrateur sérieux a sa propre chaîne d'intégration continue : il construit une image contenant Odoo et ses modules, la teste, puis la propose au déploiement. La règle que nous appliquons est simple : l'image testée par la CI de l'intégrateur est celle qui part en production. L'hébergeur ne la reconstruit pas à partir des commits. Reconstruire, c'est livrer autre chose que ce qui a été testé, et ouvrir une porte aux attaques sur la chaîne d'approvisionnement logicielle.

Dans l'offre infogérée, l'organisation type ressemble à ceci :

• Deux dépôts séparés. Le dépôt applicatif appartient à l'intégrateur. Le dépôt d'infrastructure appartient à l'hébergeur et reste en lecture seule pour les développeurs : ils voient comment Odoo est déployé, ils ne peuvent pas le modifier.
• Des déclencheurs de pipeline relient les deux. Quand l'intégrateur publie une image validée, le pipeline d'infrastructure la déploie, d'abord en recette.
• Recette et production cloisonnées dans deux environnements distincts, avec des clés de stockage séparées : la recette peut lire les pièces jointes de la production, elle ne peut pas y écrire.
• Des accès nominatifs et tracés, pour savoir qui a déployé quoi.

Vos développeurs ne touchent pas l'infrastructure, et l'hébergeur ne touche pas votre image. Chacun reste dans son couloir.

Côté données, voici ce que la plateforme Odoo managée de France Nuage fait aujourd'hui, tel que décrit dans le guide Odoo :

• La base PostgreSQL est opérée par CloudNativePG, avec trois réplicas répartis sur des zones différentes et une bascule automatique en cas de panne d'un nœud.
• Une sauvegarde complète quotidienne, plus un archivage continu du journal des transactions (WAL), qui permet une restauration à un instant précis (PITR).
• Une rétention de 30 jours pour la base de données.
• Une copie des sauvegardes sur un stockage objet situé sur un autre site que la production, et un test de restauration automatisé chaque jour : une sauvegarde n'est considérée comme valide que si elle se restaure.

Copier la production vers la recette. L'intégrateur a souvent besoin d'une copie récente de la production pour rejouer des imports et des flux. Le piège, c'est une recette qui envoie de vrais e-mails aux clients ou déclenche des tâches planifiées. Dans l'offre infogérée, la copie passe par des scripts de nettoyage exécutés avant le redémarrage de la recette : serveurs de messagerie sortante désactivés, tâches planifiées suspendues, et ce que l'intégrateur juge utile d'anonymiser.

Restaurer la production : uniquement sur feu vert du client. Restaurer la mauvaise sauvegarde, c'est prolonger la panne et parfois perdre des écritures valides. L'intégrateur aide à choisir le point de restauration, l'hébergeur exécute, mais c'est le client qui donne son accord explicite. Personne ne restaure la production de sa propre initiative.

Une mise en production d'Odoo provoque une brève interruption, le temps que la nouvelle version démarre. Les opérations plus lourdes (montée de version, migration de données) se planifient le soir ou le week-end, sur des créneaux convenus à l'avance entre les trois parties.

Odoo sait afficher un message à ses utilisateurs : on s'en sert pour prévenir avant chaque intervention. C'est simple, et cela évite la plupart des appels au support le lendemain matin.

Un ERP contient tout : clients, factures, salaires, contrats. Chez France Nuage, l'instance Odoo et sa base tournent sur des serveurs situés en France, opérés par une société française. Les briques de la plateforme ne dépendent d'aucun sous-traitant soumis au droit américain : PostgreSQL opéré par CloudNativePG sur notre propre cluster, sauvegardes sur notre stockage objet, relais d'e-mail sortant chez un opérateur allemand. Pas de CLOUD Act, pas d'accès par des autorités étrangères.

Et parce qu'Odoo Community est sous licence LGPLv3, rien n'est verrouillé : un export PostgreSQL et vos modules suffisent pour reprendre l'ERP sur vos propres serveurs.

Le plan Odoo managé de base se déploie en quelques minutes depuis la console. Le modèle décrit ici, avec intégrateur, CI, recette cloisonnée et actions ciblées, relève de l'offre infogérée : il se cadre au cas par cas, sur devis.

Vous êtes intégrateur et vous préparez la proposition d'hébergement d'un client ? Ou vous êtes le client et vous voulez que votre intégrateur et votre hébergeur parlent la même langue ? Parlons-en, avec votre intégrateur autour de la table. Vous pouvez aussi consulter la page Odoo managé et notre programme partenaires.