J'ai revu beaucoup de handoffs de design responsive en plus de dix ans. Ceux qui échouent systématiquement ont la même cause racine : le designer a complété le layout desktop, puis l'a réduit au mobile comme une réflexion après coup. Le résultat est une expérience mobile techniquement responsive mais expérientiellement cassée : une navigation entassée, des cibles tactiles qui nécessitent une précision de chirurgien, et une hiérarchie de contenu qui a du sens sur un canvas de 1440px mais qui s'effondre sur un écran de 390px.
Mobile first est une philosophie, pas une technique. La media query CSS min-width n'est que l'expression mécanique d'une décision qui aurait dû être prise bien plus tôt : au moment où vous avez décidé quel contenu compte le plus, quelle est la tâche principale de l'utilisateur sur cette surface, et comment un environnement contraint devrait forcer la clarté plutôt que le compromis.
La contrainte est le design
Un viewport de 390px avec un clavier logiciel qui en prend le tiers ou plus dès que la barre de prédiction apparaît, un pouce comme appareil d'entrée principal, une connexion qui coupe sans prévenir, et un utilisateur qui fait autre chose en même temps : voilà le problème de design. Commencez là et vous êtes forcé de prendre de vraies décisions. Quelle est la seule chose que cet écran doit faire ? Quelle information est vraiment nécessaire ? Qu'est-ce qui est reporté à un écran secondaire ou à une session plus intentionnelle ?
Quand vous partez du desktop, vous n'avez jamais à prendre ces décisions. Vous avez l'espace pour tout accommoder, donc tout est inclus. Puis vous essayez de tout faire rentrer dans le mobile et rien ne tient proprement. Le menu hamburger devient un fourre-tout. Les cartes s'effondrent en une densité illisible. Le CTA principal est enterré sous le pli.
L'architecture de l'information vient en premier
Avant tout design visuel, le processus mobile-first commence par la priorisation du contenu. Pour chaque écran, je demande : quel est l'objectif principal de l'utilisateur sur mobile ? Quelle information soutient directement cet objectif ? Qu'est-ce qui peut attendre ?
Cet exercice produit une hiérarchie de contenu spécifique au contexte mobile. Imaginez un tableau de bord bancaire. Sur desktop, l'écran porte un résumé du compte, les transactions récentes, les analyses de dépenses, les offres promotionnelles, les liens rapides et les alertes tous en même temps. Sur mobile, la hiérarchie est le solde du compte et la transaction la plus récente d'abord, tout le reste atteignable mais secondaire. Ce n'est pas une décision de mise en page. C'est une décision d'architecture de l'information qui change ce qui est construit, pas seulement comment c'est arrangé.
- Commencer par un audit de contenu : lister chaque élément à l'écran et le classer par valeur utilisateur dans un contexte mobile
- Éliminer sans pitié : si un élément n'est pas dans les trois premières priorités pour le mobile, il est soit reporté soit supprimé
- Définir la divulgation progressive : ce qui apparaît immédiatement, ce qui nécessite un tap pour révéler, ce qui vit sur un écran séparé
- Considérer le contexte de la tâche : les utilisateurs mobiles sont souvent en déplacement, designer pour l'interruption, pas pour des sessions soutenues
- Designer l'état vide et l'état de chargement pour le mobile d'abord : ce sont les états qui exposent le plus les hypothèses erronées
Cibles tactiles : 24x24 est le plancher, 44x44 est la règle
Les Human Interface Guidelines d'Apple spécifient une cible tactile minimum de 44x44 points. Le Material Design de Google recommande 48x48dp. Le WCAG a deux critères ici et la différence compte dès que quelqu'un vous demande à quoi vous vous conformez. Le SC 2.5.8 Target Size (Minimum) est de niveau AA dans WCAG 2.2 et demande 24x24 pixels CSS. Le SC 2.5.5 Target Size (Enhanced) est de niveau AAA et demande 44x44. Donc 24x24 est le plancher à franchir pour revendiquer AA, et 44x44 est le chiffre qu'utilisent les guidelines des plateformes et celui que je vise en design mobile. Franchissez le plancher dans l'audit, visez 44x44 dans le design.
C'est là que les designs desktop-first cassent visiblement. Un bouton icône de 24x24 sur desktop a assez d'espace blanc autour pour être utilisable à la souris. Le même bouton de 24x24 sur mobile est une machine à frustration. Gardez la taille visuelle à 24x24 si le design l'exige, puis étendez la zone tappable à 44x44 avec du padding ou un pseudo-élément. La taille dessinée et la zone de contact sont deux chiffres différents et un seul des deux doit satisfaire la directive.
/* Touch-friendly icon button, visible size 24px, tap target 44px */
.icon-btn {
/* Visual size */
width: 24px;
height: 24px;
/* Extend tap target without affecting layout */
position: relative;
cursor: pointer;
display: inline-flex;
align-items: center;
justify-content: center;
/* Invisible extended touch area */
&::after {
content: '';
position: absolute;
inset: -10px; /* Extends 10px in all directions: 24 + 20 = 44px */
}
}
/* Alternatively, use padding */
.touch-btn {
padding: 10px;
min-width: 44px;
min-height: 44px;
display: inline-flex;
align-items: center;
justify-content: center;
box-sizing: border-box;
}Navigation : le problème mobile le plus difficile
La navigation est la décision d'architecture de l'information la plus lourde de conséquences dans un design mobile-first. Le menu hamburger est devenu la solution par défaut, et c'est une solution faible. Il cache la navigation, réduit la découvrabilité, et ajoute un tap et une surcouche plein écran à chaque action de navigation.
Les alternatives dépendent du nombre d'éléments de navigation. Pour cinq destinations principales ou moins, une barre d'onglets en bas (suivant les patterns mobiles natifs) est dramatiquement plus utilisable : atteignable au pouce, toujours visible, zéro tap supplémentaire. Pour des hiérarchies plus profondes, considérez quels éléments doivent réellement être dans la navigation principale versus accessibles via des actions contextuelles dans chaque section.
Sortir les destinations principales d'un menu hamburger pour les mettre dans une navigation persistante et accessible au pouce est l'un des gains les moins chers d'une refonte mobile-first. Les utilisateurs se sentent moins perdus quand la navigation est toujours visible.
- Barre d'onglets en bas : meilleur pour 3-5 destinations principales, suit les patterns natifs que les utilisateurs connaissent déjà
- Menu hamburger : acceptable pour la navigation secondaire avec plus de 7 éléments, jamais pour la navigation principale
- Fil d'Ariane + bouton retour : essentiel pour les hiérarchies profondes, s'assurer que le bouton retour est atteignable au pouce
- Navigation contextuelle : liens et actions pertinents au contenu actuel, réduit le besoin de navigation globale
- Éviter les méga-menus entièrement sur mobile : c'est un pattern desktop qui n'a pas d'équivalent mobile
Formulaires sur mobile : réduire, puis réduire encore
Les formulaires sont l'élément le plus sujet aux échecs dans le design mobile. Le clavier logiciel prend le tiers de l'écran ou plus, si bien que le champ dans lequel vous tapez peut se retrouver juste au-dessus du clavier, avec le bouton de soumission hors de vue. Les erreurs de validation nécessitent de défiler pour être vues. L'approche que j'adopte pour les formulaires mobiles est progressive : ne montrer que ce dont l'étape actuelle a besoin, définir le bon type d'entrée pour que le bon clavier s'ouvre, et valider inline plutôt qu'à la soumission.
// Angular form with mobile-optimized inputs
@Component({
selector: 'app-contact-form',
imports: [ReactiveFormsModule],
template: `
<form [formGroup]="form" (ngSubmit)="onSubmit()">
<!-- Correct inputmode triggers optimized mobile keyboards -->
<input
formControlName="phone"
type="tel"
inputmode="tel"
autocomplete="tel"
placeholder="Phone number" />
<input
formControlName="amount"
type="text"
inputmode="decimal"
autocomplete="off"
placeholder="Amount" />
<input
formControlName="email"
type="email"
inputmode="email"
autocomplete="email"
placeholder="Email" />
<!-- Large touch target for submit -->
<button
type="submit"
style="min-height: 48px; width: 100%; font-size: 1rem;">
Submit
</button>
</form>
`
})
export class ContactFormComponent {
form = this.fb.group({
phone: ['', Validators.required],
amount: ['', Validators.required],
email: ['', [Validators.required, Validators.email]]
});
constructor(private fb: FormBuilder) {}
onSubmit(): void { /* ... */ }
}Patterns responsive Angular qui fonctionnent vraiment
Côté implémentation, l'approche CSS mobile-first signifie écrire les styles de base pour le plus petit viewport et ajouter de la complexité pour les plus grands viewports avec des media queries min-width. C'est l'opposé de l'approche traditionnelle desktop-first et ça produit du CSS plus léger et plus maintenable.
Deux fonctionnalités CSS plus récentes font le travail que les media queries et le JavaScript se partageaient. Les container queries permettent à un composant de réagir à la largeur de son propre conteneur plutôt qu'à celle du viewport, ce qui est la bonne unité pour une carte qui vit dans une barre latérale sur une route et prend toute la largeur sur une autre. Mettez container-type: inline-size sur le wrapper, écrivez @container (min-width: 400px) sur la carte, et la carte se moque de l'endroit où elle a été montée. Ça supprime l'essentiel des raisons de recourir à BreakpointObserver au niveau du composant, et ça laisse les media queries pour la vraie mise en page de page.
Les unités de viewport dynamiques règlent directement le problème du clavier logiciel. 100vh sur mobile correspond au grand viewport, celui mesuré avec la barre du navigateur rétractée, si bien qu'une mise en page pleine hauteur se fait rogner sous la barre d'adresse. 100svh est le petit viewport et ne se fait jamais rogner. 100dvh suit le viewport courant au fur et à mesure que le clavier et la barre d'URL apparaissent et disparaissent. Utilisez dvh pour une coquille d'application pleine hauteur, svh pour tout ce qui ne doit jamais être coupé, et ajoutez env(safe-area-inset-bottom) en bas, sinon votre barre d'onglets inférieure se retrouve sous l'indicateur d'accueil.
/* Mobile-first CSS, base styles apply to all sizes */
.card-grid {
display: grid;
gap: var(--ds-spacing-4);
grid-template-columns: 1fr; /* Single column on mobile */
/* Tablet and up */
@media (min-width: 768px) {
grid-template-columns: repeat(2, 1fr);
}
/* Desktop and up */
@media (min-width: 1024px) {
grid-template-columns: repeat(3, 1fr);
}
}
/* Angular CDK BreakpointObserver for component-level responsive logic */
import { BreakpointObserver, Breakpoints } from '@angular/cdk/layout';
import { Component } from '@angular/core';
import { map } from 'rxjs/operators';
@Component({ /* ... */ })
export class ResponsivePanelComponent {
isMobile$ = this.breakpointObserver
.observe([Breakpoints.Handset])
.pipe(map(state => state.matches));
constructor(private breakpointObserver: BreakpointObserver) {}
}Amélioration progressive vs dégradation gracieuse
L'amélioration progressive signifie commencer avec une expérience de base qui fonctionne partout : petits écrans, connexions lentes, anciens navigateurs, technologies d'assistance, et ajouter des couches de comportement plus riche pour les environnements plus capables. La dégradation gracieuse signifie construire pour le meilleur cas et essayer de gérer les cas limites quand ils cassent.
Mobile first est philosophiquement de l'amélioration progressive. Commencer avec l'environnement contraint et prouver que le design fonctionne là. Puis améliorer pour les plus grands écrans, les connexions plus rapides, les états hover et les mises en page multi-colonnes. La base n'est pas une version dépouillée du vrai truc : c'est le vrai truc, et la version améliorée est une variante plus riche.
La discipline que les contraintes mobiles imposent n'est pas une limitation. C'est un filtre de clarté. Chaque élément qui survit au filtre mobile-first est là parce qu'il mérite sa place. Tout le reste est du bruit.
La prochaine fois que vous commencez un design, ouvrez Figma à 390px. Designez l'expérience entière à cette largeur avant de toucher un frame desktop. Vous prendrez des décisions plus difficiles plus tôt, éliminerez plus d'éléments inutiles, et produirez un design cohérent à chaque taille plutôt que cassé à la petite extrémité. Ce n'est pas une astuce CSS : c'est une discipline de design.
Références
- Apple Human Interface Guidelines. https://developer.apple.com/design/human-interface-guidelines/buttons
- Material Design 3 guidelines. https://m3.material.io/components/buttons/guidelines
- WCAG 2.2 Understanding SC 2.5.8 Target Size (Minimum), Level AA. https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html
- WCAG 2.2 Understanding SC 2.5.5 Target Size (Enhanced), Level AAA. https://www.w3.org/WAI/WCAG22/Understanding/target-size-enhanced.html
- Angular CDK BreakpointObserver. https://material.angular.dev/cdk/layout/overview
- MDN. CSS container queries. https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_containment/Container_queries
- MDN. Viewport units svh, lvh and dvh. https://developer.mozilla.org/en-US/docs/Web/CSS/length#viewport-percentage_lengths