Odoo : qui fait quoi entre l'entreprise, l'intégrateur et l'hébergeur
Par François-Guillaume Ribreau, cofondateur de NoBullshit Conseil. Publié le 19 octobre 2026.
En bref
Autour d'un Odoo hébergé sur un serveur dédié, trois acteurs se partagent le travail. L'entreprise décide et possède ses données, l'intégrateur fait évoluer l'application et l'hébergeur exploite le serveur. Ce partage s'écrit avant la mise en service, tâche par tâche, avec un nom en face de chaque décision.
Pourquoi écrire le partage des rôles avant la mise en service ?
Un partage des rôles écrit évite qu'un incident se transforme en échange de tickets entre deux prestataires qui pensent chacun que le problème vient de l'autre.
Dans un projet Odoo, la crainte la plus fréquente porte sur la zone grise entre celui qui paramètre l'ERP et celui qui fait tourner le serveur. Un contrat d'intégration et un contrat d'hébergement signés séparément laissent souvent cette zone sans propriétaire.
Le jour où le disque se remplit ou une mise à jour bloque une facturation, chacun lit son propre contrat. Le tableau ci-dessous sert à combler cette zone avant d'en avoir besoin.
Le tableau des responsabilités
Ce tableau donne un partage de départ pour un Odoo installé sur un serveur dédié, à adapter puis à annexer à vos contrats.
Il se lit ligne par ligne. Quatre verbes suffisent : décide, réalise, vérifie et informé. Une case « aucun rôle » veut dire que l'acteur n'intervient pas sur cette tâche.
| Tâche | Entreprise | Intégrateur | Hébergeur |
|---|---|---|---|
| Paramétrage métier et droits des utilisateurs | Décide et valide | Réalise | Aucun rôle |
| Qualité des données (fiches clients, articles) | Réalise | Conseille et contrôle | Aucun rôle |
| Modules spécifiques et correctifs d'Odoo | Valide la mise en production | Réalise et teste | Déploie la version validée |
| Montée de version d'Odoo | Donne le go | Migre, teste et valide | Fournit l'environnement de test |
| Système, PostgreSQL et leurs correctifs | Informée | Consulté avant chaque changement | Réalise |
| Réseau, DNS et certificats | Reste titulaire du nom de domaine | Aucun rôle | Réalise |
| Stockage et capacité du serveur | Informée | Signale les besoins à venir | Réalise |
| Sauvegardes | Fixe la durée de conservation | Aucun rôle | Réalise |
| Tests de restauration | Reçoit le compte rendu | Vérifie l'application restaurée | Réalise |
| Supervision | Informée des alertes qui la concernent | Informé des alertes applicatives | Réalise |
| Incident applicatif | Signale | Traite | Fournit les journaux |
| Incident d'infrastructure | Signale | Informé | Traite |
| Restauration de la production | Décide | Vérifie l'application après coup | Exécute |
| Copie de recette depuis la production | Autorise | Teste sur la copie | Crée et neutralise la copie |
Qui appeler quand Odoo est en panne ?
Quand Odoo tombe, l'entreprise appelle un seul point d'entrée, et ce point d'entrée commence par qualifier l'incident.
Une erreur affichée à un seul utilisateur, sur un écran précis, relève presque toujours de l'application. Un site inaccessible pour tout le monde, des lenteurs générales ou un disque plein relèvent du serveur.
Une fois l'incident qualifié, le ticket va à celui qui le porte, avec l'entreprise et l'autre prestataire en copie. Le contrat peut prévoir que l'hébergeur transmette les journaux à l'intégrateur dès l'ouverture du ticket.
Qui décide de restaurer une sauvegarde ?
La restauration d'une base de production est une décision de l'entreprise, que l'hébergeur exécute et que l'intégrateur contrôle ensuite.
Restaurer revient à effacer tout ce qui a été saisi depuis la sauvegarde choisie : commandes, factures, mouvements de stock. Restaurer la mauvaise sauvegarde prolonge la panne.
C'est aussi pour cela qu'une sauvegarde se teste avant d'en avoir besoin. Tant qu'on ne l'a jamais restaurée sur un serveur de test, on ignore si elle est complète, combien de temps elle prend à remettre en service et si les pièces jointes suivent.
L'intégrateur doit-il avoir un accès au serveur ?
L'intégrateur a besoin de quelques gestes précis sur le serveur, et ces gestes peuvent lui être ouverts sans lui confier tout le système.
Lire les journaux, redémarrer l'application, lancer ou récupérer une sauvegarde : ce sont les actions dont il se sert chaque semaine. Limiter les accès de l'intégrateur aux gestes dont il a besoin réduit le risque d'erreur sur le système.
Les accès restent nominatifs et tracés, pour savoir qui a fait quoi. La production et la recette tournent sur des environnements séparés.
Comment tester sur une copie de vos vraies données ?
On teste une évolution ou une migration sur une copie de la production, préparée pour ne rien envoyer à l'extérieur et isolée de la production.
Une copie brute d'une base Odoo garde ses tâches planifiées, ses serveurs d'e-mails sortants et ses connecteurs. Sans précaution, elle peut relancer des clients ou envoyer des commandes à de vrais fournisseurs.
Odoo sait neutraliser une base copiée, en désactivant notamment ses tâches planifiées et ses serveurs d'e-mails sortants (documentation officielle Odoo, page « Neutralized database »). Les connecteurs spécifiques se vérifient un par un.
La copie contient les données personnelles de la production. Quand le test le permet, on anonymise ou on pseudonymise ces données avant de les copier.
Dans tous les cas, la copie reçoit les mêmes protections que la production, son accès est limité aux personnes qui testent, et elle est supprimée à la fin du test.
Notre page migration Odoo présente notre démarche de migration.
Montée de version : deux calendriers à tenir
Une montée de version d'Odoo et une montée de version de l'infrastructure sont deux chantiers distincts, avec deux responsables.
La version d'Odoo relève de l'intégrateur : migration des données et des modules, tests, validation. La version du système et de PostgreSQL relève de l'hébergeur. Chacun consulte l'autre avant de changer quoi que ce soit, et l'entreprise donne le go final.
La réforme de la facturation électronique est un bon exemple. Elle pousse beaucoup de PME à monter de version, comme nous l'expliquons dans notre article sur Odoo et la facturation électronique.
Comment l'écrire dans vos contrats ?
Le plus simple est d'annexer le même tableau aux deux contrats, celui de l'intégrateur et celui de l'hébergeur, pour que les deux prestataires signent la même répartition.
- Le point d'entrée unique en cas d'incident, avec ses horaires.
- La liste nominative des personnes qui ont un accès administrateur.
- Le lieu de stockage des sauvegardes et leur durée de conservation.
- La fréquence des tests de restauration et le destinataire du compte rendu.
- Ce que l'entreprise récupère si elle change de prestataire, et dans quel délai : base, pièces jointes, code des modules spécifiques et droits d'utilisation associés.
Pour l'exploitation du serveur, notre page hébergement et infogérance Odoo détaille ce que nous prenons en charge. Pour le paramétrage et les évolutions, voyez notre page intégrateur Odoo en Vendée.
Vous voulez savoir qui porte quoi autour de votre Odoo aujourd'hui ?
Faire le point sur votre exploitation Odoo