The Patterns We Don't Name - Christian Johansen - NDC Oslo 2026

The Patterns We Don't Name - Christian Johansen - NDC Oslo 2026

Les schémas que nous ne nommons pas - Christian Johansen - NDC Oslo 2026

par Christian Johansen · Voir la chaîne sur PSI

Sciences appliquées & ingénierie Informatique & Cybersécurité UMProgrammation informatiqueUMZGénie logiciel
🎙 Christian Johansen 👥 230K 📅 13 octobre 2026 ⏱ 46 min 👁 19 📄 conférence technique 🧭 2026-10-13
Disponible en : Français (actuel) English

Mots-clés

patternsarchitecturepagescommandesCQRS

Résumé

Christian Johansen, développeur expérimenté, propose une approche pratique de l’architecture logicielle. Il constate que les systèmes grandissant, des concepts importants pour l’équipe (comme les « pages ») sont souvent dispersés dans le code et ne sont pas nommés explicitement. Il propose de rendre ces concepts « first class » en les modélisant comme des structures de données explicites. À partir d’exemples issus de son travail (une application d’inspection sanitaire), il montre comment définir des « pages » avec route, données et rendu, puis comment générer le code de routage à partir de ces définitions. Il introduit ensuite des « commandes » pour représenter les modifications souhaitées, s’inspirant de CQRS, ce qui permet de centraliser validation, autorisation et observabilité. L’accent est mis sur la réduction de la fatigue décisionnelle et l’augmentation de la cohérence. La présentation se termine par une analogie avec le jeu Jeopardy pour souligner que les bons choix architecturaux viennent souvent de la reconnaissance de schémas récurrents.

159 mots

Évaluation critique

Valeur des informations & solidité de l’argumentation

La valeur de cette présentation réside dans l’illustration concrète d’une démarche d’architecture émergente, basée sur l’identification de patterns réels dans le code plutôt que sur une conception descendante. L’argumentation est solide : l’orateur s’appuie sur des exemples de code réels, explique les bénéfices en termes de maintenabilité et de cohérence, et démontre comment de petites contraintes donnent levier au système. La progression logique (passer des pages aux commandes) est bien construite et les choix sont justifiés. La démonstration des extensions via un simple réglage (rendu client, streaming) illustre efficacement le gain de flexibilité obtenu par la centralisation.

Rigueur scientifique, qualité des sources, adéquation du titre

La rigueur scientifique est correcte : l’auteur cite des concepts reconnus (CQRS, DDD) et s’appuie sur son expérience en production. Il admet que les exemples ne sont pas directement réutilisables mais servent à illustrer un processus. Les sources externes se limitent aux conférences NDC, aucune référence académique n’est donnée, mais cela reste acceptable pour une conférence technique. L’adéquation titre/contenu est excellente : le titre « The Patterns We Don’t Name » résume parfaitement la thèse centrale. La présentation est cohérente et les exemples étayent l’argumentation.

197 mots

Adéquation titre / contenu

Le titre évoque les modèles (patterns) implicites dans le code ; le contenu illustre précisément comment identifier, nommer et modéliser ces patterns pour les rendre explicites.

Qualité & fiabilité

8/10

Exposé clair et structuré, s'appuyant sur une expérience pratique concrète et des principes reconnus (CQRS, DDD). Les exemples sont issus d'un système réel en production. La démonstration est cohérente et les choix architecturaux sont justifiés.

Moments clés

Repères établis par PSI à partir de la transcription : le créateur n'a pas défini de chapitres.

Sources citées

  • NDC Conferences — Organisation des conférences NDC, où cette présentation a été enregistrée
  • NDC Oslo — Site de la conférence NDC Oslo 2026

Sources concordantes

Apport & nouveautés

L’apport original de cette présentation est de proposer une méthode concrète pour identifier et rendre explicites les patterns implicites du code, en les transformant en concepts de premier ordre (pages, commandes) via des structures de données. Cette approche permet de réduire la complexité et d’augmenter la cohérence, tout en offrant un levier pour ajouter des fonctionnalités transversales. Le processus de nommer et modéliser ces patterns est transférable à d’autres contextes.

Pour aller plus loin :

  • Domain-Driven Design (DDD) — Fondamentaux pour modéliser le domaine métier, source d’inspiration pour les patterns techniques.
  • Command Query Responsibility Segregation (CQRS) — Pattern mentionné explicitement, dont s’inspire le système de commandes.
  • Event Sourcing — Complément naturel au flux persistant de commandes évoqué dans la présentation.
  • Clojure — Langage utilisé dans les exemples de production, illustrant la programmation fonctionnelle.

133 mots

Profil radar

Le profil est équilibré, avec une qualité et une fiabilité élevées, un niveau technique correct et une quantité d'informations substantielle. Le point le plus faible est le niveau technique, car l'exposé reste accessible sans plonger dans les détails d'implémentation.

Fiabilité 8/10