Points clés sur sa stratégie de contenu

par lena · 20 décembre 2016

Quelque soit l’outil utilisé pour construire et mettre en place notre site, et à plus fortes raisons quelque soit le framework utilisé, Joomla, WordPress, Drupal, Spip, Typo3, CMS Made simple ou bien d’autres… il faut savoir que les CMS nous permettent juste dans la majeure partie des cas de créer et de mettre en ligne très rapidement du contenu.

Seulement voilà, une fois encore, vitesse et précipitation ne répondent pas systématiquement à un gage de qualité. Bon, bien que tout puisse être discutable et que certains diront que produire un site de type blog ne nécessite rien d’autre que de pondre du contenu, prenons quand même le temps de cet article pour nous poser quelques questions et voir en quoi nous pourrions toujours améliorer le contenu de nos sites, simplement en préparant un minimum notre travail.

Définitions et objectifs du site

Avant toute chose, il est bon de reprendre de manière générale les grandes lignes des définitions et de la mise en place d’un projet de site web.
Deux ébauches d’articles, Organisation et mise en place d’un projet de site web et Description d’un projet de site web, permettent déjà de pouvoir mettre en place une liste de points à aborder et à prendre en considération.

Nous pourrons retenir et préciser quelques points pour les propos de cet article

Bien clarifier les objectifs du site et la ligne éditoriale
Définir la ou les cible(s) et les personnes s’y rattachant
Savoir si le site sera une maquette ou directement un site de contenu

Architecture d’information

La prise en compte, par une attention particulière, de l’architecture d’information, peut s’avérer très vite productive et porteuse d’intérêts multiples. En effet, il est fréquent de négliger cet aspect et de composer directement avec une arborescence qui peut parfois nous paraître intuitive. C’est bien souvent la meilleure manière de se retrouver rapidement face à des incohérences, qu’elles soient de navigation ou encore de catégorisation…

Il est important à ce stade de réflexion de travailler en étroite relation avec les internautes de base à qui s’adresse ce site. Ce sont eux qui vont permettre de mieux définir l’ensemble du vocabulaire contrôlé et des regroupements de thèmes relatifs au domaine d’activité qui les concerne. Le recours à un tri de cartes (ouvert ou fermé) peut éventuellement être employé afin de mieux définir non seulement la catégorisation du site, mais également son étiquetage. Vous pouvez vous rapprocher de l’article d’Introduction à l’architecture d’information sur ce même site.

Étiquetage, labellisation et autres mots clés

Afin de pouvoir homogénéiser l’utilisation de certains termes tout au long des pages, il est très important de travailler sur un vocabulaire contrôlé. Cela permettra non seulement de faciliter la lecture, la mise à jour, l’accessibilité ou encore le référencement du site.

Par exemple, un acronyme écrit BMR dans une page et B.M.R dans une autre, peut être un piège dans lequel il est facile de tomber. De même et toujours à titre d’exemple, est-ce le mot volcanologie ou vulcanologie, ou alors volcanologie (vulcanologie)… bref… vous aurez compris qu’il faut homogénéiser l’emploi des mots forts et clés du contenu. Il est toujours bon de pouvoir composer cette liste dès les premiers travaux en relation avec le client et les utilisateurs cibles.

Afin d’affiner cette étape l’article Taxonomie, Thésaurus et vocabulaire contrôlé peut être d’une certaine utilité. Une fois générée, cette liste de mots clés et propre à l’univers du site en cours de développement, pourra être utilisée de manière multiple :

Pour nommer les rubriques et éléments de menus
En injection directe dans le contenu des articles
En nommage de dossiers, noms de classe CSS, ou autre éléments de code
Comme méta données placées au cœurs des fichiers médias
Pour alimenter glossaire, index, FAQ ou autre éléments de recherche par mots clés

Outils, technologies et langages

Très rapidement il va nous falloir définir quelques éléments de technologie à utiliser, à commencer par le type de framework sur lequel nous allons nous appuyer (log, CMS, Wiki,…). Puis ensuite sur quelle solution ou versions… WordPress ? Drupal ?… Joomla ? 1.5?, 1.6 ?… 2.5 ???. Parfois le choix est imposé par le client car celui-ci, ou un de ses partenaires, utilise déjà une application basée sur une solution particulière. Parfois le choix peut être purement subjectif et relatif à une préférence personnelle…

Dans la majeure partie des cas, il est conseillé de s’appuyer sur une réponse à un besoin qui soit pris en compte par l’outil choisit et dont les éventuelles extensions seront compatibles. Un petit tour du côté des forums spécialisés ou du site CMSMatrix peut s’avérer intéressant.

Un autre élément à prendre en compte va être le type de DOCTYPE que nous allons utiliser, HTML 4.01, xHTML 1.0 ou HTML5. Si les deux premiers portent presque uniquement sur la propreté du code HTML employé, le dernier lui, va engendrer non seulement une prise en considération forte des navigateurs cibles, et des adaptions qui en découlent, mais va porter également sur le panel de balises structurelles et sémantiques qui sont à disposition.

Il peut également être envisagé dans un premier temps de travailler en HTML 4.01, ou xHTML 1.0, et de préparer le balisage en usant de <div class= »header »> en lieu et place de <header> ce qui peut permettre une évolution plus douce vers une bascule sur HTML5.

Structure des pages

L’architecture d’information ne doit pas être réduite à une simple catégorisation et labellisation du site de manière globale. Bien au contraire, il faut également prendre en compte une granularité plus fine, à commencer par la structure de la page elle-même :

Sa composition et son découpage en zones de fonctionnalité et d’affichage, en tête, navigation, pied de page, contenu… puis continuer en détaillant la moindre structure d’information présente, comme les notes avec leur titre, sous-titre, chapeau, lien en savoir plus, citation éventuelle, illustration… ou encore les encarts de contenu qui peuvent se décliner en autant d’éléments que de contextes…

Bref la description de nos pages peut s’avérer devenir un véritable travail de découpage, d’organisation, de structuration, et ce travail n’est après tout que la continuité de celui effectué sur l’architecture d’information.

Dans un premier temps, la page peut elle même être découpée en divers contextes :

Contenu textuel, pages de base et de contenu
Catalogue produit
Fiche d’évaluation ou de présentation
Détails d’information
Sous-navigation et menu contextuel
Formulaires de communication ou de retour d’information
etc…

Chacun de ces contextes devra être nomenclaturé et architecturé sous forme de balises HTML : En partant du sectionnement <section>, <article>, <div> ou encore <span>, en passant par les menus d’entêtes <h1>, <h2>…. intégrant la finesse de la granularité de l’information, les éléments de navigation primaire et secondaire <nav>, <ul>… jusqu’aux éléments de description de contenu <aside>, <blockquote>, <q> et autres balises pouvant définir de manière à la fois structurelle et sémantique le contenu des pages.

Dans un second temps, la granularité de découpe peut définir divers sous-éléments composés de :

Divers niveaux de titres
Description courte ou longue, divers niveaux de détails
Référence en citation courte ou longue et liens complémentaires
Illustrations et galeries
Contenus principaux et assimilés…

Gardons à l’esprit que grand nombre de sites web basés sur une architecture de CMS ou de blog, déroulent leur contenu de manière linéaire, sans baliser le moindre aspect du contenu qu’ils déversent, juste des titres et des paragraphes… Aucune citation, niveaux de détails, liens contextuels, encarts…. Pensons à ne pas commettre les mêmes erreurs et à ajouter à notre back-office un éditeur HTML digne de ce nom pour nous aider à aller plus loin…

En commençant par utiliser les deux lignes de l’éditeur par défaut de WordPress
En musclant un peu l’éditeur par défaut de WordPress
en utilisant un autre éditeur interne par exemple :
N’hésitez pas à googler sur le sujet et à nous faire part de vos préférences

Accessibilité

Trop souvent ignorée, l’accessibilité des sites devrait devenir un des éléments majeurs de nos préoccupations en tant que développeurs intégrateurs. N’oublions pas que se pencher sur cette problématique, c’est permettre à tout un chacun, et donc au plus grand nombre, d’accéder de manière confortable à l’information que le site distribue.

De même, au niveau de l’optimisation des contenus pour le référencement, les sites qui sont accessibles, seront forcément mieux visités par les moteurs de recherche et de ce fait, à contenu équivalent, auront plus de chance d’être mieux positionnés. Dans les deux cas c’est que du bon. Donc en avant, accessibilisons!

L’article « Introduction et notions d’accessibilité » encore en cours d’écriture, devrait être publié prochainement… si cela n’est pas le cas lorsque vous lirez ce contenu, n’hésitez pas à nous le rappeler. En résumé, et bien que l’accessibilité soit d’aspect très volumineux et engage un grand nombre de prises en compte, nous pouvons dégager une liste (non exhaustive), d’éléments majeurs pouvant figurer dans l’intégration de nos contenus de CMS.

Points à prendre en compte

Les documents téléchargés (PDF, type Word, Tableurs, etc…) se devraient d’être accessibles
Les éléments multimédias, images, animations, vidéos doivent diriger vers un contenu alternatif et éventuellement proposer un sous-titrage
Si l’identité visuelle n’est pas optimisée, il est bon de prévoir une feuille alternative accessible depuis le navigateur
L’ensemble des balises structurelles doivent avoir recours à l’attribut aria-role
Les formulaires doivent permettre une saisie complète sans l’utilisation de la souris
La structure des pages et du site doit être optimale, pensez aux lecteurs d’écrans

Optimisation pour le référencement

Certes, il n’est pas possible de résumer en quelques lignes les principes d’optimisation de pages en vue d’un meilleur référencement naturel, mais il est déjà possible d’en fortifier quelques bases élémentaires. Surtout, si l’architecture du site et la structure des pages ont été optimisées, une grande partie du travail est déjà réalisée.

Récupérons le document du vocabulaire contrôlé et établissons une liste parallèle de mots et expressions clés que nous souhaiterions retenir. Munis de ces deux listes, il faut maintenant s’assurer qu’un certain nombre de points soit pris en compte . Pour cela et page par page, une liste de deux ou trois mots clés des plus appropriée va être retenue. Le référencement est une affaire de pages et non de site.

Vérifier pour chaque page que :

Les titres de page, balises <title> et principales balises de header <h1>, <h2>… contiennent ces mots ou expressions clés
Ces mêmes mots clés devront être également utilisés dans des balises d’emphases <em>, <strong>, <small>…
Un certain nombre de liens utilisant ces mots clés devra pointer vers des pages externes ou internes au site et de même, des pages externes ou internes au site devront pointer vers cette page. Attention à ne pas tomber dans de l’échange de liens qui peut au contraire nuire à un bon positionnement.
Il faut s’assurer que l’ensemble des abréviations ou acronymes contenus dans la page sont correctement balisés en <abbr> et que leur attribut title est bien renseigné.
Bien que pour l’instant les moteurs ne s’appuient pas sur les balises <meta keywords> cela ne coûte rien de les renseigner et surtout de préciser avec un texte court, la balise <meta description> qui elle, est souvent utilisée par les moteurs pour remplir le snippet.

Lorsqu’un grand nombre de pages utilise ou fait référence aux mêmes mots et expressions clés, il est bon de prévoir des pages d’atterrissage afin de concentrer les mots en un point et non pas de les édulcorer dans la masse du site.

Le site doit-il être responsive ?

La question majeure a se poser sur la cible utilisateur, est basée sur le type d’appareil utilisé pour naviguer sur ce site. En clair, est ce que les appareils mobiles doivent être pris en compte pour afficher le contenu ?

Cette réponse influera en grande partie sur le choix et la mise en place du template, mais dans un premier temps, au court de cette rubrique uniquement dédiée à l’aspect responsive, il y a déjà quelques éléments à prendre en considération et sur lesquels il faut se positionner.

Responsive ou non ?

Bien s’assurer qu’il s’agit d’un site web mobile et non pas d’une application web mobile
Les contenus sont-ils identiques ou différents en fonction de la plateforme ? En clair devra t-on jouer sur l’affichage / masquage de certaines zones, ou bien les contenus HTML sont-ils distincts ?
Une approche mobile first est-elle adoptée ?
Prendre en considération l’ensemble des multimédia (image, vidéo, animation…) de manière réactive
Bien s’assurer que des unités de mesures proportionnelles soient employées dans les CSS, em, rem et %

Amélioration de l’interface utilisateur ou UX Design ?

Qu’il s’agisse d’un site responsive ou non, il existe un grand nombre d’améliorations concernant l’expérience utilisateur qui doit être pris en compte.

Cette approche à la fois basée sur l’ergonomie et l’utilisabilité, doit placer l’utilisateur au cœur de ces préoccupations. Non pas une représentation de l’utilisateur sous forme de personas, mais bel et bien faire appel à de vrais utilisateurs et si possible avec de vrais rencontres présentielles et non pas au travers de visioconférences. L’intérêt est de pouvoir ainsi constater la manière de naviguer, d’accéder aux services, d’utiliser le site…. que les utilisateurs adoptent.

Plusieurs travaux sur l’utilisabilité ont été menés par l’incontournable Jacob Nielsen et son site useit, il existe également une mine d’informations sur le site usability.gov. Vous trouverez également de nombreuses sources de publications en ligne qui abordent l’UX Design de manière plus large, en incluant également l’objet plateforme de navigation. Smashing magasine réserve une rubrique entière sur le sujet, UX Magazine ou UX Booth centralisent également un grand nombre d’informations.

Attention, si le site s’oriente largement vers la distribution à destination d’appareils mobiles, de garder une réflexion qui respecte le ‘Finger-friendly design’.

Template sur mesure ou personnalisation d’un template ?

A bien y regarder, l’étape, ou du moins la prise en compte de l’affichage et du visuel, n’arrive que maintenant… c’est-à-dire bien après que le projet ait été architecturé, structuré, optimisé, réfléchi, liquéfier et rendu utilisable ….

Cela peut paraître bizarre, mais très souvent lorsque quelqu’un parle d’un site, cela se passe d’entrée de jeu autour d’une interface à la Photoshop… donc un peu comme si tout ne passait que par le visuel… et c’est parfois là l’erreur, sans être trop pessimiste.

Ne tombons donc pas dans le piège d’un site qui se veuille avant tout esthétique. L’un n’empêche pas l’autre, mais le travail de réflexion sur le contenu et son architecture passe avant, le visuel ne venant qu’au dernier moment, pour accentuer et mettre en valeur certains points de l’interface utilisateur.

L’ensemble des étapes précédentes devrait donner lieu à la mise en place d’un prototype. Chaque étape aura affiné ce prototype en utilisabilité, en ergonomie, en architecture et structure, et se sera nourri d’expérience utilisateur… bref… le prototype donnera alors les grandes lignes de ce que l’on recherche comme modèle d’affichage et de visuel. A côté du bon vieux papier stylo ou de la méthode du scrapbooking, les outils de prototypage sont nombreux et parmi les grands classiques on retrouve :

Il ne nous reste plus qu’à mettre en place le template. La principale question est alors… hem, doit-on créer un template depuis une copie blanche, doit-on récupérer un template qui répond plus ou moins à nos objectifs et l’adapter au mieux, ou doit-on partir du template de base du framework (JA-Purity pour Joomla, Twenty Ten pour WordPress… etc…) et construire le notre ?

La question trouvera réponse au cas par cas dans l’une ou l’autre des possibilités. Il existe à ces propos quelques tutoriels très intéressants sur la réalisation de templates, notamment celui de Françis Chouquet, Créez votre thème WordPress de A à Z, ou celui de Cédric Keiflin, Tutoriels pour les templates Joomla! 1.6.

Enfin, notez le tout nouvel article Create a responsive, Mobile first WordPress theme de Ellen Bauer sur Smashing.

Utilisation de plug in ou AJAX à la sauce perso !

Il se peut cependant, qu’une fonctionnalité nécessaire à notre projet de site ne trouve pas de solution tip top, parmi la panoplie généralement très étendue des plug in gravitant autour des divers frameworks. Le premier réflexe serait d’en développer un.

Si cette tâche peut s’avérer abordable pour certains, il n’en reste pas moins que le développement d’un plug in ne peut pas être pris à la légère, afin de garantir une bonne évolution dans le temps et une bonne compatibilité avec les évolutions futures du cœur du framework.

En fonction des besoins, il est parfois possible d’injecter directement du code PHP au sein d’un article, ou d’avoir recours à un bon vieux XMLHttpRequest, ou bien tout autre approche similaire s’appuyant sur jQuery, Mootools, Dojo, Prototype… etc… également injecté au sein d’un article afin d’ajouter certaines fonctionnalités de présentation ou d’interaction à nos contenus.

Afin de pouvoir interpréter ce code placé dans les articles, les frameworks proposent toujours un plug in qui prend en compte cette possibilité. Par exemple, Code Sourcerer chez Joomla ou Exec-PHP du côté de WordPress. De ce fait, il a été plus simple et plus rapide de développer le tableau de Livres et Magasines du site de Puce et Média en utilisant cette méthode, plutôt que de développer un plug in adapté.

Nature du contenu

Enfin, la dernière question concerne le remplissage du site de contenu… Le client nous a t-il fait parvenir des éléments, lui avons nous donné un accès au back-office pour que de manière simultanée et progressive du contenu soit saisi ? Ou encore, allons nous devoir faire appel à du contenu de substitution afin de rendre la maquette utilisable ?

Plusieurs alternatives sont possibles : dans le cas de texte et images de remplissage, il faut se tourner vers des images libres de droits si possible gratuites et du bon vieux Lorem Ipsum. Attention, malgré l’aspect fictif du contenu, il ne faut pas négliger les étapes d’optimisation en accessibilité, structure et référencement.

Dans le cas ou du faux texte et des fausses images devraient être utilisées… voici quelques liens qui peuvent être utiles :

Et enfin la mise en ligne

Bien que cet aspect soit traité en fin de parcours, il est préférable d’utiliser une adresse de test en ligne bien avant, afin de permettre à l’équipe de participer à distance, de faire intervenir le client pour un éventuel début de remplissage, de tester le bon fonctionnement et l’utilisabilité générale… bref d’anticiper toutes les étapes qui peuvent être longues et fastidieuses.

Il existe diverses solutions d’hébergement, qui permettent de manière gratuite de pouvoir déposer et utiliser ces contenus. Voici quelques liens qui ont retenu notre attention, et sur lesquels quelques applications sont actuellement toujours en cours de tests et d’évaluation….

Attention, certaines solutions d’hébergement gratuits nécessitent une mise à jour régulière des contenus pour éviter que les robots contrôleurs ne retirent votre site de leurs serveurs.