Responsivité mobile pour UIs générées par l'IA : un audit de mise en page

Ce qui casse généralement sur mobile (en termes simples)

Quand quelqu'un dit qu'une page n'est "pas adaptée au mobile", il veut généralement dire quelque chose de simple : elle se charge, mais elle est pénible ou impossible à utiliser sur un vrai téléphone.

Vous reconnaîtrez les symptômes :

• On peut glisser horizontalement parce que quelque chose est plus large que l'écran
• Le texte est tronqué ou se chevauche
• Les boutons et liens sont trop petits, trop proches, ou partiellement hors écran
• La mise en page saute quand les images se chargent ou quand on ouvre le clavier
• Les menus, modales ou dropdowns apparaissent au mauvais endroit et vous bloquent

Cela arrive souvent avec des prototypes générés par l'IA parce que beaucoup d'outils produisent une UI qui a l'air correcte dans un aperçu desktop, puis la maintiennent avec du CSS fragile : largeurs fixes, positionnement absolu, et espacements pixel-perfect. Ils partent aussi du principe d'une seule taille de police, d'une seule longueur de contenu et d'une seule taille de viewport. Les téléphones cassent vite ces hypothèses.

Un exemple réaliste : un écran d'onboarding utilise une mise en page à deux colonnes dans un conteneur fixe de 900px. Sur desktop c'est propre. Sur téléphone, la colonne de droite dépasse, créant un défilement horizontal. Le bouton "Continuer" se retrouve sous le pli, et le texte légal chevauche un champ parce que le clavier réduit le viewport.

Si vous voulez de la responsivité, ne redessinez pas d'abord. Auditez d'abord, puis corrigez dans cet ordre : trouvez ce qui force la page à être plus large que l'écran, supprimez le CSS qui bloque les éléments, et ce n'est qu'ensuite que vous ajustez les espacements et les cibles tactiles.

Préparez un test rapide et réaliste

Testez sur de vrais appareils quand c'est possible. Une fenêtre redimensionnable sur desktop aide, mais elle peut masquer les désagréments que créent les vrais téléphones : l'UI du navigateur qui prend de la place, le rendu des polices différent, les safe areas, et la façon dont votre pouce atteint réellement les boutons.

Choisissez 3 à 5 écrans qui représentent l'app complète (pas chaque page). Un bon premier lot : accueil/dashboard, connexion, paramètres/profil, et un écran "argent" comme paiement, upgrade ou réservation. Corriger ceux-ci rend souvent le reste plus simple.

Choisissez quelques tailles communes et tenez-vous y pour pouvoir comparer avant/après. Vous n'essayez pas de couvrir tous les appareils, juste ceux qui exposent les mauvaises décisions de mise en page :

• Petit téléphone : 360 x 800
• Grand téléphone : 390 x 844
• Téléphone grand format : 414 x 896
• Tablette : 768 x 1024
• Une taille intermédiaire issue de vos analytics (si vous en avez)

Définissez ce que signifie "bon" avant de toucher le CSS : pas de défilement horizontal, texte lisible sans zoom, boutons faciles à tapoter, et parcours clés réalisables à une main.

Règle pratique : si vous ne pouvez pas terminer la connexion et l'action principale sur un vrai téléphone en moins d'une minute, la mise en page n'est pas prête.

Trouvez les sources de débordement et du défilement horizontal

Le défilement horizontal signifie presque toujours qu'un élément est plus large que l'écran.

Reproduisez le problème dans un viewport étroit. Si vous pouvez traîner la page un peu à gauche/droite, quelque chose déborde.

Une méthode rapide pour trouver le coupable : affichez temporairement une bordure autour de tout, puis faites défiler horizontalement et voyez ce qui dépasse. Quand vous repérez la carte ou le bouton "mystère" qui dépasse, inspectez sa largeur, son padding et le contenu enfant qui pourrait forcer l'élargissement.

Les mêmes causes reviennent : largeurs fixes (comme un conteneur à 420px), images ou SVG volumineux qui ne rétrécissent pas, longues chaînes sans retour à la ligne (emails, identifiants, clés) qui ne peuvent pas se wrap, tableaux larges, et éléments positionnés en absolu qui s'étendent hors du viewport.

Le débordement se cache souvent dans des composants qui flottent au-dessus de la page. Les modales, dropdowns et toasts peuvent avoir leur propre conteneur avec des largeurs fixes, du padding supplémentaire, ou des animations qui les poussent hors écran. Une modal peut sembler centrée sur desktop mais créer du scroll horizontal sur mobile parce que son contenu interne refuse de se réduire.

Une règle qui fait gagner du temps : privilégiez des tailles flexibles avant d'ajouter plus de breakpoints. Avant de multiplier les @media, supprimez la contrainte dure qui force la mise en page à s'élargir.

Exemple : un écran d'onboarding a une modal "Vérifier le code". La modal fait 480px de large et l'input du code affiche un placeholder long. Sur un téléphone de 375px, la modal déborde. Passer la modal à max-width: 90vw et laisser le placeholder se wrapper supprime le scroll sans redessiner quoi que ce soit.

Supprimez le CSS fragile qui force la casse

La plupart des échecs mobiles dans des frontends générés par l'IA viennent de CSS qui suppose une seule taille d'écran. Les gains les plus rapides viennent généralement de la suppression de ces hypothèses.

Recherchez les largeurs et hauteurs fixes qui "ont l'air correctes" sur desktop mais qui ne peuvent pas rétrécir. Coupables fréquents : width: 1200px, min-width: 900px, height: 100vh sur des conteneurs qui devraient s'étendre, et inputs/boutons avec des tailles codées en dur. Si une carte doit avoir une certaine largeur, elle poussera tout le reste en défilement horizontal.

Autre problème fréquent : wrapper sur wrapper. Les outils IA empilent souvent des conteneurs qui ajoutent chacun padding, max-width et centrage. Trois wrappers avec 24px de padding chacun peuvent voler beaucoup d'espace utilisable sur un petit téléphone.

Si vous voyez des patterns comme un positionnement absolu pour l'alignement, des "nombres magiques" comme left: 37px, des margins négatives pour ajuster, ou des règles globales comme white-space: nowrap, considérez-les suspects. Remplacez-les par des règles flexibles : max-width: 100% au lieu de largeurs fixes, height: auto quand c'est possible, et gap plutôt que des empilements de margins manuels.

Exemple : un écran d'onboarding où le bouton "Continuer" est positionné absolument en bas d'une carte. Sur un petit appareil, l'ouverture du clavier fait chevaucher le bouton avec le formulaire. Passer la carte en colonne flex et pousser le bouton avec margin-top: auto le maintient en place sans chevauchement.

Faites évoluer les mises en page avec flexbox et grid

Le code UI généré par l'IA fonctionne souvent seulement parce que le contenu d'exemple a la longueur parfaite. Sur un vrai téléphone, le texte est plus long, les boutons se wrap, et la mise en page s'effondre en chevauchement ou défilement horizontal.

Une règle simple aide : utilisez flexbox pour une mise en page unidimensionnelle (ligne ou colonne) et grid pour une mise en page bidimensionnelle (lignes et colonnes qui doivent s'aligner). Forcer tout avec un seul outil rend généralement le code fragile.

Utilisez flexbox pour les barres de navigation, toolbars, rangées de boutons, et lignes "icône + texte + action". Utilisez grid pour les galeries de cartes, pages de paramètres avec labels/valeurs, et dashboards où les colonnes doivent s'aligner entre les lignes.

Deux choix CSS font la plupart du travail sur du contenu réel : autoriser le wrapping et permettre au texte de rétrécir sans casser la ligne.

/* Card rows that wrap without odd gaps */
.cards {
  display: flex;
  flex-wrap: wrap;
  gap: 12px;
}
.card { flex: 1 1 260px; }

/* Grid that adapts to screen size */
.grid {
  display: grid;
  gap: 12px;
  grid-template-columns: repeat(auto-fit, minmax(220px, 1fr));
}

/* Mixed content row: icon + long title + button */
.row { display: flex; align-items: center; gap: 8px; }
.title { min-width: 0; flex: 1; }
.action { flex: 0 0 auto; }

Exemple concret : un écran d'onboarding a un nom de plan long et un bouton "Continuer". Si le titre ne peut pas rétrécir, il pousse le bouton hors écran. Mettre min-width: 0 sur le titre et laisser le bouton flex: 0 0 auto empêche le débordement sans redessiner.

Améliorez la lisibilité et les cibles tactiles sans tout redesign

La plupart des douleurs mobiles ne viennent pas d'un gros problème de mise en page. Ce sont du texte trop petit, des espacements qui s'écrasent, et des contrôles difficiles à atteindre avec le pouce.

Commencez par quelques valeurs par défaut ennuyeuses qui calment chaque écran : 16px pour le texte du corps avec un interligne de 1.4 à 1.6, des titres réduits pour ne pas dominer, et un padding cohérent sur les conteneurs de page (souvent 16px) pour que le contenu ne colle pas aux bords.

Les cibles tactiles sont le gain suivant. Beaucoup d'UIs générées par l'IA affichent de jolis boutons qui sont physiquement minuscules sur un téléphone. Visez au moins 44x44px pour les cibles interactives, gardez 8 à 12px entre actions séparées, et ajoutez du padding aux liens textuels pour qu'ils soient tapables. Assurez-vous aussi que les styles de focus restent visibles et ne soient pas rognés.

Les formulaires ratent plus souvent que les pages de destination. Gardez les labels proches des inputs, évitez les rangées de formulaires en deux colonnes sur petits écrans à moins qu'elles tiennent véritablement, et faites les inputs en pleine largeur sur mobile. Réservez de l'espace pour les messages d'erreur afin que la page ne saute pas quand la validation apparaît.

Les sauts de mise en page viennent souvent des toasts, bannières et validations inline. Si des messages apparaissent/disparaissent, essayez de garder une hauteur cohérente, ou utilisez une zone superposée pour que le contenu ne bouge pas.

Exemple : un écran d'onboarding avec "Prénom" et "Nom" côte à côte écrase souvent les deux champs. Passer en une seule colonne, garder les labels au-dessus et donner au bouton Continuer une vraie taille de tap rend l'écran fini sans changer le design.

Maîtrisez les composants délicats : images, tableaux et modales

Beaucoup de ruptures mobiles proviennent de quelques coupables : images avec tailles fixes, tableaux qui supposent la largeur desktop, et modales qui oublient que les téléphones doivent pouvoir scroller.

Images qui cassent les conteneurs

Si une image a une largeur fixe (par ex. 800px) elle peut forcer la page plus large que le téléphone.

Laissez les images réduire mais pas s'agrandir. Dans la plupart des cas, mettez une max-width de 100% du conteneur et laissez la hauteur suivre le ratio. Si le design demande une hero à hauteur fixe, recadrez proprement avec object-fit pour ne pas déformer l'image.

Les longues chaînes de texte non interrompues peuvent causer le même défilement. Identifiants utilisateurs, emails, liens d'invitation, numéros de commande et blocs de code refusent souvent de se wrapper. Appliquez des règles de wrapping aux zones de contenu pour que les longues chaînes cassent la ligne au lieu de pousser la mise en page.

Tableaux sans douleur

Les tableaux sont difficiles sur petits écrans. Choisissez une stratégie par tableau selon ce que les gens ont réellement besoin de faire sur mobile : autoriser le défilement horizontal du tableau dans son propre conteneur, empiler chaque ligne en carte, ou afficher un résumé court avec une vue détail.

Notez la stratégie choisie et pourquoi. Sinon, une modification ultérieure peut réintroduire silencieusement le débordement.

Modales et drawers utilisables

Les modales cassent souvent car leur hauteur est fixe et la page derrière continue de défiler. Un pattern plus sûr : limiter la hauteur de la modal au viewport, rendre le corps de la modal scrollable, et garder l'en-tête (titre et close) visible.

Contrôles rapides qui attrapent la plupart des bugs :

• Le bouton de fermeture est visible et facile à tapoter sur petits écrans
• Le contenu de la modal défile, mais l'arrière-plan non
• Le clavier ne cache pas le bouton d'action principal

Exemple : une modal d'inscription avec un long paragraphe de conditions doit défiler à l'intérieur de la modal, pas s'étendre hors écran.

Un audit de mise en page étape par étape à répéter sur chaque page

La rapidité compte. Le chemin le plus court consiste à auditer un écran à la fois et corriger la chose unique qui fait dérailler la mise en page.

Choisissez un écran qui casse clairement sur téléphone. Écrivez les symptômes comme un bug report : "Je dois défiler horizontalement", "le bouton principal est coupé", "la modal sort de l'écran", "le texte chevauche l'input." Cela vous empêche de courir après des changements CSS aléatoires.

Ensuite, isolez le plus petit élément qui déclenche la casse. Dans DevTools, basculez les éléments jusqu'à ce que le problème disparaisse. C'est souvent un enfant avec une largeur fixe, une chaîne non rompue, ou un composant qui ignore son conteneur.

Un flux réutilisable :

• Trouvez le premier élément qui dépasse la largeur du viewport
• Supprimez le dimensionnement fixe (largeurs en px, valeurs left/right fixes) et laissez le parent contrôler la largeur
• Préférez des règles fluides comme max-width: 100% et width: 100% quand c'est approprié
• Ajoutez du wrapping pour les contenus longs (noms, emails, textes d'erreur)
• Retestez sur un vrai téléphone, puis sur une tablette

Exemple concret : un écran d'onboarding semble correct sur desktop, mais sur iPhone le bouton "Continuer" glisse hors écran. En inspectant le footer, vous trouvez un conteneur avec width: 480px. Supprimer cette règle et laisser le footer à width: 100% corrige le scroll horizontal et ramène le bouton.

Pièges fréquents qui font échouer les correctifs plus tard

Les corrections rapides pour mobile ont l'air correctes à une taille d'écran, puis se brisent quand le contenu réel arrive. Bonne règle : si vous avez dû deviner une valeur en pixels, ça cassera probablement plus tard.

Erreur fréquente : ajouter des breakpoints au lieu de corriger la mise en page de base. Les breakpoints sont utiles, mais si la mise en page de base dépend de largeurs fixes ou d'un wrapper desktop-first, vous passez votre temps à courir derrière de nouveaux problèmes sur chaque appareil. Commencez par des conteneurs flexibles, puis ajoutez un ou deux breakpoints pour des changements importants.

Autre piège : utiliser overflow: hidden pour faire disparaître le défilement horizontal. Ça masque le symptôme tout en rognant des boutons, messages d'erreur, ou outlines de focus. Sur les formulaires, ça peut cacher les messages de validation et empêcher l'utilisateur de finir le parcours.

Les hauteurs codées en dur sont aussi fragiles. Une carte parfaite à height: 420px coupera quand un nom est plus long, une erreur apparaît ou l'utilisateur active une taille de texte plus grande. Privilégiez le flux naturel du contenu et laissez la page défiler.

Des règles d'espacement contradictoires peuvent détricoter votre travail. Les composants IA apportent souvent leurs propres margins, paddings et line-heights, et le CSS global ajoute encore. Quand un composant embarque des hypothèses différentes, l'alignement dérive et le débordement revient.

Ne sautez pas les tests en mode sombre et en zoom élevé. Contrôles rapides qui attrapent les échecs tôt : augmentez la taille du texte à 200% et retestez formulaires et modales, basculez le mode sombre et cherchez des bordures ou textes helpers invisibles, et testez une petite et une grande largeur de téléphone.

Checklist rapide pour l'utilisabilité mobile

Utilisez ceci après avoir corrigé le débordement et le CSS fragile. Cela attrape les choses qui rendent une page inutilisable sur un vrai téléphone, même si elle a l'air correcte sur desktop.

Assurez-vous que la page ne force jamais de mouvement horizontal. Ouvrez vos écrans clés (landing, connexion, dashboard, paramètres) et essayez de glisser gauche/droite. Si quelque chose bouge, quelque chose est encore plus large que le viewport.

Puis vérifiez la lisibilité et l'interaction : les paragraphes doivent se wrapper naturellement, les titres ne doivent pas être coupés, vous ne devez pas avoir à zoomer pour lire des labels ou erreurs, et les boutons ne doivent pas sembler à l'étroit.

Liste de contrôles simple :

• Pas de défilement horizontal sur les écrans clés (y compris dans les modales)
• Le texte se wrappe naturellement (pas de titres tronqués ou de blocs texte en largeur fixe)
• Les cibles tactiles sont confortables (boutons et liens non écrasés)
• Les formulaires restent utilisables (inputs, dropdowns et états d'erreur restent visibles)
• Les parcours à une main fonctionnent (menus et modales ne demandent pas des taps précis)

Après tout changement d'UI, re-vérifiez juste quelques points : une largeur de 320px fonctionne toujours, avec le clavier ouvert vous pouvez atteindre le champ suivant et le bouton submit, les états d'erreur restent visibles, les états de chargement n'étirent pas les conteneurs, et le mode sombre reste lisible.

Exemple : si une page de paramètres générée par l'IA ajoute une nouvelle pastille "Upgrade to Pro", elle peut discrètement déclencher un débordement. Attrapez-la tôt en répétant le test du glissement et la vérification 320px.

Exemple : sauver un écran d'onboarding cassé

Cas courant : l'écran d'onboarding a l'air bien sur desktop, mais sur iPhone la carte est coupée, la page défile horizontalement, et le bouton "Continuer" se retrouve sous le clavier.

Dans une intervention, trois causes racines créaient la plupart des dégâts. La carte principale avait une largeur fixe (par ex. 520px) et une marge gauche fixe, donc elle ne pouvait pas rétrécir. Le champ email laissait les adresses longues dépasser parce que la rangée d'input ne pouvait pas se réduire proprement. Et une modal "Terms" utilisait une hauteur fixe sans scroll interne, donc elle débordait du viewport.

L'audit commence par reproduire le problème aux tailles réelles, puis trouver le premier élément qui dépasse. De là, remontez la chaîne des parents jusqu'à trouver le conteneur qui refuse de rétrécir.

Les corrections furent petites et ciblées, axées sur la suppression du dimensionnement forcé. La carte est passée d'une largeur fixe à une largeur maximale fluide, les marges sont devenues réactives (centrées avec margins latérales automatiques), la rangée d'input a reçu des règles lui permettant de se réduire sans pousser ses voisins, et la modal est passée d'une hauteur fixe à une hauteur max dependante du viewport avec scroll interne.

Les checks d'acceptation sur téléphone et tablette furent simples :

• Pas de défilement horizontal nulle part, même en focalisant les inputs
• Le bouton principal reste visible au-dessus du clavier
• La modal tient dans l'écran et défile à l'intérieur de son contenu
• Le texte reste lisible sans zoom, et les cibles tactiles sont faciles

Étapes suivantes si votre UI générée par l'IA continue de casser

Si les problèmes mobiles réapparaissent, le projet manque souvent de règles de mise en page partagées. Quelques décisions maintenant empêchent la prochaine série de corrections d'annuler les précédentes.

Rédigez une courte note "règles mobiles" et gardez-la près du code. Soyez spécifique :

• Pas de largeurs fixes sur les conteneurs au niveau page (préférez max-width et sizing fluide)
• Tout composant susceptible de déborder doit le gérer volontairement (wrap, clamp, ou scroll)
• Un système d'espacement unique (un petit set de gaps et tailles de police)
• Les boutons et inputs doivent rester utilisables au pouce (hauteur confortable et labels clairs)

Puis corrigez dans un ordre qui crée de la stabilité : éliminez d'abord le défilement horizontal, corrigez ensuite les formulaires (inputs, erreurs, comportement du clavier), et ce n'est qu'après que vous peaufinez les écrans secondaires.

Si vous avez hérité d'un frontend généré par l'IA et que vous butez sur les mêmes échecs de mise en page, il peut être plus rapide d'obtenir un diagnostic clair de ce qui force réellement le débordement et le positionnement fragile. FixMyMess (fixmymess.ai) se concentre sur la réparation des apps générées par l'IA depuis des outils comme Lovable, Bolt, v0, Cursor et Replit, et un audit rapide du code peut vous dire exactement ce qui casse sur de vrais appareils avant que vous perdiez du temps à colmater des symptômes.