Aller au contenu principal

Produit avec back-office et admin Django

Repères utiles :

info

Ce tutoriel explique pourquoi Django est particulièrement intéressant lorsqu'un produit a besoin d'un back-office, d'une interface d'administration ou d'outils d'exploitation internes. L'objectif est de comprendre la différence entre produit utilisateur, back-office et admin Django, de savoir quand l'admin intégré suffit, quand il faut aller plus loin, et comment construire un backend qui sert aussi les équipes internes.

1. Introduction​

Quand on parle d'un produit numérique, on pense souvent d'abord à l'interface visible par l'utilisateur final.

Mais dans énormément de projets réels, cette interface publique ou client n'est qu'une partie du système. En coulisses, il faut aussi souvent :

  • corriger des données
  • vérifier des comptes
  • modérer du contenu
  • relancer un workflow
  • suivre des incidents
  • valider certaines étapes
  • aider le support
  • superviser l'activité

Autrement dit, le produit a souvent besoin d'un back-office. Et c'est précisément l'un des domaines où Django possède un avantage historique très fort grâce à son admin intégré.

2. Le problème concret à résoudre​

Imaginons un produit qui fonctionne déjà côté utilisateur. Les clients peuvent :

  • créer des comptes
  • utiliser des fonctionnalités
  • générer des objets métier
  • soumettre des demandes
  • consulter leurs résultats

Tout semble bien aller. Mais très vite, l'équipe interne se retrouve face à des besoins très concrets :

  • un utilisateur a un problème et il faut inspecter son dossier
  • une donnée est incohérente et doit être corrigée
  • un workflow est bloqué et il faut comprendre pourquoi
  • un rôle doit être changé manuellement
  • un document doit être revu ou supprimé
  • un compte doit être suspendu
  • une activité suspecte doit être analysée

Le vrai problème n'est donc pas seulement de construire une application pour les utilisateurs. Le vrai problème est de construire aussi un système opérable par l'équipe qui porte le produit.

3. Pourquoi ce use case est si important​

Beaucoup de projets découvrent ce sujet trop tard.

Au début, toute l'énergie va sur :

  • le frontend client
  • l'API principale
  • les fonctionnalités visibles

Puis un jour l'équipe se rend compte qu'elle n'a pas de bons outils pour :

  • superviser
  • corriger
  • auditer
  • assister
  • administrer

Et là, le coût monte vite.

Un bon produit n'est pas seulement utilisable par ses clients. Il doit aussi être pilotable par ses équipes internes.

4. Qu'est-ce qu'un back-office ?​

Un back-office est une interface ou un ensemble d'outils utilisés par les équipes internes pour gérer, surveiller, corriger ou administrer le produit.

Exemples d'usages de back-office :

  • consulter un dossier utilisateur
  • changer un statut
  • modérer un contenu
  • réinitialiser un paramètre
  • vérifier des événements métier
  • exporter des données
  • corriger une anomalie
  • superviser un workflow

Un back-office n'est donc pas simplement “une deuxième interface”. C'est un outil de travail pour les équipes internes.

5. Qu'est-ce que l'admin Django ?​

L'admin Django est une interface d'administration générée à partir de tes modèles Django.

Elle permet souvent très vite de :

  • lister des objets
  • les rechercher
  • les filtrer
  • les consulter
  • les modifier
  • les supprimer
  • gérer certains liens entre objets

C'est un des grands atouts de Django. Et c'est aussi l'une des raisons pour lesquelles il est très apprécié dans les produits métiers, les SaaS et les outils internes.

6. Ce qu'il faut comprendre tout de suite​

Il y a trois choses différentes qu'il faut bien distinguer.

6.1 Le produit utilisateur​

C'est ce que voit le client ou l'utilisateur final.

6.2 Le back-office​

C'est l'interface ou la logique interne utilisée par les équipes du produit.

6.3 L'admin Django​

C'est un outil interne extrêmement puissant, mais ce n'est pas automatiquement un back-office final parfait pour tous les cas.

Cette distinction est très importante.

attention

L'admin Django peut être une solution parfaite dans certains contextes, une excellente solution transitoire dans d'autres, et une base insuffisante dans d'autres encore. Tout dépend du besoin réel.

7. Pourquoi Django est particulièrement pertinent ici​

Django est très fort pour ce use case pour plusieurs raisons.

7.1 L'admin est native​

Contrairement à beaucoup d'autres stacks, Django te donne très tôt une interface interne exploitable.

7.2 L'admin repose sur les modèles​

Si tes modèles sont bien pensés, tu peux rapidement administrer une grande partie du système.

7.3 Django aime les produits structurés​

Dès qu'il y a :

  • des objets métier
  • des relations
  • des statuts
  • des rôles
  • des permissions
  • des besoins d'exploitation

Django devient très naturel.

7.4 Le couple Django + DRF permet deux mondes complémentaires​

  • DRF expose une API propre pour les clients du produit
  • Django admin ou un back-office dédié aide les équipes internes à piloter le système

Cette combinaison est très puissante.

8. Quand utiliser Django DRF pour ce cas​

C'est un excellent choix si ton produit a besoin :

  • d'une API pour le frontend utilisateur
  • d'une base de données structurée
  • d'un outil interne pour supervision ou support
  • d'une interface d'administration rapide
  • d'une logique métier durable
  • d'opérations internes fréquentes
  • de rôles et permissions bien définis

Exemples typiques :

  • produit SaaS avec support client
  • outil métier avec étapes de validation
  • plateforme avec modération
  • app où certains objets doivent être revus ou corrigés en interne
  • système où une équipe admin ou ops intervient régulièrement

9. Quand ce n'est pas forcément le bon angle​

Ce use case est moins central si :

  • tu construis un produit très petit, très simple, et sans véritable exploitation interne
  • tu n'as presque jamais besoin d'agir côté équipe interne
  • tu veux un prototype très jetable
  • tu n'as pas de données sensibles ni de besoin d'administration réelle

Mais encore une fois, beaucoup de produits pensent être “simples” jusqu'au jour où le support, la correction manuelle ou la supervision deviennent incontournables.

10. Pré-requis​

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

Les notes suivantes sont aussi très liées :

11. Vocabulaire indispensable​

Back-office​

Interface ou outillage utilisé par les équipes internes pour piloter le produit.

Admin Django​

Interface d'administration générée par Django autour des modèles.

Modération​

Action qui consiste à contrôler, valider, cacher ou supprimer certains contenus ou objets.

Exploitation​

Ensemble des besoins liés au fonctionnement quotidien du produit : supervision, correction, assistance, opérations internes.

Audit​

Capacité à vérifier qui a fait quoi, sur quoi et quand.

Support​

Travail d'assistance aux utilisateurs ou aux équipes.

Outil interne​

Outil réservé à l'équipe ou à l'organisation qui exploite le produit.

12. Vision d'ensemble​

Dans ce use case, il faut arrêter de penser le backend seulement comme une couche API pour le frontend client.

Le backend devient aussi :

  • la source de vérité des données
  • le gardien des règles métier
  • le support de l'exploitation interne
  • la base de l'administration du produit

On peut résumer le tout comme ceci :

  1. le produit utilisateur sert les clients
  2. l'API Django DRF structure les interactions applicatives
  3. la logique métier protège les règles du système
  4. le back-office et/ou l'admin Django servent les équipes internes
  5. la base de données garde l'état et l'historique

13. Architecture type​

Voici une architecture simple pour raisonner correctement.

graph TD
    A[Frontend utilisateur] --> B[API Django DRF]
    H[Back-office interne] --> B
    I[Admin Django] --> E[Base de données]
    B --> C[Logique métier]
    B --> D[Authentification et permissions]
    C --> E[Base de données]
    C --> F[Audit / historique / opérations]
    C --> G[Services externes optionnels]

13.1 Frontend utilisateur​

Il sert l'expérience du client ou de l'utilisateur final.

13.2 API Django DRF​

Elle structure les opérations applicatives normales.

13.3 Back-office interne​

Il sert les besoins métiers internes, le support, la supervision ou la validation.

13.4 Admin Django​

Il peut servir de :

  • point d'administration rapide
  • outil support
  • outil ops
  • base de travail avant un back-office plus sur mesure

13.5 Audit et historique​

Ils deviennent souvent très importants dans ce type de produit.

14. Quand l'admin Django suffit vraiment​

Il faut être honnête : dans beaucoup de projets, l'admin Django est déjà extrêmement utile.

Il peut suffire si tu as surtout besoin de :

  • consulter les objets
  • corriger certaines données
  • filtrer et rechercher
  • modifier quelques statuts
  • gérer des comptes ou des objets métier simples
  • aider une petite équipe interne

Dans ce cas, chercher tout de suite à construire un back-office custom peut être inutilement coûteux.

15. Quand l'admin Django ne suffit plus vraiment​

L'admin Django atteint ses limites quand les besoins internes deviennent plus sophistiqués.

Exemples :

  • parcours internes très spécifiques
  • ergonomie métier complexe
  • tableaux de bord opérationnels avancés
  • workflows de validation riches
  • interfaces conçues pour des équipes non techniques nombreuses
  • actions internes très guidées et contextuelles

Dans ce cas, il faut souvent compléter ou remplacer certaines parties par un back-office plus spécifique.

16. La vraie bonne question à se poser​

La bonne question n'est pas :

“Est-ce que je dois utiliser l'admin Django ?”

La bonne question est plutôt :

“De quels outils internes mes équipes ont-elles réellement besoin pour opérer le produit correctement ?”

Ensuite seulement, on décide si :

  • l'admin Django suffit
  • l'admin Django suffit au début
  • il faut un back-office dédié
  • il faut un mélange des deux

17. Construction pas à pas​

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

Étape 1 — Identifier les besoins d'exploitation​

Ne pense pas seulement au client final. Liste les besoins de l'équipe interne.

Exemples :

  • rechercher un utilisateur
  • voir ses objets liés
  • corriger un statut
  • relancer un processus
  • vérifier un historique
  • modérer un contenu
  • suspendre un compte

Étape 2 — Distinguer les besoins support, ops, admin et métier​

Tous les besoins internes ne sont pas identiques.

Exemples :

  • support : aider un utilisateur
  • ops : surveiller le bon fonctionnement
  • admin : configurer ou corriger
  • métier : valider ou superviser un processus

Cette distinction aide à ne pas tout mélanger dans une seule interface confuse.

Étape 3 — Identifier quelles ressources doivent être administrables​

Tout n'a pas forcément besoin d'être administré de la même façon.

Exemples :

  • utilisateurs
  • dossiers
  • commandes
  • contenus
  • pièces jointes
  • événements
  • historiques

Étape 4 — Identifier quelles actions internes sont sensibles​

Par exemple :

  • changement de rôle
  • suppression
  • validation forcée
  • modification de statut
  • accès à certaines données confidentielles

Ces actions demandent souvent une attention particulière côté permissions et audit.

Étape 5 — Décider ce qui passe par l'admin Django​

Pose-toi :

  • cette action est-elle surtout technique ou opérationnelle ?
  • son ergonomie peut-elle rester simple ?
  • un outil générique suffit-il ?

Si oui, l'admin Django peut être parfait.

Étape 6 — Décider ce qui mérite un vrai back-office métier​

Si l'équipe interne a besoin de :

  • parcours dédiés
  • vues synthétiques spécifiques
  • actions guidées
  • dashboards ciblés
  • écrans adaptés à un processus métier précis

alors un back-office plus dédié est souvent préférable.

Étape 7 — Prévoir l'audit et l'historique​

Dans ce type de produit, une question arrive souvent tôt ou tard :

  • qui a fait ce changement ?
  • quand ?
  • dans quel contexte ?

Ne pas prévoir cela assez tôt peut vite rendre le produit difficile à exploiter.

Étape 8 — Prévoir des permissions internes sérieuses​

Le fait qu'une interface soit “interne” ne veut pas dire que tout le monde doit pouvoir tout faire.

Il faut se demander :

  • qui peut lire ?
  • qui peut modifier ?
  • qui peut supprimer ?
  • qui peut voir des données sensibles ?
  • qui peut effectuer une action d'administration ?

Étape 9 — Penser la qualité de vie des équipes internes​

Une interface interne mal pensée coûte du temps, crée des erreurs et fatigue les équipes.

Il faut donc penser aussi :

  • recherche
  • filtres
  • lisibilité
  • sécurité des actions
  • confirmations
  • historique
  • repérage rapide des anomalies

Étape 10 — Ne pas surconstruire trop tôt​

Il faut rester pragmatique.

Souvent, une bonne stratégie est :

  1. démarrer avec l'admin Django
  2. observer les vrais besoins internes
  3. créer ensuite un back-office plus ciblé là où c'est nécessaire

18. Exemple concret mental​

Imaginons une plateforme de gestion documentaire.

Côté utilisateur​

Les clients peuvent :

  • déposer des documents
  • voir leur statut
  • recevoir un résultat ou une validation

Côté interne​

L'équipe a besoin de :

  • voir les documents en attente
  • corriger des métadonnées
  • reclasser certains objets
  • valider ou rejeter certains cas
  • aider les utilisateurs en difficulté
  • auditer des changements sensibles

Dans ce cas :

  • l'API Django DRF sert le produit utilisateur
  • l'admin Django peut déjà aider à gérer une partie des opérations
  • un back-office dédié peut devenir utile pour les validations ou la supervision fine

19. Ce que le frontend utilisateur ne doit pas porter​

Une erreur classique consiste à vouloir faire passer tous les besoins internes dans le frontend principal.

Ce n'est généralement pas une bonne idée.

Le frontend utilisateur doit servir l'utilisateur final. Il ne doit pas devenir un cockpit brouillon pour le support, l'admin, la modération et les opérations internes.

C'est précisément pour cela que la séparation :

  • produit utilisateur
  • back-office
  • admin

est si importante.

20. Erreurs fréquentes​

Erreur 1 — Oublier l'exploitation jusqu'à la fin​

On découvre trop tard que l'équipe interne n'a pas d'outils corrects.

Erreur 2 — Croire que l'admin Django remplace automatiquement tout back-office​

Parfois oui, souvent partiellement, parfois non. Il faut juger selon le besoin réel.

Erreur 3 — Construire un back-office custom trop tôt​

L'inverse existe aussi. On peut surinvestir dans une interface interne sur mesure avant d'avoir compris les vrais usages.

Erreur 4 — Oublier les permissions internes​

Une interface interne non contrôlée peut devenir très risquée.

Erreur 5 — Négliger l'audit​

Sans historique ni visibilité sur les actions sensibles, l'exploitation devient fragile.

Erreur 6 — Mélanger produit utilisateur et opérations internes​

Cela dégrade souvent les deux mondes à la fois.

21. Bonnes pratiques​

21.1 Identifier tôt les besoins internes​

Le produit n'est pas seulement fait pour le client ; il est aussi vécu par les équipes qui le maintiennent.

21.2 Utiliser l'admin Django intelligemment​

L'admin n'est pas un gadget. C'est souvent un accélérateur très puissant.

21.3 Faire simple au début, puis spécialiser​

Commencer pragmatique, puis construire un back-office plus sur mesure là où le besoin est prouvé.

21.4 Protéger les actions sensibles​

Tout ce qui modifie fortement le système doit être bien encadré.

21.5 Prévoir l'audit et la supervision​

Surtout si le produit a un impact métier fort.

21.6 Séparer les rôles des interfaces​

Tous les outils internes ne doivent pas être accessibles à tous les rôles.

22. Variantes et évolutions possibles​

Variante 1 — Produit simple avec admin Django uniquement​

Très valable pour certaines équipes petites ou moyennes.

Variante 2 — Produit avec admin + quelques écrans internes dédiés​

Approche souvent très saine.

Variante 3 — Produit avec vrai back-office métier​

Nécessaire quand les besoins internes sont riches et fréquents.

Variante 4 — Produit avec forte exigence d'audit​

Nécessite plus d'historique, de traçabilité et de contrôle.

Variante 5 — Produit plus mature avec plusieurs équipes internes​

Support, ops, conformité, métier, admin : chacun peut avoir ses besoins propres.

23. Comment savoir si tu es sur la bonne voie​

Tu avances bien si :

  • tu sais distinguer produit utilisateur, admin et back-office
  • tu sais quelles actions internes sont réellement nécessaires
  • tu n'imposes pas trop tôt une interface sur mesure inutile
  • tu n'oublies pas l'audit, la sécurité et l'exploitation
  • ton équipe interne peut travailler sans bricoler la base de données à la main

24. Résumé final​

Django est particulièrement fort quand un produit a besoin non seulement d'une API ou d'une interface utilisateur, mais aussi d'une vraie capacité d'administration et d'exploitation interne.

Son avantage distinctif ici vient du fait qu'il permet de combiner :

  • un backend structuré
  • une logique métier durable
  • une API propre avec DRF
  • un admin intégré immédiatement utile
  • la possibilité de faire évoluer ensuite un vrai back-office métier

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

un bon produit n'est pas seulement bien conçu pour ses utilisateurs finaux ; il doit aussi être bien outillé pour les équipes qui le pilotent et le maintiennent.

25. Pour aller plus loin​

La suite logique du wiki peut maintenant être :

Relire aussi :

26. Mini-projet guidé avec code​

Pour rendre ce use case concret, on va prendre un exemple très représentatif :

un produit avec des commandes clients, un espace interne de suivi, et un back-office réservé aux équipes opérationnelles

Le but du mini-projet est de montrer :

  • comment Django peut fournir un admin immédiat
  • comment DRF peut exposer une API back-office dédiée
  • comment les équipes internes peuvent exécuter des actions métier sans dépendre du frontend utilisateur

27. Structure du mini-projet​

opsdesk/
├── manage.py
├── opsdesk/
│   ├── settings.py
│   ├── urls.py
│   └── ...
└── orders/
    ├── admin.py
    ├── models.py
    ├── serializers.py
    ├── permissions.py
    ├── views.py
    └── urls.py

Repères utiles avant de lire le code :

  • models.py structure la commande client et l'historique d'événements internes.
  • serializers.py renvoie la commande avec le contexte opérationnel utile au back-office.
  • permissions.py limite l'API interne aux comptes staff.
  • views.py expose des actions métier concrètes comme mark_paid et ship.
  • urls.py sépare explicitement l'API back-office du reste du produit.
  • admin.py fournit immédiatement une interface interne exploitable pour l'équipe.

28. Implémentation guidée avec code​

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

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

django-admin startproject opsdesk .
python manage.py startapp orders

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

Dans opsdesk/settings.py :

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

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

Étape 3 — Modéliser les commandes et les événements internes​

Dans orders/models.py :

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


class CustomerOrder(models.Model):
    STATUS_CHOICES = [
        ("new", "New"),
        ("paid", "Paid"),
        ("shipped", "Shipped"),
        ("cancelled", "Cancelled"),
    ]

    customer = models.ForeignKey(
        settings.AUTH_USER_MODEL,
        on_delete=models.CASCADE,
        related_name="customer_orders",
    )
    reference = models.CharField(max_length=40, unique=True)
    status = models.CharField(max_length=20, choices=STATUS_CHOICES, default="new")
    total_amount = models.DecimalField(max_digits=10, decimal_places=2)
    shipping_address = models.TextField()
    internal_note = models.TextField(blank=True)
    created_at = models.DateTimeField(auto_now_add=True)

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


class OrderEvent(models.Model):
    order = models.ForeignKey(
        CustomerOrder,
        on_delete=models.CASCADE,
        related_name="events",
    )
    event_type = models.CharField(max_length=50)
    comment = models.TextField(blank=True)
    created_by = models.ForeignKey(
        settings.AUTH_USER_MODEL,
        on_delete=models.CASCADE,
        related_name="order_events",
    )
    created_at = models.DateTimeField(auto_now_add=True)

    def __str__(self) -> str:
        return f"{self.order.reference} - {self.event_type}"

Puis lancer :

python manage.py makemigrations
python manage.py migrate

Pourquoi ? Parce qu'un back-office sérieux ne manipule pas seulement un état courant : il a aussi besoin d'un historique d'actions internes.

Étape 4 — Créer les serializers​

Dans orders/serializers.py :

from rest_framework import serializers

from .models import CustomerOrder, OrderEvent


class OrderEventSerializer(serializers.ModelSerializer):
    created_by = serializers.StringRelatedField(read_only=True)

    class Meta:
        model = OrderEvent
        fields = ["id", "event_type", "comment", "created_by", "created_at"]
        read_only_fields = ["id", "created_by", "created_at"]


class CustomerOrderSerializer(serializers.ModelSerializer):
    customer = serializers.StringRelatedField(read_only=True)
    events = OrderEventSerializer(many=True, read_only=True)

    class Meta:
        model = CustomerOrder
        fields = [
            "id",
            "reference",
            "customer",
            "status",
            "total_amount",
            "shipping_address",
            "internal_note",
            "created_at",
            "events",
        ]
        read_only_fields = ["id", "customer", "status", "created_at", "events"]

Pourquoi ? Parce que l'API back-office ne doit pas juste renvoyer une commande brute : elle doit aussi donner du contexte opérationnel.

Étape 5 — Poser une permission staff-only​

Dans orders/permissions.py :

from rest_framework.permissions import BasePermission


class IsBackOfficeStaff(BasePermission):
    def has_permission(self, request, view):
        return bool(request.user and request.user.is_authenticated and request.user.is_staff)

    def has_object_permission(self, request, view, obj):
        return bool(request.user and request.user.is_staff)

Pourquoi ? Parce que cette API n'est pas destinée aux clients finaux. Elle est destinée aux équipes internes.

Étape 6 — Écrire le viewset back-office​

Dans orders/views.py :

from rest_framework import status, viewsets
from rest_framework.decorators import action
from rest_framework.permissions import IsAuthenticated
from rest_framework.response import Response

from .models import CustomerOrder, OrderEvent
from .permissions import IsBackOfficeStaff
from .serializers import CustomerOrderSerializer


class BackOfficeOrderViewSet(viewsets.ModelViewSet):
    serializer_class = CustomerOrderSerializer
    permission_classes = [IsAuthenticated, IsBackOfficeStaff]

    def get_queryset(self):
        return CustomerOrder.objects.select_related("customer").prefetch_related("events").order_by("-created_at")

    @action(detail=True, methods=["post"])
    def mark_paid(self, request, pk=None):
        order = self.get_object()
        if order.status != "new":
            return Response(
                {"detail": "Seule une commande nouvelle peut être marquée comme payée."},
                status=status.HTTP_400_BAD_REQUEST,
            )

        order.status = "paid"
        order.save(update_fields=["status"])
        OrderEvent.objects.create(
            order=order,
            event_type="marked_paid",
            comment="Paiement validé par le back-office.",
            created_by=request.user,
        )
        return Response(self.get_serializer(order).data)

    @action(detail=True, methods=["post"])
    def ship(self, request, pk=None):
        order = self.get_object()
        if order.status != "paid":
            return Response(
                {"detail": "Seule une commande payée peut être expédiée."},
                status=status.HTTP_400_BAD_REQUEST,
            )

        order.status = "shipped"
        order.save(update_fields=["status"])
        OrderEvent.objects.create(
            order=order,
            event_type="shipped",
            comment="Commande expédiée.",
            created_by=request.user,
        )
        return Response(self.get_serializer(order).data)

Pourquoi ce code est intéressant ? Parce qu'il montre très bien la différence entre :

  • un simple CRUD générique
  • et une API interne pensée pour les opérateurs

Le back-office n'a pas seulement besoin de lire des commandes. Il a besoin d'exécuter des actions métier utiles.

Étape 7 — Brancher les routes​

Dans orders/urls.py :

from rest_framework.routers import DefaultRouter

from .views import BackOfficeOrderViewSet

router = DefaultRouter()
router.register("backoffice/orders", BackOfficeOrderViewSet, basename="backoffice-order")

urlpatterns = router.urls

Dans opsdesk/urls.py :

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

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

Étape 8 — Configurer un admin Django utile tout de suite​

Dans orders/admin.py :

from django.contrib import admin

from .models import CustomerOrder, OrderEvent


@admin.register(CustomerOrder)
class CustomerOrderAdmin(admin.ModelAdmin):
    list_display = ("reference", "customer", "status", "total_amount", "created_at")
    list_filter = ("status",)
    search_fields = ("reference", "customer__username")


@admin.register(OrderEvent)
class OrderEventAdmin(admin.ModelAdmin):
    list_display = ("order", "event_type", "created_by", "created_at")
    list_filter = ("event_type",)
    search_fields = ("order__reference",)

Pourquoi ? Parce que c'est ici qu'on voit l'un des grands atouts de Django : tu obtiens immédiatement une interface interne exploitable, même avant d'avoir développé un vrai back-office sur mesure.

29. Vérification guidée​

Lancer le projet​

python manage.py createsuperuser
python manage.py runserver

Vérifier l'admin​

Ouvrir :

  • http://127.0.0.1:8000/admin/

Créer :

  • un utilisateur client
  • une commande associée à ce client
  • éventuellement un utilisateur staff pour les opérations internes

Vérifier l'API back-office​

Un utilisateur staff doit pouvoir lister les commandes :

curl -u staffuser:password http://127.0.0.1:8000/api/backoffice/orders/

Marquer une commande comme payée :

curl -u staffuser:password -X POST \
  http://127.0.0.1:8000/api/backoffice/orders/1/mark_paid/

Puis l'expédier :

curl -u staffuser:password -X POST \
  http://127.0.0.1:8000/api/backoffice/orders/1/ship/

Vérifier qu'un non-staff est bloqué​

La requête de listing ou d'action exécutée avec un utilisateur non staff doit renvoyer 403 Forbidden.

Ce que tu dois observer​

  • l'admin permet une exploitation rapide des données
  • l'API back-office permet des actions métier ciblées
  • seuls les comptes internes peuvent utiliser cette API
  • les événements internes gardent une trace de ce qui a été fait

30. Ce que cet exemple t'apprend vraiment​

Cet exemple montre concrètement comment Django et DRF se complètent dans ce use case :

  • l'admin Django donne un poste de pilotage immédiat
  • le modèle structure les commandes et les événements internes
  • le serializer façonne une réponse exploitable par un back-office
  • la permission staff-only protège les opérations internes
  • les actions DRF matérialisent les gestes métier des équipes

Autrement dit, on ne parle plus seulement d'admin Django comme d'un bonus : on voit comment il s'articule avec une API interne plus ciblée pour faire tourner un produit réel.

success

Si tu comprends bien cet exemple, tu commences à voir que l'exploitation interne n'est pas un détail annexe du produit : c'est une partie essentielle de sa qualité et de sa maintenabilité.