GPT-5.5 vient de changer ton calcul de routage de modèles

OpenAI a publié GPT-5.5 cette semaine, en le positionnant comme leur modèle le plus performant à ce jour — plus rapide, plus solide sur les tâches de code et de recherche, et conçu pour opérer à travers des outils. Pour la plupart des CTOs, le réflexe est d'y voir une question de mise à niveau. Ce n'en est pas une. C'est une invitation à réexaminer chaque décision de routage prise quand GPT-4o ou o3 définissaient le compromis qualité/prix de référence — parce que cette référence ne tient plus.

Ce qui a changé avec GPT-5.5

OpenAI décrit GPT-5.5 comme leur modèle le plus intelligent à ce jour, avec des gains notables sur les tâches complexes et multi-étapes : code, synthèse de recherche, analyse de données à travers des intégrations d'outils. L'accent mis sur le Tool Use est significatif — il ne s'agit pas simplement d'un gain sur des benchmarks en silo ; le modèle est positionné pour mieux performer à l'intérieur d'une boucle agentique avec retrieval, exécution de code ou APIs externes.

La sortie suit un rythme accéléré. GPT-4o est arrivé il y a environ 12 mois ; GPT-4.5 a été livré plus tôt cette année ; GPT-5.5 est déjà là. Ce rythme signale qu'OpenAI tourne désormais en cycle de mise à niveau continue, et non plus selon un rythme de release générationnel de 12 à 18 mois. Les équipes qui ont gravé leurs décisions de routage dans l'infrastructure et ne les ont pas rebenchmarkées depuis GPT-4o devraient traiter cet écart comme une dette technique qui s'accumule activement.

Les détails de tarification au moment de la publication sont disponibles dans la documentation de l'API OpenAI, mais le schéma des releases précédentes se répète : les capacités flagship viennent à un coût par token élevé, tandis que les anciens flagships sont repositionnés en milieu de gamme. Ce repositionnement, c'est là que le calcul de routage devient intéressant.

Pourquoi cela remet à zéro le calcul de ton stack actuel

La plupart des stacks d'IA en production ne tournent pas sur un seul modèle — ils tournent sur une couche de routage, même informelle. Une tâche de classification va vers un modèle plus rapide et moins coûteux. Un résumé côté client va vers quelque chose de milieu de gamme. Une revue de contrat ou une génération de code complexe va vers le flagship. Ce découpage avait du sens quand l'écart de capacité entre GPT-4o et un modèle plus petit justifiait le delta de coût. GPT-5.5 déplace deux choses simultanément : ce que le flagship peut faire, et ce que coûte désormais l'ancien flagship.

Ce que la plupart des analyses ratent, c'est le risque de régression au niveau du prompt. Les prompts ajustés pour le comportement de GPT-4o — sa verbosité, sa tendance à nuancer, sa façon de gérer les instructions ambiguës — peuvent produire des sorties différentes sur GPT-5.5, même sur des tâches où la qualité s'améliore nominalement. Si tes evals ont été écrites contre des sorties GPT-4o, un score BLEU plus élevé ou une meilleure note LLM-as-judge ne garantit pas que ton application en aval se comporte comme prévu. Tu dois re-exécuter ta suite d'evals sur des inputs de production représentatifs avant de router du trafic réel.

Il y a aussi un effet de seuil sur les workloads agentiques. Si tu as des agents qui appellent aujourd'hui GPT-4o pour les décisions de Tool Use et basculent vers un modèle moins cher pour la synthèse, les gains annoncés de GPT-5.5 sur le Tool Use multi-étapes pourraient permettre de consolider — moins de sauts, moins de Latency, potentiellement un coût total plus bas même à un tarif par token plus élevé. C'est l'arbitrage qui vaut la peine d'être modélisé cette semaine.

Talk to Domani AI about building this →

Ce qu'un CTO devrait faire avant vendredi

Les 4 heures les plus utiles que tu puisses passer cette semaine : mener un audit structuré de prompts sur GPT-5.5 pour tes 10 templates de prompts les plus critiques en production. Pas une impression à la volée — une eval scorée avec la même grille que ton équipe utilise déjà pour la qualité des sorties. L'objectif est une matrice de décision de routage : les tâches où GPT-5.5 surpasse clairement ton modèle actuel à un coût acceptable, celles où il est équivalent (tenir la ligne, économiser les tokens), et celles où le changement de comportement crée un risque de régression à traiter avant toute migration.

Si tu n'as pas de suite d'evals formelle, c'est ça, le vrai chantier du lundi — pas la mise à niveau du modèle. Un workload d'IA en production sans evals scorées, c'est piloter sans instruments. GPT-5.5 est un bon déclencheur pour corriger ça, parce que le prochain flagship arrivera avant la fin de l'année et le problème se cumule.

Étapes concrètes pour la semaine :

• Extrais tes 10 templates de prompts de production les plus utilisés depuis les logs, par volume d'appels ou criticité métier — pas selon ton intuition de ce qui compte
• Fais tourner chacun sur ton modèle actuel et sur GPT-5.5 avec des inputs identiques ; score les sorties sur ta grille existante (ou construis une grille à 3 points en 30 minutes si tu n'en as pas)
• Signale chaque sortie où GPT-5.5 modifie la structure ou le format d'une façon dont dépend ton parsing en aval — ce sont tes risques de régression
• Modélise le delta de coût en tokens pour chaque workload au volume de trafic actuel ; identifie les 2 à 3 workloads où consolider vers GPT-5.5 améliore à la fois la qualité et l'économie
• Prends une décision de routage — n'essaie pas de tout migrer ; valide le processus sur un seul workload d'abord

Ce que ça coûte, et où ça économise

Le compromis honnête : migrer vers un nouveau modèle flagship en milieu de cycle coûte du temps d'ingénierie que tu n'as probablement pas budgété — 2 à 4 jours pour un passage eval-et-routage rigoureux sur un stack de taille moyenne, davantage si ta couche de prompts est enchevêtrée avec la logique applicative plutôt que clairement abstraite. Si tu repousses de 6 semaines, tu rates la fenêtre pour capturer l'arbitrage de coût lié au repositionnement de GPT-4o en milieu de gamme, et tes agents continuent de tourner sur un modèle désormais une génération en retard sur les performances de Tool Use.

L'économie se fait précisément sur les workloads agentiques. Si GPT-5.5 réduit le nombre d'appels de modèle nécessaires par tâche agent — moins de fallbacks, moins de boucles de clarification — le coût par tâche peut baisser même si le tarif par token augmente. Ce calcul est spécifique à chaque workload et tu ne le connaîtras pas avant d'avoir fait l'audit. Le risque de ne pas le faire : un concurrent qui le fait aura des coûts d'Inference plus bas et des temps de réponse plus rapides sur la même classe de tâche d'ici le T3.