Qu'est-ce qu'un AI Data Agent ? Comment ChatGPT traite-t-il JSON et CSV pour analyser automatiquement ?

En 2026, on peut encore lire dans une fenêtre de chat une conclusion fluide : « l'APAC a bien grandi en août, surveillez le SKU phare ». Remettre ce texte à la facturation, à un tableau de bord, ou à l'étape Agent suivante : les phrases ne suffisent plus. Fenêtre temporelle absente, définition d'indicateur absente, filtres absents : l'aval ne peut que deviner. ChatGPT traite JSON et CSV, non parce que le suffixe est joli, mais parce que la boucle d'analyse mange des tables ou des objets typés. Pour choisir un phare : Guerre des modèles 2026. Cet article n'écrit que les chemins de données déjà dans la session et l'espace de travail entreprise.

Le chat explique, le Data Agent interroge

En surface, ça n'a rien à voir. Le chat ordinaire vend l'explication et le brouillon. Le Data Agent vend « posez une question à cette table ou cette base, le système calcule ». L'écart est le même : le langage naturel n'a pas de type, et un rapport ne se referme pas avec des adjectifs.

Un nom de colonne manquant, un montant écrit « environ 90 000 », une date écrite « le mois dernier » : en aval, il faut de la regex, des retries, un filet humain. Le Data Agent range le problème dans le même genre d'interface : d'abord rendre un résultat intermédiaire recalculable, puis autoriser à côté une phrase destinée à l'humain. Pourquoi la couche objet veut encore un JSON Schema, l'article précédent Pourquoi ChatGPT, Gemini et Siri ont besoin de données structurées l'a déjà écrit ; celui-ci ajoute : comment la ligne interroger les données entre dans la boucle depuis un fichier.

Ce qu'est vraiment un AI Data Agent

À l'oral, « Data Agent » se résume souvent à « un ChatGPT qui lit les tableaux ». En production, il y a trois couches. Les mélanger, et l'on a l'impression que « ça calcule juste parfois, parfois ça s'envole ».

1. Le plan données. Une entrée lisible par une machine : lignes CSV, objet JSON, table d'entrepôt, ou fichier tiré par un connecteur. Ça doit pouvoir parser ; colonnes ou clés doivent avoir un nom.
2. La boucle d'analyse. L'Agent explore la forme → choisit une transformation ou une requête → exécute le code / SQL → relit la table ou l'agrégat → décide s'il faut un autre tour.
3. Le contrat. Comment s'appelle l'indicateur, comment on le calcule, quels filtres sont légaux, quels champs la conclusion doit rendre. En entreprise, ça s'appelle souvent couche sémantique ; dans l'interface, c'est souvent un JSON Schema.

Enlevez-en une : le reste dégénère en « veuillez analyser sérieusement » dans le prompt — la démo passe, le recalcul non. Le Coding Agent réutilise le process via les Skills : Pourquoi les Coding Agents ont besoin de Skills. Le Data Agent réutilise les indicateurs et la forme : le même net_revenue ne peut pas inclure les remboursements aujourd'hui et les exclure demain.

L'écart avec Coding Agent et chat ordinaire

Les trois types d'Agent « choisissent un outil, remplissent les paramètres, lisent la valeur de retour ». Ils ne mangent pas le même matériau.

Le contrat d'outil du Coding Agent reste un Schema : DevDay 2026 Agent. Le Data Agent a une couche de plus : le référentiel métier. La même colonne amount : TTC, avec remboursements, ou seulement le payé — il faut le figer. Sinon le modèle « rend service » et choisit un algorithme à chaque fois, le rapport ne colle plus à la finance.

Les deux chemins de données ChatGPT

Le « ChatGPT Data Agent » du titre, en 2026-09, désigne au moins deux choses. Mélanger les noms produit, et l'on prend « pouvoir uploader un CSV » et « pouvoir interroger l'entrepôt » pour le même bouton.

1. Upload de fichier + bac à sable Python

La version personnelle et la plupart des espaces de travail passent encore par là : accrocher le fichier à la session, laisser le modèle écrire et exécuter du Python. La page d'aide données d'OpenAI le dit : les entrées courantes incluent .csv, .xls / .xlsx, .json, .xml, .yaml, .txt, .md, et le PDF ; avec des connecteurs, on peut aussi accrocher des fichiers depuis Google Drive, OneDrive, SharePoint. Côté analyse, les gestes courants : résumer lignes, colonnes et outliers, générer une table ligne par ligne, tracer, transformer et calculer, et expliquer les hypothèses.

L'environnement d'exécution ressemble à un Jupyter avec état : les tables pandas peuvent s'afficher comme tables interactives. La limite clé est sur la même page : le bac à sable ne sort pas sur le réseau par défaut, il n'appelle pas d'API externe. Les données externes manquantes, il faut d'abord les uploader ou d'abord brancher la source. Pouvoir uploader un fichier, ce n'est pas pouvoir tout analyser d'un coup — trop gros, trop sale, tableau scanné : il faut découper le fichier ou nommer la feuille / les colonnes.

Ce chemin convient : un export, une exploration, un graphique destiné à l'humain. Il ne remplace pas les droits de l'entrepôt, et ne garantit pas que les quatre lettres « revenu net » collent au calendrier finance.

2. Le @Data de ChatGPT Work

Vers le 2026-09-10, OpenAI a mis le Data Agent dans ChatGPT Work (et l'espace Codex) : installer le plugin Data, @Data dans la conversation, interroger « qu'est-ce qui a changé » sur les sources déjà approuvées par l'entreprise. Le centre d'aide liste Amazon Redshift, ClickHouse, Databricks, Google BigQuery, MongoDB, Snowflake ; côté documents, on peut superposer Google Drive et SharePoint. L'admin gère connexions et disponibilité ; les droits déjà posés sur tables, lignes, colonnes restent en vigueur.

Ce chemin a trois choses que l'analyse par upload n'a pas :

• Couche sémantique. Définitions d'indicateurs, calculs, relations entre jeux. Lui dire quel référentiel utiliser est plus stable que de le laisser « comprendre le chiffre d'affaires tout seul ».
• Sortie BI. Le résultat d'analyse peut atterrir dans un outil de tableau de bord déjà là (Tableau, Power BI, Sigma, ThoughtSpot, etc., selon ce que l'espace a réellement ouvert), au lieu de s'arrêter dans la bulle de chat.
• Relance et confrontation. Dans la même session : changer un filtre, comparer des groupes, recouper source, fenêtre temporelle et définition d'indicateur. Si ça ne colle pas à l'ancien rapport, comparez d'abord ces trois, avant de soupçonner le modèle.

Ce n'est toujours pas de la magie. Sans plugin ouvert, sans rôles de gouvernance mappés, sans indicateurs fiables, @Data n'est qu'une fenêtre de chat plus douée pour le SQL. La boucle de production veut le quatuor : source, fenêtre temporelle, filtres, nom d'indicateur — tous pointables.

Comment le JSON entre dans la boucle

Le JSON est un bus d'objets, pas une table. Un Data Agent qui traite du JSON fait en général d'abord quatre choses :

1. parser. La syntaxe échoue, tout s'arrête derrière. Virgule finale, apostrophes simples, commentaires : il faut d'abord nettoyer.
2. Reconnaître la forme. La racine est un objet ou un tableau ? Les enregistrements sont dans data[] ou rows[] ? Combien de niveaux d'imbrication ?
3. Aplatir ou garder le nested. Pour un groupby, on casse souvent les objets imbriqués en colonnes ; pour le saut Agent suivant, il faut au contraire garder l'objet.
4. Surveiller les types. "89.7" est une chaîne, 89.7 un nombre. null, clé absente, chaîne vide : ce n'est pas la même chose.

La commande imbriquée est le piège classique : customer.region, lines[].sku, payment.refunded non aplatis, et le groupby tombe sur des colonnes vides. Une fois aplati, on perd la granularité « une commande, plusieurs lignes ». La bonne pratique : d'abord déclarer le grain : par commande, par ligne, ou par client. Le grain écrit dans l'objet de conclusion, le saut suivant sait si les chiffres s'additionnent.

Le JSON convient aussi comme la requête d'analyse elle-même : question, indicateur, filtres, fenêtre temporelle en objet, pas un « aide-moi à voir si ça se vend bien récemment ». Le NL Query et le Structured Output de ce site font exactement ça : refermer la phrase en une forme validable. Après le graphique, l'Agent cloud devrait encore pouvoir cracher le même objet.

Comment le CSV entre dans la boucle

Le CSV a l'air plus sage que le JSON : une ligne, un enregistrement, l'en-tête comme nom de colonne. L'Agent se plante encore à cinq endroits.

• En-têtes. Amt, Montant (TTC), amount_usd ne sont pas la même colonne. En-tête vide, en-tête dupliqué : pandas renomme, le prompt suivant ne colle plus.
• Séparateur et quotes. Point-virgule, tabulation, virgule dans un champ. L'extension .csv ne garantit pas la virgule.
• Inférence de type. Codes postaux, numéros de commande, SKU ramassés en nombres : les zéros de tête disparaissent. Les dates s'écrivent chacune à sa façon.
• Encodage. Du GBK sans BOM se lit en mojibake dans le bac à sable : les noms de colonnes cassent d'abord.
• Grain. Détail et agrégat mélangés dans une table : le total est additionné deux fois.

Le conseil d'OpenAI reste simple : noms de colonnes clairs, une ligne un enregistrement, et dans le prompt nommer les colonnes à regarder, le calcul, le groupement et le type de graphique. Le premier graphique est faux : spécifiez la méthode, n'espérez pas que « automatique » tombe juste du premier coup.

JSON et CSV doivent souvent se convertir. Les logs d'API sont du JSON, la finance veut du CSV ; l'outil tableau mange du plat, les paramètres d'outil Agent mangent des objets. Le JSON ↔ CSV et le Tableau JSON de ce site alignent les deux faces dans le navigateur, sans uploader d'abord tout l'entrepôt.

Les étapes réelles de l'analyse automatique

Que ce soit le bac à sable d'upload ou @Data, la boucle qu'on peut raconter est à peu près la même :

1. Accrocher les données. Upload, connecteur, ou plugin d'entrepôt. Pas de fichier, pas de droits : la boucle ne démarre pas.
2. Explorer. Nombre de lignes, noms de colonnes, dtype, valeurs vides, unicité de la clé. Sautez cette étape, et les « insights » derrière sont surtout des paris.
3. Aligner le référentiel. Version perso : la formule que vous figez dans le prompt ; Work : la couche sémantique ou l'indicateur que vous nommez.
4. Transformer. Sélection de colonnes, filtres, join, aplatissement, colonnes dérivées. Chemin Python : pandas ; chemin entrepôt : SQL.
5. Agréger et visualiser. La table pour recouper, le graphique pour voir la tendance. Ni l'un ni l'autre n'est le terminus.
6. Relancer. Changer la fenêtre, changer le groupe de contrôle, demander les preuves. Dans le bac à sable : réécrire le code et relancer ; dans @Data : changer la requête et recouper la source.
7. Rendre un objet. Au moins : source, grain, indicateur, filtres, fenêtre temporelle, chiffre, confiance ou « confirmation humaine requise ».

L'étape 7 est la plus souvent sautée. Un graphique seul, le saut Agent suivant ne le lit pas ; un morceau de prose, on ne peut pas en faire un diff. Refermer la conclusion en JSON, et ça passe par Function Calling ou MCP Tool : le modèle ne « dit pas qu'il faut réapprovisionner », il soumet une action qui doit pouvoir se valider.

Un échantillon de commandes à recetter en local

L'objet ci-dessous joue deux rôles à la fois : c'est l'entrée du Data Agent (commande imbriquée), et le contrat de la requête d'analyse (question, indicateur, fenêtre dans le même fichier).

{
  "dataset": "orders_q3",
  "grain": "order_line",
  "source": "json_export",
  "period": {
    "start": "2026-08-01",
    "end": "2026-08-31",
    "timezone": "Asia/Shanghai"
  },
  "metric": {
    "name": "net_revenue",
    "formula": "sum(line.amount) where refunded = false"
  },
  "question": "Which SKU grew fastest in APAC in August?",
  "orders": [
    {
      "order_id": "ORD-1042",
      "paid_on": "2026-08-12",
      "refunded": false,
      "customer": {
        "region": "apac",
        "segment": "pro"
      },
      "line": {
        "sku": "JSON-PRO",
        "qty": 3,
        "amount": 89.7,
        "currency": "USD"
      }
    }
  ]
}

Selon les règles d'inférence actuelles du site, cet échantillon donne :

Les mêmes lignes, pour un outil tableau ou le bac à sable d'upload, s'aplatissent en CSV :

order_id,paid_on,refunded,region,segment,sku,qty,amount,currency
ORD-1042,2026-08-12,false,apac,pro,JSON-PRO,3,89.7,USD

Notez que refunded reste un mot booléen, pas « non ». Une fois aplati, customer.region devient region ; le grain reste la ligne, ne mélangez pas avec l'en-tête de commande. Échantillon prêt : ouvrez JSON ↔ CSV pour recouper la table plate, puis Structured Output pour générer le Schema de la conclusion d'analyse. L'objet de conclusion devrait au moins avoir : metric.name, period, filters, top_sku, value, evidence_rows.

Recetter dans la Boîte à outils JSON

1. Collez le JSON ci-dessus dans le formatage JSON, pour confirmer que ça parse. Export sale : d'abord le Nettoyage JSON.
2. Avec le Tableau JSON, voyez si le nested s'ouvre au grain que vous pensiez. Une ligne devient plusieurs : changez l'échantillon d'abord, puis uploadez.
3. Besoin d'un fichier plat : exportez via JSON ↔ CSV, vérifiez en-têtes, booléens, dates, puis décidez si vous le donnez à ChatGPT.
4. Avec Structured Output ou JSON → Schema, générez le premier brouillon de contrat pour la requête / la conclusion.
5. Un second jeu de sorties réelles — le modèle écrit le montant en chaîne, region en « Asie-Pacifique » — passe en validation Schema. Le premier échantillon est toujours trop propre.
6. Quand vous passez de « analyse par upload » à @Data ou à un autre export, utilisez la Comparaison JSON pour voir si un champ a disparu ou si le référentiel a dérivé.

Tout se traite dans le navigateur, rien n'est envoyé au serveur. L'Agent cloud calcule ; l'outil local, avant de rendre le fichier, fige la forme et le contrat.

FAQ

Quelle est la différence entre un AI Data Agent et un chat ChatGPT ordinaire ?

Le chat donne des phrases à l'humain. Un Data Agent doit explorer les données, exécuter du code ou du SQL, sortir tables et graphiques, puis rendre la conclusion en objet. Sans résultat intermédiaire validable, le saut suivant ne tient que si un humain surveille.

ChatGPT peut-il analyser directement du JSON et du CSV ?

Oui. La version personnelle passe par l'upload, puis le bac à sable Python explore et calcule. Le @Data de Work peut encore brancher l'entrepôt et la couche sémantique. Le JSON imbriqué doit souvent s'aplatir d'abord ; un CSV aux colonnes floues fait dériver les types.

Le Data Agent de ChatGPT Work et l'analyse par fichier uploadé, c'est la même chose ?

Non. L'analyse par upload mange les fichiers de la session ; le bac à sable ne sort pas sur le réseau par défaut. @Data mange des connexions déjà approuvées, plus les définitions d'indicateurs et les droits.

Pourquoi un Data Agent a-t-il encore besoin d'un JSON Schema ?

Le graphique est pour l'humain. L'écriture, l'évaluation, le saut Agent suivant veulent un objet : indicateur, filtres, fenêtre temporelle, chiffre. Sans Schema, on parie que le modèle a cette fois écrit toutes les clés.

Faut-il envoyer tout de suite des données sensibles à ChatGPT ?

Regardez d'abord la forme en local, anonymisez, puis uploadez. Les outils de ce site ne quittent pas le navigateur par défaut ; le bac à sable cloud lira le fichier que vous lui donnez.

En résumé

Un AI Data Agent n'est pas « une fenêtre de chat plus douée pour les tableaux ». C'est une boucle qui ne se referme que grâce à une entrée structurée : explorer, transformer, agréger, relancer, rendre un objet. ChatGPT, en 2026-09, a deux chemins déjà utilisables — upload de session plus bac à sable Python, et le @Data de ChatGPT Work / Codex, avec connecteurs et couche sémantique. Le JSON doit reconnaître racine, nested et types ; le CSV doit reconnaître en-têtes, séparateur, encodage et grain. L'analyse automatique n'épargne ni l'exploration, ni le référentiel. Ce qui survit au renouvellement de la semaine suivante, c'est l'échantillon, la table plate et le Schema de conclusion, pas le « veuillez analyser en profondeur » dans le prompt. Un seul échantillon de commandes fait pousser le contrat ; validation, CSV, tableau, et l'objet que vous préparerez pour l'Agent, le suivent.

Outils liés