Naviguez vers la page de liste. Dès l’affichage, le DataTable déclenche une requête de récupération des éléments avec les paramètres par défaut (page initiale, taille par défaut, filtres et tri sauvegardés si présents).

Le tableau doit afficher un loader général (overlay léger ou skeleton rows). Informez l’utilisateur que le contenu est en cours de chargement pour éviter les clics répétés.

Dès que la première page arrive, afficher les lignes, puis les métadonnées (total d’éléments, pages totales). Mettre à jour l’état “chargé”.

Si des compteurs (badges) ou agrégations sont affichés, lancez leur chargement séparément afin de ne pas retarder l’affichage principal. Pour les jeux volumineux, chargez ces agrégations en pages pour éviter les temps de réponse longs.

Si la requête échoue, montrez un message clair avec action possible (Réessayer). Si aucune donnée, affichez un état “vide” avec suggestion d’actions (créer un élément, élargir les filtres).

L’utilisateur applique un filtre ou clique sur l’en-tête de colonne pour trier. Indiquez visuellement que la requête va se relancer (icône spinner ou état désactivé pendant la requête).

• Tri simple : cliquer une fois → ordre croissant, cliquer deux fois → décroissant, trois clics → annuler le tri.
• Tri multi-colonne (si activé) : maintenez la touche dédiée ou utilisez l’UI prévue pour empiler les critères. Affichez une pastille résumant les critères actifs.

Envoyez la demande avec les critères actuels (filtres + tri + page). Affichez un petit loader sur la table ou seulement sur la colonne triée pour limiter le jitter visuel.

À la réponse, mettez à jour les lignes, l’état de pagination et l’indicateur de tri (flèche ascendante/descendante). Conservez la mémoire du tri pour la navigation (back/forward).

Si la table a des paramètres personnalisés (colonnes visibles, tri, filtres), proposez une option pour enregistrer la vue ou restaurer les préférences.

Décidez de l’approche adaptée : pagination par page (offset) ou par curseur/infinite scroll selon la volumétrie et la nature des données (voir tableau comparatif).

• Navigation page par page : boutons Précédent/Suivant + saisie de numéro de page.
• Taille de page : permettre 10/25/50/100 résultats par page. Indiquez le total d’éléments pour informer.

Si vous utilisez infinite scroll, chargez la page suivante automatiquement quand l’utilisateur approche du bas. Affichez un loader inline et une action “Charger plus” en fallback.

• Changer la taille de page : recalculer la vue et renvoyer la requête.
• Aller à une page précise : valider l’existence de la page (basée sur le total) et charger.

Lors d’un clic sur un élément qui ouvre un détail, conservez la page courante et le scroll pour pouvoir revenir à la même position après fermeture.

Affichez un loader central pour la première requête. Pour les requêtes suivantes (filtres/tri/pagination), affichez un loader local (sur le tableau ou sur le header) afin de ne pas masquer l’ensemble de la page.

Affichez un message clair (ex : “Impossible de charger la liste”), une action “Réessayer” et un bouton pour contacter le support si besoin. Conservez les paramètres du tableau pour réessayer sans perte d’état.

Si aucune ligne : montrer une carte vide avec : explication courte, actions recommandées (créer, supprimer les filtres, modifier la période) et lien vers l’aide.

Pour les tableaux avec totaux/agrégations, affichez les lignes immédiatement et un état de chargement séparé pour les métriques. Utilisez des valeurs partielles suivies d’une mise à jour.

Proposez un bouton “Réessayer” et mettez en place un comportement de backoff côté client si l’échec est répété (montrer un message adapté après 3 tentatives).

Si l’utilisateur ajoute/modifie un élément depuis la liste, choisissez entre : rafraîchir la page courante (préserver position) ou recharger la liste depuis la page 1 selon la nature du changement.

Après suppression, si on vide la page courante, remonter automatiquement d’une page si celle-ci devient vide, pour éviter d’afficher une page sans résultats.

Pour exporter, proposer deux modes : exporter la page courante (rapide) ou exporter la totalité (asynchrone si volumineux) avec notification lorsque prêt.

Pour les dashboards contenant plusieurs DataTables, implémentez des rafraîchissements ciblés (une table à la fois) afin d’éviter la surcharge réseau.