Infogérance Odoo : ce que vous pouvez gérer vous-même

L'infogérance Odoo délègue l'exploitation technique à un prestataire. Vous pouvez aussi garder cette exploitation dans votre équipe, avec un serveur à vous ou une plateforme en libre-service. La condition : savoir qui reçoit les alertes, qui restaure les données et qui valide les changements. Un tableau de bord ouvert dans un onglet ne répond à aucune de ces questions.

Notre recommandation : organisez le travail autour de preuves vérifiables. Une alerte reçue, une pièce jointe retrouvée après restauration, un changement documenté. Ce guide décrit les tâches à couvrir pour une instance avec des modules spécifiques. Les réglages cités se réfèrent à la documentation Odoo 19, Community et Enterprise, consultée le 5 novembre 2026.

Organiser l'infogérance Odoo ou l'exploitation en interne#

Votre équipe garde la responsabilité de décider ce qui doit fonctionner et comment le vérifier. L'exécution peut appartenir à votre administrateur, à votre développeur ou à un prestataire. Écrivez leurs noms, plutôt que « l'informatique ».

Commencez par ce registre. Les fréquences sont des décisions à prendre selon votre activité, pas des engagements fournis par ce guide.

Tâche	Responsable à nommer	Preuve attendue	Fréquence à décider
Surveiller l'instance	Destinataire des alertes et remplaçant	Alerte de test reçue, incident attribué	Contrôles automatiques et plages de réponse
Sauvegarder	Personne qui vérifie les copies	Sauvegarde récente, base et filestore présents	Selon la perte de données acceptable
Restaurer	Opérateur et personne qui recettent	Compte rendu, durée mesurée, document ouvert	Selon les risques et après changement du mécanisme
Mettre à jour	Administrateur et développeur des modules	Test sur une copie, retour arrière préparé	Selon les correctifs et votre fenêtre de changement
Revoir les accès	Administrateur désigné	Comptes et droits vérifiés	Après un départ et à une cadence fixée

Ajoutez la date de la dernière vérification et celle de la prochaine. Qui prend le relais pendant les congés ? Sans remplaçant désigné et sans accès testé par cette personne avant votre départ, le nom dans le tableau ne sert pas à grand-chose lorsque la production s'arrête.

Ce partage varie avec l'hébergement. Une plateforme peut gérer le système sans tester vos modules. Un intégrateur peut maintenir votre code sans recevoir vos alertes disque. Notre comparaison des modes d'hébergement Odoo aide à repérer ces frontières. Si Odoo Online accepte tout ce dont vous avez besoin, vous n'avez pas à administrer un serveur pour le principe.

Surveiller un parcours utilisateur, pas seulement un port#

Un serveur qui répond sur HTTPS peut héberger un Odoo inutilisable. Séparez la disponibilité technique de la vérification d'un usage : connexion avec un compte de test peu privilégié, ouverture d'un écran autorisé, accès à un document prévu pour ce contrôle. Évitez de créer une commande commerciale à chaque sonde.

La documentation de déploiement d'Odoo 19 (nouvel onglet) recommande la surveillance des ressources et décrit les journaux de connexion. Elle ne choisit ni vos seuils ni votre organisation d'astreinte. À vous de relier chaque signal à une action.

Signal	Première vérification	Trace à garder
Le site ne répond plus	DNS, certificat, reverse proxy, processus Odoo	Heure et résultat du contrôle extérieur
L'écran charge lentement	Charge CPU, mémoire, connexions et verrous PostgreSQL	Mesures et logs sur le même créneau
Une tâche attend	Dernière exécution du cron, erreur Python, service externe	Tâche concernée et dernier succès connu
Le disque se remplit	Base, filestore, logs, sauvegardes locales	Évolution de l'espace disponible

Testez aussi le trajet de l'alerte. Faites échouer une sonde dédiée, sans couper la production, puis vérifiez qu'un humain la reçoit, sait où commencer et dispose des accès nécessaires pour consulter les logs de l'instance concernée. La boîte partagée ne répondra pas seule.

Fixez vos seuils après avoir observé un fonctionnement normal, notamment pendant les imports et traitements planifiés. Ajouter des workers au premier ralentissement risque de masquer un verrou ou une requête coûteuse. Conservez le contexte avant de changer le dimensionnement.

Sauvegarder la base et les fichiers avec le même objectif#

Une sauvegarde d'Odoo doit permettre de retrouver la base PostgreSQL et les fichiers du filestore qui lui correspondent. Les pièces jointes stockées sur disque ne réapparaissent pas avec un simple dump SQL. La même documentation recommande des sauvegardes quotidiennes de la base et du filestore, copiées vers un serveur d'archivage distant inaccessible depuis le serveur de production.

Le quotidien est un point de départ documentaire. Votre activité peut exiger une autre cadence. Demandez aux utilisateurs jusqu'à quel moment ils accepteraient de ressaisir les opérations perdues : c'est votre objectif de perte de données, le RPO. Choisissez ensuite une méthode qui peut le tenir, puis vérifiez-le sur les copies réellement disponibles.

Conservez avec chaque sauvegarde l'heure de référence, la version d'Odoo et la révision de vos modules. Notez aussi où retrouver la configuration et les dépendances nécessaires au redémarrage. Une base restaurée avec un autre code peut échouer avant même l'écran de connexion.

Vérifiez que les identifiants nécessaires à la restauration restent accessibles si la production tombe. Un coffre dont l'accès dépend du serveur en panne crée une boucle assez désagréable. Gardez les secrets dans le dispositif prévu par votre équipe, jamais dans le registre de suivi ou les captures du rapport.

Une tâche de sauvegarde verte prouve que le programme s'est terminé. Contrôlez également la présence des fichiers, leur date, leur taille et le résultat du transfert hors du serveur. Une variation inhabituelle mérite une vérification, pas une suppression automatique des anciennes copies.

Restaurer dans un environnement isolé et conserver le résultat#

Le test utile va jusqu'à un usage vérifié. Démarrer Odoo sur la base restaurée est une étape ; ouvrir une pièce jointe et retrouver un enregistrement choisi avant la sauvegarde en est une autre. C'est là que vous vérifiez le couple base et filestore.

Préparez ce déroulé avec la personne qui utilise l'application :

1. Choisissez une sauvegarde et relevez son heure de référence. Retrouvez la version du code correspondante avant de commencer.
2. Préparez un environnement séparé. Bloquez les sorties vers les services réels avant de démarrer Odoo, y compris les connecteurs développés chez vous.
3. Restaurez la base et le filestore avec la méthode de votre hébergement. Ne remplacez jamais la production pour vérifier une sauvegarde.
4. Faites démarrer l'application, contrôlez les logs, puis ouvrez le document témoin et un parcours représentatif avec un utilisateur autorisé.
5. Notez l'heure de départ, l'heure où le service devient utilisable, les erreurs rencontrées et la personne qui valide. Corrigez la procédure, puis rejouez la partie en échec.

La documentation des bases neutralisées (nouvel onglet) décrit notamment la désactivation des actions planifiées, des e-mails sortants et de plusieurs intégrations. Elle donne une liste non exhaustive. Ne supposez pas qu'une restauration quelconque neutralise automatiquement vos connecteurs spécifiques. Vérifiez le mécanisme de copie utilisé et gardez le blocage réseau tant que vous n'avez pas contrôlé les sorties.

Une base neutralisée contient toujours vos données : la neutralisation n'est pas une anonymisation. Limitez les accès à la copie et prévoyez sa suppression après le test. Pour réactiver un cron à des fins de recette, utilisez un service factice ou une destination de test explicitement configurée.

Notre tutoriel Odoo avec Docker montre une restauration dans un projet Compose distinct. Ce test ne prouve pas, à lui seul, que vous saurez récupérer après la perte de l'hôte. Pour ce scénario, prévoyez aussi un exercice depuis une autre machine et vos copies distantes.

Tester un correctif avant de toucher à la production#

Une mise à jour d'exploitation doit conserver un chemin de retour. Distinguez le correctif de votre version d'Odoo, les mises à jour du système ou de PostgreSQL, et la migration vers une autre version d'Odoo. Leur périmètre de test n'est pas interchangeable.

Pour un correctif, partez d'une copie récente et isolée. Appliquez le changement avec le code prévu, puis testez les écrans touchés et vos modules spécifiques. Une connexion réussie ne valide pas un import, un calcul planifié ou la génération d'un document. Choisissez les parcours avec l'équipe métier, sans recopier toute la recette fonctionnelle à chaque intervention.

Avant la fenêtre de production, écrivez ce qui déclenche l'abandon : échec du démarrage, erreur sur un parcours retenu, durée incompatible avec la fenêtre. Précisez aussi qui peut prendre cette décision. Attendre qu'un collègue réponde dans une messagerie rallonge une interruption pourtant évitable.

Le retour arrière doit couvrir le code et les données. Si le changement a modifié le schéma ou le contenu de la base, remettre l'ancien code ne suffit pas forcément : préparez la restauration cohérente et décidez comment traiter les écritures effectuées après le changement. Vous risquez de perdre ces écritures. Le métier doit accepter cette perte éventuelle.

Gardez dans le journal d'exploitation la révision déployée, les tests réalisés et le résultat. Évitez les mentions « mis à jour » sans référence : lors du prochain incident, personne ne saura ce qui a réellement changé.

Vérifier les accès et décider qui intervient hors horaires#

L'accès aux outils de secours doit fonctionner avant l'incident. Faites vérifier les droits par chaque opérateur désigné, avec son compte personnel, puis retirez les accès devenus inutiles. N'utilisez pas le compte administrateur partagé comme raccourci d'organisation.

Sur une installation Odoo 19 exposée à Internet, la documentation recommande de désactiver le gestionnaire de bases. Elle décrit list_db = False et le filtrage des bases avec dbfilter. Le réglage proxy_mode s'active seulement derrière un reverse proxy. Testez les accès depuis l'extérieur après modification, plutôt que de considérer le fichier de configuration comme une preuve suffisante.

Notre liste de contrôle de sécurité Odoo détaille ces vérifications. Si votre plateforme contrôle le reverse proxy ou PostgreSQL, identifiez ce qu'elle vous permet de régler et ce qu'elle prend en charge. Inutile d'écrire une procédure nécessitant un accès root que votre offre ne fournit pas.

Décidez enfin ce qui se passe hors horaires. Sans personne disponible, votre équipe ne doit pas promettre une remise en service nocturne. Vous pouvez accepter cette limite, organiser une rotation ou déléguer une tâche précise. L'infogérance Odoo devient alors un choix de capacité, avec un périmètre explicite, plutôt qu'un mot censé tout couvrir.

Si vous déléguez, comparez les engagements écrits aux preuves que vous demandez. Le SLA du cloud Odoo (nouvel onglet) distingue les objectifs de disponibilité et de reprise de garanties juridiquement contraignantes. Ses objectifs concernent son propre service ; ils ne se transfèrent ni à votre serveur ni à Ofleet. Votre RTO reste l'objectif de durée de reprise que vous avez décidé, pas le résultat d'un seul exercice favorable.

Préparer votre prochain exercice d'exploitation#

Prenez une tâche du registre qui n'a encore aucune preuve. Nommez son responsable, fixez une date et préparez l'accès nécessaire. Pour une sauvegarde, la prochaine action peut simplement être de retrouver la copie hors serveur et la révision du code associée. Ce premier contrôle révèle déjà les dépendances manquantes.

Sur Ofleet, vous pilotez vous-même vos instances Tests et Production, avec le clonage, les logs et le shell disponibles dans la plateforme. Vous pouvez essayer Ofleet sur votre projet pour examiner ces outils. Gardez votre registre à côté : une console ne choisit ni vos tests métier ni la personne qui répondra à l'alerte.