Réduire un tableau de dix colonnes à la largeur d’un téléphone produit rarement une interface utilisable. Les libellés se coupent, les actions deviennent minuscules et les relations entre les valeurs se perdent. Avec Tailwind CSS, les classes responsive facilitent l’adaptation, mais elles ne choisissent pas à votre place ce que l’utilisateur doit pouvoir comparer ou modifier. La première décision concerne donc l’usage du tableau, puis la manière de préserver cet usage sur un écran étroit.
Identifier la tâche mobile prioritaire
Demandez ce qu’une personne cherche à faire sur téléphone : consulter un statut, retrouver une commande, comparer des montants ou modifier plusieurs lignes. Ces tâches appellent des présentations différentes. Pour retrouver une commande, quelques informations et un accès au détail peuvent suffire. Pour comparer plusieurs colonnes, conserver un vrai tableau avec défilement peut être plus utile qu’une succession de cartes.
Prenons un exemple fictif de suivi d’interventions. Au bureau, le responsable compare les dates, techniciens et durées. Sur le terrain, un intervenant cherche surtout l’adresse, l’horaire et l’action suivante. Copier exactement la vue desktop sur mobile n’est pas forcément le meilleur choix. Définissez les informations indispensables à chaque situation et les données qui peuvent être consultées dans un détail accessible.
Garder la structure sémantique quand elle porte le sens
Un tableau exprime des relations entre lignes et colonnes. Le tutoriel W3C sur les tableaux explique le rôle des en-têtes et de leur association avec les cellules. Si vous remplacez toute la structure par des blocs visuels, vous devez vérifier que ces relations restent compréhensibles. La présentation responsive ne doit pas faire disparaître le sens pour une personne qui parcourt les données autrement que visuellement.
Ajoutez un titre ou une légende qui explique le contenu et utilisez des en-têtes explicites. Une colonne intitulée « date » est moins utile que « date d’intervention » lorsqu’il existe plusieurs dates possibles. Pour les tableaux complexes, examinez si la complexité vient réellement du besoin ou d’un regroupement excessif d’informations. Deux vues plus ciblées peuvent parfois être plus compréhensibles qu’un tableau universel.
Utiliser les variantes responsive dans le bon sens
La documentation Tailwind décrit une approche mobile d’abord : les classes sans préfixe s’appliquent à toutes les tailles, puis les variantes ajoutent des règles à partir de leurs seuils. Définissez donc le comportement de base pour un espace étroit, puis enrichissez la présentation lorsque la largeur disponible le permet. Vérifiez les seuils configurés dans votre projet plutôt que de supposer qu’ils sont restés par défaut.
La largeur d’un écran ne révèle pas toujours la largeur du composant. Un tableau peut se trouver dans un panneau latéral ou une zone partagée. Testez sa taille réelle dans les différentes mises en page. Évitez d’empiler des exceptions de classes jusqu’à obtenir une capture correcte : une règle simple sur le conteneur et une hiérarchie claire des colonnes se maintiennent plus facilement.
Ne pas confondre masquer et simplifier
Masquer une colonne réduit la largeur, mais peut retirer une information nécessaire à la décision. Avant de cacher un montant, un statut ou un identifiant, vérifiez où l’utilisateur peut le retrouver. Une action comme « valider » ne doit pas rester visible si les éléments nécessaires à sa vérification ont disparu. La simplification doit préserver la capacité à comprendre les conséquences de l’action.
Choisir un défilement horizontal maîtrisé
Lorsque la comparaison entre colonnes est essentielle, placez le tableau dans un conteneur qui permet un défilement horizontal sans faire déborder toute la page. Rendez ce comportement perceptible. Le visiteur doit comprendre que d’autres colonnes existent, sans devoir le découvrir par hasard. Vérifiez aussi l’accès au clavier et la manière dont le focus se déplace vers les actions situées hors de la zone initialement visible.
Un en-tête ou une première colonne fixe peut aider à conserver les repères, mais ajoute des contraintes de superposition et de contraste. Testez les lignes longues, les menus d’action et le zoom. Une colonne fixe trop large peut occuper presque tout l’espace mobile et rendre les autres valeurs inutilisables. Le réglage doit être vérifié avec des données réalistes, pas seulement des libellés courts de démonstration.
Préparer une vue détaillée lorsque la lecture est individuelle
Si l’utilisateur examine une ligne à la fois, une liste compacte menant vers une fiche détaillée peut convenir. La liste affiche les repères de sélection et le détail présente les champs complets. Conservez la possibilité de revenir à la même position, avec les filtres précédents. Sans ce retour, l’utilisateur doit recommencer sa recherche après chaque consultation, ce qui rend le parcours pénible.
Une présentation en cartes peut aussi fonctionner, à condition de répéter les libellés nécessaires et de conserver un ordre stable. Évitez les cartes qui donnent une grande place à la décoration tout en cachant l’information opérationnelle. Vérifiez le volume : parcourir cinquante cartes peut demander beaucoup plus de défilement qu’un tableau compact. Le choix dépend de la fréquence et de la nature du travail effectué.
Conserver des actions compréhensibles et accessibles
Les icônes seules peuvent devenir ambiguës, surtout lorsqu’elles se répètent sur chaque ligne. Donnez aux contrôles un nom accessible qui identifie leur action et leur objet. Prévoyez des zones d’activation utilisables au toucher et une indication de focus visible. Une suppression ou une validation doit rester associée à la bonne ligne même après un tri ou un filtrage.
Testez les menus près des bords du conteneur : un mécanisme de débordement peut les couper. Vérifiez également les états désactivés, le chargement et les erreurs. Une ligne en cours de mise à jour doit conserver assez de contexte pour que l’utilisateur comprenne ce qui attend une confirmation. Ces comportements ne sont pas réglés automatiquement par le choix d’un framework CSS.
Faire une recette avec des données difficiles
Contrôlez aussi le sens des valeurs une fois la ligne triée. Un statut exprimé uniquement par un point coloré peut devenir incompréhensible hors de son contexte. Ajoutez un libellé lorsque c’est nécessaire et gardez les unités près des chiffres. Sur un petit écran, l’utilisateur voit parfois une fraction du tableau ; les repères doivent rester suffisants pour interpréter cette portion.
Utilisez des noms longs, des cellules vides, des valeurs importantes, plusieurs statuts et des textes traduits. Testez un écran étroit, une taille de police agrandie, le clavier et le défilement tactile. Demandez à une personne de retrouver une ligne et d’effectuer une action précise. Mesurez les hésitations et les retours en arrière plutôt que de valider uniquement l’absence de débordement dans une capture.
Notre expertise Tailwind CSS relie les maquettes aux contraintes réelles des interfaces. Pour faire adapter un tableau métier, présentez ses colonnes et les tâches prioritaires sur mobile. Nous pourrons choisir une structure et une recette qui préservent la lecture, les comparaisons et les actions nécessaires.
Pour approfondir : React : concevoir les états d’un formulaire qui ne perd pas la saisie.
