--- title: "Design et conversion : ce que l’interface décide, et ce qu’elle ne prouve pas" description: "Appliquez UXUI01–24 à la conversion : critères d’acceptation, contrôles observables et preuves requises pour abandon, uplift, compréhension et confiance." canonical: "https://www.edikka.com/insights/ux-ui-design/design-qui-convertit" author: "Bertrand Morel" publisher: "Edikka" version: "1.0" published: "2026-09-04" last_reviewed: "2026-09-04" next_review: "2026-12-04" license: "CC BY 4.0" --- # Design et conversion : ce que l’interface décide, et ce qu’elle ne prouve pas **Sections de l’article complet** - [Un design qui convertit rend une décision plus simple. Il ne prouve pas que la décision a eu lieu.](https://www.edikka.com/insights/ux-ui-design/design-qui-convertit#design-conversion-reponse-courte) - [Séparer qualité d’interface, preuve d’utilisabilité et preuve causale business.](https://www.edikka.com/insights/ux-ui-design/design-qui-convertit#design-conversion-frontiere) - [Quatre phrases familières doivent rester des hypothèses tant qu’elles ne sont pas observées.](https://www.edikka.com/insights/ux-ui-design/design-qui-convertit#design-conversion-affirmations) - [De l’observation à la décision : quatre traces, dans cet ordre.](https://www.edikka.com/insights/ux-ui-design/design-qui-convertit#design-conversion-methode) - [UXUI01–24 appliqués à la conversion : acceptation, observation et preuve.](https://www.edikka.com/insights/ux-ui-design/design-qui-convertit#application-conversion-uxui) - [Trois changements sont vérifiables publiquement sans inventer un uplift.](https://www.edikka.com/insights/ux-ui-design/design-qui-convertit#design-conversion-rejeux) - [Quand le trafic manque, améliorer la certitude avant de rechercher la significativité.](https://www.edikka.com/insights/ux-ui-design/design-qui-convertit#design-conversion-faible-trafic) - [Cette page possède les décisions d’interface ; les pages liées possèdent les questions suivantes.](https://www.edikka.com/insights/ux-ui-design/design-qui-convertit#design-conversion-frontieres) - [Télécharger, rejouer et contester l’application conversion.](https://www.edikka.com/insights/ux-ui-design/design-qui-convertit#design-conversion-ressources) - [Les sources cadrent les frontières de preuve, pas les résultats Edikka.](https://www.edikka.com/insights/ux-ui-design/design-qui-convertit#design-conversion-sources) Appliquez UXUI01–24 à la conversion : critères d’acceptation, contrôles observables et preuves requises pour abandon, uplift, compréhension et confiance. Réponse courte ## Un design qui convertit rend une décision plus simple. Il ne prouve pas que la décision a eu lieu. Une interface utile relie une intention réelle à une action compréhensible, expose les preuves nécessaires pour décider et permet de récupérer lorsqu’un état échoue. Ces propriétés peuvent être inspectées et testées. **La hausse de conversion est une affirmation distincte** : elle exige une population, un événement, un dénominateur, une fenêtre et une comparaison définis. Cette page n’ajoute donc aucune nouvelle checklist. Elle applique la [Matrice Edikka des responsabilités UX/UI](/insights/ux-ui-design/ux-vs-ui-differences) à la conversion. Les mêmes identifiants, `UXUI01` à `UXUI24`, montrent désormais ce que la conversion change dans l’acceptation et la preuve. La conversion ne crée pas une nouvelle famille de décisions UX/UI. Elle modifie leurs critères d’acceptation et augmente l’exigence de preuve. Frontière de décision ## Séparer qualité d’interface, preuve d’utilisabilité et preuve causale business. *Ce que chaque niveau autorise l’équipe à conclure* | Niveau | Question | Preuve valide | Conclusion autorisée | | --- | --- | --- | --- | | Propriété d’interface | L’action est-elle nommée, atteignable, opérable et correctement représentée ? | Interface rendue, DOM, clavier, responsive et tests d’états. | La propriété spécifiée est présente ou absente. | | Résultat de l’usage | Les personnes visées comprennent-elles et réussissent-elles la tâche ? | Test contextualisé, benchmark d’utilisabilité, entretiens ou signaux support. | Ce qui s’est produit pour les personnes, tâches et conditions testées. | | Effet business | La modification a-t-elle causé le mouvement d’une métrique ? | Expérience contrôlée ou quasi-expérience justifiée avec instrumentation fiable. | Un effet proportionné au protocole, à l’échantillon, à la période et aux garde-fous. | Une inspection peut fermer un défaut de libellé absent. Un test de tâche peut montrer que des participants récupèrent après une erreur. Aucun de ces résultats n’autorise seul « la conversion a augmenté ». Barrière de preuve · UXUI21–24 ## Quatre phrases familières doivent rester des hypothèses tant qu’elles ne sont pas observées. Les quatre dernières lignes de la matrice canonique sont le centre de cette application. Elles empêchent une description d’interface de devenir silencieusement une promesse comportementale ou commerciale. Abandon ### `UXUI21` — La personne abandonne à cause du design, du manque de confiance ou du formulaire. **Pourquoi elle reste ouverte :** Une sortie, une erreur ou une rupture peuvent être localisées si elles sont mesurées. **Preuve attendue :** Données de parcours, incidents techniques, entretiens ou tests et journal d’hypothèses. Variation de conversion ### `UXUI22` — Le nouveau design a augmenté ou diminué la conversion. **Pourquoi elle reste ouverte :** La variation temporelle et les volumes bruts peuvent être décrits ; la causalité ne se lit pas dans un avant/après seul. **Preuve attendue :** Expérience randomisée ou quasi-expérience justifiée, instrumentation contrôlée, qualité des données et résultats bruts. Compréhension ### `UXUI23` — Le message est clair, évident ou immédiatement compris. **Pourquoi elle reste ouverte :** Exactitude, grammaire et cohérence peuvent être inspectées ; la compréhension doit être observée. **Preuve attendue :** Test de compréhension ou de tâche, verbatims anonymisés, résultats par scénario et limites de l’échantillon. Confiance ### `UXUI24` — Ces logos, témoignages, couleurs ou finitions créent la confiance. **Pourquoi elle reste ouverte :** Présence, exactitude, provenance et accessibilité des signaux de preuve peuvent être inspectées. **Preuve attendue :** Protocole comparatif, réponses reliées aux éléments vus, codage, limites et éventuels comportements observés. Protocole de décision ## De l’observation à la décision : quatre traces, dans cet ordre. Observer ### Décrire l’état sans l’expliquer Consigner page, viewport, appareil, tâche, date, état visible, DOM ou événement et volumes bruts. « Le bouton porte le libellé X » est observable. « Les personnes font confiance à X » ne l’est pas. Accepter ### Écrire le seuil avant d’évaluer Nommer ce qui doit être vrai pour que la propriété ou la tâche passe, avec exceptions, accessibilité et récupération. Émettre l’hypothèse ### Conserver les causes concurrentes Trafic, offre, prix, incident technique, compréhension, confiance et mesure peuvent produire des signaux de tunnel similaires. Prouver ### Choisir la méthode la plus légère qui soutient réellement l’affirmation Inspection pour les propriétés, observation de tâche pour les résultats d’usage, comparaison contrôlée pour l’uplift causal. Conserver « non résolu » lorsque la preuve est insuffisante. Vue d’application ouverte · v1.0 ## UXUI01–24 appliqués à la conversion : acceptation, observation et preuve. Chaque volet conserve l’identifiant canonique et la responsabilité de la matrice UX/UI. Les champs ajoutés décrivent seulement ce qui change lorsque la décision est appliquée à la conversion. Les éditions HTML, JSON, XLSX et Markdown sont générées depuis les mêmes 24 lignes. Dominante UX · 4 arbitrages ### Dominante UX Le parcours, la structure ou la récupération de la tâche gouvernent l’arbitrage. #### Ordonner les étapes d’un formulaire complexe **ID :** `UXUI01` · **Responsable :** UX / interaction design — Produit, contenu, développement **Contexte conversion :** Ordonner les étapes d’une demande, d’une inscription ou d’un paiement. **Acceptation pour cet usage :** Chaque étape rapproche d’un résultat nommé et ne demande que les informations nécessaires à ce stade. **Observable publiquement :** La séquence, les regroupements, les embranchements et le nombre de champs sont inspectables. **Affirmation interdite :** Un formulaire plus court convertit mieux. **Preuve nécessaire :** Test de tâche pour la progression ; mesure de tunnel ou expérimentation contrôlée pour l’effet business. **Rejeu daté :** 04/09/2026 — vérifier qu’une demande de diagnostic distingue contexte, besoin et coordonnées sans demander une donnée avant qu’elle soit utile. #### Structurer la navigation et l’architecture de l’information **ID :** `UXUI02` · **Responsable :** UX / architecture de l’information — Contenu, SEO, produit **Contexte conversion :** Relier intention, offre, preuve et action dans l’architecture de l’information. **Acceptation pour cet usage :** Chaque objectif critique dispose d’un chemin explicite et d’un libellé cohérent d’une page à l’autre. **Observable publiquement :** Destinations, profondeur, intitulés et liens contextuels sont inspectables. **Affirmation interdite :** Une navigation simplifiée génère davantage de prospects. **Preuve nécessaire :** Test d’arborescence ou de recherche pour la trouvabilité ; données de parcours pour l’effet sur les demandes. **Rejeu daté :** 04/09/2026 — relier la page Design qui convertit à la matrice UX/UI, au CRO et à l’audit sans dupliquer leur objet. #### Prévoir la reprise après interruption **ID :** `UXUI03` · **Responsable :** UX / interaction design — Produit, contenu, développement **Contexte conversion :** Permettre de reprendre une action interrompue sans perdre les données déjà valides. **Acceptation pour cet usage :** Le point de reprise, l’état conservé et les conséquences de chaque option sont visibles avant réengagement. **Observable publiquement :** Persistance, retour, brouillon et messages de reprise peuvent être contre-testés. **Affirmation interdite :** La sauvegarde automatique réduit l’abandon. **Preuve nécessaire :** Scénario d’interruption pour la récupération ; comparaison mesurée pour l’abandon. **Rejeu daté :** 04/09/2026 — interrompre une saisie, recharger la page puis vérifier précisément ce qui est conservé et annoncé. #### Définir les règles d’un parcours conditionnel **ID :** `UXUI04` · **Responsable :** UX / interaction design — Produit, métier, développement **Contexte conversion :** Qualifier une demande sans exposer de branche inutile ni créer d’impasse. **Acceptation pour cet usage :** Chaque condition possède une entrée, une sortie et un traitement explicite des cas incomplets. **Observable publiquement :** Les branches et cas limites sont rejouables depuis une table de décision. **Affirmation interdite :** Le parcours conditionnel améliore la qualité des prospects. **Preuve nécessaire :** Tests des branches pour la logique ; statuts commerciaux comparables pour la qualité des prospects. **Rejeu daté :** 04/09/2026 — rejouer les réponses projet, budget et délai, y compris les combinaisons non prévues. Dominante UI · 6 arbitrages ### Dominante UI Le comportement est établi ; l’arbitrage porte principalement sur le système visuel et perceptif. #### Construire l’échelle typographique **ID :** `UXUI05` · **Responsable :** UI / visual design — Contenu, accessibilité, développement **Contexte conversion :** Rendre promesse, preuve, limite et action distinguables au premier balayage. **Acceptation pour cet usage :** La hiérarchie sémantique possède une traduction typographique stable, lisible et responsive. **Observable publiquement :** Tokens, tailles, graisse, interlignage, zoom et reflow sont testables. **Affirmation interdite :** Une typographie plus grande augmente la conversion. **Preuve nécessaire :** Inspection et tests WCAG pour la lisibilité technique ; test utilisateur ou expérimentation pour l’effet comportemental. **Rejeu daté :** 04/09/2026 — vérifier que le H1, les quatre affirmations à prouver et le téléchargement conservent leur ordre perceptif à 200 % de zoom. #### Définir les couleurs d’interface **ID :** `UXUI06` · **Responsable :** UI / visual design — Marque, accessibilité, développement **Contexte conversion :** Distinguer action principale, action secondaire, erreur, succès et information. **Acceptation pour cet usage :** Chaque couleur conserve un rôle stable, un contraste applicable et un signal non fondé sur la couleur seule. **Observable publiquement :** Tokens, contrastes et redondance des états sont inspectables. **Affirmation interdite :** Un bouton d’une couleur donnée convertit mieux. **Preuve nécessaire :** Mesure de contraste pour la conformité ; expérimentation contrôlée pour attribuer un effet à la couleur. **Rejeu daté :** 04/09/2026 — contrôler que téléchargement, contact, erreur et succès restent distincts en niveaux de gris. #### Fixer le rythme d’espacement et la densité **ID :** `UXUI07` · **Responsable :** UI / visual design — UX, accessibilité, développement **Contexte conversion :** Regrouper proposition, preuve et action sans fabriquer de proximité trompeuse. **Acceptation pour cet usage :** La même relation utilise le même espacement et le reflow ne sépare pas un contrôle de son contexte. **Observable publiquement :** Grille, tokens, densité, zoom et largeurs cibles sont inspectables. **Affirmation interdite :** Davantage d’espace blanc augmente la confiance ou la conversion. **Preuve nécessaire :** Inspection responsive pour la relation visuelle ; recherche ou expérience pour l’effet perçu ou business. **Rejeu daté :** 04/09/2026 — vérifier que chaque preuve reste plus proche de l’affirmation qu’elle justifie que de la suivante. #### Définir la grammaire visuelle des surfaces **ID :** `UXUI08` · **Responsable :** UI / visual design — Design system, accessibilité, développement **Contexte conversion :** Différencier contenu, démonstration, limite et zone d’action dans une page dense. **Acceptation pour cet usage :** Bordure, surface et élévation correspondent à une relation documentée et non à un effet décoratif isolé. **Observable publiquement :** Les traitements de surfaces et leurs usages sont comparables dans le design system. **Affirmation interdite :** Les cartes ou les ombres rendent l’offre plus premium. **Preuve nécessaire :** Spécimen et inspection pour la cohérence ; protocole perceptif pour une affirmation premium. **Rejeu daté :** 04/09/2026 — réserver le traitement de mise en avant aux limites de preuve et aux actions qui changent réellement l’étape. #### Créer le langage des icônes et illustrations **ID :** `UXUI09` · **Responsable :** UI / visual design — Marque, contenu, accessibilité **Contexte conversion :** Soutenir une action ou une explication sans remplacer son libellé. **Acceptation pour cet usage :** Chaque signe essentiel possède une fonction stable, un libellé ou une alternative appropriée. **Observable publiquement :** Cohérence, rôle décoratif ou informatif et alternatives sont inspectables. **Affirmation interdite :** Une illustration augmente la confiance ou l’engagement. **Preuve nécessaire :** Audit des alternatives pour l’accès ; recherche comparative pour la perception ou l’engagement. **Rejeu daté :** 04/09/2026 — vérifier qu’aucune icône seule ne porte le sens de télécharger, continuer ou ouvrir un service externe. #### Régler le mouvement d’une transition **ID :** `UXUI10` · **Responsable :** UI / motion design — UX, accessibilité, développement **Contexte conversion :** Signaler changement d’état, progression ou disponibilité sans retarder l’action. **Acceptation pour cet usage :** Le mouvement explique l’état, reste interruptible et respecte la réduction des animations. **Observable publiquement :** Durée, déclencheur, résultat et préférence de mouvement sont testables. **Affirmation interdite :** L’animation guide mieux l’utilisateur ou augmente l’engagement. **Preuve nécessaire :** Test des états et de prefers-reduced-motion ; observation utilisateur pour l’effet de guidage. **Rejeu daté :** 04/09/2026 — désactiver les animations et vérifier que l’ouverture d’un détail conserve le même état et le même sens. Responsabilité partagée · 10 arbitrages ### Responsabilité partagée Structure, contenu, comportement et présentation ne peuvent pas être décidés indépendamment. #### Concevoir un appel à l’action **ID :** `UXUI11` · **Responsable :** UX + UI — Contenu, produit, développement **Contexte conversion :** Transformer une intention en action compréhensible, atteignable et réversible si nécessaire. **Acceptation pour cet usage :** Libellé, priorité, emplacement, destination, nom accessible et états décrivent la même action. **Observable publiquement :** Texte visible, href, hiérarchie, focus et états peuvent être inspectés. **Affirmation interdite :** Ce CTA convertit, ou convertit mieux que le précédent. **Preuve nécessaire :** Test de compréhension et de tâche ; expérimentation ou comparaison contrôlée pour le gain de conversion. **Rejeu daté :** 04/09/2026 — remplacer « Checklist priorisée » par « Générer ma checklist dans ChatGPT » : l’action devient explicite, son effet reste non démontré. #### Concevoir un champ de formulaire **ID :** `UXUI12` · **Responsable :** UX + UI — Contenu, accessibilité, développement, métier **Contexte conversion :** Collecter seulement les données nécessaires à une demande ou une transaction valide. **Acceptation pour cet usage :** Chaque champ est justifié, nommé, saisissable, annoncé et compréhensible dans tous ses états. **Observable publiquement :** Nécessité déclarée, HTML, clavier, aides, validation et autocomplétion sont contrôlables. **Affirmation interdite :** Supprimer un champ augmente mécaniquement le taux de conversion. **Preuve nécessaire :** Justification métier et test accessible ; expérimentation pour l’effet du retrait sur les résultats. **Rejeu daté :** 04/09/2026 — associer chaque libellé au contrôle, indiquer les champs obligatoires et vérifier l’autocomplétion pertinente. #### Concevoir une expérience d’erreur **ID :** `UXUI13` · **Responsable :** UX + UI — UX writing, accessibilité, développement **Contexte conversion :** Permettre de corriger une erreur sans perdre les données ni deviner la solution. **Acceptation pour cet usage :** L’erreur est identifiée, associée, localisable, annoncée et corrigeable. **Observable publiquement :** Détection, message, focus, DOM, conservation et correction peuvent être contre-testés. **Affirmation interdite :** Une meilleure erreur récupère des prospects perdus. **Preuve nécessaire :** Scénarios d’échec pour la récupération ; mesure de tunnel ou expérience pour l’impact business. **Rejeu daté :** 04/09/2026 — provoquer chaque erreur serveur et client, puis vérifier le focus, le message et la conservation des valeurs valides. #### Adapter la navigation au mobile **ID :** `UXUI14` · **Responsable :** UX + UI — Contenu, accessibilité, développement **Contexte conversion :** Préserver l’accès à l’offre, à la preuve et à l’action sur petit écran. **Acceptation pour cet usage :** Toutes les destinations critiques restent visibles ou découvrables, ordonnées, annoncées et tactiles. **Observable publiquement :** Inventaire desktop/mobile, reflow, clavier, zoom et cibles tactiles sont testables. **Affirmation interdite :** L’interface mobile convertit mieux après adaptation. **Preuve nécessaire :** Tests responsive et de tâche ; analyse segmentée ou expérimentation pour l’effet sur la conversion. **Rejeu daté :** 04/09/2026 — vérifier à 390 px que le fil d’Ariane défile sans masquer l’élément courant et que l’action principale reste atteignable. #### Concevoir une modale ou un tiroir **ID :** `UXUI15` · **Responsable :** UX + UI — Accessibilité, contenu, développement **Contexte conversion :** Présenter une information ou une action interrompante seulement lorsqu’elle est nécessaire. **Acceptation pour cet usage :** Le motif du pattern, le nom, le focus, la fermeture, l’arrière-plan et la sortie sont documentés. **Observable publiquement :** Ouverture, fermeture, ordre de focus, Escape et contenu arrière sont testables. **Affirmation interdite :** Une modale ou un pop-up augmente les inscriptions. **Preuve nécessaire :** Parcours clavier et audit du pattern ; expérimentation avec garde-fous pour l’effet sur les inscriptions. **Rejeu daté :** 04/09/2026 — ouvrir puis fermer une modale au clavier et vérifier le retour du focus au déclencheur. #### Concevoir chargement, progression et état vide **ID :** `UXUI16` · **Responsable :** UX + UI — Contenu, accessibilité, développement **Contexte conversion :** Maintenir la compréhension pendant le chargement, l’attente, l’absence de résultat ou la progression. **Acceptation pour cet usage :** Chaque état décrit la réalité, conserve les actions sûres et expose un statut perceptible et programmatique. **Observable publiquement :** Délais simulés, états, annonces et actions disponibles sont testables. **Affirmation interdite :** Un indicateur de progression rassure et réduit l’abandon. **Preuve nécessaire :** Carte d’états et test d’annonce ; observation ou expérimentation pour la confiance et l’abandon. **Rejeu daté :** 04/09/2026 — simuler réponse lente, échec et résultat vide, puis comparer message visible et statut annoncé. #### Concevoir un tableau de données ou un dashboard **ID :** `UXUI17` · **Responsable :** UX + UI — Data, accessibilité, produit, développement **Contexte conversion :** Présenter métriques, comparaison ou estimation qui aide réellement une décision. **Acceptation pour cet usage :** Chaque visualisation répond à une question nommée et conserve unité, période, provenance et alternative. **Observable publiquement :** Données, unités, encodage, source et alternative tabulaire sont inspectables. **Affirmation interdite :** Un dashboard ou un estimateur augmente l’engagement ou les demandes. **Preuve nécessaire :** Contrôle des données pour l’exactitude ; test de tâche ou expérimentation pour l’effet sur la décision. **Rejeu daté :** 04/09/2026 — vérifier qu’un chiffre de conversion affiche toujours son numérateur, son dénominateur, sa période et sa source. #### Concevoir un onboarding **ID :** `UXUI18` · **Responsable :** UX + UI — Contenu, produit, recherche, développement **Contexte conversion :** Faire atteindre la première valeur utile sans imposer un parcours pédagogique superflu. **Acceptation pour cet usage :** Chaque étape répond à un besoin immédiat, peut être quittée et n’empêche pas une personne autonome d’avancer. **Observable publiquement :** Sortie, reprise, progression, étapes obligatoires et résultat sont testables. **Affirmation interdite :** Le tour guidé améliore l’activation. **Preuve nécessaire :** Scénarios novice/confirmé ; cohorte ou expérimentation pour attribuer un changement d’activation. **Rejeu daté :** 04/09/2026 — accomplir l’action principale sans lancer l’aide, puis vérifier qu’elle reste disponible au moment utile. #### Créer un composant de design system **ID :** `UXUI19` · **Responsable :** UX + UI — Contenu, accessibilité, développement, design system **Contexte conversion :** Réutiliser les mêmes contrats pour CTA, champs, erreurs, preuve et confirmation. **Acceptation pour cet usage :** Usage, non-usage, contenu, états, accessibilité et implémentation de référence sont documentés. **Observable publiquement :** Documentation, variantes, code et tests de composants sont contrôlables. **Affirmation interdite :** La cohérence du design system augmente la conversion. **Preuve nécessaire :** Audit de conformité au composant ; comparaison produit pour l’effet business. **Rejeu daté :** 04/09/2026 — comparer tous les boutons d’action et relever chaque écart de libellé, état, focus ou destination. #### Concevoir confirmation et prochaine étape **ID :** `UXUI20` · **Responsable :** UX + UI — Contenu, produit, accessibilité, développement **Contexte conversion :** Confirmer le résultat réel, fournir une trace utile et proposer une suite proportionnée. **Acceptation pour cet usage :** Le statut serveur est annoncé avant toute nouvelle sollicitation et la référence utile reste disponible. **Observable publiquement :** Réponse, confirmation, focus, référence et prochaine action sont testables. **Affirmation interdite :** Ajouter une action secondaire après confirmation augmente la valeur client. **Preuve nécessaire :** Test de fin de tâche ; données aval ou expérimentation pour l’effet commercial. **Rejeu daté :** 04/09/2026 — soumettre une demande valide et vérifier que la confirmation précède toute proposition de prochaine étape. Preuve requise · 4 arbitrages ### Preuve requise L’attribution dépend d’une cause ou d’un effet qui doit être observé plutôt que supposé. #### Expliquer un abandon dans un parcours **ID :** `UXUI21` · **Responsable :** À déterminer après observation — Recherche, data, UX, UI, produit, technique **Contexte conversion :** Expliquer pourquoi une personne quitte une étape ou ne poursuit pas. **Acceptation pour cet usage :** Le signal est décrit sans cause unique et les explications concurrentes restent visibles. **Observable publiquement :** Une sortie, une erreur ou une rupture peuvent être localisées si elles sont mesurées. **Affirmation interdite :** La personne abandonne à cause du design, du manque de confiance ou du formulaire. **Preuve nécessaire :** Données de parcours, incidents techniques, entretiens ou tests et journal d’hypothèses. **Rejeu daté :** 04/09/2026 — classer toute phrase commençant par « les visiteurs abandonnent parce que » comme hypothèse tant que la cause n’est pas observée. #### Attribuer une hausse ou baisse de conversion **ID :** `UXUI22` · **Responsable :** À déterminer par le protocole — Data, produit, recherche, UX, UI **Contexte conversion :** Attribuer une variation de demande, d’inscription, de paiement ou de qualification à une modification. **Acceptation pour cet usage :** Métrique, population, fenêtre, unité de randomisation, garde-fous et règle de décision sont fixés avant lecture du résultat. **Observable publiquement :** La variation temporelle et les volumes bruts peuvent être décrits ; la causalité ne se lit pas dans un avant/après seul. **Affirmation interdite :** Le nouveau design a augmenté ou diminué la conversion. **Preuve nécessaire :** Expérience randomisée ou quasi-expérience justifiée, instrumentation contrôlée, qualité des données et résultats bruts. **Rejeu daté :** 04/09/2026 — interdire tout pourcentage d’uplift dans un cas Edikka sans protocole, dénominateur, période et données vérifiables. #### Affirmer qu’un libellé est compris **ID :** `UXUI23` · **Responsable :** Recherche utilisateur — UX writing, UX, produit **Contexte conversion :** Affirmer qu’une promesse, une preuve, un libellé ou une prochaine étape est compris. **Acceptation pour cet usage :** Population, tâche, question de compréhension et seuil sont définis avant le test. **Observable publiquement :** Exactitude, grammaire et cohérence peuvent être inspectées ; la compréhension doit être observée. **Affirmation interdite :** Le message est clair, évident ou immédiatement compris. **Preuve nécessaire :** Test de compréhension ou de tâche, verbatims anonymisés, résultats par scénario et limites de l’échantillon. **Rejeu daté :** 04/09/2026 — « Générer ma checklist dans ChatGPT » nomme mieux l’action que « Checklist priorisée », sans autoriser à dire qu’elle est comprise. #### Affirmer qu’une interface inspire confiance ou paraît premium **ID :** `UXUI24` · **Responsable :** Recherche utilisateur — Marque, UX, UI, contenu **Contexte conversion :** Affirmer que l’interface rassure, inspire confiance, réduit le risque ou paraît premium. **Acceptation pour cet usage :** Le public, le contexte, les termes, les stimuli et les réponses attendues sont définis avant observation. **Observable publiquement :** Présence, exactitude, provenance et accessibilité des signaux de preuve peuvent être inspectées. **Affirmation interdite :** Ces logos, témoignages, couleurs ou finitions créent la confiance. **Preuve nécessaire :** Protocole comparatif, réponses reliées aux éléments vus, codage, limites et éventuels comportements observés. **Rejeu daté :** 04/09/2026 — vérifier l’existence et la source d’une preuve client, mais laisser « inspire confiance » ouvert jusqu’à une recherche dédiée. Rejeux datés · page Edikka ## Trois changements sont vérifiables publiquement sans inventer un uplift. *Observations publiques · 4 septembre 2026* | Décision | État précédent | État publié | Conclusion autorisée | Toujours non démontré | | --- | --- | --- | --- | --- | | UXUI11 / UXUI23 | « Checklist priorisée ». | « Générer ma checklist dans ChatGPT ». | Le libellé visible nomme l’action et le service externe. | Qu’il est compris ou produit davantage d’usages. | | UXUI02 | Article de règles autonome sans correspondance stable. | Chaque recommandation est rattachée à UXUI01–24 et reliée à la matrice. | La source et la responsabilité de chaque décision sont traçables. | Que les lecteurs décident plus vite ou contactent davantage Edikka. | | UXUI22 | Langage de conversion sans protocole de résultat publié. | Toute causalité est bloquée sans population, métrique, fenêtre, garde-fous et comparaison. | La règle de publication refuse un uplift non étayé. | Tout résultat de conversion Edikka. | B2B à faible trafic ## Quand le trafic manque, améliorer la certitude avant de rechercher la significativité. Un site B2B peut ne pas disposer d’assez de parcours éligibles pour une expérience fiable. Le travail ne s’arrête pas : corriger les défauts reproductibles, tester les tâches critiques avec des personnes pertinentes, examiner les signaux commerciaux et support, publier les volumes bruts et vérifier l’instrumentation. Ces actions peuvent fermer des questions d’interface ou d’utilisabilité. Elles ne transforment pas un petit échantillon en preuve causale. Un pourcentage sans numérateur, dénominateur, fenêtre et règle d’éligibilité n’est pas une décision. Le résultat correct peut rester **données insuffisantes**. Architecture éditoriale ## Cette page possède les décisions d’interface ; les pages liées possèdent les questions suivantes. ### Ne pas demander à un article de prouver tout le système. La matrice possède la responsabilité. Le CRO possède l’hypothèse et l’expérience. Le tunnel possède les dénominateurs. Le développement web possède la performance et l’implémentation. - [01Matrice UX/UIAttribuer les 24 décisions canoniques](/insights/ux-ui-design/ux-vs-ui-differences) - [02CRODiagnostiquer et tester une hypothèse de conversion](/insights/ux-ui-design/cro-ameliorer-taux-conversion) - [03TunnelDéfinir transitions et dénominateurs](/insights/strategie-digitale/tunnel-de-conversion) - [04DéveloppementPosséder performance et preuves d’implémentation](/expertise/developpement-web) Ressources ouvertes · CC BY 4.0 ## Télécharger, rejouer et contester l’application conversion. - [Application conversion UX/UI · XLSX](/docbd/data/application-conversion-uxui-edikka-v1.xlsx) — feuilles de travail, journal de décision et rejeu contradictoire. - [Application bilingue canonique · JSON](/docbd/data/application-conversion-uxui-edikka-v1.json) — 24 lignes indexées par UXUI01–24. - [Édition Markdown française](/llms/insights/design-qui-convertit.md) et [édition Markdown anglaise](/llms/insights/design-that-converts.md). - [Matrice canonique des responsabilités UX/UI · XLSX](/docbd/data/matrice-responsabilites-ux-ui-edikka-v1.xlsx) — responsabilités, acceptation et preuve sources. Pour la v1.1, cinq praticiens indépendants devront répondre ligne par ligne à une seule question : « quelle ligne est fausse, ambiguë ou impossible à décider ? » Les objections, changements acceptés et désaccords conservés seront publiés avec leur accord. Sources primaires ## Les sources cadrent les frontières de preuve, pas les résultats Edikka. - [ISO 9241-11:2018 — Usability: Definitions and concepts](https://www.iso.org/standard/63500.html) — Cadre l’efficacité, l’efficience et la satisfaction comme résultats de l’usage dans un contexte spécifié. - [W3C — Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/) — Fournit des critères testables pour perception, interaction, compréhension et robustesse. - [W3C WAI — Forms Tutorial](https://www.w3.org/WAI/tutorials/forms/) — Documente libellés, regroupements, instructions, validation, erreurs, notifications et formulaires multi-étapes. - [GOV.UK Service Manual — Measuring the success of your service](https://www.gov.uk/service-manual/measuring-success/measuring-the-success-of-your-service) — Associe métriques de performance et recherche utilisateur et recommande plusieurs sources de données. - [GOV.UK Service Manual — Usability benchmarking a website or whole service](https://www.gov.uk/service-manual/measuring-success/usability-benchmarking-a-website-or-whole-service) — Cadre les tâches, la réussite, le temps, l’abandon et la répétition d’un benchmark d’utilisabilité. - [Microsoft Research — Online Experimentation at Microsoft](https://www.microsoft.com/en-us/research/publication/online-experimentation-at-microsoft/) — Explique pourquoi randomisation et conception contrôlée sont nécessaires pour attribuer causalement un effet produit. - [Microsoft Research — Trustworthy analysis of online A/B tests](https://www.microsoft.com/en-us/research/publication/trustworthy-analysis-of-online-a-b-tests-pitfalls-challenges-and-solutions/) — Documente les hypothèses statistiques et risques qui peuvent rendre une analyse A/B trompeuse. **Limite de méthode :** cette application est une production Edikka. Elle n’est ni une norme ISO, W3C, GOV.UK ou Microsoft, ni la publication d’un uplift Edikka mesuré. Version 1.0 relue le 4 septembre 2026. Prochaine revue : 4 décembre 2026. ### Journal des modifications - **1.0 · 4 septembre 2026 :** remplacement d’un article de règles autonome par une application de la matrice UXUI01–24 ; ajout des barrières de preuve, des 24 critères contextualisés et des ressources ouvertes.