Le pattern que son créateur a fini par abandonner

Connaissez-vous le container/presentational pattern ? Peu importe la réponse : dans cet article, on s’intéresse surtout à son histoire. Ceci dit, si la réponse est non et que vous débutez dans le développement front-end, restez, vous êtes au bon endroit.

Ce n’est ni le seul “pattern” existant, ni une solution magique à tous vos problèmes d’architecture front-end. Mais c’est un concept structurant : comprendre ses origines, sa philosophie et ses limites est un vrai plus pour tout développeur.

Et au passage, on expliquera aussi pourquoi Google vous renvoie encore des résultats contradictoires quand vous cherchez “container/presentational pattern” [3].

Ce n’est pas un concept récent. On peut même dire que sa version moderne a plus de dix ans. Pourtant, sa simplicité apparente fait que chacun semble en avoir sa propre définition. En voici une qui servira de base à notre discussion :

Presentational components : Components that only care about how a specific data is shown to the user.

Container components : Components that mainly care about what data is shown by which component to the user.

Autrement dit, on sépare nos composants en deux catégories : ceux qui affichent, et ceux qui décident quoi afficher. Voilà, c’est tout rien de compliqué.

Sauf que, en creusant, on découvre autant de sources que de définitions [5]. Elles se ressemblent, mais ne sont jamais identiques, comme s’il n’existait pas de définition officielle. Et pour cause : vous ne trouverez ni trace de ce pattern sur refactoring.guru, ni dans le livre du Gang of Four. Il n’y a pas de source “officiel” qui maintiens et se rend responsable de la définition.

Pour comprendre son origine, il faut revenir à l’article qui a popularisé le terme dans la communauté front-end : en 2015, un article de Dan Abramov [1] présente ce pattern comme une approche élégante pour structurer une clean architecture en React.

45K 👏

Cet article a eu un impact énorme. Dan Abramov, cofondateur de Redux et développeur influent de l’écosystème React [13], n’était pas un inconnu. Et à l’époque, React était en pleine ascension : le Virtual DOM faisait sensation et tout le monde attendait les nouveautés du framework avec impatience.

Oui, on parle de React sans Hooks.

C’est donc logiquement que l’article d’Abramov est devenu la référence implicite du pattern. Mais il est essentiel de le rappeler : il ne l’a pas inventé. Il l’a simplement popularisé, car il y voyait un moyen simple de structurer le code.

I call them Container and Presentational components, but I also heard Fat and Skinny, Smart and Dumb, Stateful and Pure, Screens and Components, etc. These are not exactly the same, but the core idea is similar.

Autrement dit, le concept existait déjà sous d’autres noms. Alors d’où vient-il vraiment ?

Pour trouver ses racines, il faut remonter à 2004, lorsque Microsoft introduit le pattern MVVM (Model–View–ViewModel), inspiré du Presentation Model de Martin Fowler [9].

Le MVVM sépare clairement la logique métier de la logique de présentation d’une application, et permet de découpler la logique de l’interface utilisateur (UI) de son rendu. Ça commence à ressembler à quelque chose de familier, non ? Séparer la vue de la logique, exactement ce que cherche à faire le pattern container/presentational. La différence principale, ici, réside dans la notion de composant, absente du MVVM original.

Aujourd’hui, l’architecture component-based [4,7] est devenue la norme dans le développement front-end : React, Svelte, Angular, Vue… tous reposent sur ce principe. Mais cela n’a pas toujours été le cas [2].

À l’origine, les applications front-end étaient beaucoup plus monolithiques, souvent basées sur des structures MVC [8]. C’est dans ce contexte que naît Backbone.js en 2010, un des premiers frameworks populaires à s’appuyer sur le MVC [6]. Peu après, AngularJS apporte un two-way data binding plus dynamique, se rapprochant du MVVM, mais sans encore adopter une architecture orientée composants.

Il faut attendre 2013, avec React, pour voir apparaître une architecture réellement component-based. React influence alors l’ensemble des frameworks qui suivront [11,12].

Avec cette évolution, le pattern MVVM s’adapte : la séparation interface/logiciel demeure, mais elle s’incarne désormais dans les composants eux-mêmes. Le rôle du ViewModel est en grande partie absorbé par la logique du composant.

Nous voilà en 2015.

La boucle est bouclée : le pattern container/presentational est formalisé sur Medium par Dan Abramov.

Retournement de situation en 2019, Dan Abramov met à jour son article. Il y explique qu’il ne recommande plus d’utiliser ce pattern. Et si vous avez déjà travaillé avec React, la raison est évidente : l’arrivée des Hooks rend souvent cette séparation superflue [3].

Pattern c’est vraiment le terme ?

J’attire votre attention sur la notion de ‘pattern’. Le Dumb/Smart n’a jamais été validé par une instance de référence. C’est un pattern “communautaire”, né de l’adaptation naturelle des développeurs à de nouveaux moyens techniques.

C’est une évolution presque organique de l’écosystème front-end. On peut donc se demander si le terme “pattern” est vraiment légitime.

Un pattern au sens classique : celui du Gang of Four, c’est une solution nommée, documentée, avec un contexte d’application précis et des compromis explicites. Le container/presentational ne coche pas ces cases. Pas de documentation de référence, pas d’instance qui en maintient la définition, et comme on l’a vu, un auteur qui finit par se rétracter.

On pourrait donc dire que c’est davantage une convention partagée qu’un pattern à proprement parler. Une pratique qui a émergé naturellement, s’est diffusée par l’usage, et s’est stabilisée autour d’une idée centrale sans jamais se cristalliser en définition unique.

Mais c’est là que ça devient intéressant. Le GoF date de 1994. L’écosystème front-end moderne n’existait pas. Les patterns d’aujourd’hui n’émergent plus dans des livres académiques, ils naissent sur Medium, se discutent sur GitHub, se valident en production dans des milliers de projets. Est-ce que ça les rend moins légitimes ?

Et c’est précisément cette absence de définition canonique qui répond à la question posée en introduction : pourquoi Google renvoie-t-il des résultats contradictoires quand on cherche “container/presentational pattern” ? Ce n’est pas une erreur, ce n’est pas un manque de sources correctes. C’est le reflet fidèle de la nature même du concept. Chaque développeur qui a écrit sur le sujet l’a fait depuis sa propre expérience, son propre framework. Il n’existe pas de source à laquelle se référer pour départager les interprétations.

C’est inconfortable si on cherche une réponse définitive. C’est fascinant si on accepte que certaines idées structurantes du développement fonctionnent ainsi : non pas imposées par le haut, mais construites collectivement par une communauté qui résout les mêmes problèmes avec les mêmes outils.

Alors, ce pattern est-il mort ?

Pas tout à fait. Dan Abramov a bien mis à jour son article en 2019 pour expliquer que les Hooks React rendent cette séparation souvent superflue. Mais cette conclusion ne vaut que pour React et l’écosystème web ne se résume pas à un seul framework.

Dans Vue.js, Angular, dans Svelte, la question de séparer logique et présentation reste entière et pertinente. Le pattern n’a pas disparu : il s’est adapté, d’ailleurs dans react aussi simplement on ne le fait plus de la même manière.

Pour rappel

On a commencé par la brique de base : un bon composant, c’est un contexte clair et une responsabilité unique. Ni trop large, ni trop flou. C’est le fondement sans lequel aucune architecture ne tient.

On a ensuite vu comment organiser ces composants entre eux grâce au pattern smart/dumb. Les composants atomiques et moléculaires gèrent l’affichage. Les pages gèrent la logique, les appels HTTP, la transformation des données. Le flux descend, ne remonte jamais. Quand un bug apparaît, vous savez exactement où chercher.

Cet article ajoute la dernière couche : ce n’est pas un pattern sorti de nulle part. Il est le produit d’une évolution organique de l’écosystème front-end. Le comprendre dans son histoire, c’est comprendre pourquoi la séparation logique/vue n’est pas un dogme à appliquer mécaniquement, mais un principe à adapter à son contexte.

Ce qui ne change pas, en revanche, c’est l’enjeu derrière tout ça : la maintenabilité. Une base de code que personne ne comprend six mois plus tard n’est pas une base de code, c’est une dette.

L’architecture front-end est souvent traitée comme un détail, repoussée au moment où “le projet sera plus stable”. C’est exactement l’inverse qu’il faut faire. Les décisions structurelles prises au début d’un projet sont celles qu’on paie et dont on bénéficie pendant des années.

Source

1. Abramov, D. (2019, 17 février). Presentational and Container Components — Dan Abramov — Medium. Medium. https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0
2. Barroca, L., Hall, J., & Hall, P. (2000). An Introduction and History of Software Architectures, Components, and Reuse. Dans Springer eBooks (p. 1‑11). https://doi.org/10.1007/978-1-4471-0367-7_1
3. Borenkraout, M. (2024, 2 octobre). Why you should stop using the “container/presentational” pattern in Redux. Medium. https://medium.com/@matanbobi/why-you-should-stop-using-the-container-presentational-pattern-in-redux-29b112406128
4. Component-Based Architecture and Design : A Practical Guide with Examples. (s. d.). Maruti Techlabs. https://marutitech.com/guide-to-component-based-architecture/
5. Container/Presentational pattern. (s. d.). https://www.patterns.dev/react/presentational-container-pattern/
6. Crudu, V. (2025, 23 juin). Debunking Common Myths About Backbone.js in Developer Forums. MoldStud — Custom Software Development Company. https://moldstud.com/articles/p-debunking-common-myths-about-backbonejs-in-developer-forums
7. Das, A., & Das, A. (2024a, août 25). Ultimate Guide to Component-Based Architecture in Web Development. PixelFreeStudio Blog -. https://blog.pixelfreestudio.com/ultimate-guide-to-component-based-architecture-in-web-development/
8. Das, A., & Das, A. (2024b, août 29). The Impact of Component-Based Architecture on Web Performance — PixelFreeStudio Blog. PixelFreeStudio Blog -. https://blog.pixelfreestudio.com/the-impact-of-component-based-architecture-on-web-performance/
9. Fowler, M. (s. d.). Presentation model. http://martinfowler.com . https://martinfowler.com/eaaDev/PresentationModel.html
10. Kothapalli, M. (2024). The Evolution of Component-Based Architecture in Front-End Development. Zenodo. https://doi.org/10.5281/zenodo.12772844
11. Suranga, S. (2025, 12 février). A guide to modern frontend architecture patterns — LogRocket Blog. LogRocket Blog. https://blog.logrocket.com/guide-modern-frontend-architecture-patterns/
12. Wanyoike, M. (2024, 4 juin). History of front-end frameworks — LogRocket Blog. LogRocket Blog. https://blog.logrocket.com/history-of-frontend-frameworks/
13. Polycube AI Studio. (2024, 4 novembre). Dan Abramov : pionnier de Redux et visionnaire du développement JavaScript. Best Speakers. https://bestspeakers.blog/2024/11/04/dan-abramov-pionnier-de-redux-et-visionnaire-du-developpement-javascript/