Bouton ou lien HTML : la règle sémantique que trop de développeurs ignorent encore

Le 29 juillet 2026, un débat vieux comme le web refait surface sur r/programming : quelle est la vraie différence entre un bouton et un lien en HTML ? Une question qui semble triviale, mais qui continue de produire des interfaces inaccessibles, mal indexées par Google, et pénibles à utiliser au clavier, même sur des sites professionnels récents.

Ce rappel mérite votre attention, car la confusion entre button et a href n'est pas un détail esthétique. Elle a des conséquences directes sur l'accessibilité, le référencement naturel et l'expérience clavier de vos visiteurs. On détaille la règle, les erreurs les plus fréquentes, et comment les corriger sans toucher au design.

Bouton et lien, deux rôles bien différents

La règle sémantique tient en une phrase. Un lien (<a href>) sert à naviguer : il envoie l'utilisateur vers une autre page, une autre section de la même page, un fichier à télécharger, ou une adresse email. Un bouton (<button>) sert à déclencher une action sans quitter la page : soumettre un formulaire, ouvrir une modale, filtrer une liste, incrémenter un compteur.

Cette distinction n'est pas arbitraire. Elle est définie dans la spécification HTML elle même, et elle conditionne le comportement par défaut de ces éléments dans le navigateur : focus, rôle annoncé aux technologies d'assistance, comportement au clic milieu, au Ctrl+clic, ou à l'ouverture dans un nouvel onglet.

Ce que le mauvais choix casse concrètement

Utiliser le mauvais élément n'est pas juste une entorse aux bonnes pratiques, ça casse des fonctionnalités réelles pour une partie de vos visiteurs.

• Le clavier. Un bouton s'active avec la touche Entrée et la barre d'espace. Un lien ne s'active qu'avec Entrée. Si vous simulez un bouton avec un lien ou une div, la barre d'espace ne fait plus rien, et vos utilisateurs au clavier restent bloqués.
• Les lecteurs d'écran. Un lecteur d'écran annonce "bouton" ou "lien" selon l'élément natif utilisé. Une div dotée d'un simple gestionnaire de clic, sans rôle ARIA, n'est annoncée comme rien du tout : elle reste invisible pour un utilisateur non voyant, même si elle est parfaitement cliquable à la souris.
• Le référencement. Les robots d'indexation suivent les attributs href des balises a pour découvrir vos pages. Un lien simulé en JavaScript sur un bouton ou une div est invisible pour ces robots, ce qui peut couper des pages entières de votre maillage interne.
• L'ouverture dans un nouvel onglet. Le clic milieu ou le Ctrl+clic sur un vrai lien ouvre un nouvel onglet nativement. Un faux lien géré en JavaScript ne le permet pas, sauf à recoder ce comportement à la main.

L'anti-pattern à bannir : le faux bouton en lien

Le cas le plus répandu, celui que ce rappel vise en premier lieu, c'est le lien détourné en bouton :

<a href="#" onclick="ouvrirModale(); return false;">Ouvrir</a>

Ce code fonctionne à la souris, mais il cumule les problèmes : le href="#" pollue l'historique de navigation et fait sauter la page en haut si l'annulation du comportement par défaut échoue, l'élément est mal annoncé aux lecteurs d'écran comme un lien de navigation alors qu'il déclenche une action, et il dépend entièrement du JavaScript pour ne pas casser complètement.

La correction est simple et ne change rien au design visuel :

<button type="button" onclick="ouvrirModale()">Ouvrir</button>

Le type="button" est important : sans lui, un bouton placé dans un formulaire agit par défaut comme un bouton de soumission, ce qui peut déclencher un envoi non désiré.

Comment trancher rapidement dans votre code

Une question suffit la plupart du temps : est-ce que l'URL change, ou est-ce qu'un nouvel écran devrait pouvoir s'ouvrir dans un nouvel onglet ? Si oui, c'est un lien, même s'il doit être stylé pour ressembler à un bouton avec du CSS. Si non, c'est un bouton, même s'il doit ressembler à un simple texte souligné.

Le style visuel (couleur de fond, bordure, soulignement) ne doit jamais dicter le choix de la balise. C'est l'inverse qui doit se produire : on choisit d'abord la sémantique correcte, puis on l'habille avec du CSS pour obtenir le rendu voulu. Cette règle simple évite la quasi totalité des anti-patterns rencontrés en audit.

Un enjeu légal en France aussi

Pour les sites publics français et une partie des grandes entreprises privées, l'accessibilité numérique n'est pas une option : elle est encadrée par le RGAA (Référentiel Général d'Amélioration de l'Accessibilité), qui s'appuie largement sur les mêmes règles sémantiques que celles décrites ici. Un site qui confond systématiquement boutons et liens échoue mécaniquement sur plusieurs critères d'audit RGAA liés au clavier et aux technologies d'assistance.

Pour une PME qui n'est pas soumise à cette obligation légale, le raisonnement reste valable côté SEO et taux de conversion : un site navigable au clavier et bien indexé touche plus de monde, sans coût de développement supplémentaire une fois la bonne habitude prise.

Notre lecture chez CZSyn

Dans nos audits techniques, ce type d'anti-pattern revient très régulièrement, y compris sur des sites livrés par des agences ou générés avec des frameworks modernes. La raison est souvent la même : un designer ou un développeur reproduit un composant visuel "bouton" sans se poser la question du comportement réel attendu derrière.

La bonne nouvelle, c'est que corriger ce point coûte très peu une fois identifié : changer une balise, préciser un type explicite, retirer un lien factice orphelin. C'est l'un des rares chantiers où l'effort est minime et le gain (accessibilité, SEO, expérience clavier) immédiat et cumulatif. Nous recommandons systématiquement un audit sémantique rapide à nos clients avant toute refonte, car ces détails, invisibles à l'œil nu, pèsent réellement sur le référencement et sur la part de trafic qui utilise le clavier ou un lecteur d'écran.

Sources primaires

• Discussion, « The difference between a button and a link », r/programming.
• MDN Web Docs, élément HTML « button ».
• MDN Web Docs, élément HTML « a ».
• W3C WAI-ARIA Authoring Practices Guide, patron « Button ».