La page de résultats d’un catalogue peut sembler correcte tout en répétant des produits, en sautant des lignes ou en perdant le filtre choisi. Pour une équipe Symfony, la pagination engage donc trois choses à la fois : la requête qui sélectionne les données, l’ordre dans lequel elles arrivent et les liens qui permettent de poursuivre la navigation.
Le 21 septembre 2026, Symfony UX 3.5 a présenté UX Pagination, un composant dédié qui relie une source de données PHP à une navigation rendue par Twig. La même version a aussi modifié la façon dont certains attributs HTML de composants sont rendus. Ces évolutions se testent ensemble dans une interface, mais elles répondent à deux questions différentes : comment découper un ensemble de résultats, et quel HTML le navigateur reçoit-il réellement ? L’annonce de Symfony UX 3.5 date ces changements et précise leur périmètre.
Avant d’installer : distinguer le composant et son niveau de stabilité
UX Pagination fait partie de Symfony UX, l’ensemble de composants qui relie les applications Symfony à des interfaces web. Ce n’est pas un composant du cœur Symfony. L’annonce de la version 3.5 précise que le bundle de pagination est expérimental : son API peut évoluer. Sa documentation montre son fonctionnement, mais ne change pas ce statut. Avant de l’adopter, examinez la compatibilité de votre version de PHP, Symfony, Twig et des paquets UX déjà installés. Faites cette vérification sur un projet d’essai ou une branche dédiée, pas en mettant à jour les dépendances de votre site de production pour suivre un exemple.
Le composant peut paginer des tableaux, des requêtes Doctrine ORM ou DBAL, ainsi que d’autres sources qui implémentent son interface. Le code de l’application garde la responsabilité de préparer et d’autoriser la requête. Twig affiche ensuite les liens. Dans le parcours serveur présenté par Symfony, les contrôles sont de vrais liens HTML : JavaScript, Stimulus ou Turbo ne sont pas nécessaires pour passer d’une page à l’autre. Cette séparation est utile : la présentation ne devrait pas décider quels enregistrements un utilisateur a le droit de voir.
Choisir la stratégie à partir de la question métier
Imaginez un catalogue interne de pièces détachées. Une personne filtre les pièces par catégorie et cherche une page précise. Si le nombre total est utile — par exemple parce qu’un traitement permet de consulter la page 12 — une pagination numérotée répond à ce besoin. Elle peut toutefois demander une requête de comptage, en plus de la requête qui récupère les lignes. Le coût exact dépend de la base, des filtres et des index : ne supposez pas qu’il sera faible ou élevé sans mesurer votre propre requête.
Si l’interface n’a besoin que d’indiquer qu’il reste des résultats, la stratégie dite lookahead récupère un élément supplémentaire pour savoir s’il existe une page suivante. Elle évite de calculer un total exact. C’est souvent une meilleure représentation lorsque l’utilisateur parcourt simplement une liste, mais elle ne permet pas d’annoncer « 243 résultats » sans autre mécanisme.
Enfin, si les lignes peuvent changer pendant la consultation, une pagination par curseur peut mieux conserver la position. Au lieu de demander « donnez-moi la page 4 », le navigateur transmet une position de continuation. Prenons une liste triée par date de création, de la plus récente à la plus ancienne : plusieurs pièces peuvent partager la même date. Il faut donc ajouter un critère stable, comme l’identifiant, pour obtenir un ordre total. Sans ce second critère, une insertion simultanée peut déplacer des lignes entre deux requêtes et provoquer des doublons ou des omissions. Le curseur n’annule pas le besoin d’un ordre déterministe, d’index adaptés et de filtres cohérents.
| Besoin du lecteur | Stratégie à examiner | Question à vérifier |
|---|---|---|
| Voir un total et rejoindre une page précise | Numérotée | Le coût du comptage est-il acceptable avec les filtres réels ? |
| Savoir seulement si la suite existe | Lookahead | L’interface peut-elle se passer du nombre total ? |
| Continuer dans un ensemble qui évolue | Curseur | Le tri est-il stable et complet, y compris en cas d’égalité ? |
Le filtre et l’autorisation doivent être appliqués avant la pagination, dans la requête adaptée à l’utilisateur. Sinon, le nombre affiché peut révéler des informations ou les pages peuvent contenir des résultats incohérents. Ces choix sont des principes d’architecture à valider dans le projet concerné, pas des performances mesurées par cette présentation de la version.
Relire les attributs que Twig rend
Symfony UX 3.5 fait aussi passer le rendu des attributs de ComponentAttributes par la logique HTML de Twig. L’annonce décrit plusieurs différences : une valeur null n’entraîne plus la même erreur, les booléens aria-* sont rendus explicitement, et des tableaux, itérables ou énumérations adossées deviennent acceptés. Une classe de composant et un gabarit Twig ordinaire peuvent ainsi partager la même règle de rendu. Pour une application, le point important est que la sortie HTML peut changer lors de la mise à niveau.
Ne mettez pas à jour un instantané de test simplement parce qu’il diffère. Dans une branche d’essai, comparez l’ancien et le nouveau DOM pour les composants concernés. Contrôlez qu’un attribut absent reste absent lorsqu’il vaut null, que aria-expanded="false" demeure une valeur explicite et que les classes produites correspondent au composant attendu. Puis vérifiez le comportement au clavier : focus visible, ordre de tabulation, libellés compréhensibles et retour à la liste après avoir suivi un lien. Le fait qu’un composant fournisse une navigation annoncée comme accessible ne certifie pas l’ensemble de votre page, de vos filtres ou de vos contenus.
Pour une application qui utilise un lecteur d’écran, vérifiez aussi le nom accessible de la zone de navigation et les libellés des liens précédent, suivant et des pages. Des snapshots identiques ne prouvent pas que les contrôles fonctionnent ; des snapshots différents ne prouvent pas qu’ils sont incorrects. Il faut comparer la structure aux exigences d’usage.
Monter un essai qui répond à une décision
Créez un jeu de données fictif avec quelques produits, plusieurs éléments à la même date, une catégorie vide et un filtre qui réduit fortement la liste. Faites une liste de contrôle avant d’évaluer le composant : première et dernière page, aucun résultat, égalités de tri, filtre conservé dans l’URL, accès clavier, bouton retour du navigateur et autorisation d’accès. Pour chaque stratégie, notez les requêtes attendues, l’information que l’interface affiche et la manière dont elle se comporte quand un nouvel élément apparaît.
Si vous évaluez le coût, mesurez séparément le comptage et la récupération des résultats sur une base représentative, avec les index prévus et des filtres réalistes. Cet article ne fournit aucun chiffre d’exécution : le tableau aide à choisir quoi mesurer. Si vous évaluez le HTML, inspectez les éléments réellement rendus dans le navigateur après l’intégration, au lieu de tester uniquement le nom du thème CSS.
Au 1er octobre 2026, UX Pagination est documenté et reste expérimental. Essayez-le si son contrat correspond à votre liste, si les versions verrouillées sont compatibles et si l’équipe accepte de suivre l’évolution de l’API. Pour une interface qui exige une stabilité stricte, le bon résultat de l’essai peut être d’attendre. Dans les deux cas, jugez la pagination à la requête, à l’ordre et au parcours complet, pas uniquement à son apparence.
Sources vérifiées le 1er octobre 2026
- Symfony, « Symfony UX 3.5 released », publié le 21 septembre 2026 : annonce de la release, statut expérimental de Pagination et changement de rendu des attributs.
- Symfony UX, « UX Pagination », documentation consultée le 1er octobre 2026 : stratégies numérotée, lookahead et curseur, navigation et thèmes.
Les exemples de catalogue et les recommandations de test sont fictifs. Aucun benchmark ni audit d’accessibilité n’a été exécuté pour cet article.