Depuis une dizaine d'années, toute grille façon Pinterest — colonnes de largeur égale, cartes de hauteurs variables qui se calent sans laisser de trous — repose soit sur du JavaScript (Masonry.js, Isotope), soit sur un hack CSS à base de column-count qui casse l'ordre de lecture en répartissant les éléments colonne par colonne plutôt que ligne par ligne. En 2026, ce compromis est en train de disparaître : CSS Grid Layout Level 3 introduit nativement le layout grid lanes, capable de produire un vrai masonry sans une ligne de script. Safari 26.4 l'a déjà livré sans drapeau expérimental, Chrome et Firefox le testent derrière un flag, et l'initiative Interop 2026 pousse pour une convergence cette année.

Le nom a mis du temps à se stabiliser. Le sujet agite le CSS Working Group depuis 2020 (ticket csswg-drafts #4650), avec un désaccord de fond entre Apple et Google : fallait-il ajouter une valeur masonry directement dans grid-template-rows/grid-template-columns de CSS Grid Level 2, comme le proposait Apple, ou en faire un mode de display séparé, plus proche de flexbox dans son fonctionnement, comme le défendait Chrome ? Après des années d'allers-retours, la spécification a tranché en faveur d'un nouveau mode : display: grid-lanes, publié dans le brouillon de CSS Grid Layout Level 3.

Concrètement, qu'est-ce que ça change si tu construis une galerie d'images, un flux d'articles ou un tableau de bord avec des cartes de hauteurs variables ? On regarde la syntaxe, l'état réel du support navigateur début septembre 2026, et comment adopter la propriété dès maintenant sans casser le rendu ailleurs.

Le problème que grid-lanes vient enfin résoudre

Les deux solutions historiques ont chacune un défaut structurel. Le hack column-count/column-width répartit les éléments colonne par colonne : l'élément 1 en haut de la colonne 1, l'élément 2 juste en dessous, et ainsi de suite, jusqu'à repartir en haut de la colonne 2. Résultat, un lecteur au clavier ou au lecteur d'écran parcourt la grille dans un ordre qui n'a rien à voir avec l'ordre visuel en lignes. Les bibliothèques JavaScript comme Masonry.js contournent ce problème en positionnant chaque carte en position: absolute après avoir mesuré sa hauteur réelle, mais ça implique du JavaScript bloquant au chargement, un flash de contenu mal positionné (FOUC) le temps que le script s'exécute, et le même souci d'ordre de tabulation si le script ne le corrige pas explicitement.

display: grid-lanes résout les deux à la fois : le rendu est géré nativement par le moteur de rendu (donc pas de recalcul JS ni de flash), et l'algorithme de placement respecte l'ordre du DOM tout en remplissant visuellement les colonnes les plus courtes.

La syntaxe de display: grid-lanes

La forme la plus simple ressemble à une grille classique, à un détail près : tu définis seulement les colonnes (ou seulement les lignes), jamais les deux.

.galerie {
  display: grid-lanes;
  grid-template-columns: repeat(auto-fill, minmax(200px, 1fr));
  gap: 16px;
}

L'algorithme place les éléments un par un, dans l'ordre du DOM, en choisissant à chaque fois la colonne ("lane") qui a le moins de contenu accumulé — exactement le comportement visuel qu'on attend d'un masonry, mais sans mesurer manuellement quoi que ce soit en JavaScript. Autre avantage concret : si tu charges de nouvelles cartes en lazy loading et que tu les ajoutes à la fin du DOM, elles s'insèrent à la suite sans repositionner les cartes déjà affichées — un point sur lequel les anciennes bibliothèques JS étaient souvent instables.

inline-grid-lanes pour un remplissage horizontal

Il existe aussi une variante inline-grid-lanes, qui empile les éléments par lignes plutôt que par colonnes — utile pour un mur de tuiles qui défile horizontalement plutôt que verticalement :

.mur-horizontal {
  display: inline-grid-lanes;
  grid-template-rows: repeat(3, 140px);
  grid-auto-flow: column;
  gap: 12px;
}

Le principe reste identique : tu fixes un seul axe (ici les lignes), et le navigateur se charge de répartir les éléments sur l'autre axe en respectant l'ordre du DOM.

Où en est le support navigateur en septembre 2026

C'est le point à vérifier avant de te lancer en production :

Safari a été le premier à livrer la fonctionnalité sans drapeau, dans Safari 26.4 (sortie le 24 mars 2026). C'est aujourd'hui l'implémentation la plus complète.
Chrome et Edge proposent le support depuis la version 140 (juillet 2025), mais uniquement derrière le drapeau expérimental "CSS Masonry Layout" dans chrome://flags (activable aussi via "Experimental Web Platform features"). Aucune version stable et non flaggée n'a encore livré la fonctionnalité au moment de la rédaction.
Firefox a également une implémentation derrière un flag, sans date de passage en stable annoncée.

L'initiative Interop 2026, qui réunit les principaux moteurs pour prioriser les convergences de comportement, inclut grid-lanes dans ses discussions ; une stabilisation chez Chrome et Firefox est attendue dans le courant de l'année, sans date ferme à ce stade. Avant toute mise en production, vérifie l'état à jour sur Can I Use plutôt que de te fier à une date précise — le calendrier des navigateurs Chromium et Firefox peut encore bouger.

Adopter grid-lanes dès maintenant, sans rien casser ailleurs

Tant que le support n'est pas généralisé, la bonne pratique est la détection de fonctionnalité avec @supports, en gardant un repli propre pour les navigateurs qui ne suivent pas encore :

.galerie {
  /* Repli : une grille classique à largeur fixe, sans effet masonry */
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(200px, 1fr));
  gap: 16px;
}

@supports (display: grid-lanes) {
  .galerie {
    display: grid-lanes;
  }
}

Cette approche ne casse rien : les navigateurs qui ne connaissent pas encore grid-lanes affichent une grille à cartes de hauteur égale (moins spectaculaire, mais parfaitement lisible), pendant que Safari 26.4 et les navigateurs Chromium/Firefox avec le flag activé profitent du vrai rendu masonry. C'est nettement plus robuste que de charger conditionnellement une bibliothèque JS de secours, qui ajoute une dépendance et un chemin de code à maintenir pour un gain esthétique temporaire.

Ordre du DOM et accessibilité : l'avantage décisif

Le point le plus sous-estimé de grid-lanes n'est pas visuel, il est structurel. Parce que l'algorithme de placement suit l'ordre du DOM pour décider dans quelle colonne insérer chaque élément, l'ordre de tabulation au clavier et l'ordre de lecture pour un lecteur d'écran restent cohérents avec l'ordre visuel ligne par ligne — ce que ni column-count ni la plupart des implémentations JS ne garantissaient par défaut. C'est un argument suffisant pour préférer grid-lanes à un hack CSS existant dès que le support le permet, même sans urgence sur l'esthétique.

Ceci dit, la vigilance reste de mise : sur une grille très dense avec beaucoup de cartes interactives (boutons, liens multiples par carte), teste toujours la navigation au clavier après migration. Le placement en colonnes signifie que l'ordre visuel "à l'écran" peut différer légèrement de l'ordre "au clavier" selon la largeur du viewport et le nombre de colonnes réellement rendues — un test rapide au Tab suffit à s'en assurer.

Ce qu'il faut faire maintenant

Si tu démarres un nouveau projet avec une grille de type Pinterest, il n'y a plus de raison d'installer une dépendance JS pour ça : écris directement la version @supports décrite plus haut. Le repli en grille classique fonctionne partout dès aujourd'hui, et tu récupères le vrai masonry gratuitement à mesure que Chrome et Firefox stabilisent leur implémentation. Sur un projet existant qui utilise déjà Masonry.js ou un hack column-count, la migration peut attendre que Chrome livre sans flag — mais commence dès maintenant à vérifier l'état du support sur Can I Use pour planifier la bascule, plutôt que de la découvrir en urgence dans six mois.

CSS Grid Lanes : le masonry natif arrive, Safari en tête