Amazon AWS ajoute un catalogue agentique, mais les curateurs humains gardent les clés

Amazon AWS a introduit une expérience de catalogue agentique qui relie Amazon Quick à deux grands catalogues d’entreprise, malgré les questions persistantes autour des modèles de données générés par l’IA.

La préversion prend en charge AWS Glue Data Catalog et Databricks Unity Catalog. Les curateurs de données peuvent décrire un cas d’usage analytique en langage naturel, examiner les actifs recommandés et créer plusieurs jeux de données au cours d’une seule conversation guidée.

Ce flux de travail rapproche du catalogue une partie difficile de l’informatique décisionnelle. Au lieu de reconstruire les descriptions et les relations dans chaque outil d’analyse, les curateurs peuvent réutiliser une sémantique déjà maintenue en amont.

AWS n’a toutefois pas retiré le curateur du processus. Sa propre documentation indique aux auteurs de vérifier les tables découvertes, les relations déduites et les descriptions héritées avant de poursuivre.

Cet avertissement définit le véritable enjeu. Amazon Quick automatise l’assemblage d’une frontière de contexte analytique, mais la qualité de cette frontière dépend toujours du jugement humain.

Il place également Amazon AWS dans une compétition plus large avec Databricks et Microsoft. Chaque fournisseur veut faire des métadonnées gouvernées la base de l’analytique conversationnelle et des agents d’entreprise.

Amazon AWS transforme les métadonnées du catalogue en actifs Quick

La préversion réunit la découverte de données, la création de jeux de données et la configuration sémantique dans un seul flux de travail conversationnel.

Un curateur commence par connecter Amazon Quick à un catalogue pris en charge. L’auteur sélectionne ensuite Explore data et décrit le cas d’usage envisagé en langage courant.

AWS propose un exemple de chaîne d’approvisionnement dans son flux de travail agentique. Un curateur demande des données permettant de répondre à des questions sur la performance des transporteurs et les coûts d’expédition dans différents centres de distribution.

L’agent recherche dans les métadonnées de catalogue disponibles les actifs pertinents. Ces métadonnées peuvent inclure des descriptions de tables, des descriptions de colonnes, des scores de qualité des données et des informations de lignage.

Cela va au-delà de la recherche d’un nom de table familier. L’agent est censé faire correspondre un objectif métier à des actifs techniques susceptibles d’employer des conventions de nommage différentes.

Le curateur examine les recommandations avant de créer quoi que ce soit. Après validation, Quick crée ensemble les jeux de données sélectionnés, au lieu d’exiger un processus de configuration distinct pour chaque table.

Ces jeux de données utilisent DirectQuery, qui envoie les requêtes à la source connectée plutôt que d’importer toutes les données dans Quick. Le catalogue en amont demeure la source de vérité déclarée.

Le flux de travail traite ensuite des relations. Quick peut hériter des relations du catalogue lorsqu’elles existent et proposer des relations supplémentaires qu’il déduit des métadonnées disponibles.

Enfin, l’agent crée un Topic multi-jeux de données. Un Topic est la couche sémantique qui aide Quick à interpréter le langage métier et à générer des requêtes sur les jeux de données sélectionnés.

Les descriptions sont également automatiquement transmises en aval. Les descriptions de tables et de colonnes du catalogue deviennent des métadonnées des nouveaux jeux de données Quick.

Cet héritage est important, car le nom d’une colonne contient rarement à lui seul suffisamment de sens métier. Un champ nommé revenue peut représenter le chiffre d’affaires réservé, le chiffre d’affaires comptabilisé ou une prévision.

Une description maintenue peut préserver cette distinction. Sans elle, un système d’IA doit deviner à partir des noms, des champs voisins et de la formulation de l’utilisateur.

L’expérience de catalogue agentique fait donc plus que localiser des tables. Elle regroupe les actifs, relations et définitions sélectionnés dans un contexte que Quick peut utiliser pour l’analyse.

AWS présente cette capacité comme une préversion, ce qui signifie que son comportement et les fonctionnalités prises en charge restent susceptibles d’évoluer. Ce statut rend également essentielle une évaluation rigoureuse avant toute dépendance en production.

Pour les connexions Databricks, AWS précise explicitement que les fonctionnalités en préversion ne sont généralement pas recommandées pour des charges de travail de production critiques. Cette réserve tempère la commodité promise par le flux de travail guidé.

La publication reste importante, car elle cible un goulot d’étranglement récurrent. Les équipes d’analytique d’entreprise maintiennent souvent des métadonnées précieuses en amont, puis répètent une grande partie de ce travail dans les plateformes de reporting.

Amazon AWS mise sur le fait qu’un agent peut transporter davantage de ce contexte à travers cette frontière. Le travail du curateur devient la sélection et la vérification plutôt que la construction répétitive d’actifs.

Le véritable goulot d’étranglement est le choix du bon contexte

Trouver davantage de données est facile ; définir le plus petit ensemble fiable pour une question métier reste difficile.

Les grandes organisations peuvent posséder des milliers de tables réparties entre entrepôts de données, lacs de données, systèmes opérationnels et projets départementaux. Un vaste catalogue aide à les organiser, mais cette étendue crée son propre problème.

Un agent analytique ne devrait pas recevoir toutes les tables disponibles. Les actifs supplémentaires introduisent des champs ambigus, des définitions concurrentes, des relations non pertinentes et davantage d’occasions de générer des requêtes incorrectes.

AWS appelle l’ensemble sélectionné une frontière de contexte ciblée. L’entreprise recommande de créer uniquement les jeux de données nécessaires au cas d’usage envisagé.

Ce conseil révèle pourquoi l’expérience de catalogue agentique existe aujourd’hui. L’analytique conversationnelle nécessite un contexte plus restreint et mieux décrit que celui généralement fourni par la recherche traditionnelle dans les catalogues.

Un analyste humain peut examiner plusieurs tables aux noms similaires et demander à un collègue laquelle fait autorité. Un agent d’IA a besoin que ces distinctions soient exprimées au moyen de métadonnées, d’instructions et de relations gouvernées.

Le nouveau flux de travail tente de raccourcir le chemin entre le catalogue d’entreprise et un contexte exploitable. Il recherche dans les métadonnées, propose un sous-ensemble pertinent et transfère la sémantique approuvée dans Quick.

Prenons le scénario de la chaîne d’approvisionnement. La performance des livraisons peut impliquer des événements d’expédition, des transporteurs, des centres de distribution, des contrats, des factures et des dimensions calendaires.

Sélectionner trop peu d’actifs produit des réponses incomplètes. En sélectionner trop augmente l’ambiguïté et peut exposer des champs sans lien avec les décisions réelles des responsables.

Le curateur reste donc responsable du périmètre. L’IA propose un ensemble analytique, mais une personne doit décider si cet ensemble reflète le langage opérationnel de l’organisation.

C’est là que l’héritage sémantique a une valeur pratique. Un catalogue bien entretenu contient déjà des définitions créées par des gestionnaires de données et des experts métier.

Réutiliser ces définitions réduit le travail en double et décourage la création d’une nouvelle couche sémantique isolée. Cela fournit également à l’agent Quick davantage de contexte métier que les schémas bruts n’en offrent.

Pourtant, l’héritage ne peut pas améliorer des métadonnées sources inexactes. Une description vague reste vague après sa copie par Quick, tandis qu’une définition obsolète peut se propager avec assurance dans une nouvelle interface.

Les signaux de lignage et de qualité facilitent le processus de découverte, mais ne tranchent pas tous les différends métier. Deux tables gouvernées peuvent toujours représenter différentes versions acceptées d’une même métrique.

L’agent doit également déduire l’intention de l’utilisateur à partir d’une courte demande en langage naturel. Un curateur demandant des données sur la valeur client peut vouloir parler de chiffre d’affaires, de marge, de fidélisation ou d’un score composite propre à l’entreprise.

Le langage naturel rend la configuration plus accessible, mais peut masquer l’ambiguïté. Un formulaire proposant des choix de modélisation explicites révèle parfois les désaccords plus tôt qu’une conversation fluide.

Le changement important n’est pas que la modélisation disparaît. La modélisation devient une tâche de revue effectuée après qu’un agent a proposé une structure.

Cette transition ressemble à d’autres flux de travail de connaissance assistés par l’IA. Les outils peuvent rassembler et combiner du contexte, mais une sortie fiable exige toujours de contrôler les sources qui entrent dans l’ensemble de travail.

Pour la recherche individuelle, le même principe soutient une combinaison des connaissances rigoureuse. L’unité utile n’est pas l’ensemble des documents disponibles, mais les preuves pertinentes pour une question définie.

Amazon Quick applique ce principe aux données d’entreprise gouvernées. Sa préversion ne réussira que si les curateurs peuvent comprendre pourquoi chaque actif et chaque relation ont été recommandés.

Les fournisseurs de catalogues rivalisent désormais par la couche sémantique

Amazon Quick entre dans une compétition visant à déterminer quelle plateforme transforme les métadonnées gouvernées en réponses d’IA fiables.

Databricks considère déjà Unity Catalog comme une couche de gouvernance unifiée pour les données et l’IA. Il applique des contrôles d’accès, enregistre le lignage et expose des actifs gouvernés à travers plusieurs interfaces.

Databricks prend également en charge la découverte par mots-clés et par sémantique pour les tables et colonnes enregistrées. Ses nouveaux outils de découverte permettent aux utilisateurs de parcourir des actifs partagés et de poser des questions en langage naturel.

L’expérience Databricks discovery recoupe une partie de la proposition d’Amazon. Les deux systèmes utilisent le contexte du catalogue pour aider les utilisateurs à trouver des actifs gouvernés pertinents.

La différence réside dans la destination. Amazon Quick utilise les résultats du catalogue pour créer des jeux de données Quick et un Topic multi-jeux de données destiné à l’analyse et aux questions conversationnelles.

AWS ne remplace donc pas Unity Catalog. L’entreprise transforme les métadonnées Unity Catalog en données d’entrée pour une expérience analytique contrôlée par Amazon.

Cette distinction rend l’intégration à la fois coopérative et concurrentielle. Databricks fournit la source gouvernée, tandis qu’Amazon Quick devient l’endroit où les utilisateurs métier consomment le contexte résultant.

La préversion prend en charge les Personal Access Tokens et OAuth à trois branches pour les connexions Databricks. OAuth peut également préserver l’identité individuelle de l’utilisateur lorsque Quick interroge le système en amont.

AWS Glue Data Catalog offre une voie plus verticalement intégrée. Quick peut utiliser un rôle de service ou AWS IAM Identity Center pour la découverte agentique et l’héritage sémantique.

Pour les clients utilisant Lake Formation, la propagation d’identité de confiance peut appliquer les autorisations en amont pour chaque utilisateur. Le système source détermine quelles données cet utilisateur peut interroger.

La propagation d’identité est facultative pour le flux de travail agentique. Toutefois, elle ne s’applique qu’aux jeux de données DirectQuery, selon la documentation de gouvernance.

Si un jeu de données est transféré vers SPICE ou reçoit des transformations, cette identité propagée ne s’applique pas. Les équipes doivent alors utiliser les propres contrôles de sécurité au niveau des lignes et des colonnes de Quick.

Cette limite compte, car la gouvernance est au cœur de la valeur du produit. Un processus de découverte pratique ne peut compenser un modèle d’autorisations que les équipes comprennent mal.

Microsoft poursuit une stratégie connexe avec les agents de données Fabric et les modèles sémantiques Power BI. Ces agents relient les questions en langage naturel à des sources de données gouvernées et à des définitions métier.

Les recommandations de Microsoft soulignent que la qualité des réponses dépend de la préparation des modèles sémantiques pour l’IA. Les descriptions, les réponses vérifiées et les instructions aident l’agent à interpréter correctement le langage métier.

Ses recommandations sur les modèles sémantiques renforcent la même leçon que l’avertissement d’AWS aux curateurs. L’accès conversationnel fonctionne au mieux lorsqu’un contexte métier structuré existe déjà.

La compétition ne porte pas simplement sur le modèle qui écrit le meilleur SQL. Elle concerne la propriété de la couche située entre les données brutes de l’entreprise et l’employé qui pose une question.

Les plateformes de catalogues veulent gouverner cette couche. Les plateformes d’informatique décisionnelle veulent la consommer et l’enrichir. Les plateformes d’agents veulent raisonner sur elle et déclencher des actions.

Amazon AWS relie ces rôles dans Quick. L’aperçu de son catalogue réduit les frictions entre les métadonnées de gouvernance et l’interface analytique finale.

Cependant, Databricks et Microsoft se rapprochent eux aussi des utilisateurs métier. Ils n’entendent pas rester de simples fournisseurs passifs de métadonnées pendant qu’une autre plateforme s’approprie l’expérience conversationnelle.

Cette pression bénéficie aux clients si elle encourage des descriptions portables, des relations explicites et des requêtes tenant compte de l’identité. Elle crée un risque lorsque chaque plateforme ajoute une sémantique propriétaire qui se transfère mal.

Le choix architectural le plus solide de l’aperçu consiste à conserver le catalogue amont comme source de vérité. Cette approche limite la création d’une nouvelle copie non contrôlée des définitions d’entreprise.

Sa valeur à long terme dépendra de la fiabilité avec laquelle les modifications continueront de circuler. Un processus d’héritage ponctuel peut encore créer une dérive si les mises à jour ultérieures du catalogue n’atteignent pas les actifs Quick dépendants.

Comment Amazon Quick construit un Topic multi-jeux de données

Le mécanisme fonctionne parce que Quick transforme les objets du catalogue en un modèle analytique contraint, plutôt que de donner à un agent un accès illimité à tout.

Les jeux de données Quick représentent les actifs de catalogue sélectionnés. L’agent peut en créer plusieurs en masse une fois que le curateur a accepté ses recommandations.

Le flux de travail relie ensuite ces jeux de données au moyen de relations héritées ou inférées. Ces relations indiquent au moteur de requêtes comment joindre les champs de tables distinctes.

Le Topic obtenu fournit un conteneur sémantique pour l’analyse en langage naturel. Il contient les jeux de données, les relations, les définitions métier et les instructions nécessaires pour interpréter les questions des utilisateurs.

Amazon a récemment étendu les Topics multi-jeux de données dans le cadre d’un aperçu public distinct. Un Topic peut contenir jusqu’à 12 jeux de données, selon la présentation de la couche sémantique de l’entreprise.

Le moteur de requêtes interprète une question, identifie les colonnes utiles, suit les relations définies et construit le SQL requis. Il renvoie ensuite un tableau ou une visualisation.

Ce modèle répond à une limite de l’architecture antérieure de Quick Sight. Traditionnellement, un jeu de données apparaissait comme une table aplatie, et chaque visualisation ne pouvait utiliser qu’un seul jeu de données.

Les équipes joignaient souvent les tables sources dans un vaste jeu de données dénormalisé durant la préparation. Cette conception simplifiait l’exécution, mais rendait les domaines complexes plus difficiles à maintenir.

Les Topics multi-jeux de données permettent de conserver les jeux de données normalisés séparés. La couche sémantique décrit leurs relations, et Quick construit les jointures lorsqu’une question nécessite des champs provenant de plusieurs actifs.

Par exemple, un Topic de vente au détail peut relier les ventes, les retours, les clients, les produits, les magasins et les dates. Un responsable pourrait interroger les taux de retour par segment de clientèle et catégorie de produit.

Aucune table unique ne contient nécessairement cette réponse. Le moteur doit sélectionner les bonnes mesures, suivre des relations valides et éviter de multiplier les lignes par une jointure incorrecte.

L’héritage du catalogue peut réduire la charge de configuration de ce modèle. Lorsque Unity Catalog enregistre déjà les relations et les descriptions, Quick peut les réutiliser au lieu d’exiger une saisie manuelle.

AWS Glue fournit des descriptions de tables et de colonnes, tandis que Unity Catalog peut également fournir des relations. Les capacités exactes de l’aperçu varient selon la source et la méthode d’authentification.

Les descriptions ne constituent qu’un volet de l’exactitude sémantique. Le modèle d’enrichissement plus large de Quick inclut aussi les synonymes, les types sémantiques, les champs calculés, les exclusions et les instructions personnalisées.

Un synonyme peut associer « effectif » à un champ portant un nom technique. Un type sémantique peut indiquer au système qu’une colonne contient des devises, des dates, des villes ou des États.

Les instructions personnalisées peuvent encoder des calendriers fiscaux ou des définitions internes. Ces ajouts restent importants lorsque les métadonnées du catalogue amont ne contiennent pas le niveau de détail requis pour un public donné.

L’expérience de catalogue agentique accélère la construction initiale, mais elle n’élimine pas le travail d’affinage en aval. Les curateurs doivent toujours tester des questions réalistes et examiner les résultats générés.

DirectQuery crée également un compromis opérationnel. Il maintient les données et les autorisations plus près de la source, mais la vitesse des requêtes dépend de la plateforme amont et du SQL généré.

SPICE, le moteur d’analyse en mémoire d’Amazon, peut améliorer les performances interactives des données importées. Cependant, abandonner DirectQuery modifie le mécanisme de propagation de l’identité.

Les équipes doivent donc arbitrer entre fraîcheur, performances, gouvernance et besoins de transformation. L’aperçu ne réduit pas ces choix à une configuration universellement correcte.

Le mécanisme est utile parce qu’il automatise des tâches répétables. Il peut rechercher des métadonnées, créer des représentations, hériter de définitions et assembler un Topic candidat.

Les décisions les plus difficiles restent contextuelles. Les curateurs doivent choisir quels actifs doivent être regroupés, quelles relations sont sûres et quelles définitions métier nécessitent des précisions supplémentaires.

Les recommandations fluides exigent toujours un examen sceptique

Le principal risque n’est pas un flux de travail manifestement défaillant ; c’est une recommandation plausible qui encode discrètement une mauvaise signification métier.

AWS demande explicitement aux auteurs d’examiner chaque recommandation. Cela inclut les tables découvertes, les relations inférées et les descriptions héritées du catalogue source.

L’avertissement est particulièrement important pour les relations inférées. Un nom de colonne commun ne garantit pas que deux champs utilisent la même granularité, le même domaine ou le même calendrier de mise à jour.

Un identifiant client peut représenter un compte dans une table et une entité de facturation dans une autre. Les joindre peut produire des totaux crédibles qui restent néanmoins erronés.

La cardinalité crée un autre risque. Un agent peut identifier une jointure techniquement valide, mais ne pas anticiper les doublons causés par des relations plusieurs-à-plusieurs.

Ces échecs sont difficiles à détecter parce que le tableau de bord obtenu peut paraître soigné. Les explications en langage naturel peuvent également donner à une réponse incertaine une apparence d’autorité plus forte qu’elle ne l’est.

Les curateurs ont besoin de questions de test dont les résultats sont connus. Ils devraient comparer les résultats de Quick avec des tableaux de bord fiables, des requêtes approuvées et les attentes des responsables de domaine.

L’examen devrait également couvrir les cas négatifs. Un Topic fiable doit savoir quand le contexte sélectionné ne permet pas de répondre à une question en toute sécurité.

La qualité des métadonnées demeure un autre point de pression. Les catalogues contiennent souvent des descriptions incomplètes, des enregistrements de propriété obsolètes et des conventions de nommage incohérentes entre unités opérationnelles.

L’héritage sémantique préserve le travail existant, mais il préserve également les défauts existants. L’automatisation accélère la circulation des bons comme des mauvais contextes.

Les scores de qualité des données peuvent aider à classer les actifs, mais un score couvre rarement toutes les préoccupations sémantiques. La fraîcheur, l’exhaustivité et la validité ne prouvent pas qu’une table répond à la question visée.

La traçabilité peut montrer l’origine des données et leur parcours. Elle n’explique pas nécessairement pourquoi la finance et les ventes utilisent des définitions différentes pour une même étiquette.

La maturité de l’aperçu ajoute de l’incertitude. AWS n’a pas publié de références indépendantes sur l’exactitude du flux de travail complet, du catalogue au Topic, dans les documents examinés.

Il n’existe pas non plus de preuves publiques indiquant le temps que la fonctionnalité fait gagner aux curateurs pour différentes tailles de catalogue. Les affirmations concernant une livraison plus rapide devraient donc rester des affirmations de l’entreprise.

Le comportement multiplateforme mérite une prudence similaire. Les métadonnées Unity Catalog peuvent être riches, mais les organisations les configurent et les maintiennent différemment.

Un environnement Databricks bien gouverné offre des entrées plus utiles qu’un catalogue composé principalement de schémas techniques. L’intégration ne peut pas créer de toutes pièces des connaissances institutionnelles manquantes.

Les autorisations exigent des tests délibérés. Les équipes devraient vérifier les résultats sous plusieurs identités utilisateur plutôt que de supposer que la connectivité au catalogue garantit une application correcte des contrôles.

DirectQuery est nécessaire à la propagation de l’identité, mais la propagation de l’identité elle-même est facultative. Les administrateurs doivent comprendre quel plan de contrôle protège chaque jeu de données.

Le contexte suggéré par l’agent devrait aussi rester inspectable après sa création. Les curateurs ont besoin d’un registre clair des actifs sélectionnés, des définitions héritées, des relations inférées et des modifications manuelles.

Sans cette visibilité, le dépannage devient plus difficile. Une réponse erronée peut provenir des données sources, des métadonnées du catalogue, de l’inférence des relations, de la configuration du Topic ou du SQL généré.

Cela ne rend pas l’aperçu inexploitable. Cela définit le standard d’évaluation que les acheteurs d’entreprise devraient appliquer.

Un pilote utile devrait se concentrer sur un domaine métier circonscrit, avec des réponses de référence établies. L’équipe peut alors mesurer l’effort de configuration, les taux de correction et la cohérence des réponses.

Le meilleur résultat ne serait pas l’absence totale d’intervention humaine. Ce serait un assemblage plus rapide tout en préservant une responsabilité claire et une piste d’examen auditable.

Ce qu’il faut surveiller à mesure que l’aperçu s’étend

Trois signaux montreront si Amazon Quick devient un consommateur sémantique de confiance ou simplement un autre endroit où réparer des métadonnées.

Le premier signal est la qualité des retours de production des clients d’AWS Glue et de Databricks. Les équipes devraient surveiller la fréquence à laquelle les curateurs acceptent les recommandations sans correction substantielle.

Des taux d’acceptation élevés dans des catalogues bien gouvernés appuieraient le mécanisme d’AWS. Des substitutions fréquentes de tables ou des corrections de relations affaibliraient l’argument d’automatisation.

L’acceptation brute ne suffit pas. Les clients ont également besoin de réponses stables lorsque plusieurs utilisateurs formulent différemment la même question métier.

Le deuxième signal est la manière dont AWS gère les changements du catalogue après la création initiale. L’héritage sémantique n’a une valeur durable que si les équipes peuvent gérer les mises à jour sans dérive silencieuse.

AWS devrait préciser si les descriptions modifiées, les relations, les signaux de qualité et la traçabilité sont répercutés dans les actifs Quick existants. L’entreprise devrait aussi expliquer comment les conflits sont signalés.

Une synchronisation fiable renforcerait le modèle de source de vérité amont. Des réimportations manuelles réintroduiraient une grande partie de la charge de maintenance que le flux de travail promet de réduire.

Le troisième signal est la réponse concurrentielle de Databricks et Microsoft. Tous deux combinent déjà données gouvernées, contexte sémantique et interaction en langage naturel.

Databricks peut approfondir son propre parcours, de la découverte dans Unity Catalog à l’analyse métier. Microsoft peut resserrer les connexions entre Fabric, les modèles Power BI et les agents de données.

Si ces plateformes améliorent la portabilité intersystème, les clients gagnent davantage de liberté quant à la couche de consommation. Si la sémantique reste propriétaire, les coûts de changement augmenteront.

La disponibilité générale fournira un autre point de contrôle pratique parmi ces signaux. Les acheteurs devraient rechercher une prise en charge plus large des catalogues, des limites documentées, des contrôles administratifs et une fiabilité mesurable.

Amazon AWS a identifié le bon problème d’entreprise. L’analytique IA ne peut pas dépendre de noms de schémas et d’un accès illimité au catalogue.

L’aperçu utilise également une limite judicieuse. L’agent propose des actifs et des relations, tandis que le curateur approuve ce qui devient partie intégrante du contexte analytique.

AWS doit maintenant démontrer que cette répartition du travail résiste à la complexité réelle des catalogues. Une conversation de configuration fluide est utile, mais une analytique fiable exige une vérification reproductible.

Les équipes qui évaluent Amazon Quick devraient choisir un domaine disposant de métadonnées matures et de réponses connues. Elles devraient consigner chaque correction effectuée lors de la création des jeux de données et du Topic.

Elles devraient ensuite tester les autorisations, le comportement des relations, la cohérence des requêtes et les mises à jour du catalogue. Ces éléments montreront si le flux de travail réduit le travail de modélisation ou le déplace simplement.

La question plus large dépasse la veille économique. Chaque agent d’entreprise a besoin d’un pont contrôlé entre le langage d’un utilisateur et les informations réelles de l’organisation.

Amazon AWS propose désormais une version de ce pont. Les prochains mois montreront si les conservateurs peuvent le franchir plus rapidement sans renoncer au discernement qui garantit la crédibilité des données d’entreprise.