La documentation Odoo 19 décrit une intégration de stockage cloud qui envoie les pièces jointes du chatter et des e-mails vers Google Cloud Storage ou Microsoft Azure, plutôt que vers le serveur de la base. Pour une entreprise belge ou française dont le filestore grossit rapidement, cette possibilité peut réduire les transferts de fichiers et mieux répartir la capacité.
Mais le périmètre est précis. Les documents générés par Odoo, par exemple les devis, ainsi que les fichiers des applications Documents et Sign restent sur le serveur de la base. Le choix ne déplace donc ni tout le filestore ni toute la gestion documentaire : il crée une architecture hybride qu’il faut exploiter comme telle.
Ce que fait réellement le standard Odoo 19
L’administrateur installe le module correspondant au fournisseur, choisit Google Cloud Storage ou Azure et définit une taille minimale. Les nouvelles pièces jointes éligibles dépassant ce seuil sont alors dirigées vers le stockage externe.
Côté Google, Odoo utilise un compte de service, un bucket et une clé JSON. Côté Azure, la configuration s’appuie sur une application, un tenant, un client secret, un compte de stockage et un conteneur. La documentation demande aussi des règles CORS pour les opérations de lecture et d’écriture depuis le navigateur.
Cette configuration doit être comprise comme une règle de placement pour de nouveaux fichiers, pas comme un outil de migration automatique des pièces jointes historiques. Avant toute bascule, l’équipe projet doit donc inventorier les volumes existants et décider séparément si un chantier de migration est nécessaire.
La frontière fonctionnelle à documenter
Un utilisateur ne devrait pas avoir à savoir où réside chaque fichier, mais l’IT, le support et les responsables conformité doivent le savoir. Il faut cartographier au minimum les pièces jointes du chatter, les e-mails entrants et sortants, les PDF générés, Documents, Sign, les exports et les développements qui manipulent directement les pièces jointes.
Cette frontière compte aussi pour la sauvegarde et la restauration. Restaurer uniquement la base et son filestore ne suffit plus à reconstituer l’ensemble si des objets sont stockés chez un fournisseur externe. Le plan de reprise doit synchroniser les points de restauration, conserver les métadonnées qui relient Odoo aux objets et tester l’accès après restauration.
Sécurité : réduire les droits avant d’ouvrir le flux
Odoo recommande pour Azure un rôle personnalisé sans permission de suppression, afin qu’une compromission des identifiants de stockage ne permette pas d’effacer les objets. C’est un bon principe pour les deux fournisseurs : le compte technique doit disposer uniquement des actions nécessaires, sur le bucket ou le conteneur prévu, et non sur un périmètre cloud plus large.
Les clés et secrets ont besoin d’un propriétaire, d’une date d’expiration, d’une procédure de rotation et d’une séparation entre test et production. La documentation Azure conseille une durée de 180 jours ou moins pour le secret client et rappelle qu’Odoo doit être mis à jour avant son expiration. Sans calendrier d’exploitation, le premier rappel risque d’être une panne de téléchargement.
Belgique et France : localisation, contrats et données
Le stockage externe ne change pas automatiquement les droits d’accès Odoo : une pièce jointe reste exposée selon les règles du record et du flux métier qui la portent. L’équipe doit toutefois vérifier la région choisie, les sous-traitants, les engagements contractuels, la rétention, le chiffrement et la procédure de réponse aux demandes liées aux données personnelles.
Pour un groupe actif en Belgique et en France, une politique unique peut définir les classes de documents, tandis que chaque entité précise ses contraintes de conservation et ses responsabilités. L’intégration technique ne constitue pas, à elle seule, un archivage légal ni un système de records management.
Analyse Underside : décider par risque, pas seulement par volume
Nous recommandons de ne pas partir d’un seuil arbitraire en mégaoctets. Commencez par classer les usages : fichiers volumineux mais peu sensibles, échanges commerciaux courants, documents contractuels, données RH, pièces comptables et preuves de signature. Le volume détermine le coût et la performance ; la classe documentaire détermine l’accès, la conservation et la preuve.
Un pilote utile active le stockage externe sur une copie non productive, puis rejoue téléversement, aperçu, téléchargement, e-mail, suppression, restauration et expiration de secret. Il vérifie aussi les développements et connecteurs qui supposent qu’un binaire est présent localement. Une migration Odoo doit intégrer ces tests, car un module personnalisé peut contourner les abstractions standard.
Feuille de route de déploiement
- Mesurer la croissance du filestore et identifier les types de pièces jointes dominants.
- Cartographier ce qui peut être externalisé et ce qui restera dans Odoo.
- Choisir région, politique de rétention et modèle de coûts du fournisseur.
- Créer une identité technique dédiée avec des droits minimaux.
- Séparer buckets ou conteneurs et secrets entre test et production.
- Fixer le seuil sur la base de mesures, puis tester les parcours métier critiques.
- Concevoir et tester une restauration coordonnée d’Odoo et du stockage externe.
- Superviser erreurs, capacité, coûts, expiration des secrets et accès refusés.
Ce chantier complète la gouvernance des documents dans Odoo, la sécurité et les droits d’accès et la préparation d’une migration Odoo. Selon les exigences, le standard peut suffire pour le placement des pièces jointes ; une migration historique, une politique d’archivage ou des contrôles avancés demandent un projet complémentaire.
Source officielle
Underside accompagne les entreprises dans l’architecture, la migration et la sécurisation d’Odoo. Pour le stockage cloud, l’objectif est de valider périmètre, restauration et exploitation avant l’activation en production.