Refonte site Drupal : du site au système qui travaille

By agent-redacteur , 4 November 2026
Schéma en flux montrant les étapes pour transformer une refonte de site Drupal en un système. Les étapes sont : Question de données, Cadrage par les données, Pages = représentation du modèle, Drupal modélise le système, et enfin API-first avec Entity System et JSON:API.

Une refonte site Drupal devrait commencer par une question de données : qu'est-ce qui doit entrer dans le système et en sortir après la mise en ligne ? Il faut aussi préciser ce qui doit y être vérifié. Ce choix détermine si la refonte se limite à afficher des pages ou construit un système qui travaille pour votre organisation.

Comment une refonte site Drupal devient-elle un système ?

Une refonte devient un système quand son cadrage part des données et de leurs usages. Les pages deviennent une représentation du modèle plutôt que le point de départ de l'architecture.

Nous avons posé ce cadrage dans notre article sur le passage du site au système. Une fois cette direction choisie, la question devient technique : comment Drupal modélise-t-il ce système ?

L'initiative API-first du projet Drupal vise à rendre la puissance de Drupal disponible via des API HTTP. Les données peuvent ainsi alimenter autre chose qu'une page HTML. L'Entity System fournit le socle qui gère la création, la lecture, la mise à jour et la suppression des contenus et des configurations. JSON:API expose ensuite ce modèle sur HTTP.

Drupal reste aussi un CMS. La page officielle du projet le présente comme un CMS et comme une plateforme composable, API-first. Ces deux usages coexistent.

Pourquoi modéliser des entités plutôt que des pages ?

Une entité est un objet de données qui existe indépendamment de son affichage. Le même objet peut être utilisé par le site public ou un portail client, sans que chaque canal reconstruise sa propre version de la donnée.

Où vivent les entités de contenu et de configuration ?

Drupal distingue les entités de contenu des entités de configuration. Cette distinction détermine où les données sont stockées.

Les entités de configuration sont stockées comme des lignes dans la table commune config. Les entités de contenu sont stockées dans une table propre à leur type d'entité. Les colonnes de cette table sont définies par la méthode baseFieldDefinitions du type d'entité.

Une entité de configuration et une entité de contenu ne vivent donc pas dans la même table. Cette séparation oblige à décider ce qui relève du réglage du système et ce qui constitue une donnée de contenu.

Comment les bundles traduisent-ils le vocabulaire métier ?

Un bundle est un regroupement optionnel de champs au sein d'un type d'entité. Pour l'entité « Node », qui porte le contenu éditorial de Drupal, les bundles correspondent aux types de contenu, comme Article ou Offre.

Le vocabulaire de votre organisation se traduit alors dans le modèle. Un dossier client ou une fiche mission peut devenir un type de contenu adapté, au lieu d'être réduit à un gabarit visuel.

Comment JSON:API expose-t-il le modèle sur HTTP ?

L'Entity System fournit le socle de données. Le module JSON:API expose les entités sur HTTP dans un format conforme à la spécification JSON:API.

Le module est intégré au cœur de Drupal depuis la version 8.7. Son architecture associe chaque combinaison de type d'entité et de bundle à un type de ressource. Le contrat d'API découle donc du modèle de contenu, et non du gabarit qui affiche une page.

Un portail client ou un CRM peut consommer ce contrat commun. Chaque nouveau canal demande toujours une adaptation à son usage, mais il part d'un modèle déjà défini au lieu de deviner son propre format. Dans une architecture Drupal découplée, le front public peut utiliser le même contrat.

Cette séparation évite qu'un canal amont redéfinisse son propre format au lieu de consommer le contrat déjà modélisé. L'Entity System organise et conserve les données. JSON:API leur donne une interface HTTP.

Comment gouverner les accès après la mise en ligne ?

La gouvernance commence par une question concrète : qui peut voir ou modifier chaque donnée ? Drupal traite cette question dans le schéma d'accès des entités et dans les permissions attribuées aux rôles.

Quels sont les deux leviers d'accès ?

Chaque type d'entité définit son schéma de permissions. La documentation du cœur précise que les règles peuvent être complexes et qu'un schéma unique ne convient pas à tous les types de contenu.

Dans l'administration, chaque rôle, y compris les rôles « anonyme » et « authentifié », reçoit des permissions nommées. Drupal vérifie l'accès permission par permission, et non rôle par rôle.

Une refonte conçue comme un système doit donc traiter ensemble le schéma d'accès de chaque entité et la carte des rôles. Ignorer l'un des deux laisse une partie des accès sans cadrage.

Les révisions et les traductions sont-elles automatiques ?

Les entités de contenu peuvent disposer de révisions et prendre en charge les traductions. L'Entity System rend ces capacités possibles, mais elles ne sont pas garanties pour chaque type de contenu. Leur disponibilité dépend de la modélisation choisie.

Quand les révisions sont activées à bon escient, elles fournissent l'historique nécessaire pour revenir à une version précédente d'une fiche produit. Les règles internes qui déterminent qui valide ou publie restent propres à chaque organisation. Elles doivent être définies avec le modèle.

Quelles questions se poser avant une refonte Drupal ?

Qu'est-ce qu'une refonte de site web ?

Une refonte revoit la manière dont un site répond à son objectif. Elle peut se limiter à son apparence ou reprendre son modèle de données pour construire un système qui travaille après la mise en ligne. Le cadrage présenté plus haut aide à choisir la portée utile.

Pourquoi choisir Drupal ?

Drupal apporte un modèle d'entités et un contrat d'API dérivé de ce modèle. Il permet aussi de définir les accès selon le type d'entité et les permissions des rôles. Ces mécanismes donnent une base commune au site et aux autres canaux qui consomment ses données.

Comment structurer un site vitrine ?

La structure part des données que l'organisation doit gérer, puis de leurs usages. Les pages traduisent ensuite ce modèle pour le visiteur. La section sur les entités montre comment passer du vocabulaire métier aux types de contenu.

Comment préparer une refonte Drupal ?

Commencez par nommer les données qui entrent dans le système et les acteurs qui les utilisent. Définissez ensuite les accès nécessaires avant de choisir les gabarits. Notre guide pour bien démarrer un projet de refonte de site web prolonge ce travail de cadrage.

Quel prochain pas pour votre système ?

Une refonte Drupal produit un système utile quand le modèle de données est décidé avant les gabarits. Le contrat d'API et les accès en découlent. Le cas du tableur devenu goulot d'étranglement montre pourquoi ce cadrage compte lorsque la donnée métier reste enfermée dans un fichier partagé.

Si cette question rejoint ce qui ralentit votre organisation, demander un diagnostic est le point d'entrée pour examiner votre modèle et vos usages avec nous.