Drupal : modéliser son contenu pour couvrir les réponses attendues par les IA

Le problème du grand champ de texte libre

Beaucoup de sites concentrent l'essentiel de leurs informations dans un unique champ « body » (corps de texte) rédigé pour une seule page. Les prix, les limites, les spécifications techniques ou les marchés couverts existent bien, mais ils sont enfermés dans des paragraphes. Résultat : impossible de les afficher dans un tableau comparatif, de les filtrer, de les exposer à un système tiers ou de vérifier qu'ils sont à jour, sans relire et réécrire du texte à la main.

La modélisation de contenu (content modeling) dans Drupal consiste à stocker les valeurs comparables dans des champs dédiés, à relier les enregistrements entre eux via des références d'entités (entity references), et à réserver la prose à l'explication et au contexte. Les mêmes valeurs peuvent alors alimenter la page elle-même, un comparateur, du JSON-LD (balisage de données structurées lisible par les moteurs et les IA), un flux, une API et même un rapport de couverture des contenus. Une seule modification met à jour toutes les sorties.

Partir des questions des acheteurs, pas de la maquette

Les modèles de contenu naissent souvent d'un wireframe : la maquette prévoit un titre, un hero, une zone de texte, une image et un appel à l'action, donc le type de contenu Drupal reçoit des champs portant ces noms. Cette approche décrit la mise en page, pas l'information.

La démarche recommandée inverse l'ordre : commencer par les questions qu'un acheteur doit résoudre avant de décider.

• Combien cela coûte-t-il ?
• Quelles spécifications puis-je comparer ?
• Est-ce disponible dans mon pays ?
• Avec quels systèmes cela s'intègre-t-il ?
• Qu'est-ce qui est exclu du périmètre ?
• Sous quel délai pouvez-vous livrer ?
• Quelle référence prouve que vous avez déjà réalisé un travail similaire ?

Chaque question pointe vers une information que l'organisation doit maintenir. Plusieurs pages peuvent utiliser la même réponse, et un assistant IA peut également l'extraire lorsqu'il compare des fournisseurs. Le template décide ensuite où la réponse s'affiche ; le modèle de contenu décide ce qu'elle signifie, qui en est responsable et où le site peut la réutiliser. Cet ordre évite un écueil classique : reconstruire l'ancienne page champ par champ en conservant tous ses défauts d'information.

Quand une valeur mérite-t-elle son propre champ ?

Trois tests permettent de trancher, et ils protègent aussi le modèle contre les champs superflus.

• La valeur est-elle comparée par les acheteurs ? Prix, dimensions, certifications, délais, versions supportées, zones de couverture : ces valeurs servent à éliminer des options et exigent des noms et formats cohérents. « Livraison rapide » relève de la prose ; « Livraison standard : 10 jours ouvrés » relève d'un champ.
• La valeur est-elle réutilisée ailleurs sur le site ? Un service peut apparaître sur sa propre page, dans une landing page sectorielle, dans un comparatif et dans un cas client. Copier son mode de livraison dans chaque page crée plusieurs propriétaires pour un même fait. Il faut stocker la valeur une fois et la référencer.
• Un rapport, un filtre ou une intégration en a-t-il besoin ? Si l'équipe marketing veut lister les services sans prix publié, le statut de prix doit être requêtable. Si un utilisateur filtre des produits par voltage, cette donnée ne peut pas exister uniquement dans du HTML. Si un ERP (progiciel de gestion) fournit la disponibilité, Drupal a besoin d'un champ de destination au format défini.

À l'inverse, une phrase utilisée une seule fois, jamais comparée et jamais requêtée peut rester en prose. C'est ce qui évite la sur-modélisation.

À quoi ressemble un type de contenu produit bien structuré ?

Pour un produit industriel comme une pompe, un modèle utile sépare par exemple : le nom et l'identifiant produit (texte), la famille de produit (référence à une taxonomie, pour les pages de catégorie et les filtres), le voltage et le débit maximal (champs décimaux) accompagnés chacun d'un champ d'unité distinct, l'indice de protection (vocabulaire contrôlé), la disponibilité et le délai de livraison (liste et entier avec unité), les marchés couverts (taxonomie), la documentation (référence média vers une fiche technique PDF), une date de dernière vérification, et enfin un champ de description en texte formaté pour le contexte et la persuasion.

Deux principes ressortent de ce modèle :

• La valeur numérique et son unité occupent des champs séparés, car un chiffre nu n'a aucun sens. Un type de champ personnalisé peut les combiner à la saisie, mais le modèle a besoin des deux parties.
• Les valeurs manquantes obéissent à une règle explicite : un délai de livraison vide signifie « non renseigné », pas « immédiat ». Des états comme « sur commande » ou « devis individuel » se modélisent explicitement, plutôt que de laisser le template deviner.

Une fois les valeurs structurées, une vue Drupal peut produire un tableau de produits, un filtre peut exploiter le voltage ou le marché, le JSON-LD peut mapper l'identifiant et les propriétés, et JSON:API (l'API standard de Drupal pour exposer les contenus) peut renvoyer le même enregistrement à un autre système.

Et pour une offre de services ?

Les services aussi ont besoin de structure, avec des champs différents d'un catalogue produit : nom du service, réponse courte (deux phrases autonomes destinées aux extraits de recherche et aux résumés d'IA), cibles adaptées, livrables, modèle d'engagement, présentation du prix, durée typique, langues supportées, exclusions de périmètre, preuve associée (référence vers un cas client validé), propriétaire du contenu, date de prochaine revue et explication détaillée en texte formaté.

Cette liste n'est pas universelle : les bons champs découlent des vraies questions des acheteurs, des conversations commerciales et des systèmes qui fournissent les valeurs. Une société de services peut avoir besoin de champs pour le lieu de livraison, le modèle d'équipe ou la conformité ; un éditeur pour l'auteur, l'édition, le sujet et l'audience. La méthode reste la même. Le champ « réponse courte » gagne à être rédigé selon une logique « réponse d'abord », car il doit pouvoir tenir seul dans un extrait ou un résumé généré par une IA.

Un enjeu de gouvernance autant que de technique

Derrière ces choix de champs se cachent des questions d'organisation. Qui possède le prix quand il vient de l'ERP ? Qui vérifie les valeurs et à quelle fréquence ? Les champs « propriétaire », « date de revue » et « dernière vérification » inscrivent ces responsabilités dans le modèle lui-même et rendent possibles des rapports de fraîcheur ou de couverture : par exemple, lister automatiquement tous les services sans prix publié ou sans cas client associé.

C'est aussi ce qui conditionne la visibilité auprès des IA génératives : un assistant qui compare des fournisseurs a besoin de faits nommés, formatés et vérifiables. Tant qu'ils sont noyés dans du texte rédigé pour une seule page, ils sont difficiles à extraire et à citer. La migration d'un site existant peut se faire par étapes, en sortant progressivement les valeurs comparables du champ body plutôt qu'en refondant tout d'un bloc.