D7 · Production Safety and Operations

Ce domaine représente environ 8 % de l’examen blanc OAI-API — à peu près 5 des 60 items — et s’appuie sur le matériel d’exploitation et de sécurité tissé à travers le parcours API de l’Academy. Il teste si vous savez amener une application qui fonctionne en production en toute sécurité : modérer le contenu, faire du red teaming et surveiller le mésalignement, marquer la provenance, régler les limites de débit et de dépense, gérer les erreurs avec des retries, et verrouiller l’accès avec le RBAC et des contrôles réseau.

Ce que vous devez savoir

La production est là où une application rencontre des entrées non fiables, de l’argent réel et de vrais utilisateurs. Vous filtrez le contenu avec la modération et des classificateurs de sécurité, sondez les faiblesses avec le red teaming, et surveillez le mésalignement dans le comportement en direct. Vous marquez les médias générés par IA avec la provenance du contenu. Vous plafonnez le rayon d’impact avec des limites de débit et des limites de dépense, et vous gérez les défaillances transitoires avec des retries et un backoff exponentiel déclenchés selon les bons codes d’erreur. Vous restreignez qui et quoi peut atteindre l’API avec le RBAC, Private Link, des IP allowlists, le mutual TLS et la workload identity federation — pour que les identifiants soient scopés, à courte durée de vie et bornés au réseau. Une checklist de déploiement lie tout cela sous forme de gates de lancement.

Objectifs d’apprentissage

À la fin de cette page, vous devriez être capable de :

1. Appliquer la modération et des classificateurs de sécurité aux entrées et sorties.
2. Expliquer le red teaming et la surveillance du mésalignement.
3. Régler les limites de débit et les limites de dépense pour borner le rayon d’impact.
4. Gérer les codes d’erreur avec un comportement correct de retry et de backoff.
5. Choisir les contrôles d’accès : RBAC, Private Link, IP allowlist, mTLS, workload identity federation.
6. Exécuter une checklist de déploiement avant le lancement.

7.1 Sécurité : modération, classificateurs, red teaming, mésalignement

Le red teaming est proactif (vous attaquez votre propre système) ; la surveillance du mésalignement est continue (vous surveillez ce qu’il fait réellement). La provenance du contenu (marquer les médias générés par IA) soutient les obligations de transparence.

7.2 Limites de débit et limites de dépense

Deux contrôles de rayon d’impact différents :

Des boucles d'agent emballées appelant l'API 1000×/min
        │
   limite de débit → 429 plafonne le taux de requêtes
   limite de dépense → plafond dur en dollars, alerte avant le plafond

Réglez les deux avant le lancement. Une limite de dépense est la différence entre un bug qui coûte $50 et un qui coûte $50,000.

7.3 Codes d’erreur et retries

import time
for attempt in range(5):
    try:
        return client.responses.create(model="gpt-5.6-terra", input=q)
    except RateLimitError:               # 429
        time.sleep(2 ** attempt)         # 1, 2, 4, 8, 16s
    except BadRequestError:              # 400 — ne pas retry
        raise

Le discriminant de nombreux items : retry les erreurs transitoires (429/5xx) avec backoff ; ne jamais retry aveuglément un 400/401/403 — retry une requête malformée ou non autorisée ne fait que gaspiller le quota et peut aggraver la limitation de débit.

7.4 Contrôle d’accès et sécurité réseau

7.5 La checklist de déploiement

Avant le lancement, confirmer :
[ ] Modération sur les entrées et sorties non fiables
[ ] Passe de red team pour injection / jailbreak / exfiltration
[ ] Guardrails + approbation humaine sur les actions irréversibles
[ ] Limite de débit réglée ; limite de dépense réglée avec alerte sous le plafond
[ ] Retry avec backoff exponentiel sur 429/5xx ; pas de retry sur les 4xx auth/validation
[ ] RBAC au moindre privilège sur les clés et les rôles
[ ] Contrôles réseau selon besoin (Private Link / IP allowlist / mTLS)
[ ] Identifiants fédérés à courte durée de vie au lieu de clés statiques où c'est possible
[ ] Résidence / rétention des données vérifiées face aux exigences (voir D4)
[ ] Gate d'évaluation au vert (voir D3) ; tracing/observabilité actif (voir D4)
[ ] Surveillance du mésalignement pour les agents déployés

Cadre de décision

Utilisez GUARD pour décider des contrôles qu’un lancement en production nécessite.

Erreurs fréquentes

Défi de mise en situation

Mise en situation. Vous lancez un agent de support autonome qui lit des messages clients (entrée non fiable), appelle des outils internes pour émettre des remboursements, et s’exécute sur Kubernetes. La sécurité demande : comment l’empêcher de vider le budget, empêcher un message malveillant de le détourner, et éviter les clés d’API statiques dans le cluster ? Le plan actuel de l’équipe enveloppe chaque appel d’API dans une boucle « retry jusqu’à 5 fois sur toute erreur » et stocke une clé d’API à longue durée de vie dans un Kubernetes secret.

Trace de raisonnement d’expert.

1. Rayon d’impact du budget → limite de dépense + limite de débit. Un agent qui boucle ou est abusé pourrait appeler l’API des milliers de fois. Réglez une limite de dépense avec alerte sous le plafond et une limite de débit, pour qu’une boucle emballée heurte un plafond dur en dollars et un 429 plutôt qu’une facture illimitée.
2. Message malveillant → red team + modération + guardrails + approbation. Les messages clients sont non fiables, donc une charge de prompt-injection pourrait tenter de faire émettre à l’agent un remboursement non autorisé. Faites du red team pour l’injection avant le lancement, modérez les entrées, ajoutez des guardrails de sortie/d’outil, et placez l’action de remboursement derrière une approbation humaine (D4) puisqu’elle est irréversible.
3. La boucle de retry est mauvaise. « Retry toute erreur 5× » retentera volontiers un 400 (malformé) et un 401/403 (auth/permission), gaspillant le quota et masquant de vrais bugs. Correct : ne retry que les 429/5xx avec backoff exponentiel, et échouer vite sur les 4xx auth/validation.
4. La clé statique est une responsabilité. Une clé à longue durée de vie dans un K8s secret peut fuiter. Utilisez la workload identity federation pour que le pod échange son identité Kubernetes contre un token à courte durée de vie — pas de clé statique à voler.
5. Contrôles réseau. Si l’egress de la charge est fixe, ajoutez une IP allowlist, et utilisez Private Link si le trafic doit rester hors internet public ; le RBAC scope l’identifiant aux seuls outils de remboursement/support.
6. Surveiller après le lancement. Activez la surveillance du mésalignement et le tracing pour qu’un agent qui dérive ou est détourné soit attrapé en production.

Décision conforme à l’examen : limites de dépense + de débit, red teaming et modération avec un gate d’approbation sur les remboursements, retry sélectif (429/5xx avec backoff uniquement), workload identity federation au lieu d’une clé statique, RBAC et contrôles réseau, et surveillance du mésalignement. Pas de retry-tout, pas de clé à longue durée de vie dans un secret, pas de remboursement automatique sans gate.

Pièges d’évaluation

Questions d’entraînement

Chaque item indique combien de réponses sélectionner. Engagez-vous avant de révéler.

Points clés à retenir

• Filtrez les entrées non fiables et les sorties du modèle avec la modération et des classificateurs de sécurité ; faites du red team avant le lancement.
• Réglez à la fois une limite de débit (débit) et une limite de dépense (dollars) avec alerte pour borner le rayon d’impact.
• Ne retry que les erreurs transitoires (429, 5xx) avec backoff exponentiel ; ne jamais retry aveuglément un 400/401/403.
• Scopez les identifiants avec le RBAC au moindre privilège et ajoutez Private Link, IP allowlist ou mTLS au niveau de risque.
• Préférez la workload identity federation et les tokens à courte durée de vie aux clés statiques à longue durée de vie.
• Placez les actions d’agent irréversibles derrière une approbation humaine et surveillez les agents déployés pour le mésalignement.
• Traitez la checklist de déploiement comme des gates de lancement : sécurité, limites, résilience, accès, résidence, évaluations et observabilité.