Apprendre Django depuis le début : une feuille de route basée sur HTTP

Apprendre Django depuis le début : une feuille de route basée sur HTTP

À la fin de l’année, on a naturellement envie de faire le bilan de l’année écoulée. Pour moi, un thème revient chaque année sans faute : « Est-ce que j’ai vraiment bien appris Django ? »

Je travaille avec Django et Django REST Framework (DRF) depuis plusieurs années. Après de nombreux projets, je peux enfin dire :

« Je comprends mieux comment tout fonctionne qu’auparavant. »

Il reste encore des zones d’ombre, mais je peux désormais dire à mon ancien moi, et aux développeurs qui débutent avec Django, que « suivre cette séquence d’apprentissage vous évitera de vous perdre ».

Cet article est donc un guide personnel sur comment reprendre Django depuis le début. Il peut être lu comme un bilan de fin d’année, mais il reste valable à tout moment comme point de référence pour l’apprentissage de Django.

1. Django est avant tout un framework HTTP

C’est une évidence, mais on oublie souvent ce point lorsqu’on débute.

Que l’on rende une page HTML ou qu’on ne renvoie que du JSON, l’essence de Django est de recevoir une requête HTTP et de renvoyer une réponse HTTP.

• Le client (navigateur, application, autre serveur) envoie une requête HTTP.
• Django la reçoit, la traite.
• Il renvoie une réponse HTTP (HTML, JSON, fichier, erreur, etc.).

Les éléments que l’on associe souvent à Django :

• URLConf
• View (FBV/CBV)
• Template
• ORM
• Middleware
• Authentification / Permissions
• Serializer, ViewSet, Router de DRF…

Tout cela n’est qu’un ensemble d’outils pour bien recevoir, traiter et renvoyer une requête HTTP.

Si on ne garde pas cette perspective, le framework devient vite un « boîte à magie ».

« On peut juste l’utiliser, mais on ne comprend pas pourquoi ça fonctionne. »

Si cette situation perdure, on se retrouve à être entraîné par le framework.

2. Avant les fonctionnalités flashy, comprenez pourquoi elles existent

Quand on commence, on remarque souvent ces fonctionnalités :

• Connexion / inscription, login social
• Gestion des permissions
• Mise en cache
• Tâches asynchrones (Celery, etc.)
• Divers middlewares et paramètres

Elles sont utiles, mais si on les aborde trop tôt, on se pose la question :

« Pourquoi doit-on faire ça exactement ? »

Sans réponse, on construit du code qui reste fragile :

• On corrige les erreurs mais on ne comprend pas le fond.
• On ne peut pas changer l’architecture sans se heurter au framework.
• On colle des solutions trouvées sur Google et on passe à l’« on fait comme ça, ça marche ».

Mon conseil pour mon ancien moi et pour les débutants :

Avant de coder une fonctionnalité, comprenez le principe du web et le flux HTTP.

3. Comprendre le flux HTTP vous ouvre les coulisses de Django

Pour maîtriser Django de façon transparente, il faut connaître le flux de base du protocole HTTP.

Il est utile de toucher directement à ces éléments :

• La structure d’une requête : URL, méthode (GET/POST/PUT/DELETE…), en-têtes, query string, corps.
• Les critères de réponse : code d’état (200/400/404/500…), en-têtes, corps (JSON/HTML, etc.).
• Ce que le navigateur cache et ce que le serveur doit gérer.

Par exemple, envoyons une requête depuis le terminal :

curl -X GET "http://localhost:8000/articles/1/" -H "Accept: application/json"

Cette requête contient tout le cœur d’HTTP :

• URL : /articles/1/
• Méthode : GET
• En-tête : Accept: application/json
• Contenu attendu : JSON

Une fois que ce flux vous est familier, vous voyez aussi :

• Pourquoi nginx proxy certaines routes vers Django.
• Le rôle de WSGI (gunicorn, uWSGI, etc.).
• Où Django prend en charge le traitement et où d’autres couches interviennent.

À ce stade, Django n’est plus un « mystère » mais un ensemble de structures nécessaires pour gérer les requêtes HTTP.

Les fonctionnalités de commodité de Django sont des extensions, pas le cœur. Comprendre HTTP vous permet de les intégrer naturellement.

4. Le premier projet : simple, FBV

Pour un débutant, je recommande de commencer ainsi :

Un premier projet simple, en utilisant des Function-Based Views (FBV).

Conditions idéales :

• Authentification / permissions minimal.
• Pas de configuration d’administration compliquée.
• Modèles simples (ex. articles, commentaires).
• Fonctionnalités qui montrent le flux d’exécution plutôt que la structure parfaite.

Exemple d’une vue FBV pour afficher un article :

# views.py
from django.http import JsonResponse
from .models import Article

def article_detail(request, pk):
    article = Article.objects.get(pk=pk)
    data = {
        "id": article.id,
        "title": article.title,
        "content": article.content,
    }
    return JsonResponse(data)

Cette vue contient tout le flux de base :

1. request est reçu.
2. Le pk de l’URL est utilisé pour interroger la base via l’ORM.
3. Un dictionnaire Python est créé.
4. Il est renvoyé sous forme de JSON.

En déboguant pas à pas, on voit :

• Comment URLConf relie l’URL à la vue.
• Ce que contient l’objet request.
• Le SQL généré par l’ORM.
• La conversion en JSON.

Maîtriser ce flux vous donne un atout majeur pour tout projet futur.

5. Passer rapidement à CBV et DRF

Une fois que vous avez bien assimilé le flux HTTP–View–ORM–Response en FBV, il est temps de passer à la prochaine étape : CBV et DRF.

C’est là que la vraie puissance de Django se révèle.

CBV et DRF offrent :

• Réduction des répétitions grâce à des structures réutilisables.
• Un schéma cohérent à travers le projet.
• Des responsabilités clairement séparées.
• Une architecture extensible (URL, Serializer, ViewSet, Permission).

Exemple avec DRF :

# views.py (DRF)
from rest_framework.viewsets import ReadOnlyModelViewSet
from .models import Article
from .serializers import ArticleSerializer

class ArticleViewSet(ReadOnlyModelViewSet):
    queryset = Article.objects.all()
    serializer_class = ArticleSerializer

Et le routeur :

# urls.py
from rest_framework.routers import DefaultRouter
from .views import ArticleViewSet

router = DefaultRouter()
router.register(r'articles', ArticleViewSet, basename='article')

urlpatterns = router.urls

Vous obtenez alors automatiquement :

• /articles/
• /articles/{id}/

Si vous avez déjà compris le flux HTTP, ces « magies » deviennent simplement des abstractions de ce même flux.

« Dans ces classes, le même flux HTTP se répète, mais il est encapsulé dans des patterns réutilisables. »

Si vous avez des doutes, n’hésitez pas à plonger dans le code source de Django.

6. Récapitulatif de la séquence d’apprentissage

Pour mon ancien moi et pour les nouveaux développeurs Django, voici la séquence que je recommande :

1. Comprendre le web et HTTP - Flux requête/réponse navigateur‑serveur. - Méthodes, codes d’état, en-têtes, cookies, sessions. - Expérimenter avec curl ou Postman.
2. Django de base : FBV - URLConf → View → Template → ORM. - Petit projet sans authentification. - CRUD avec l’ORM.
3. Explorer l’ORM et l’Admin - Modèles, relations, optimisation des requêtes. - Gestion de données via l’Admin.
4. Passer à CBV - Vues génériques, mixins, héritage. - Apprendre l’abstraction de patterns.
5. Créer une API avec DRF - Serializer, ViewSet, Router, Permissions, Authentification. - Refaire les fonctionnalités FBV/CBV en DRF.
6. Fonctionnalités avancées - Authentification/autorisation, throttling, pagination, filtres. - Cache, tâches asynchrones, déploiement, scalabilité.

L’essentiel est de pouvoir expliquer pourquoi chaque étape est nécessaire, pas seulement comment la réaliser.

7. Conclusion : ne mémorisez pas le framework, comprenez le web

Enfin, un dernier message pour mon ancien moi et pour les débutants :

Ne mémorisez pas le framework, comprenez le fonctionnement du web.

Django est un excellent outil pour faciliter cette compréhension.

En gardant cette perspective, vous pourrez :

• Vous adapter aux changements de version.
• Passer à d’autres frameworks (Flask, FastAPI, Node, Spring, etc.).
• Aborder de nouvelles architectures ou environnements cloud.

Vous pourrez toujours vous poser les questions suivantes :

• « Comment ce système gère-t-il HTTP ? »
• « Où chaque responsabilité est-elle prise en charge ? »
• « Quelle abstraction masque quel pattern de requête/réponse ? »

Avec ces bases, vous deviendrez un développeur web capable de rester stable, quel que soit le framework ou l’environnement.