Django : le cadre de travail complet pour un site en Python

Définition

Mettre un site en ligne, ce n'est presque jamais écrire la fonctionnalité qui vous intéresse. Avant elle viennent une base de données à ouvrir, des adresses à relier à du code, des mots de passe à stocker sans les mettre en danger. Ce travail est le même partout, et il occupe pourtant les premières semaines de chaque projet.

Django répond à cet ennui. Ce cadre de travail web écrit en Python, distribué comme un package, livre la plomberie déjà écrite et déjà branchée : routage des adresses, accès à la base, gabarits, formulaires, comptes utilisateurs, administration. Reste à écrire le métier, la seule partie que personne ne peut écrire à votre place.

La promesse se voit mieux sur un exemple. Le fichier ci-dessous ne fait rien d'autre que décrire ce qu'est un article : trois informations et leur type.

from django.db import models

class Article(models.Model):
    titre = models.CharField(max_length=200)
    contenu = models.TextField()
    publie_le = models.DateTimeField(auto_now_add=True)

    def __str__(self):
        return self.titre

De cette seule description, Django déduit une table en base, un formulaire de saisie et un écran d'administration où une personne non technique publie sans voir une ligne de code. La méthode __str__, une méthode magique, choisit le texte affiché partout où l'article apparaît. Le tout s'installe avec pip, dans un environnement virtuel propre au projet.

Ce qu'il vous évite d'écrire

Ce que Django fournit reste abstrait tant qu'on n'a pas essayé de l'écrire soi-même : lire une requête HTTP, associer une adresse à une fonction, ouvrir une connexion à la base, construire du SQL sans se laisser injecter, hacher les mots de passe.

Plusieurs de ces briques sont des sujets de sécurité, et cela change la nature du problème. Une erreur de mise en page se corrige dans la journée ; une erreur sur le stockage des mots de passe ne se voit pas, jusqu'au jour où la base fuite. Django tranche à votre place, avec des réglages par défaut qui tiennent.

Le confort a un prix : vous héritez d'une structure de projet et de conventions à apprendre avant d'être productif. La première semaine avance moins vite qu'avec un outil minimaliste, et le rapport s'inverse quand arrivent les comptes utilisateurs : l'inscription, la connexion et les droits d'accès sont déjà là, alors qu'ils auraient coûté des jours.

Face à Flask et FastAPI

La question n'est pas de savoir lequel a le plus de fonctionnalités, mais combien de décisions chacun vous laisse. Le tableau se lit dans ce sens : à gauche ce qui est tranché, à droite ce que vous devrez brancher vous-même.

Django n'apporte rien à un script, à un robot ou à une API de trois routes : ce serait porter une structure entière pour un seul fichier. Dès qu'un projet a des utilisateurs qui se connectent, des contenus modifiés par une équipe et une base relationnelle, refaire tout cela à la main revient en revanche à réécrire Django en moins sûr.

Reste l'API pure et fortement typée : FastAPI adossé à Pydantic y est plus direct, les annotation de type suffisant à valider les données entrantes.

L'ORM, son vrai centre de gravité

Sans cadre de travail, un site finit avec des morceaux de SQL disséminés dans des chaînes de caractères, que rien ne relie au reste du code. L'ORM de Django supprime ce problème en traitant chaque table comme un objet Python ordinaire.

Le mécanisme réutilise ce que vous savez déjà : chaque table est décrite par une classe qui reçoit ses capacités par héritage de models.Model, et chaque colonne par un attribut. Les requêtes s'écrivent alors en Python, et le SQL est produit puis échappé pour vous.

recents = Article.objects.filter(publie_le__year=2026).order_by("-publie_le")[:5]

Cette ligne se lit sans connaître SQL : garder les articles publiés en 2026, les trier par date, ne prendre que les cinq premiers.

Vient ensuite la question que tout le monde se pose : que devient la base le jour où la classe change ? Deux commandes calculent la différence et l'appliquent sans perdre les lignes déjà enregistrées.

python manage.py makemigrations
python manage.py migrate

Chaque changement laisse un fichier versionné avec le code, qu'un collègue rejoue en une commande. C'est ce couple modèle plus migration qui explique pourquoi tant d'équipes restent sur Django une fois le projet lancé.

Les deux erreurs du premier projet

La première n'est pas syntaxique, elle est structurelle. Django distingue le projet, qui porte la configuration, et les applications, qui portent chacune un domaine. Beaucoup de débutants entassent tout dans une application unique : cela tient six mois, puis plus rien ne peut être isolé ni testé séparément. Une application par domaine dès le premier jour suffit à l'éviter.

La seconde ne se voit pas à l'écriture, elle se voit sous la charge, et elle porte un nom : la requête N+1.

Questions fréquentes

Oui, et pas seulement la syntaxe. Le cadre repose sur les classes, sur un découpage en modules et sur le décorateur, qui réserve ici une page aux membres connectés. Ses messages d'erreur supposent aussi que vous savez lire une pile d'appels : sinon, vous chercherez dans Django une erreur venue de votre propre code.

Oui, avec Django REST Framework, une extension qui transforme les modèles en réponses json et couvre la pagination, les permissions et la validation. Le calcul dépend du point de départ : sur une base Django existante, elle évite de redéclarer des modèles déjà écrits ; pour une API seule partant de zéro, FastAPI demande moins de cérémonie.

En partie. Les vues acceptent async et await depuis la version 3.1, et l'ORM expose des appels asynchrones, mais une part importante de l'écosystème reste synchrone. Sur un site classique, le gain est nul : l'asynchrone paie sur les connexions maintenues ouvertes, une messagerie ou un flux temps réel, pas sur des pages qui répondent en millisecondes.