Modal ou nouvelle page ? La règle simple pour éviter les interfaces pénibles

Pourquoi ce choix compte vraiment

Une modal n'est pas "une petite page". Une page dédiée n'est pas "une grosse modal". Les deux composants servent des objectifs différents.

Quand tu utilises une modal, tu gardes l'utilisateur dans son contexte. C'est pratique pour modifier un champ, confirmer une action, ou consulter un détail rapide. Mais si la tâche demande du temps, plusieurs étapes, de la lecture, ou une vraie navigation, la modal devient vite agaçante.

Selon Modal vs. Separate Page: UX Décision Tree par Vitaly Friedman, les overlays mal placés cassent souvent le flux de travail. Je le vois souvent dans des outils métiers : on veut aller vite, puis on finit avec une fenêtre qui bloque tout, au mauvais moment, avec un bouton "Fermer" trop discret. Résultat, l'utilisateur soupire, perd le fil, puis recommence.

Le bon réflexe, c'est de se poser une question très simple : est-ce que l'action doit rester dans le contexte actuel, ou est-ce qu'elle mérite son propre espace ?

Le test en 30 secondes

Avant de coder, je passe généralement par ce mini test.

Choisis une modal si

• l'action est courte
• la tâche est indépendante du reste de la page
• l'utilisateur a besoin d'un retour immédiat
• tu veux éviter une navigation complète
• la perte de contexte serait plus gênante qu'utile

Exemples :

• renommer un projet
• confirmer une suppression
• voir un aperçu rapide
• éditer un tag
• inviter un collègue

Choisis une page dédiée si

• l'utilisateur doit comparer plusieurs informations
• la saisie est longue
• la tâche demande plusieurs étapes
• il faut pouvoir revenir plus tard facilement
• le contenu a sa propre URL partageable

Exemples :

• formulaire de création complexe
• réglages avancés
• fiche complète d'un client
• tableau de bord détaillé
• gestion d'un workflow complet

Comparatif rapide

Le tableau est simple, mais il évite beaucoup d'erreurs. En consulting, j'ai vu trop de produits empiler des modales "parce que c'est plus rapide à shipper". En pratique, tu gagnes une demi-journée de dev et tu perds des heures d'utilisation côté produit.

Les erreurs que je vois tout le temps

La première erreur, c'est d'utiliser une modal pour du contenu qui mérite une URL. Une fiche client, par exemple, ouverte dans une modal sans adresse propre, c'est pénible. On ne peut pas la partager facilement, on ne peut pas la retrouver dans l'historique, et on perd l'indexation si le contenu doit être public.

La deuxième erreur, c'est la modal qui contient une autre modal. Là, on entre dans la zone "je fais ça en prod et je prie". Techniquement, c'est possible. Humainement, c'est souvent une mauvaise idée.

La troisième erreur, c'est l'overlay utilisé comme cache-misère pour éviter de structurer l'app. Si tu empiles tout dans une fenêtre flottante, tu crées un faux raccourci. Le produit paraît simple, mais l'utilisateur fait le boulot de navigation à ta place.

Règle pratique que j'utilise

Je fonctionne avec cette règle :

si la tâche est finie en moins de 15 secondes, la modal peut être une bonne option ; si l'utilisateur doit réfléchir, comparer ou revenir, une page dédiée est souvent meilleure.

Ce n'est pas une loi mathématique. C'est un repère de terrain. Dans un outil métier, une action courte peut rester rapide même si elle a de la valeur. À l'inverse, un "petit formulaire" peut devenir lourd dès qu'il y a des validations, des dépendances, ou des champs conditionnels.

Un exemple concret

Imagine un SaaS de gestion interne :

• "Modifier le statut" → modal
• "Créer un nouveau client" → page dédiée
• "Voir le détail d'une facture" → page dédiée si on veut naviguer dedans, modal si c'est juste un aperçu
• "Attribuer un responsable" → modal
• "Configurer le pipeline commercial" → page dédiée

Le sujet n'est pas la taille visuelle du composant. Le sujet, c'est la nature de la tâche.

Implémentation propre en TypeScript

Prenons un cas simple : tu veux ouvrir une modal si l'action est courte, sinon naviguer vers une page.

typescripttype ActionType = "quick-edit" | "details" | "create" | "settings";

type UxMode = "modal" | "page";

function decideUxMode(action: ActionType, hasOwnUrl: boolean, complexity: number): UxMode {
  if (hasOwnUrl) return "page";
  if (complexity >= 7) return "page";

  switch (action) {
    case "quick-edit":
      return "modal";
    case "details":
      return complexity <= 4 ? "modal" : "page";
    case "create":
      return complexity <= 3 ? "modal" : "page";
    case "settings":
      return "page";
  }
}

function openAction(action: ActionType) {
  const mode = decideUxMode(action, false, 5);

  if (mode === "modal") {
    // ouvrir une fenêtre légère
    console.log("Open modal");
    return;
  }

  // navigation dédiée
  window.location.href = `/app/${action}`;
}

Et côté accessibilité, on fait comment ?

Une modal mal faite est souvent plus cassante qu'une page. Le focus doit entrer dans la fenêtre, rester dedans, puis revenir à l'élément déclencheur à la fermeture. L'escape doit fonctionner. Le fond doit être géré correctement. Et si le contenu est important, le texte doit rester lisible sans gymnastique.

Une page dédiée est souvent plus simple à rendre accessible. Tu gardes les balises HTML normales, les titres, l'historique, les liens, le scroll naturel. Pour un outil métier, ça compte vite.

Si tu veux aller vite sans sacrifier l'UX, ma règle est claire : modal pour une action locale et courte, page pour tout ce qui ressemble à un vrai écran de travail.

Cas spécial : quand les deux sont bons

Parfois, les deux options sont défendables. Par exemple, une liste de clients avec un panneau latéral ou une modal de détails peut fonctionner. Mais dès qu'on veut éditer sérieusement l'objet, je préfère une page dédiée.

Pourquoi ? Parce que l'édition demande souvent :

• de revoir plusieurs champs
• de comparer des données
• de naviguer vers des sous-objets
• de sauvegarder sans perdre le contexte

Une modal peut afficher l'information. Une page peut porter le travail.

Conclusion

Le vrai sujet n'est pas "modal ou page", c'est "quelle friction tu veux imposer à l'utilisateur". Si la tâche est courte et locale, la modal fait gagner du temps. Si l'action mérite de l'espace, de la lecture, un historique ou une URL, la page dédiée est plus propre.

Si tu construis un produit web et que tu hésites entre les deux, je peux t'aider à faire le tri. Chez Pal'Temps, je conçois des interfaces et des outils sur mesure qui évitent les mauvais raccourcis et les UX bancales.

Sources

• Modal vs. Separate Page: UX Décision Tree — Vitaly Friedman, 2026-03-19, via Smashing Magazine