Comment un écran s'organise selon la largeur disponible. Les seuils suivent les classes de taille de fenêtre de Material 3 ; vps-admin est l'implémentation de référence.

Classes de largeur

• Le point de rupture se choisit : 600 px (classes de fenêtre M3) ou 760 px quand la navigation dépasse 4 destinations ou que le contenu a besoin de largeur. Les deux sont acceptés, mais une seule valeur par app ; vps-admin et le site Pelote utilisent 760 px.
• Jamais de barre du bas sur PC, jamais de rail sur un téléphone en portrait.
• La snackbar et les FAB se placent au-dessus de la barre du bas ; avec le rail, la snackbar se centre sur la zone de contenu.

Largeur sur PC : pas d'espace mort

La règle n'est pas « ne jamais prendre toute la largeur » mais « ne jamais laisser d'espace mort ». Deux manières de faire, selon ce que montre l'écran.

1. Bento pleine largeur : quand l'écran est une vue d'ensemble

Tableau de bord, accueil, profil, page de projet : le contenu est une collection de modules.

• La grille prend toute la largeur (marges latérales de 24 à 32 px) avec des tuiles de tailles différentes selon leur importance : la mesure principale en 2×2, les graphiques en 2×1, les petites valeurs en 1×1.
• Grille de 4 colonnes en expanded, 6 en large, 8 à 12 en extra-large ; les tuiles gardent une largeur de colonne entre 160 et 320 px et changent de taille plutôt que de s'étirer.
• Les rangées se remplissent sans trou : on choisit les tailles pour que la grille tombe juste (grid-auto-flow: dense).
• Le texte à l'intérieur d'une tuile reste court ; un module qui contient du texte long ouvre un détail.

2. Largeur limitée + volet : quand on lit ou qu'on édite

Liste, détail, formulaire, document, réglages : le contenu principal se lit en continu.

• Largeur maximale : texte courant 65 à 70 caractères, formulaire 640 px, liste ou tableau 1340 px (vps-admin).
• L'espace restant accueille un volet utile qui ne répète pas le contenu : barre de widgets (vps-admin, à partir de 1500 px, choisie et refermable par la personne), volet de détail à côté d'une liste, aperçu à côté d'un formulaire.
• Si rien d'utile ne peut occuper l'espace, le contenu se centre. On ne remplit jamais avec du décor.

Dans tous les cas

• Jamais de cartes identiques étirées sur 2560 px : soit elles changent de taille (bento), soit le contenu est borné.
• Le fond décoratif (trame de points du portfolio, formes) peut occuper toute la largeur.
• Une app peut mélanger les deux : la vue d'ensemble de vps-admin peut passer en bento pleine largeur, ses pages de détail garder la largeur limitée et la barre de widgets.

Écrans pliables (fold)

• Fold fermé : compact, comme un téléphone.
• Fold ouvert à plat (environ 700 à 900 px) : medium ou expanded. Rail à gauche et deux volets, un de chaque côté de la charnière.
• Charnière : aucun texte, bouton ni image importante ne passe dessus. Web : @media (horizontal-viewport-segments: 2) et env(viewport-segment-width 0 0) pour placer les volets de part et d'autre. Flutter : MediaQuery.displayFeatures et DisplayFeatureSubScreen.
• Posture table (à moitié plié, horizontal) : le contenu à lire en haut, les commandes en bas, exactement comme le motif deux écrans de la 3DS (pz-dual en Plaza).
• Le passage d'une posture à l'autre garde l'état : pas de rechargement, la sélection reste sélectionnée.

Espace vide

• Un écran qui n'a pas encore de contenu montre un état vide qui guide (quoi faire, en combien de temps), jamais une grande zone blanche.
• Dans une carte, pas d'élément court seul sur sa ligne (voir Règles UX).
• Dans une grille, les cartes d'une même rangée ont la même hauteur de contenu ; pas de case vide qui pend en fin de grille : la colonne s'adapte au nombre d'éléments.

Hauteur et défilement

• La barre de navigation (rail ou barre du bas) reste fixe ; le contenu défile.
• Le volet de soutien défile indépendamment (vps-admin : barre de widgets en position: sticky, hauteur de l'écran).
• Sur mobile, respecter les zones sûres (env(safe-area-inset-*)) : la barre du bas ajoute l'inset du bas à son padding.