Les pires anti-patterns UX et comment les corriger

La semaine dernière, j'ai essayé de modifier mes préférences de cookies sur le site d'une grande compagnie aérienne. Le bouton « Tout accepter » était d'un bleu vif, impossible à rater. Le lien « Gérer les préférences » ? Du texte gris en police 11px, planqué sous un paragraphe de jargon juridique. Quand je l'ai enfin trouvé, je suis tombé sur une page avec 47 interrupteurs individuels, tous activés par défaut, et aucun bouton « Tout refuser » à l'horizon. Je suis resté une bonne minute à cliquer sur des interrupteurs avant d'abandonner et de supprimer mes cookies à la main.

Ce n'est pas un cas isolé. C'est la norme. Une mauvaise UX n'est pas seulement agaçante, elle est hostile. Et le pire ? La plupart de ces anti-patterns ont des correctifs ultra simples, qui demandent moins de temps à implémenter que les acrobaties de dark patterns qu'ils remplacent. Je développe des applications web depuis plus de dix ans, et je suis sincèrement stupéfait qu'on continue de livrer ce genre de choses. Alors parlons des pires coupables et de la façon de les éliminer.

Les dark patterns qui traitent les utilisateurs comme des pigeons

Les dark patterns ne sont pas des accidents. Quelqu'un était assis dans une réunion, a regardé les métriques de conversion et a décidé que tromper les utilisateurs était une stratégie commerciale acceptable. C'est ce qui les rend si exaspérants : ils sont délibérés.

Confirmshaming : la culpabilisation comme élément d'interface

Vous les avez déjà vus. Une fenêtre modale s'affiche pour vous inviter à vous abonner à une newsletter. Le bouton d'acceptation dit « Oui, je veux économiser ! ». Le bouton de refus dit « Non merci, je préfère payer plein tarif ». C'est ce qu'on appelle le confirmshaming, et on le trouve partout : sites e-commerce, parcours d'onboarding SaaS, et même certains outils pour développeurs. Ça fonctionne sur un infime pourcentage d'utilisateurs et ça froisse tous les autres.

La solution est d'une simplicité embarrassante : utilisez un langage neutre pour les deux options.

<!-- BEFORE: Manipulative confirmshaming -->
<div class="modal">
<p>Join 50,000 smart developers!</p>
<button class="btn-primary">Yes, sign me up!</button>
<button class="btn-link text-sm">
No thanks, I don't care about my career
</button>
</div>
<!-- AFTER: Respectful, neutral options -->
<div class="modal">
<p>Get weekly frontend tips — no spam, unsubscribe anytime.</p>
<button class="btn-primary">Subscribe</button>
<button class="btn-secondary">No thanks</button>
</div>

Remarquez que la version après supprime aussi la preuve sociale gonflée et ajoute une promesse claire concernant le spam. Le respect inspire plus de confiance que la manipulation. Votre taux de conversion à long terme vous remerciera.

Le Roach Motel : inscription en un clic, annulation en sept étapes

S'inscrire prend 30 secondes. Annuler exige de naviguer dans Paramètres > Compte > Abonnement > Gérer le forfait > Annuler le forfait > Dites-nous pourquoi > Êtes-vous sûr > Parler au service de rétention > Annuler définitivement. Certains services exigent encore un appel téléphonique. En 2026. Pour résilier un abonnement souscrit d'un seul clic.

Je me moque de ce que disent vos métriques de rétention. Les utilisateurs piégés ne sont pas des clients fidèles : ce sont des otages qui génèrent des rétrofacturations et des avis à une étoile. Rendez l'annulation exactement aussi simple que l'inscription.

• Placez l'option d'annulation dans les paramètres du compte, là où les gens s'attendent à la trouver
• Deux étapes maximum : « Êtes-vous sûr ? » puis « Terminé, votre compte est annulé »
• Ne cachez pas le bouton d'annulation derrière un lien « Contacter le support »
• Si vous proposez une remise de rétention, très bien, mais n'en faites pas une étape obligatoire du parcours
• Envoyez un e-mail de confirmation avec un lien de réactivation plutôt que de donner l'impression que l'annulation est irréversible

Interrupteurs à bascule défaillants et contrôles d'interface confus

Petite expérience amusante : allez dans les réglages de votre téléphone et comptez combien d'interrupteurs vous ne pouvez pas identifier immédiatement comme activés ou désactivés. J'attends.

L'interrupteur ambigu est l'une des défaillances d'interface les plus courantes que je rencontre en revue de code. Un interrupteur devrait communiquer une seule chose : l'état actuel. Est-ce activé, ou désactivé ? C'est tout. Pourtant, les développeurs continuent de livrer des interrupteurs dont les deux états se ressemblent presque, ou dont le code couleur est ambigu, ou qui affichent ce qui va se passer ensuite au lieu de ce qui se passe maintenant.

/* BEFORE: Both states look nearly identical */
.toggle {
width: 48px;
height: 24px;
background: #d1d5db;
border-radius: 12px;
cursor: pointer;
}
.toggle.active {
background: #9ca3af; /* barely different from inactive */
}
/* AFTER: Unmistakable state difference + accessible */
.toggle {
width: 48px;
height: 24px;
background: #d1d5db;
border-radius: 12px;
cursor: pointer;
position: relative;
}
.toggle[aria-checked="true"] {
background: #2563eb; /* strong contrast from inactive */
}
.toggle .label {
font-size: 10px;
font-weight: 600;
color: white;
}
.toggle[aria-checked="true"] .label::after { content: "ON"; }
.toggle[aria-checked="false"] .label::after { content: "OFF"; }

Trois règles pour des interrupteurs qui ne troublent personne : des couleurs distinctes pour chaque état (avec un contraste suffisant pour les utilisateurs daltoniens), un libellé texte à l'intérieur ou à côté de l'interrupteur, et des attributs aria-checked corrects pour que les lecteurs d'écran puissent annoncer l'état. Si vous ne vous fiez qu'à la couleur, vous avez raté à la fois l'UX et l'accessibilité d'un seul coup.

Arrêtez de réinventer les contrôles de formulaire natifs

Je relis beaucoup de PR frontend, et un motif me rend fou : les listes déroulantes faites maison qui cassent la navigation au clavier. Un développeur passe deux jours à construire un menu de sélection élaboré à partir de rien, avec une flopée de div et de gestionnaires de clics. Ça a fière allure dans la démo. Puis un utilisateur essaie de parcourir un formulaire avec la touche Tab, tombe sur la liste personnalisée, et rien ne se passe. Pas de prise en charge des flèches. Pas de recherche par saisie anticipée. Incompatible avec les gestionnaires de mots de passe. Cassé sur mobile.

En revanche, l'élément natif <select> ou une bibliothèque bien testée comme Radix UI ou Headless UI gère tout cela gratuitement. L'API Popover HTML et l'élément <selectlist> bénéficient désormais d'un bon support par les navigateurs. Utilisez-les. Vos utilisateurs se moquent que votre liste déroulante ait une animation personnalisée. Ce qui compte, c'est qu'elle fonctionne.

Les anti-patterns d'accessibilité qui excluent de vrais utilisateurs

L'accessibilité n'est pas un bonus. Ce n'est pas une fonctionnalité qu'on ajoute lors d'un sprint futur. Plus d'un milliard de personnes dans le monde vivent avec une forme de handicap, et le rapport WebAIM Million constate régulièrement que plus de 96 % du million de sites les plus visités présentent des échecs WCAG détectables. Ce ne sont pas des cas marginaux obscurs : ce sont des boutons cassés, des libellés manquants et des images sans texte alternatif.

Voici ce que je vois le plus souvent :

1. Images sans texte alternatif : le lecteur d'écran annonce simplement « image » et passe à la suite
2. Ratios de contraste inférieurs à 4,5:1 : le texte devient illisible pour les malvoyants
3. Pas de navigation au clavier : si vous ne pouvez pas parcourir votre application avec Tab, les utilisateurs au clavier et ceux qui utilisent un contacteur sont bloqués
4. Pièges de focus dans les modales : l'utilisateur ouvre une boîte de dialogue et ne peut pas en sortir sans souris
5. Libellés de formulaire manquants : le lecteur d'écran ne sait pas à quoi sert un champ de saisie
6. Vidéo en lecture automatique sans bouton pause : désorientant pour les personnes souffrant de troubles vestibulaires

Le gain le plus rapide consiste à ajouter des vérifications d'accessibilité automatisées à votre pipeline CI. Elles ne détecteront pas tout (les outils automatisés trouvent peut-être 30 à 40 % des problèmes), mais elles attrapent les évidences avant la mise en production.

// BEFORE: No accessibility testing at all
test('homepage loads', async ({ page }) => {
await page.goto('/');
await expect(page.locator('h1')).toBeVisible();
});
// AFTER: Accessibility violations fail the build
import AxeBuilder from '@axe-core/playwright';
test('homepage loads and is accessible', async ({ page }) => {
await page.goto('/');
await expect(page.locator('h1')).toBeVisible();
const a11yResults = await new AxeBuilder({ page })
.withTags(['wcag2a', 'wcag2aa'])
.analyze();
expect(a11yResults.violations).toEqual([]);
});

Cinq minutes de configuration. Exécuté sur chaque PR. Détecte automatiquement les textes alternatifs manquants, les rôles ARIA cassés, les contrastes insuffisants et des dizaines d'autres échecs. Aucune excuse pour ne pas le faire.

Surcharge cognitive : la page de paramètres infernale

La mémoire de travail humaine retient environ quatre à sept éléments à la fois. Ce n'est pas une suggestion : c'est une limite cognitive stricte. Quand votre interface déverse 200 options sur une seule page sans hiérarchie, vous ne donnez pas le contrôle aux utilisateurs. Vous leur offrez une paralysie décisionnelle.

J'ai un jour compté les paramètres d'un outil de gestion de projet que nous utilisions au travail. 347 options. Une seule page. Pas de recherche. Aucun regroupement au-delà de catégories vagues comme « Général » et « Avancé ». La moitié de l'équipe n'avait jamais modifié un seul paramètre, parce que la page était si écrasante qu'ils la fermaient immédiatement.

La solution, c'est la divulgation progressive. Affichez les cinq paramètres que les gens modifient réellement. Placez tout le reste derrière des sections dépliables clairement étiquetées. Ajoutez une barre de recherche. Et pour l'amour de tout ce qui est sacré, fournissez des valeurs par défaut raisonnables pour que la plupart des utilisateurs n'aient jamais besoin de la page de paramètres.

Si votre page de paramètres a besoin de sa propre documentation, c'est elle le problème.

La surcharge de notifications habitue les utilisateurs à tout ignorer

Quand chaque événement déclenche une notification (un coéquipier a rejoint un canal, quelqu'un a réagi avec un emoji, un déploiement s'est terminé, un événement de calendrier commence dans 30 minutes), les utilisateurs apprennent à tout ignorer. Vous avez transformé votre système de notifications en bruit de fond. L'unique alerte critique qui compte vraiment ? Enfouie sous 47 notifications non lues.

La réponse, ce sont des valeurs par défaut prudentes. Les nouveaux utilisateurs ne devraient recevoir que les notifications critiques. Regroupez le reste non urgent dans un récapitulatif quotidien. Et toujours, toujours, laissez les utilisateurs désactiver ou personnaliser directement depuis la notification elle-même, et non depuis une page de préférences enfouie à trois clics de là.

Une interface lente est une interface cassée : la performance comme problème d'UX

Un bouton qui met deux secondes à réagir n'est pas lent. Il est cassé. Les utilisateurs ne pensent pas « oh, le serveur traite ma requête ». Ils pensent « mon clic a-t-il été pris en compte ? » et ils recliquent. Vous obtenez alors des soumissions en double, un état confus et un utilisateur qui ne fait plus confiance à votre application.

Au-delà de 100 ms, ça paraît lourd. Au-delà d'une seconde, l'utilisateur perd le fil de sa pensée. Pourtant, on continue de livrer des bundles JavaScript de plusieurs mégaoctets, des scripts tiers bloquant le rendu et des décalages de mise en page qui poussent les gens à cliquer sur le mauvais élément. La solution n'est pas compliquée : il suffit d'y prêter attention.

// BEFORE: User clicks, waits 2 seconds, nothing happens
async function handleLike(postId: string) {
const result = await fetch(`/api/posts/${postId}/like`, {
method: 'POST',
});
if (result.ok) {
setLikeCount(prev => prev + 1); // UI updates after network round-trip
}
}
// AFTER: Optimistic update — UI responds instantly
function handleLike(postId: string) {
// Update UI immediately
setLikeCount(prev => prev + 1);
// Sync with server in background
startTransition(async () => {
const result = await fetch(`/api/posts/${postId}/like`, {
method: 'POST',
});
if (!result.ok) {
// Rollback only on failure
setLikeCount(prev => prev - 1);
toast.error('Something went wrong. Try again.');
}
});
}

Mises à jour optimistes, écrans squelettes plutôt que spinners, JavaScript non critique chargé de façon différée, et suivi des Core Web Vitals comme de vraies métriques, pas comme des réflexions de dernière minute. Ce ne sont pas des techniques avancées. Ce sont des attentes de base.

Les anti-patterns UX mobiles qui refusent de mourir

Le mobile a sa propre catégorie de péchés UX, principalement parce que les développeurs continuent de tester sur un iPhone flambant neuf et s'en contentent.

Des cibles tactiles qui exigent une précision chirurgicale

Les recommandations d'Apple préconisent un minimum de 44x44 pixels CSS pour les cibles tactiles. WCAG 2.2 est d'accord. Pourtant, je vois encore des boutons de fermeture de 20 pixels sur les modales, des liens minuscules serrés les uns contre les autres dans les pieds de page, et des boutons-icônes presque impossibles à toucher sur un téléphone. C'est encore pire pour les utilisateurs ayant des troubles moteurs.

/* BEFORE: Tiny, frustrating touch targets */
.close-btn {
width: 20px;
height: 20px;
font-size: 12px;
}
.footer-links a {
padding: 2px 4px;
font-size: 11px;
}
/* AFTER: Actually tappable elements */
.close-btn {
min-width: 44px;
min-height: 44px;
display: flex;
align-items: center;
justify-content: center;
}
.footer-links a {
padding: 12px 8px;
font-size: 14px;
/* spacing between adjacent targets */
margin: 4px 0;
}

Les interstitiels plein écran qui bloquent le contenu

Vous tapez sur un résultat de recherche. La page se charge. Avant que vous ayez pu lire un seul mot, une modale plein écran réclame votre adresse e-mail. Vous n'avez même pas encore vu le contenu. Pourquoi vous abonneriez-vous ?

Google pénalise les interstitiels intrusifs dans le classement de recherche depuis 2017. Ils persistent parce que quelqu'un, quelque part, regarde un tableau de bord affichant un taux de capture d'e-mails de 2 % et crie victoire, tout en ignorant le taux de rebond de 40 % qu'il provoque. Utilisez plutôt des bannières intégrées ou des panneaux inférieurs. Attendez que l'utilisateur se soit réellement engagé avec votre contenu avant de lui demander quoi que ce soit. Un lecteur qui a fini trois articles s'abonnera volontiers. Un lecteur interrompu trois fois partira et ne reviendra jamais.

Comment bâtir une culture de qualité UX (et pas seulement corriger des bugs isolés)

Corriger les anti-patterns un par un est nécessaire, mais pas suffisant. Si votre processus continue d'en produire, il vous faut un meilleur processus. Voici ce qui fonctionne vraiment :

1. Ajoutez axe-core à votre pipeline CI : vérifications d'accessibilité automatisées sur chaque PR
2. Intégrez la revue UX à la revue de code, plutôt que d'en faire un processus distinct réservé au design
3. Testez avec 5 vrais utilisateurs avant de livrer les grandes fonctionnalités : 5 utilisateurs font remonter environ 85 % des problèmes d'utilisabilité
4. Suivez les taux de réussite des tâches et les taux d'erreur, pas seulement les pages vues et le temps passé sur le site
5. Utilisez un design system avec des composants accessibles préconçus, pour que chaque développeur ne résolve pas les mêmes problèmes d'interaction à partir de zéro
6. Utilisez votre propre produit sans relâche : quand le développeur qui a construit la page de paramètres doit s'en servir au quotidien, elle est corrigée très vite

La meilleure amélioration UX que j'ai jamais faite est partie de mon test du tunnel de paiement de notre propre application sur mon téléphone, et d'un message rageur envoyé à 23 h sur le canal produit.

Chaque anti-pattern de cet article a une solution directe. Aucun ne demande une technologie de pointe ni une refonte massive. Ils demandent simplement de s'en soucier vraiment. Commencez par une seule correction aujourd'hui. Lancez un audit d'accessibilité cette semaine. Testez avec un vrai utilisateur ce mois-ci. Une bonne UX ne repose pas sur de grands gestes : elle consiste à choisir systématiquement le respect de vos utilisateurs plutôt que les métriques à court terme. L'écart entre les logiciels que les gens tolèrent et ceux qu'ils adorent est plus petit qu'on ne le pense. Ce sont simplement mille petites décisions, bien prises.