Votre application OpenAI peut cesser de répondre demain : recherchez ces deux noms de modèles dans votre code

Deux chaînes de caractères peuvent suffire à mettre une application OpenAI en panne à partir de demain. OpenAI arrête l’accès API à gpt-5.2-chat-latest et gpt-5.3-chat-latest le 10 août 2026. Si l’un de ces identifiants est encore utilisé par un site, un worker, une fonction serverless ou un scénario n8n, les appels concernés pourront échouer après la coupure.

La documentation officielle recommande gpt-5.6-sol pour les deux modèles. Mais remplacer une chaîne en production sans test serait une seconde erreur : le modèle de remplacement est plus cher, accepte davantage de contexte, peut raisonner différemment et mérite une vérification des tool calls, des sorties structurées, de la latence et des limites de consommation.

Ce qu’OpenAI coupe exactement le 10 août

La page officielle des dépréciations OpenAI indique que les développeurs ont été prévenus le 8 mai 2026. Elle associe les deux arrêts au même remplacement :

Il s’agit des identifiants API « chat latest », pas d’une annonce disant que tout GPT-5.2, tout GPT-5.3 ou ChatGPT s’arrête simultanément. Un produit qui utilise un autre modèle n’est pas concerné par ces deux lignes. En revanche, une seule route secondaire oubliée peut suffire à casser la génération d’un résumé, une relance de support ou le traitement nocturne d’une file d’attente.

Le symptôme ne sera pas nécessairement une page blanche. L’API peut échouer dans un worker pendant que le site reste accessible, provoquer des retries coûteux, laisser des messages en attente ou activer un fallback ancien. Il faut donc chercher l’identifiant, puis suivre le trajet complet de la requête jusqu’à son consommateur.

L’audit de 10 minutes : où chercher les deux noms

Minute 0 à 2 : le dépôt. Recherchez les deux valeurs dans les sources, les fichiers cachés, les tests, les exemples, les manifestes de déploiement et les fichiers d’infrastructure. Vérifiez aussi les dépôts séparés du frontend, du backend et des workers. Une recherche dans le seul projet ouvert dans votre éditeur ne couvre pas forcément le service qui appelle réellement OpenAI.

Minute 2 à 4 : les environnements. Contrôlez les variables portant des noms comme OPENAI_MODEL, CHAT_MODEL, SUMMARY_MODEL ou LLM_DEFAULT dans le développement, la préproduction et la production. Ouvrez aussi le gestionnaire de secrets du fournisseur cloud. Le nom du modèle peut être la valeur d’un secret même s’il n’est pas confidentiel.

Minute 4 à 6 : les traitements invisibles. Inspectez les tâches cron, files de messages, workers, jobs nocturnes et services de reprise. Les agents persistants et les traitements longs, comme ceux abordés dans notre analyse de Muse Code et de la reprise après interruption, rendent cette vérification particulièrement importante : un processus déjà lancé peut conserver une ancienne configuration en mémoire.

Minute 6 à 8 : les outils sans code. Dans n8n et Make, recherchez les modules OpenAI, les requêtes HTTP personnalisées et les champs calculés. Vérifiez chaque version publiée d’un workflow, pas seulement le brouillon affiché. Faites le même contrôle dans Zapier, les outils internes, les fonctions serverless et les paramètres d’une plateforme d’hébergement.

Minute 8 à 10 : les données. Certaines applications permettent à un administrateur de choisir un modèle et stockent ce choix en base. Cherchez dans les tables de réglages, les feature flags, les configurations par client et les caches distribués. Vérifiez enfin les fallbacks : le modèle principal peut être à jour alors que le modèle appelé après un timeout ne l’est pas.

Le script qui scanne un projet sans afficher vos secrets

La commande rg -n est rapide, mais elle affiche généralement toute la ligne correspondante. Dans un fichier .env, cette ligne peut aussi contenir une clé, une URL privée ou un autre secret. Le scanner Node.js ci-dessous n’affiche que le chemin, le numéro de ligne et l’identifiant obsolète trouvé. Il ignore les fichiers binaires, les gros artefacts et les répertoires générés courants.

import { readdir, readFile, stat } from "node:fs/promises";
import { resolve, relative } from "node:path";

const ROOT = resolve(process.argv[2] ?? ".");
const SELF = resolve(process.argv[1] ?? "");
const TARGETS = [
  "gpt-5.2-chat-latest",
  "gpt-5.3-chat-latest",
];
const IGNORED = new Set([
  ".git", "node_modules", "vendor", "dist", "build",
  ".next", ".nuxt", "coverage", "target", ".venv",
]);
const MAX_BYTES = 2 * 1024 * 1024;
let matches = 0;

async function walk(directory) {
  let entries;
  try {
    entries = await readdir(directory, { withFileTypes: true });
  } catch {
    return;
  }

  for (const entry of entries) {
    if (IGNORED.has(entry.name)) continue;
    const fullPath = resolve(directory, entry.name);

    if (entry.isDirectory()) {
      await walk(fullPath);
      continue;
    }
    if (!entry.isFile() || fullPath === SELF) continue;

    try {
      if ((await stat(fullPath)).size > MAX_BYTES) continue;
      const buffer = await readFile(fullPath);
      if (buffer.includes(0)) continue;

      const lines = buffer.toString("utf8").split(/\r?\n/);
      lines.forEach((line, index) => {
        for (const model of TARGETS) {
          if (!line.includes(model)) continue;
          console.log(`${relative(ROOT, fullPath)}:${index + 1} -> ${model}`);
          matches += 1;
        }
      });
    } catch {
      // Fichier illisible : on continue et on le contrôle manuellement.
    }
  }
}

await walk(ROOT);
console.log(matches ? `${matches} occurrence(s) à corriger.` : "Aucune occurrence trouvée.");
process.exitCode = matches ? 1 : 0;

Enregistrez-le sous scan-openai-models.mjs, puis lancez :

node scan-openai-models.mjs .

Le code de sortie vaut 1 lorsqu’une occurrence est trouvée. Vous pouvez donc ajouter ce contrôle à la CI pour empêcher le retour d’un modèle retiré. Dans un dépôt utilisé par plusieurs agents, documenter cette commande dans AGENTS.md permet à Codex, Claude et Cursor d’exécuter le même contrôle au lieu d’improviser chacun une recherche différente.

Ce script ne prouve pas que la production est propre. Il ne voit pas les valeurs d’un secret cloud, une ligne de base chiffrée, un workflow distant ou une image de conteneur déjà construite. Sa bonne sortie signifie seulement : « aucune occurrence lisible dans ce dossier ». Le reste de l’inventaire demeure obligatoire.

Remplacer le modèle sans transformer l’urgence en régression

Pour rétablir rapidement un service utilisant Chat Completions, conservez d’abord le même endpoint, les mêmes messages, les mêmes outils et le même parseur. Modifiez le champ model dans un environnement de test, puis rendez l’effort de raisonnement explicite afin de pouvoir comparer les essais. Exemple en JavaScript avec le SDK OpenAI :

const completion = await client.chat.completions.create({
  model: "gpt-5.6-sol",
  messages,
  reasoning_effort: "none",
  tools,
});

Le niveau none constitue ici un point de départ de latence, pas une recommandation universelle. La documentation de migration GPT-5.6 demande de choisir intentionnellement l’effort de raisonnement et indique que le réglage omis prend medium par défaut. Testez ensuite low ou medium si la qualité du cas d’usage le justifie.

Si l’application utilise déjà Responses API, la forme équivalente place l’effort dans l’objet reasoning :

const response = await client.responses.create({
  model: "gpt-5.6-sol",
  input,
  reasoning: { effort: "none" },
  tools,
});

Ne migrez pas en même temps l’endpoint, le modèle, le prompt, le schéma JSON et les outils si votre priorité est d’éviter une coupure demain. Faites d’abord le changement minimal observable. La migration vers Responses API peut ensuite être réalisée dans une branche et un déploiement séparés. OpenAI recommande Responses pour les nouveaux projets et pour les workflows de raisonnement, d’outils et de conversations, mais Chat Completions reste pris en charge.

Les sept tests à rejouer avant le déploiement

1. Réponse simple. Vérifiez que le texte utile est extrait au bon endroit et que les erreurs sont gérées.
2. Sortie structurée. Rejouez les schémas JSON stricts, les champs obligatoires, les enums et les cas de refus.
3. Tool calls. Testez chaque outil, ses arguments, les appels multiples, les erreurs d’outil et la boucle de retour.
4. Streaming. Contrôlez les événements, l’ordre des fragments, la fin de réponse et l’annulation côté client.
5. Latence et timeouts. Mesurez p50, p95 et p99 sur des requêtes représentatives ; surveillez aussi les retries du proxy et des workers.
6. Tokens et coût. Comparez tokens d’entrée, tokens mis en cache, tokens de sortie et tokens de raisonnement sur le même jeu de tests.
7. Charge. Vérifiez les limites de débit du projet, la concurrence, les files d’attente et le comportement du fallback.

Les snapshots « chat latest » retirés coûtaient 1,75 dollar par million de tokens d’entrée et 14 dollars par million de tokens de sortie selon leurs pages de modèle. GPT-5.6 Sol est affiché à 5 dollars en entrée et 30 dollars en sortie, avec 0,50 dollar pour l’entrée mise en cache. À volume identique, le changement peut donc augmenter la facture avant même de compter un raisonnement plus long.

Il ne faut pourtant pas remplacer automatiquement Sol par le modèle le moins cher : le choix dépend de la difficulté, de la qualité attendue et de la charge. Notre comparatif GPT-5.6 Sol, Terra ou Luna détaille les écarts de prix qui peuvent multiplier la facture API par cinq. Pour l’urgence du 10 août, utilisez le remplacement explicitement recommandé par OpenAI, mesurez, puis décidez si un autre membre de la famille convient à certains parcours.

Le déploiement le moins risqué en cinq étapes

1. Créez un jeu de référence. Conservez des requêtes réelles anonymisées, leurs sorties attendues et les cas d’erreur.
2. Déployez en préproduction. Utilisez les mêmes outils, schémas, limites et timeouts que la production.
3. Lancez un canary. Envoyez une petite part du trafic vers gpt-5.6-sol et comparez les indicateurs.
4. Surveillez les erreurs par modèle. Ajoutez l’identifiant du modèle aux métriques, pas le prompt ni les données personnelles aux journaux.
5. Retirez le fallback obsolète. Une fois le canary validé, supprimez les deux anciens noms et relancez le scanner.

Prévoyez un rollback vers une configuration connue, mais pas vers les modèles qui s’arrêtent. Un feature flag peut basculer vers une autre configuration testée ; il ne doit pas seulement remettre l’ancienne chaîne. Vérifiez également les processus déjà actifs : redémarrer proprement un worker peut être nécessaire pour qu’il recharge la nouvelle variable d’environnement.

Deuxième alerte : l’Assistants API s’arrête le 26 août 2026

La correction des deux modèles ne règle pas une autre échéance proche. OpenAI indique que l’Assistants API sera arrêtée le 26 août 2026, après l’obtention d’une parité fonctionnelle dans Responses API. L’éditeur recommande une migration vers Responses API et Conversations API.

Le guide officiel de migration Assistants donne une correspondance claire :

Ajoutez donc une seconde recherche à l’audit : /v1/assistants, /v1/threads, /v1/threads/runs, beta.assistants et beta.threads. Cette migration est plus profonde qu’un changement de modèle. Elle mérite son propre inventaire des assistants, des fichiers, des outils, des threads actifs et des données à conserver.

La checklist finale avant de fermer le ticket

• Les deux identifiants obsolètes ont disparu des dépôts et des configurations distantes.
• Les workflows n8n, Make, cron, serverless et les workers ont été republiés ou redémarrés si nécessaire.
• Les sorties structurées et tous les tool calls passent sur un jeu de tests représentatif.
• Le niveau de raisonnement est explicite et mesuré.
• Les timeouts, retries et fallbacks ne renvoient pas vers un modèle retiré.
• Les métriques séparent erreurs, latence, tokens et coût par modèle.
• Un propriétaire et une date sont assignés à la migration Assistants avant le 26 août.

La priorité de ce 9 août n’est pas de réécrire toute l’intégration OpenAI. Elle est de retrouver chaque référence aux deux modèles, de valider le remplacement recommandé dans les conditions réelles de l’application et de déployer avec une observation suffisante pour revenir vers une configuration sûre. Dix minutes suffisent pour découvrir si le risque existe ; les tests déterminent si le correctif est réellement prêt.

Article vérifié le 9 août 2026 à partir des pages officielles de dépréciation, de modèles et de migration OpenAI. Les prix, limites et recommandations peuvent évoluer ; contrôlez les pages liées avant une décision de production.