s0up4200/mobile-adapt

Mobile Adapt

Objectif

Adapter les interfaces existantes pour qu'elles fonctionnent correctement sur les téléphones sans supprimer les fonctionnalités essentielles. Prioriser le web mobile de classe iPhone, sauf si l'utilisateur nomme une autre cible.

Cible par défaut

Si l'utilisateur ne spécifie pas d'appareil ou de navigateur, optimiser d'abord pour :

• iPhone Pro Max en portrait et paysage
• iOS Safari
• écrans tactiles compacts d'environ 375-440 CSS px de large
• utilisation avec clavier ouvert, texte large, zones de sécurité et mouvement réduit

Quand faire des recherches

Ce skill dépend du comportement actuel de la plateforme.

• Consulter les sources officielles lorsque l'utilisateur demande les directives les plus récentes/actuelles, un comportement spécifique à iPhone, des bizarreries Safari/WebKit, le comportement des zones de sécurité, le comportement PWA/écran d'accueil ou des citations directes.
• Privilégier Apple Developer, WebKit, W3C/WCAG, MDN, Android Developers et web.dev.
• Utiliser des dates absolues lors de la citation de changements récents de la plateforme.

Pour les règles et sources actuelles à fort signal, lire references/mobile-ui-2026.md.

Règles principales

• Garder les téléphones compacts en un seul volet. Ne pas passer à une architecture de bureau IA simplement parce qu'un téléphone en paysage dépasse un point de rupture générique. Un téléphone tourné sur le côté est toujours tenu à deux mains à bout de bras — le modèle mental de l'utilisateur est « téléphone », pas « tablette ». Passer à une disposition à plusieurs volets crée une expérience déroutante où rien n'est assez grand pour être utilisé confortablement.

• Utiliser une navigation mobile inférieure pour les sections de premier niveau uniquement. La limiter à 3-5 destinations principales ; déplacer le débordement vers Plus, une feuille ou des flux secondaires. Le bas de l'écran est la zone de repos naturelle du pouce — placer la navigation principale en bas signifie que les actions les plus courantes nécessitent le moins d'effort. Plus de 5 éléments réduisent les cibles tactiles en dessous d'une taille utilisable et submergent le balayage.

• Chaque cible interactive doit faire au moins 44x44 CSS px dans les deux dimensions. Cela inclut les éléments secondaires faciles à négliger : boutons d'action en ligne (modifier, supprimer, voir), bascules d'expansion/réduction, puces de filtre, boutons d'icône dans les barres d'outils, boutons de fermeture sur les feuilles, et lignes de cases à cocher/boutons radio (utiliser la <label> comme cible tactile complète, pas seulement l'entrée). Les écrans tactiles capacitifs enregistrent le centre de la zone de contact d'un doigt à environ 44pt — des cibles plus petites provoquent de la frustration due à des mauvaises frappes, surtout en mouvement. Classes Tailwind courantes qui sont insuffisantes : h-8 (32px), h-9 (36px), p-1 sur une icône (~24px), p-1.5 (~28px), p-2 (~32px). Utiliser h-11 (44px), min-h-[44px], ou équivalent comme base pour chaque élément cliquable. Ceci est conforme à Apple HIG et dépasse le minimum de 24px de WCAG 2.2.

• Ne pas compter sur le survol, les petites icônes tactiles ou les actions de ligne cachées. Il n'y a pas d'état de survol sur le tactile — tout ce qui nécessite le survol pour être découvert est invisible. Utiliser des contrôles visibles, des actions de balayage avec un indice visuel, ou une feuille/menu contextuel.

• Éviter le défilement horizontal de la page. L'utilisation à une main du téléphone est un défilement vertical avec le pouce. Le défilement horizontal brise le modèle spatial de l'utilisateur et cache le contenu hors écran sans aucun repère visible. Refondre, empiler, paginer ou faire défiler localement les tableaux et graphiques au lieu de la page entière.

• Utiliser viewport-fit=cover, env(safe-area-inset-*) et min-height: 100dvh. Les iPhones modernes ont des coins arrondis, le Dynamic Island et l'indicateur d'accueil — qui empiètent tous sur la fenêtre rectangulaire. Sans gestion explicite des zones de sécurité, le contenu est masqué derrière le chrome matériel. dvh tient compte de la barre d'outils Safari qui se réduit, ce que l'ancien vh ne fait pas.

• Garder les actions principales à l'écart des barres du navigateur, de l'indicateur d'accueil, des coins arrondis et du clavier à l'écran. Un bouton « Soumettre » caché derrière le clavier ou chevauchant l'indicateur d'accueil est fonctionnellement cassé — l'utilisateur ne peut ni le voir ni le toucher sans déclencher un geste système.

• Préférer un seul conteneur de défilement principal pour les flux chargés en formulaires ou en clavier. Les régions de défilement imbriquées sur iOS Safari créent un piège de défilement : le pouce de l'utilisateur fait défiler le conteneur intérieur alors qu'il avait l'intention de faire défiler la page, ou vice versa. WebKit a eu des bugs persistants ici (voir fichier de référence). Utiliser le défilement imbriqué uniquement lorsqu'il n'y a pas d'alternative.

• Utiliser des entrées mobiles sémantiques. Étiquettes au-dessus des champs (pas à côté — il n'y a pas d'espace horizontal), type, inputmode, autocomplete et enterkeyhint corrects. Ces attributs contrôlent le clavier qui apparaît — inputmode="decimal" affiche le pavé numérique pour les devises, enterkeyhint="next" permet aux utilisateurs de parcourir un formulaire sans fermer le clavier.

• Traiter le texte large comme une véritable entrée de mise en page. Les utilisateurs iOS peuvent définir un texte plus large à l'échelle du système, et beaucoup le font. Envelopper et refondre — ne pas cacher le sens clé derrière une troncature. Si une étiquette tronquée fait deviner à l'utilisateur s'il regarde « Compte d'épargne » ou « Compte de salaire », la mise en page a échoué.

• Sur les téléphones, les graphiques soutiennent l'histoire ; ils ne sont pas toute l'histoire. Un écran de téléphone peut afficher environ 5 à 6 barres lisibles ou un donut. Ce n'est pas une densité de données suffisante pour que le graphique soit explicite. Commencer par le chiffre clé et un résumé textuel ; utiliser le graphique comme renfort visuel.

• Préserver la marque et le système de conception existants du produit sauf si l'utilisateur demande une refonte plus large. L'adaptation mobile concerne la mise en page et l'interaction, pas le changement d'apparence.

Exemples

Avant de modifier une coque de navigation, un tableau de données, ou un formulaire avec un bouton de soumission, lire references/mobile-examples.md. Il contient des codes avant/après pour une barre latérale qui devient une barre d'onglets inférieure, un tableau qui devient une liste de cartes sur les téléphones, et un formulaire dont le bouton de soumission reste au-dessus du clavier.

Flux de travail

1. Verrouiller le contexte cible.
   • appareil, navigateur, orientation, contexte d'utilisation
   • par défaut iPhone Pro Max + iOS Safari si non spécifié
2. Auditer d'abord la coque.
   • mode de navigation
   • zones de sécurité
   • barres collantes/fixes
   • comportement en paysage
   • comportement du clavier
3. Auditer chaque écran ou composant.
   • listes et lignes
   • formulaires
   • tableaux
   • graphiques
   • états vides/erreur/chargement
4. Choisir la transition nette.
   • ce qui devient une seule colonne
   • ce qui devient des cartes
   • ce qui se déplace dans une feuille/tiroir
   • ce qui devient secondaire sous Plus
5. Implémenter les adaptations mobile-first.
   • préférer les requêtes de conteneur pour les composants internes
   • préférer les requêtes de fenêtre pour les changements de coque/mode de mise en page
   • ne pas conserver l'ancien comportement mi-bureau/mi-mobile sauf si explicitement requis
6. Vérifier sur compact portrait et compact paysage.
   • Safari/WebKit d'abord
   • puis Chromium
7. Signaler d'abord les problèmes les plus risqués, puis les changements concrets et les lacunes restantes.

Liste de vérification des écrans

Coque et navigation

• Garder les téléphones en paysage dans la coque du téléphone.
• Éviter les bascules dures md => barre latérale de bureau pour les appareils qui sont encore des téléphones.
• Rembourrer l'interface utilisateur inférieure avec env(safe-area-inset-bottom).
• Faire en sorte que les actions collantes soient au-dessus de la navigation inférieure.
• Garder les étiquettes mobiles courtes.

Listes et lignes

• Laisser les titres, les métadonnées et les montants s'enrouler sur deux lignes si nécessaire.
• Réserver un espace stable pour les prix, les soldes et les totaux.
• Préférer des métadonnées empilées plutôt que des métadonnées en ligne compressées.
• Exposer les actions avec des contrôles visibles ou une feuille/menu, pas le survol.
• Dimensionner les boutons d'action de ligne (modifier, supprimer, voir, développer) à au moins 44x44 CSS px — pas seulement la navigation principale et les boutons de la barre d'outils.

Formulaires

• Utiliser une seule colonne sur les téléphones compacts.
• Garder le bouton de soumission visible au-dessus du clavier.
• Utiliser un CTA principal clair en pleine largeur.
• Diviser les longs flux en étapes ou en divulgation progressive.
• Éviter type="number" pour les devises si le formatage ou la précision est important.

Tableaux et flux d'import/révision

• Convertir les tableaux denses et modifiables en cartes/listes sur les téléphones.
• Si un véritable tableau doit rester, isoler le défilement horizontal au tableau uniquement.
• Garder les en-têtes collants et les barres d'outils de masquer les entrées ciblées.

Graphiques et statistiques

• Commencer par le chiffre clé et un court récit.
• Ajouter des légendes compactes et un repli textuel.
• Préférer le défilement horizontal ou les comparaisons paginées plutôt que des barres denses illisibles.
• Éviter les minuscules camemberts/donuts sur les écrans compacts.

Vérification

Pour chaque vérification ci-dessous, confirmer la condition de réussite spécifique et utiliser l'outillage suggéré. Les tests sur appareils réels sont la référence absolue — les simulateurs sont utiles pour l'itération mais ne peuvent pas reproduire complètement le timing du clavier, l'inertie de défilement ou la précision tactile.

• Portrait et paysage — Le téléphone reste dans la coque mobile dans les deux orientations. Pas de rupture de mise en page, pas de débordement de contenu, pas de passage soudain à une barre latérale de bureau ou à une vue multi-volet. Tester à 375px (iPhone SE/mini), 390px (iPhone Pro) et 430px (iPhone Pro Max) en portrait, et leurs équivalents en paysage. Utiliser la barre d'outils d'appareil Chrome DevTools ou Xcode Simulator.

• Zones de sécurité iOS Safari — Le contenu n'est pas masqué par le Dynamic Island, les coins arrondis ou l'indicateur d'accueil. Les éléments fixés en bas ont un rembourrage visible env(safe-area-inset-bottom) (~34px sur les iPhones Face ID). Vérifier que viewport-fit=cover est défini dans la balise meta viewport — sans cela, toutes les valeurs env(safe-area-inset-*) retournent 0. Le meilleur test est dans Xcode Simulator (inserts précis par appareil) ou Polypane 26+ (navigateur de bureau avec des préréglages réels de zones de sécurité). Chrome DevTools 135+ prend en charge Emulation.setSafeAreaInsetsOverride mais nécessite une configuration manuelle.

• Flux de formulaire avec clavier ouvert — Cibler chaque entrée dans l'ordre et vérifier : (1) le champ ciblé défile dans la vue, (2) l'action de soumission est visible et cliquable, (3) les en-têtes collants n'obscurcissent pas le champ ciblé. Être conscient que les éléments position: fixed; bottom: 0 se cachent derrière le clavier iOS (la fenêtre de mise en page ne rétrécit pas), et position: sticky; bottom: 0 échoue également à rester épinglé pendant l'affichage du clavier (WebKit bug #202120). Playwright et Cypress ne peuvent pas déclencher de vrais claviers à l'écran — cela nécessite des tests sur appareils réels ou Xcode Simulator avec Safari Web Inspector.

• Texte large / zoom d'affichage — WCAG 1.4.4 (AA) exige que le texte soit redimensionnable à 200% sans perte de contenu. WCAG 1.4.10 (AA) exige le refoulement à 400% de zoom (équivalent à une fenêtre de 320px de large) sans défilement horizontal. Tester en : (1) réglant le zoom du navigateur à 200% et vérifiant qu'il n'y a pas de troncature ou de chevauchement, (2) réglant la fenêtre à 1280px et zoomant à 400% pour simuler l'exigence de refoulement à 320px, (3) activant iOS Réglages > Accessibilité > Affichage et texte > Texte plus grand au maximum. Vérifier que la balise meta viewport ne définit pas user-scalable=no ou maximum-scale en dessous de 2.0.

• Mouvement réduit — Les animations respectent prefers-reduced-motion: reduce. Les transitions communiquent toujours les changements d'état mais utilisent des fondus ou de l'opacité plutôt que du mouvement. iOS Safari ne supprime pas automatiquement les animations Web lorsque le mouvement réduit est activé — le développeur doit le gérer. Tester via : l'onglet Rendu de Chrome DevTools > « Émuler prefers-reduced-motion », les remplacements de préférences de Safari Web Inspector (disponibles depuis fin 2022), ou page.emulateMedia({ reducedMotion: 'reduce' }) de Playwright.

• États vides/erreur/chargement — Ces états s'affichent correctement sur l'écran compact. Les squelettes de chargement correspondent à la mise en page mobile, pas à celle du bureau. Les messages d'erreur sont lisibles sans défilement.

• Mode autonome/PWA (le cas échéant) — Si l'application prend en charge display: standalone, vérifier que la zone de la barre d'état, l'indicateur d'accueil et les zones de gestes sont gérés. svh et dvh se résolvent à la même valeur en mode autonome puisqu'il n'y a pas de barre d'outils pliable (WebKit bug #261185). Le bug WebKit #254868 peut entraîner des valeurs de hauteur incorrectes. Le bug WebKit #265578 provoque la mise à jour tardive de la hauteur de la fenêtre visuelle lorsque l'interface utilisateur de Safari revient en vue par animation.

• Pas de défilement horizontal du document — Balayer gauche/droite sur le corps de la page ne produit aucun mouvement. Tout défilement horizontal est isolé dans un conteneur spécifique (tableau, carrousel) avec un repère de débordement visible et overscroll-behavior: contain pour empêcher le déclenchement de changements d'interface utilisateur Safari (WebKit bug #240861). Pour une vérification automatisée dans Playwright :

  const hasOverflow = await page.evaluate(() =>
    document.documentElement.scrollWidth > document.documentElement.clientWidth
  );
  expect(hasOverflow).toBe(false);
  

Livrable

Lors de l'utilisation de ce skill, produire :

• un court plan d'adaptation mobile
• les problèmes les plus risqués en premier
• des changements concrets par écran
• la vérification effectuée
• toute incertitude restante concernant l'appareil/le navigateur