Un design pattern (patron de conception) est une solution type, éprouvée et réutilisable, à un problème de conception logicielle qui revient souvent. Ce n'est pas du code prêt à copier, mais un schéma d'organisation que l'on adapte à son contexte.
La notion a été popularisée en 1994 par le livre Design Patterns de quatre auteurs surnommés le « Gang of Four », qui décrit 23 patterns classés en trois familles : création (comment fabriquer des objets, par exemple Singleton ou Factory), structure (comment assembler des composants, par exemple Adapter ou Decorator) et comportement (comment ils communiquent, par exemple Observer ou Strategy).
Leur premier intérêt est le vocabulaire commun : dire « on passe par un Observer » suffit à une équipe pour comprendre l'intention. Bien utilisés, ils rendent le code plus lisible et plus facile à faire évoluer. Mal utilisés, ils ajoutent des couches d'abstraction inutiles. On parle aussi de patterns d'architecture (MVC, CQRS) à une échelle plus large.
Pourquoi ça compte quand on recrute
Réciter des noms de patterns ne prouve pas grand-chose. En entretien, demandez au candidat un cas où il a choisi un pattern et un cas où il l'a retiré parce qu'il compliquait le code. Le bon signal : il part du problème, pas du catalogue. Un profil junior qui en met partout est un classique ; un profil senior sait rester simple.