4.1Web back-end avec Django
L'essentiel en 30 secondes
- Django = « batteries incluses » : ORM (base manipulée en objets Python), migrations (évolution sans SQL manuel), admin auto-généré et auth fournis d'office.
- Circuit MVT :
models.py(données) →urls.py(routes) →views.py(logique) → template.html(affichage) ;makemigrations + migrateaprès chaque modèle. - Réflexe de Nabil : épouser les conventions MVT au lieu de se battre contre elles — Django impose une structure contraignante au début, salvatrice ensuite.
Mini-cas filé — Nabil expose ses ventes à Alger
Nabil, data analyst junior à Alger, passe ses journées à renvoyer le même fichier CSV des ventes à ses collègues. Il décide de construire un mini back-office avec Django : un modèle Vente (ville, montant, date), des migrations qui créent la table sans SQL, et l'admin auto-généré où l'équipe consulte et filtre les ventes sans le déranger. En une semaine, son CSV hebdomadaire devient une application que chacun interroge seul. Premier jalon du fil rouge : de l'analyste qui envoie des fichiers au développeur qui expose un service.
Ce même cas revient dans le cours, le schéma, le script et le défi 48h — et continue en 4.2, 4.3, 4.4 et 4.5.
1. Django « batteries incluses » et le MVT
Django est le framework web complet de Python : il fournit d'office l'administration (back-office généré), l'ORM (base manipulée en objets Python), l'authentification (comptes, permissions) et la sécurité (CSRF, XSS, injections). Son organisation s'appelle MVT : le Modèle (models.py) décrit les données, la Vue (views.py) contient la logique, le Template (.html) affiche — le routage (urls.py) reliant URL et vues. Comme Nabil, on épouse ces conventions : c'est contraignant au début, salvateur ensuite.
2. ORM, migrations et admin : le trio productif
L'ORM traduit vos classes Python en tables : class Vente(models.Model) avec des champs (CharField, DecimalField, DateField) devient une table, et Vente.objects.filter(ville="Alger") remplace le SELECT — sans SQL manuel. Les migrations versionnent chaque changement de modèle : python manage.py makemigrations puis migrate, et la base évolue proprement, en équipe comme en production. L'admin (activé par createsuperuser, sur /admin) offre dès les premières minutes un back-office pour consulter et corriger les données. Nabil y gagne son premier service rendu à l'équipe.
Quand choisir Django ? Pages servies côté serveur + comptes + back-office → Django. JSON pur consommé par un front séparé → plutôt une API légère (voir 4.2). Et même avec l'ORM, des bases de SQL restent utiles pour optimiser et comprendre ce qui se passe sous le capot.
🔎 Exemple concret — 🔎 Exemple concret — Les ventes de Nabil en MVT
Les quatre gestes de Nabil, avec les API réelles :
models.py → class Vente(models.Model): ville, montant, date
shell → makemigrations + migrate (table créée, sans SQL)
urls.py → path('ventes/', vues.liste_ventes)
views.py → Vente.objects.filter(ville="Alger") → templateLecture : modèle, route, vue, template — chacun à sa place.
Leçon : l'admin expose ces ventes sans back-office à coder.
Vocabulaire de la section
- Django
- Framework web Python complet (« batteries incluses ») : admin, ORM, authentification et sécurité fournis d'origine.
Exemple simple : Nabil y construit son back-office des ventes en une semaine.
Ce que ce n'est pas : un empilement de scripts sans structure ni comptes.
Réflexe : pages + comptes + admin ? penser Django en premier.
- MVT (Modèle-Vue-Template)
- Organisation du code Django : Modèle (données), Vue (logique), Template (affichage HTML), reliés par le routage urls.py.
Exemple simple : Les ventes de Nabil : modèle Vente, vue liste_ventes, template ventes.html.
Ce que ce n'est pas : un unique script mélangeant SQL, logique et HTML.
Réflexe : pour chaque fichier, demander : donnée, logique ou affichage ?
- ORM
- Manipulation de la base via des objets Python (Vente.objects.filter(...)) au lieu d'écrire du SQL.
Exemple simple : Nabil filtre les ventes d'Alger sans écrire un SELECT.
Ce que ce n'est pas : du SQL concaténé avec des variables dans le code.
Réflexe : lire les requêtes générées quand une page ralentit.
- Migration
- Fichier qui traduit les changements de vos modèles en modifications de la base (makemigrations + migrate).
Exemple simple : Nabil ajoute le champ date : une migration fait évoluer la table partout.
Ce que ce n'est pas : des ALTER TABLE faits à la main en production.
Réflexe : jamais de structure modifiée hors migration.
En pratique — En pratique — Découvrir Django et son admin
- Dans un venv, installez Django (pip install django) et créez un projet : « django-admin startproject monsite », puis une application « python manage.py startapp ventes ».
- Déclarez un modèle (ex. Vente : ville, montant, date), puis lancez « makemigrations » et « migrate » : observez la table créée sans SQL.
- Créez un super-utilisateur (« createsuperuser »), lancez « runserver » et explorez l'admin : ajoutez et filtrez des lignes.
- Ajoutez une URL, une vue qui interroge l'ORM et un template qui affiche la liste.
Script prêt à dire — présenter son back-office (30 s)
« C'est Nabil : nos ventes vivent dans un modèle Django, la base évolue par migrations, et l'équipe les consulte dans l'admin sans me demander de CSV. Les URL, les vues et les templates suivent le MVT : chacun sait où chercher. »
À dire en point d'équipe ; montrez l'admin en direct.
Modèle copier-coller — mini-app Django (code testé)
# ventes/models.py
from django.db import models
class Vente(models.Model):
ville = models.CharField(max_length=80)
montant = models.DecimalField(max_digits=10, decimal_places=2)
date = models.DateField()
def __str__(self):
return f"{self.ville} — {self.montant}"
# ventes/views.py
from django.shortcuts import render
from .models import Vente
def liste_ventes(request):
ventes = Vente.objects.filter(ville="Alger").order_by("-date")[:20]
return render(request, "ventes/liste.html", {"ventes": ventes})
# ventes/urls.py
from django.urls import path
from . import views
urlpatterns = [
path("ventes/", views.liste_ventes, name="liste-ventes"),
]
# Commandes :
# python manage.py makemigrations && python manage.py migrate
# python manage.py createsuperuser && python manage.py runserver
Premier projet
Un modèle + l'admin suffisent : exposez vos données en une heure avant de coder la moindre page.
Application d'équipe
Comme Nabil : MVT strict, tout changement de base en migration, admin comme back-office de secours.
Données existantes
Importez votre CSV dans l'ORM une fois (script d'import), puis laissez Django servir : fini les fichiers qui circulent.
Vers une API
JSON pur pour un front séparé ? Gardez les modèles Django et ajoutez une couche API (voir 4.2) au lieu de tout réécrire.
✓ Bonnes pratiques
- Épouser les conventions MVT au lieu de les contourner.
- Migrer dès le premier modèle, admin dès la première heure.
- Garder des bases de SQL pour optimiser l'ORM.
✗ Pièges fréquents
- Se battre contre les conventions du framework.
- Écrire du SQL manuel au lieu d'utiliser l'ORM.
- Prendre Django pour une API JSON pure et légère.
Points clés à retenir
- DJANGO = framework « BATTERIES INCLUSES » : admin, ORM, auth, sécurité fournis d'office.
- MVT : MODÈLE (données) → URL (routage) → VUE (logique) → TEMPLATE (affichage).
- ORM = base en objets Python ; MIGRATIONS = évolution sans SQL manuel.
- ADMIN auto-généré : back-office dès les premières minutes. De l'analyste CSV au service exposé.
Défi 48h — appliquez demain
Créez 1 projet Django avec 1 modèle de vos propres données, migrez, explorez l'admin et affichez 1 liste filtrée dans un template.
- Je peux citer MVT, ORM, migrations et admin.
- Je sais créer un modèle et migrer sans SQL.
- J'ai 1 page Django qui affiche mes données.
Questions fréquentes
Django ou Flask/FastAPI : comment choisir ?
Django quand il faut une application complète et structurée : pages servies, comptes, permissions, back-office — tout est fourni et cohérent, au prix d'épouser ses conventions. Flask ou FastAPI quand il faut un service léger et sur-mesure, typiquement une API JSON consommée par un autre client (voir 4.2). Nabil retient : back-office d'équipe → Django ; JSON pur pour un front → API.
Faut-il connaître le SQL pour utiliser l'ORM Django ?
Non au début : l'ORM suffit pour créer, lire et filtrer. Oui dès que ça grandit : comprendre tables, index et requêtes générées pour optimiser les pages lentes, déboguer, et écrire les requêtes complexes que l'ORM exprime mal. L'ORM + des bases SQL = le bon duo.
Pourquoi dit-on que Django est « batteries incluses » ?