conception-de-site-de-contenu

Conception de site de contenu

Un site de contenu existe pour qu'un lecteur puisse trouver une page, confirmer qu'il s'agit de la bonne, obtenir la réponse ou la compréhension recherchée, et passer à autre chose. La plupart des lecteurs arrivent depuis un moteur de recherche sur une page profonde, scannent avant de lire et repartent dès qu'ils ont ce qu'il leur faut. L'erreur la plus courante des modèles est de concevoir l'enveloppe (héro, cartes, barre latérale, bascule mode sombre) et de négliger la structure du contenu lui-même : titres vagues, en-têtes qui ne disent rien ("Aperçu", "Introduction"), réponse trois paragraphes plus bas, page qui mélange tutoriel, référence et opinion, texte de lien comme "ici", absence de dates, et recherche sur le site qui ne renvoie rien d'utile.

Appliquez les principes classés de interface-guidelines (tout le monde peut l'utiliser > il dit la vérité > il dit ce qu'il veut dire > la réponse vient en premier > les erreurs sont surmontables > il reste en place > le possible est visible > convention > finition). Si cette compétence est installée, lisez d'abord son SKILL.md. La taille du corps de texte, la longueur de ligne, le contraste et le réécoulement sont traités dans ce fichier (references/human-interface.md sections 6 et 7) ; cette compétence couvre la structure du contenu, la navigation, la recherche et le lecteur agent.

Brief

• Type de site : documentation, centre d'aide, base de connaissances, éditorial ou blog, ou un mélange. Les sites mixtes nomment un travail principal par section.
• Lecteurs et leur arrivée : depuis une recherche vers une page profonde, depuis un produit (lien "?"), navigation, ou abonné. Qui est novice et qui est expert ?
• Tâches principales : les 10 à 20 questions que les lecteurs apportent, dans leurs propres mots. Extrayez-les des journaux de recherche, des tickets de support et des forums, pas de l'organigramme.
• Types de contenu : pour la documentation, parmi tutoriel, procédure, référence, explication ; pour l'éditorial, parmi actualité, analyse, opinion, guide.
• Fraîcheur : fréquence de mise à jour du contenu, propriétaire de chaque page, que se passe-t-il lorsqu'une version de produit change.
• Lecteurs agents : agents de codage qui lisent la documentation, moteurs de recherche et de réponse qui citent des pages, agents navigateurs. Que doivent-ils obtenir correctement ?
• Qui écrit : personnel uniquement, ou aussi utilisateurs (commentaires, réponses communautaires) ? Marquez le contenu écrit par des externes.

Règles

Balises : [E] empirique, [S] standard ou institutionnel, [P] praticien, [J] jugement. Les sources se trouvent dans les fichiers de référence.

Pages

• La réponse en premier. Les deux premiers paragraphes portent le point principal ; les détails suivent par ordre d'importance décroissante (pyramide inversée) [S : GOV.UK ; P : NN/g]. Les lecteurs ne lisent qu'une fraction des mots d'une page, une estimation que Nielsen a placée à environ 20 à 28 % [P : Nielsen 2008, d'après les données de Weinreich et al. 2008].
• Une page, un travail. Un tutoriel enseigne, une procédure dirige, une référence décrit, une explication discute ; ne les mélangez pas sur une même page [P : Procida, Diátaxis].
• Les titres sont uniques, spécifiques et mis en avant, dans les mots du lecteur, environ 65 caractères ou moins pour que les résultats de recherche ne les coupent pas [S : GOV.UK]. Les pages de tâche commencent par un verbe ("Faire pivoter une clé API") ; les conseils sur une tâche utilisent la forme en -ant ("Faisant pivoter les clés API") [S : GOV.UK].
• Un résumé sous le titre d'une phrase, 160 caractères ou moins, qui ajoute des mots que le titre ne possède pas ; le même texte sert de méta-description [S : GOV.UK].
• Les en-têtes disent ce que la section dit, mis en avant, pas "Aperçu" ou "Plus d'infos", et pas formulés comme des questions ; le contenu a toujours du sens avec les en-têtes supprimés [S : GOV.UK]. Les niveaux d'en-tête suivent la structure : un h1, pas de niveaux sautés [S : WCAG 1.3.1, 2.4.6].
• Phrases et paragraphes courts, mots simples. Scindez les phrases de plus de 25 mots, gardez les paragraphes à cinq phrases ou moins, expliquez un terme spécialisé à sa première occurrence [S : GOV.UK]. Adressez-vous au lecteur par "vous", voix active, condition avant instruction ("Pour supprimer un projet, ouvrez Paramètres") [S : Guide de style développeur Google].
• Listes numérotées pour les étapes, listes à puces pour les ensembles, tableaux pour les comparaisons [S : Guide de style développeur Google ; GOV.UK].
• Formatez pour le scan : des en-têtes significatifs et des paragraphes mis en avant contrent le scan en F, où les lecteurs ignorent le côté droit et les parties inférieures d'une page [P : Pernice, NN/g 2017].
• Des dates qui ont du sens : "Dernière mise à jour le 4 nov. 2026" avec une courte note de modification pour les changements substantiels, et une date de publication sur les articles. Les pages anciennes mais toujours exactes indiquent "Révisé" [S : GOV.UK notes de modification ; J].
• Notes de bas de page : GOV.UK les interdit pour le contenu de service ; les articles savants et éditoriaux longs peuvent en avoir besoin. Décidez selon que les lecteurs doivent vérifier les sources [S : GOV.UK ; J].

Liens

• Le texte du lien nomme la destination, mis en avant et unique par destination sur la page ; jamais "cliquez ici", "lire plus" ou "ici" [S : GOV.UK, WCAG 2.4.4].
• Dites quand un lien quitte le site, ouvre un fichier ou change de langue : "Fiche de prix (PDF, 240 Ko)" [S : GOV.UK].
• Liens là où ils aident, pas entassés en bas dans "Pour en savoir plus" ; les prochaines étapes à la fin d'une page de tâche sont acceptables si spécifiques [S : GOV.UK].
• Chaque en-tête a une ancre stable (#faire-pivoter-une-cle), avec un contrôle de copie de lien visible. Renommer un en-tête maintient l'ancienne ancre fonctionnelle [J].
• Les URL sont lisibles et permanentes. Lorsqu'une page est déplacée, redirigez l'ancienne URL ; ne laissez jamais les liens de documentation en 404 [J].

Navigation

• Les lecteurs arrivent en profondeur. Chaque page montre où elle se trouve (fil d'Ariane ou section en surbrillance) et ce qui est à côté et à proximité [S : WCAG 2.4.8 ; P : NN/g fils d'Ariane].
• Les étiquettes de navigation utilisent les mots des lecteurs et prédisent leur contenu (indice d'information) [E : Pirolli et Card 1999].
• Au moins deux façons d'atteindre une page : navigation plus recherche, ou un plan du site [S : WCAG 2.4.5].
• Une table des matières dans la page pour les pages longues, générée à partir des h2 et h3, mettant en évidence la section en cours [J].
• Pagination ou "Charger plus" plutôt que défilement infini pour les archives et les résultats de recherche, afin que les lecteurs puissent atteindre le pied de page, revenir à un endroit et partager une position [P : NN/g défilement infini].
• Documentation : une barre latérale organisée par tâche du lecteur et type Diátaxis, un sélecteur de version visible là où les versions diffèrent, et une bannière sur les pages obsolètes renvoyant vers la page actuelle [P : Procida ; J].

Recherche

• La recherche est un chemin principal, pas un ajout. La boîte est visible sur chaque page, pas cachée derrière une icône sur ordinateur [P : NN/g ; J].
• Les résultats montrent le titre de la page, sa section ou son type, un extrait avec les mots correspondants et la date. Tolérez les fautes de frappe et les synonymes des requêtes réelles [J].
• Les pages sans résultat suggèrent des corrections orthographiques, des termes plus larges et les pages les plus consultées, et enregistrent la requête [J].
• Passez en revue mensuellement les requêtes zéro résultat et les plus fréquentes ; chacune nomme une page manquante, un synonyme manquant ou un mauvais titre [P : pratique courante de documentation ; J].

Confort de lecture

• La police du corps de texte, la mesure, l'interlignage, le contraste et le réécoulement suivent les fondations. Sur téléphone, les lecteurs comprennent un texte court et simple aussi bien que sur ordinateur mais ralentissent sur un texte difficile, donc le contenu difficile nécessite une structure supplémentaire sur mobile [P : Moran, NN/g 2016].
• Pas d'interstitiels ou d'éléments collants qui couvrent le texte ; les publicités et les invitations à la newsletter n'interrompent jamais le premier écran de la réponse [S : WCAG 2.4.11 pour le focus ; J].
• Les images qui portent des informations ont un texte alternatif qui énonce l'information ; les images décoratives ont un alt vide [S : WCAG 1.1.1]. Les diagrammes ont une explication textuelle à proximité [J].
• Les exemples de code sont en texte, jamais en images, avec un contrôle de copie et le langage étiqueté. Les onglets pour les variantes de langage gardent toutes les variantes dans le DOM [J].
• Les modes d'impression et de lecture produisent le contenu sans chrome de navigation [J].

Pour les agents

• Le contenu est dans le HTML, rendu serveur, pas assemblé par JavaScript client après le chargement, afin que les crawlers et les agents qui n'exécutent pas de scripts l'obtiennent [J].
• La structure sémantique est l'interface : en-têtes, listes, tableaux, code et pre avec classes de langage, figure et figcaption [S : WCAG 1.3.1].
• URL et ancres stables et référençables, une URL canonique par page, et une date dans la page [J].
• Une copie Markdown propre de chaque page de documentation à la même URL avec .md ajouté, liée avec rel="alternate" type="text/markdown", est un moyen peu coûteux de donner aux agents de codage le contenu sans chrome. llms.txt à la racine du site ou de la documentation est une proposition communautaire ; une faible demande a été mesurée pour les sites généraux, mais cela correspond à la documentation lue par les agents de codage [P : Howard, llms.txt ; section 6 des surfaces agents fondamentales].
• Aucune instruction cachée pour les agents dans le texte de la page, les commentaires ou les éléments invisibles. Elles sont indistinguables d'une injection de prompt [J ; section 5 de la supervision fondamentale].
• Le contenu généré par les utilisateurs (commentaires, réponses communautaires, messages de forum) est marqué comme tel dans le balisage et visuellement, avec auteur et date, afin que les agents et les personnes puissent l'évaluer [J].

Ordre de construction

1. Tâches principales et inventaire du contenu : chaque page existante ou planifiée avec son type, propriétaire, dernière révision et la tâche qu'elle sert. Supprimez ou fusionnez les pages qui ne servent aucune tâche.
2. Architecture de l'information : sections à partir des tâches des lecteurs et des types de contenu ; étiquetez avec les mots des lecteurs ; testez les étiquettes avec un test d'arborescence (les personnes trouvent cinq tâches dans une arborescence textuelle uniquement) [P : NN/g test d'arborescence].
3. Modèles de page par type de contenu : titre, résumé, dates, structure du corps, prochaines étapes. Pour la documentation : modèles tutoriel, procédure, référence, explication (references/docs.md).
4. Rédigez ou réécrivez d'abord les pages des tâches principales avec references/writing.md ; une page complète et bonne vaut mieux que vingt ébauches.
5. Coque HTML sémantique : repères, lien d'évitement, fil d'Ariane, barre latérale en tant que nav avec aria-current, table des matières dans la page, pied de page. Rendu serveur.
6. Recherche avec des requêtes réelles issues des journaux ou de la liste des tâches principales ; ajustez les synonymes.
7. Couche agent : URL canoniques, ancres, copies Markdown, plan du site, llms.txt facultatif.
8. Style pour la lecture longue ; la marque possède l'apparence (brand-identity).
9. Vérifiez (ci-dessous).

Vérifier

1. Audit rendu sur une page d'accueil, un article long ou une page de référence, une page de résultats de recherche, et une page 404 :

   node <interface-guidelines>/scripts/audit.mjs <dist-or-url> --out audit-output
   

2. Test des tâches principales : pour chaque tâche principale, partez d'une requête de moteur de recherche ou de la page d'accueil, et atteignez la réponse. Comptez les étapes et notez là où l'indice a échoué. Faites-le une fois en tant que personne au clavier en largeur téléphone, et une fois en tant qu'agent avec uniquement l'instantané d'accessibilité.

3. Vérification du contenu sur chaque page (references/writing.md section 8 a un plan de script) : un h1 ; aucun niveau d'en-tête sauté ; titres uniques et 65 caractères ou moins ; résumé présent et 160 ou moins ; aucun en-tête ou texte de lien générique ("Aperçu", "cliquez ici", "lire plus") ; phrases de plus de 25 mots signalées ; images avec alt manquant ; date de dernière mise à jour présente.

4. Liens : explorez les liens internes cassés et les ancres manquantes ; vérifiez que les anciennes URL redirigent.

5. Vérification sans JS : récupérez une page avec curl et confirmez que le contenu principal et les en-têtes sont dans le HTML.

6. Recherche : exécutez les 20 requêtes les plus fréquentes et 5 fautes d'orthographe ; la bonne page se trouve dans les trois premiers résultats.

7. Lecture par agent : donnez à un agent uniquement l'URL d'une page de documentation ou sa copie .md et demandez-lui d'effectuer la tâche ; vérifiez qu'il suit la version actuelle et cite la bonne ancre de section.

Pièges

• Grilles de cartes d'accroches d'articles comme page d'accueil de la documentation, sans points d'entrée de tâche ni recherche.
• En-têtes nommés "Introduction", "Aperçu", "Détails", ou écrites comme des questions.
• Pages FAQ qui rassemblent des questions non liées au lieu d'y répondre sur les pages où elles surviennent.
• La réponse en dessous d'un long préambule sur l'importance du sujet.
• Un tutoriel qui se transforme en référence à mi-parcours, ou une référence agrémentée d'opinions.
• Articles non datés, et "dernière mise à jour" définie sur la date de construction sur chaque page.
• Contenu rendu uniquement par JavaScript client, onglets dont les panneaux cachés ne sont pas dans le DOM, code sous forme de captures d'écran.
• Défilement infini sur les archives et les résultats de recherche.
• Texte d'instruction pour les crawlers d'IA caché dans la page.
• Refaire le style d'un site de documentation alors que les titres, les en-têtes et la recherche restent cassés.

Références

Fichier	Lire quand
references/writing.md	Rédiger ou modifier des pages : titres, résumés, en-têtes, phrases, liens, dates, nombres, spécificités éditoriales et un plan de vérification
references/docs.md	Documentation et centres d'aide : types Diátaxis avec modèles, pages de référence API, exemples de code, versions, journaux de modifications, documentation pour agents de codage
references/navigation-search.md	Structure du site, étiquettes, barres latérales, fils d'Ariane, listes de contenu, archives, résultats de recherche, 404