Un nouveau modèle arrive. Les graphiques montent. Les démonstrations impressionnent. Et, assez vite, la même question revient : est-ce que cela va vraiment changer quelque chose dans mes projets ?
Avec GPT-6 Astra, c’est cette question qui m’intéresse.
Dans mon article sur le vibe coding, je parlais déjà de la manière de guider l’IA avec du contexte, des étapes claires et des vérifications. Gardons ce point de départ. Ici, le sujet est différent : ce qu’Astra apporte face à GPT-5.6 Sol, et ce que ces progrès peuvent changer dans un projet réel.
Ce qui progresse face à GPT-5.6 Sol
OpenAI annonce Astra et publie notamment ces résultats :
| Évaluation | GPT-5.6 Sol | GPT-6 Astra |
|---|---|---|
| Terminal-Bench 4.0 | 37,3 % | 57,9 % |
| DeepSWE v1.1 | 72,7 % | 74,1 % |
| Migrations de bases de données — test interne | 42,7 % | 63,9 % |
Ces scores viennent d’OpenAI, dans ses conditions d’évaluation. Le Sol comparé est celui de l’API, de Codex et de ChatGPT Work. Ils ne mesurent pas le gain de temps garanti sur ton projet. Annonce officielle
Ce tableau raconte quelque chose de plus intéressant qu’un simple « tout est meilleur ».
Sur certains tests, l’écart est marqué. Sur d’autres, il reste modeste. Il faut donc résister à deux raccourcis : penser que rien ne change, ou décider que l’ancien modèle est soudain devenu inutile.
Le résultat qui mérite un vrai essai
Pour quelqu’un qui maintient des applications métier, la ligne sur les migrations attire forcément l’attention.
Changer une structure de données ne consiste pas seulement à générer une migration. Il faut penser aux données existantes, aux anciennes versions de l’application, au déploiement et à ce qui se passera si l’on doit revenir en arrière.
Mon interprétation : c’est le genre de tâche sur lequel un modèle plus capable pourrait apporter davantage qu’une meilleure autocomplétion. Mais le score interne ne permet pas de conclure qu’Astra maîtrise déjà les contraintes de ton application Laravel.
Il donne une bonne raison de tester. Pas une raison de retirer les garde-fous.
Changer de modèle, oui. Changer sans mesurer, non.
Si GPT-5.6 Sol fonctionne déjà bien dans ton environnement, je ne commencerais pas par tout remplacer.
Je prendrais une tâche connue : un bug reproduit, une modification avec des tests existants, ou une migration préparée sur des données de test. Même besoin, mêmes contraintes, mêmes outils pour les deux modèles.
Puis je regarderais le résultat complet : la justesse du changement, les éléments oubliés, le temps de relecture, les corrections nécessaires et le coût de l’exécution.
Un modèle qui répond rapidement mais impose une longue réparation ne fait pas forcément gagner du temps. À l’inverse, une exécution plus longue peut être utile si elle laisse moins de travail derrière elle.
Et Codex dans tout cela ?
Je garde ce sujet pour un article séparé.
Le modèle et l’environnement de travail méritent chacun leur analyse. Une comparaison de capacités ne répond pas à toutes les questions sur l’interface, les permissions ou la manière de relire les changements.
C’est justement ce que les discussions autour des outils de développement m’amènent à regarder : la capacité technique compte, mais son intégration dans nos habitudes compte aussi.
Ce que j’en retiens
Astra mérite de l’attention. Pas parce qu’un nouveau numéro oblige à abandonner ce que l’on utilise déjà, mais parce que certains écarts donnent envie de réévaluer ce que l’on peut raisonnablement déléguer.
La bonne question reste très pratique : est-ce que ce modèle m’aide à livrer une meilleure solution, avec moins de friction et sans perdre la maîtrise du résultat ?
C’est dans nos projets que la réponse deviendra intéressante.