Design patterns : lesquels apprendre et quand les utiliser ?

Le moment où les noms ne suffisent plus

Quand j’accompagnais des stagiaires et des développeurs juniors, une question revenait : je connais MVC, j’ai entendu parler de Singleton, mais où est-ce que je les utilise concrètement ? Savoir reconnaître un nom laissait entière la difficulté de choisir une structure dans le code du projet.

On prenait alors un tableau blanc. On dessinait les composants et les données qui circulaient entre eux. Les flèches faisaient apparaître le problème : une prop traversait plusieurs couches sans y être utilisée, ou une règle métier se retrouvait recopiée dans plusieurs écrans. On pouvait enfin discuter d’une solution à partir de ce qui gênait réellement le travail.

C’est le point de départ que je conseille pour apprendre les design patterns : décrire la difficulté, puis comparer les réponses possibles. Voici quelques repères pour un projet frontend en JavaScript ou React.

Une donnée traverse trop de composants : regarder le Provider

Imaginons une préférence d’affichage utilisée par plusieurs composants éloignés dans l’arbre React. Des composants intermédiaires reçoivent cette valeur uniquement pour la transmettre. Ce passage de props à travers plusieurs niveaux est souvent appelé prop drilling.

Le pattern Provider donne une autre voie : placer la valeur dans un contexte, puis laisser les descendants concernés la lire avec useContext. Le Provider délimite la partie de l’arbre qui reçoit cette valeur. Le schéma de couverture montre le rôle de ce périmètre.

Quelques props restent faciles à suivre et rendent les dépendances visibles. Avant d’ajouter un contexte, je regarde aussi si une composition différente des composants raccourcirait leur trajet. Un Provider devient intéressant quand le passage intermédiaire complique vraiment les modifications. Il faut encore décider où vit l’état et qui peut le modifier : le contexte transporte une valeur, il ne définit pas à lui seul les règles de sa mise à jour.

Des composants répètent un comportement : extraire un hook ciblé

Deux écrans doivent réagir au même événement du navigateur et nettoyer leur abonnement quand ils disparaissent. Si cette logique est recopiée, une correction risque de ne toucher qu’un seul écran. Un hook personnalisé permet de regrouper ce comportement derrière un nom lié au besoin, par exemple useOnlineStatus pour suivre la connexion réseau.

Chaque appel conserve toutefois son propre état React local. Extraire usePanier puis l’appeler dans deux composants ne leur donne pas automatiquement un panier commun. Pour partager la même donnée, il faut choisir un propriétaire de l’état et un moyen de la transmettre, ou s’appuyer sur une source externe commune.

Une fonction qui calcule un résultat sans appeler de hook React peut rester une fonction ordinaire. Je réserve le préfixe use aux abstractions qui en ont besoin. Cela évite de lier inutilement une règle métier à React.

Une règle métier est éparpillée : commencer par un module

Prenons une règle fictive : une commande peut être expédiée lorsque son paiement est confirmé et son stock réservé. Si chaque écran recopie ces conditions, leur évolution demande de retrouver toutes les variantes. Je commencerais par extraire une fonction dans un module dédié.

type Commande = {
  paiement: "en-attente" | "confirme";
  stockReserve: boolean;
};

export function peutExpedier(commande: Commande): boolean {
  return commande.paiement === "confirme"
    && commande.stockReserve;
}

Les écrans peuvent utiliser cette fonction pour afficher leur décision. La règle se relit sans parcourir du JSX et se vérifie avec des entrées précises. Cet extrait illustre uniquement le calcul d’éligibilité ; il n’effectue aucune expédition et ne représente pas les règles complètes d’un commerce réel.

Le découpage en modules suffit parfois à clarifier le code. Si deux règles semblables répondent à des besoins métier différents, les réunir trop tôt peut au contraire les rendre difficiles à faire évoluer séparément. Je vérifie d’abord qu’elles doivent changer ensemble.

Un état global devient confus : vérifier sa portée avant Singleton

Singleton vise à fournir une instance unique dans un périmètre donné. Il peut correspondre à une ressource dont plusieurs instances poseraient un problème identifié. Le nom du pattern ne suffit donc pas à justifier un objet partagé pour toute l’application.

Un objet mutable accessible partout peut masquer les endroits qui le modifient et compliquer l’isolation des tests. Côté serveur, un état conservé dans un module peut aussi survivre entre des requêtes : y ranger le panier d’un utilisateur crée un risque de partage avec d’autres utilisateurs. Avant ce choix, je précise la durée de vie attendue et les consommateurs. Une dépendance passée explicitement en paramètre peut être plus simple à remplacer pendant un test.

Utiliser Patterns.dev à partir d’un problème du projet

Patterns.dev est une ressource gratuite qui rassemble des patterns de conception, de rendu et de performance pour les applications web, avec des exemples JavaScript et React. Le site présente son catalogue comme un moyen de reconnaître des solutions possibles, sans en faire une liste à appliquer partout. C’est une ressource que j’aurais aimé avoir sous la main pour accompagner ces discussions au tableau blanc.

Pour commencer, je propose les pages Provider Pattern et Hooks Pattern si vous travaillez sur la circulation des données ou la réutilisation de logique React. La page Singleton Pattern permet ensuite d’examiner les contraintes d’une instance partagée. Les liens figurent dans les sources. Pour les API React, je croise les exemples avec la documentation officielle, notamment les explications sur le contexte et les hooks personnalisés.

Un exercice à faire sur la prochaine modification

Choisissez un endroit du projet qui ralentit une modification réelle. Avant de refactorer, écrivez ce qui pose problème et dessinez le chemin des données. Comparez ensuite la structure actuelle à une alternative, en gardant le même comportement attendu.

En binôme ou pendant un accompagnement, je demanderais au développeur d’expliquer où une prochaine règle serait ajoutée et ce qu’il faudrait vérifier. Si la réponse demande encore de parcourir des fichiers sans lien évident, le découpage mérite d’être repris. Le nom du pattern devient utile lorsqu’il permet à l’équipe de discuter précisément de ce choix et de ses limites.

Sources et liens utiles

• Patterns.dev : catalogue et démarche, consultés le 19 octobre 2026
• Patterns.dev : Provider Pattern
• Patterns.dev : Hooks Pattern
• Patterns.dev : Singleton Pattern et limites de l’état partagé
• React : transmettre des données en profondeur avec le contexte
• React : réutiliser de la logique avec des hooks personnalisés