<!-- Canonical URL: https://ask.atlascloud.ai/fr/build-sanitized-request-replay-set-llm-api-migration -->

# Comment créer un jeu de relecture de requêtes assaini pour migrer une API de LLM ?

> Créez un corpus minimal et versionné en échantillonnant par couverture, en supprimant les champs inutiles, en remplaçant les valeurs sensibles par des données synthétiques cohérentes qui préservent la structure, en isolant les outils et en analysant l'artefact final.

Créez un jeu assaini en sélectionnant des requêtes représentatives, en détectant et remplaçant secrets et données personnelles, en préservant les propriétés structurelles qui influencent le modèle et en vérifiant qu'aucune donnée sensible ne subsiste. Stockez-le comme artefact de test versionné avec assertions, pas comme export de journaux bruts.

L'objectif est de couvrir le comportement sans recopier le risque de production.

## Définir ce que la relecture doit prouver

Énumérez les risques avant l'échantillonnage : longueur, langues, schemas d'outils, sortie structurée, éléments multimodaux, streaming, refus de sécurité, grand contexte et paramètres.

Créez des catégories de couverture et choisissez délibérément les cas. Un échantillon aléatoire peut manquer les formes rares, tandis qu'une collection d'échecs déforme le trafic normal.

## Minimiser lors de la collecte

N'exportez que les champs nécessaires. Supprimez en-têtes d'autorisation, cookies, adresses IP, métadonnées de compte, facturation et journaux sans rapport avant l'arrivée dans l'espace de test.

Utilisez une liste autorisée comme celle-ci :

```json
{
  "fixture_id": "fx_0042",
  "request": {
    "model_alias": "support_default",
    "messages": [],
    "tools": [],
    "temperature": 0.2
  },
  "assertions": {
    "valid_json": true,
    "required_keys": ["category", "confidence"]
  }
}
```

Générez un nouveau `fixture_id` et n'utilisez pas un ID utilisateur ou fournisseur comme clé publique.

## Détecter les données sensibles par couches

Combinez détecteurs déterministes, dictionnaires internes et revue contextuelle. Cherchez clés API, tokens, clés privées, chaînes de connexion, emails, téléphones, comptes, hôtes internes, secrets de code et identifiants réglementés.

Aucun détecteur n'est complet. Effectuez plusieurs passages et confiez les correspondances incertaines à un réviseur autorisé. Les métadonnées et pixels des images et documents peuvent aussi contenir des informations sensibles.

## Remplacer tout en préservant le comportement

Utilisez des marqueurs typés cohérents comme `<EMAIL_1>` ou `<ORDER_ID_2>`. Une même valeur reçoit le même marqueur dans un cas, mais la correspondance ne doit pas être réversible hors d'un processus temporaire contrôlé.

Préservez longueur approximative, classe Unicode, type JSON, taille de liste, délimiteurs et relations entre champs. Si la longueur en tokens déclenche un échec, remplacez le texte par un contenu synthétique sûr de taille proche.

Ne vous contentez pas de hacher les numéros de téléphone ou autres valeurs à faible entropie. Supprimez ou synthétisez lorsqu'aucune réversibilité n'est requise.

## Retirer le contenu actif et dangereux

Le jeu peut contenir injections de prompt, commandes, URL ou code à effets secondaires. Désactivez les outils externes par défaut et remplacez ceux qui écrivent par des stubs déterministes.

N'autorisez le réseau que vers des endpoints de test contrôlés. Ne relisez jamais des identifiants de production, URL signées, commandes destructrices ou webhooks clients.

## Ajouter des assertions, pas des réponses exactes

La sortie d'un LLM varie. Stockez des contrôles de schema, champs obligatoires, choix d'outil, catégorie de refus, langue, latence maximale, limites de tokens et rubriques sémantiques. Réservez l'égalité exacte aux transformations déterministes.

Consignez modèles source et cible, version de l'adaptateur, version du template et date à chaque exécution.

## Valider l'artefact assaini

Avant approbation, analysez secrets et PII, inspectez les types de fichier et révisez manuellement un échantillon. Confirmez que chaque catégorie reste représentée. Remplacez tout cas devenu sûr mais non représentatif par un équivalent synthétique.

Protégez ce jeu comme des données de test, pas comme un document public. Appliquez accès, rétention, audit et suppression. Séparez la table temporaire de correspondance et détruisez-la après validation si la politique le permet.

## L'utiliser comme porte de migration

Exécutez les mêmes cas avec les adaptateurs source et cible. Comparez sorties normalisées, erreurs, latence, usage et coût. Étudiez les différences par catégorie et ajoutez des cas de régression pour les nouvelles incompatibilités.

Versionnez ensemble le jeu et les règles d'assainissement.

## En résumé

Un jeu sûr est un corpus de test minimal conçu à cet effet, pas une copie des journaux. Appliquez détection et revue en couches, données synthétiques préservant la structure, isolation des effets et assertions de comportement. Analysez de nouveau l'artefact avant d'en faire une porte de migration.

## FAQ

### Pourquoi ne pas relire un export aléatoire des journaux de production ?

Les journaux bruts peuvent exposer secrets et données personnelles, tandis qu'un échantillon aléatoire peut manquer des formes rares. Construisez un jeu minimal selon des catégories de risque explicites.

### Comment remplacer les valeurs sensibles ?

Utilisez des marqueurs typés cohérents ou des données synthétiques qui préservent longueur, type, délimiteurs, classe Unicode et relations utiles sans rester réversibles.

### Le hachage suffit-il à anonymiser les données utilisateur ?

Pas pour les valeurs à faible entropie comme les numéros de téléphone, souvent devinables. Préférez la suppression ou la synthèse si la réversibilité est inutile.

### Comment relire en sécurité les appels d'outils ?

Désactivez les outils externes par défaut et remplacez-les par des stubs déterministes. N'incluez jamais d'identifiants de production, de webhooks clients ni d'effets d'écriture.

### Les sorties attendues doivent-elles être du texte exact ?

En général, non. Utilisez des assertions de schema, champs, outil, refus, langue, latence, usage et rubrique; réservez l'égalité exacte aux tâches déterministes.

### Comment approuver le jeu final ?

Exécutez des analyses de secrets et de PII, inspectez les fichiers, révisez un échantillon, confirmez la couverture et appliquez accès, rétention et suppression.
