Bouton UI : 6 variantes, 5 tailles et les états à ne pas oublier
Un ui button n’est pas seulement un rectangle cliquable avec un libellé. C’est un composant d’interface qui déclenche une action, guide l’utilisateur et donne du rythme à un parcours produit. Pour qu’il soit vraiment exploitable, il doit combiner un style lisible, des états prévisibles, une logique d’accessibilité et une intégration simple dans le framework ou le design system utilisé.
Que vous cherchiez une inspiration visuelle, une documentation de composant ou une base technique à réutiliser, l’objectif reste le même : obtenir un bouton cohérent, maintenable et adapté au contexte. Un bon bouton UI doit pouvoir se décliner sans repartir de zéro à chaque écran.
Ce qu’un ui button doit résoudre dans une interface
Un bouton UI sert à rendre une action identifiable : valider un formulaire, ouvrir une modale, lancer un achat, supprimer un élément, passer à l’étape suivante. Sa valeur vient autant de son apparence que de son comportement. Un bouton qui ressemble à un lien, un bouton principal utilisé partout ou un état désactivé mal signalé peut créer de l’hésitation, voire des erreurs.
Un composant, pas un simple style CSS
Dans une application moderne, le bouton est rarement codé comme un élément isolé. Il devient un button component avec des paramètres réutilisables : variante, couleur, taille, icône, état de chargement, largeur complète ou forme carrée. Cette approche évite la duplication et permet à l’équipe de faire évoluer toute l’interface depuis une base commune.
La différence est simple : un style CSS règle l’apparence d’un bouton à un instant donné, tandis qu’un composant prévoit ses usages futurs. Il peut intégrer une icône de début, une icône de fin, un avatar, un spinner de chargement ou une gestion de focus visible sans réécrire la logique à chaque fois.
La cohérence comme repère utilisateur
Un utilisateur apprend vite la grammaire visuelle d’un produit. Si le bouton principal est toujours plein, contrasté et placé au même endroit, il comprend où agir. Si les boutons secondaires utilisent un contour ou un style plus discret, il distingue naturellement les priorités. Cette cohérence réduit l’effort cognitif et rend l’interface plus fluide.
Le socle d’un bon design system doit rester stable. Avant de multiplier les effets, les arrondis ou les micro-animations, il faut définir ce qui ne bouge presque jamais : hiérarchie des actions, contrastes minimums, espacements, zones cliquables, comportement au clavier. C’est ce socle qui permet ensuite d’ajouter des variantes créatives sans fragiliser l’expérience.
Les variantes de bouton UI à connaître avant de designer
Les bibliothèques de composants avancées distinguent généralement plusieurs variantes pour couvrir différents niveaux d’importance. Dans Nuxt UI, par exemple, 6 variantes de style sont visibles : solid, outline, soft, subtle, ghost et link. Ces noms ne sont pas seulement décoratifs, ils traduisent une hiérarchie d’action.
| Variante | Usage recommandé | Risque si mal utilisée |
|---|---|---|
| solid | Action principale : enregistrer, acheter, confirmer | Trop de boutons importants sur le même écran |
| outline | Action secondaire visible mais moins prioritaire | Concurrence visuelle avec l’action principale |
| soft | Action douce, contexte informatif ou interface dense | Manque de contraste dans certains thèmes |
| subtle | Action discrète dans une barre d’outils ou une liste | Action trop peu repérable |
| ghost | Bouton minimal, souvent avec icône | Confusion avec du texte non cliquable |
| link | Navigation ou action proche d’un lien | Ambiguïté entre changement de page et action directe |
Couleurs et intention d’action
Les variantes de couleur les plus courantes suivent une logique sémantique. On retrouve notamment 7 couleurs dans certaines documentations de composants : primary, secondary, success, info, warning, error et neutral. Cette palette aide à distinguer une action positive, informative, dangereuse ou neutre.
Un bouton error pour supprimer un compte, un bouton success pour confirmer une opération ou un bouton neutral pour annuler une fenêtre rendent l’interface plus explicite. Mais la couleur ne doit jamais être le seul signal. Le libellé, l’icône, le placement et l’état doivent confirmer l’intention.
Tailles et densité d’interface
Les tailles disponibles influencent directement la lisibilité et la densité. Les 5 tailles fréquentes sont xs, sm, md, lg et xl. Un bouton xs peut convenir à une table de données ou une barre d’outils, tandis qu’un bouton lg ou xl fonctionne mieux pour un appel à l’action central sur une page marketing.
Le bon choix dépend aussi du périphérique. Sur mobile, une action trop petite devient difficile à toucher. Dans un back-office, un bouton trop grand peut alourdir l’écran. La taille doit donc accompagner le contexte, pas seulement respecter une préférence esthétique.
États indispensables : loading, disabled, active, block et square
Un ui button fiable ne se limite pas à son état normal. Il doit réagir correctement aux situations réelles : clic en cours, action indisponible, sélection active, besoin de pleine largeur ou affichage en icône seule. Ces états évitent les doubles soumissions, clarifient le statut de l’action et améliorent la perception de qualité.
Disabled et aria-disabled : deux logiques à distinguer
L’état disabled rend généralement le bouton non interactif. Il est utile quand une action n’est pas encore disponible, par exemple tant qu’un formulaire obligatoire n’est pas rempli. Mais un bouton désactivé peut aussi frustrer si l’utilisateur ne comprend pas pourquoi il ne peut pas continuer.
aria-disabled ajoute une nuance utile en accessibilité : il signale qu’un contrôle est indisponible aux technologies d’assistance, tout en permettant parfois de conserver certains comportements de focus ou d’explication selon l’implémentation. Dans une documentation de composant, il est préférable de préciser comment le bouton se comporte au clavier, au focus visible et avec un lecteur d’écran.
Loading : empêcher l’incertitude après le clic
L’état loading indique qu’une action est en cours. Il peut afficher un spinner, remplacer temporairement le libellé ou désactiver le bouton pour éviter plusieurs clics successifs. C’est particulièrement utile lors d’un paiement, d’un envoi de formulaire ou d’une sauvegarde distante.
Le bon réflexe consiste à conserver un libellé compréhensible. Un bouton qui passe simplement de “Publier” à une icône tournante peut être moins clair qu’un bouton indiquant “Publication…” ou “Enregistrement…”. L’utilisateur doit comprendre que son action a bien été prise en compte.
Active, block et square : des détails très visibles
L’état active sert à montrer une sélection en cours, par exemple dans un groupe de filtres ou une barre de navigation. Le mode block force le bouton à occuper toute la largeur disponible, pratique dans un formulaire mobile ou une carte produit. Le mode square, lui, convient aux boutons d’icône où la hauteur et la largeur doivent rester équilibrées.
Ces propriétés paraissent secondaires, mais elles évitent beaucoup de bricolage CSS. Dans un design system, mieux vaut prévoir ces comportements au niveau du composant que multiplier des exceptions locales difficiles à maintenir.
Personnalisation technique : props, slots et compound variants
Un bouton UI efficace doit rester personnalisable sans perdre sa cohérence. Les bibliothèques modernes s’appuient souvent sur des props pour choisir la variante, la taille ou la couleur, et sur des slots pour insérer un contenu plus riche. Les slots courants incluent base, label, leadingIcon, trailingIcon et leadingAvatar.
Icônes et avatars sans casser l’alignement
Un bouton avec une icône de début peut aider à reconnaître une action : télécharger, rechercher, ajouter, filtrer. Une icône de fin peut suggérer une progression, une ouverture externe ou un menu. L’intérêt des slots est de gérer automatiquement l’espacement, l’alignement vertical et les tailles relatives au lieu d’ajouter des marges manuelles à chaque usage.
Le slot leadingAvatar est plus spécifique, mais utile dans des interfaces collaboratives : assigner une tâche, inviter un membre, afficher une action liée à un profil. Dans ce cas, le composant doit prévoir une taille d’avatar cohérente avec la taille du bouton.
Compound variants : gérer les combinaisons sensibles
Les compound variants servent à définir des règles pour des combinaisons précises : par exemple une variante solid en couleur primary, une variante ghost en état désactivé ou une taille xs avec icône seule. Ils évitent les incohérences quand plusieurs paramètres interagissent.
Cette approche devient précieuse dans les grandes interfaces. Sans compound variants, chaque combinaison finit par produire des ajustements locaux. Avec eux, le design system garde une logique centralisée : mêmes transitions, mêmes classes utilitaires, mêmes comportements de focus et mêmes règles de contraste.
Choisir entre inspiration visuelle, bibliothèque UI et documentation framework
La bonne ressource dépend de votre besoin immédiat. Une galerie comme Dribbble aide à explorer des styles, des formes, des effets de survol ou des tendances visuelles. Une plateforme de composants comme uiverse peut donner des idées de boutons prêts à adapter. Une documentation comme NiceGUI ou Nuxt UI répond plutôt à une question d’implémentation : quelles props utiliser, quels états existent, comment intégrer le composant dans le projet.
- Pour un designer UI, commencer par l’inspiration visuelle, puis traduire les idées en variantes réalistes.
- Pour un développeur front-end, privilégier une documentation de composant compatible avec le framework utilisé.
- Pour une équipe produit, définir d’abord la hiérarchie des actions, puis seulement les styles.
- Pour un design system, documenter les variantes, les tailles, les couleurs, les états et les cas limites.
Si vous travaillez avec Vue ou Nuxt, une bibliothèque alignée avec cet écosystème simplifie l’intégration et la maintenance. Si votre projet repose sur Python côté interface avec NiceGUI, une documentation native sera plus pertinente. Dans tous les cas, le meilleur ui button n’est pas celui qui impressionne en capture d’écran, mais celui qui reste clair, accessible et stable dans tous les scénarios d’usage.
Avant d’adopter un composant, vérifiez donc quatre points : les 6 variantes de style nécessaires à votre hiérarchie, les 5 tailles utiles à vos écrans, les 7 couleurs sémantiques si votre produit en a besoin, et la gestion complète des états disabled, aria-disabled, loading, active, block et square. Si ces éléments sont couverts, vous disposez d’une base solide pour construire des boutons cohérents et réellement réutilisables.
