OpenAI a annoncé le 14 octobre 2026 le retrait de plusieurs modèles de la famille GPT‑4 de son API, l’interface utilisée pour intégrer l’IA dans un logiciel. L’arrêt est prévu le 14 janvier 2027. Ce n’est pas une coupure aujourd’hui, ni une nouvelle annonce sur les modèles proposés dans ChatGPT. L’échéance concerne les applications qui appellent les versions désignées par la notice.
Quels modèles sont concernés ?
- GPT‑4o : versions du 6 août et du 20 novembre 2024.
- GPT‑4o mini : version du 18 juillet 2024.
- GPT‑4.1 et GPT‑4.1 mini : versions du 14 avril 2025.
La notice inclut aussi leurs versions personnalisées par entraînement, appelées modèles fine-tunés. Elle recommande GPT‑6 Luna comme remplaçant. Elle ne vise pas toute la famille GPT‑4 sans distinction : il faut comparer le modèle réellement utilisé à cette liste.
Un remplacement recommandé n’est pas une migration terminée
La fiche officielle de Luna indique qu’il accepte du texte et des images en entrée et produit du texte. Elle mentionne les réponses structurées et l’appel de fonctions, c’est-à-dire la possibilité de demander une opération à un logiciel. Mais le fine-tuning n’est pas pris en charge. Une équipe qui a entraîné un modèle pour ses dossiers ne peut donc pas simplement refaire cet entraînement sur Luna.
Concrètement, imaginons un outil fictif qui transforme des demandes clients en fiches prêtes à traiter. Le remplacer ne consiste pas seulement à obtenir une réponse qui semble correcte. Il faut vérifier que les champs attendus sont présents, que les informations absentes ne sont pas inventées et que le logiciel sait traiter un échec. Ce sont nos recommandations de test, pas une garantie donnée par OpenAI.
Pourquoi maintenant, et qui prend le risque ?
OpenAI organise le renouvellement de son catalogue, mais la notice ne donne pas de raison spécifique à ce retrait. Notre lecture : maintenir un service fondé sur une API implique de suivre le calendrier du fournisseur, même si l’application satisfait encore ses utilisateurs. Le délai disponible doit servir à préparer et vérifier la transition, pas à supposer que deux modèles se comportent de façon identique.
Le fournisseur peut concentrer son offre sur d’autres modèles. Les développeurs peuvent saisir l’occasion de revoir leurs consignes et leurs tests. Ces avantages restent possibles, non établis par l’annonce. Le travail immédiat repose sur les équipes qui maintiennent les applications ; leurs clients risquent une interruption si une dépendance oubliée reste en place. Une petite automatisation rarement utilisée mérite donc aussi d’être recensée.
La vérification utile avant de basculer
Commencer par un inventaire des outils concernés, y compris ceux fournis par un prestataire. Pour chacun, identifier une personne responsable et quelques exemples représentatifs : une demande normale, une demande incomplète et un cas difficile. Comparer les résultats avec le fonctionnement actuel, puis mesurer le délai de réponse, le coût total et les corrections nécessaires. Prévoir un traitement manuel pour les dossiers qui ne passent pas.
Pour les modèles personnalisés, il faut examiner séparément comment conserver le comportement recherché : améliorer les instructions, apporter les documents utiles ou choisir une autre solution compatible. Ce sont des pistes à évaluer, pas des équivalents assurés du modèle existant. Avant la bascule, surveiller les précisions du fournisseur, la compatibilité des fonctions utilisées et les retours des premiers essais. La date d’arrêt est une échéance d’exploitation ; elle ne dispense pas de vérifier la qualité.
