Backend produit autour d'un système IA 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
• Application métier / SaaS / outil interne avec Django DRF
• API avec utilisateurs, rôles et permissions avec Django DRF
• Produit avec back-office et admin Django
• Application centrée base de données avec Django DRF
• API B2B / API interne avec Django DRF
• Parcours de lecture
• FAQ, erreurs fréquentes et conseils pratiques

info

Ce tutoriel explique comment penser Django DRF non pas comme le moteur du modèle IA lui-même, mais comme la couche produit qui encadre un système intelligent. L'objectif est de comprendre comment gérer utilisateurs, jobs, fichiers, résultats, permissions, traçabilité, exploitation, intégrations et durabilité autour d'une brique IA sans réduire le produit à un simple endpoint d'inférence.

1. Introduction

Quand on entend “produit IA”, beaucoup de personnes imaginent immédiatement le modèle lui-même.

Elles pensent à :

• l'inférence
• le modèle
• le GPU
• l'algorithme
• le score
• la prédiction

Mais dans un vrai produit, le modèle n'est qu'une partie du système. Très souvent, il faut aussi gérer :

• des utilisateurs
• des projets
• des fichiers envoyés
• des jobs ou traitements
• des résultats
• des permissions
• des historiques
• des validations humaines
• des statuts d'exécution
• de l'administration et de l'exploitation

Autrement dit :

un produit IA sérieux a besoin d'une vraie couche backend produit autour du modèle.

Et c'est précisément là que Django DRF peut être très intéressant.

2. Le problème concret à résoudre

Imaginons plusieurs types de produits IA :

• un outil d'analyse d'images
• une plateforme de transcription ou de résumé
• un système d'aide à la décision
• un produit de détection d'anomalies
• un moteur d'analyse documentaire
• une application de scoring ou de classification

Dans chacun de ces cas, le modèle ne vit pas dans le vide. Il faut souvent :

• recevoir une demande
• associer cette demande à un utilisateur ou un projet
• stocker des fichiers ou des données d'entrée
• lancer un traitement
• suivre son état
• récupérer un résultat
• versionner ou historiser ce résultat
• restreindre qui peut le voir
• permettre une supervision ou une correction humaine

Le vrai problème n'est donc pas seulement :

“comment appeler un modèle ?”

Le vrai problème devient :

“comment transformer une capacité IA en produit exploitable, sûr et maintenable ?”

3. Ce qu'est réellement un backend produit autour d'une IA

Un backend produit autour d'une IA est la couche qui organise tout ce qui entoure le modèle.

Cela peut inclure :

• la gestion des utilisateurs
• la gestion des projets ou espaces de travail
• la réception des entrées
• la gestion des jobs de traitement
• le stockage des artefacts
• la gestion des résultats
• la traçabilité
• la sécurité
• l'administration interne
• l'exposition d'une API stable au reste du produit

Le modèle IA est important, mais il n'est pas suffisant pour faire un vrai produit.

4. Pourquoi Django DRF est pertinent ici

Django DRF est particulièrement intéressant dans ce use case pour une raison très simple :

il excelle dans tout ce qu'il y a autour du modèle.

4.1 Il structure les objets métier autour de l'IA

Dans un produit IA, on retrouve souvent des objets comme :

• utilisateur
• organisation
• projet
• lot de fichiers
• demande d'inférence
• job
• résultat
• annotation
• revue humaine
• modèle déployé
• version de pipeline

Ce sont des objets très naturels pour Django.

4.2 Il est très bon pour les workflows

Les produits IA ont souvent des états comme :

• reçu
• en attente
• en cours
• terminé
• échoué
• validé
• rejeté
• archivé

Cette logique de workflow est très compatible avec une approche Django DRF bien structurée.

4.3 Il gère bien permissions et exploitation

Un résultat IA n'est pas toujours visible par tout le monde. Il faut parfois gérer :

• confidentialité
• accès par client ou projet
• visibilité selon le rôle
• supervision interne
• audit des actions

4.4 Il permet de découpler le modèle du produit

C'est un point très important. Le backend Django DRF peut servir de couche stable même si :

• le modèle change
• le fournisseur d'inférence change
• la logique de traitement évolue
• une file de tâches est ajoutée

Autrement dit, le produit ne dépend pas entièrement de la forme actuelle du modèle.

5. Quand utiliser Django DRF pour ce cas

Django DRF est un très bon choix si :

• l'IA n'est qu'une partie d'un produit plus large
• tu as besoin d'utilisateurs, projets, permissions, historique, supervision
• tu veux structurer proprement les entrées, jobs et résultats
• tu veux une API stable autour de la brique IA
• tu veux un socle backend durable et administrable

Exemples typiques :

• plateforme d'analyse d'images pour des clients
• produit de traitement documentaire avec suivi des jobs
• outil d'inspection industrielle avec résultats et historique
• app d'aide à la décision avec revue humaine et audit

6. Quand Django DRF n'est pas forcément le cœur du besoin

Il faut aussi être lucide.

Si ton besoin se résume vraiment à :

• envoyer une entrée
• recevoir immédiatement une sortie
• sans utilisateurs, sans historique, sans logique produit, sans supervision

alors une solution beaucoup plus minimale peut suffire.

Mais dès que tu veux construire un produit IA réel, Django DRF redevient vite très pertinent.

7. Pré-requis

Pour tirer le meilleur 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

Et plus particulièrement :

• Application métier / SaaS / outil interne avec Django DRF
• Produit avec back-office et admin Django
• Application centrée base de données avec Django DRF
• API B2B / API interne avec Django DRF

8. Vocabulaire indispensable

Inférence

Exécution du modèle sur une entrée pour produire une sortie.

Job

Un traitement lancé, souvent asynchrone, que le système suit dans le temps.

Artefact

Élément produit ou manipulé par le système, par exemple un fichier d'entrée, un rapport, un résultat exporté ou une image annotée.

Pipeline

Chaîne de traitement autour du modèle : préparation, inférence, post-traitement, stockage, etc.

Revue humaine

Étape où un humain vérifie, corrige ou valide un résultat produit par le système.

Traçabilité

Capacité à savoir quel modèle, quelle version, quel utilisateur, quelle entrée et quel moment ont conduit à un résultat donné.

Produit IA

Produit dont une capacité IA fait partie de la proposition de valeur, mais qui repose aussi sur un vrai système logiciel autour.

9. Vision d'ensemble

Dans ce use case, le modèle est une brique spécialisée. Le backend Django DRF sert à construire le cadre produit autour de cette brique.

On peut résumer cela ainsi :

1. le client soumet une entrée
2. le backend crée un contexte produit autour de cette demande
3. le système lance ou orchestre le traitement
4. le résultat est stocké, relié, historisé et sécurisé
5. les utilisateurs ou équipes internes peuvent le consulter, le valider, le comparer ou l'exploiter

L'idée essentielle est donc :

Django DRF est souvent le bon endroit pour construire la colonne vertébrale produit d'un système IA.

10. Architecture type

Voici une architecture mentale simple.

graph TD
    A[Frontend / client] --> B[API Django DRF]
    B --> C[Authentification et permissions]
    B --> D[Logique produit]
    D --> E[Base de données]
    D --> F[Stockage de fichiers / artefacts]
    D --> G[Service d'inférence / worker / pipeline]
    G --> H[Résultats et sorties]
    I[Admin Django / back-office] --> B

10.1 Le frontend ou client

Il envoie des fichiers, paramètres ou demandes de traitement.

10.2 L'API Django DRF

Elle structure l'accès au système et relie toutes les briques du produit.

10.3 La logique produit

C'est elle qui décide :

• comment un job est créé
• qui peut le voir
• comment son statut évolue
• comment le résultat est stocké
• comment il est exposé ensuite

10.4 Le service d'inférence

Il peut être local, distant, synchrone, asynchrone ou opéré par un autre service.

10.5 L'admin ou back-office

Il sert à superviser, auditer, corriger et exploiter le produit.

11. Ce qui rend ce use case spécifique

Ce use case est particulier parce qu'il combine plusieurs mondes :

• un backend produit classique
• une logique data-centric
• un besoin de workflows et permissions
• une brique technique IA souvent plus changeante ou coûteuse

Le danger le plus fréquent est de construire tout le produit comme s'il n'était qu'un simple wrapper autour du modèle.

C'est rarement suffisant.

12. Construction pas à pas

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

Étape 1 — Identifier les objets produit autour du modèle

Ne pars pas d'abord du modèle lui-même. Pars du produit.

Exemples d'objets :

• utilisateur
• projet
• fichier source
• job d'analyse
• résultat
• rapport
• revue humaine
• historique d'exécution

Étape 2 — Clarifier le cycle de vie d'une demande

Que se passe-t-il entre l'entrée et le résultat ?

Exemple :

• soumission
• en file d'attente
• traitement
• succès ou échec
• publication du résultat
• éventuelle validation humaine
• archivage

Étape 3 — Décider ce qui relève de l'API, du worker et du modèle

Tout ne doit pas être mélangé.

Questions utiles :

• qu'est-ce qui doit vivre dans Django DRF ?
• qu'est-ce qui relève d'un job asynchrone ?
• qu'est-ce qui relève du service d'inférence ?

Étape 4 — Penser les permissions tôt

Qui peut :

• soumettre une demande ?
• voir les résultats ?
• relancer un traitement ?
• supprimer un artefact ?
• valider ou corriger un résultat ?

Étape 5 — Penser la traçabilité très tôt

Dans un produit IA, il faut souvent pouvoir répondre à des questions comme :

• quel utilisateur a lancé ce job ?
• quel fichier a été utilisé ?
• quel modèle ou pipeline a produit ce résultat ?
• à quelle date ?
• avec quel statut ?

Étape 6 — Penser l'expérience d'exploitation

Quand un traitement échoue, quelqu'un doit comprendre :

• où cela a cassé
• pourquoi
• comment le relancer
• comment isoler les cas problématiques

Étape 7 — Penser les besoins de stockage

Les produits IA manipulent souvent :

• fichiers source
• fichiers intermédiaires
• sorties annotées
• rapports
• logs
• exports

Il faut donc penser ces éléments comme des objets du produit, pas comme des détails annexes.

Étape 8 — Penser l'évolution du modèle sans casser le produit

Le modèle peut changer. Le pipeline peut changer. Le service d'inférence peut changer.

Le backend produit doit rester suffisamment stable pour absorber ces changements.

Étape 9 — Prévoir la revue humaine si elle existe

Dans beaucoup de produits IA sérieux, le résultat n'est pas forcément “vérité absolue”. Il peut être :

• vérifié
• corrigé
• validé
• enrichi

Étape 10 — Prévoir l'intégration à d'autres systèmes

Un produit IA mature doit parfois fournir ses résultats à :

• un ERP
• un back-office métier
• un autre service
• une API client B2B

13. Exemple concret mental

Prenons un exemple simple : une plateforme d'analyse d'images d'inspection.

Ressources principales

• utilisateur
• projet d'inspection
• image ou lot d'images
• job d'analyse
• résultat de détection
• rapport
• historique d'exécution
• validation humaine

Logique produit

• un utilisateur dépose une image
• le backend crée un job
• le job appelle le service d'inférence
• un résultat est produit et stocké
• un opérateur peut le consulter
• un rôle interne peut le valider ou corriger
• le rapport final peut être exporté

Ici, le modèle IA n'est qu'un élément dans une chaîne de valeur plus large.

14. Ce que le backend produit doit porter

Le backend doit porter au moins :

• la cohérence des objets
• le cycle de vie des traitements
• les permissions
• le lien entre les entrées et les résultats
• la traçabilité
• les besoins internes d'exploitation

Sinon, le produit risque de ressembler à une simple démo technique, pas à un vrai système.

15. Erreurs fréquentes

Erreur 1 — Réduire le produit à un endpoint d'inférence

C'est la plus classique. Le produit réel est presque toujours plus riche.

Erreur 2 — Ne pas modéliser proprement les jobs et résultats

Sans cela, l'exploitation devient floue.

Erreur 3 — Négliger la traçabilité

Dans un produit IA, oublier quelle version ou quel pipeline a produit quoi peut devenir très problématique.

Erreur 4 — Oublier la validation ou revue humaine

Beaucoup de produits IA ont besoin d'une couche de contrôle humain.

Erreur 5 — Coupler trop fortement le produit à une implémentation précise du modèle

Le backend devient alors fragile face aux évolutions.

Erreur 6 — Négliger les besoins internes

Support, audit, relance, supervision, correction : tout cela doit être pensé.

16. Bonnes pratiques

16.1 Penser le produit avant le modèle

Le modèle sert le produit, pas l'inverse.

16.2 Modéliser clairement les entrées, jobs et résultats

Cela rend le système beaucoup plus lisible.

16.3 Prévoir permissions et visibilité des résultats

Toutes les sorties ne doivent pas être visibles par tout le monde.

16.4 Prévoir la traçabilité comme une exigence produit

Surtout si les résultats ont un impact métier réel.

16.5 Penser l'admin et le back-office tôt

Les équipes internes auront presque toujours besoin d'outils pour comprendre et gérer les traitements.

16.6 Garder le backend stable malgré l'évolution du modèle

Le backend produit doit absorber une partie des changements techniques.

17. Variantes et évolutions possibles

Variante 1 — Produit IA simple avec exécution quasi immédiate

Peu de rôles, peu de supervision, mais déjà un vrai suivi de résultats.

Variante 2 — Produit IA avec jobs asynchrones

Files de traitement, statuts, relance et suivi plus riches.

Variante 3 — Produit IA avec revue humaine

Les résultats sont complétés ou validés par des humains.

Variante 4 — Produit IA multi-client ou B2B

Permissions, isolation et exposition d'API deviennent plus complexes.

Variante 5 — Produit IA mature

Historique fort, audit, comparaisons de versions, administration riche, intégrations externes plus nombreuses.

18. Comment savoir si tu vas dans la bonne direction

Tu avances bien si :

• tu peux expliquer clairement les objets produit autour du modèle
• tu sais ce qu'est un job, un résultat, un artefact et un flux d'exécution
• les permissions sont claires
• la traçabilité est pensée
• le produit reste compréhensible même si le modèle évolue
• les équipes internes peuvent superviser le système sans bricolage excessif

19. Résumé final

Django DRF est un excellent choix quand on veut construire la couche produit autour d'un système IA.

Il est particulièrement fort pour organiser :

• les utilisateurs
• les projets
• les fichiers
• les jobs
• les résultats
• les permissions
• la traçabilité
• l'exploitation interne
• l'exposition API stable du produit

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

dans un produit IA sérieux, le modèle est une brique de valeur, mais le backend Django DRF peut devenir la colonne vertébrale qui transforme cette brique en système exploitable.

20. Pour aller plus loin

Le plan principal des grands use cases est désormais complet. La suite logique du wiki peut être une phase de raffinage avec :

• glossaire dédié
• notes de comparaison
• renforcement pédagogique transversal
• cas pratiques supplémentaires

Relire aussi :

• Application métier / SaaS / outil interne avec Django DRF
• Produit avec back-office et admin Django
• Application centrée base de données avec Django DRF
• API B2B / API interne avec Django DRF

21. Mini-projet guidé avec code

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

un backend produit où des utilisateurs créent des projets, lancent des jobs d'inférence et consultent des résultats

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

• les utilisateurs
• les projets
• les jobs
• les statuts d'exécution
• les résultats exposés au produit

Autrement dit : le modèle IA n'est pas le produit entier ; le backend orchestre l'usage réel de ce modèle.

22. Structure du mini-projet

aiplatform/
├── manage.py
├── aiplatform/
│   ├── settings.py
│   ├── urls.py
│   └── ...
└── inference/
    ├── admin.py
    ├── models.py
    ├── serializers.py
    ├── permissions.py
    ├── services.py
    ├── views.py
    └── urls.py

Repères utiles avant de lire le code :

• models.py structure le produit autour des projets, des jobs et des prédictions.
• serializers.py expose le statut du job et les résultats persistés.
• permissions.py protège le périmètre du projet.
• services.py isole l'orchestration technique du lancement d'inférence.
• views.py sépare la gestion des projets de la gestion et du lancement des jobs.
• urls.py expose les ressources /api/projects/ et /api/jobs/.
• admin.py sert de poste d'observation interne pour les équipes produit et ops.

23. 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 aiplatform .
python manage.py startapp inference

Étape 2 — Déclarer DRF et l'application

Dans aiplatform/settings.py :

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

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 projets, les jobs et les prédictions

Dans inference/models.py :

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


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

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


class InferenceJob(models.Model):
    STATUS_CHOICES = [
        ("created", "Created"),
        ("queued", "Queued"),
        ("running", "Running"),
        ("succeeded", "Succeeded"),
        ("failed", "Failed"),
    ]

    project = models.ForeignKey(
        AIProject,
        on_delete=models.CASCADE,
        related_name="jobs",
    )
    requested_by = models.ForeignKey(
        settings.AUTH_USER_MODEL,
        on_delete=models.CASCADE,
        related_name="inference_jobs",
    )
    input_text = models.TextField()
    model_version = models.CharField(max_length=80, default="v1")
    status = models.CharField(max_length=20, choices=STATUS_CHOICES, default="created")
    created_at = models.DateTimeField(auto_now_add=True)
    finished_at = models.DateTimeField(null=True, blank=True)

    def __str__(self) -> str:
        return f"Job {self.id} - {self.status}"


class Prediction(models.Model):
    job = models.ForeignKey(
        InferenceJob,
        on_delete=models.CASCADE,
        related_name="predictions",
    )
    label = models.CharField(max_length=120)
    score = models.FloatField()
    explanation = models.TextField(blank=True)

    def __str__(self) -> str:
        return f"{self.label} ({self.score})"

Puis lancer :

python manage.py makemigrations
python manage.py migrate

Pourquoi ? Parce qu'un produit IA sérieux ne manipule pas seulement des entrées et sorties : il manipule aussi des projets, des jobs, des statuts et des résultats persistés.

Étape 4 — Créer les serializers

Dans inference/serializers.py :

from rest_framework import serializers

from .models import AIProject, InferenceJob, Prediction


class PredictionSerializer(serializers.ModelSerializer):
    class Meta:
        model = Prediction
        fields = ["id", "label", "score", "explanation"]
        read_only_fields = ["id"]


class AIProjectSerializer(serializers.ModelSerializer):
    owner = serializers.StringRelatedField(read_only=True)

    class Meta:
        model = AIProject
        fields = ["id", "owner", "name", "description", "created_at"]
        read_only_fields = ["id", "owner", "created_at"]


class InferenceJobSerializer(serializers.ModelSerializer):
    requested_by = serializers.StringRelatedField(read_only=True)
    predictions = PredictionSerializer(many=True, read_only=True)

    class Meta:
        model = InferenceJob
        fields = [
            "id",
            "project",
            "requested_by",
            "input_text",
            "model_version",
            "status",
            "created_at",
            "finished_at",
            "predictions",
        ]
        read_only_fields = [
            "id",
            "requested_by",
            "status",
            "created_at",
            "finished_at",
            "predictions",
        ]

Pourquoi ? Parce que le frontend produit a besoin d'une vue claire du job :

• qui l'a lancé
• dans quel projet il vit
• où il en est
• quels résultats il a produits

Étape 5 — Ajouter une permission liée au projet

Dans inference/permissions.py :

from rest_framework.permissions import BasePermission


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

    def has_object_permission(self, request, view, obj):
        if request.user.is_staff:
            return True

        project = getattr(obj, "project", obj)
        return project.owner == request.user

Pourquoi ? Parce qu'un job d'inférence appartient à un projet, et ce projet appartient à un utilisateur ou à une équipe. Le backend doit porter cette relation de confiance.

Étape 6 — Séparer l'orchestration technique dans un service

Dans inference/services.py :

def enqueue_inference(job):
    # Dans un vrai produit, on enverrait ici le job à Celery,
    # à une file de tâches ou à un service d'inférence externe.
    job.status = "queued"
    job.save(update_fields=["status"])
    return job

Pourquoi ? Parce que le code qui orchestre l'appel au modèle ne doit pas forcément vivre directement dans la vue. C'est une première séparation utile entre API produit et exécution IA.

Étape 7 — Écrire les viewsets DRF

Dans inference/views.py :

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

from .models import AIProject, InferenceJob
from .permissions import IsProjectOwnerOrStaff
from .serializers import AIProjectSerializer, InferenceJobSerializer
from .services import enqueue_inference


class AIProjectViewSet(viewsets.ModelViewSet):
    serializer_class = AIProjectSerializer
    permission_classes = [IsAuthenticated, IsProjectOwnerOrStaff]

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

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


class InferenceJobViewSet(viewsets.ModelViewSet):
    serializer_class = InferenceJobSerializer
    permission_classes = [IsAuthenticated, IsProjectOwnerOrStaff]

    def get_queryset(self):
        queryset = InferenceJob.objects.select_related(
            "project", "requested_by"
        ).prefetch_related("predictions").order_by("-created_at")
        if self.request.user.is_staff:
            return queryset
        return queryset.filter(project__owner=self.request.user)

    def perform_create(self, serializer):
        project = serializer.validated_data["project"]
        if not self.request.user.is_staff and project.owner != self.request.user:
            raise PermissionDenied("Tu ne peux pas créer un job sur le projet d'un autre utilisateur.")
        serializer.save(requested_by=self.request.user)

    @action(detail=True, methods=["post"])
    def launch(self, request, pk=None):
        job = self.get_object()
        if job.status != "created":
            return Response(
                {"detail": "Seul un job créé peut être lancé."},
                status=status.HTTP_400_BAD_REQUEST,
            )

        enqueue_inference(job)
        return Response(self.get_serializer(job).data)

Pourquoi ce code est important ? Parce qu'il montre très concrètement comment DRF structure un produit IA :

• un endpoint pour les projets
• un endpoint pour les jobs
• une action dédiée pour lancer le traitement
• une séparation entre l'API et la logique d'orchestration

Étape 8 — Brancher les routes

Dans inference/urls.py :

from rest_framework.routers import DefaultRouter

from .views import AIProjectViewSet, InferenceJobViewSet

router = DefaultRouter()
router.register("projects", AIProjectViewSet, basename="ai-project")
router.register("jobs", InferenceJobViewSet, basename="inference-job")

urlpatterns = router.urls

Dans aiplatform/urls.py :

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

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

Étape 9 — Ajouter l'admin Django

Dans inference/admin.py :

from django.contrib import admin

from .models import AIProject, InferenceJob, Prediction

admin.site.register(AIProject)
admin.site.register(InferenceJob)
admin.site.register(Prediction)

Pourquoi ? Parce qu'un produit IA a souvent besoin d'un poste d'observation interne pour voir les jobs, corriger des métadonnées ou inspecter des résultats.

24. Vérification guidée

Lancer le serveur

python manage.py createsuperuser
python manage.py runserver

Créer un projet

curl -u username:password -X POST http://127.0.0.1:8000/api/projects/ \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Projet démo IA",
    "description": "Projet de test pour les jobs d\'inférence"
  }'

Créer un job d'inférence

curl -u username:password -X POST http://127.0.0.1:8000/api/jobs/ \
  -H "Content-Type: application/json" \
  -d '{
    "project": 1,
    "input_text": "Analyse cette entrée de démonstration",
    "model_version": "v1"
  }'

Lancer le job

curl -u username:password -X POST http://127.0.0.1:8000/api/jobs/1/launch/

Ce que tu dois observer

• le projet appartient à un utilisateur précis
• le job est rattaché à ce projet
• le statut passe de created à queued
• le backend garde la trace du demandeur et du modèle utilisé
• les résultats pourront être rattachés au job au lieu d'être renvoyés de manière volatile

25. Ce que cet exemple t'apprend vraiment

Cet exemple montre comment DRF est utilisé concrètement autour d'un système IA :

• le backend produit organise les projets et les usages
• les jobs rendent visible le cycle de vie d'une exécution
• les résultats persistés rendent le système exploitable au-delà d'un simple appel instantané
• les permissions protègent le périmètre utilisateur
• la couche service prépare l'intégration avec un vrai moteur d'inférence

Autrement dit, on ne parle plus ici d'un simple endpoint “/predict” : on voit comment un produit IA commence à prendre une forme exploitable, traçable et maintenable.

success

Si tu comprends bien ce mini-projet, tu commences à voir qu'un système IA utile en production n'est pas juste un modèle qui répond, mais un produit qui orchestre utilisateurs, jobs, résultats et exploitation interne.