Lien vs Bouton HTML - Le guide pour un code sémantique

Un lien qui prend l’apparence d’un bouton doit rester un lien dans le code, sinon l’interface devient vite fragile, moins accessible et plus difficile à faire évoluer. Je passe ici en revue le bon choix entre `` et ``, la manière propre de le styliser, puis les points qui comptent vraiment sur desktop comme sur mobile. Le bouton lien est donc moins une astuce visuelle qu’une décision de structure et d’usage.

Savoir si l’élément doit naviguer ou agir

La première question n’est pas “à quoi ça ressemble ?”, mais “que se passe-t-il quand on clique ?”. Si le clic mène vers une autre page, une autre route, un fichier, un e-mail ou une ancre dans la page, je pars sur un lien. Si le clic ouvre une fenêtre, valide un formulaire, lance un filtrage ou modifie l’état de l’interface, je prends un bouton. Cette distinction est simple, mais elle évite beaucoup d’interfaces bancales.

Je vois encore trop souvent des interfaces qui utilisent un bouton pour rediriger vers une page. Ça fonctionne techniquement, mais ça brouille les attentes de l’utilisateur et celles des technologies d’assistance. Si le comportement est une navigation, je garde le lien. Cette base posée, le vrai travail commence au niveau du rendu visuel.

Comment le coder sans tricher sur la sémantique

Le réflexe sain consiste à garder le bon élément HTML, puis à lui donner une apparence adaptée. Pour une navigation, je style un `` comme un bouton. Pour une action, je style un `` si besoin. C’est plus propre, plus lisible et bien plus durable qu’un faux bouton construit à partir d’un élément mal choisi.

Parler à un conseiller

Ouvrir le panneau

.cta-link {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  min-height: 44px;
  padding: 0.75rem 1rem;
  border-radius: 9999px;
  background: #0f172a;
  color: #fff;
  text-decoration: none;
  font-weight: 600;
  gap: 0.5rem;
  transition: transform 0.15s ease, background-color 0.15s ease;
}

.cta-link:hover {
  background: #1e293b;
}

.cta-link:focus-visible {
  outline: 3px solid #38bdf8;
  outline-offset: 3px;
}

Ce que je cherche ici, ce n’est pas juste un “effet bouton”. Je veux une cible claire, un état au survol, un état au focus, et un texte qui reste immédiatement compréhensible. Si j’ajoute une icône, je la traite comme un soutien, jamais comme un substitut au libellé. Et si l’interface est en SPA, je garde quand même `` pour la navigation réelle dès qu’il s’agit de changer de destination.

Autrement dit, le style peut mentir un peu, mais le code ne doit pas mentir du tout. Cette exigence devient encore plus importante quand on parle d’accessibilité et d’usage mobile.

Rendre le clic fiable au clavier et au toucher

Un bon composant doit être simple à atteindre, simple à comprendre et simple à activer. Sur ce point, je vérifie toujours quatre choses.

• Le focus visible doit exister. Sans `:focus-visible`, un utilisateur clavier peut se perdre dans la page.
• La taille de la cible doit rester confortable. Je vise souvent 44 × 44 CSS px quand le design le permet, et je garde en tête qu’une cible trop petite devient vite pénible sur mobile.
• Le texte du lien doit décrire la destination ou l’action. Un libellé comme “En savoir plus” peut fonctionner, mais seulement si le contexte autour est clair.
• Les liens uniquement en icône doivent avoir un nom accessible explicite, par exemple avec du texte visible ou, à défaut, un attribut adapté.

Il y a aussi un détail que beaucoup de maquettes oublient : le clavier. Un lien se valide avec `Entrée`, tandis qu’un bouton est conçu pour déclencher une action au sein de l’interface. Cette différence paraît minime, mais elle compte dès qu’on navigue sans souris ou qu’on utilise une technologie d’assistance.

Je fais également attention au contraste. Si le composant ressemble à un bouton mais qu’il repose seulement sur une nuance de bleu très pâle ou un contour trop discret, il perd sa fonction de repère. À l’inverse, si je surcharge les effets au survol, je gagne un peu de style mais je perds en lisibilité. Le bon compromis est souvent plus sobre qu’on ne l’imagine.

Quand ces bases sont solides, on peut varier les formes sans casser l’expérience. C’est justement ce que je regarde dans la section suivante.

Choisir la bonne variante visuelle selon le contexte

Toutes les interfaces n’ont pas besoin du même traitement. Dans un site éditorial, je privilégie généralement des liens visibles mais pas agressifs. Dans une page produit ou une landing page, je peux accentuer davantage l’appel à l’action. Le bon choix dépend du rôle du bloc, pas d’une tendance graphique.

Mon avis est simple : un site propre n’empile pas dix variantes différentes. Il choisit une hiérarchie claire et la répète avec discipline. Quand tout ressemble à un bouton, plus rien ne ressort. Quand tout ressemble à un lien discret, les actions importantes se noient dans le reste du contenu.

La cohérence visuelle compte donc autant que la fonction. Et c’est précisément là que les erreurs les plus fréquentes finissent par coûter du temps en maintenance.

Les erreurs qui coûtent le plus cher en maintenance

Je retrouve presque toujours les mêmes fautes, parfois dans des produits très sérieux. Elles ne cassent pas forcément l’interface le premier jour, mais elles créent une dette discrète qui s’accumule vite.

• Utiliser un bouton pour rediriger au lieu d’un lien. Le code devient trompeur et moins prévisible.
• Supprimer le `href` d’un lien pour le faire ressembler à un bouton inactif. On perd alors le comportement natif du lien.
• Compter uniquement sur la couleur pour signaler l’état actif, le survol ou le focus.
• Réduire la zone cliquable à quelques pixels autour du texte ou de l’icône.
• Oublier le nom accessible sur les liens purement iconographiques.
• Simuler un état désactivé sur un lien sans réfléchir au parcours de secours. Dans ce cas, je préfère souvent retirer le lien ou proposer une vraie alternative.

Le plus gênant, c’est que ces erreurs ne se voient pas toujours en maquette. Elles apparaissent au moment des tests clavier, des tests mobiles ou des audits d’accessibilité. C’est pour ça que je préfère décider très tôt si un composant est une navigation ou une action. Cette décision simplifie ensuite le design, le code et la validation.

Ce que je recommande pour un site éditorial ou SaaS

Si je devais résumer ma méthode en pratique, je dirais ceci : je garde `` pour tout ce qui déplace l’utilisateur, je réserve `` à tout ce qui agit dans la page, puis je donne au composant une apparence cohérente avec sa priorité. Sur un site éditorial, je reste sobre et lisible. Sur un produit SaaS, je peux renforcer l’appel à l’action, mais je ne sacrifie jamais la sémantique.

• Navigation vers une page ou une ressource : ``.
• Ouverture d’une modale, d’un menu ou d’un panneau : ``.
• Zone cliquable confortable : au moins assez large pour être touchée sans précision excessive.
• Focus visible et contraste net : indispensables, pas décoratifs.
• Un seul objectif principal par bloc : sinon la lecture se dilue.

Le meilleur résultat n’est pas celui qui “fait bouton” à tout prix, c’est celui qui reste clair pour l’utilisateur, stable pour l’équipe et cohérent avec le HTML. Quand ces trois exigences sont réunies, le composant disparaît au bon sens du terme : il ne gêne plus la lecture, il guide simplement l’action.