Application centrée base de données 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
• Backend pour application web ou mobile avec Django DRF
• API avec utilisateurs, rôles et permissions avec Django DRF
• Application métier / SaaS / outil interne avec Django DRF
• Produit avec back-office et admin Django
• Parcours de lecture
• FAQ, erreurs fréquentes et conseils pratiques

info

Ce tutoriel explique pourquoi Django DRF est particulièrement adapté aux applications où la donnée structurée est au centre du produit. L'objectif est de comprendre ce qu'est une application “data-centric”, comment penser les modèles, les relations, les filtres, la cohérence métier et la maintenabilité, et pourquoi Django devient souvent un choix très naturel sur ce terrain.

1. Introduction

Certaines applications sont surtout reconnues par leur interface. D'autres sont surtout définies par leur logique métier. Et d'autres encore sont avant tout structurées autour de la donnée.

Dans ce dernier cas, le cœur du système n'est pas simplement l'écran ou l'action ponctuelle. Le cœur du système est souvent :

• un ensemble d'entités bien définies
• des relations entre ces entités
• des règles de cohérence
• des opérations de lecture, recherche, filtrage, regroupement et mise à jour
• une nécessité de garder des données fiables dans le temps

C'est exactement le terrain où Django DRF devient très convaincant.

2. Le problème concret à résoudre

Imaginons des produits comme :

• un inventaire
• un catalogue produit
• une base documentaire
• un système de suivi d'actifs
• une plateforme de gestion de commandes
• un système de reporting opérationnel
• un référentiel interne
• un outil de suivi d'inspections ou d'audits

Tous ces systèmes peuvent avoir des interfaces très différentes. Mais ils partagent une même réalité de fond :

la qualité du produit dépend énormément de la qualité de la structure de la donnée.

Le vrai problème n'est donc pas seulement d'afficher des listes. Le vrai problème est de construire un backend capable de :

• représenter correctement les objets
• maintenir leur cohérence
• gérer leurs relations
• exposer proprement ces données via une API
• rester clair à mesure que le volume et la complexité augmentent

3. Qu'est-ce qu'une application centrée base de données ?

Une application centrée base de données est une application où :

• la donnée est un actif principal du système
• les objets métier sont nombreux ou riches
• les relations entre objets sont importantes
• la qualité, l'intégrité et la traçabilité des données comptent fortement
• le produit sert souvent à consulter, filtrer, croiser, mettre à jour ou superviser des informations structurées

Ce n'est pas forcément une application “juste CRUD”. Mais c'est souvent une application où le modèle de données est une pièce maîtresse de l'architecture.

4. Pourquoi Django DRF est très pertinent ici

Django DRF est particulièrement fort dans ce use case pour plusieurs raisons.

4.1 Django aime les modèles relationnels

Django a été pensé très tôt pour travailler avec des données structurées. Son ORM rend très naturelle la modélisation de :

• relations un-à-plusieurs
• relations plusieurs-à-plusieurs
• contraintes
• entités riches avec historique ou statut

4.2 DRF rend l'exposition API cohérente

Une fois les modèles bien pensés, DRF aide à construire une API claire pour :

• lister
• consulter
• filtrer
• rechercher
• paginer
• créer
• modifier
• supprimer
• exposer certaines relations de manière contrôlée

4.3 Le couple Django + DRF aide à maintenir la discipline

Dans une application data-centric, le danger est de laisser la structure des données devenir confuse. Django DRF aide à maintenir des séparations plus propres entre :

• modèle métier
• représentation API
• règles d'accès
• logique de lecture et d'écriture

4.4 Le produit peut grandir sans s'effondrer trop vite

Quand le volume de données augmente, les besoins augmentent aussi :

• filtres plus fins
• recherche
• historique
• reporting
• opérations en masse
• permissions différenciées
• validations supplémentaires

Django DRF supporte généralement bien cette montée en maturité si la base est saine.

5. Quand utiliser Django DRF pour ce cas

Ce choix est particulièrement pertinent si ton projet ressemble à ceci :

• beaucoup d'objets métier clairement identifiables
• relations structurées entre entités
• importance des requêtes de lecture
• besoin de filtres, recherche, tri, pagination
• nécessité de préserver l'intégrité de la donnée
• besoin de maintenir le projet dans le temps
• importance du back-office ou de l'administration interne

Exemples concrets :

• catalogue avec produits, catégories, variantes, fournisseurs
• système avec équipements, sites, historiques, inspections
• base documentaire avec versions, statuts, auteurs, validations
• gestion d'inventaire avec mouvements, stocks, emplacements, audits

6. Quand Django DRF n'est pas forcément le meilleur choix

Il faut aussi connaître les limites de ce raisonnement.

Django DRF n'est pas forcément le plus évident si :

• la donnée relationnelle n'est pas vraiment au centre du système
• le produit est surtout un flux temps réel très intensif
• l'application n'a presque pas de modèle de données structuré
• ton besoin porte surtout sur quelques actions très simples et peu durables
• tu veux un prototype ultra léger sans réelle ambition de pérennité

Mais dès que la donnée devient un vrai pilier du produit, Django revient souvent comme un choix naturel.

7. Pré-requis

Pour bien profiter de ce tutoriel, il est conseillé d'avoir déjà lu :

• Comprendre Django
• Comprendre Django REST Framework
• Comment penser une API avec Django DRF
• Les briques de base de Django DRF

Les tutoriels suivants sont aussi liés :

• Backend pour application web ou mobile avec Django DRF
• Application métier / SaaS / outil interne avec Django DRF
• Produit avec back-office et admin Django

8. Vocabulaire indispensable

Modèle de données

La manière dont les objets métier sont représentés, liés et structurés dans le système.

Intégrité des données

Le fait que la donnée reste cohérente, correcte et conforme aux règles du système.

Relation

Lien entre plusieurs types d'objets métier.

Filtrage

Capacité à sélectionner seulement certaines données selon des critères.

Pagination

Capacité à découper une liste longue en pages ou blocs plus gérables.

Recherche

Capacité à retrouver des objets à partir de mots-clés ou d'attributs.

ORM

Couche qui permet de manipuler la base via des objets Python, sans écrire du SQL partout.

Data-centric

Terme qui signifie que la donnée structurée est un pilier du produit.

9. Vision d'ensemble

Dans ce use case, le backend doit être vu comme un système qui :

• modélise le monde du produit
• protège la cohérence des objets
• sert des lectures fiables et exploitables
• permet des mises à jour contrôlées
• garde la structure du système compréhensible

L'idée la plus importante est la suivante :

dans une application centrée base de données, la qualité du produit dépend énormément de la qualité du modèle de données et de la clarté du backend.

10. Architecture type

Voici une architecture mentale simple pour ce type de projet.

graph TD
    A[Frontend ou client interne] --> B[API Django DRF]
    H[Admin Django / back-office] --> B
    B --> C[Modèles et ORM Django]
    B --> D[Serializers]
    B --> E[Permissions et logique d'accès]
    C --> F[Base de données relationnelle]
    B --> G[Recherche / filtres / pagination]

10.1 Le frontend ou client

Il consomme des listes, des détails, des formulaires, des filtres, des statistiques, ou des opérations de mise à jour.

10.2 L'API Django DRF

Elle expose la donnée proprement, applique des règles d'accès et renvoie des réponses cohérentes.

10.3 Les modèles et l'ORM

Ils représentent le cœur du système. C'est là que les entités et leurs relations prennent forme.

10.4 Les serializers

Ils traduisent la donnée vers l'API et valident les entrées.

10.5 Les permissions

Elles déterminent qui a le droit de voir ou manipuler quoi.

10.6 L'admin et le back-office

Ils sont souvent très utiles dans ce type d'application pour explorer, corriger et superviser les données.

11. Ce qui rend ce use case exigeant

Ce use case paraît parfois simple au début, parce qu'il ressemble à :

• des tables
• des listes
• des formulaires
• des filtres

Mais en réalité, il devient vite exigeant à cause de sujets comme :

• la qualité du modèle de données
• les relations mal pensées
• les duplications
• les règles de cohérence
• les filtres coûteux ou mal cadrés
• la complexité de lecture croisée
• les permissions sur de grands volumes de données

Autrement dit, le danger n'est pas forcément visible au premier écran. Il se cache souvent dans la qualité structurelle du backend.

12. Construction pas à pas

Voici une manière saine de construire ce type de système.

Étape 1 — Clarifier les objets métier centraux

Avant toute chose, identifie les entités principales.

Exemples :

• produit
• catégorie
• fournisseur
• stock
• site
• inspection
• rapport
• pièce jointe

Cette étape est essentielle. Si les objets sont mal pensés, tout le reste se complique.

Étape 2 — Clarifier les relations entre objets

Demande-toi :

• qu'est-ce qui appartient à quoi ?
• qu'est-ce qui référence quoi ?
• qu'est-ce qui peut exister seul ou non ?
• quels liens sont obligatoires ?
• quels liens sont multiples ?

C'est ici que beaucoup d'architectures deviennent soit très propres, soit très confuses.

Étape 3 — Identifier les règles de cohérence

Exemples :

• un objet ne peut exister sans parent
• un statut donné interdit certaines modifications
• certaines combinaisons de champs sont interdites
• une suppression est interdite si des objets liés existent encore

Ce sont ces règles qui donnent sa robustesse au système.

Étape 4 — Clarifier les usages de lecture

Dans une application data-centric, la lecture est souvent au moins aussi importante que l'écriture.

Il faut se demander :

• quelles listes seront consultées ?
• quels filtres seront utiles ?
• quelles recherches seront fréquentes ?
• quels regroupements ou vues d'ensemble seront nécessaires ?

Étape 5 — Clarifier les usages d'écriture

Ensuite, demande-toi :

• qui crée ?
• qui modifie ?
• quels champs sont éditables ?
• à quelles étapes ?
• quelles validations sont nécessaires ?

Étape 6 — Penser les permissions assez tôt

Même une application centrée sur la donnée n'est pas neutre en termes d'accès.

Questions importantes :

• tout le monde voit-il toutes les données ?
• certaines organisations voient-elles seulement leurs propres objets ?
• certains rôles ont-ils accès à des champs sensibles ?
• certaines écritures sont-elles réservées ?

Étape 7 — Prévoir les filtres, la pagination et la recherche dès la conception

Ce n'est pas un “bonus de fin de projet”. Dans une application orientée données, ces éléments sont centraux pour l'expérience utilisateur et la maintenabilité.

Étape 8 — Prévoir l'administration et l'exploration des données

Ce point a été approfondi dans Produit avec back-office et admin Django. Mais ici il revient fortement : quand la donnée est centrale, les équipes internes ont souvent besoin de l'explorer et de la corriger.

Étape 9 — Penser à la croissance du modèle

Demande-toi :

• que se passe-t-il si le nombre d'objets double ?
• si les relations se multiplient ?
• si de nouveaux champs ou statuts apparaissent ?
• si le reporting devient plus riche ?

Étape 10 — Garder le système lisible

Le plus grand danger de ce use case est de construire un système de données devenu trop dense, trop implicite ou trop difficile à expliquer.

13. Exemple concret mental

Prenons un exemple simple : une plateforme de gestion d'inventaire technique.

Objets centraux

• site
• équipement
• catégorie d'équipement
• intervention
• rapport d'inspection
• pièce jointe
• utilisateur

Relations

• un site possède plusieurs équipements
• un équipement peut avoir plusieurs inspections
• une inspection peut générer plusieurs pièces jointes
• certaines inspections sont liées à certains utilisateurs ou équipes

Besoins typiques

• rechercher un équipement par site, type ou statut
• voir l'historique des inspections
• filtrer les éléments non conformes
• créer ou mettre à jour un rapport
• superviser les anomalies

Tu vois ici que l'essentiel du produit repose sur la structure et l'exploitation de la donnée.

14. Ce que le frontend ne doit pas porter seul

Même dans une application très orientée donnée, le frontend ne doit pas devenir l'endroit où l'on reconstruit toute la logique des relations, des permissions ou de la cohérence.

Le backend doit rester responsable de :

• la vérité du modèle
• la cohérence de la donnée
• les permissions
• les validations importantes
• la stabilité de l'API

Le frontend peut aider à afficher, trier localement certaines choses ou guider l'utilisateur. Mais il ne doit pas être la seule garantie de cohérence.

15. Erreurs fréquentes

Erreur 1 — Penser uniquement en tables, pas en objets métier

On obtient un schéma technique, mais pas un vrai modèle lisible pour le produit.

Erreur 2 — Sous-estimer l'importance des usages de lecture

Le produit devient vite frustrant si les listes, filtres et recherches n'ont pas été pensés tôt.

Erreur 3 — Exposer trop brutalement les relations

Une API peut devenir confuse ou bavarde si elle reflète les relations sans stratégie claire.

Erreur 4 — Ajouter la qualité de donnée après coup

Quand l'intégrité est traitée trop tard, le nettoyage devient coûteux.

Erreur 5 — Oublier l'administration interne

Quand la donnée est centrale, l'équipe interne a presque toujours besoin d'outils pour l'inspecter et la corriger.

Erreur 6 — Multiplier les champs et relations sans gouvernance

Le système devient rapidement opaque.

16. Bonnes pratiques

16.1 Nommer clairement les objets métier

Si les modèles sont difficiles à expliquer en français simple, c'est souvent un mauvais signal.

16.2 Faire du modèle de données un sujet de conception, pas un détail technique

Le modèle est une partie du produit.

16.3 Penser les usages de lecture aussi sérieusement que les usages d'écriture

Les utilisateurs passent souvent énormément de temps à consulter, rechercher et filtrer.

16.4 Préserver la cohérence à plusieurs niveaux

• modèle
• validation API
• logique métier
• permissions

16.5 Prévoir l'administration et l'exploration interne

Surtout si la donnée est stratégique pour le produit.

16.6 Garder une structure explicable

Si l'architecture ne peut plus être expliquée clairement à quelqu'un de l'équipe, elle risque déjà de dériver.

17. Variantes et évolutions possibles

Variante 1 — Référentiel simple

Catalogue ou base de référence avec peu d'écritures mais beaucoup de lecture.

Variante 2 — Application métier riche en lecture et écriture

Données, statuts, pièces jointes, historiques, validations.

Variante 3 — Data-centric avec forte dimension de reporting

Beaucoup de tableaux, filtres, exports, agrégations, supervision.

Variante 4 — Plateforme multi-équipe ou multi-organisation

Les permissions et la visibilité des données deviennent plus complexes.

Variante 5 — Produit plus mature avec exigences accrues

Historique détaillé, audit, performances, structures de recherche plus avancées, outillage interne renforcé.

18. Comment savoir si tu vas dans la bonne direction

Tu avances bien si :

• tu sais expliquer clairement les objets du système
• les relations sont compréhensibles
• les règles de cohérence sont identifiées
• les usages de lecture ont été pensés sérieusement
• l'API n'expose pas la donnée de manière brute et confuse
• les équipes internes peuvent aussi explorer et superviser les données

19. Résumé final

Django DRF est un excellent choix pour une application centrée base de données lorsque le produit repose fortement sur :

• des objets métier structurés
• des relations claires
• des opérations de lecture riches
• des besoins de filtres, recherche et pagination
• une exigence de cohérence et de durabilité

Sa force vient du fait qu'il combine bien :

• un ORM très naturel pour les modèles relationnels
• une API claire avec DRF
• un cadre structurant pour la validation et les permissions
• des outils utiles pour l'administration et l'exploitation

L'idée la plus importante à retenir est la suivante :

dans une application data-centric, la base de données n'est pas un simple détail technique ; elle fait partie de l'architecture profonde du produit.

20. Pour aller plus loin

La suite logique du wiki peut maintenant être :

• API B2B / API interne avec Django DRF
• ou Backend produit autour d'un système IA avec Django DRF
• ou une future comparaison dédiée : modèle relationnel bien pensé vs modèle bricolé

Relire aussi :

• Application métier / SaaS / outil interne avec Django DRF
• Produit avec back-office et admin Django
• Comment penser une API avec Django DRF
• Les briques de base de Django DRF

21. Mini-projet guidé avec code

Pour rendre ce use case concret, on va prendre un exemple très représentatif d'application data-centric :

un inventaire d'équipements avec sites, matériel, historique de maintenance, recherche et filtres

Le but du mini-projet est de montrer comment Django DRF aide à :

• modéliser des relations claires
• exposer une API structurée
• proposer des filtres, une recherche et une pagination utiles
• garder la donnée centrale dans l'architecture du produit

22. Structure du mini-projet

datacore/
├── manage.py
├── datacore/
│   ├── settings.py
│   ├── urls.py
│   └── ...
└── inventory/
    ├── admin.py
    ├── models.py
    ├── serializers.py
    ├── views.py
    └── urls.py

Repères utiles avant de lire le code :

• settings.py active les filtres, la recherche, l'ordre et la pagination.
• models.py structure les relations entre Site, Equipment et MaintenanceRecord.
• serializers.py expose les relations de manière lisible pour le client API.
• views.py centralise la navigation dans la donnée : filtre, recherche et tri.
• urls.py expose la ressource /api/equipments/.
• admin.py aide à corriger, enrichir et explorer rapidement les enregistrements.

23. Implémentation guidée avec code

Étape 1 — Créer le projet et installer les dépendances utiles

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

django-admin startproject datacore .
python manage.py startapp inventory

Pourquoi ? Parce qu'une application centrée base de données a très souvent besoin de filtres et de navigation riche dans les données.

Étape 2 — Déclarer DRF, django-filter et l'application

Dans datacore/settings.py :

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

REST_FRAMEWORK = {
    "DEFAULT_PERMISSION_CLASSES": [
        "rest_framework.permissions.IsAuthenticated",
    ],
    "DEFAULT_AUTHENTICATION_CLASSES": [
        "rest_framework.authentication.SessionAuthentication",
        "rest_framework.authentication.BasicAuthentication",
    ],
    "DEFAULT_FILTER_BACKENDS": [
        "django_filters.rest_framework.DjangoFilterBackend",
        "rest_framework.filters.SearchFilter",
        "rest_framework.filters.OrderingFilter",
    ],
    "DEFAULT_PAGINATION_CLASS": "rest_framework.pagination.PageNumberPagination",
    "PAGE_SIZE": 10,
}

Pourquoi ? Parce qu'ici la qualité d'usage de l'API dépend beaucoup de la manière dont on peut parcourir la donnée.

Étape 3 — Modéliser les relations métier

Dans inventory/models.py :

from django.db import models


class Site(models.Model):
    name = models.CharField(max_length=120)
    city = models.CharField(max_length=120)

    def __str__(self) -> str:
        return f"{self.name} ({self.city})"


class Equipment(models.Model):
    site = models.ForeignKey(
        Site,
        on_delete=models.CASCADE,
        related_name="equipments",
    )
    name = models.CharField(max_length=150)
    category = models.CharField(max_length=80)
    serial_number = models.CharField(max_length=120, unique=True)
    installed_at = models.DateField()
    is_active = models.BooleanField(default=True)

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


class MaintenanceRecord(models.Model):
    equipment = models.ForeignKey(
        Equipment,
        on_delete=models.CASCADE,
        related_name="maintenance_records",
    )
    performed_at = models.DateField()
    performed_by = models.CharField(max_length=120)
    note = models.TextField()

    def __str__(self) -> str:
        return f"{self.equipment} - {self.performed_at}"

Puis lancer :

python manage.py makemigrations
python manage.py migrate

Pourquoi ? Parce qu'on veut montrer dès le départ qu'une application data-centric vit sur des relations explicites :

• un site possède des équipements
• un équipement possède un historique de maintenance

Étape 4 — Créer les serializers

Dans inventory/serializers.py :

from rest_framework import serializers

from .models import Equipment, MaintenanceRecord


class MaintenanceRecordSerializer(serializers.ModelSerializer):
    class Meta:
        model = MaintenanceRecord
        fields = ["id", "performed_at", "performed_by", "note"]
        read_only_fields = ["id"]


class EquipmentSerializer(serializers.ModelSerializer):
    site_name = serializers.CharField(source="site.name", read_only=True)
    maintenance_records = MaintenanceRecordSerializer(many=True, read_only=True)

    class Meta:
        model = Equipment
        fields = [
            "id",
            "site",
            "site_name",
            "name",
            "category",
            "serial_number",
            "installed_at",
            "is_active",
            "maintenance_records",
        ]
        read_only_fields = ["id", "site_name", "maintenance_records"]

Pourquoi ? Parce qu'une bonne API data-centric doit rendre les relations lisibles sans obliger le frontend à tout reconstruire à la main.

Étape 5 — Exposer une vue DRF orientée données

Dans inventory/views.py :

from rest_framework import viewsets
from rest_framework.permissions import IsAuthenticated

from .models import Equipment
from .serializers import EquipmentSerializer


class EquipmentViewSet(viewsets.ModelViewSet):
    serializer_class = EquipmentSerializer
    permission_classes = [IsAuthenticated]
    queryset = (
        Equipment.objects.select_related("site")
        .prefetch_related("maintenance_records")
        .order_by("name")
    )
    filterset_fields = ["site", "category", "is_active"]
    search_fields = ["name", "serial_number"]
    ordering_fields = ["name", "installed_at"]

Pourquoi ce code est important ? Parce qu'il montre très concrètement comment DRF sert ici à faire plus qu'un simple CRUD :

• filtrer
• rechercher
• ordonner
• paginer
• précharger proprement les relations

Étape 6 — Brancher les routes

Dans inventory/urls.py :

from rest_framework.routers import DefaultRouter

from .views import EquipmentViewSet

router = DefaultRouter()
router.register("equipments", EquipmentViewSet, basename="equipment")

urlpatterns = router.urls

Dans datacore/urls.py :

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

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

Étape 7 — Ajouter l'admin Django

Dans inventory/admin.py :

from django.contrib import admin

from .models import Equipment, MaintenanceRecord, Site

admin.site.register(Site)
admin.site.register(Equipment)
admin.site.register(MaintenanceRecord)

Pourquoi ? Parce qu'un projet centré base de données bénéficie énormément d'un outil simple pour corriger, enrichir et explorer rapidement les enregistrements.

24. Vérification guidée

Lancer le serveur

python manage.py createsuperuser
python manage.py runserver

Préparer quelques données dans l'admin

Créer :

• 2 sites
• plusieurs équipements
• quelques historiques de maintenance

Tester la liste paginée

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

Tester les filtres

curl -u username:password "http://127.0.0.1:8000/api/equipments/?site=1&category=capteur&is_active=true"

Tester la recherche et l'ordre

curl -u username:password "http://127.0.0.1:8000/api/equipments/?search=SN-2026&ordering=-installed_at"

Ce que tu dois observer

• la donnée est structurée autour des relations
• l'API permet d'explorer un corpus sans bricolage frontend inutile
• la pagination évite de tout charger d'un coup
• les filtres et la recherche rendent l'API vraiment exploitable

25. Ce que cet exemple t'apprend vraiment

Cet exemple montre comment DRF est utilisé concrètement dans une application centrée base de données :

• l'ORM Django structure les relations
• le serializer expose ces relations proprement
• le viewset devient un point d'accès de consultation et d'édition
• les filtres DRF transforment l'API en outil de navigation dans la donnée
• l'admin Django aide à faire vivre et contrôler la base

Autrement dit, on voit ici que la base de données n'est pas cachée derrière l'application : elle organise la forme même du produit et de son API.

success

Si tu comprends bien ce mini-projet, tu commences à voir qu'une bonne application data-centric ne repose pas seulement sur “une base quelque part”, mais sur un modèle de données lisible, interrogeable et durable.