Arrêt d’une AI API : auditer la migration avant la date limite

Changer modèle ou Base URL ne suffit pas : streaming, tools, erreurs, limites et usage peuvent changer. Il faut la date primaire de shutdown, toutes les dépendances, une comparaison de contrat et un cutover réversible. Le 25-08-2026, OpenAI publie date et remplacement dans Deprecations ; sa politique générale prévoit six mois pour generally available, trois pour les variantes spécialisées et moins pour preview. Suivez l’entrée précise.

1. Consigner l’événement

Avant le code, notez source, date de contrôle, endpoint/model ancien et nouveau, shutdown_date et owner. Prenez la date uniquement dans l’avis ; sinon, inscrivez unknown, désignez une vérification et n’inventez pas l’urgence.

deprecation_source: https://developers.openai.com/api/docs/deprecations
checked_at: 2026-08-25
old_endpoint: /v1/chat/completions
old_model: OLD_MODEL_ID
replacement_endpoint: /v1/chat/completions
replacement_model: NEW_MODEL_ID
shutdown_date: YYYY-MM-DD
owner: team-name

2. Inventorier les dépendances

Incluez endpoint, Base URL, protocole, ID/fallback, payload/messages, schema/fields/choice des tools, parser SSE/usage, erreurs/retry, prompt, services, cron, workflows, SDK, CI, serverless, n8n/Dify, secret store et jobs. Gardez noms et owners des secrets, jamais leurs valeurs.

3. Préparer les contrôles

Utilisez des tâches réelles nettoyées : texte factuel, JSON obligatoire, tool call valide, cas sans tool, stream terminé, 4xx et erreur temporaire/test double. Comparez schema, arguments, résultat, faits, fin du stream et retry, pas la prose ; mesurez coût et latency séparément.

4. Vérifier streaming et erreurs

Notez événement et data, fin, usage, coupure avant/après le premier token et risque de doublon externe. Conservez HTTP status, code machine-readable et limite de retry. Ne répétez pas 401, 403 ou schema validation error ; pour 429/5xx temporaire, respectez Retry-After, limitez les essais et ajoutez idempotency.

5. Doubler l’exécution

En test, l’ancien chemin est baseline et le nouveau reçoit les mêmes fixtures. Gardez :

case_id | old_result | new_result | contract_pass | difference | decision

Arguments, fields, fin de stream ou erreur modifiés exigent correction ou acceptation.

Avec BetterToken, utilisez https://www.bettertoken.ai/v1/chat/completions, Bearer Key et Model ID courant. Créez une test Key, exécutez la requête de contrôle selon le contrat actuel de Chat Completions et consignez le HTTP status ainsi qu’un champ de réponse vérifiable : format, non équivalence.

Avant le cutover, comparez les fields au contrat actuel. Ouvrir le guide Chat Completions

6. Basculer de façon réversible

Préparez feature flag/config versionnée, owner/fenêtre, métriques, condition exacte de rollback et ancienne config sans secrets. Déployez les deux, commencez contrôlé, comparez, élargissez seulement si les critères passent, revenez sur invariant écrit et retirez l’ancien après observation avant shutdown. Gardez le temps de corriger et recommencer : rollback ne rétablit pas une API arrêtée.

Preuves

Exigez source/date, inventaire avec owners, fixtures/résultats versionnés, décision par différence et runbook mesurable. Sans un élément, restez migration_in_progress malgré 200.

Sources : https://developers.openai.com/api/docs/deprecations et https://docs.bettertoken.ai/api-reference/chat-completions.