Chapitre 0
Chapitre 00 — Introduction
Chapitre 00 — Introduction
Cours 00 — Introduction à l'Ingénierie Front-End Moderne
1. Pourquoi ce cours existe-t-il ?
1.1 Le constat
Le marché du front-end est saturé de développeurs capables d'utiliser React, Vue ou Angular, mais rares sont ceux qui comprennent vraiment comment ces frameworks fonctionnent, pourquoi ils existent, et quels problèmes ils résolvent. La plupart des formations actuelles se concentrent sur l'outillage et la syntaxe, négligeant les fondamentaux.
Le problème : Un développeur qui ne comprend que la surface des frameworks produit des applications :
- Lentes (ref lows excessifs, bundles surdimensionnés)
- Fragiles (couplage fort, absence de séparation des concerns)
- Inaccessibles (ignorance des normes WCAG)
- Non sécurisées (XSS, CSRF, injection)
- Difficiles à maintenir (dette technique architecturale)
1.2 La solution : une approche d'ingénieur
Ce cours adopte une approche radicalement différente :
- Pourquoi avant le comment
- Quel problème cette technologie résout-elle ?
- Quelles étaient les alternatives à l'époque ?
- Quelles sont les limites actuelles ?
- Quand l'utiliser et quand l'éviter ?
2. Ingénieur Front-End vs Développeur Front-End
2.1 Développeur Front-End
Un développeur front-end sait :
- Transformer une maquette en code
- Utiliser un framework (React, Vue, Angular)
- Faire des appels API
- Dépoyer une application
Le focus est sur la productivité immédiate.
2.2 Ingénieur Front-End
Un ingénieur front-end sait tout ce que sait un développeur, plus :
- Concevoir l'architecture d'une application (choix de patterns, organisation du code)
- Analyser et optimiser les performances (Core Web Vitals, bundle analysis)
- Garantir l'accessibilité (WCAG 2.2, ARIA)
- Assurer la sécurité (CSP, OWASP Top 10)
- Mettre en place des stratégies de rendu (CSR, SSR, SSG, ISR, RSC)
- Choisir et justifier chaque dépendance (cost-benefit analysis)
- Documenter les décisions architecturales (ADR)
- Mentorer et établir des standards d'équipe
2.3 La différence fondamentale
| Aspect | Développeur | Ingénieur |
|---|---|---|
| Question | "Comment faire ?" | "Pourquoi faire ainsi ?" |
| Portée | La feature | Le système |
| Horizon | Le sprint | L'année |
| Dette technique | La subit | La gère consciemment |
| Tests | Les ignore ou les subit | Les conçoit (stratégie) |
| Performance | Si ça marche | Si ça tient la route |
3. Les piliers du front-end moderne
3.1 HTML (HyperText Markup Language)
Ce n'est pas "juste du markup". L'HTML sémantique est le socle de l'accessibilité, du SEO, et de la maintenabilité.
Bonnes pratiques :
- Utiliser les éléments sémantiques (
<header>,<nav>,<main>,<article>,<section>,<aside>,<footer>) - Structure hiérarchique des titres (h1 → h6)
- Attributs ARIA en complément (pas en remplacement) de la sémantique native
langattribute sur<html>pour les lecteurs d'écran
Erreurs junior :
<div>pour tout- Titres choisis par taille visuelle et non par hiérarchie
- ARIA overuse sans comprendre les rôles implicites
3.2 CSS (Cascading Style Sheets)
CSS est un langage de déclaration de styles avec ses propres algorithmes complexes (cascade, spécificité, héritage).
Concepts clés :
- Cascade et spécificité (comprendre le score : inline > ID > class > tag)
- Box model (content-box vs border-box)
- Layout : Flexbox, Grid, Multicol
- Responsive design : media queries, clamp(), container queries
- Custom properties (variables CSS) vs preprocesseurs
Erreurs junior :
!importantsystématique- Spécificité excessive (nesting deep)
- Ignorer le stacking context
pxpour tout (ignorerrem,em,vw,vh,clamp())
3.3 JavaScript (ES2024+)
JavaScript n'est plus un "jouet". C'est un langage multi-paradigme avec un modèle d'exécution complexe.
Concepts fondamentaux :
- Closure, hoisting, event loop, prototypal inheritance
- Async : callbacks → promises → async/await → Observable (pattern)
- Modules : ES Modules vs CommonJS, tree-shaking
- Typage : TypeScript est devenu le standard de facto
Erreurs junior :
- Ignorer l'event loop (setTimeout(0) pour "vider la stack")
- Mutation non contrôlée des objets
- Import * sauvage sans tree-shaking awareness
- Ne pas gérer les erreurs dans les Promises
3.4 Accessibilité (a11y)
L'accessibilité n'est pas optionnelle. C'est un droit légal (RGAA, ADA, Section 508) et une obligation éthique.
Piliers :
- Perceptible : tout contenu doit être présenté d'au moins une façon
- Utilisable : composants d'interface navigables
- Compréhensible : contenu lisible, comportement prévisible
- Robuste : compatibilité avec les technologies d'assistance
Erreurs junior :
- "On fera l'a11y plus tard" (c'est 10x plus cher à corriger après)
- Contraste insuffisant (ratio 4.5:1 minimum)
- Navigation clavier non testée
- Messages d'erreur vagues
3.5 Performance
La performance est une fonctionnalité. Google l'utilise comme facteur de ranking (Core Web Vitals).
Métriques clés :
- LCP (Largest Contentful Paint) : < 2.5s
- FID (First Input Delay) : < 100ms → remplacé par INP (Interaction to Next Paint)
- CLS (Cumulative Layout Shift) : < 0.1
- TTFB (Time To First Byte) : < 800ms
Approches :
- Bundle splitting (code-splitting)
- Lazy loading (images, composants)
- Tree-shaking
- Optimisation des images (WebP, AVIF, responsive)
- Preload, prefetch, preconnect
3.6 Sécurité
Le front-end est la première ligne de défense. Même si la sécurité backend est cruciale, le front-end doit se protéger.
Top risques OWASP Front-End :
- XSS (Cross-Site Scripting) : injection de scripts via input non nettoyé
- CSRF (Cross-Site Request Forgery) : requêtes inter-sites
- Clickjacking : piège visuel
- Sensitive data exposure : clés API dans le bundle
- Dependency vulnerabilities : packages avec failles
4. Roadmap complète de la formation
┌─────────────────────────────────────────────────────────────┐
│ MODERN FRONT-END ENGINEERING │
├──────────┬──────────┬──────────┬──────────┬──────────┬──────┤
│ CH00 │ CH01 │ CH02 │ CH03 │ CH04 │ CH05 │
│ INTRO │ HIST │ BROWSER │ HTML │ CSS │ JS │
│ │ │ │ │ │ │ │
│ CH06 │ CH07 │ CH08 │ CH09 │ CH10 │ CH11 │
│ TS │ PERF │ SECU │ A11Y │ ARCH │ BUILD│
│ │ │ │ │ │ │
│ CH12 │ CH13 │ CH14 │ CH15 │ CH16 │ CH17 │
│ TEST │ REACT │ ROUTER │ STATE │ REND │ API │
│ │ │ │ │ │ │
│ CH18 │ CH19 │ CH20 │ CH21 │ CH22 │ CH23 │
│ CSS │ ANIM │ PWA │ WEB │ CI/CD │ MIC │
│ FRAMEW │ │ │ ASSEM │ │ RO │
│ │ │ │ │ │ │
│ CH24 │ CH25 │ CH26 │ CH27 │ CH28 │ CH29 │
│ DESIGN │ MONO │ PERF │ SEC │ DATA │ EDGE│
│ SYST │ REPO │ AUDIT │ AUDIT │ VIZ │ │
└──────────┴──────────┴──────────┴──────────┴──────────┴──────┘
5. Projet fil rouge : Enterprise ProjectHub
Tout au long de la formation, nous construirons Enterprise ProjectHub, une application de gestion de projets d'entreprise.
Spécifications fonctionnelles
- Dashboard avec métriques en temps réel
- Gestion de projets, tâches, utilisateurs
- Système de notifications
- Recherche full-text
- Export PDF/CSV
- Mode hors-ligne (PWA)
- i18n (FR, EN)
Spécifications techniques
- Architecture micro-frontends (Module Federation)
- RSC (Server Components) + SSR hybride
- Real-time avec WebSockets
- Tests : Unit (Vitest) + Integration (Playwright) + E2E (Playwright)
- CI/CD : GitHub Actions, déploiement sur Vercel + Cloudflare Workers
- Monitoring : Sentry, Lighthouse CI
Architecture initiale
projecthub/
├── apps/
│ ├── web/ # Application principale Next.js
│ ├── dashboard/ # Micro-frontend dashboard (RSC)
│ ├── projects/ # Micro-frontend projets (RSC)
│ └── notifications/ # Micro-frontend notifications
├── packages/
│ ├── ui/ # Design system (shadcn/ui)
│ ├── config/ # ESLint, TypeScript configs
│ ├── api/ # Client API partagé
│ └── types/ # Types partagés
├── tools/
│ └── storybook/ # Documentation des composants
├── turbo.json # Turborepo configuration
└── package.json # Workspaces
6. Configuration de l'environnement de travail
6.1 Node.js
# Installation via nvm (Windows : nvm-windows)
nvm install --lts
nvm use --lts
node --version # ≥ 20.x
npm --version # ≥ 10.x
# Ou utiliser fnm (plus rapide)
fnm install --lts
fnm use lts-latest
Pourquoi nvm/fnm ? Différents projets peuvent nécessiter différentes versions de Node. NVM permet de basculer instantanément.
6.2 VS Code
Extensions obligatoires :
- ESLint (dbaeumer.vscode-eslint)
- Prettier (esbenp.prettier-vscode)
- Tailwind CSS IntelliSense (bradlc.vscode-tailwindcss)
- Error Lens (usernamehw.errorlens)
- GitLens (eamodio.gitlens)
- Thunder Client (rangav.vscode-thunder-client)
6.3 Git
git config --global user.name "Votre Nom"
git config --global user.email "votre@email.com"
git config --global init.defaultBranch main
git config --global core.autocrlf input # Windows: true
6.4 Configuration du projet
# Création du projet avec Vite
npm create vite@latest projecthub -- --template react-ts
cd projecthub
npm install
# Configuration ESLint
npm init @eslint/config
# Configuration Prettier
npm install -D prettier eslint-config-prettier
echo '{"semi": true, "singleQuote": true, "trailingComma": "all"}' > .prettierrc
7. Introduction aux outils
7.1 Vite
Pourquoi Vite plutôt que Webpack/CRA ?
Vite résout un problème fondamental : le temps de démarrage des dev servers avec Webpack augmente linéairement avec la taille du projet. Vite utilise :
- ES Modules natifs en développement (pas de bundling)
- esbuild pour le pre-bundling (écrit en Go, 10-100x plus rapide que Terser)
- Rollup pour la production (optimisé)
# Comparaison des temps de démarrage
# Webpack (CRA) : 30-60s pour un projet moyen
# Vite : < 1s pour n'importe quelle taille
7.2 npm
# npm workspaces pour monorepo
npm init -w packages/ui
npm install -w apps/web react
# npm audit
npm audit # Vérifier les vulnérabilités
npm audit fix # Corriger automatiquement
npm outdated # Voir les dépendances obsolètes
7.3 ESLint
ESLint analyse statiquement le code pour trouver des problèmes avant l'exécution.
# flat config (ESLint 9+)
npm install -D eslint @eslint/js typescript-eslint
Pourquoi c'est important : Un linter attrape :
- Les erreurs potentielles (variable non utilisée, fall-through switch)
- Les anti-patterns
- Les problèmes de performance
- Les violations de style d'équipe
7.4 Prettier
Prettier est un formateur de code déterministe. Il élimine les débats de style dans une équipe.
Règle d'or : ESLint détecte les erreurs, Prettier formate le code. Les deux doivent coexister (eslint-config-prettier désactive les règles de style d'ESLint qui entrent en conflit).
7.5 Configuration combinée
// .vscode/settings.json
{
"editor.formatOnSave": true,
"editor.defaultFormatter": "esbenp.prettier-vscode",
"editor.codeActionsOnSave": {
"source.fixAll.eslint": "explicit"
}
}
8. Erreurs de juniors vs pratiques de seniors
| Junior | Senior |
|---|---|
| Installe toutes les extensions sans réfléchir | Sélectionne chaque outil avec une analyse coût/bénéfice |
Utilise npm install -g pour tout | Utilise npx ou les scripts npm |
| Ignore les warnings ESLint | Configure ESLint pour son équipe |
| Formate manuellement le code | Automatise tout (format on save, pre-commit hooks) |
Un seul fichier index.js de 2000 lignes | Architecture modulaire dès le début |
| "Ça marche, on déploie" | "Ça marche, mais est-ce que c'est maintenable, testé, performant, accessible ?" |