La documentation Odoo 19 présente un mode hors ligne destiné aux utilisateurs déjà connectés lorsque la couverture devient instable ou disparaît. Les vues et enregistrements ouverts auparavant en ligne peuvent être rouverts. C’est utile dans un train, un entrepôt mal couvert ou sur un site client, mais ce n’est pas un ERP complet fonctionnant sans réseau.
La limite essentielle est simple : les données préparées restent consultables, mais ne peuvent pas être modifiées hors ligne. Il n’y a donc ni saisie différée généralisée, ni file d’attente standard rejouant toutes les opérations au retour de la connexion. Une entreprise doit traiter cette fonction comme une capacité de consultation dégradée, pas comme son plan de continuité à elle seule.
Ce qu’Odoo 19 met réellement à disposition
Odoo conserve localement les vues et fiches qu’un utilisateur connecté a déjà ouvertes. Pour anticiper une perte de réseau, la documentation conseille d’ouvrir brièvement les éléments nécessaires pendant que la connexion est disponible. Le périmètre dépend donc de l’activité récente et de la préparation de chaque utilisateur ; il ne s’agit pas d’une réplication automatique de la base.
Odoo plafonne les données hors ligne à 2 Go pour des raisons de performance. Quand cette limite est atteinte, les données les plus anciennes sont retirées au profit des plus récentes. Ce plafond est une enveloppe technique, pas la garantie qu’une liste métier précise restera toujours présente.
Un rechargement forcé du navigateur avec Ctrl + F5 ou Cmd + Shift + R supprime les données stockées localement. Un geste courant de dépannage peut donc faire disparaître la consultation hors ligne juste avant un déplacement. Cette conséquence doit figurer dans les consignes du support.
Lecture seule : usages utiles et faux espoirs
Le mode peut aider un commercial à relire une fiche client déjà consultée, un chef de projet à retrouver un dossier préparé ou un technicien à consulter les informations préchargées d’une intervention. En revanche, la source officielle ne promet pas la création hors ligne d’un devis, la validation d’un bon, l’enregistrement d’un temps ou la clôture d’une intervention.
Il faut distinguer une microcoupure, une zone à faible couverture et une indisponibilité prolongée. Dans les deux premiers cas, la consultation locale réduit la friction. Dans le troisième, les dépendances à l’authentification, aux pièces jointes, aux intégrations, aux paiements, à l’impression et aux traitements serveur imposent un véritable plan de reprise.
Modules personnalisés : tester sans extrapoler
Odoo indique que l’accès hors ligne est pris en charge pour les applications et modules construits avec les composants standard de son framework. Cette formulation appelle un test explicite des développements spécifiques : vues personnalisées, widgets JavaScript, appels à des contrôleurs, contenus chargés à la demande et intégrations externes peuvent se comporter différemment.
Une migration vers Odoo 19 ne devrait donc pas déclarer le sujet validé après le seul test d’une fiche standard. La matrice de recette doit associer chaque profil terrain aux vues, champs, pièces jointes et personnalisations dont il a besoin. Les écarts relèvent parfois de la configuration, parfois d’une adaptation, et parfois d’une procédure métier de secours.
Belgique et France : sécuriser les usages terrain
Équipes de maintenance, commerciaux itinérants, dépôts, chantiers et sites industriels belges ou français rencontrent tous des zones de couverture inégale. La bonne unité d’analyse n’est pas le pays mais le parcours opérationnel, l’appareil utilisé et la qualité réelle du réseau.
La conservation locale implique aussi des règles d’équipement. Un poste partagé, un appareil personnel ou un terminal perdu ne présentent pas le même risque. Les entreprises doivent maintenir verrouillage, chiffrement, gestion des appareils, révocation des accès et procédure de départ ; le mode hors ligne ne remplace pas les contrôles de sécurité Odoo.
Analyse Underside : concevoir un service dégradé
Nous recommandons de définir ce que l’utilisateur doit pouvoir consulter, ce qu’il peut reporter sur un support contrôlé et ce qui doit attendre le retour du réseau. Cette séparation évite qu’une promesse vague de « mode offline » se transforme en double saisie, décisions fondées sur des données anciennes ou contournements non tracés.
Le test utile se déroule sur les appareils réels, avec le navigateur retenu. L’utilisateur se connecte, ouvre son jeu de données, coupe totalement le réseau, ferme puis rouvre les vues attendues et vérifie leur lisibilité. Il teste ensuite le retour en ligne, la fraîcheur des informations et les limites liées aux fichiers. Le scénario doit être rejoué après une mise à jour d’Odoo ou d’un module personnalisé.
Protocole de validation
- Identifier les rôles exposés aux coupures et leurs informations indispensables.
- Distinguer consultation, saisie, validation, impression et synchronisation.
- Précharger des vues et fiches représentatives sur chaque type d’appareil.
- Couper réellement Wi-Fi et réseau mobile, puis rouvrir les contenus attendus.
- Tester les modules spécifiques et les données provenant de services externes.
- Vérifier les pièces jointes avec des volumes proches des usages réels.
- Documenter l’impact du rechargement forcé et les gestes autorisés au support.
- Prévoir un canal de secours pour les opérations exigeant une écriture immédiate.
Cette validation complète un audit Odoo, la préparation d’une migration Odoo et l’organisation du support après mise en production. Le standard peut suffire pour une consultation préparée ; un processus complet hors ligne demande une analyse et, si nécessaire, une architecture dédiée.
Source officielle
Underside accompagne les entreprises dans le cadrage, la migration et la sécurisation d’Odoo. Pour les équipes mobiles, l’enjeu est de tester le service réellement disponible en cas de coupure et d’organiser les opérations impossibles hors ligne.