OpenAI a introduit un agent Data dans ChatGPT Work. Les salariés peuvent lui poser des questions sur les données de l’entreprise, examiner des évolutions, créer des tableaux de bord et recommander ou exécuter des actions de suivi en langage naturel. L’annonce est importante parce qu’elle transpose une promesse désormais familière de l’IA dans un goulot d’étranglement moins spectaculaire : l’analyse métier, techniquement disponible mais difficile à utiliser pour les employés ordinaires.

Tableau abstrait d’analytique d’entreprise avec graphiques, définitions de métriques, contrôles d’accès et piste d’audit

Le produit peut se connecter à des sources comme Amazon Redshift, Datadog, Google BigQuery, ClickHouse, Databricks, MongoDB et Snowflake. Il peut aussi exploiter les fichiers et documents de Google Drive et SharePoint, utiliser des définitions métier fournies par des couches sémantiques et interagir avec des outils comme Tableau, Power BI, Sigma et ThoughtSpot. OpenAI indique que les administrateurs choisissent les connexions et les rôles activés, tandis que les requêtes appliquent les droits existants du compte connecté. OpenAI décrit ici le produit et ses connexions prises en charge.

Cela ressemble à une nouvelle interface pour l’analytique. C’en est une, mais l’interprétation la plus utile est plus limitée : l’agent Data peut réduire le coût d’une première question. Il ne dispense pas de déterminer ce que la question signifie, de vérifier si les données sous-jacentes permettent d’y répondre ni de décider de l’autorité qu’une réponse doit avoir dans l’entreprise.

Pour les équipes qui envisagent le produit, le bon point de départ n’est pas une collection de prompts impressionnants. Il faut plutôt un pilote contrôlé autour d’un processus de décision, avec des métriques nommées, un accès aux données limité, des vérifications indépendantes et une frontière nette entre analyse et action.

Ce qu’OpenAI ajoute réellement

Les outils traditionnels de business intelligence prennent déjà en charge les tableaux de bord, les requêtes SQL, les rapports planifiés et les métriques gouvernées. La nouvelle couche est celle de l’enquête conversationnelle. Un utilisateur peut demander pourquoi le nombre d’utilisateurs actifs hebdomadaires a changé, comparer des périodes, repérer des facteurs possibles, demander un graphique, interroger les réserves méthodologiques, puis transformer le résultat en tableau de bord partageable sans apprendre la syntaxe d’un entrepôt ni la structure d’une application de BI.

OpenAI indique que l’agent peut utiliser les termes métier de l’organisation, ses définitions de métriques, ses calculs personnalisés et les relations entre les sources de données. Ces définitions peuvent venir de couches sémantiques et de systèmes de confiance comme dbt, Databricks Genie Ontology, GitHub, Snowflake Horizon et des tableaux de bord de BI existants. Ce détail compte. Une question en langage naturel n’est fiable que dans la mesure où les définitions disponibles derrière elle le sont.

Prenons la question suivante : pourquoi la rétention brute a-t-elle diminué au dernier trimestre ? Plusieurs interprétations de la rétention brute sont plausibles. Le calcul peut varier selon le produit, le segment de clientèle, le traitement des devises, le statut contractuel, la fenêtre de renouvellement et la manière de traiter les expansions ou les déclassements. Un modèle peut produire une explication bien rédigée à partir de la mauvaise définition. Connecter une couche sémantique augmente les chances que l’agent comprenne la question comme prévu, mais cela ne rend pas la définition évidente pour autant.

Le produit dépasse également la réponse en lecture seule. OpenAI affirme que les utilisateurs peuvent demander à l’agent de recommander les prochaines étapes, d’identifier les personnes à impliquer, de partager les résultats dans Slack ou par e-mail et d’exécuter des actions approuvées au moyen d’outils connectés. C’est à ce moment que le profil de risque change. Un graphique erroné relève d’un problème de vérification. Un message incorrect, une mise à jour de ticket, une modification de prévision ou un déclenchement de workflow peut devenir un incident opérationnel.

L’annonce présente l’agent Data comme disponible dans le répertoire des plugins de ChatGPT Work. Les administrateurs peuvent installer le plugin Data, activer les plugins correspondant aux sources, gérer les accès, puis laisser les utilisateurs commencer une conversation avec @Data. La mise en place n’est donc pas simplement le choix d’un chatbot par un salarié. C’est une décision de configuration de l’espace de travail qui implique les propriétaires des données, les administrateurs des identités, les équipes de sécurité et les responsables des définitions utilisées dans les rapports.

Le problème pratique qu’il pourrait résoudre

De nombreuses demandes d’analyse ne sont pas difficiles parce que le SQL est complexe. Elles le sont parce que la demande doit traverser plusieurs files d’attente. Un responsable remarque une variation de la conversion, demande une explication à un analyste, attend que celui-ci trouve les tables pertinentes, précise la définition, attend encore un graphique, puis découvre qu’une deuxième équipe utilise un autre dénominateur. Le délai peut dépasser la durée de l’analyse elle-même.

Un agent conversationnel peut rendre cette première passe moins coûteuse. Un responsable commercial pourrait examiner l’évolution du pipeline avant de demander un rapport formel à l’équipe des opérations commerciales. Un responsable du support pourrait comparer le volume de tickets aux effectifs et aux données de niveau de service. Une équipe produit pourrait étudier une variation de la rétention et établir une liste d’hypothèses pour l’expérience suivante. La finance pourrait utiliser l’outil pour repérer des anomalies de dépenses avant de décider si un examen plus approfondi est nécessaire.

L’intérêt n’est pas que chaque salarié devienne data scientist. Il tient au fait que davantage de questions peuvent être orientées au plus près du moment où elles apparaissent. Les questions simples peuvent recevoir une réponse directe. Les questions ambiguës peuvent être détectées plus tôt. Les analystes peuvent consacrer moins de temps à produire des premières versions répétitives et davantage à vérifier les définitions, concevoir des mesures et traiter les décisions qui exigent du jugement.

OpenAI indique que la quasi-totalité de son équipe produit et plus des deux tiers de son organisation go-to-market utilisent des agents de données dans ChatGPT Work. L’entreprise cite également des organisations participant à un programme alpha, parmi lesquelles NTT DATA, Thermo Fisher, ServiceTitan, Zipline, Empower, Piston et d’autres. Ces exemples donnent une indication des workflows visés, mais restent des exemples de clients rapportés par le fournisseur, et non une preuve indépendante des performances générales. Un acheteur doit les considérer comme des références d’implémentation, pas comme une prévision de retour sur investissement.

Un bon pilote devrait mesurer des résultats moins spectaculaires : le temps entre la question et une première réponse vérifiée, le pourcentage de réponses nécessitant une correction, le nombre de demandes de reporting en doublon, l’adoption par le groupe d’utilisateurs visé, le coût des requêtes et le nombre de fois où un utilisateur a mal compris une métrique malgré une explication fluide. Ces mesures montrent si l’agent améliore le processus de décision, plutôt que de simplement produire des objets séduisants.

Pourquoi la couche sémantique compte davantage que le prompt

L’expression analyse en langage naturel peut donner l’impression que l’interface constitue l’innovation principale. En pratique, le modèle de données qui se trouve derrière est plus important. Une couche sémantique fournit à un système des noms partagés, des relations, des calculs et des règles. Sans elle, l’agent doit déduire le sens métier à partir des noms de tables, des noms de colonnes, des descriptions, des valeurs d’exemple et du contexte de la conversation. Cela peut suffire pour explorer. C’est une base fragile pour un reporting récurrent destiné à la direction.

Avant un pilote, l’équipe doit consigner les définitions des métriques que les utilisateurs devraient demander. Chaque définition devrait préciser les tables sources, le fuseau horaire, la période, les filtres, les règles d’inclusion et d’exclusion, le traitement des remboursements ou des annulations, la conversion des devises et le responsable habilité à approuver une modification. La liste n’a pas besoin de couvrir tout l’entrepôt. Elle doit couvrir la décision que le pilote doit aider à prendre.

L’équipe doit aussi documenter la source prioritaire lorsque les systèmes ne concordent pas. Le CRM peut contenir l’étape d’une opportunité, le système de facturation son statut de facture et la base produit l’usage réel. Les trois informations peuvent être correctes dans leur contexte. Pour répondre à une question métier précise, l’agent a besoin d’une règle, pas seulement d’un accès aux trois systèmes.

La répartition des rôles peut être formulée ainsi :

  • L’agent peut transformer une question en enquête, récupérer les informations pertinentes, comparer des périodes, préparer une visualisation et repérer des facteurs possibles.
  • Le propriétaire des données définit la métrique, la priorité des sources, les filtres acceptables et l’exigence de fraîcheur.
  • L’analyste ou l’expert métier teste le résultat, examine les éléments probants et décide s’il est suffisant pour une décision.
  • Le responsable de la décision détermine l’action à suivre et vérifie que les preuves répondent au niveau d’exigence de l’organisation.

L’agent peut raccourcir le chemin entre ces personnes. Il ne peut pas légitimement endosser les quatre rôles.

Les droits d’accès sont nécessaires, mais ne constituent pas tout le système de contrôle

OpenAI indique que les administrateurs d’entreprise peuvent sélectionner les connexions et les rôles disponibles, et que les requêtes appliquent les restrictions du compte connecté, notamment au niveau des tables, des lignes et des colonnes. C’est une exigence de conception importante. Une interface d’IA ne doit pas devenir une porte dérobée autour du modèle d’autorisation qui protège déjà un entrepôt.

Il ne suffit toutefois pas d’entendre que les droits sont appliqués. L’implémentation doit être testée avec des identités représentatives. Le pilote devrait inclure un utilisateur qui peut voir un jeu de données régional mais pas celui d’une autre région, un utilisateur qui peut consulter une rémunération agrégée mais pas les salaires individuels, et un utilisateur qui peut voir l’activité client sans accéder aux identifiants personnels. L’équipe doit tester les questions directes ainsi que les questions indirectes susceptibles de révéler des informations protégées au moyen de totaux, de comparaisons ou de requêtes répétées.

La documentation BigQuery de Google montre pourquoi ces tests sont nécessaires. BigQuery prend en charge des contrôles d’accès au niveau du projet, du jeu de données et de la table, ainsi que la sécurité au niveau des lignes et des colonnes. Les règles au niveau des lignes filtrent les enregistrements visibles par un principal ; les règles au niveau des colonnes peuvent restreindre les champs sensibles et être associées au masquage. Google avertit également que des schémas d’accès mal conçus peuvent divulguer des informations par des canaux auxiliaires, comme le comportement des requêtes ou leur durée. La documentation BigQuery explique l’interaction entre les contrôles sur les lignes et les colonnes.

La leçon dépasse BigQuery. Un modèle n’a pas besoin d’imprimer une valeur protégée pour divulguer quelque chose à son sujet. Une demande telle que « quel salarié de la petite équipe européenne a obtenu la plus forte hausse de rémunération ? » peut devenir sensible même si la table n’expose pas directement une colonne de salaire. Les seuils d’agrégation, les petits groupes, les catégories rares et les comparaisons répétées doivent faire l’objet de règles explicites.

La revue minimale des autorisations doit répondre à cinq questions :

  1. Quelles identités peuvent appeler l’agent ?
  2. Quelles connexions chaque identité peut-elle utiliser ?
  3. Le système source applique-t-il aux requêtes générées par l’agent les mêmes restrictions de lignes et de colonnes qu’aux requêtes ordinaires ?
  4. Que se passe-t-il lorsque l’agent combine des données issues de sources soumises à des règles d’accès différentes ?
  5. Quels journaux indiquent l’utilisateur, la question, la requête ou l’opération générée, les sources consultées, la destination du résultat et toute action approuvée ensuite ?

Si la réponse à la dernière question reste vague, le pilote n’est pas prêt à utiliser des données sensibles.

Les promesses de confidentialité doivent correspondre au produit et au contrat réels

La politique d’OpenAI relative aux données professionnelles indique que, par défaut, les entrées et sorties de ChatGPT Enterprise, ChatGPT Business, ChatGPT Edu, ChatGPT for Healthcare et de la plateforme API ne servent pas à entraîner ou améliorer les modèles. Elle décrit également le chiffrement en transit et au repos, les contrôles fondés sur les rôles, des options de conservation pour les organisations éligibles et des choix de résidence des données pour certains services. La page d’OpenAI consacrée aux données professionnelles précise ces engagements et leur périmètre.

Ces engagements répondent à des questions importantes, mais pas à toutes celles qu’une équipe data doit poser. La revue doit porter sur l’édition exacte de ChatGPT Work, les plugins connectés, les fournisseurs de données, la configuration de conservation, les accès du support, le traitement régional, les modalités d’export et de suppression, ainsi que les conditions applicables à chaque service partenaire. Dire que le modèle n’est pas entraîné sur les données de l’entreprise ne revient pas à garantir qu’aucun système connecté ne conserve les journaux de requêtes, les extraits copiés, les artefacts de tableaux de bord ou les traces d’action.

L’architecture de l’agent Data introduit aussi une question de localisation des données. OpenAI indique que le produit peut se connecter aux sources d’entreprise et décrit, dans le produit destiné aux services financiers annoncé le même jour, des données intégrées provenant de fournisseurs qui sont indexées et hébergées sur l’infrastructure d’OpenAI. Cette offre financière est distincte, mais elle montre pourquoi les clients doivent distinguer un connecteur qui interroge leur système d’un service qui copie, indexe, met en cache ou enrichit les données ailleurs. L’annonce d’OpenAI consacrée aux services financiers décrit cette distinction pour son offre ciblée.

Une revue de sécurité devrait demander un schéma des flux de données, et pas seulement un résumé de sécurité. Il doit montrer le parcours d’un prompt, de la requête générée, des lignes récupérées, des fichiers intermédiaires, de la sortie du tableau de bord, de l’enregistrement d’audit et de tout message sortant. Il doit identifier les éléments traités par OpenAI, l’entrepôt, l’outil de BI, le connecteur et le système d’action. L’organisation doit savoir quel composant est responsable de la suppression et lequel applique les droits à chaque étape.

La vérification des preuves distingue l’analyse de la mise en scène de l’automatisation

Une réponse qui affirme que les ventes ont baissé à cause d’une demande plus faible des grandes entreprises peut être plausible tout en étant fausse. La question utile est la suivante : quelles données étayent cette affirmation, quelle comparaison a été faite, quelles explications concurrentes ont été examinées et que reste-t-il d’inconnu ?

OpenAI indique que les utilisateurs peuvent examiner les preuves derrière les conclusions et poser des questions de suivi. Cela devrait devenir une habitude de fonctionnement. Un tableau de bord sans définition visible ni chaîne de sources n’est pas une analyse terminée. C’est une piste pour une enquête supplémentaire.

Un modèle de vérification pratique peut demander à l’agent de fournir :

  • la définition exacte de la métrique utilisée ;
  • la période étudiée et la période de comparaison ;
  • les tables, vues, documents ou tableaux de bord consultés ;
  • les filtres et jointures appliqués ;
  • le nombre d’enregistrements ou de groupes concernés ;
  • la fraîcheur des données et les avertissements sur les données manquantes ;
  • les éléments les plus solides à l’appui de chaque conclusion ;
  • les explications alternatives plausibles ;
  • les contrôles susceptibles d’infirmer l’explication principale ;
  • une prochaine étape recommandée qui ne suppose pas que la conclusion soit vraie.

Ce format est volontairement moins séduisant qu’un récit assuré. Il est plus facile à auditer. Il apprend aussi aux utilisateurs qu’une explication générée est une hypothèse étayée par des preuves, et non une réponse de direction simplement parce qu’elle est bien écrite.

Les équipes devraient conserver un petit jeu d’évaluation composé de questions réelles, avec des réponses connues et des pièges identifiés. Il peut inclure une métrique dont la définition a changé, une table actualisée avec retard, un doublon client, une région soumise à une restriction d’accès et une question dont la bonne réponse est que les données ne suffisent pas. Il faut exécuter ce jeu avant le lancement et après chaque modification importante de la couche sémantique, du connecteur, du modèle ou des droits.

Le cas des preuves insuffisantes mérite une attention particulière. Un système qui fournit toujours un facteur explicatif est plus dangereux qu’un système qui s’arrête parfois. Un agent utile doit pouvoir dire que les données disponibles montrent une corrélation mais pas une causalité, qu’une source est obsolète, que deux systèmes divergent ou que l’échantillon est trop petit pour identifier une tendance fiable.

Les coûts ne se limitent pas à l’abonnement

L’annonce d’OpenAI ne présente pas de tarif public universel pour l’agent Data. Il est donc prématuré de calculer un rendement simple par utilisateur. Le modèle de coût dépendra probablement de la formule ChatGPT Work, de l’utilisation des modèles, des systèmes connectés, des frais de requête de l’entrepôt, des licences de BI, des accords avec les fournisseurs de données, du stockage et des outils d’action. Les acheteurs potentiels doivent demander les tarifs et limites d’usage propres à leur espace de travail, au lieu de les déduire des offres ChatGPT grand public ou des coûts ordinaires d’une base de données.

Des coûts opérationnels apparaissent aussi après le lancement. Les requêtes qui parcourent de grandes tables peuvent mobiliser les ressources de l’entrepôt. Un utilisateur qui demande à répétition l’actualisation d’un tableau de bord peut créer une charge évitable. L’exploration en langage naturel peut multiplier les demandes parce que les questions de suivi semblent peu coûteuses. Certains systèmes facturent les données parcourues, les appels d’API, les actualisations de tableaux de bord ou les connecteurs premium.

Un pilote responsable doit fixer des budgets et les observer. Il faut commencer, lorsque c’est possible, avec des vues organisées ou des tables récapitulatives. Ajouter des délais d’expiration et des limites de balayage. Enregistrer le coût par équipe et par workflow. Rendre la fraîcheur explicite pour éviter que les utilisateurs actualisent sans cesse une source qui ne se met à jour qu’une fois par jour. Décider si un tableau de bord généré par l’agent peut s’actualiser automatiquement ou seulement à la demande.

La maîtrise des coûts est aussi une question de modèle de données. Un entrepôt mal modélisé oblige l’agent à payer plusieurs fois pour un travail qui aurait pu être préparé une seule fois. Une couche sémantique bien conçue, une table agrégée ou une vue gouvernée peut améliorer simultanément la vitesse, la fiabilité et la dépense.

Où commencer et où ne pas commencer

Les meilleurs premiers cas d’usage ont un responsable clairement identifié, une sensibilité modérée, des questions répétitives et une personne capable de vérifier rapidement le résultat. On peut citer l’étude de l’adoption d’un produit, la préparation d’une revue opérationnelle interne, la recherche d’incohérences dans les rapports, l’exploration de la demande du support, la comparaison des performances de campagnes et la rédaction d’une liste de questions pour un analyste.

Le premier cas d’usage ne devrait pas être le rapport le plus politiquement important de l’entreprise. Il ne faut pas commencer par la rémunération, les décisions réglementées concernant des clients, les conclusions médicales, les décisions de crédit, les déterminations juridiques ou un workflow automatisé qui modifie les dossiers de nombreuses personnes. Ces domaines pourront éventuellement bénéficier de la même interface, mais ils exigent des contrôles plus solides, une validation plus formelle et une structure de responsabilité claire.

Les petites entreprises ne doivent pas supposer qu’un grand entrepôt est indispensable. Une entreprise de taille réduite peut tirer parti d’une connexion à un jeu de données commercial ou de support fiable pour répondre à une question opérationnelle étroite. Elle peut aussi découvrir que son véritable problème tient à l’absence de définitions, et non au manque de logiciel analytique. Ce serait déjà un résultat utile.

Les grandes entreprises ne doivent pas supposer qu’un déploiement large sera automatiquement efficace. Un entrepôt mondial peut contenir des années d’exceptions, des acquisitions, des produits renommés, des pipelines dupliqués et des équipes qui emploient différemment le même terme. L’agent rendra cette ambiguïté plus facile d’accès. Il ne la fera pas disparaître.

Les équipes devraient probablement remettre le produit à plus tard si elles ne peuvent pas identifier un propriétaire des sources, tester les droits, disposer d’un chemin d’audit ou mobiliser quelqu’un pour vérifier les résultats. Dans ce cas, l’agent risque d’accélérer la production de désaccords dans l’organisation.

Un pilote de quatre semaines qui produit des éléments utiles

Un pilote raisonnable peut être mené en quatre étapes. Le calendrier importe moins que les points de contrôle qui les séparent.

Première semaine : choisir la décision, pas la technologie

Sélectionnez une décision récurrente, par exemple l’explication des variations hebdomadaires de l’activation ou la préparation d’une revue de capacité du support. Nommez le groupe d’utilisateurs, le responsable de la décision, le propriétaire des données, l’analyste chargé de la revue, le délai de réponse acceptable et le niveau maximal de sensibilité. Notez les cinq à dix questions que l’équipe pose réellement aujourd’hui. Incluez au moins une question qui devrait déclencher un avertissement d’incertitude.

Inventoriez les sources pertinentes et identifiez le système propriétaire de chaque champ. Créez un petit glossaire avec les définitions des métriques, les attentes de fraîcheur et les exclusions connues. Si l’équipe ne parvient pas à s’accorder sur une définition, consignez le désaccord au lieu de demander à l’agent de le résoudre.

Deuxième semaine : préparer les vues et les droits

Préférez des vues gouvernées ou des jeux de données sélectionnés à un accès sans restriction à tout un entrepôt de production. Séparez les données d’exploration des systèmes contenant des identifiants directs, des identifiants d’accès, des informations de santé, des données de paie ou d’autres champs à haut risque. Créez des comptes de test représentant les personnes qui utiliseront le pilote.

Configurez la journalisation, la conservation et les alertes budgétaires avant de commencer. Vérifiez si les outils connectés conservent des copies des prompts, des requêtes, des fichiers, des tableaux de bord ou des résultats. Examinez les conditions du fournisseur et des connecteurs pour les services exacts concernés.

Troisième semaine : tester la précision et les comportements d’échec

Exécutez le jeu d’évaluation. Comparez les résultats générés par l’agent avec une réponse produite indépendamment par un analyste. Suivez non seulement la précision numérique, mais aussi l’exactitude de la définition, le choix des sources, le comportement des permissions, la qualité de l’attribution, les avertissements de fraîcheur et la capacité à refuser ou nuancer une réponse.

Demandez aux utilisateurs d’essayer des questions normales et des questions volontairement simples mais adversariales. Une demande telle que « affiche-moi la liste complète des clients » peut révéler un problème de politique d’accès plus rapidement qu’un prompt analytique complexe. Testez les petits groupes et les segments sensibles. Testez une source obsolète. Testez une métrique dont la définition a récemment changé.

Quatrième semaine : mesurer l’impact sur le workflow

Laissez les utilisateurs visés travailler sur des questions réelles à faible risque. Mesurez le temps nécessaire pour obtenir une réponse vérifiée, le taux de correction, le temps de revue de l’analyste, le coût de l’entrepôt, le nombre de sessions abandonnées et la capacité des utilisateurs à expliquer les preuves derrière leurs conclusions. Interrogez les analystes chargés des revues. Ils révèlent souvent si l’agent a réduit le travail répétitif ou s’il a simplement déplacé le nettoyage en aval.

Ce n’est qu’après cette étape que l’équipe devrait décider d’élargir l’accès aux données, d’ajouter des permissions d’action ou de connecter davantage d’unités métier. L’extension doit reposer sur des contrôles démontrés, et non sur le nombre de graphiques intéressants produits pendant l’essai.

L’alternative n’est pas toujours un autre produit d’IA

Une entreprise qui évalue l’agent Data devrait le comparer à des améliorations moins visibles mais parfois plus durables. Un catalogue de métriques, une couche sémantique gouvernée, de meilleurs modèles d’entrepôt, un programme de formation à la BI en libre-service, un ensemble de tableaux de bord bien conçu ou un service d’analyste disponible peuvent résoudre plus directement le problème sous-jacent.

Dans certaines équipes, le bon ordre consiste à corriger d’abord le modèle de données, puis à ajouter une interface conversationnelle. Dans d’autres, les définitions existantes sont solides mais enfouies derrière des outils spécialisés, ce qui rend une couche en langage naturel réellement utile. La distinction peut être testée. Posez la même question dans l’interface de BI existante et dans l’agent. Si l’agent est plus rapide mais moins précis, améliorez les définitions et recommencez. S’il est à la fois plus rapide et précis dans le périmètre du pilote, élargissez avec prudence.

Le choix dépend aussi de la dépendance au fournisseur. Une couche sémantique portable entre moteurs de requêtes et outils de BI préserve une marge de manœuvre. Un workflow dépendant de connecteurs propriétaires, du comportement d’un modèle, d’une logique de transformation cachée ou de conventions de prompts non documentées peut devenir difficile à migrer. Conservez les définitions des métriques, les cas d’évaluation, les règles d’accès et les spécifications de tableaux de bord dans des systèmes que l’organisation peut inspecter et maintenir indépendamment de l’interface conversationnelle.

La décision à prendre aujourd’hui

L’agent Data d’OpenAI est surtout convaincant comme porte d’entrée vers des données gouvernées, et non comme remplacement de la gouvernance des données. Il peut rendre l’enquête accessible aux personnes qui connaissent le problème métier mais pas le schéma de l’entrepôt. Il peut produire une première analyse utile, faire apparaître les questions de suivi et transformer un résultat en objet partageable. Ces améliorations comptent lorsque les files d’attente de reporting sont longues et que les définitions sont déjà maîtrisées.

Sa principale limite est tout aussi concrète. Une réponse fluide peut dissimuler une métrique fragile, une jointure incomplète, des données obsolètes, une inférence non autorisée ou une histoire causale non étayée. Plus le système fonctionne sans heurt, plus il devient important de rendre visibles les preuves, les permissions et l’incertitude.

Les équipes devraient l’essayer lorsqu’elles disposent d’un processus de décision étroit, de sources fiables, de définitions claires, de permissions testables et de personnes responsables de la revue. Elles devraient attendre lorsque l’organisation espère qu’un chatbot réglera la propriété des données encore indéterminée ou compensera l’absence de contrôles.

La question utile n’est pas de savoir si un salarié peut poser une question à une base de données en langage courant. Cette capacité arrive désormais sous plusieurs formes. La question utile est de savoir si l’organisation peut rendre la réponse traçable, correctement circonscrite, abordable et suffisamment sûre pour influencer une décision réelle. Pour l’agent Data, c’est la frontière entre l’analytique pratique et un travail digne de confiance.

Sources