Un commercial sort d'un rendez-vous client, monte dans le TER de fin d'après-midi et ouvre Odoo pour noter l'issue de la rencontre. Le train passe sous un tunnel, le réseau tombe, la page se fige. Depuis des années, la seule réponse du produit était un message d'erreur et une note qu'on ressaisissait le soir. Odoo 20 apporte un mode hors ligne, et l'éditeur le range dans les nouveautés de la plateforme, pas dans une application particulière. Ce changement mérite qu'on s'y arrête, parce qu'il est plus limité que son nom ne le laisse croire, et plus sensible que ce que les notes de version laissent deviner.
Cet article s'appuie sur les notes de version d'Odoo 20 et sur la page de documentation 20.0 du mode hors ligne. Je distingue ce que l'éditeur affirme de ce que je déduis, et je dis ce qui reste à vérifier chez vous. Pour le panorama général de la version, l'article sur ce qui est confirmé par rapport aux annonces reste la référence.
Ce que la documentation promet, et ce qu'elle refuse de promettre
La première phrase de la documentation est un avertissement : le mode hors ligne répond à des coupures de courte durée, il n'est pas conçu pour offrir un fonctionnement complet ni prolongé sans connexion. Je prends cette phrase au mot, parce qu'elle fixe le cadre mieux que n'importe quel argumentaire.
Voici ce que Odoo décrit. Dès que la connexion tombe, un bouton « Working offline » apparaît dans l'en-tête de la base. Les vues et les fiches ouvertes auparavant en ligne peuvent être rouvertes, même si elles n'étaient plus affichées au moment de la coupure. Les recherches déjà exécutées peuvent être relancées. On peut modifier, supprimer, archiver et désarchiver des fiches, et en créer, sous conditions. Ce qui n'est pas disponible hors ligne apparaît grisé. Les modifications attendent dans une file locale et partent vers la base quand le réseau revient.
Les conditions pèsent lourd. Une fiche ne se modifie hors ligne que si elle a été ouverte en ligne auparavant. Une création n'est possible que si une fiche du même type a déjà été créée en ligne. Les pièces jointes et les images se consultent, mais ne se téléversent ni ne se suppriment. Le stockage local est plafonné à 2 Go : au-delà, les données les plus anciennes sont écartées. Enfin, un rechargement forcé du navigateur (Ctrl + F5, ou Cmd + Maj + R) efface tout ce qui a été stocké localement, et avec lui la disponibilité hors ligne.
La documentation ajoute que le mode fonctionne pour les applications et modules construits avec les composants standards du framework. Un développement spécifique qui sort de ce cadre n'a donc aucune garantie.
Mon avis : un filet de sécurité pour le déplacement, pas un outil d'atelier
Mon jugement est net : c'est une bonne fonction pour le commercial, le technicien ou le dirigeant qui passe quelques minutes sans réseau, et une mauvaise idée pour quiconque en ferait la base d'un processus. L'éditeur le dit lui-même, et il a raison de le dire.
Pour le CRM, le cas d'usage est évident : compte rendu après un rendez-vous, changement d'étape d'une opportunité, correction d'un montant attendu. La documentation prend d'ailleurs cet exemple, avec un changement de commercial et de revenu attendu sur une opportunité. Les files d'attente de ce type sont courtes, les conflits rares, et le risque est faible.
Pour un entrepôt, la question est tout autre. Un magasinier qui valide des réceptions dans une zone mal couverte ne veut pas d'une file locale qui se vide plus tard, il veut un stock juste tout de suite. Rien dans la documentation n'indique que les opérations de stock soient conçues pour ce mode, et je ne les y mettrais pas sans essai. Même prudence pour la comptabilité : une écriture saisie hors ligne peut tomber, à la synchronisation, après une date de verrouillage posée entre-temps, et personne ne l'aura vu.
Une zone blanche permanente, un atelier au sous-sol ou un chantier isolé ne se règlent pas avec ce mode. Là, il faut régler le problème de réseau (relais 4G, Wi-Fi d'appoint), ou choisir un outil conçu pour travailler déconnecté pendant des heures.
La question que la documentation ne traite pas : les conflits
Le point que je n'ai pas réussi à éclaircir dans la documentation est le plus important pour une PME qui travaille à plusieurs. Deux personnes modifient la même fiche, l'une hors ligne dans le train, l'autre au bureau. Quand le réseau revient, laquelle l'emporte ? Les écritures sont-elles rejouées dans l'ordre, champ par champ, ou la fiche entière est-elle écrasée ? La page décrit la file d'attente, l'étiquette « Created », « Edited », « Archived » ou « Unarchived » et le détail des changements au survol, ainsi que la possibilité d'abandonner les modifications en attente tant qu'on est encore hors ligne. Elle ne dit rien de la résolution des conflits.
Ce silence ne prouve pas que le comportement est mauvais. Il veut dire qu'il faut le tester avant de promettre quoi que ce soit aux équipes. Le test est simple et prend vingt minutes sur une base d'essai : ouvrir une même opportunité sur deux postes, couper le réseau sur l'un, modifier le même champ sur les deux, rétablir la connexion, et regarder ce qui reste. Refaites-le avec deux champs différents. Le résultat décidera si vous pouvez ouvrir la fonction à toute l'équipe commerciale ou seulement à quelques personnes.
Ce que le DSI et le DAF doivent regarder avant d'activer quoi que ce soit
Le mode hors ligne place sur l'appareil des données de la base : fiches ouvertes, résultats de recherche, vues. La documentation parle de données stockées localement et d'une enveloppe de 2 Go. C'est une déduction de ma part, mais elle s'impose : un ordinateur ou un téléphone perdu, volé ou partagé peut contenir des fiches clients que personne n'a eu l'intention d'y laisser.
Trois questions concrètes à poser avant le déploiement, et auxquelles je ne peux pas répondre à votre place :
- Les données locales sont-elles effacées à la déconnexion de l'utilisateur ? La documentation ne le précise pas, à vérifier sur une base de test avec deux comptes successifs sur le même navigateur.
- Les droits d'accès sont-ils appliqués de la même façon hors ligne ? Odoo 20 a justement simplifié les droits en supprimant les règles d'enregistrement au profit d'un domaine défini sur le droit d'accès lui-même. Je ne sais pas si le cache local respecte à la lettre ce nouveau mécanisme, et je recommande de le vérifier avant de l'ouvrir à des profils restreints.
- Vos politiques d'appareils (chiffrement des disques, verrouillage, effacement à distance) couvrent-elles les postes qui vont désormais conserver une partie de la base ? Si votre société a des obligations en matière de protection des données personnelles, cette question relève du RGPD autant que de l'informatique.
Dans le même registre, le rechargement forcé qui efface le cache est un piège d'exploitation. Le conseil habituel du support (« faites un Ctrl + F5 ») risque de vider le cache local : la documentation dit que le rechargement supprime les données stockées localement, sans préciser ce qu'il advient des modifications encore en attente. Mieux vaut demander à vos utilisateurs de ne jamais l'utiliser tant que le bouton « Working offline » est affiché.
Une vue peut être exclue du cache
Un détail rassurera les responsables de reporting. Pour une vue où afficher une information périmée serait trompeur, comme un tableau de bord de trésorerie, la documentation indique comment désactiver la mise en cache de cette vue seule. Il faut ouvrir la vue en mode développeur, cliquer sur l'icône d'insecte dans l'en-tête de la base, choisir « Action », puis désactiver « Data caching ». La vue n'est alors plus disponible hors ligne. C'est une bonne option de sécurité, mais elle se règle vue par vue : sur une base riche en rapports, cela représente un vrai chantier, et rien dans les notes ne parle d'un réglage global.
Que faire concrètement
Si vous êtes sur Odoo 19 et que vous attendez de migrer, ne basez pas la décision sur cette fonction : elle ne justifie pas, seule, de précipiter une montée de version, et le test d'une base migrée doit d'abord porter sur la comptabilité et les droits d'accès. Si vous êtes déjà en Odoo 20, avancez par un pilote : choisissez deux commerciaux itinérants, faites le test de conflit décrit plus haut, et ne généralisez qu'après avoir vu ce qui se passe réellement lors de la synchronisation.
Une réserve sur l'édition : les notes de version et la documentation que j'ai lues ne rattachent pas le mode hors ligne à une application payante particulière, et je n'ai pas vu de restriction à l'Enterprise. Je ne l'affirme pas pour autant sur les deux éditions sans l'avoir essayé.
Pour voir les gestes de la version 20 écran par écran, le livre d'Emmanuel Chaumery, Odoo 20 au quotidien, consacre son chapitre 7 aux nouveautés de la V20. Il est disponible en version brochée sur Amazon et en ebook chez Cultura.
Sources
- Odoo, notes de version d'Odoo 20 (septembre 2026), rubrique Offline mode, Simplified access rights et Connect Odoo to anything : Lire la page
- Odoo, documentation 20.0, Offline mode (consultée le 21/10/2026) : Lire la documentation