--- title: "Laissez cliquer, puis réparez l’état" locale: "fr" url: "https://irz.fr/fr/articles/let-me-click-state-repair-fr" markdown_url: "https://irz.fr/fr/articles/let-me-click-state-repair-fr.md" category: "tech" tags: ["UX", "interface", "accessibilité", "affordance", "Ilya Birman", "interaction"] published_at: "2026-08-28T09:05:00.000Z" author: "Manon Girard" translation: "https://irz.fr/en/articles/let-me-click-state-repair-en.md" --- # Laissez cliquer, puis réparez l’état Le principe « Let me click » d’Ilya Birman propose d’accepter l’intention avant de corriger les dépendances. Une bonne cible doit paraître actionnable, être atteignable et produire un état cohérent. Un contrôle peut être visible, assez grand, correctement dessiné et tout de même sembler cassé. Il suffit qu'il refuse le clic au moment précis où quelqu'un essaie de s'en servir. Ilya Birman résume ce problème par une règle : **« Let me click »**.[1](https://ilyabirman.net/meanwhile/all/let-me-click/) Il ne propose pas de rendre chaque surface interactive. Il demande surtout de ne pas transformer l'état courant en interdiction lorsqu'une intention reste valide. Si plusieurs contrôles dépendent les uns des autres, l’interface peut accepter l’action puis remettre le système dans un état cohérent. C’est une différence subtile entre **empêcher** et **réconcilier**. ## Le dernier checkbox Premier exemple de Birman : plusieurs cases définissent les canaux de notification et au moins une doit rester cochée.[1](https://ilyabirman.net/meanwhile/all/let-me-click/) La solution la plus simple consiste à désactiver la dernière case encore active. Le formulaire reste valide, au prix d'un détail gênant : l'utilisateur perd le droit d'agir dans l'ordre qu'il avait choisi. S’il souhaite désactiver « chat » avant d’activer « e-mail », l’interface lui impose l’ordre inverse. Birman déplace le problème. La dernière case peut se décocher ; juste après, le système active une option de secours.[1](https://ilyabirman.net/meanwhile/all/let-me-click/) L'invariant métier tient toujours ; seul l'ordre des gestes cesse d'être imposé. > **Accepter l’intention, réparer l’état** > Comparaison entre une interface qui bloque une action pour préserver une contrainte et une interface qui accepte l’action puis restaure automatiquement un état valide > - LA CONTRAINTE N'IMPOSE PAS L'ORDRE > - BLOQUER dernère case désactivée ordre imposé > - RÉCONCILIER accepter le clic puis restaurer un défaut > - Même invariant final, mais l'utilisateur garde la liberté de l'ordre des actions. > Le principe de Birman déplace la contrainte : elle s'applique à l'état final, pas nécessairement au geste intermédiaire. On peut lire cette mécanique comme une minuscule transaction : intention, action, puis remise en cohérence des dépendances. ## Le champ qui s’active Deuxième exemple : une case « envoyer par e-mail » et le champ d’adresse associé.[1](https://ilyabirman.net/meanwhile/all/let-me-click/) Techniquement, rien n'empêche de griser le champ tant que la case reste décochée. L'adresse n'a effectivement aucun usage si l'envoi par e-mail est coupé. Mais l’utilisateur peut vouloir saisir l’adresse d’abord. Birman garde pourtant le champ éditable. Dès qu'une adresse apparaît, l'option d'envoi s'allume toute seule.[1](https://ilyabirman.net/meanwhile/all/let-me-click/) Dans l’autre sens, décocher l’option ne doit pas effacer l’adresse. Le système modifie son propre état, pas les données saisies par la personne.[1](https://ilyabirman.net/meanwhile/all/let-me-click/) Une règle supplémentaire apparaît ici : **la correction automatique ne devrait pas être plus destructive que le geste qui l'a déclenchée**. ## Les dates impossibles Le troisième exemple déplace encore la frontière : filtrer trop tôt peut gêner autant que valider trop tard. Un sélecteur de date peut masquer « juin » lorsque le jour 31 est sélectionné, puisque le 31 juin n’existe pas. Mais si la personne veut saisir le 10 juin, elle peut parfaitement commencer par le mois.[1](https://ilyabirman.net/meanwhile/all/let-me-click/) Birman préfère laisser le choix de juin et effacer le jour incompatible. Si le jour est ensuite sélectionné en conflit avec le mois, c’est le mois qui est vidé.[1](https://ilyabirman.net/meanwhile/all/let-me-click/) La date impossible ne persiste pas, sans pour autant transformer chaque dépendance en verrou préalable. > 3 COUCHES > **Un clic fiable demande plus qu’un bouton** > - l'élément doit sembler actionnable: 1. Signifiant > - la zone doit être assez grande pour être acquise: 2. Cible > - le clic doit accepter l'intention et produire un état lisible: 3. Transition > - une seule couche manquante suffit à donner une impression de bug: Échec > Le principe Let me click travaille surtout la troisième couche : ne pas transformer une dépendance d'état en interdiction arbitraire. ## Avant le clic Le principe de Birman suppose évidemment que l’utilisateur sache où cliquer. Nielsen Norman Group distingue l’affordance de son **signifiant** : une action peut être techniquement possible sans que l’interface montre clairement où elle se trouve.[2](https://www.nngroup.com/articles/top-10-application-design-mistakes/) Dans une interface graphique, presque n’importe quel pixel peut recevoir un événement. Cela ne signifie pas que l’utilisateur doit jouer au démineur pour découvrir les zones actives.[2](https://www.nngroup.com/articles/top-10-application-design-mistakes/) Le premier contrat est visuel : ce qui promet une action doit l'exécuter, et une action importante doit se signaler sans chasse au trésor. Cette cohérence vient surtout de l'habitude. Soulignement, capsule, carte qui réagit au survol ou curseur différent finissent par fonctionner comme des promesses apprises. Casser la promesse ajoute une hésitation à chaque interaction suivante. ## La zone réelle Un signifiant impeccable ne sauve pas une cible minuscule. WCAG 2.2 demande au niveau AA une cible d’au moins **24 × 24 pixels CSS**, avec plusieurs exceptions notamment liées à l’espacement ou aux liens intégrés dans une phrase.[3](https://www.w3.org/TR/WCAG22/#target-size-minimum) Apple recommande pour ses boutons une zone d’activation d’au moins **44 × 44 points** afin de faciliter la sélection au doigt, au pointeur ou avec d’autres méthodes d’entrée.[4](https://developer.apple.com/design/human-interface-guidelines/buttons) Les deux nombres n'ont pas le même statut et ne se contredisent donc pas réellement. Ils rappellent surtout qu’un bouton possède deux tailles : **sa forme visible et sa hitbox**. Une icône visuellement petite peut donc posséder une hitbox beaucoup plus généreuse. ## Quand il faut vraiment bloquer « Let me click » n’est pas une consigne pour activer toutes les commandes en permanence. Certaines actions, elles, sont vraiment indisponibles : permission absente, ressource inexistante, opération irréversible à confirmer, service hors ligne. Dans ces cas, inventer un résultat pour satisfaire le clic serait pire que le blocage. La vraie séparation est ailleurs : **l'action est-elle impossible, ou l'état courant rend-il seulement son ordre gênant ?** Dans les trois exemples de Birman, la personne exprime une intention parfaitement valide. C’est le modèle de dépendances qui est trop rigide. Dans ce cas, l'interface peut absorber elle-même une partie de la rigidité du modèle. ## Une petite architecture Pour un développeur, la règle peut se traduire en trois tests très simples : 1. L’utilisateur peut-il identifier la zone d’action ? 2. Peut-il l’atteindre sans précision excessive ? 3. Si son intention est valide mais l’état intermédiaire ne l’est pas, le système peut-il réconcilier cet état sans détruire ses données ? Le troisième test disparaît facilement dans une maquette Figma ; c'est pourtant celui qui finit par coûter du code. Il oblige à concevoir les transitions, pas seulement les écrans. Une bonne interface ne se contente pas de montrer ce qui est permis maintenant. Elle essaie de comprendre **ce que l’utilisateur est en train d’essayer de faire**. Puis, quand elle le peut, elle le laisse cliquer. ## References 1. [Ilya Birman, Let me Click, 2026](https://ilyabirman.net/meanwhile/all/let-me-click/) 2. [Nielsen Norman Group, Top 10 Application-Design Mistakes — Hard-to-Acquire Targets](https://www.nngroup.com/articles/top-10-application-design-mistakes/) 3. [W3C, WCAG 2.2 — Success Criterion 2.5.8 Target Size (Minimum)](https://www.w3.org/TR/WCAG22/#target-size-minimum) 4. [Apple Human Interface Guidelines — Buttons](https://developer.apple.com/design/human-interface-guidelines/buttons)