Aller au contenu principal

API avec utilisateurs, rôles et permissions avec Django DRF

Repères utiles :

info

Ce tutoriel explique comment penser une API où tous les utilisateurs n'ont pas les mêmes droits. L'objectif est de comprendre quand Django DRF est pertinent pour ce besoin, comment structurer mentalement les rôles et permissions, quelles erreurs éviter, et comment construire une base saine avant même d'entrer dans les détails de code.

1. Introduction​

Dès qu'une application a plusieurs types d'utilisateurs, une question centrale apparaît :

qui a le droit de voir, créer, modifier ou supprimer quoi ?

Tant que l'on a une application très simple, cette question peut sembler secondaire. Mais en réalité, c'est souvent l'une des questions les plus structurantes d'un backend.

Pourquoi ? Parce que si la gestion des accès est floue, l'application devient vite :

  • dangereuse
  • incohérente
  • difficile à faire évoluer
  • pénible à maintenir

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

  • ce qu'on veut vraiment dire par utilisateurs, rôles et permissions
  • pourquoi Django DRF est un bon choix pour ce type de besoin
  • comment penser une API sécurisée et lisible
  • comment éviter les erreurs de conception les plus fréquentes

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

Imaginons une application avec plusieurs profils :

  • un utilisateur standard
  • un manager
  • un administrateur
  • éventuellement un opérateur interne ou un support

Très vite, ces profils n'ont pas les mêmes droits.

Exemples classiques :

  • un utilisateur peut voir uniquement ses propres données
  • un manager peut voir les objets de son équipe
  • un admin peut gérer plus largement le système
  • un support peut lire certaines données sans tout modifier

Le vrai problème n'est donc pas seulement de “connecter des gens”. Le vrai problème est de contrôler finement l'accès aux ressources.

3. Pourquoi ce use case est si fréquent​

Ce use case revient partout.

On le retrouve dans :

  • les SaaS
  • les outils internes
  • les plateformes B2B
  • les apps de gestion
  • les systèmes d'approbation
  • les applications RH
  • les plateformes d'inspection ou de reporting
  • les dashboards d'entreprise

En pratique, dès que tu as plusieurs acteurs avec plusieurs niveaux de responsabilité, tu es déjà dans ce use case.

4. Pourquoi Django DRF est pertinent ici​

Django DRF est particulièrement fort dans ce type de projet, car il repose sur un socle déjà très utile.

4.1 Django a déjà une vraie base utilisateur​

Django fournit déjà des briques solides pour :

  • les utilisateurs
  • les mots de passe
  • les groupes
  • les permissions
  • les sessions

Cela ne résout pas tout à ta place, mais te donne un terrain de départ sérieux.

4.2 DRF ajoute la couche API nécessaire​

DRF rend plus naturel le fait de gérer dans une API :

  • l'authentification
  • les permissions
  • les accès par vue
  • les accès par ressource
  • les réponses cohérentes lorsqu'un accès est refusé

4.3 Le couple Django + DRF aide à garder les responsabilités claires​

Avec une bonne discipline, tu peux structurer :

  • qui est l'utilisateur
  • quel est son rôle
  • ce qu'il peut faire
  • sur quelles ressources
  • avec quelles limites

4.4 Ce use case demande de la durabilité​

La gestion des rôles et permissions vieillit rarement bien si elle est bricolée. Django DRF aide justement à installer une base plus stable, plus explicite et plus maintenable.

5. Quand utiliser Django DRF pour ce cas​

Ce choix est particulièrement bon si ton application a :

  • plusieurs profils utilisateur
  • plusieurs niveaux de droits
  • des ressources métier sensibles
  • des données qui ne doivent pas être visibles par tout le monde
  • des actions réservées à certains rôles
  • un besoin de croissance maîtrisée de la politique d'accès

Exemples typiques :

  • une plateforme où un employé, un manager et un admin n'ont pas la même vue
  • une app où chaque utilisateur ne voit que ses objets
  • un système où certains rôles valident, d'autres créent, d'autres supervisent

6. Quand Django DRF n'est pas forcément nécessaire pour ce cas​

Si ton besoin est ultra simple, Django DRF peut être plus structuré que nécessaire.

Exemples où il faut réfléchir avant de le choisir :

  • une mini-application sans vraie notion de rôles
  • un projet où tout le monde a exactement les mêmes droits
  • un backend très petit et temporaire
  • une application qui ne possède quasiment pas de logique de sécurité autre que “connecté ou non connecté”

Mais attention : beaucoup de projets pensent au début qu'ils n'auront que deux cas simples, puis découvrent très vite qu'il faut gérer des exceptions, des droits d'équipe, des accès partiels, des rôles internes, etc.

7. Pré-requis​

Pour bien comprendre ce tutoriel, il est utile d'avoir déjà en tête :

  • ce qu'est un backend
  • ce qu'est une API
  • la différence entre frontend et backend
  • quelques bases sur Django et DRF

Les notes de fondation à relire si nécessaire sont :

8. Vocabulaire indispensable​

Utilisateur​

Une identité connue du système.

Authentification​

Le mécanisme qui permet de répondre à la question :

qui est cette personne ?

Autorisation​

La logique qui répond à la question :

cette personne a-t-elle le droit de faire cette action ?

Rôle​

Une manière simple de regrouper certains droits ou responsabilités. Exemples : member, manager, admin, support.

Permission​

Une règle plus précise qui détermine si une action est autorisée dans un contexte donné.

Ressource​

Un objet métier exposé via l'API. Exemples : projet, tâche, dossier, rapport, commentaire.

Permission globale​

Une permission qui s'applique à une vue ou à une action de manière générale. Exemple : “il faut être authentifié”.

Permission objet​

Une permission qui dépend de l'objet concerné. Exemple : “cet utilisateur peut modifier seulement son propre projet”.

9. La distinction la plus importante : auth n'est pas permission​

Beaucoup de débutants mélangent ces deux choses.

Il faut les séparer clairement.

L'authentification répond à :​

  • qui est connecté ?
  • cette requête vient-elle bien d'un utilisateur reconnu ?

Les permissions répondent à :​

  • cette personne peut-elle lire ?
  • peut-elle créer ?
  • peut-elle modifier ?
  • peut-elle supprimer ?
  • peut-elle agir sur cet objet précis ?
attention

Une application peut avoir une bonne authentification et de très mauvaises permissions. Être capable d'identifier un utilisateur ne suffit pas à sécuriser une API.

10. Vision d'ensemble​

Dans ce use case, le backend doit faire beaucoup plus que “renvoyer des données”. Il doit aussi servir de gardien d'accès.

Le flux mental est souvent le suivant :

  1. un client appelle l'API
  2. le backend identifie l'utilisateur
  3. il détermine son rôle ou son contexte d'accès
  4. il vérifie l'action demandée
  5. il vérifie si cette action est permise sur cette ressource
  6. il exécute ou refuse
  7. il renvoie une réponse claire

L'idée essentielle est donc :

une API avec rôles et permissions est avant tout un système de contrôle d'accès cohérent, pas seulement une collection d'endpoints.

11. Architecture type​

Voici une architecture mentale simple pour ce use case.

graph TD
    A[Frontend web ou mobile] --> B[API Django DRF]
    B --> C[Authentification]
    B --> D[Permissions]
    B --> E[Logique métier]
    E --> F[Base de données]
    B --> G[Admin Django / outils internes]

11.1 Le frontend​

Il envoie des demandes d'accès et d'action. Mais il ne doit pas être l'arbitre final des droits.

11.2 L'API Django DRF​

Elle reçoit les requêtes et orchestre l'ensemble.

11.3 L'authentification​

Elle identifie l'utilisateur.

11.4 Les permissions​

Elles appliquent les règles de lecture et d'écriture.

11.5 La logique métier​

Elle contient des règles plus profondes que le simple accès. Exemple : même un manager autorisé ne peut pas clôturer un dossier si certaines conditions ne sont pas réunies.

11.6 L'admin et les outils internes​

Ils peuvent servir à superviser, corriger ou auditer les données.

12. Les grandes questions à trancher avant d'implémenter​

12.1 Qui sont les acteurs du système ?​

Exemples :

  • visiteur
  • utilisateur connecté
  • membre
  • manager
  • administrateur
  • support

12.2 Quels objets doivent être protégés ?​

Exemples :

  • projets
  • rapports
  • documents
  • utilisateurs
  • commentaires
  • tickets

12.3 Quelles actions sont sensibles ?​

Exemples :

  • lecture
  • création
  • mise à jour
  • suppression
  • validation
  • archivage
  • export
  • changement d'état

12.4 Les droits dépendent-ils du rôle, de l'objet, ou des deux ?​

C'est une question fondamentale. Parfois le rôle suffit. Parfois non.

Exemple :

  • un manager peut modifier certains objets
  • mais seulement ceux de son périmètre

Ici, le rôle seul ne suffit pas. Il faut aussi une logique objet.

13. Trois grands niveaux de complexité​

Niveau 1 — Connecté ou non connecté​

Le plus simple. Exemple :

  • tout utilisateur connecté peut utiliser la majorité de l'API
  • tout utilisateur non connecté est refusé

Niveau 2 — Rôles distincts​

Exemple :

  • admin
  • manager
  • member

Chaque rôle a des actions différentes.

Niveau 3 — Règles contextuelles et permissions objet​

Exemple :

  • un utilisateur peut modifier un projet seulement s'il en est propriétaire
  • un manager peut agir sur les objets de son équipe mais pas sur ceux d'une autre équipe
  • un support peut lire sans modifier

C'est souvent à ce niveau que les projets réels deviennent intéressants.

14. Construction pas à pas​

Voici une manière saine de construire ce type d'API.

Étape 1 — Clarifier les acteurs​

Commence par écrire noir sur blanc les profils du système.

Exemples :

  • utilisateur standard
  • manager
  • admin

L'erreur fréquente serait de garder cela flou trop longtemps.

Étape 2 — Clarifier les ressources sensibles​

Demande-toi quelles données ou actions méritent une protection explicite.

Exemples :

  • profil utilisateur
  • rapport interne
  • document confidentiel
  • projet d'équipe

Étape 3 — Écrire une matrice d'accès simple​

Avant même le code, il est souvent très utile d'écrire une grille du type :

  • qui peut voir ?
  • qui peut créer ?
  • qui peut modifier ?
  • qui peut supprimer ?
  • qui peut valider ?

Cette étape évite énormément de confusion plus tard.

Étape 4 — Distinguer permissions globales et permissions objet​

Cette distinction change tout.

Exemple :

  • permission globale : il faut être authentifié pour accéder à la vue
  • permission objet : tu peux modifier uniquement les objets qui t'appartiennent

Étape 5 — Décider comment représenter les rôles​

Il faut choisir une stratégie conceptuelle claire.

Par exemple :

  • rôle simple attaché au profil utilisateur
  • groupes logiques
  • combinaison rôle + contexte métier

L'important n'est pas seulement la technique. L'important est que la logique reste lisible pour l'équipe.

Étape 6 — Décider ce qui doit être visible dans l'API​

Tout ce qu'un objet contient n'a pas forcément vocation à être visible pour tous les rôles.

Il faut réfléchir à :

  • quels champs sont publics
  • quels champs sont privés
  • quels champs sont réservés à certains profils

Étape 7 — Faire vivre les règles dans le backend​

Ne te contente jamais de masquer des boutons côté frontend. Le backend doit réellement bloquer les actions non autorisées.

Étape 8 — Prévoir la montée en complexité​

Même si aujourd'hui tu n'as que trois rôles, demain tu pourras avoir :

  • des rôles temporaires
  • des permissions d'équipe
  • des accès en lecture seule
  • des statuts spéciaux
  • des auditeurs ou superviseurs

Il faut donc poser un modèle mental qui pourra évoluer.

15. Exemple mental concret​

Prenons une application de gestion de dossiers.

Acteurs​

  • membre
  • manager
  • admin

Ressource​

  • dossier

Règles possibles​

  • un membre voit ses propres dossiers
  • un membre ne modifie pas les dossiers validés
  • un manager voit les dossiers de son équipe
  • un manager peut approuver certains dossiers
  • un admin peut tout voir et superviser

Tu vois ici que la difficulté ne vient pas du fait de “faire une route”. La difficulté vient du fait de faire respecter les règles du produit.

16. Ce que le frontend ne doit jamais porter seul​

Le frontend peut :

  • masquer un bouton
  • adapter l'affichage
  • guider l'utilisateur

Mais il ne doit jamais être l'unique barrière de sécurité.

Le backend doit aussi contrôler :

  • l'accès à la route
  • l'accès à la ressource
  • l'autorisation de l'action
  • les transitions métier

Sinon, un utilisateur pourrait appeler directement l'API en contournant l'interface.

17. Erreurs fréquentes​

Erreur 1 — Confondre rôle et permission​

Un rôle est un regroupement pratique. Une permission est une règle plus précise. Les deux sont liés, mais pas identiques.

Erreur 2 — Gérer les droits uniquement côté frontend​

C'est insuffisant et dangereux.

Erreur 3 — Attendre la fin pour penser la sécurité​

Si tu ajoutes la logique d'accès trop tard, tu risques de devoir refactorer beaucoup.

Erreur 4 — Penser uniquement en rôles globaux​

Dans les vrais projets, les droits dépendent souvent aussi du contexte et de l'objet.

Erreur 5 — Faire une politique d'accès implicite​

Si l'équipe ne peut pas expliquer clairement qui peut faire quoi, la sécurité deviendra floue.

Erreur 6 — Exposer trop de données à des rôles qui n'en ont pas besoin​

Une API trop bavarde crée du risque et de la confusion.

18. Bonnes pratiques​

18.1 Écrire la politique d'accès en français avant de l'implémenter​

C'est une pratique très sous-estimée.

Par exemple :

  • un membre peut voir ses propres objets
  • un manager peut voir ceux de son équipe
  • un admin peut superviser l'ensemble

Si cette phrase n'est pas claire, le code sera probablement flou aussi.

18.2 Prévoir les permissions objet tôt​

Beaucoup de projets commencent avec des permissions trop globales puis découvrent qu'elles sont insuffisantes.

18.3 Rester cohérent d'une ressource à l'autre​

Si deux ressources suivent la même logique d'accès, la politique doit être cohérente.

18.4 Séparer identification, autorisation et logique métier​

Ces trois choses sont liées, mais ne doivent pas être mélangées au point de devenir illisibles.

18.5 Penser à l'audit et à l'exploitation​

Dans les projets réels, il est souvent utile de savoir :

  • qui a fait quoi
  • qui a modifié quoi
  • qui a validé quoi

19. Variantes et évolutions possibles​

Variante 1 — Système simple à trois rôles​

Un début raisonnable pour beaucoup de projets.

Variante 2 — Permissions par équipe ou organisation​

Très fréquent dans les SaaS B2B.

Variante 3 — Lecture et écriture dissociées​

Certains rôles peuvent lire sans modifier.

Variante 4 — Actions métier spéciales​

Exemples : approuver, rejeter, archiver, exporter.

Variante 5 — Multi-tenant plus avancé​

Les droits dépendent alors de l'organisation, de l'espace ou du compte client.

20. Comment savoir si ton design est bon​

Tu vas dans la bonne direction si :

  • tu sais expliquer clairement qui peut faire quoi
  • tu sais distinguer auth, rôle et permission
  • tu sais quels droits dépendent du rôle seul et lesquels dépendent de l'objet
  • tu peux justifier pourquoi certaines données sont visibles ou cachées
  • la logique d'accès ne vit pas uniquement dans le frontend

21. Résumé final​

Django DRF est un excellent choix pour construire une API avec utilisateurs, rôles et permissions lorsque ton application doit gérer des accès différenciés de manière sérieuse.

Sa force vient du fait qu'il permet de structurer :

  • l'identité de l'utilisateur
  • la logique d'accès
  • la protection des ressources
  • la cohérence globale de l'API

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

dans ce use case, le backend n'est pas seulement un fournisseur de données ; c'est un arbitre de confiance qui décide ce que chaque acteur a le droit de faire.

22. Pour aller plus loin​

Après ce tutoriel, la suite logique du wiki peut être :

Relire aussi :

23. Mini-projet guidé avec code​

Pour rendre ce use case vraiment concret, on va prendre un mini-exemple réaliste :

une API d'équipe où plusieurs utilisateurs travaillent dans un même espace, mais n'ont pas tous les mêmes droits

Le but du mini-projet est de permettre :

  • à un admin de gérer l'espace d'équipe
  • à un manager de publier des rapports
  • à un member de lire les rapports autorisés sans pouvoir créer n'importe quoi

C'est exactement le genre de situation où Django REST Framework ne sert pas seulement à exposer du JSON : il sert à faire respecter qui peut faire quoi.

24. Structure du mini-projet​

Arborescence minimale :

secureapi/
├── manage.py
├── secureapi/
│   ├── settings.py
│   ├── urls.py
│   └── ...
└── access/
    ├── admin.py
    ├── models.py
    ├── serializers.py
    ├── permissions.py
    ├── views.py
    └── urls.py

Repères utiles avant de lire le code :

  • settings.py active DRF avec une base d'authentification cohérente pour une API protégée.
  • models.py rend explicites l'équipe, l'appartenance à l'équipe et la ressource protégée.
  • serializers.py définit le contrat d'API pour les rapports.
  • permissions.py encode les règles qui combinent rôle, appartenance et objet visé.
  • views.py applique le bon périmètre de lecture et d'écriture pour chaque utilisateur.
  • urls.py expose le point d'entrée principal /api/reports/.
  • admin.py aide à préparer rapidement des scénarios de test réalistes.

25. 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 secureapi .
python manage.py startapp access

Pourquoi ? Parce qu'on veut un projet très simple où la vraie complexité n'est pas le nombre de fichiers, mais la gestion des accès.

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

Dans secureapi/settings.py :

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

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

Pourquoi ? Parce qu'ici une API anonyme n'aurait pas de sens : la première porte d'entrée, c'est déjà l'authentification.

Étape 3 — Modéliser l'équipe, les rôles et les rapports​

Dans access/models.py :

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


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

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


class TeamMembership(models.Model):
    ROLE_CHOICES = [
        ("admin", "Admin"),
        ("manager", "Manager"),
        ("member", "Member"),
    ]

    user = models.ForeignKey(
        settings.AUTH_USER_MODEL,
        on_delete=models.CASCADE,
        related_name="team_memberships",
    )
    team = models.ForeignKey(
        Team,
        on_delete=models.CASCADE,
        related_name="memberships",
    )
    role = models.CharField(max_length=20, choices=ROLE_CHOICES)

    class Meta:
        constraints = [
            models.UniqueConstraint(
                fields=["user", "team"],
                name="unique_membership_per_team",
            )
        ]

    def __str__(self) -> str:
        return f"{self.user} - {self.team} ({self.role})"


class Report(models.Model):
    team = models.ForeignKey(
        Team,
        on_delete=models.CASCADE,
        related_name="reports",
    )
    title = models.CharField(max_length=150)
    body = models.TextField()
    is_private = models.BooleanField(default=False)
    created_by = models.ForeignKey(
        settings.AUTH_USER_MODEL,
        on_delete=models.CASCADE,
        related_name="created_reports",
    )
    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'avant de coder des permissions, il faut rendre explicites les trois briques métier :

  • l'équipe
  • l'appartenance à l'équipe
  • la ressource protégée

Étape 4 — Créer les serializers DRF​

Dans access/serializers.py :

from rest_framework import serializers

from .models import Report, TeamMembership


class TeamMembershipSerializer(serializers.ModelSerializer):
    class Meta:
        model = TeamMembership
        fields = ["id", "team", "role"]
        read_only_fields = ["id"]


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

    class Meta:
        model = Report
        fields = [
            "id",
            "team",
            "title",
            "body",
            "is_private",
            "created_by",
            "created_at",
        ]
        read_only_fields = ["id", "created_by", "created_at"]

Pourquoi ? Parce que le serializer définit ce que l'API accepte et ce qu'elle renvoie. Il transforme la règle métier en contrat lisible pour le frontend et pour les intégrateurs.

Étape 5 — Écrire la permission personnalisée​

Dans access/permissions.py :

from rest_framework.permissions import BasePermission, SAFE_METHODS

from .models import TeamMembership


class IsTeamMemberAndCanManageReports(BasePermission):
    def _membership(self, user, team):
        return TeamMembership.objects.filter(user=user, team=team).first()

    def has_permission(self, request, view):
        if not request.user or not request.user.is_authenticated:
            return False

        if request.method in SAFE_METHODS:
            return True

        team_id = request.data.get("team")
        if not team_id:
            return False

        return TeamMembership.objects.filter(
            user=request.user,
            team_id=team_id,
            role__in=["admin", "manager"],
        ).exists()

    def has_object_permission(self, request, view, obj):
        membership = self._membership(request.user, obj.team)
        if not membership:
            return False

        if request.method in SAFE_METHODS:
            return True

        return membership.role == "admin" or obj.created_by == request.user

Pourquoi ce code est important ? Parce qu'il montre exactement ce qu'on attendait de ce chapitre :

  • un utilisateur authentifié n'est pas automatiquement autorisé partout
  • le rôle n'est pas une simple étiquette décorative
  • la décision dépend parfois du rôle, parfois de l'objet, parfois des deux

Étape 6 — Créer le viewset DRF​

Dans access/views.py :

from rest_framework import viewsets
from rest_framework.permissions import IsAuthenticated

from .models import Report
from .permissions import IsTeamMemberAndCanManageReports
from .serializers import ReportSerializer


class ReportViewSet(viewsets.ModelViewSet):
    serializer_class = ReportSerializer
    permission_classes = [IsAuthenticated, IsTeamMemberAndCanManageReports]

    def get_queryset(self):
        return (
            Report.objects.filter(team__memberships__user=self.request.user)
            .select_related("team", "created_by")
            .distinct()
            .order_by("-created_at")
        )

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

Pourquoi ? Parce que le viewset traduit maintenant le use case en comportement réel :

  • on ne voit que les rapports de ses équipes
  • on ne peut pas écrire si on n'a pas le bon rôle
  • l'auteur est fixé côté backend, pas laissé au frontend

Étape 7 — Brancher les routes​

Dans access/urls.py :

from rest_framework.routers import DefaultRouter

from .views import ReportViewSet

router = DefaultRouter()
router.register("reports", ReportViewSet, basename="report")

urlpatterns = router.urls

Dans secureapi/urls.py :

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

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

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

Dans access/admin.py :

from django.contrib import admin

from .models import Report, Team, TeamMembership

admin.site.register(Team)
admin.site.register(TeamMembership)
admin.site.register(Report)

Pourquoi ? Parce que l'admin Django permet ici de créer rapidement une équipe, d'ajouter des membres et de visualiser les rapports sans construire tout de suite un back-office spécifique.

26. Vérification guidée​

Préparer des utilisateurs de test​

Le plus simple est de :

  • créer un superuser
  • créer deux utilisateurs classiques dans l'admin
  • créer une équipe
  • donner le rôle manager à l'un et member à l'autre
python manage.py createsuperuser
python manage.py runserver

Tester en lecture​

Un membre d'équipe doit pouvoir lire les rapports de son équipe :

curl -u member:password http://127.0.0.1:8000/api/reports/

Tester en écriture avec un manager​

curl -u manager:password -X POST http://127.0.0.1:8000/api/reports/ \
  -H "Content-Type: application/json" \
  -d '{
    "team": 1,
    "title": "Rapport hebdomadaire",
    "body": "Tout est sous contrôle.",
    "is_private": false
  }'

Vérifier qu'un membre simple ne peut pas créer​

La même requête avec member:password doit renvoyer un refus (403 Forbidden).

Ce que tu dois observer​

  • un utilisateur authentifié sans appartenance d'équipe ne voit rien
  • un membre peut consulter mais ne peut pas forcément écrire
  • un manager peut créer
  • un admin garde les droits les plus larges
  • le backend reste l'arbitre central des accès

27. Ce que cet exemple t'apprend vraiment​

Cet exemple montre concrètement comment DRF est utilisé dans ce use case :

  • le modèle représente la structure sociale du système
  • le serializer définit le contrat d'API
  • la permission personnalisée encode les règles d'accès
  • le viewset applique ces règles à chaque endpoint
  • l'admin Django aide à exploiter et tester rapidement le système

Autrement dit, on ne parle plus seulement de rôles et permissions de manière abstraite : on voit comment ces idées deviennent du code backend vérifiable.

success

Si tu comprends bien ce mini-projet, tu franchis un cap important : tu ne vois plus l'autorisation comme une couche vague ou secondaire, mais comme une partie centrale de la conception d'une API fiable.