Décisions de conception pour un site qui dure

Un site qui dure se décide avant la mise en ligne : chaque ressource graphique entre avec sa licence vérifiée et son contraste mesuré, chaque page part avec ses liens testés, ses métadonnées remplies et ses images compressées. Le contrôle ne se fait pas à l’œil en fin de projet, il se fait par étapes, avec des commandes que l’on peut rejouer. C’est la condition pour qu’une page reste lisible et rapide dans deux ans, quand l’équipe aura changé.

Pour tenir ce cap, il existe des guides pratiques qui rassemblent ces décisions, par exemple les ressources de design et outils web recensées par Sites To Use, un guide en anglais qui traite du choix des icônes, des échelles typographiques, de la compression d’images et des audits de performance. On peut s’en servir comme point de départ, puis adapter chaque étape à son propre projet.

Comment choisir une ressource de design en vérifiant sa licence et sa lisibilité réelle ?

Une ressource graphique, icône, police ou illustration, s’accepte en trois temps. D’abord la licence : repérer la mention exacte, CC0, CC BY, MIT, SIL OFL, et noter ce qu’elle impose. Une CC BY exige une attribution visible, pas seulement un commentaire dans le code. Une licence propriétaire gratuite peut interdire la modification ou la revente. Ensuite la compatibilité : une police sous SIL OFL peut être embarquée dans un site, une police de bureau ne le peut pas toujours. Enfin la lisibilité réelle : afficher l’icône ou la police à la taille d’usage, sur le fond réel, avec le contraste réel.

Pour les icônes, le test se fait à 16 px et à 24 px, pas dans une planche de présentation. Une icône lisible en grand peut devenir une tache en petit. On vérifie aussi qu’elle porte un titre accessible, un 'aria-label' ou un texte visible, et qu’elle ne dépend pas uniquement de la couleur pour transmettre une information. Pour une police, on teste le texte courant, pas le titre : un paragraphe de 60 signes par ligne, à la taille de lecture, avec les chiffres, les accents et les ponctuations. Si les jambages se touchent ou si les accents se collent, la ressource est écartée, même si elle est jolie.

Un repère vérifiable : le contraste texte sur fond doit atteindre 4,5:1 pour le texte courant et 3:1 pour le grand texte, seuil publié par les WCAG du W3C. On peut le mesurer avec un contrôleur de contraste, pas à l’estime. Autre repère : la licence et la source de chaque fichier sont notées dans un fichier 'CREDITS.md' ou dans un commentaire en tête de feuille de style. Sans cette trace, une ressource devient impossible à remplacer ou à justifier plus tard.

Que faut-il contrôler avant de livrer une page : liens, métadonnées, poids d’image et Core Web Vitals ?

Avant de livrer, on passe une liste courte, dans cet ordre. Les liens : chaque lien interne et externe répond, y compris les ancres et les liens de navigation. Les métadonnées : titre, description, langue, canonical, image de partage, et données structurées si la page en a. Le poids des images : chaque image est au format adapté, avec une largeur maximale proche de son affichage réel, et un texte alternatif utile. Les Core Web Vitals : LCP, INP et CLS, mesurés sur mobile, pas seulement sur le poste de développement.

Pour les images, la décision se prend au moment de l’export. Une photo de 4000 px de large pour un affichage de 800 px est un gaspillage qui pèse sur le LCP. On exporte en AVIF ou en WebP, avec un fallback si le public cible l’exige, et on garde le JPEG d’origine dans un dossier séparé. On fixe les dimensions en HTML pour éviter le décalage de mise en page, et on charge en différé ce qui est sous la ligne de flottaison, sauf l’image principale. Un repère simple : l’image principale d’une page ne devrait pas dépasser quelques centaines de kilo-octets, et le total des images d’une page de contenu rester sous le mégaoctet.

Pour les Core Web Vitals, on mesure avec les données de terrain quand elles existent, et avec un audit local sinon. Le LCP se joue souvent sur l’image principale, la police ou un script bloquant. L’INP se joue sur les gestionnaires d’événements trop lourds. Le CLS se joue sur les images sans dimensions et les publicités insérées. On corrige d’abord ce qui est mesuré, pas ce qui est supposé. Un audit de performance n’est pas un concours de score : c’est une liste de causes classées par impact.

Pourquoi un contrôle automatisé des liens et des métadonnées vaut-il mieux qu’une relecture à l’œil ?

Une relecture à l’œil trouve ce qu’on regarde, pas ce qu’on oublie. Un lien mort dans une page ancienne, une description dupliquée, une balise 'lang' absente : ces défauts ne se voient pas à la lecture, ils se voient au test. Un script de contrôle des liens parcourt toutes les pages, suit les redirections, note les codes de réponse et signale les ancres introuvables. Un script de contrôle des métadonnées compare les titres et les descriptions, repère les doublons, les longueurs excessives et les champs vides. Ces deux scripts tournent en quelques minutes et produisent une liste, pas une impression.

L’automatisation a une limite : elle ne juge pas la pertinence d’un texte alternatif ni la qualité d’une description. Elle vérifie la présence, le format et la réponse du serveur. Le travail humain reste sur le contenu, la relecture éditoriale et les cas ambigus. La bonne répartition est celle-ci : la machine contrôle ce qui est mécanique, la personne contrôle ce qui demande du jugement. Un contrôle automatisé qui tourne à chaque publication vaut mieux qu’une relecture unique avant lancement, parce qu’il attrape les régressions, ces défauts introduits par une modification ultérieure.

Comment rendre une échelle typographique fluide et lisible ?

Une échelle typographique fluide se construit avec des valeurs relatives, pas avec des tailles fixes par point de rupture. On définit une taille de base, puis des rapports, et on interpole entre deux bornes avec 'clamp()'. Par exemple, un texte courant entre 16 px et 20 px selon la largeur de la fenêtre, un titre de section entre 24 px et 36 px. L’interpolation évite les sauts brutaux au redimensionnement et réduit le nombre de media queries à maintenir.

Trois repères de lisibilité accompagnent cette échelle. La longueur de ligne : viser entre 45 et 75 signes pour le texte courant, ce qui se règle avec une largeur maximale en 'ch' ou en 'rem'. L’interligne : autour de 1,5 pour le texte courant, un peu moins pour les titres. La hiérarchie : chaque niveau doit se distinguer par au moins deux facteurs, taille et graisse, ou taille et couleur, pour rester perceptible même en vision réduite. On teste enfin le zoom à 200 % : le texte doit rester lisible sans défilement horizontal, exigence des WCAG.

Quels gestes de maintenance gardent un site utilisable dans le temps ?

La maintenance se planifie comme une tâche, pas comme une urgence. Un contrôle mensuel des liens et des métadonnées, un contrôle trimestriel des performances sur mobile, une revue annuelle des licences et des dépendances. On note les dates dans un fichier de suivi, avec la commande exécutée et le résultat. Ce journal permet de savoir ce qui a été vérifié, quand, et par qui.

Un deuxième geste consiste à documenter les décisions : pourquoi cette police, pourquoi ce format d’image, pourquoi ce script de contrôle. Un modèle de documentation court, une page par décision, suffit. Il évite de refaire les mêmes arbitrages à chaque changement d’équipe. Un troisième geste consiste à suivre le temps passé : un audit qui prend trois heures chaque mois n’est pas tenable, un script qui prend dix minutes l’est. On calibre les contrôles pour qu’ils restent exécutables, sinon ils sont abandonnés.

Enfin, on garde une trace des ressources et de leurs licences dans le dépôt du site, à côté du code. C’est ce qui permet de remplacer une icône ou une police sans enquête, et de répondre à une question de conformité sans reconstituer l’historique. Un site qui dure n’est pas un site figé : c’est un site dont les décisions sont écrites et dont les contrôles sont rejouables.

Source vérifiée le 15 septembre 2026 : w3.org.