Tous les articles
IA & dev

Dépréciation de GPT-4o et GPT-4.1 dans l'API : la checklist de migration avant le 14 janvier 2027

Par Elouan Laurent
Lettres en bois formant OpenAI ChatGPT, illustration de la fin de GPT-4o et GPT-4.1 dans l'API

Qu'est-ce qu'OpenAI a annoncé le 14 octobre ?

Le 14 octobre 2026, OpenAI a annoncé l'arrêt de cinq versions de modèles dans son API, le 14 janvier 2027. Sont visés gpt-4o-2024-08-06, gpt-4o-2024-11-20, gpt-4o-mini-2024-07-18, gpt-4.1-2025-04-14 et gpt-4.1-mini-2025-04-14. Les fine-tunes construits sur ces modèles s'arrêtent le même jour.

Le remplaçant recommandé pour les cinq est gpt-6-luna, sorti le 22 septembre. C'est ce qu'indique la page Deprecations d'OpenAI, que j'ai relue le 15 octobre 2026.

Le préavis est de trois mois. La même page promet pourtant « au moins 6 mois » pour les modèles en disponibilité générale, sauf raison de sécurité ou de conformité. L'entrée du 14 octobre n'explique pas l'écart.

Ne confondez pas avec février. Le 13 février 2026, GPT-4o a quitté l'application ChatGPT, et l'API n'avait pas bougé.

Cette fois, c'est votre code qui est concerné.

Les prix et les dates qui suivent viennent de la documentation d'OpenAI au 15 octobre 2026. Je n'ai pas testé gpt-6-luna.

Étape 1 : trouver tous les appels, y compris ceux qu'un grep ne voit pas

Commencez par chercher les identifiants dans le code, la configuration et les fichiers de déploiement :

grep -rnE "gpt-4o|gpt-4\.1|GPT_4_O|GPT_4_1" \
  --include='*.java' --include='*.kt' --include='*.properties' \
  --include='*.yml' --include='*.yaml' --include='*.json' --include='*.env' .

GPT_4_O et GPT_4_1 sont les constantes de l'enum OpenAiChatModelName de LangChain4j. Les guillemets autour des motifs comptent : sans eux, zsh, le shell par défaut de macOS, refuse la commande. Je n'ai pas lancé ce grep sur un vrai projet. Étendez-le aux valeurs Helm, aux variables d'environnement et aux tables de paramètres en base.

Trois cas échappent au grep.

  • Le défaut de Spring AI 1.x. La propriété spring.ai.openai.chat.options.model vaut gpt-4o-mini quand on ne la renseigne pas, d'après la doc 1.1. Une application sans aucun nom de modèle appelle donc l'alias gpt-4o-mini, dont la version par défaut est visée.
  • Les alias sans date. gpt-4o pointe par défaut vers gpt-4o-2024-08-06, et gpt-4o-mini vers gpt-4o-mini-2024-07-18. L'annonce ne cite pas les alias, et OpenAI ne dit pas ce qu'ils deviendront. Je les traite comme visés.
  • Les modèles choisis à l'exécution, lus dans une base ou passés par un client. Seuls les journaux d'appels les montrent.

Pour surveiller la suite, GET /v1/models peut renvoyer un champ shutdown_date pour chaque modèle. Il vaut null tant qu'aucune date n'est annoncée. OpenAI prévient aussi par e-mail les comptes qui utilisent un modèle visé.

Étape 2 : les fine-tunes ne se refont pas sur gpt-6-luna

Un fine-tune est un modèle réentraîné sur vos propres exemples. Celui de gpt-4o-mini-2024-07-18 s'arrêtera avec son modèle de base.

Le réflexe serait de le réentraîner sur le remplaçant. C'est impossible : la fiche gpt-6-luna indique « Fine-tuning : Not supported ». Même chose pour gpt-6-sol.

OpenAI met d'ailleurs fin, par étapes, à sa plateforme de fine-tuning. Depuis le 2 juillet 2026, une organisation sans inférence sur un fine-tune depuis 60 jours ne peut plus créer de job. Le 6 janvier 2027, les clients actifs perdront aussi ce droit.

Dans la table de prix du fine-tuning, chaque modèle de base listé a une date d'arrêt au plus tard le 14 janvier 2027. Un fine-tune OpenAI n'a donc pas de successeur direct.

Il reste trois pistes :

  • remplacer le fine-tune par des instructions et des exemples dans le prompt, mesurés sur vos cas ;
  • passer par la sortie structurée quand le fine-tune servait à imposer un format ;
  • réentraîner un modèle ailleurs, chez un autre fournisseur ou sur des poids ouverts.

Étape 3 : comparer les prix, tokens de raisonnement compris

Voici les prix publics de la page Pricing, en dollars par million de tokens, au tarif standard :

gpt-4o gpt-4o-mini gpt-4.1 gpt-4.1-mini gpt-6-luna
Entrée 2,50 0,15 2 0,40 0,10
Entrée en cache 1,25 0,075 0,50 0,10 0,01
Sortie 10 0,60 8 1,60 0,50

Depuis gpt-4o, l'entrée coûte 25 fois moins cher et la sortie 20 fois moins. Depuis gpt-4o-mini, l'écart tombe à 1,5 et 1,2.

Le piège est ailleurs. gpt-6-luna est un modèle de raisonnement, avec un effort medium par défaut. Ses tokens de raisonnement sont invisibles, mais facturés comme de la sortie.

Prenons une requête de 2 000 tokens d'entrée et 500 de sortie. C'est un calcul sur les prix publiés, pas une mesure :

  • gpt-4o : 10 $ les 1 000 requêtes.
  • gpt-4o-mini : 0,60 $ les 1 000 requêtes.
  • gpt-6-luna sans raisonnement : 0,45 $ les 1 000 requêtes.

Chaque token de raisonnement ajoute 0,50 $ par million. Au-delà de 300 tokens de raisonnement par requête, gpt-6-luna coûte plus cher que gpt-4o-mini sur cet exemple.

Deux autres lignes changent. L'écriture de cache est facturée 0,125 $ par million de tokens. Et au-delà de 272 000 tokens d'entrée, toute la requête paie double en entrée et en cache, et 1,5 fois en sortie.

Étape 4 : ce qui peut casser côté Spring AI et LangChain4j

Changer le nom du modèle ne suffit pas. La fiche de gpt-6-luna pose une contrainte : en Chat Completions, l'appel d'outils ne fonctionne qu'avec reasoning_effort à none. L'API Responses n'a pas cette limite.

Or Spring AI 2.0.1 passe par Chat Completions. Le jalon 2.1 ajoute OpenAiResponsesChatModel : j'en ai détaillé l'usage dans le jalon Spring AI 2.1 et son API Responses. Côté LangChain4j, OpenAiResponsesChatModel existe déjà, avec un réglage reasoningEffort.

# Spring AI 2.1.0-M1 (jalon, non stable) : passer par l'API Responses
spring.ai.openai.chat.api=responses
spring.ai.openai.responses.model=gpt-6-luna
spring.ai.openai.responses.reasoning-effort=low

Ce bloc reprend les propriétés de la doc 2.1. Je ne l'ai pas exécuté.

Trois points à tester en branche :

  • max-tokens : en Chat Completions, la doc Spring AI 2.0.1 l'interdit pour les modèles de raisonnement et demande max-completion-tokens. Avec l'API Responses de la 2.1, la propriété devient max-output-tokens.
  • temperature : Spring AI la dit non supportée par les modèles GPT-5 de raisonnement. Pour gpt-6-luna, je n'ai trouvé aucune règle écrite.
  • Le nom du modèle : l'enum OpenAiChatModelName de LangChain4j n'a pas de constante GPT-6 sur sa branche principale. Passez la chaîne "gpt-6-luna".

Étape 5 : un jeu de prompts maison comme test de non-régression

Un modèle plus récent n'est pas meilleur sur vos cas par principe. Il faut le vérifier.

Constituez 30 à 50 requêtes réelles, tirées de vos journaux. Pour chacune, écrivez une sortie attendue que le code peut contrôler : une classe, un JSON validé, un identifiant. Les réponses libres se comparent mal.

Rejouez ce jeu sur l'ancien modèle, puis sur gpt-6-luna à plusieurs niveaux d'effort. Relevez le taux de réussite, la latence et les tokens de raisonnement indiqués dans usage. Ce dernier chiffre décide du coût réel.

Gardez ce jeu dans le dépôt. Il resservira à la prochaine annonce.

Le calendrier jusqu'au 14 janvier 2027

Au 15 octobre, il reste 13 semaines. Trois dates tombent avant l'échéance du 14 janvier :

  • 23 octobre 2026 : arrêt de gpt-4o-2024-05-13 et de gpt-4.1-nano, annoncé en avril. Si vous avez figé ce snapshot de GPT-4o, votre échéance tombe près de trois mois plus tôt.
  • 11 décembre 2026 : arrêt de gpt-5-mini-2025-08-07, le snapshot par défaut de l'alias gpt-5-mini. Cet alias est le modèle par défaut de Spring AI 2.0.1.
  • 6 janvier 2027 : les clients actifs ne peuvent plus créer de job de fine-tuning.
  • 14 janvier 2027 : arrêt des cinq modèles et de leurs fine-tunes.

Mon avis : que faire cette semaine ?

Mon avis : le changement d'identifiant est rapide, la vérification occupera le reste du trimestre. Le prix baisse beaucoup depuis gpt-4o, beaucoup moins depuis gpt-4o-mini, et le raisonnement peut inverser le calcul.

Trois actions :

  1. Faire l'inventaire avec le grep, les propriétés Spring AI et les journaux d'appels. N'oubliez pas le défaut gpt-4o-mini de Spring AI 1.x.
  2. Lister vos fine-tunes et décider d'un plan B avant le 6 janvier.
  3. Sortir le nom du modèle du code : une propriété par usage, et le jeu de tests pour chaque changement. Une passerelle comme OpenRouter permet aussi de changer de fournisseur sans toucher au code.

Vous avez une application Spring Boot qui appelle GPT-4o ou GPT-4.1 ? Je développe en Java / Spring Boot depuis 2015 et je peux auditer vos appels avec vous. Réserver un appel découverte de 30 minutes.

À lire ensuite