Les itinéraires de course de GPT-6 Astra ont fonctionné, mais le code a disparu

GPT-6 Astra a passé 27 minutes à générer des itinéraires de course depuis le domicile de Simon Willison, puis a livré des cartes et des fichiers téléchargeables correspondant à sa demande. Ce résultat concluant a rendu l’absence de preuves encore plus frappante. ChatGPT Work lui a montré l’itinéraire final, mais pas le code Python ni l’historique complet d’exécution qui le sous-tendaient.

Willison avait demandé des boucles de 5 km et 10 km commençant et se terminant à son adresse. Il avait demandé à ChatGPT Work d’utiliser les données d’OpenStreetMap. Selon son récit sur les itinéraires de course, l’agent a renvoyé une visualisation intégrée, des téléchargements GPX et des fichiers GeoJSON.

La tâche constitue un exemple inhabituellement concret de l’utilité de l’IA agentique au-delà du travail de bureau classique. Elle réunissait le géocodage, la récupération de données cartographiques, l’analyse de graphes, la sélection d’itinéraires, la génération de fichiers et la visualisation au sein d’une seule conversation.

Pourtant, le résultat a aussi révélé un conflit au cœur des agents d’IA. Un système peut achever une tâche difficile tout en empêchant son utilisateur de reconstituer la manière dont il est parvenu à la réponse.

Ce conflit importe davantage que l’itinéraire lui-même. OpenAI présente GPT-6 Astra comme un modèle destiné au travail informatique prolongé, où les utilisateurs délèguent des objectifs complexes plutôt que de demander des réponses isolées. Cette délégation accroît la valeur des journaux d’exécution, des fichiers intermédiaires et du code reproductible.

L’exemple des itinéraires de course de GPT-6 Astra teste donc simultanément deux promesses. Astra semble capable d’accomplir un flux de travail géospatial spécialisé. ChatGPT Work semble moins préparé à conserver ensuite les éléments nécessaires pour examiner ce flux de travail.

Les itinéraires de course de GPT-6 Astra ont réuni plusieurs outils en un seul résultat

Le changement important n’était pas qu’une IA suggère un parcours de jogging, mais qu’elle ait assemblé un livrable géospatial utilisable à partir d’une brève demande.

Willison a demandé au système de localiser son adresse et de calculer deux boucles à partir de données OpenStreetMap. Une boucle devait commencer et se terminer au même endroit tout en restant raisonnablement proche d’une distance cible.

C’est plus difficile que de demander à un service de cartographie des itinéraires entre deux points fixes. L’agent devait d’abord obtenir une coordonnée géographique de départ. Il devait ensuite disposer d’un réseau local de routes et de sentiers qu’un coureur pourrait emprunter.

ChatGPT a ensuite indiqué à Willison avoir utilisé Nominatim pour localiser l’adresse. Nominatim est un géocodeur, c’est-à-dire qu’il convertit un lieu ou une adresse écrite en coordonnées géographiques.

Le système a déclaré avoir utilisé Overpass pour télécharger les routes et sentiers OpenStreetMap à proximité. L’API Overpass permet d’effectuer des requêtes structurées sur les données OpenStreetMap, notamment sur les éléments géographiques et leurs balises descriptives.

Le travail restant aurait été réalisé localement. L’agent devait transformer les éléments cartographiques en réseau connecté, identifier des boucles candidates, estimer leurs longueurs et sélectionner des itinéraires proches de cinq et dix kilomètres.

Willison n’a pas reçu l’implémentation ; ces étapes algorithmiques précises restent donc une reconstitution éclairée. La brève explication de l’agent n’indiquait ni sa bibliothèque de graphes, ni sa méthode de recherche, ni ses règles d’évaluation des itinéraires, ni sa logique de filtrage.

Les résultats visibles étaient plus concrets. ChatGPT Work a généré une boucle portuaire de 5,1 kilomètres et l’a affichée dans la conversation. Il a également fourni des fichiers GPX et GeoJSON, deux formats courants d’échange de géométries d’itinéraires.

GPX est un format basé sur XML pris en charge par de nombreux appareils de fitness et applications cartographiques. GeoJSON représente les éléments géographiques à l’aide de JSON, ce qui le rend pratique pour les cartes web et les pipelines logiciels.

La carte intégrée était elle-même un artefact généré. Willison a constaté que ChatGPT avait créé un fichier HTML contenant la géométrie de l’itinéraire et du JavaScript qui rendait la visualisation avec D3.

Le HTML stockait la géométrie dans un élément de données de l’application. Cela signifiait que l’itinéraire affiché n’était pas une simple capture d’écran statique. Il contenait des coordonnées que des logiciels pouvaient lire et redessiner.

Cette combinaison importe car elle franchit la frontière entre une réponse et un livrable achevé. Une liste de noms de rues exigerait encore beaucoup de travail avant qu’un coureur puisse l’utiliser.

Les fichiers générés pouvaient être importés ailleurs, inspectés ou transférés vers des appareils compatibles. La carte permettait à l’utilisateur de vérifier immédiatement le résultat visuellement sans nécessiter une autre application.

OpenAI décrit ChatGPT Work comme un agent destiné aux tâches longues et en plusieurs étapes, ainsi qu’aux livrables finalisés. Sa documentation Work actuelle distingue cette expérience de l’assistance conversationnelle ordinaire.

La tâche d’itinéraire correspond étroitement à cette définition. Elle a commencé par un objectif exprimé en langage naturel, utilisé des données externes, réalisé des calculs locaux et renvoyé plusieurs résultats coordonnés.

Cependant, une réussite à ce niveau modifie les attentes des utilisateurs envers l’interface. Lorsqu’un agent effectue des calculs significatifs, son processus devient une partie du produit, et non une activité de fond jetable.

Pourquoi cette petite tâche cartographique importe

L’itinéraire est une démonstration compacte de la façon dont les agents d’IA peuvent transformer des flux de travail spécialisés en demandes ordinaires.

Construire manuellement un tel itinéraire nécessiterait généralement plusieurs outils. Un utilisateur pourrait géocoder une adresse, télécharger des données cartographiques, configurer un logiciel de routage, examiner des parcours candidats et exporter la géométrie choisie.

Chaque étape exige une forme de connaissance différente. Le géocodage suppose de connaître les services de recherche de lieux. L’extraction de données OpenStreetMap nécessite une syntaxe de requête ou une interface adaptée.

Le calcul d’itinéraire introduit des concepts de graphes tels que les nœuds, les arêtes, les poids de chemin et la connectivité. L’exportation de fichiers exige de connaître les formats acceptés par les applications de fitness et de cartographie.

ChatGPT Work aurait coordonné ces composantes sans demander à Willison de superviser chaque choix technique. L’interface lui permettait de décrire le résultat recherché plutôt que de prescrire une implémentation complète.

C’est la proposition de valeur centrale d’un agent généraliste. Il peut sélectionner et combiner des outils en fonction d’un objectif, plutôt que de limiter l’utilisateur à un flux de travail prédéterminé.

Le moment est également significatif. OpenAI a présenté Astra en mettant l’accent sur le codage, la navigation web, l’utilisation d’ordinateurs et le travail professionnel complexe. Sa page de lancement d’Astra présente le modèle comme capable de produire des fichiers, des graphiques, des sites web et d’autres artefacts finalisés.

OpenAI indique qu’Astra a obtenu 72,6 % dans sa configuration OSWorld 2.0 citée. GPT-5.6 Sol a obtenu 65,7 % dans la même configuration rapportée.

L’entreprise indique également qu’Astra a achevé ces tâches informatiques simulées en environ 40 minutes, contre environ 75 minutes pour GPT-5.6 Sol. Il s’agit toujours de résultats de référence rapportés par l’entreprise, et non d’une validation indépendante de l’itinéraire de Willison.

Néanmoins, la tâche de course de 27 minutes donne une forme reconnaissable à ces affirmations plus larges. Le modèle ne s’est pas contenté d’utiliser un site web connu ou de remplir des champs dans un formulaire standard.

Il aurait improvisé un flux de travail autour d’une infrastructure géographique ouverte. Il a choisi des services, téléchargé des données, exécuté des calculs, créé des fichiers portables et construit une couche de présentation personnalisée.

Cette flexibilité met sous pression deux catégories de logiciels. La première regroupe les outils grand public spécialisés, construits autour d’interfaces fixes de planification d’itinéraires.

Un agent généraliste n’a pas besoin de remplacer complètement ces produits. Il peut plutôt prendre en charge des demandes inhabituelles que les interfaces rigides ont du mal à exprimer.

Un coureur pourrait demander une boucle proche d’une distance précise, éviter une route particulière, privilégier les sentiers, passer par une fontaine à eau ou terminer avant le coucher du soleil. Le langage naturel peut facilement combiner ces contraintes.

La deuxième catégorie mise sous pression est le chatbot traditionnel lui-même. Une fois que les utilisateurs voient un agent accomplir un tel travail, une réponse uniquement textuelle commence à sembler incomplète.

Ils attendent des fichiers générés, des vues interactives, des calculs modifiables et un relevé des étapes effectuées. Le livrable devient la norme à l’aune de laquelle la conversation est jugée.

Les notes de version d’OpenAI de septembre décrivent Astra comme une amélioration pour le travail en plusieurs étapes. Elles indiquent également que ChatGPT Work peut utiliser des fichiers locaux et des outils de sites web pris en charge avec autorisation.

L’exemple de l’itinéraire suggère que ces capacités peuvent s’étendre au-delà des documents de bureau. Elles peuvent soutenir des projets personnels assortis d’exigences techniques qui nécessitaient auparavant des logiciels sur mesure.

Cela ne rend pas automatiquement le résultat digne de confiance. Cela rend la vérification plus importante, car l’agent peut désormais produire des artefacts qui semblent assez complets pour être utilisés immédiatement.

Le principal conflit oppose les capacités à l’auditabilité

ChatGPT Work a accompli le travail demandé, mais n’a pas conservé suffisamment d’éléments visibles pour que l’utilisateur puisse reproduire le résultat.

Willison a demandé comment l’itinéraire avait été créé après avoir reçu les livrables. ChatGPT a fourni l’explication générale impliquant Nominatim, Overpass et des calculs locaux.

Cette explication identifiait la vaste architecture. Elle ne révélait pas quels points de terminaison de services avaient été contactés, quelles requêtes avaient été soumises, ni quelles balises cartographiques avaient été considérées comme adaptées à la course.

Elle ne révélait pas non plus comment les boucles candidates avaient été générées. Un script de routage peut utiliser des recherches de plus courts chemins, un échantillonnage de points de passage, une détection de cycles, une optimisation ou plusieurs méthodes combinées.

Ces choix influencent l’itinéraire final. Ils peuvent déterminer si le système privilégie les routes goudronnées, les sentiers côtiers, les traversées, les segments escarpés ou les chemins dont les informations d’accès sont incomplètes.

Willison a ensuite demandé le code Python. ChatGPT ne pouvait plus le fournir, apparemment parce que la conversation avait fait l’objet d’une compaction.

La compaction condense le contexte antérieur afin qu’un agent fonctionnant sur une longue durée puisse continuer dans les limites de sa fenêtre de contexte disponible. Elle peut aider le système à rester opérationnel, mais certains détails peuvent disparaître du contexte actif.

Willison a soutenu que les systèmes recourant à la compaction devraient conserver les éléments d’origine. Il souhaite aussi que les agents puissent récupérer ces éléments au moyen d’outils lorsqu’une demande ultérieure l’exige.

Sa critique identifie un problème d’interface plutôt qu’un problème d’intelligence du modèle. Le système a peut-être produit un code fiable tout en échouant à fournir un relevé adéquat.

Cette distinction est essentielle. La capacité du modèle répond à la question de savoir si un agent peut accomplir une tâche. L’auditabilité répond à la question de savoir si une personne peut comprendre, vérifier, reproduire ou contester cette exécution.

Pour une idéation informelle, un résumé concis du processus peut suffire. Pour des itinéraires générés, des calculs financiers, des jeux de données de recherche ou des fichiers professionnels, ce n’est souvent pas le cas.

Une piste d’audit utile n’exige pas d’exposer le raisonnement interne privé. Elle peut être constituée de preuves opérationnelles propres à la tâche.

Ces éléments pourraient inclure les scripts générés, les commandes de terminal, les URL des sources de données, les horodatages, les réponses des outils, les avertissements, les fichiers intermédiaires et les versions des bibliothèques pertinentes.

Ces enregistrements diffèrent du raisonnement interne caché. Ils documentent des actions et transformations observables, à la manière dont un journal de compilation documente la production d’un logiciel.

Le HTML de l’itinéraire a survécu parce qu’il faisait partie du livrable final. L’implémentation Python n’a pas survécu, alors qu’elle était sans doute plus importante pour la vérification.

Cette asymétrie encourage les utilisateurs à faire davantage confiance à la présentation qu’à la provenance. Une carte soignée peut paraître faisant autorité tout en dissimulant des hypothèses qui influencent matériellement la sécurité et l’exactitude.

Le problème devient plus aigu lorsqu’un agent travaille pendant 27 minutes. Une tâche plus longue peut impliquer davantage d’état, d’appels d’outils, de décisions intermédiaires et d’occasions d’échec silencieux.

Les utilisateurs ne devraient pas avoir à prédire quel artefact ils souhaiteront consulter plus tard. Le système devrait conserver un dossier de tâche structuré avant que la compression du contexte ne supprime des détails importants.

Un dossier robuste relierait chaque résultat à son origine. Le fichier GPX devrait être associé au script exact, aux données source, aux paramètres et à l’exécution qui l’ont produit.

Cela ressemble à la gestion d’un workflow IA avec des entrées et sorties traçables. Le sujet diffère, mais le principe de tenue des registres reste le même.

L’opposition fondamentale dans cette histoire est donc celle entre capacité et auditabilité. Astra a fourni un résultat impressionnant, tandis que le produit qui l’entoure n’a pas permis d’examiner pleinement ce résultat.

OpenStreetMap soulève des questions de politique et de sécurité

Un itinéraire peut être techniquement valide tout en restant inadapté, dangereux ou incompatible avec les politiques qui régissent ses sources de données.

Le résultat généré s’appuyait sur OpenStreetMap, une base de données géographique collaborative dont la couverture et le balisage varient selon les lieux. Son ouverture permet des workflows inhabituels, mais elle n’élimine pas l’incertitude.

Une route ou un sentier peut exister dans la base de données sans convenir à tous les coureurs. Les restrictions d’accès, fermetures temporaires, conditions de surface, éclairage, traversées, travaux et dangers locaux peuvent être absents ou obsolètes.

Un calcul sur graphe peut également produire une boucle connectée qui paraît cohérente à l’écran, mais se révèle peu satisfaisante sur le terrain. La connectivité seule ne garantit ni le confort ni la sécurité.

Le code source manquant empêche les personnes extérieures de vérifier comment l’agent a traité ces facteurs. On ignore quelles catégories de voies étaient autorisées ou si les balises d’accès privé ont été exclues.

On ignore également si l’agent a identifié les trottoirs, restrictions piétonnes, surfaces non revêtues, escaliers, liaisons par ferry ou sections de sentier à accès limité.

Willison a indiqué que le système avait produit exactement ce qu’il avait demandé. Il s’agit d’un témoignage direct utile sur l’exécution de la tâche, mais pas d’une validation complète de la qualité de l’itinéraire.

L’exemple ne porte que sur un utilisateur, une zone et une paire de distances demandées. L’article n’a rapporté ni test sur le terrain, ni analyse du dénivelé, ni examen de l’accessibilité, ni comparaison indépendante.

L’étape de géocodage soulève une autre préoccupation, car une adresse personnelle exacte constitue une information sensible. Les utilisateurs devraient comprendre où un agent envoie cette adresse et quels journaux peuvent la conserver.

OpenAI indique que Work peut utiliser des fichiers, la navigation et le contexte de la tâche conformément aux autorisations de l’environnement sélectionné. Les comptes gérés peuvent également être soumis aux paramètres de conservation et de gouvernance de l’organisation.

Le récit de l’itinéraire cité ne permet pas d’établir quel déploiement Nominatim l’agent a contacté. Il ne peut donc pas confirmer quels journaux, limites ou pratiques de conservation s’appliquaient à cette requête.

Si l’agent a utilisé le service public de l’OpenStreetMap Foundation, la politique Nominatim entrerait en jeu. Cette politique limite les usages intensifs et exige des requêtes identifiables ainsi qu’une attribution appropriée.

La politique impose également des restrictions aux services génériques de géocodage générés automatiquement. Une recherche personnelle diffère du déploiement d’un produit de routage grand public, mais les agents doivent distinguer ces cas.

Overpass soulève des considérations opérationnelles similaires. Ses serveurs publics prennent en charge de petits projets, mais peuvent être surchargés, selon les recommandations Overpass.

Ces recommandations encouragent les utilisateurs réguliers ou commerciaux à mettre les requêtes en cache, réduire leur consommation, utiliser des extraits ou exploiter une infrastructure adaptée. Les points de terminaison publics sont des ressources partagées, pas des backends d’agents illimités.

Un registre d’exécution auditable aiderait à résoudre ces questions. Il pourrait afficher les points de terminaison exacts, les en-têtes de requête, le nombre de requêtes, l’attribution et la taille des réponses.

Sans ce registre, l’utilisateur ne peut pas confirmer que l’agent a respecté les politiques de service applicables. Les fichiers finaux fournissent peu d’éléments sur la manière dont les données ont été acquises.

La sécurité exige également de présenter les itinéraires comme des suggestions, et non comme des instructions vérifiées. Un coureur devrait examiner les segments inconnus et tenir compte des conditions locales actuelles avant de se fier à une boucle générée automatiquement.

Le système devrait exposer les hypothèses de l’itinéraire en langage clair. Il pourrait indiquer qu’il a exclu les routes privées, privilégié les chemins piétons, accepté les sentiers non revêtus et ne disposait pas de données actualisées sur les fermetures.

Ces informations ne sont pas de simples avertissements décoratifs. Elles aident les utilisateurs à déterminer si le résultat répond à leurs besoins et si des vérifications supplémentaires sont nécessaires.

Un agent de génération d’itinéraires doit également pouvoir signaler l’incertitude. Si les balises cartographiques sont contradictoires ou si le statut d’accès à un sentier est incertain, cette ambiguïté devrait apparaître dans le livrable final.

Le résultat d’Astra montre que les données cartographiques ouvertes peuvent prendre en charge des tâches personnelles sophistiquées. La trace manquante montre pourquoi l’accès à des données ouvertes ne remplace pas une exécution transparente.

Ce qu’un travail d’agent transparent devrait conserver

Le prochain test pour ChatGPT Work sera de savoir si les tâches réussies deviennent des dossiers de projet reproductibles plutôt que des conversations jetables.

Le signal le plus immédiat sera un accès persistant au code et aux commandes générés. Les utilisateurs devraient pouvoir rouvrir une tâche terminée et récupérer chaque artefact créé durant son exécution.

Cela ne nécessite pas d’afficher en permanence la sortie du terminal par défaut. Une interface compacte pourrait montrer d’abord le résultat tout en conservant un registre d’activité complet derrière un contrôle d’inspection.

Le deuxième signal sera la provenance associée à chaque livrable. Un fichier devrait identifier les entrées, outils, transformations et avertissements liés à sa création.

Pour la tâche d’itinéraires de course GPT-6 Astra, la provenance relierait les fichiers GPX et GeoJSON au même calcul d’itinéraire. Elle conserverait également la requête OSM pertinente et le script Python généré.

Le troisième signal sera une meilleure gestion de la compression du contexte. Une conversation compactée devrait conserver une archive récupérable, même lorsque le modèle ne retient plus activement chaque détail.

L’agent pourrait rechercher dans cette archive lorsqu’un utilisateur demande ce qui s’est passé plus tôt. Cela séparerait un contexte actif efficace d’un historique durable de la tâche.

Ces changements renforceraient les affirmations de transparence d’OpenAI sans exposer le raisonnement privé du modèle. OpenAI indique qu’Astra met l’accent sur l’alignement, les limites de la tâche et un comportement plus clair pendant le travail délégué.

Des registres opérationnels rendraient ces affirmations vérifiables au niveau du produit. Les utilisateurs pourraient examiner si un agent est resté dans le périmètre prévu au lieu de se fier uniquement à son résumé.

Les concurrents qui développent des agents généralistes font face au même défi. La rapidité d’exécution et de meilleurs scores aux benchmarks compteront moins lorsque les utilisateurs ne pourront pas vérifier des résultats critiques pour leur activité.

Les développeurs attendent déjà des environnements reproductibles, des historiques de versions et des journaux. Les travailleurs du savoir développeront des attentes similaires lorsque les agents commenceront à produire des analyses, présentations, jeux de données et changements opérationnels.

L’interface devrait également permettre aux utilisateurs d’exporter un dossier complet de tâche. Ce dossier pourrait contenir le prompt, les autorisations approuvées, les scripts, les journaux, les références sources, les artefacts et un résumé concis de l’exécution.

Un dossier partageable améliorerait la collaboration. Un collègue pourrait examiner la méthode sans reconstruire l’intégralité de la conversation ni faire confiance à une capture d’écran.

Il faciliterait également les corrections. Si un itinéraire incluait un sentier inadapté, l’utilisateur pourrait identifier la règle responsable et relancer le workflow avec une contrainte révisée.

Des registres persistants rendraient le travail des agents cumulatif. Un itinéraire 5K réussi pourrait devenir le point de départ de demandes ultérieures concernant les côtes, les surfaces, l’éclairage ou les fermetures saisonnières.

Sans ces registres, chaque suivi risque de devenir une nouvelle inférence. L’agent pourrait générer une méthode différente tout en la présentant comme une continuation de la tâche initiale.

La réussite sous-jacente ne devrait pas être minimisée. Une courte instruction en langage naturel a produit deux distances de boucle, une carte interactive et des fichiers géospatiaux portables en 27 minutes.

Il s’agit d’un exemple crédible d’agent généraliste coordonnant des outils pour un objectif personnel précis. Il illustre pourquoi les livrables terminés peuvent compter davantage que des réponses fluides.

Ce cas montre aussi que la qualité du résultat ne peut pas être la seule mesure de succès. Les utilisateurs ont besoin de preuves durables lorsque le processus d’un agent affecte la fiabilité, la sécurité ou la légalité de son travail.

Les futurs itinéraires de course GPT-6 Astra devraient donc être jugés selon deux résultats. L’itinéraire répondait-il à la demande, et l’utilisateur peut-il reconstruire exactement la manière dont il a été produit ?

Si OpenAI ajoute des historiques d’exécution durables, une provenance des artefacts et des registres récupérables avant compression, cet exemple apparaîtra comme une lacune initiale du produit. Dans le cas contraire, le travail caché deviendra un risque plus important à mesure que les agents prendront en charge des tâches à plus forts enjeux.

La réponse pratique consiste à demander des preuves tant que la tâche est encore active. Demandez le script, les points de terminaison sources, les hypothèses, les fichiers intermédiaires et les notes de vérification en même temps que le livrable final.

Cette habitude ne devrait pas rester nécessaire indéfiniment. Une interface d’agent mature devrait conserver ces éléments automatiquement et laisser l’utilisateur décider quand les examiner.

L’itinéraire a fonctionné. La prochaine étape consiste à rendre le travail qui le sous-tend aussi portable, vérifiable et durable que le fichier GPX lui-même.