Design system et IA : pourquoi les composants ne suffisent pas à créer une bonne interface

Design system et IA : pourquoi les composants ne suffisent pas à créer une bonne interface

Un design system peut donner l’impression d’avoir résolu une grande partie d’un projet Web. Les couleurs sont définies, les boutons existent, les formulaires sont documentés et les équipes disposent de composants réutilisables. Pourtant, une bibliothèque bien rangée ne garantit pas à elle seule une bonne interface. Cet article ne traite ni d’un outil de chatbot ni d’une méthode générale de webdesign : il s’intéresse à la gouvernance d’un design system utilisé par des outils génératifs et des agents.

Le sujet prend une nouvelle dimension avec les outils d’intelligence artificielle capables de générer des maquettes, du code ou des variantes d’écrans. Pour produire de manière cohérente et contrôlable, ces outils peuvent s’appuyer sur des règles explicites : composants, tokens — des valeurs nommées et réutilisables pour une couleur, une taille ou un espacement —, comportements, contraintes d’accessibilité et exemples d’utilisation.

Mais un design system utilisé par une IA ne devient pas automatiquement fiable. Il faut toujours vérifier les parcours, le contenu, les erreurs, l’adaptation aux différentes tailles d’écran (responsive), l’accessibilité et la cohérence avec le besoin métier.

Un design system, ce n’est pas seulement une bibliothèque de boutons

Un design system rassemble généralement plusieurs éléments. Il ne faut pas le confondre avec un simple guide de style, une bibliothèque de composants ou un kit de code : il relie ces ressources à des règles d’usage, des décisions de conception et une documentation.

• des composants d’interface ;
• des règles de typographie, de couleurs et d’espacement ;
• des principes d’usage ;
• des modèles de pages et de parcours ;
• une documentation ;
• parfois du code directement réutilisable.

L’objectif est de ne pas recréer chaque écran depuis zéro. Une équipe peut ainsi utiliser un même champ de formulaire, un même message d’erreur ou un même bouton dans plusieurs parties d’un site ou d’une application.

Le design system sert aussi à transmettre des décisions. Il explique pourquoi un composant existe, dans quel contexte l’utiliser et quelles variantes éviter. Cette dimension est essentielle : sans règles d’usage, une collection de composants peut rapidement devenir un catalogue dans lequel chacun choisit ce qui l’arrange.

Ce que l’IA change dans la conception des interfaces

Les outils d’IA peuvent aujourd’hui, selon l’outil et sa configuration, produire une première interface à partir d’une description, convertir une maquette en code, proposer plusieurs variantes ou appliquer une modification à plusieurs composants.

Plusieurs initiatives récentes vont dans cette direction. Meta présente Astryx, annoncé en bêta, comme un design system ouvert et « AI-fluent », avec des composants présentés comme accessibles, un système de thèmes et une volonté de rendre ses règles utilisables par les personnes comme par les agents. Magic Patterns présente de son côté un agent capable d’exploiter des composants, des tokens et des règles existants pour générer ou faire évoluer des interfaces. Il s’agit de fonctionnalités revendiquées par leurs éditeurs, et non d’une évaluation indépendante de leur efficacité ou de leur maturité.

Le bénéfice attendu est compréhensible : accélérer les premiers essais, réduire les tâches répétitives et éviter que chaque projet ne reparte d’une feuille blanche. Des règles structurées peuvent aussi améliorer la cohérence, la contrôlabilité et la vérification des sorties, sans garantir à elles seules un meilleur résultat.

Pour une petite équipe, cela peut être utile lors de la création d’un site institutionnel, d’une landing page ou d’une interface métier simple. Les éléments récurrents peuvent être préparés plus vite, tandis que les personnes se concentrent davantage sur le contenu, le parcours et les décisions propres au projet.

Cependant, l’IA ne comprend pas nécessairement l’intention complète du design system. Elle peut appliquer une couleur correcte au mauvais endroit, utiliser un composant adapté à un autre contexte ou produire une succession d’écrans cohérents visuellement mais difficile à utiliser.

Un composant accessible ne rend pas tout le parcours accessible

Le GOV.UK Design System rappelle une distinction importante : disposer de composants accessibles ne suffit pas à rendre un service accessible. La recherche, la conception, l’intégration et les tests restent nécessaires.

Un champ de formulaire peut respecter les bonnes pratiques pris isolément et devenir difficile à comprendre lorsqu’il est placé dans un parcours trop dense. Un bouton peut être correctement codé, mais son libellé peut rester vague. Une navigation peut utiliser des composants conformes tout en proposant trop de choix à l’utilisateur.

L’accessibilité dépend donc aussi :

• du vocabulaire employé ;
• de la hiérarchie des informations ;
• de l’ordre des étapes ;
• des messages d’erreur ;
• de la visibilité des actions importantes ;
• de la possibilité de revenir en arrière ;
• de la compréhension du résultat obtenu.

Ces points renvoient aux critères WCAG 2.2 et, en France, au RGAA lorsque le périmètre du projet le rend applicable. Un design system facilite la cohérence, mais il ne remplace ni l’analyse du contexte réglementaire, ni l’observation des usages, ni les tests avec des personnes.

Le risque d’une interface cohérente mais inadaptée

La cohérence visuelle est utile, mais elle ne doit pas devenir le seul objectif. Une interface peut appliquer parfaitement les mêmes couleurs, les mêmes cartes et les mêmes espacements tout en répondant mal au besoin du projet.

Une application métier utilisée toute la journée n’a pas forcément les mêmes priorités qu’un site vitrine. Un parcours de commande ne se conçoit pas comme une page éditoriale. Un extranet destiné à des utilisateurs réguliers peut privilégier la rapidité et les repères, alors qu’un service public doit parfois expliquer davantage chaque étape.

Avant de demander à un outil de réutiliser des composants, il faut donc répondre à quelques questions :

• quelle tâche l’utilisateur doit-il accomplir ?
• quelles informations doit-il comprendre avant d’agir ?
• quelles erreurs sont possibles ?
• quelles actions sont réversibles ?
• quels utilisateurs reviennent régulièrement ?
• quels contenus doivent rester visibles sur mobile ?

Le design system intervient ensuite pour accélérer et fiabiliser la réalisation, pas pour décider seul de la structure du service.

Des règles lisibles par les agents, mais contrôlées par les humains

Pour être exploitable par un agent, un design system doit être plus explicite qu’une simple bibliothèque visuelle. Les règles doivent préciser :

• le nom et la fonction du composant ;
• les propriétés disponibles ;
• les variantes autorisées ;
• les contextes dans lesquels il peut être utilisé ;
• les comportements sur mobile ;
• les contraintes d’accessibilité ;
• les exemples à suivre et les erreurs à éviter.

Les tokens — par exemple une couleur, une taille de texte ou une valeur d’espacement réutilisable — peuvent faciliter les changements globaux. Mais ils doivent être associés à des règles de conception compréhensibles. Modifier une couleur principale dans tous les écrans n’est pas neutre si cette couleur sert aussi à signaler une erreur, une confirmation ou un lien.

Une évolution intéressante consiste à rendre ces règles consultables par des outils de conception et de développement. Cela peut réduire les divergences entre une maquette, le code et le site en production.

La limite reste la même que pour tout système automatisé : l’agent propose ou applique une modification, mais une personne doit pouvoir comprendre ce qui a changé, vérifier ses conséquences et revenir en arrière. Cela suppose au minimum une revue humaine, un historique des changements, un environnement de test, une validation avant mise en production et une procédure de restauration.

Comment commencer sans construire une usine à composants ?

Un design system n’a pas besoin de contenir toutes les possibilités d’un site dès le premier jour. Pour un petit projet, une démarche progressive est souvent plus adaptée.

Commencer par les éléments réellement répétés

Identifier les boutons, liens, champs, messages, titres, cartes et blocs de contenu utilisés plusieurs fois. Ne pas créer une abstraction pour un élément qui n’apparaît qu’une seule fois et dont le comportement est très particulier.

Documenter les décisions utiles

Pour chaque composant important, préciser son usage, ses variantes, ses états d’erreur et ses contraintes d’accessibilité. Une documentation courte et tenue à jour vaut mieux qu’un catalogue très complet mais difficile à consulter.

Tester les composants dans des parcours

Vérifier un composant seul ne suffit pas. L’utiliser dans une inscription, une recherche, un achat, une demande de contact ou une tâche métier permet de repérer les problèmes de rythme, de compréhension et de densité.

Prévoir la maintenance

Un design system évolue avec le site et l’application. Il faut savoir qui en est responsable, qui valide une nouvelle variante, quels droits sont accordés aux outils d’IA, comment les changements sont annoncés et comment éviter qu’une correction améliore un écran tout en en dégradant un autre. Les fichiers de conception, tokens et règles transmis à un service externe doivent aussi être compatibles avec les exigences de confidentialité du projet.

Utiliser l’IA avec un périmètre clair

L’IA peut aider à produire des variantes, à repérer des incohérences ou à appliquer une règle répétitive. Elle ne doit pas être autorisée à modifier silencieusement tous les écrans sans comparaison, validation et possibilité de retour arrière.

Un enjeu particulier pour les petits sites

Les design systems sont parfois associés aux grandes entreprises et aux produits numériques complexes. Pourtant, leurs principes peuvent aussi être utiles pour des projets plus modestes.

Pour un site vitrine ou une landing page, il ne s’agit pas de créer une plateforme complète. Quelques règles sur la typographie, les couleurs, les boutons, les formulaires et les blocs de contenu peuvent déjà faciliter les évolutions et éviter les incohérences.

Le bénéfice n’est pas seulement graphique. Une base claire peut réduire le temps nécessaire pour créer une nouvelle page, faciliter la reprise du projet par une autre personne et rendre les corrections plus prévisibles.

La limite à surveiller est le temps consacré à la préparation. Un design system trop ambitieux peut coûter plus cher que le problème qu’il cherche à résoudre. Son niveau de formalisation doit rester proportionné au nombre de pages, à la fréquence des évolutions et au nombre de personnes qui interviennent sur le projet.

Conclusion

Un design system ne remplace ni la conception UX, ni la direction artistique, ni les tests. Il organise des décisions et rend certains choix plus faciles à reproduire.

Avec l’arrivée d’outils capables de générer des maquettes et du code, cette organisation devient encore plus importante. Les agents ont besoin de composants, de règles et d’exemples pour produire quelque chose de cohérent. Mais ils peuvent aussi appliquer une règle au mauvais endroit, reproduire une erreur ou donner une impression de qualité sans vérifier l’expérience réelle.

Pour une organisation, la bonne question n’est donc pas : « Avons-nous suffisamment de composants ? » Il faut plutôt demander : « Nos règles aident-elles réellement les équipes — et les outils qui les assistent — à concevoir des parcours compréhensibles, accessibles et maintenables ? »

Sources

• GOV.UK Design System
• GOV.UK Design System — Accessibility strategy
• GOV.UK Design System — Navigate a service
• W3C — Web Content Accessibility Guidelines (WCAG) 2.2
• RGAA — Référentiel général d’amélioration de l’accessibilité
• Meta — Introducing Astryx, annonce produit en bêta
• Magic Patterns — Introducing Design System Agent