« La matrice Likert à 7 points conçue pour le bureau est devenue un cauchemar de scroll horizontal sur mobile, et les répondants ont tapé l'option du milieu jusqu'à la fin. » Toute personne ayant pratiqué la recherche marketing a vu une étude échouer parce que l'optimisation mobile avait été reléguée au second plan. À une époque où plus de 70% des réponses aux enquêtes web proviennent des smartphones, les équipes qui traitent l'UX mobile comme un « bonus » subissent une dégradation structurelle de la qualité de leurs données.
Cet article couvre pourquoi l'optimisation mobile est devenue obligatoire, les trois principaux schémas d'échec mobile, les principes de conception par taille d'écran, cinq principes pour réduire la charge cognitive, les différences iOS/Android et la pratique des tests, et nos lignes directrices éditoriales. Il s'agit d'une « reformulation des connaissances de conception existantes — wording, effets d'ordre, matrices — dans le contexte mobile. »
1. Pourquoi l'optimisation mobile est devenue obligatoire
Le basculement vers le mobile
Lugtig & Toepoel (2016) The Use of PCs, Smartphones, and Tablets in a Probability-Based Panel Survey a rapporté que le taux de réponse mobile dans les panels probabilistes européens a dépassé 30% au milieu des années 2010. Les années 2020 ont accéléré encore davantage cette tendance : 70–85% de part mobile pour les enquêtes B2C et 40–60% même en B2B sont désormais la valeur de référence du secteur.
Comment le mobile dégrade la qualité des données
Mavletova (2013) Data Quality in PC and Mobile Web Surveys a exécuté le même questionnaire sur PC et mobile et a démontré empiriquement :
- Taux de complétion : le mobile est inférieur de 10–15% au PC
- Temps de réponse : le mobile prend 1,5–2× plus de temps
- Straight-lining : 1,3–2× plus fréquent sur mobile
- Longueur des champs ouverts : 30–50% plus court sur mobile
La réalité est que « la même enquête renvoie des données différentes sur mobile. »
Antoun, Couper, & Conrad (2018) Effects of Mobile versus PC Web on Survey Response Quality a également démontré comment la précision du tap et les contraintes de taille d'écran propres au mobile affectent la qualité de réponse.
Donc optimisation mobile = sécurisation de la qualité des données
L'optimisation mobile n'est pas qu'une politesse UX — c'est une exigence statistique pour protéger la qualité des données. Les équipes qui la sous-estiment transforment de fait un échantillon N=1 000 en un N=700–800 réellement analysable.
2. Les trois principaux échecs spécifiques au mobile
En pratique, l'UX mobile se brise selon environ trois schémas.
Échec 1 : Enfer du scroll horizontal sur les questions matricielles
Une matrice de 5 lignes × 7 colonnes qui tient sur un écran de bureau devient un panneau à scroll horizontal sur mobile, où les libellés « Très insatisfait » et « Très satisfait » sont coupés au bord de l'écran et les répondants perdent le fil de quel côté est lequel.
→ Résultat : les répondants satisficent en choisissant l'option du milieu de manière répétée (détaillé dans l'article matrice).
Échec 2 : Abandon sur des textes de question trop longs
Sur un smartphone, un texte de question de plus de 3 lignes nécessite généralement de scroller pour être lu en entier. Toepoel et al. (2009) Design of Web Questionnaires ont montré que le temps de réponse et l'abandon sur mobile augmentent linéairement avec la longueur de la question.
→ Résultat : davantage de répondants tapent une option sans avoir lu la question dans son intégralité.
Échec 3 : Mistaps sur des cibles trop petites
Les clics PC ont une précision pixel, mais les taps smartphone sont limités par la taille du bout du doigt (environ 9–10 mm). Quand les boutons d'option font moins de 44 pt (≈11 mm), les mistaps sur les options adjacentes deviennent fréquents.
→ Résultat : la mauvaise option est enregistrée — une perte de qualité difficile à détecter et douloureuse à corriger après coup.
Les Apple Human Interface Guidelines recommandent une cible de tap minimale de 44 pt × 44 pt. Google Material Design recommande 48 dp × 48 dp.
3. Principes de conception par taille d'écran
« Smartphone » n'est pas une seule taille — les appareils réels couvrent une plage large de largeurs.
Principales tranches de largeur (à 2026)
| Tranche | Largeur (CSS px) | Appareils représentatifs | Part attendue de répondants |
|---|---|---|---|
| Petit | 320–375 px | iPhone SE / ancien Android | 5–10% |
| Standard | 376–428 px | iPhone standard / Android grand public | 60–70% |
| Grand | 429–480 px | iPhone Pro Max / grand Android | 10–15% |
| Tablette | 481–1 024 px | iPad / tablette Android | 5–10% |
| Bureau | 1 025 px et + | Bureau / portable | 15–25% |
Lignes de base minimales en conception
- Texte de question : doit tenir en 2 lignes sur iPhone SE (375 px de large)
- Matrice : 5 colonnes ou moins est le plafond pratique sur mobile
- Options : une option par ligne, au moins 44 pt de haut
- Champs de saisie : supposez que le clavier à l'écran occupe la moitié du viewport et fournissez la gestion du scroll pendant la saisie au besoin
Faire de « est-ce que ça casse sur iPhone SE ? » un check standard de revue de conception prévient environ la moitié des incidents qualité.
4. Cinq principes pour réduire la charge cognitive sur mobile
Principe 1 : Une question par écran
Mettre plusieurs questions sur un seul écran est acceptable sur bureau, mais sur mobile la règle est une question par écran. Moins de scroll, plus de concentration par question, et des taux de complétion qui se rapprochent du bureau.
Antoun et al. (2018) ont également démontré que la conception « une question par écran » minimise l'écart de qualité de données avec le bureau.
Principe 2 : Respectez la zone du pouce
Les smartphones sont typiquement utilisés à une main avec le pouce, et le tiers inférieur de l'écran est la « zone facile d'accès ».
- Bouton « Suivant » : à placer en bas de l'écran
- Commandes fréquentes : à garder à portée du pouce
- Boutons à fort impact (Envoyer, Annuler) : à placer en haut, où les mistaps sont moins probables
Principe 3 : Cibles de tap de 44 pt et plus
Recommandé à la fois par Apple HIG et Material Design. Les boutons sous 44 pt produisent des mistaps. Définissez toujours min-height: 44px sur les boutons d'option en CSS.
Principe 4 : Affichez une barre de progression
Il est plus difficile d'évaluer « combien de questions reste-t-il ? » sur mobile que sur bureau, donc rendez-le explicite avec une barre de progression. Couper et al. (2017) rapportent que l'indication de progression augmente les taux de complétion de 5–10%.
Cela dit, placez la barre de progression en haut, pas en bas (pour ne pas interférer avec les gestes de scroll).
Principe 5 : Texte de question ≤30 caractères/ligne (JA) ou ≤60 caractères/ligne (EN/FR)
Le nombre de caractères par ligne sur mobile est limité.
- Japonais : ≤30 caractères/ligne
- Anglais / Français : ≤60 caractères/ligne
Au-delà, le texte se replie sur 3–4 lignes et la lisibilité chute. Quand les questions s'allongent, divisez-les en deux (la même correction structurelle utilisée contre les questions à double sens dans l'article wording).
5. Différences iOS / Android et pratique des tests
Différences de clavier virtuel
- iOS : la touche point est difficile à faire apparaître pendant la saisie numérique
- Android : le changement de mode de saisie mélange facilement japonais et alphanumérique
→ Pour la saisie numérique, <input type="text" inputmode="decimal"> est plus confortable sur iOS que <input type="number">.
Gestes de swipe
- iOS : le swipe depuis le bord déclenche « retour »
- Android : le geste retour varie selon l'appareil
→ Être ramené à l'écran d'accueil au milieu de l'enquête peut effacer la progression. Implémentez une boîte de dialogue de confirmation ou sauvegardez automatiquement la progression.
Rendu des polices
- iOS : San Francisco (police système)
- Android : Roboto (par défaut) ou polices spécifiques au constructeur
→ Le même nombre de caractères occupe une largeur différente en pixels. Testez sur appareils réels pour les deux OS.
Sélection des appareils de test (minimum 3 modèles)
Si les tests doivent être faits avec un budget contraint, le minimum est :
- iPhone SE / standard (iOS, 375 px de large) — l'écran le plus exigeant
- iPhone Pro / Pro Max (iOS, 428 px de large) — le gros des répondants
- Android grand public (Galaxy / Pixel) — vérification de la part Android
Si votre conception tient sur ces trois-là, elle marche pour ~95% des utilisateurs.
6. Vue éditoriale — cinq lignes directrices pratiques
À partir de la littérature et de notre opération terrain, voici les cinq règles que l'équipe éditoriale ne négocie pas.
1. Repensez le nombre de questions en partant du mobile. Maintenir un taux de complétion de 80% sur une enquête PC de 30 questions n'est pas réalisable sur mobile. Le mouvement pragmatique consiste à limiter les enquêtes mobile-centric à 15–20 questions. Coupez sans pitié les questions « au cas où ». Utilisez le guide de taille d'échantillon pour faire la coupe.
2. Remplacez les questions matricielles par des questions individuelles. Les matrices sont efficaces sur PC, mais une fois que la part mobile dépasse 50%, les questions individuelles surpassent les matrices en complétion et qualité — un constat soutenu par Toepoel et al. (2009) et d'autres. Résister à l'envie de « tout regrouper en matrice » est le levier individuel le plus important pour la qualité de données à l'ère mobile.
3. Raccourcissez le texte des questions. Les questions écrites pour PC transposées sur mobile se replient fréquemment sur 3–4 lignes. Plafonnez à 30 caractères/ligne (JA) ou 60 caractères/ligne (EN/FR), et divisez en questions séparées quand les prérequis se complexifient. C'est aussi cohérent avec le principe de charge cognitive de l'article wording.
4. Définissez le bon type sur les champs de saisie.
Téléphone → inputmode="tel", email → type="email", numérique → inputmode="decimal". Bien faire ça améliore drastiquement l'UX de saisie smartphone et réduit significativement les erreurs de saisie et l'abandon qui s'ensuit. Mettez-le dans la checklist d'implémentation.
5. Faites des tests sur appareils réels sur au moins 3 modèles. Les simulateurs (Chrome DevTools et autres) ratent des problèmes que seul le matériel réel révèle — réactivité tactile, bizarreries du clavier virtuel, interférence de gestes. Testez toujours sur iPhone SE + iPhone standard + un Android grand public, au minimum. Trente minutes de tests évitent une semaine de pompiers post-lancement.
7. Fonctionnalités d'optimisation mobile de l'outil de sondage Kicue
Kicue est conçu mobile-first par défaut.
Rendu responsive
Tous les types de questions (SA / MA / matrice / échelle / ouverte) adaptent automatiquement leur layout à la taille d'écran. Il existe également une option qui convertit les matrices en format de questions individuelles sur les petits écrans.
Aperçu mobile / bureau
La fonction d'aperçu affiche instantanément les vues mobile et bureau, permettant de vérifier « est-ce que ça casse sur iPhone SE ? » avant la mise en ligne.
Taille de cible de tap par défaut
La hauteur minimale du bouton d'option est fixée au standard du secteur de 44 pt, conformément aux recommandations d'Apple HIG et de Material Design.
Barre de progression
La progression sur le total des questions est affichée en haut, donc les répondants ont toujours une perception visuelle de « combien de questions restent ».
Structure mobile recommandée
Les questions matricielles et les échelles de Likert devraient être divisées en format de questions individuelles quand la part mobile est élevée (voir articles liés).
Vérification a posteriori de la part mobile
L'export de données brutes inclut des informations d'appareil filtrables, vous pouvez donc analyser comment la part mobile se rapporte à la complétion. Réinjectez-le dans la boucle de conception de la prochaine enquête.
Choisir le bon outil — Les limites du plan gratuit, le support du branchement, les capacités IA et l'export CSV varient beaucoup entre outils. Consultez notre comparatif des outils de sondage gratuits pour trouver le bon pour cette approche.
Résumé
Une checklist de conception d'enquête mobile :
- La part mobile est de 70% et plus (référence du secteur) — l'optimisation mobile est une exigence de qualité de données.
- Trois échecs principaux : scroll horizontal des matrices / abandon sur questions longues / mistaps sur petites cibles.
- La référence de taille minimale est iPhone SE (375 px de large) — faites de « est-ce que ça casse ici ? » un check standard de revue de conception.
- Cinq principes de conception : une question par écran / zone du pouce / cibles de tap 44 pt+ / barre de progression / ≤30 caractères/ligne.
- Différences iOS / Android : validez claviers, swipes et polices sur appareils réels — minimum 3 modèles.
- Cinq éditoriales : redéfinir le nombre de questions / individualiser les matrices / raccourcir le texte / configurer correctement les input types / tester sur 3 appareils réels.
- Kicue est mobile-first par défaut — aperçu, cibles de tap 44 pt et barre de progression sont intégrés.
L'optimisation mobile n'est pas « ce serait bien d'avoir » — c'est une exigence statistique qui détermine si votre N=1 000 reste N=1 000 ou devient effectivement N=700. Dans la cohérence de la série qualité d'enquête (wording / pilote / nettoyage / agrégation / visualisation), la posture moderne consiste à traiter l'optimisation mobile comme un prérequis pour protéger la qualité des données.
Références
Académique / méthodologique
- Couper, M. P., Antoun, C., & Mavletova, A. (2017). Mobile Web Surveys: A Total Survey Error Perspective. Dans Total Survey Error in Practice. Wiley.
- Toepoel, V., Das, M., & van Soest, A. (2009). Design of Web Questionnaires: The Effects of the Number of Items per Screen. Field Methods, 21(2), 200–213.
- Antoun, C., Couper, M. P., & Conrad, F. G. (2018). Effects of Mobile versus PC Web on Survey Response Quality. Public Opinion Quarterly, 81(S1), 280–306.
- Mavletova, A. (2013). Data Quality in PC and Mobile Web Surveys. Social Science Computer Review, 31(6), 725–743.
- Lugtig, P., & Toepoel, V. (2016). The Use of PCs, Smartphones, and Tablets in a Probability-Based Panel Survey. Social Science Computer Review, 34(1), 78–94.
Organismes de standardisation / centres méthodologiques
- Apple Human Interface Guidelines: Tap Targets.
- Google Material Design: Touch Targets.
- AAPOR (American Association for Public Opinion Research): Standard Definitions.
Guides du secteur (référencés à titre d'observation terrain)
Si vous voulez lancer rapidement une enquête web optimisée pour le mobile, essayez l'outil de sondage gratuit Kicue. Rendu responsive, cibles de tap 44 pt, fonction d'aperçu et barre de progression sont de série — pour pouvoir vérifier la qualité mobile dès la phase de conception.
