Revue de GPT-6 Astra : je l’ai mis au travail sur un vrai CRM

Ma première revue de GPT-6 Astra a commencé avec un tableau de bord CRM qui ne se chargeait pas correctement. Je voulais que l’agent trouve la cause, la corrige et montre que la page fonctionnait. Cela semblait être une bonne façon de passer la soirée avec un nouveau modèle.

Le travail a produit trois corrections concrètes : des valeurs d’installation par défaut manquantes, des paramètres qui n’enregistraient pas les utilisateurs sélectionnés et le chargement des données perturbé par des alias de modèles incohérents. Le tableau de bord s’est ensuite ouvert dans un environnement de test local.

C’est suffisant pour m’intéresser au sujet. Ce n’est pas suffisant pour déclarer obsolète tout autre modèle de codage.

Il s’agit d’un premier retour pratique, accompagné de résultats de benchmarks indépendants et des premières impressions d’autres développeurs. Les recherches reflètent la période du 3 au 4 septembre 2026. Les modifications du CRM décrites ici étaient locales et non validées au moment du test ; elles ne constituaient pas une mise en production.

Pour quoi GPT-6 Astra est-il conçu ?

OpenAI présente Astra comme un modèle destiné aux tâches exigeantes dans le code, les navigateurs, les documents et d’autres logiciels. Le modèle API est `gpt-6-astra`, avec une fenêtre de contexte de 1 050 000 tokens et la prise en charge des entrées d’image. Ses nouvelles capacités comprennent les appels d’outils asynchrones et l’envoi d’instructions pendant l’exécution d’une tâche. Documentation des modèles OpenAI, Guide Astra.

Pour moi, le test intéressant consiste à déterminer si ces capacités sont utiles dans un système existant. Un CRM fonctionnel comporte des permissions, d’anciennes hypothèses, des intégrations incomplètes et des utilisateurs qui s’attendent à ce que les fonctionnalités d’hier continuent de fonctionner. Générer un composant propre n’est qu’une partie de ce travail.

Ma revue de GPT-6 Astra : trois corrections dans un vrai CRM

J’ai utilisé une session Codex pilotée par Astra pour examiner un tableau de bord de travail quotidien dans une installation de Perfex CRM. Le module existait déjà. Astra n’a pas construit l’ensemble du CRM, et les travaux précédents sur le projet avaient impliqué d’autres modèles.

Le premier problème se trouvait dans l’installation. Le module vérifiait l’absence de paramètres en utilisant la mauvaise valeur de retour. Il pouvait donc ignorer des valeurs par défaut nécessaires. La correction a utilisé la fonction existante et répétable de la plateforme pour créer les options.

Le deuxième problème se trouvait dans l’écran des paramètres. Son script s’exécutait avant que jQuery soit disponible ; les utilisateurs pilotes sélectionnés n’étaient donc pas transmis aux champs envoyés par le formulaire. Attendre que la page soit prête a corrigé ce chemin.

Le troisième problème concernait les alias des modèles de base de données. Certaines parties du module chargeaient un modèle sous un nom et tentaient d’y accéder sous un autre. Des alias explicites ont corrigé cette incohérence. Il s’agissait de modèles applicatifs, et non de modèles AI.

Des tests de régression ont été ajoutés autour de ces trois modes de défaillance. La session a également vérifié le tableau de bord authentifié, l’historique et le calendrier à venir dans une copie isolée de la base de données locale.

L’aspect le plus utile était le lien entre les symptômes et les corrections. L’installation, le comportement du formulaire et le chargement côté serveur nécessitaient chacun une vérification différente. Une simple capture d’écran d’une page rendue n’aurait pas expliqué pourquoi elle avait échoué.

Certaines sources de données connectées signalaient encore des avertissements par la suite, et les suggestions de croissance restaient bloquées. Je considère cela comme un travail d’intégration inachevé, et non comme la preuve que tout était prêt pour le lancement.

Je ne peux pas non plus transformer cette session en comparaison de vitesse. Je n’ai pas exécuté les mêmes tâches avec un autre modèle, dans le même état initial et avec le même budget de temps. Mon guide pour évaluer les modèles AI sur un travail réel décrit la comparaison que je souhaiterais effectuer avant de tirer cette conclusion.

Ce que d’autres développeurs disent d’Astra

Le retour de Claire Vo sur l’accès anticipé décrit des progrès sur des projets de codage qui avaient résisté à de précédentes tentatives avec Sol et Fable. Ses exemples comprennent une fonctionnalité d’intelligence produit, l’assurance qualité dans le navigateur et du travail dans des outils créatifs. L’aspect des tests dans le navigateur est particulièrement pertinent par rapport à mon expérience : écrire une correction et vérifier son comportement doivent faire partie du même flux de travail. Il s’agit de ses expériences rapportées, et non d’une comparaison contrôlée. Revue pratique de Claire Vo.

La première revue de Matt Shumer met en avant l’ingénierie backend, la continuité dans les longues conversations et des mises à jour de progression plus claires. Il mentionne également des inconvénients : Astra peut être plus lent qu’il ne le souhaiterait, et il préfère toujours le goût visuel et la création d’éléments graphiques de Claude. Il indique utiliser le raisonnement Medium pour le travail quotidien et Ultra pour les expériences plus importantes. C’est un point de départ utile à tester, et non un réglage universel. Revue de Matt Shumer.

La réaction de la communauté est moins uniforme. Une discussion sur r/codex affirme que l’automatisation et l’efficacité comptent davantage que le label GPT-6, tout en se demandant si les benchmarks justifient l’enthousiasme suscité par le lancement. Je considérerais cela comme un échantillon du débat, et non comme une enquête auprès des développeurs. Discussion de la communauté.

Benchmarks d’Astra : lisez aussi la colonne des coûts

Artificial Analysis rapporte les résultats de lancement suivants :

Il s’agit de points d’indice, et non de pourcentages de réussite des tâches. La comparaison de codage évalue Astra et Sol dans Codex, et Fable dans Claude Code ; elle compare donc des configurations modèle-outil plutôt que d’isoler les modèles.

À effort maximal, Astra a utilisé environ un tiers des tokens de Sol dans l’évaluation de codage et a coûté à peu près le même prix par tâche. Le Intelligence Index plus large raconte une histoire différente : des performances globales similaires à celles de Sol, mais un coût par tâche environ 75 % plus élevé. L’efficacité dépend de la charge de travail. Méthodologie et résultats d’Artificial Analysis.

Pour une équipe qui décide où consacrer son budget, je mesurerais la quantité de vérification et de reprise nécessaire après l’arrêt de l’agent. Une réponse plus courte n’est utile que si le travail est correct. Une exécution plus longue peut être rentable si elle résout un problème difficile, mais la durée seule ne prouve rien.

Cinq conseils pour obtenir un travail utile d’Astra

1. Définissez ce que signifie « terminé »

Décrivez l’échec et un test d’acceptation observable. Demandez une reproduction, une correction ciblée et une vérification du parcours utilisateur concerné.

2. Indiquez clairement ses permissions

Astra peut s’arrêter pour demander des précisions. Précisez les actions locales qu’il est autorisé à effectuer. Gardez le déploiement et les messages externes derrière une approbation distincte.

3. Gardez les instructions du projet cohérentes

Auditez `AGENTS.md` et les skills pertinents. OpenAI avertit que des instructions contradictoires peuvent interrompre la progression. Supprimez les règles obsolètes ou contradictoires.

4. Adaptez les tests à la modification

Demandez des vérifications capables de détecter l’échec réel. Astra peut élargir excessivement les tests sur les petites tâches ; les vérifications supplémentaires doivent répondre à des questions non résolues.

5. Donnez une mission précise aux réviseurs

Pour les modifications risquées, attribuez à un réviseur les permissions, la gestion des échecs ou les régressions. Expliquez quand déléguer ; Astra peut le faire moins souvent que prévu. Conseils officiels de prompting.

Mon flux de revue de code multi-agent sépare la revue indépendante de l’auteur final. J’utiliserais cette structure pour une modification importante, plutôt que de demander à plusieurs agents de modifier les mêmes fichiers simultanément.

Où j’utiliserais Astra ensuite

Mes prochains tests porteraient sur des bugs backend répartis sur plusieurs couches, des problèmes d’intégration aux symptômes trompeurs et des vérifications dans le navigateur après une modification du code. Ce sont des tests utiles des points forts décrits par les premiers évaluateurs.

Je conserverais une comparaison distincte pour le design visuel. Je comparerais également le coût des tâches terminées avant de confier le travail courant à un modèle plus coûteux.

La session CRM m’a donné une raison concrète de continuer à tester Astra : trois échecs ont été compris et corrigés, tandis que les problèmes d’intégration restants sont restés visibles. Je veux un agent capable de faire cette distinction. L’ouverture réussie d’un tableau de bord local est un progrès. Une fonctionnalité révisée et déployée avec des intégrations saines est une étape différente.

*Divulgation : cet article a été préparé avec l’aide de AI à partir d’une revue de mes modifications Git, des enregistrements de session et des sources liées. L’image principale est une illustration éditoriale, et non une capture d’écran du CRM.*