Chaîne de montage automatisée tournant seule dans un atelier vide sous une étiquette d'échéance

Vos automatisations tournent-elles encore dans trois mois ?

OpenAI éteint quatre de ses modèles. GPT-4o, GPT-4o mini, GPT-4.1 et GPT-4.1 mini quitteront son API le 14 janvier 2027, l’API étant la porte par laquelle un logiciel envoie ses questions au modèle et reçoit ses réponses. Cela paraît réservé aux développeurs, ce ne l’est pas : un chatbot sur un site, un tri automatique des emails, un scénario Make ou n8n qui remplit le CRM ont presque toujours l’un de ces quatre noms inscrit quelque part dans leurs réglages. Ce jour-là, l’outil ne répondra plus, il renverra une erreur. Trois mois pour s’en apercevoir, vérifier et basculer, c’est court quand on ne sait plus très bien qui a construit l’outil, ni avec quelle clé.

Le retrait vaut pour les versions affinées, et un premier lot tombe le 23 octobre

La page de dépréciation d’OpenAI est précise. Les versions datées de GPT-4o (août et novembre 2024), de GPT-4o mini (juillet 2024), de GPT-4.1 et de GPT-4.1 mini (avril 2025) s’arrêtent le 14 janvier, et les modèles affinés sur ces bases, ceux qu’une entreprise a entraînés sur ses propres exemples, s’arrêtent le même jour. Le remplaçant conseillé est le même pour les quatre : gpt-6-luna, le modèle léger de la famille GPT-6, celui qui sert déjà les comptes gratuits de ChatGPT.

Un lot plus ancien part avant. La toute première version de GPT-4o, celle de mai 2024, ainsi que GPT-4.1 nano, GPT-4 Turbo, o1, o3-mini et o4-mini disparaissent le 23 octobre. Ce retrait-là avait été annoncé en avril. Il concerne les automatisations les plus anciennes, donc les plus oubliées.

Le préavis fait tiquer. Sur la même page, OpenAI écrit qu’un modèle en disponibilité générale est annoncé au moins six mois avant son retrait, sauf raison de sécurité ou de conformité. GPT-4o et GPT-4.1 en ont eu trois, sans explication, comme le relève The New Stack. Ce n’est pas un détail pour qui planifie un budget : la règle des six mois est une intention, pas une garantie contractuelle.

L’email est parti, mais pas forcément chez vous

OpenAI prévient par email « les clients qui utilisent activement le modèle ». Le client, au sens d’OpenAI, c’est le titulaire de la clé d’API. Quand une agence, un indépendant ou un éditeur de logiciel a construit l’automatisation avec sa propre clé, c’est lui qui a reçu le message le 14 octobre, au milieu de ses autres notifications. L’entreprise qui dépend de l’outil n’a rien vu passer, et rien ne l’oblige à être prévenue.

Second angle mort : les outils sans code. Dans n8n ou Make, le nom du modèle est enregistré en toutes lettres dans le scénario au moment où on le construit. Un workflow monté en 2024 à partir d’un modèle de la bibliothèque porte très probablement gpt-4o-mini quelque part, parce que c’était le choix économique de l’époque, et personne ne l’a rouvert depuis. Les workflows qui marchent sont ceux qu’on ne regarde plus. Nous l’avons constaté la semaine dernière chez un client : un agent de qualification dans n8n tournait sur gpt-5-mini, dont le retrait est fixé au 11 décembre. Il n’était pas en panne. Il allait l’être.

Il existe un moyen de le savoir sans attendre un email. L’API porte, pour chaque modèle, un champ nommé shutdown_date, qui contient la date de retrait annoncée, ou rien quand il n’y en a pas. Un script de dix lignes qui interroge la liste des modèles une fois par semaine et signale toute date nouvelle suffit à ne plus dépendre d’une boîte mail que l’on ne lit pas.

Le remplaçant coûte vingt fois moins, et ne répond pas pareil

Sur le papier, la migration est une bonne affaire. GPT-4o se facture 2,50 $ le million de jetons en entrée et 10 $ en sortie ; gpt-6-luna, 0,10 $ et 0,50 $, d’après la grille tarifaire d’OpenAI. Même le petit GPT-4o mini, à 0,15 $ et 0,60 $, coûte plus cher que le remplaçant. L’argument du prix ne pèsera donc pas contre la migration. L’argument du comportement, si.

gpt-6-luna est un modèle qui raisonne avant de répondre, avec un niveau d’effort réglé sur « moyen » par défaut, selon sa fiche. GPT-4o ne raisonnait pas. Trois conséquences pour une automatisation conçue pour lui :

  • Les jetons de raisonnement sont facturés en sortie. Une alerte de consommation réglée en nombre de jetons se déclenchera pour de mauvaises raisons, et les réponses arriveront un peu plus tard qu’avant.
  • L’appel de fonctions change de règle. Dans l’interface classique de l’API, celle que la plupart des intégrations de 2024 utilisent, le modèle ne peut déclencher une action (chercher un dossier, écrire dans le CRM) que si le raisonnement est désactivé. Un agent qui s’en sert doit soit couper le raisonnement, soit passer à la nouvelle interface Responses, ce qui est un chantier à part entière.
  • Les connaissances s’arrêtent en mai 2026, contre octobre 2023 pour GPT-4o. Un prompt qui compensait l’ignorance de l’ancien modèle à coups de rappels peut se mettre à le contredire.

Et puis il y a ce qu’aucune documentation n’annonce : la forme des réponses. Un modèle plus récent découpe autrement, prend d’autres libertés avec un format JSON imposé, ferme ses phrases différemment. Le maillon suivant, celui qui lit cette sortie pour remplir une fiche ou router un ticket, n’a pas été prévenu. C’est pour cela qu’on ne remplace pas un nom de modèle dans un champ : on rejoue d’abord une cinquantaine de cas réels sur l’ancien et sur le nouveau, et on compare ligne à ligne.

L’inventaire tient en une semaine

Avant le 14 janvier : cinq gestes pour vos automatisations

1

Lister les appels

Le tableau de bord d’utilisation d’OpenAI ventile la consommation par modèle. Côté outils, exporter les workflows n8n ou Make et chercher « gpt-4o » et « gpt-4.1 » dans les fichiers.

2

Écrire aux prestataires

Une question par outil : quel modèle, quelle clé, quelle date de bascule prévue, quel test. Réponse écrite, avec une date.

3

Rejouer cinquante cas réels

Les mêmes entrées envoyées à l’ancien et au nouveau modèle. Comparer le format des réponses, les appels d’outils déclenchés, le délai.

4

Basculer, raisonnement coupé d'abord

Changer l’identifiant et régler l’effort de raisonnement sur « none » pour rester au plus près de l’ancien comportement. Ouvrir le raisonnement plus tard, si un cas le justifie.

5

Poser la surveillance

Le champ shutdown_date interrogé chaque semaine, et un calendrier des retraits tenu pour OpenAI, Google et Anthropic.

Le point 2 est celui qui se négocie le moins. Un prestataire qui tient la clé d’API tient aussi la date de bascule : il faut la lui demander par écrit, avec le nom du modèle de remplacement et la façon dont il compte tester. Une réponse du type « on s’en occupe » n’est pas une date.

La prochaine vague est déjà datée

Le 14 janvier n’est pas une exception. La même page annonce le retrait de GPT-5.1 et de GPT-5.3-Codex au 1er avril 2027, celui des modèles de synthèse vocale tts-1 au 6 janvier, celui de la famille audio de GPT-4o au 20 janvier. Anthropic et Google tiennent des calendriers équivalents. Un modèle vit entre un et deux ans dans une API, et l’automatisation construite dessus est censée durer plus longtemps que lui.

C’est le point que nous décrivions dans notre article sur la dépendance au fournisseur d’IA et dans celui sur l’IA qui marche en démo et casse en silence : ce qui coûte cher n’est pas l’outil, c’est l’absence de quelqu’un qui le regarde. Une automatisation en production a besoin d’un nom en face, d’une ligne de budget pour les tests de bascule, et d’un calendrier des retraits. Le 14 janvier, les workflows que personne n’a rouverts le seront pour la première fois depuis deux ans, par un message d’erreur.

On peut faire ce relevé avec vous : quels modèles tournent dans vos workflows, lesquels ont une date de retrait, et le test de bascule sur vos cas réels avant janvier.

Faire l'inventaire →

À lire en ce moment