L'adoption d'un ERP ne se joue pas sur ses fonctions mais sur ses gestes quotidiens : combien de clics pour modifier dix lignes, est-ce utilisable depuis un téléphone sur un chantier, la fenêtre modale est-elle assez grande pour lire.
Quatre modules du socle traitent exactement cela. Aucun n'ajoute de fonction métier ; ensemble, ils expliquent une bonne part de la différence entre « on a Odoo » et « on utilise Odoo ».
Résumé
Aucun de ces cinq modules n'ajoute de fonction métier, et ils expliquent pourtant une bonne part de la différence entre « on a Odoo » et « on utilise Odoo » : une interface utilisable sur téléphone, l'édition de plusieurs champs en masse, des fenêtres modales lisibles.
Deux points structurants : web_responsive exclut web_enterprise — à savoir si une bascule vers l'édition payante est envisagée — et une action d'édition en masse mal restreinte modifie des centaines d'enregistrements en un clic, sans confirmation détaillée.
L'essentiel
web_responsive: menu des applications en grille avec recherche, en-têtes de liste collants, boutons compacts sur petit écran. Incompatible avecweb_enterprise.server_action_mass_edit: modifier plusieurs champs à la fois sur une sélection, là où Odoo n'en permet qu'un — 43 champs ajoutés.web_dialog_size: agrandir une fenêtre modale en plein écran, et la restaurer.web_notify: infrastructure de notifications instantanées depuis le serveur, pour les développeurs de modules.base_technical_features: l'accès permanent au mode développeur, par une case dans les préférences utilisateur.
web_responsive : l'absence d'application mobile, compensée
C'est l'un des manques réels de l'édition Community : pas d'application mobile native. web_responsive ne la remplace pas — il rend le client web utilisable sur petit écran, ce qui suffit à la plupart des usages nomades.
| Ce qu'il change | Effet concret |
|---|---|
| Menu des applications en grille plein écran avec recherche intégrée | On trouve une application en tapant son nom, au lieu de parcourir un menu |
| En-têtes et pieds de liste collants | Sur une liste longue, on sait encore quelle colonne on lit |
| Barre de statut de formulaire collante | Le bouton de validation reste atteignable sans remonter |
| Boutons compacts en icône sur petit écran | L'écran reste utilisable sur un téléphone |
| Raccourcis clavier revus | Saisie plus rapide au clavier |
| Améliorations du chatter | Messages et notes plus lisibles |
Le point d'incompatibilité à connaître avant toute chose : le module exclut explicitement web_enterprise. Les deux ne peuvent pas cohabiter. Ce n'est pas un problème sur une instance Community — c'en est un si vous envisagez un jour une bascule vers l'édition payante.
Les usages où il fait la différence, d'après ce que nos clients en font : la saisie des temps depuis un chantier, la photo d'un justificatif de frais, la consultation d'une fiche client en rendez-vous, la validation d'une demande depuis un téléphone.
Voir faire adopter Odoo par ses équipes.
server_action_mass_edit : plusieurs champs à la fois
Odoo permet nativement d'éditer un champ en masse depuis une vue liste. Un seul. Pour en modifier trois sur deux cents enregistrements, il faut répéter l'opération trois fois — ou le faire à la main.
Ce module ajoute un type d'action serveur, Mass Edit Records, configurable par un administrateur sur n'importe quel modèle. Une fois configurée, l'action apparaît dans le menu Action d'une vue liste pour les utilisateurs autorisés.
- Créer l'action : choisir le modèle, puis les champs concernés.
- Définir pour chaque champ l'opération proposée — Définir, Retirer ou Ajouter, selon le type de champ.
- Restreindre l'action par groupes de sécurité, et éventuellement par domaine.
- L'utilisateur sélectionne des enregistrements dans une vue liste, ouvre le menu Action, lance l'assistant et applique les modifications.


L'opération Ajouter / Retirer sur les champs à valeurs multiples est ce qui le rend vraiment utile : ajouter une étiquette à trois cents contacts sans écraser celles qu'ils portent déjà.
Limite répertoriée : les champs utilisés dans des domaines liés ne sont pas ajoutés automatiquement à l'action lorsqu'un domaine est appliqué. En pratique, cela signifie de déclarer explicitement tous les champs dont l'action a besoin.
Un avertissement d'usage : une action d'édition en masse mal restreinte permet de modifier deux cents enregistrements en un clic, sans confirmation détaillée. Restreignez-la par groupe, et n'y mettez que les champs qui doivent réellement être modifiables en lot.
Les deux modules discrets : web_dialog_size et web_notify
| Module | Ce qu'il fait | Pour qui |
|---|---|---|
web_dialog_size | Un bouton d'agrandissement dans l'en-tête des fenêtres modales : bascule entre taille d'origine et pleine largeur | Tous les utilisateurs |
web_notify | Infrastructure de notifications instantanées envoyées par le serveur via le bus temps réel | Les développeurs de modules |
web_dialog_size est le plus petit module du socle — zéro champ, zéro vue, zéro menu — et l'un des plus appréciés au quotidien. Les formulaires complexes affichés en fenêtre modale deviennent lisibles. Sa limite répertoriée est modeste : on ne peut pas définir une taille par défaut par utilisateur.
web_notify n'a aucun écran : c'est une brique pour les développeurs, qui permet d'avertir un utilisateur connecté — succès, erreur, avertissement, information — sans recharger la page. Il figure au socle parce que plusieurs modules métier en dépendent, pas pour un usage direct.
base_technical_features : le mode développeur, sans l'activer chaque fois
Certains champs et menus d'Odoo sont marqués comme réservés au mode développeur. Les atteindre suppose d'activer ce mode à chaque session — et un mode développeur activé en permanence sur un compte courant est une mauvaise idée.
Ce module permet d'accorder cet accès de façon permanente à un utilisateur précis, par une case à cocher dans ses préférences. Il crée un groupe de droits dédié.
- À qui l'accorder : la personne qui administre l'instance, et celle qui a besoin d'un bouton réservé au mode développeur dans son travail quotidien — par exemple le bouton de facturation immédiate d'un contrat.
- À qui ne pas l'accorder : tout le monde. Le mode développeur expose des écrans techniques où une modification faite sans comprendre casse des choses difficiles à diagnostiquer.
C'est la bonne réponse à un cas que nous rencontrons souvent : une personne qui facture les contrats chaque mois et à qui l'on a appris à « activer le mode développeur » — elle le laisse activé en permanence. Voir les contrats récurrents et les droits utilisateurs.
Ce que ces modules ajoutent à l'instance
| Module | Modèles étendus | Champs | Version | Licence |
|---|---|---|---|---|
web_responsive | 2 | 3 | 18.0.1.0.8 | LGPL-3 |
server_action_mass_edit | 4 | 43 | 18.0.1.1.4 | AGPL-3 |
web_dialog_size | 1 | 0 | 18.0.1.0.3 | AGPL-3 |
web_notify | 1 | 5 | 18.0.1.1.2 | LGPL-3 |
base_technical_features | 3 | 6 | 18.0.1.0.2 | AGPL-3 |
Aucun ne crée de modèle, et c'est la signature de cette famille : ce sont des modules d'interface et d'ergonomie. Ils se retirent sans laisser de données derrière eux — ce qui en fait les plus sûrs du socle à installer en production.
Limites connues
web_responsiveexclutweb_enterprise. Les deux ne peuvent pas cohabiter : c'est une décision structurante si une bascule vers l'édition payante est envisagée.web_responsive: deux souhaits répertoriés — la navigation entre applications au clavier, et une meilleure gestion des titres longs sur les formulaires.web_dialog_size: pas de taille par défaut configurable par utilisateur.server_action_mass_edit: les champs utilisés dans des domaines liés ne sont pas ajoutés automatiquement à l'action.web_notifyn'a aucun usage direct : c'est une brique pour développeurs, inutile seule.
Une limite d'usage, la plus importante de cette fiche : web_responsive rend l'interface utilisable sur mobile, il ne crée pas une application mobile. Les usages qui demandent de travailler hors connexion ou d'utiliser le matériel du téléphone au-delà de l'appareil photo demandent autre chose.
Identité technique
| Module | Dépôt OCA | Dépend de |
|---|---|---|
web_responsive | web | mail, web, web_tour |
web_dialog_size | web | web |
web_notify | web | base, bus, mail, web |
server_action_mass_edit | server-ux | base |
base_technical_features | server-ux | base |
Le dépôt web compte 61 modules documentés, server-ux 34. Les cinq ci-dessus font partie de notre socle commun.
Questions fréquentes
Odoo Community a-t-il une application mobile ?
Non, pas d'application native : c'est l'un des manques réels de l'édition Community. web_responsive rend le client web réellement utilisable sur téléphone et tablette, ce qui couvre la plupart des usages nomades — saisie de temps, notes de frais, consultation d'une fiche. Il ne couvre pas le travail hors connexion.
web_responsive est-il compatible avec Odoo Enterprise ?
Non : il exclut explicitement web_enterprise, les deux ne peuvent pas cohabiter. Sur une instance Community, c'est sans conséquence. C'est en revanche un point à connaître si une bascule vers l'édition payante est envisagée un jour.
Comment modifier plusieurs champs d'un coup sur une sélection ?
Avec server_action_mass_edit : un administrateur configure une action Mass Edit Records sur le modèle voulu, en listant les champs concernés et l'opération possible pour chacun — Définir, Retirer, Ajouter. L'utilisateur la lance ensuite depuis le menu Action d'une vue liste. Odoo n'en permet nativement qu'un seul champ à la fois.
Faut-il donner l'accès permanent au mode développeur ?
À une ou deux personnes, pas plus : celle qui administre l'instance, et celle dont le travail quotidien dépend d'un bouton réservé à ce mode — la facturation immédiate d'un contrat, par exemple. base_technical_features évite qu'elles l'activent et l'oublient activé.
Ces modules sont-ils risqués en production ?
Ce sont les plus sûrs du socle : aucun ne crée de modèle, ils n'ajoutent aucune logique métier et se retirent sans laisser de données. Le seul effet à anticiper est visuel — web_responsive change l'apparence du menu des applications, prévenez vos équipes.
Se faire accompagner
Ces modules ne demandent presque pas de paramétrage, à une exception : les actions d'édition en masse, qui donnent le pouvoir de modifier des centaines d'enregistrements en un clic. Mal restreintes, elles font plus de dégâts que de gain.
Nous les configurons avec les bons groupes et les bons champs, et nous accompagnons la bascule visuelle de l'interface auprès des équipes — c'est de l'adoption, et c'est là que les projets se gagnent. Voir les prestations d'Atalios Consulting ou demander un rappel.
Pour aller plus loin
- Faire adopter Odoo par ses équipes : ce qui marche vraiment
- Les droits utilisateurs dans Odoo : qui voit quoi
- Le socle commun : les 57 modules de chaque instance
En résumé
Aucune fonction métier, et pourtant une bonne part de la différence entre « on a Odoo » et « on utilise Odoo » : une interface utilisable sur téléphone, l'édition de plusieurs champs en masse, des fenêtres modales lisibles. Un point structurant : web_responsive exclut web_enterprise. Parlons de l'adoption par vos équipes.