Backend pour application web ou mobile avec Django DRF

Repères utiles :

• Django DRF LLM Wiki
• SCHEMA
• Comprendre Django
• Comprendre Django REST Framework
• Comment penser une API avec Django DRF
• Les briques de base de Django DRF
• Parcours de lecture
• FAQ, erreurs fréquentes et conseils pratiques

info

Ce tutoriel explique quand et pourquoi utiliser Django DRF comme backend pour une application web ou mobile, comment raisonner proprement sur l'architecture, et comment construire une base saine avant même de parler d'écrans ou de code détaillé.

1. Introduction

Quand on construit une application moderne, on sépare souvent deux mondes :

• le frontend, qui affiche l'interface
• le backend, qui stocke les données, applique les règles et sécurise les accès

Dans ce type de projet, Django DRF peut devenir le cœur serveur de l'application.

Ce tutoriel est écrit pour quelqu'un qui veut comprendre :

• ce qu'on veut dire par “backend pour app web ou mobile”
• dans quels cas Django DRF est un bon choix
• comment penser ce backend de manière propre et durable
• à quoi ressemble une architecture réaliste
• quelles erreurs éviter dès le début

remarque

Ici, l'objectif n'est pas encore d'écrire du code ligne par ligne. L'objectif est d'apprendre à penser correctement le use case pour ne pas construire un backend fragile, flou ou trop couplé au frontend.

2. Le problème concret à résoudre

Imaginons que tu veuilles construire une application avec :

• un frontend web en React, Next.js ou Vue
• ou une application mobile en Flutter ou React Native

Ce frontend a besoin de faire des choses concrètes :

• afficher des données
• créer des objets
• modifier des informations
• se connecter avec un compte
• envoyer des fichiers
• filtrer des listes
• respecter des droits d'accès

Mais le frontend ne doit pas :

• parler directement à la base de données
• contenir les règles métier sensibles
• décider seul qui a le droit de faire quoi
• exposer la logique interne du produit

Il faut donc un backend qui serve d'intermédiaire fiable.

C'est là que Django DRF devient intéressant.

3. À quel type de projet ce use case correspond

Ce use case correspond très bien à des projets comme :

• une application de gestion de projets
• une application de réservation
• un dashboard SaaS
• un outil interne d'entreprise
• une app mobile de suivi ou d'organisation
• une plateforme avec comptes utilisateurs et données personnalisées

Dans tous ces cas, le frontend n'est pas autosuffisant. Il a besoin d'un backend qui prenne en charge :

• les données
• la sécurité
• la logique métier
• la cohérence globale du système

4. Pourquoi Django DRF est pertinent ici

Django DRF est particulièrement adapté à ce use case pour plusieurs raisons.

4.1 Parce qu'il sépare bien les responsabilités

Le frontend peut se concentrer sur :

• l'expérience utilisateur
• l'affichage
• la navigation
• les interactions visuelles

Le backend Django DRF peut se concentrer sur :

• les données
• les règles métier
• l'authentification
• les permissions
• la cohérence des réponses API

4.2 Parce qu'il est très bon pour les données relationnelles

Dès que ton application manipule :

• utilisateurs
• projets
• tâches
• commandes
• abonnements
• messages
• fichiers
• historiques

Django devient très naturel grâce à son ORM et à sa structuration globale.

4.3 Parce que DRF rend l'API plus claire

Avec DRF, tu obtiens plus facilement :

• des endpoints cohérents
• des serializers propres
• des permissions API
• des listes paginées
• des filtres et de la recherche

4.4 Parce que le projet peut grandir proprement

Un projet qui commence comme “simple appli web” peut rapidement devenir plus sérieux. Par exemple :

• plusieurs rôles utilisateur
• administration interne
• notifications
• fichiers
• tableaux de bord
• logique métier plus complexe

Django DRF gère bien cette montée en complexité si la base a été pensée proprement.

5. Quand utiliser Django DRF pour ce cas

Ce choix est particulièrement pertinent si :

• tu as un frontend séparé du backend
• tu veux une API JSON propre
• tu as plusieurs ressources métier à gérer
• tu as des utilisateurs connectés
• tu as des permissions ou rôles à gérer
• tu veux garder une architecture maintenable dans le temps
• tu veux pouvoir brancher plusieurs clients sur le même backend

Exemple typique :

• un frontend web pour les employés
• une app mobile pour les utilisateurs terrain
• un backend unique qui centralise les données et la logique

6. Quand ne pas utiliser Django DRF pour ce cas

Il ne faut pas utiliser Django DRF par réflexe.

Ce n'est pas forcément le meilleur choix si :

• tu n'as pas réellement de frontend séparé
• tu fais surtout un site HTML simple rendu côté serveur
• ton besoin backend est minuscule et très ponctuel
• tu veux juste une micro-API très légère avec très peu de logique métier
• ton projet est dominé par du temps réel intensif sans forte composante relationnelle

Il faut aussi faire attention à un piège fréquent :

séparer frontend et backend n'est pas automatiquement une bonne idée si le projet est minuscule.

Parfois, cette séparation ajoute plus de complexité qu'elle n'apporte de valeur.

7. Pré-requis

Pour bien profiter de ce tutoriel, il est utile d'avoir déjà une idée de :

• Python
• la notion de requête HTTP
• la différence entre frontend et backend
• ce qu'est une base de données relationnelle

Mais pas besoin d'être expert. Le but est justement de clarifier les points structurants.

8. Vocabulaire indispensable

Frontend

La partie visible de l'application, celle avec laquelle l'utilisateur interagit.

Backend

La partie serveur, qui applique les règles, stocke les données et renvoie des réponses.

API

L'interface par laquelle le frontend communique avec le backend.

Endpoint

Un point d'entrée précis de l'API.

Ressource

Un objet important du domaine métier, par exemple un projet, une tâche, une commande ou un utilisateur.

Authentification

Le mécanisme qui permet d'identifier l'utilisateur.

Permission

La règle qui détermine ce que l'utilisateur a le droit de faire.

Serializer

La brique DRF qui sert à valider et représenter les données échangées.

Tu retrouveras plusieurs de ces notions dans Les briques de base de Django DRF.

9. Vision d'ensemble

La logique générale de ce use case est simple :

1. le frontend envoie une requête
2. le backend Django DRF la reçoit
3. le backend identifie l'utilisateur si nécessaire
4. il vérifie ses droits
5. il applique la logique métier
6. il lit ou modifie la base de données
7. il renvoie une réponse structurée au frontend

L'intuition importante est la suivante :

le backend n'est pas seulement un fournisseur de données ; c'est le gardien des règles du produit.

10. Architecture type

Voici une architecture mentale simple et saine.

graph TD
    A[Frontend web ou mobile] --> B[API Django DRF]
    B --> C[Logique métier]
    B --> D[Authentification et permissions]
    C --> E[Base de données]
    B --> F[Admin Django]
    B --> G[Services externes optionnels]

10.1 Le frontend

Il peut être :

• un frontend web moderne
• une app mobile
• plusieurs clients à la fois

Son rôle principal est de :

• afficher
• demander
• envoyer
• guider l'utilisateur

10.2 L'API Django DRF

Elle sert d'interface structurée entre les clients et la logique backend.

10.3 La logique métier

C'est là que vivent les vraies règles du produit. Exemples :

• qui peut modifier quoi
• quand un objet peut changer d'état
• quelles validations métier doivent être appliquées

10.4 La base de données

Elle stocke l'état durable du système.

10.5 L'admin Django

Elle peut servir aux équipes internes pour :

• inspecter les données
• corriger des anomalies
• administrer certains objets
• accélérer les opérations support

11. Comment penser l'architecture proprement

Avant d'implémenter quoi que ce soit, il faut répondre à quelques questions.

11.1 Quels sont les clients ?

As-tu :

• seulement un frontend web ?
• seulement une app mobile ?
• les deux ?
• d'autres systèmes qui consommeront l'API ?

11.2 Quelles sont les ressources principales ?

Exemples :

• user
• profile
• project
• task
• notification
• attachment

11.3 Quelles sont les actions réellement utiles ?

Par exemple, pour une tâche, l'action importante n'est peut-être pas seulement :

• créer
• modifier
• supprimer

Mais aussi :

• assigner
• clôturer
• rouvrir
• marquer comme bloquée

11.4 Quels sont les rôles ?

Même dans une app simple, il faut vite clarifier :

• visiteur
• utilisateur connecté
• membre premium
• opérateur interne
• admin

11.5 Où vivent les règles ?

Les règles importantes ne doivent pas être abandonnées au frontend. Elles doivent vivre dans le backend.

12. Construction pas à pas

Voici une manière saine de construire ce type de backend.

Étape 1 — Définir la frontière du backend

Commence par préciser ce qui relève du backend.

Le backend doit gérer :

• les données durables
• les règles métier
• les droits d'accès
• les transformations importantes
• les actions critiques

Le backend ne doit pas devenir un simple miroir passif du frontend.

Étape 2 — Identifier les ressources métier

Liste les objets vraiment importants.

Exemple pour une app de gestion de projets :

• utilisateur
• projet
• tâche
• commentaire
• pièce jointe

Cette étape est fondamentale, car de mauvaises ressources entraînent une mauvaise API.

Étape 3 — Clarifier les parcours utilisateur

Demande-toi ce que l'utilisateur essaie réellement de faire.

Exemples :

• s'inscrire
• se connecter
• voir ses projets
• créer une tâche
• modifier le statut d'une tâche
• joindre un document

Une bonne API reflète ces parcours sans être prisonnière de l'interface.

Étape 4 — Définir la stratégie d'authentification

Dans une app web ou mobile, cette question arrive très vite.

Il faut décider comment le backend saura qui appelle. Même sans entrer dans les détails techniques, cette décision structure déjà beaucoup de choses.

Étape 5 — Définir les permissions tôt

Ne pas attendre “plus tard”.

Très tôt, demande-toi :

• qui peut lire ?
• qui peut créer ?
• qui peut modifier ?
• qui peut supprimer ?
• qui peut voir seulement ses propres objets ?

Étape 6 — Définir ce que l'API expose

Tout ce qui existe dans le modèle ne doit pas forcément être exposé tel quel.

Il faut décider :

• quels champs sont utiles au frontend
• quels champs doivent rester internes
• quelles réponses doivent être simplifiées
• quelles relations doivent être visibles ou cachées

Étape 7 — Structurer l'API autour d'intentions claires

Ne crée pas des routes juste parce qu'une table existe. Crée des routes parce qu'un besoin produit existe.

Étape 8 — Prévoir la croissance du projet

Même si ton V1 est simple, pose les bases pour :

• pagination
• filtres
• recherche
• rôles supplémentaires
• administration
• intégrations futures

Étape 9 — Prévoir les besoins opérationnels

Pense tôt à des sujets souvent oubliés :

• logs
• administration interne
• support utilisateur
• correction manuelle de données
• suivi des erreurs

13. Exemple concret de projet type

Prenons un exemple simple : une application web et mobile de suivi de projets.

Le frontend web

Il permet aux managers de :

• créer des projets
• suivre l'avancement
• consulter des tableaux de bord

L'app mobile

Elle permet aux membres terrain de :

• voir leurs tâches
• mettre à jour un statut
• envoyer une photo
• commenter une intervention

Le backend Django DRF

Il sert à :

• centraliser les données
• sécuriser les accès
• faire respecter les rôles
• historiser les changements
• alimenter les deux clients avec la même logique produit

C'est typiquement un cas où Django DRF est très à l'aise.

14. Ce que le frontend ne doit pas décider seul

C'est un point crucial.

Le frontend peut guider l'expérience. Mais il ne doit pas être l'arbitre final de règles comme :

• qui a accès à quelles données
• si une transition d'état est légitime
• si un document est modifiable
• si une ressource appartient bien à l'utilisateur

Même si le frontend masque un bouton, le backend doit lui aussi faire respecter la règle.

15. Erreurs fréquentes

Erreur 1 — Faire une API qui copie l'écran

Un écran n'est pas une architecture backend. L'API doit refléter le produit, pas seulement l'UI du moment.

Erreur 2 — Exposer brutalement tout le modèle

Une bonne API n'est pas une exportation brute de la base.

Erreur 3 — Reporter la gestion des permissions

Très mauvaise idée. Quand les permissions arrivent trop tard, il faut souvent refaire une partie de l'architecture.

Erreur 4 — Mettre trop de logique côté frontend

Le frontend ne doit pas porter la logique sensible du produit.

Erreur 5 — Sous-estimer l'admin et l'exploitation

Une vraie application a besoin d'outils d'exploitation, pas seulement d'une belle interface utilisateur.

Erreur 6 — Vouloir tout rendre générique trop tôt

Il vaut mieux une V1 claire et bien structurée qu'une architecture pseudo-universelle mais floue.

16. Bonnes pratiques

16.1 Garder la logique métier côté backend

C'est la colonne vertébrale du produit.

16.2 Garder une API cohérente

Les conventions de nommage, de permissions et de réponses doivent rester homogènes.

16.3 Penser à plusieurs clients dès le départ si c'est prévu

Si tu sais qu'il y aura web + mobile, construis une API pensée pour plusieurs consommateurs.

16.4 Préserver une séparation claire des responsabilités

• frontend : interface et expérience
• backend : données, règles, sécurité

16.5 Garder un modèle de données sobre et compréhensible

Un modèle trop tordu crée de la confusion partout dans l'API.

16.6 Utiliser l'admin Django intelligemment

Pas comme produit final pour l'utilisateur, mais comme outil opérationnel pour les équipes internes.

17. Variantes et évolutions possibles

Ce use case peut grandir de plusieurs façons.

Variante 1 — Version simple

Un seul frontend web, peu de rôles, peu de ressources.

Variante 2 — Web + mobile

Deux clients différents, mais un backend unifié.

Variante 3 — Avec logique métier plus riche

Workflows, validations, notifications, historique, fichiers, reporting.

Variante 4 — Avec services externes

Paiement, emails, stockage objet, analytics, notifications push.

Variante 5 — Avec besoin de montée en maturité

Permissions plus fines, meilleure observabilité, tâches asynchrones, documentation API plus formelle.

18. Comment savoir si tu es sur la bonne voie

Tu vas dans la bonne direction si :

• tu sais nommer clairement tes ressources
• tu sais qui fait quoi
• tu sais quelles règles le backend protège
• ton API ne dépend pas trop de l'écran actuel
• tu peux imaginer un second client sans tout refaire

19. Résumé final

Utiliser Django DRF comme backend pour une application web ou mobile est une très bonne idée lorsque :

• tu as un frontend séparé
• tu as des données structurées
• tu as des utilisateurs et des permissions
• tu veux une API propre et maintenable
• tu veux un socle backend durable

L'idée essentielle à retenir est celle-ci :

dans ce use case, Django DRF n'est pas juste un outil pour répondre en JSON ; c'est une manière de construire un backend central, cohérent et fiable pour plusieurs clients.

20. Pour aller plus loin

Pour approfondir, relire :

• Comprendre Django
• Comprendre Django REST Framework
• Comment penser une API avec Django DRF
• Les briques de base de Django DRF
• Parcours de lecture
• FAQ, erreurs fréquentes et conseils pratiques

La suite logique du wiki, après ce premier gros use case, est d'entrer dans un sujet plus précis et très fréquent : l'API avec utilisateurs, rôles et permissions.

21. Mini-projet guidé avec code

Pour corriger un point important : oui, ce use case doit aussi montrer concrètement comment DRF s'utilise.

On va donc prendre un mini-exemple réaliste :

un backend Django DRF pour une application web/mobile de gestion de projets

Le but du mini-projet est de permettre à un frontend de :

• lister les projets de l'utilisateur
• créer un projet
• voir le détail d'un projet
• modifier un projet
• lister et créer les tâches liées à un projet

22. Structure du mini-projet

Arborescence minimale :

myproduct/
├── manage.py
├── myproduct/
│   ├── settings.py
│   ├── urls.py
│   └── ...
└── projects/
    ├── admin.py
    ├── models.py
    ├── serializers.py
    ├── views.py
    ├── permissions.py
    └── urls.py

Repères utiles avant de lire le code :

• settings.py active Django, DRF et la stratégie d'authentification par défaut.
• models.py porte les deux ressources métier principales : Project et Task.
• serializers.py transforme ces ressources en contrat JSON lisible pour le frontend.
• permissions.py protège le périmètre du propriétaire.
• views.py orchestre les opérations API côté utilisateur.
• urls.py expose clairement les routes /api/projects/ et /api/tasks/.
• admin.py donne un premier poste d'exploitation interne sans effort supplémentaire.

23. Implémentation guidée avec code

Étape 1 — Créer le projet et installer DRF

Commandes :

python -m venv .venv
source .venv/bin/activate
pip install django djangorestframework

django-admin startproject myproduct .
python manage.py startapp projects

Pourquoi cette étape ? Parce qu'on pose d'abord :

• le socle Django
• la couche DRF
• une application métier dédiée à la ressource principale

Étape 2 — Déclarer l'app et DRF dans settings.py

Dans myproduct/settings.py, ajouter :

INSTALLED_APPS = [
    "django.contrib.admin",
    "django.contrib.auth",
    "django.contrib.contenttypes",
    "django.contrib.sessions",
    "django.contrib.messages",
    "django.contrib.staticfiles",
    "rest_framework",
    "projects",
]

REST_FRAMEWORK = {
    "DEFAULT_PERMISSION_CLASSES": [
        "rest_framework.permissions.IsAuthenticated",
    ],
    "DEFAULT_AUTHENTICATION_CLASSES": [
        "rest_framework.authentication.SessionAuthentication",
        "rest_framework.authentication.BasicAuthentication",
    ],
}

Pourquoi ? Parce qu'un backend web/mobile a très souvent besoin d'une API réservée aux utilisateurs authentifiés.

Étape 3 — Créer les modèles métier

Dans projects/models.py :

from django.conf import settings
from django.db import models


class Project(models.Model):
    owner = models.ForeignKey(
        settings.AUTH_USER_MODEL,
        on_delete=models.CASCADE,
        related_name="projects",
    )
    name = models.CharField(max_length=150)
    description = models.TextField(blank=True)
    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)

    def __str__(self) -> str:
        return self.name


class Task(models.Model):
    project = models.ForeignKey(
        Project,
        on_delete=models.CASCADE,
        related_name="tasks",
    )
    title = models.CharField(max_length=150)
    is_done = models.BooleanField(default=False)
    created_at = models.DateTimeField(auto_now_add=True)

    def __str__(self) -> str:
        return self.title

Puis lancer :

python manage.py makemigrations
python manage.py migrate

Pourquoi ? Parce qu'on modélise ici deux ressources très typiques d'un backend produit :

• Project
• Task

Et on montre déjà une relation centrale :

• un projet possède plusieurs tâches

Étape 4 — Créer les serializers

Dans projects/serializers.py :

from rest_framework import serializers
from .models import Project, Task


class TaskSerializer(serializers.ModelSerializer):
    class Meta:
        model = Task
        fields = ["id", "project", "title", "is_done", "created_at"]
        read_only_fields = ["id", "created_at"]


class ProjectSerializer(serializers.ModelSerializer):
    tasks = TaskSerializer(many=True, read_only=True)

    class Meta:
        model = Project
        fields = [
            "id",
            "name",
            "description",
            "created_at",
            "updated_at",
            "tasks",
        ]
        read_only_fields = ["id", "created_at", "updated_at"]

Pourquoi ? Parce que le serializer sert à :

• définir ce que l'API expose
• structurer les données de sortie
• valider les données entrantes

Ici, on expose les tâches d'un projet dans le détail du projet, ce qui est très utile côté frontend.

Étape 5 — Créer une permission simple liée au propriétaire

Dans projects/permissions.py :

from rest_framework.permissions import BasePermission, SAFE_METHODS


class IsOwnerOrReadOnly(BasePermission):
    def has_object_permission(self, request, view, obj):
        if request.method in SAFE_METHODS:
            return True
        return obj.owner == request.user

Pourquoi ? Parce qu'un backend web/mobile réel ne doit pas laisser n'importe quel utilisateur modifier n'importe quel objet.

Étape 6 — Créer les viewsets DRF

Dans projects/views.py :

from rest_framework import viewsets
from rest_framework.permissions import IsAuthenticated

from .models import Project, Task
from .permissions import IsOwnerOrReadOnly
from .serializers import ProjectSerializer, TaskSerializer


class ProjectViewSet(viewsets.ModelViewSet):
    serializer_class = ProjectSerializer
    permission_classes = [IsAuthenticated, IsOwnerOrReadOnly]

    def get_queryset(self):
        return Project.objects.filter(owner=self.request.user).order_by("-created_at")

    def perform_create(self, serializer):
        serializer.save(owner=self.request.user)


class TaskViewSet(viewsets.ModelViewSet):
    serializer_class = TaskSerializer
    permission_classes = [IsAuthenticated]

    def get_queryset(self):
        return Task.objects.filter(project__owner=self.request.user).order_by("-created_at")

Pourquoi ? Parce que c'est ici qu'on traduit concrètement le use case :

• l'utilisateur ne voit que ses projets
• l'utilisateur ne crée que ses propres projets
• l'utilisateur ne voit que les tâches de ses propres projets

C'est exactement la logique d'un backend destiné à un frontend utilisateur réel.

Étape 7 — Brancher les routes

Dans projects/urls.py :

from rest_framework.routers import DefaultRouter
from .views import ProjectViewSet, TaskViewSet

router = DefaultRouter()
router.register("projects", ProjectViewSet, basename="project")
router.register("tasks", TaskViewSet, basename="task")

urlpatterns = router.urls

Dans myproduct/urls.py :

from django.contrib import admin
from django.urls import include, path

urlpatterns = [
    path("admin/", admin.site.urls),
    path("api/", include("projects.urls")),
]

Pourquoi ? Parce que l'API doit maintenant exposer une structure claire et stable :

• /api/projects/
• /api/tasks/

Étape 8 — Enregistrer les modèles dans l'admin Django

Dans projects/admin.py :

from django.contrib import admin
from .models import Project, Task

admin.site.register(Project)
admin.site.register(Task)

Pourquoi ? Parce qu'un backend web/mobile réel bénéficie souvent énormément d'une capacité d'administration simple dès le départ.

24. Vérification guidée

Lancer le serveur

python manage.py createsuperuser
python manage.py runserver

Vérifier l'admin

Ouvrir :

• http://127.0.0.1:8000/admin/

Vérifier les endpoints

Exemples :

curl -u username:password http://127.0.0.1:8000/api/projects/

curl -u username:password -X POST http://127.0.0.1:8000/api/projects/ \
  -H "Content-Type: application/json" \
  -d '{"name": "Projet mobile", "description": "Backend DRF pour app mobile"}'

Ce que tu dois observer

• un utilisateur authentifié peut créer un projet
• les projets retournés sont limités à son périmètre
• la structure JSON est propre et prévisible
• l'admin permet de visualiser les objets

25. Ce que cet exemple t'apprend vraiment

Cet exemple n'est pas juste un petit bout de code. Il montre concrètement comment DRF est utilisé dans ce use case :

• modèles pour la donnée
• serializers pour la représentation
• viewsets pour les opérations
• permissions pour le contrôle d'accès
• routers pour la structure d'API
• admin pour l'exploitation interne

Autrement dit, il traduit la théorie du chapitre en une base backend réelle.

success

Si tu comprends bien ce use case, tu as déjà franchi une étape importante : tu ne vois plus Django DRF comme un simple framework, mais comme une base sérieuse pour organiser un produit moderne avec frontend séparé et tu vois maintenant comment cela se code concrètement.