Introduction
Dans Odoo, un « modèle » organise les données : il définit quelles informations sont stockées et comment elles sont reliées. Chaque élément de votre activité (page, commande, client...) existe sous la forme d’un enregistrement dans un modèle précis.
Pour bien paramétrer et personnaliser Odoo, les consultants fonctionnels et les développeurs doivent maîtriser la notion de modèle. C’est la brique qui fixe les champs, les liaisons entre objets et la logique métier applicables aux données.
Cet article prend comme point d’étude le modèle website.page. C’est celui qui gère les pages statiques de votre site Odoo : pages institutionnelles, landing pages ou pages créées via l’éditeur de site. Si vous construisez du contenu, automatisez des publications ou connectez des pages à d’autres systèmes, vous rencontrerez ce modèle.
Qu’est-ce que le modèle website.page ?
Le modèle website.page représente les pages statiques d’un site Odoo et fait partie de l’application Website. Il enregistre les pages que vous créez manuellement, comme « À propos », « Contact » ou une page dédiée à une campagne.
Techniquement, website.page repose sur l’héritage des modèles Odoo : il s’appuie sur ir.ui.view via _inherits. Chaque enregistrement website.page est lié à une vue ir.ui.view qui contient le template QWeb et les métadonnées associées.
Les pages dynamiques (boutique, listes de blog, etc.) sont traitées autrement et ne passent pas par website.page.
Autrement dit, website.page sert uniquement le contenu statique édité avec le constructeur de site ; les contenus générés automatiquement suivent une logique différente.
Champs essentiels du modèle
Voici les champs clés du modèle website.page qu’il est utile de connaître pour bien gérer vos pages et éviter les pièges.
1. name
Type : Char. Titre de la page. Il s’affiche dans l’onglet du navigateur, dans les menus et sert souvent comme valeur par défaut pour le titre SEO. Ce titre provient généralement de la vue liée (ir.ui.view).
2. url
Type : Char. Chemin de l’URL de la page. Doit commencer par une barre oblique (/). Exemples : /contact, /a-propos. C’est l’adresse que vos visiteurs utiliseront pour accéder à la page.
3. view_id
Type : Many2one (ir.ui.view). Obligatoire. Référence la vue QWeb qui contient le contenu réel de la page (arch/XML) et ses paramètres. La suppression de la vue entraîne la suppression de la page.
4. website_id
Type : Many2one (website). Le site auquel la page appartient. Dans une configuration multi-sites, ce champ permet de lier la page à un site ou de la laisser globale (champ vide).
5. is_published
Type : Boolean. Indique si la page est publiée et accessible aux visiteurs. Les pages non publiées peuvent renvoyer une erreur 404 ou une redirection, utile pour masquer sans supprimer.
6. website_indexed
Type : Boolean. Permet de contrôler l’indexation par les moteurs de recherche. À définir à False pour les pages de remerciement ou internes que l’on ne veut pas voir apparaître dans les résultats.
7. date_publish
Type : Datetime. Date de publication effective. Sert pour la programmation des publications et pour l’affichage de la date de mise en ligne.
8. header_visible
Type : Boolean. Indique si l’en-tête du site doit être affiché sur la page. Pratique pour des landing pages sans distractions ou expériences plein écran.
9. footer_visible
Type : Boolean. Indique si le pied de page est affiché. Permet de créer des pages épurées sans le footer standard.
10. is_homepage
Type : Boolean (calculé). Vrai si la page est définie comme page d’accueil du site. Une seule page par site peut avoir ce statut.
11. is_visible
Type : Boolean (calculé). Détermine si la page est visible en fonction du statut de publication, de la date et des règles de visibilité.
12. menu_ids
Type : One2many (website.menu). Les éléments de menu qui pointent vers cette page. Une même page peut apparaître dans plusieurs menus ou aucun.
13. create_date
Type : Datetime. Date de création de l’enregistrement, gérée automatiquement par Odoo — utile en audit et rapport.
14. write_date
Type : Datetime. Date de la dernière modification, également gérée automatiquement. Sert à suivre les mises à jour de contenu.
15. arch
Type : Text. Le template QWeb (XML) contenant la structure HTML et les snippets Odoo. Stocké sur la vue liée et modifiable via l’éditeur de site.
16. key
Type : Char. Identifiant unique de la vue, utilisé dans les fichiers XML des modules et pour l’héritage. Format courant : module.view_name.
17. type
Type : Selection. Type de vue. Pour les pages de site, c’est toujours qweb. D’autres types existent (form, list, tree) pour d’autres usages.
18. active
Type : Boolean. Flag d’archivage (soft delete). Lorsqu’il est False, l’enregistrement est archivé et la page n’est plus servie. Ce champ provient d’ir.ui.view.
19. website_meta_title
Type : Char. Titre SEO. Permet d’overrider le titre par défaut pour les résultats de recherche — important pour la visibilité.
20. website_meta_description
Type : Text. Méta description SEO. Fragment qui s’affiche dans les résultats de recherche. Idéalement entre 150 et 160 caractères pour un rendu optimal.
21. website_meta_keywords
Type : Char. Mots-clés méta. Moins déterminants aujourd’hui pour le référencement, mais encore utilisés dans certains contextes. Séparés par des virgules.
22. header_overlay
Type : Boolean. Indique si l’en-tête est superposé au contenu, utile pour les pages « hero » où le header apparaît sur la bannière.
23. header_color
Type : Selection. Thème de couleur de l’en-tête (transparent, clair, foncé, etc.). Impacte le contraste et la lisibilité du header par rapport au contenu.
24. visibility
Type : Selection. Contrôle d’accès : Public, Utilisateur connecté, Groupe restreint, Mot de passe. Permet de définir qui peut voir la page.
25. redirect_type
Type : Selection. Comportement en cas de changement d’URL : 301 (permanent), 302 (temporaire) ou aucun. Important pour conserver la valeur SEO lors de déplacements de pages.
Utilisations courantes dans les processus métier
Cas d’usage fréquent 1 : pages de campagne et landing pages
Les équipes marketing mettent en ligne des landing pages pour des campagnes : chaque landing est un enregistrement website.page avec son URL, son contenu et une date de publication programmée (date_publish). Cela facilite la gestion des lancements et des promotions.
Cas d’usage fréquent 2 : pages institutionnelles
Pages telles qu’« À propos », « Contact », conditions générales ou politique de confidentialité sont généralement gérées comme website.page. Elles sont éditées ponctuellement et positionnées dans les menus via menu_ids.
Cas d’usage fréquent 3 : pages de remerciement et confirmations
Pages affichées après une action (formulaire envoyé, commande reçue) sont des website.page. Pensez à désactiver website_indexed pour ces pages afin qu’elles ne figurent pas dans les résultats de recherche.
Cas d’usage fréquent 4 : multi-sites et contenus localisés
Dans un environnement multi-site, website_id permet d’attribuer une page à un site précis. Pour des sites multilingues, on duplique souvent la page par site et on adapte le contenu pour la localisation.
Cas d’usage fréquent 5 : contenus protégés et accès restreint
Le champ visibility permet de restreindre l’accès aux pages aux utilisateurs connectés ou à des groupes spécifiques — pratique pour des espaces membres ou de la documentation interne.
Comment les développeurs étendent ce modèle
Les développeurs étendent website.page via l’héritage de modèle et quelques bonnes pratiques propres à Odoo.
Héritage du modèle
Pour personnaliser, on déclare _inherit = 'website.page' et on ajoute des champs, on surcharge des méthodes ou on définit des contraintes. Ce pattern garde les modifications isolées dans un module, ce qui facilite les mises à jour.
Ajouter des champs
Déclarez de nouveaux champs dans votre modèle hérité en choisissant le type adapté (Char, Many2one, Boolean, Integer, Text, Selection). Pour des environnements multi-site, pensez aux champs dépendants du site (website_dependent).
Extensions Python
Surchargez create, write ou unlink pour injecter de la logique métier (contrôles, génération automatique, notifications). N’oubliez pas d’appeler super() pour conserver le comportement natif et faites attention à la relation view_id et à l’effet de cascade.
Odoo Studio
Odoo Studio permet des personnalisations rapides sans écrire de code — utile pour des ajustements de mise en page. Pour des besoins complexes (intégrations API, logique métier avancée), privilégiez un module personnalisé pour la maintenabilité.
Bonnes pratiques
- Utilisez des slugs URL propres et lisibles : pas d’espace ni de caractères étranges. Préférez les traits d’union pour séparer les mots.
- Désindexez (website_indexed = False) les pages internes ou de remerciement pour éviter qu’elles n’apparaissent dans les moteurs de recherche.
- Lors d’une modification d’URL, mettez en place un redirect approprié (301/302) afin de conserver le référencement et d’éviter les liens cassés.
- Renseignez systématiquement website_meta_title et website_meta_description pour chaque page publique — ce sont des leviers simples et efficaces pour améliorer le SEO.
- Si vous créez des pages par API ou XML-RPC, créez d’abord la vue ir.ui.view (type qweb, key unique), puis créez l’enregistrement website.page en lui associant view_id pour garantir l’intégrité.
Erreurs fréquentes
- Ne créez jamais une website.page sans view_id valide : la vue doit exister et être de type qweb pour que la page fonctionne correctement.
- Assurez-vous que les URLs commencent par une barre oblique (/). Odoo attend des chemins absolus, pas des fragments sans slash.
- N’oubliez pas de désindexer les pages de remerciement : si vous l’oubliez, elles peuvent apparaître dans les résultats et nuire à la qualité du référencement.
- Quand vous changez l’URL d’une page, configurez une redirection. Sans redirection, les anciens liens se cassent et le trafic organique peut chuter.
- Attention : modifier l’arch d’une vue précédemment éditée dans l’éditeur de site peut être bloqué par le flag noupdate dans ir.model.data. Si vos modifications XML ne passent pas, vérifiez et réinitialisez ce flag si nécessaire.
Conclusion
Le modèle website.page est la pierre angulaire de la gestion des pages statiques dans Odoo : il conserve les métadonnées, les chemins d’accès et les paramètres de publication, tandis que le contenu HTML est servi depuis la vue associée ir.ui.view.
Maîtriser ses champs et comprendre l’héritage vers ir.ui.view facilite la configuration, la personnalisation et l’intégration des sites Odoo. Qu’on soit consultant fonctionnel ou développeur, cela évite des erreurs courantes et fait gagner du temps.
Besoin d’aide pour votre déploiement Odoo ?
Dasolo accompagne les entreprises dans le déploiement, la personnalisation et l’optimisation d’Odoo. Nous sommes spécialisés en intégrations API et développement Odoo, avec une expertise approfondie de l’architecture et des modèles comme website.page.
Besoin d’un coup de main pour votre implémentation Odoo, vos pages personnalisées ou vos intégrations ? Nous pouvons vous accompagner. Demandez une démo pour discuter de votre projet.