Module 4Préparer l'environnement de développement web
Chapitre 11 sur 12
Frameworks front-end, CSS et back-end, architectures full stack et grille de décision pondérée.
Objectifs
Avec ce chapitre, tu sauras…
:::savoir Un chapitre rédigé à partir du programme Ce chapitre suit l'intitulé officiel « Choisir les Frameworks de développement web ». Le paysage des frameworks change vite : les principes de choix comptent plus que la liste du moment. Vérifie toujours la version actuelle sur le site officiel avant de démarrer un projet. :::
Leçon 1
| Bibliothèque | Framework | |
|---|---|---|
| qui appelle qui ? | ton code appelle la bibliothèque quand il en a besoin | le framework appelle ton code au bon moment : c'est l'inversion de contrôle |
| liberté | grande : tu choisis la structure | encadrée : tu suis les conventions |
| exemples | jQuery, Chart.js, Monolog, React (au sens strict) | Laravel, Symfony, Angular, Django |
| Avantages d'un framework | Inconvénients |
|---|---|
| on ne réinvente pas la roue : routage, formulaires, authentification, ORM déjà prêts | une courbe d'apprentissage |
| sécurité intégrée : protection CSRF, échappement, requêtes préparées | une dépendance au framework et à ses mises à jour |
| code organisé (souvent en MVC, module M107) et conventions partagées : un développeur qui connaît Laravel s'y retrouve dans n'importe quel projet Laravel | un poids parfois inutile pour un très petit site |
| grande communauté, documentation, paquets réutilisables | des choix imposés |
Vidéo · À regarder
FRLeçon 2
| React | Angular | Vue.js | |
|---|---|---|---|
| origine | Meta (Facebook), 2013 | Google, 2016 (successeur d'AngularJS) | Evan You, 2014, projet communautaire |
| nature | une bibliothèque d'interface, complétée par d'autres outils (routage, état) | un framework complet (routage, formulaires, HTTP, tests) | un framework progressif : on peut l'ajouter à une seule page ou bâtir toute une application |
| langage |
Leçon 3
| Framework | Langage | Points forts |
|---|---|---|
| Laravel | PHP | le plus populaire en PHP ; syntaxe élégante ; ORM Eloquent, moteur de gabarits Blade, migrations, authentification, files d'attente ; très bonne documentation ; écosystème (Livewire, Inertia) |
| Symfony | PHP | robuste et modulaire ; composants réutilisés par de nombreux projets (dont Laravel) ; ORM Doctrine ; très utilisé en entreprise, notamment en France |
| Express | JavaScript (Node.js) | minimaliste, idéal pour une API REST ; un seul langage côté client et serveur |
Leçon 4
| Architecture | Principe | Exemple |
|---|---|---|
| monolithe MVC avec rendu côté serveur | le back-end produit les pages HTML (module M107) | Laravel + Blade (+ Livewire pour l'interactivité) ; Symfony + Twig |
| API + SPA (application monopage) | le back-end expose une API REST (en JSON) ; le front-end, une application JavaScript séparée, l'appelle | Laravel ou Express (API) + React, Vue ou Angular |
| pile JavaScript complète | le même langage partout | MERN : MongoDB, Express, React, Node.js ; ou MEAN avec Angular |
Leçon 5
| Critère (poids) | Laravel + Blade | Laravel (API) + Vue | Express + React (MERN) |
|---|---|---|---|
| compétences de l'équipe (5) | 5 | 4 | 2 |
| adapté au besoin : boutique avec administration (4) | 5 | 4 | 3 |
1La principale différence entre une bibliothèque et un framework est…
2Le framework front-end qui impose TypeScript est…
3Next.js est un méta-framework pour…
4L'ORM de Laravel s'appelle…
5Une pile MERN utilise…
6Tailwind CSS repose sur…
7Pour un blog d'entreprise sans règle métier spécifique, on choisit souvent…
8La commande qui crée un projet Laravel est…
L'essentiel du chapitre
| JavaScript ou TypeScript, avec la syntaxe JSX |
| TypeScript obligatoire |
JavaScript ou TypeScript, composants monofichiers .vue |
| apprentissage | moyen | plus long (beaucoup de concepts) | le plus facile |
| usages typiques | très répandu, énorme écosystème ; applications mobiles avec React Native | grandes applications d'entreprise, équipes nombreuses | du petit widget à l'application complète ; associé souvent à Laravel |
| méta-framework | Next.js | (intégré) | Nuxt |
| Bootstrap | Tailwind CSS | |
|---|---|---|
| approche | des composants prêts à l'emploi (.btn, .card, .navbar) et une grille de 12 colonnes | des classes utilitaires : une classe par propriété (flex, p-4, text-lg, bg-blue-600) |
| avantage | rapide pour un site standard, vu en 1re année | design sur mesure fidèle à la maquette Figma, fichier CSS final léger |
| inconvénient | les sites se ressemblent si on ne personnalise pas | HTML chargé de classes |
| NestJS | TypeScript (Node.js) | structuré, inspiré d'Angular ; grandes API |
| Django | Python | « piles incluses » : administration générée, ORM, sécurité ; très bon pour les projets avec des données et de l'IA |
| Spring Boot | Java | standard des grandes entreprises et des banques |
| ASP.NET Core | C# | écosystème Microsoft, performances élevées |
| méta-framework | rendu serveur et client dans un même projet | Next.js, Nuxt |
| microservices | plusieurs petits services indépendants, chacun avec sa base, qui communiquent par API | pour de grandes plateformes ; trop complexe pour un premier projet |
Vidéo · À regarder
FR5 Min pour comprendre le Back End et le Front End
YouTube (FR) · YouTube
| hébergement disponible : mutualisé PHP (3) |
| 5 |
| 4 |
| 1 |
| interactivité de l'interface (2) | 3 | 5 | 5 |
| communauté et documentation (2) | 5 | 5 | 5 |
| total (note × poids) | 5×5 + 5×4 + 5×3 + 3×2 + 5×2 = 76 | 4×5 + 4×4 + 4×3 + 5×2 + 5×2 = 68 | 2×5 + 3×4 + 1×3 + 5×2 + 5×2 = 45 |
Un CMS (Content Management System, système de gestion de contenu) comme WordPress, Drupal ou Joomla est une application déjà construite qu'on configure (thèmes, extensions) plutôt qu'on ne la programme. Il convient aux sites de contenu (vitrine, blog, petite boutique avec WooCommerce). Dès que les règles métier sont spécifiques (gestion de stocks par magasin, réservations, calculs), un framework est plus adapté.
Ce que tu vas voir (vidéo courte, entièrement sur ce sujet) : ce qu'est un framework : une boîte à outils et un cadre de travail qui évitent de tout réécrire, et la différence avec une simple bibliothèque. Elle reprend la définition de cette section.
Ils construisent des interfaces dynamiques à partir de composants réutilisables (comme les composants Figma du chapitre 9), et s'exécutent dans le navigateur.
Les critères de choix
Rédige la partie « Choix techniques » de ton dossier de conception : (1) l'architecture retenue avec un schéma ; (2) la grille de décision pondérée comparant au moins trois solutions ; (3) la liste des frameworks et bibliothèques (back-end, front-end, CSS, base de données) avec leur rôle ; (4) les commandes de création du projet ; (5) les risques du choix et la façon de les réduire.
Classe chaque outil : jQuery, Laravel, WordPress, React, Symfony, Chart.js, Angular, Drupal, Express, Bootstrap, Django, Moment.js.
Propose une architecture (et des frameworks) pour chaque projet, en justifiant : (1) le site vitrine d'un cabinet d'architectes avec un blog ; (2) l'application de gestion des absences d'un ISTA, utilisée par 50 formateurs ; (3) une application de livraison de repas avec une application mobile pour les clients et une pour les livreurs ; (4) une plateforme de vente de billets de concerts qui doit supporter 100 000 connexions à l'ouverture des ventes.
Un méta-framework (Next.js pour React, Nuxt pour Vue) ajoute au framework front-end le rendu côté serveur (SSR, meilleur pour le référencement et le premier affichage), le routage par fichiers et des fonctions serveur. La frontière entre front et back s'estompe.
function CarteLivre({ titre, auteur, prix }) {
return (
<article className="carte-livre">
<h3>{titre}</h3>
<p>{auteur}</p>
<strong>{prix.toFixed(2)} DH</strong>
</article>
);
}<script setup>
defineProps({ titre: String, auteur: String, prix: Number })
</script>
<template>
<article class="carte-livre">
<h3>{{ titre }}</h3>
<p>{{ auteur }}</p>
<strong>{{ prix.toFixed(2) }} DH</strong>
</article>
</template>Tableau: Les frameworks CSS
composer create-project laravel/laravel kitab # un projet Laravel
symfony new kitab --webapp # un projet Symfony (avec l'outil symfony)
npm create vite@latest kitab-front # un front-end React, Vue… avec Vite
npx create-next-app@latest kitab-next # un projet Next.jsCe que tu vas voir (vidéo courte, entièrement sur ce sujet) : la différence entre le front-end (ce que voit l'utilisateur dans son navigateur) et le back-end (le serveur et la base de données), et comment ils communiquent. C'est la base des architectures full stack de cette section : une partie front, une partie back, et la communication entre les deux.
Pour Kitab, avec une équipe formée à PHP (M107) et un hébergement mutualisé, Laravel avec Blade est le meilleur choix ; on pourra ajouter de l'interactivité avec Livewire ou quelques composants Vue. Si l'on prévoyait une application mobile, l'architecture API + front-end séparé gagnerait des points, car la même API servirait le site et l'application.
Le « meilleur » framework n'existe pas : il y a le framework adapté au projet, à l'équipe et à l'hébergement. Choisir une technologie parce qu'elle est à la mode, sans que l'équipe la maîtrise, est l'une des causes classiques de retard des projets.
Une agence hésite entre Symfony et Django pour une application de gestion de cabinet médical. Critères et poids : sécurité (5), compétences de l'équipe (4), hébergement (3), administration générée automatiquement (2). Notes de Symfony : 5, 4, 4, 3. Notes de Django : 5, 2, 3, 5. Calcule les deux totaux et conclus. Que se passe-t-il si l'agence recrute deux développeurs Python expérimentés (Django passe alors à 5 en compétences) ?