Votre site possède déjà une identité qui vous convient. Pourtant, une nouvelle page peut introduire un bouton différent, un menu moins lisible ou des cartes qui ne s’alignent plus. Un design system sert à organiser les règles et les composants partagés pour éviter ces écarts. Il ne nécessite pas de remplacer votre identité visuelle ni de refaire toutes les pages.
Pour un site de petite entreprise, le point de départ peut rester simple : les styles déjà validés, les éléments réellement répétés et une liste de contrôles avant chaque mise en ligne. L’objectif est de savoir quoi réutiliser, comment le vérifier et qui peut autoriser une modification. Aucun gain de temps ou de conversion ne peut être promis sans mesure sur votre projet.
Partir du site existant, pas d’une nouvelle palette
La charte graphique décrit l’identité et ses usages. Le design system précise comment cette identité se retrouve dans des éléments d’interface réutilisables. Le guide sur la charte graphique traite notamment des règles, modèles et fichiers à remettre. Ici, le sujet est leur application dans les pages et les interactions du site.
Choisissez d’abord des pages de référence approuvées. Relevez le header, les titres, les liens, les boutons, les listes déroulantes, les cartes et les formulaires. Pour chaque élément, notez où il apparaît, son rôle et les éventuelles différences. Une différence peut être voulue : un lien de navigation et un bouton d’envoi ne remplissent pas la même fonction.
Conservez des captures réelles de ces références, avec le navigateur, la largeur et le thème utilisés. Elles permettront de comparer les évolutions. Si une version claire et une version sombre existent, les deux doivent être documentées. Un rendu approuvé sur ordinateur ne suffit pas à définir le comportement du menu mobile.
Nommer les valeurs communes et leurs exceptions
Listez les valeurs que plusieurs composants partagent : couleurs de marque, couleurs de texte et de fond, typographies, rayons, espacements et ombres. Donnez-leur des noms qui expliquent leur usage. Le fond d’un panneau de navigation et celui d’un bouton principal peuvent avoir des règles différentes, même s’ils appartiennent à la même identité.
Les propriétés personnalisées CSS documentées par MDN permettent de définir des valeurs réutilisables et de les référencer avec la fonction var(). Leur portée et la cascade comptent : une déclaration locale peut modifier le résultat dans une partie de la page. Centraliser une valeur ne prouve donc pas, à lui seul, que tous les composants l’utilisent.
Avant de remplacer des valeurs dispersées, recherchez leurs usages et comparez le rendu obtenu. Gardez la couleur de marque validée. Si une difficulté de lisibilité apparaît dans un contexte précis, documentez cette difficulté et les options possibles avant de changer la palette. Une correction partagée ne doit pas transformer silencieusement l’esthétique de toutes les pages.
Consignez aussi les exceptions justifiées, avec leur emplacement et leur raison. Sans cette information, une personne peut supprimer une différence nécessaire ou multiplier des variantes inutiles. La règle commune doit rester identifiable, sans interdire un besoin réellement différent.
Décrire les composants utiles et leurs états
Commencez par les éléments les plus répétés plutôt que par une bibliothèque exhaustive. Une fiche de composant peut tenir en quelques points : fonction, structure, contenu attendu, variantes autorisées, états et pages concernées. Ajoutez un exemple issu du site, pas une illustration présentée comme une réalisation client.
Pour un bouton, distinguez l’action de la destination. Un lien ouvre une adresse ; un bouton déclenche une action. Le modèle de bouton du W3C décrit notamment son nom accessible et son activation au clavier avec Entrée ou Espace. Une apparence similaire ne dispense pas de choisir un comportement adapté.
Pour une liste déroulante, documentez l’ouverture, la fermeture, l’ordre des éléments et le comportement du focus. Comparez également le fond et la lisibilité lorsque le panneau recouvre du texte ou une image. Une règle de transparence identique peut produire des effets différents selon ce qui se trouve derrière.
Pour un champ, prévoyez le libellé, l’aide éventuelle, la saisie et l’erreur. Pour une carte, testez un titre long, un résumé court et une image indisponible. Ces exemples sont des scénarios de contrôle, pas des résultats clients AskOptimize. Les états nécessaires dépendent des fonctions effectivement présentes.
Vérifier les pages assemblées, pas seulement les éléments isolés
Un composant peut fonctionner seul et poser problème dans une page : texte coupé, contraste insuffisant sur un autre fond, ordre de navigation incohérent ou menu masqué. Une bibliothèque de composants ne certifie pas l’accessibilité de toutes les pages. Les contrôles doivent couvrir le contexte d’utilisation et les parcours importants.
- Comparer les références approuvées aux pages modifiées, dans les thèmes disponibles.
- Vérifier les titres, les espacements, les alignements et les contenus longs sur les largeurs retenues.
- Parcourir les éléments interactifs au clavier et repérer le focus visible.
- Contrôler les noms, les états et les messages avec les outils adaptés, puis tester les parcours.
- Vérifier les liens et les actions sans confondre un écran de confirmation avec une réception effective.
Une capture permet de constater un changement visuel, mais ne démontre pas qu’un formulaire transmet une demande ou qu’un menu fonctionne au clavier. Un test automatisé peut signaler certaines anomalies, sans remplacer toutes les vérifications manuelles. Notez ce qui a été testé, sur quel environnement et ce qui reste à contrôler.
Faire évoluer une règle sans casser les pages existantes
Avant une modification partagée, identifiez les composants et les pages touchés. Séparez le changement de contenu d’une évolution visuelle ou fonctionnelle : cela facilite la comparaison et la validation. Sauvegardez la version précédente et prévoyez comment revenir en arrière si une régression apparaît.
Appliquez la modification à un périmètre explicite, comparez les états concernés, puis vérifiez les autres usages du composant. Après publication, recontrôlez les pages publiques. Une prévisualisation locale réussie ne prouve pas que la version en ligne utilise les mêmes fichiers ou le même cache.
Les tests visuels peuvent aider à repérer des différences, mais toute différence n’est pas une erreur et toute ressemblance n’est pas une preuve de fonctionnement. La validation doit préciser le changement attendu. Gardez un historique court : raison, éléments concernés, vérifications réalisées et personne ayant validé.
Préparer une documentation que l’équipe peut reprendre
Le dossier utile rassemble les références approuvées, les valeurs communes, les composants, leurs variantes et les contrôles à effectuer. Il indique où se trouvent les fichiers maintenus et qui décide d’une évolution. Un catalogue séparé peut être pertinent si l’équipe le consulte réellement ; son installation n’est pas une condition préalable à un premier système léger.
Lors d’une création ou refonte de site vitrine, précisez au devis les éléments à formaliser, les pages de référence et la documentation remise. Les contrôles d’accessibilité, la maintenance et les ajouts futurs doivent avoir un périmètre clair. Évitez de présenter une bibliothèque comme une garantie générale de conformité ou de performance.
Pour commencer, choisissez un élément répété qui pose une difficulté concrète et documentez sa règle existante. Vérifiez ses usages avant d’en ajouter d’autres. Vous pouvez présenter votre site et les incohérences à corriger pour définir le travail nécessaire, sans engager une refonte esthétique par défaut.
