title: "Créez des applications IA qui ne stockent pas les données de vos utilisateurs : API LLM sans état et RGPD" description: "Ce que signifie l'inférence sans état, pourquoi c'est important pour la conformité RGPD, et comment construire une application de chat en production qui vous donne un contrôle total sur la conservation des données." date: 2026-04-06 slug: stateless-llm-api-gdpr keywords: ["stateless llm api", "gdpr compliant llm", "zero data retention ai", "stateless inference gdpr", "llm no data retention"] category: guides schema_types: ["TechArticle", "FAQPage"]

Créez des applications IA qui ne stockent pas les données de vos utilisateurs : API LLM sans état et RGPD

La plupart des API LLM sont avec état par défaut. Lorsque vous envoyez une requête à OpenAI, le prompt et la réponse sont conservés — généralement pendant 30 jours — pour la surveillance des abus, les analyses et la journalisation opérationnelle. Ces données conservées créent des obligations RGPD : calendriers de conservation, mécanismes d'effacement, accords au titre de l'article 28 et exposition aux audits.

L'inférence sans état inverse cette logique. L'API traite votre requête en mémoire, génère une réponse et supprime immédiatement tout. Aucun journal contenant votre contenu, aucune donnée d'entraînement, rien à effacer.

Ce guide explique comment fonctionne l'architecture LLM sans état, quand elle est pertinente pour la conformité RGPD, et comment construire une application de chat prête pour la production en l'utilisant. Tous les exemples utilisent l'API compatible OpenAI de JuiceFactory.

Obtenez votre clé API gratuite : juicefactory.ai/api-key — aucune carte bancaire requise.

Ce que signifie réellement l'inférence sans état

L'absence d'état dans une API LLM signifie que le fournisseur ne maintient aucun état de conversation entre les requêtes. Chaque requête est indépendante. L'API reçoit les messages que vous envoyez, les traite, renvoie une réponse et libère la mémoire. Rien ne persiste.

C'est différent de la façon dont vous pourriez construire une application de chat, où vous stockez l'historique des conversations dans votre base de données et l'envoyez avec chaque requête. L'état réside dans votre couche applicative — pas dans le service d'inférence. L'API ne connaît jamais les conversations précédentes, sauf si vous les incluez dans la requête courante.

La distinction fondamentale du point de vue de la conformité :

# Modèle avec état — le fournisseur conserve l'historique
# Votre prompt va sur leur serveur, est journalisé, stocké, conservé
response = openai.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "My patient ID is 12345..."}]
)
# Cet identifiant patient reste dans les logs d'OpenAI pendant 30 jours

# Modèle sans état — le fournisseur supprime tout
client = OpenAI(
    api_key="jf-...",
    base_url="https://api.juicefactory.ai/v1"
)
response = client.chat.completions.create(
    model="qwen3-vl",
    messages=[{"role": "user", "content": "My patient ID is 12345..."}]
)
# Requête traitée en mémoire, réponse renvoyée, données supprimées

Le code est presque identique. Les implications en matière de conformité sont radicalement différentes.

Pourquoi c'est important pour le RGPD

Le RGPD impose des exigences spécifiques sur la manière dont les données personnelles sont traitées. Pour les applications LLM, les plus pertinentes sont :

Article 5(1)(c) — Minimisation des données : Ne traiter que ce qui est nécessaire. Conserver des prompts pendant 30 jours alors que vous n'aviez besoin de la réponse que pendant 200 ms est difficile à justifier.

Article 5(1)(e) — Limitation de la conservation : Les données ne doivent pas être conservées plus longtemps que nécessaire pour leur finalité. Avec les API avec état, vous dépendez du calendrier de conservation du fournisseur, pas du vôtre.

Article 17 — Droit à l'effacement : Les utilisateurs peuvent demander la suppression de leurs données personnelles. Avec l'inférence sans état, il n'y a rien à supprimer — les données n'ont jamais été stockées. Avec les fournisseurs avec état, vous devez mettre en place un mécanisme pour coordonner les demandes d'effacement à travers leur infrastructure.

Article 28 — Accords de sous-traitance : Tout service traitant des données personnelles pour votre compte nécessite un accord de sous-traitance (DPA). Les fournisseurs sans état ont des DPA plus simples car le périmètre du traitement se limite à la requête immédiate.

La valeur en matière de conformité n'est pas que théorique. Dans une application de santé traitant des requêtes de patients, ou un outil juridique traitant des notes de dossiers, vous voulez pouvoir dire à votre DPO : « Le fournisseur d'inférence traite les données de manière transitoire et ne conserve rien. » C'est un discours clair. « Ils conservent nos prompts pendant 30 jours, voici notre DPA » est une conversation plus difficile.

Architecture : où réside l'état

flowchart LR
    subgraph Your Infrastructure
        A[User] --> B[Your App]
        B --> C[(EU Database\nconversation history\nyour retention policy)]
    end
    subgraph JuiceFactory
        B -->|full context per request| D[Stateless API\nRAM only]
        D -->|response| B
        D --> E[Memory freed\nnothing stored]
    end

Vous possédez les données. Vous définissez la conservation. Le fournisseur d'inférence est une couche de calcul pure.

Construire une application de chat sans état

La partie légèrement contre-intuitive : l'inférence sans état ne signifie pas que vous ne pouvez pas avoir de conversations multi-tours. Cela signifie que vous gérez l'état de la conversation, pas le fournisseur. Vous stockez l'historique dans votre base de données, l'envoyez avec chaque requête et gardez un contrôle total sur ce qui est conservé et pour combien de temps.

Voici comment le mettre en place :

Configuration de base

from openai import OpenAI

client = OpenAI(
    api_key="your-juicefactory-api-key",
    base_url="https://api.juicefactory.ai/v1"
)

C'est le seul changement de configuration par rapport à une configuration OpenAI standard. Tout le reste — format des requêtes, analyse des réponses, streaming — est identique.

Gestion de l'état des conversations

from openai import OpenAI
from typing import List

client = OpenAI(
    api_key="your-juicefactory-api-key",
    base_url="https://api.juicefactory.ai/v1"
)

def chat(history: List[dict], message: str) -> tuple[str, List[dict]]:
    """
    Send a message with conversation history to the stateless API.
    Returns the response and the updated history.

    History lives in your application — the API never sees it
    except as part of the current request.
    """
    history.append({"role": "user", "content": message})

    response = client.chat.completions.create(
        model="qwen3-vl",
        messages=history,
        max_tokens=500,
        temperature=0.7
    )

    assistant_message = response.choices[0].message.content
    history.append({"role": "assistant", "content": assistant_message})

    return assistant_message, history

# Example usage
conversation = []
reply, conversation = chat(conversation, "What is the GDPR right to erasure?")
print(reply)
reply, conversation = chat(conversation, "Does it apply to AI systems?")
print(reply)

L'API traite chaque requête à neuf. Vous contrôlez l'historique que vous incluez — et la durée pendant laquelle vous le stockez dans votre propre base de données.

Serveur de production avec FastAPI

Un serveur de chat sans état complet avec traitement des données conforme au RGPD :

from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
from typing import List, Dict
from openai import OpenAI
import uvicorn

client = OpenAI(
    api_key="your-juicefactory-api-key",
    base_url="https://api.juicefactory.ai/v1"
)

app = FastAPI()

class Message(BaseModel):
    user_id: str
    content: str

class Reply(BaseModel):
    content: str
    message_count: int

# ⚠️ DEMO ONLY — in-memory storage. In production, use an EU-hosted
# database (PostgreSQL, etc.) with encryption at rest and defined
# retention periods.
conversations: Dict[str, List[dict]] = {}

@app.post("/chat", response_model=Reply)
async def chat(message: Message):
    history = conversations.get(message.user_id, [])
    history.append({"role": "user", "content": message.content})

    response = client.chat.completions.create(
        model="qwen3-vl",
        messages=history,
        max_tokens=500,
        temperature=0.7
    )

    reply = response.choices[0].message.content
    history.append({"role": "assistant", "content": reply})
    conversations[message.user_id] = history

    return Reply(content=reply, message_count=len(history))

@app.delete("/conversations/{user_id}")
async def delete_conversation(user_id: str):
    """
    GDPR Article 17 — Right to Erasure.
    User requests deletion: remove their conversation history.
    Because the inference provider stores nothing, this is the only
    place their data exists.
    """
    if user_id in conversations:
        del conversations[user_id]
        return {"status": "deleted"}
    raise HTTPException(status_code=404, detail="No conversation found")

if __name__ == "__main__":
    uvicorn.run(app, host="0.0.0.0", port=8000)

L'endpoint du droit à l'effacement est trivial à implémenter — car vous contrôlez la seule copie des données. Avec un fournisseur avec état, vous devriez également coordonner avec leur infrastructure.

Ce que couvre et ne couvre pas la conservation zéro des données

« Conservation zéro des données » du côté du fournisseur d'inférence signifie qu'il ne stocke pas vos prompts ni vos réponses. Cela ne signifie pas que votre application n'a aucune conservation — c'est votre responsabilité.

Ce que JuiceFactory ne conserve pas :

• Le contenu des prompts
• Le contenu des réponses
• Toute donnée dérivée de vos requêtes
• Les données d'entraînement

Ce que les journaux opérationnels contiennent (métadonnées uniquement, pas de contenu) :

• Horodatages
• Identifiants de requête
• Compteurs de tokens
• Mesures de latence
• Codes de statut d'erreur

Ces champs de métadonnées ne contiennent pas de données personnelles. Ce sont les informations que tout fournisseur d'infrastructure journalise à des fins de facturation et de fiabilité.

C'est dans votre couche applicative que résident les obligations RGPD :

• Stocker l'historique des conversations dans une base de données hébergée dans l'UE
• Mettre en place des périodes de conservation configurables
• Construire les endpoints d'effacement (comme dans l'exemple ci-dessus)
• Journaliser ce dont vous avez besoin pour vos propres finalités, selon vos propres politiques

OpenAI vs fournisseurs sans état dans l'UE : quelles différences

Le comportement par défaut de l'API d'OpenAI conserve les données des requêtes pendant 30 jours. Les accords entreprise permettent de configurer une conservation zéro, mais cela nécessite un engagement minimum et une négociation explicite.

Même avec une conservation zéro configurée côté OpenAI, l'infrastructure sous-jacente est basée aux États-Unis, créant une exposition au CLOUD Act — les autorités américaines peuvent contraindre la divulgation de données détenues par des entreprises américaines, quel que soit l'emplacement des serveurs.

JuiceFactory est une entreprise suédoise, constituée dans l'UE, sans société mère américaine. Les données ne quittent jamais la juridiction de l'UE et il n'y a aucune exposition au CLOUD Act.

Pour la plupart des projets de développement avec des données non sensibles, cette distinction ne change pas le quotidien. Pour les applications traitant des données réglementées — informations de patients, documents financiers, documents juridiques — c'est souvent le facteur décisif.

FAQ

L'inférence sans état signifie-t-elle que je ne peux pas avoir de conversations multi-tours ? Non. Vous gérez l'historique des conversations dans votre application et l'incluez dans chaque requête. L'API traite l'historique complet que vous envoyez mais ne conserve rien après la réponse.

Comment vérifier que le fournisseur ne conserve réellement pas de données ? Consultez leur accord de sous-traitance (disponible dans le portail JuiceFactory sous Settings → Legal). Il spécifie les interdictions contractuelles de conservation des données en tant qu'obligation au titre de l'article 28 du RGPD. Vous pouvez également demander un audit technique.

Est-ce que cela remplace la nécessité d'une revue de conformité RGPD ? Non. L'inférence sans état traite le volet sous-traitant de l'obligation. Vous avez toujours besoin d'une base juridique pour le traitement, de la transparence envers les utilisateurs, d'une infrastructure pour les droits des personnes concernées et d'une documentation en tant que responsable du traitement.

Qu'en est-il des embeddings — sont-ils aussi sans état ? Oui. L'endpoint d'embedding de JuiceFactory (Qwen3-Embed) possède la même architecture à conservation zéro. Les documents que vous intégrez sont traités de manière transitoire.

L'inférence sans état est-elle plus lente ? Non. Il n'y a pas de différence de performance significative. Le traitement sans état ne nécessite pas de calcul supplémentaire — si quoi que ce soit, il est légèrement plus rapide car il n'y a pas de surcharge liée à la lecture/écriture d'état.

Prêt à construire ? Obtenez votre clé API JuiceFactory gratuite.

Guides connexes : Migrer d'OpenAI vers une API européenne · Comparatif des API LLM européennes 2026 · RAG en Python — Conforme au RGPD