🧱 Framework — concept, histoire, types, choix & patterns

Définition : un framework est un cadre logiciel réutilisable (bibliothèques + conventions + points d’extension) qui structure une application, accélère le delivery et réduit l’entropie. Idée clé : le framework impose un workflow et une architecture par défaut (opinionated ou non), et fournit des hooks pour personnaliser sans “forker”. But : industrialiser : routing, DI, ORM, validation, auth, logs, tests, build, déploiement.

1.1

Framework — définition “pro”

Cadre : conventions + composants + points d’extension. Il “porte” ton app via un cycle de vie (request → response, job, event).

ConceptConventionsExtensibility

Historique (timeline)

Du “library jungle” → inversion of control → web frameworks → full-stack → cloud-native & IA-assisted.

IoCMVCCloud

Types de frameworks

Web, backend, frontend, mobile, desktop, data/ML, test, infra. “Opinionated” vs “unopinionated”.

ClassificationStackScope

1.2

Architecture & cycle de vie

Middleware, routing, controller/handler, services, ORM, transactions, background jobs, events, observabilité.

LifecycleMiddlewareDI

Intérêt (pourquoi c’est ROI)

Vitesse, cohérence, sécurité, tests, observabilité, onboarding, intégrations. Le vrai gain : éviter l’entropie sur 2–5 ans.

ROIStandardOps

Compromis & lock-in

Le framework “dirige” ton architecture : upgrades, compat, dépendances, magic. Lock-in ≠ mauvais, mais doit être assumé.

UpgradesCompatibilityLock-in

Complexité & anti-patterns

“Tout mettre dans controllers”, sessions gigantesques, ORM mal compris, migrations cassées, “magic” non testée, upgrades figées.

RisquesDebtMaintenance

Choisir un framework

Critères : perf, DX, écosystème, longévité, sécurité, skills, CI/CD, cloud, observabilité, licence, gouvernance.

DecisionCriteriaEcosystem

KPIs & qualité

p95 request, error rate, migrations success, time-to-merge, onboarding, security posture, lead time change, incidents.

KPISLOQuality

2.1

Extensibilité : hooks, plugins, middlewares

Bien utiliser un framework = respecter ses points d’extension. Éviter de “hacker” le core. Structurer modules & packages.

HooksPluginsClean

Upgrades & compatibilité

Politique versions, migration progressive, tests de régression, pinning deps. Un framework figé = dette exponentielle.

SemVerRegressionRelease

Playbook : cadrer un projet framework

Starter kit, conventions, modules, tests, logging, CI, migrations, secrets, monitoring, runbook, ADRs.

StarterADRsRunbook

★

Cheat-sheet Framework

Définition, différences lib/framework, types, pièges, patterns, critères de choix, “exigences prod”.

ChecklistPatternsProd

Framework — overview densifié (cadre, lifecycle, conventions, risques, décision)

Mental model (à retenir)

Conventionsstructure projet, naming, wiring “standard”

Lifecyclerequest/event/job → pipeline → response

IoC / DIle framework “appelle ton code” (inversion de contrôle)

Extension pointsmiddleware, hooks, plugins, interceptors

Cross-cuttingauth, validation, logging, errors, metrics

ToolingCLI, scaffolding, build, tests, dev server

Opsconfig, secrets, migrations, health checks

Pourquoi un framework “gagne” sur la durée

Levier	Effet	Exemple
Standardisation	moins d’entropie	mêmes patterns partout
Écosystème	réduction effort	plugins, libs, docs
Sécurité	garde-fous	middlewares, auth patterns
Observabilité	diagnostic rapide	logging/metrics intégrés

La vérité terrain (compromis)

Un framework te fait gagner du temps…
…mais te fait accepter des choix :

- une architecture par défaut (MVC, DI, etc.)
- une façon de configurer et déployer
- un rythme d'upgrade
- une “magie” interne (reflection, codegen, runtime)

=> succès = comprendre le lifecycle + respecter les extension points.

Différence clé : une lib est appelée par ton code. Un framework appelle ton code (IoC).

Checklist “framework-ready” (ultra court)

Architecture documentée (modules, boundaries).
Config séparée par env + secrets.
Migrations gérées & testées.
Logs/metrics standardisés.
Upgrades planifiés (pas de “freeze”).

1.1 Définition — Framework : cadre + IoC + conventions + points d’extension

Définition “engineering”

Un framework est un ensemble cohérent (code + conventions + outillage) qui fournit un cadre d’exécution : il définit un cycle de vie (requête, job, event…), fournit des composants standard (routing, validation, DI, ORM…) et expose des points d’extension (hooks/middlewares/plugins) pour brancher la logique métier sans réécrire l’infrastructure.

Lifecycle

IoC

Hooks

Cross-cutting

Tooling

Promesse (cadrée)

Promesse	Vrai si…	Sinon…
Vitesse	conventions suivies	combats contre le framework
Qualité	tests + standards	magie non maîtrisée
Maintenabilité	modules/clean boundaries	spaghetti controllers

One-liner

Framework = "app skeleton" + runtime pipeline
          + conventions + extension points
          + tooling (dev/build/tests)

Si tu ne connais pas le pipeline (middleware, exceptions, transactions), tu utilises le framework “à l’aveugle”.

Lib vs Framework (différence fondamentale)

Aspect	Librairie	Framework
Contrôle	Ton code appelle la lib	Le framework appelle ton code (IoC)
Architecture	pas imposée	architecture par défaut
Tooling	souvent minimal	CLI, dev server, conventions
Extensibilité	APIs	hooks/middlewares/plugins

IoC / DI : pourquoi c’est central

Inversion of Control (IoC)

Dans un framework, le point d’entrée n’est pas ton code : c’est le runtime. Il exécute un pipeline et déclenche tes handlers au bon moment (routes, events, jobs).

Request -> Middleware -> Router -> Handler
           -> Services -> DB -> Response

Dependency Injection (DI)

La DI évite le “new partout” et rend la logique testable : tu relies des interfaces à des implémentations via un container.

IEmailSender -> SmtpEmailSender
IRepo        -> PgRepo
=> tests : IRepo -> FakeRepo

“Smell test” : est-ce vraiment un framework ?

Il y a un lifecycle (pipeline) + un point d’entrée standard ?
Il impose une structure (conventions) ?
Il “appelle ton code” via des handlers (IoC) ?
Il fournit des cross-cutting concerns (logs/auth/errors) ?
Il a des extension points (middleware/plugins) ?

Historique — frameworks : du “library jungle” au cloud-native (et l’IA)

Timeline (vision “industrie”)

Avant 2000

Bibliothèques : assemblage “à la main” (logging, config, DB…). Duplication, peu de standards.

2000–2010

Web frameworks : MVC, routing, templating, ORM, conventions → accélération & standardisation.

2010–2020

Full-stack & microservices : DI, middlewares, modules, outillage tests, packaging, configs multi-env, observabilité.

2020–…

Cloud-native : 12-factor, containers, health checks, tracing, config/secrets, autoscaling.

Aujourd’hui

IA-assisted : scaffolding intelligent, migration helpers, codegen, linting & security scanning assistés (avec risques si non testés).

Pattern qui ne change pas

Frameworks apparaissent quand :
- le coût d'assemblage des libs devient trop élevé
- la maintenance devient imprévisible
- l'onboarding devient lent
=> on standardise : structure + pipeline + tooling

Pourquoi ce n’est pas une mode

Problème	Réponse framework	Risque
Entropie	conventions + structure	rigidité si trop opinionated
Sécurité	middlewares + patterns	faux sentiment de sécurité
Qualité	tests & outillage	tests ignorés
Ops	health, metrics, config	complexité runtime

Un framework est une “décision d’organisation” autant qu’une décision technique.

Types de frameworks — cartographie (web, backend, frontend, mobile, data, test…)

Cartographie (familles)

Backend Webrouting, middleware, auth, ORM, jobs

Frontend UIcomponents, state, routing, build

MobileUI + runtime + packaging

Data/MLpipelines, training, serving

Testfixtures, runners, assertions

InfraIaC, deployments, policies

Exemples (illustration)

Famille	Exemples	Ce qu’ils “apportent”
Backend	Django, Spring, .NET, Laravel	pipeline web + ORM + tooling
Frontend	Angular, Next.js, Nuxt	structure app + build + routing
Mobile	Flutter, React Native (ecosystem)	UI + packaging multi-plateforme
Data	Airflow, MLflow	workflows & gouvernance
Test	pytest, JUnit	standardisation tests

Certains outils sont “framework-like” selon usage : ex. Next.js est plus qu’une lib React.

Opinionated vs unopinionated

Type	Avantage	Coût	Quand
Opinionated	vitesse + cohérence	flexibilité moindre	équipe multiple, long terme
Unopinionated	liberté	entropie possible	experts + architecture solide

Astuce :
- si l'équipe change souvent => opinionated gagne
- si le domaine est très atypique => unopinionated peut être nécessaire

Scope : framework “narrow” vs “broad”

Narrow (ciblé)

fait très bien 1 chose
composable
souvent moins de lock-in

Broad (plateforme)

stack complet
productivité + standardisation
upgrade/compat plus structurants

Architecture & cycle de vie — request pipeline, middleware, DI, transactions, jobs

Pipeline web “canonique”

HTTP Request
  -> Middleware (auth, rate-limit, logging, cors)
  -> Router
  -> Handler/Controller
  -> Service/UseCase
  -> Repository/ORM
  -> DB
  -> Response

Le framework fournit le pipeline et les “slots”. Ton code se place au bon niveau.

Jobs & events

User action -> Event -> Queue -> Worker
                 -> Retries / DLQ
                 -> Idempotency
                 -> Observability

Piège : pas d’idempotence + side effects non maîtrisés.

Cross-cutting concerns

Domaine	Ce que tu veux	Où
Auth/RBAC	policy enforce serveur	middleware + guards
Validation	contrats inputs	schema/DTO
Error handling	codes + corr_id	global handler
Observabilité	logs/metrics/traces	instrumentation
Config/Secrets	env-based, secure	config provider

Boundaries

HTTP Layer   : mapping, status, pagination, auth context
UseCase      : logique métier, transactions, invariants
Repo/DB      : accès données, requêtes explicites
Infra        : queue, cache, mail, storage

Intérêt — pourquoi un framework est ROI

Ce que tu “achètes”

Bénéfice	Évite	Exemple
DX	boilerplate	CLI, scaffolding
Standard	styles divergents	structure modules
Sécurité	auth bricolée	middlewares, guards
Qualité	tests ad hoc	fixtures, runner
Ops	prod opaque	health, logging, metrics

Gain “organisationnel”

Sans framework :
- config/log/errors/auth réinventés
- onboarding lent
- pratiques disparates

Avec framework :
- conventions partagées
- runbooks & observabilité plus simples
- maintenance moins artisanale

Compromis — lock-in, “magic”, upgrades

Lock-in : à assumer + à mitiger

Lock-in	Avantage	Coût	Mitigation
API framework	productivité	migration	isoler métier
Écosystème	plugins	dépendances	pin + audit
Conventions	cohérence	flex réduite	ADRs

Magic (utile vs dangereuse)

Utile :
- auto-wiring DI
- validation auto
- migrations

Dangereuse :
- queries implicites (N+1)
- transactions implicites
- caching invisible

Upgrades : la vraie dette si tu freezes

- suivre LTS
- upgrades réguliers
- tests régression
- staging fidèle prod
- pin deps + scanning vuln

Complexité & anti-patterns

Top risques

Risque	Cause	Impact
God Controllers	pas de service layer	tests difficiles
N+1 queries	ORM implicite	perfs
Configs divergentes	env non maîtrisés	bugs prod
Migrations cassées	discipline absente	downtime
Upgrades figées	peur regression	obsolescence

Symptômes

Métier mélangé à la couche HTTP.
Une page déclenche 200 queries DB.
Erreurs non uniformes (pas de corr_id).
Upgrades “impossibles”.

Remèdes

1) Boundaries : handler fin, service layer, repo
2) Observabilité : metrics + traces + corr_id
3) ORM discipline : joins, pagination
4) Config 12-factor + secrets manager
5) Upgrades réguliers + CI + staging

KPI	Mesure
Lead time	commit → prod
Time-to-merge	PR cycle
Onboarding	jours
Defect rate	bugs/sprint

KPI	Mesure
p95 latency	ms
Error rate	%
DB time	%
Deploy success	%

Playbook — starter kit framework “prod-ready”

Starter kit (checklist)

Bloc	Livrable	Gate
Structure	modules + naming	guidelines
Config/Secrets	env vars + secret store	no secrets in repo
DB	migrations + seed	rollback test
Auth/RBAC	policies + roles	tests roles
Errors	schema + corr_id	standard
Observabilité	logs + metrics + traces	dashboards
Tests	unit + integ + smoke	CI green
CI/CD	deploy staging	release process
Runbook	rollback + restore	exercices

Architecture contract

- Handler HTTP fin
- Métier en service layer
- Repo/DB explicite
- Auth/RBAC testée
- Observabilité standard
- Upgrades en cadence

🧱 Framework — concept, histoire, types, choix & patterns

Framework — définition “pro”

Historique (timeline)

Types de frameworks

Architecture & cycle de vie

Intérêt (pourquoi c’est ROI)

Compromis & lock-in

Complexité & anti-patterns

Choisir un framework

KPIs & qualité

Extensibilité : hooks, plugins, middlewares

Upgrades & compatibilité

Playbook : cadrer un projet framework

Cheat-sheet Framework

Mental model (à retenir)

Pourquoi un framework “gagne” sur la durée

La vérité terrain (compromis)

Checklist “framework-ready” (ultra court)

Définition “engineering”

Promesse (cadrée)

One-liner

Lib vs Framework (différence fondamentale)

IoC / DI : pourquoi c’est central

Inversion of Control (IoC)

Dependency Injection (DI)

“Smell test” : est-ce vraiment un framework ?

Timeline (vision “industrie”)

Pattern qui ne change pas

Pourquoi ce n’est pas une mode

Cartographie (familles)

Exemples (illustration)

Opinionated vs unopinionated

Scope : framework “narrow” vs “broad”

Narrow (ciblé)

Broad (plateforme)

Pipeline web “canonique”

Jobs & events

Cross-cutting concerns

Boundaries

Ce que tu “achètes”

Gain “organisationnel”

Lock-in : à assumer + à mitiger

Magic (utile vs dangereuse)

Upgrades : la vraie dette si tu freezes

Top risques

Symptômes

Remèdes

Critères (top 12)

Heuristique

Delivery

Runtime

Hooks & middleware

Plugins

Règles

Pourquoi freeze = dette

Politique

Checklist upgrade

Starter kit (checklist)

Architecture contract

30 règles (checklist)

Résumé

Phrase IDEO-Lab