Alors que les entreprises s’empressent de développer des agents IA capables d’analyser les données métier et d’agir en conséquence, Databricks affirme que la pratique consistant depuis longtemps à séparer les systèmes de données opérationnelles et analytiques devient un frein. Selon le fournisseur en data store, cette séparation est de plus en plus mise à rude épreuve, car les agents IA ont besoin d’un accès simultané aux données opérationnelles en temps réel et au contexte historique pour prendre des décisions et agir en temps réel. Contrairement aux humains qui travaillent avec des données traitées les unes après les autres. Lors de son sommet annuel Data + AI Summit organisé du 15 au 18 juin à San Francisco, l'éditeur a présenté - aux côtés de Gernie Ontology - lake transactional and analytical processing (LTAP), une architecture qui unifie les données transactionnelles et analytiques sur une seule couche de stockage. Selon Databricks, cette approche se distingue des architectures traditionnelles de traitement transactionnel en ligne (online transaction processing, OLTP) et de traitement analytique en ligne (online analytical processing, OLAP), stockant généralement les données opérationnelles et analytiques dans des systèmes distincts.

Historiquement, les bases de données OLTP sont optimisées pour exécuter des opérations métier quotidiennes comme le traitement des commandes, les paiements et les mises à jour des stocks, tandis que les systèmes OLAP sont conçus pour les requêtes analytiques et le reporting à grande échelle. Pour cette raison, les entreprises doivent souvent recourir à des pipelines ETL (extract, transform and load), à la réplication des données et à des infrastructures distinctes pour transférer les informations entre ces deux environnements. Selon Databricks, le modèle LTAP évite le recours aux pipelines ETL, aux bases de données répliquées ou aux copies de données distinctes en stockant les données une seule fois dans une couche de lakehouse partagée. Tout en permettant à des moteurs de calcul dédiés de traiter indépendamment les charges de travail transactionnelles et analytiques. L’entreprise fait valoir qu’avec cette approche, les agents et les applications pilotés par l’IA peuvent accéder à la fois aux données opérationnelles en temps réel et au contexte analytique historique, sans nécessiter de transférer ou dupliquer des données.

Simplicité le travail des développeurs à l’ère des agents

Les analystes partagent également l’avis de Databricks selon lequel les agents IA imposent de nouvelles exigences aux architectures de données d’entreprise. « Les agents ne se comportent pas comme des personnes, ni même comme les applications que nous avons conçues pour eux. Ils analysent le contexte, effectuent des boucles, testent différentes approches, puis renvoient des informations, et ce des milliers de fois, d’une manière que l’on ne peut pas entièrement prévoir. À un tel volume, les allers-retours constants entre les systèmes de production et d’analyse commencent à constituer un goulot d’étranglement. La pression pour combler ce fossé est bien réelle, et le modèle LTAP est une façon d’y parvenir », a avancé Michael Leone, analyste principal chez Moor Insights and Strategy. Selon Bhupendra Chopra, cofondateur et directeur commercial (CRO) du cabinet de conseil en informatique Kanerika, le modèle d’accès aux données d’un agent autonome fragilise les architectures traditionnelles. « Nous le constatons directement chez les clients déployant des systèmes multi-agents : la couche de pipeline devient presque immédiatement un goulot d’étranglement, car un agent s’exécute des centaines de fois par tâche », a-t-il rapporté.

Les analystes font également remarquer que la capacité à combler le fossé entre l’OLAP et l’OLTP devrait aider les développeurs à concevoir des agents ou des applications IA plus robustes, que les entreprises cherchent actuellement à déployer. « Les modèles de workflow ou d’application les plus intéressants sont des applications en temps réel et sensibles au contexte qui combinent transactions, analyses et IA en un seul flux », a estimé Stephanie Walter, responsable de la pratique IA Stack chez Hyperframe Research. « C’est le cas, par exemple, des agents IA qui mettent à jour les workflows clients tout en tenant compte de l’historique du compte, ainsi que des systèmes de lutte contre la fraude qui agissent sur les transactions en temps réel et les schémas comportementaux à long terme », a expliqué Stéphanie Walter. Cependant, selon Michael Leone, concevoir de telles applications aujourd’hui obligerait les développeurs à rassembler des données provenant de systèmes transactionnels, d’entrepôts de données, de bases de données vectorielles et d’autres sources via des intégrations sur mesure, ce qui entraînerait une complexité technique importante et des coûts de maintenance élevés.

Simplicité opérationnelle et gains de gouvernance pour les DSI

Ashish Chaturvedi, responsable de la recherche exécutive chez HFS Research, pense que pour les DSI, la capacité du LTAP à réduire cette complexité technique se traduira par une simplification opérationnelle et par des économies. « L’avantage le plus notable serait la réduction du nombre de pipelines de données et toutes les retombées positives découlant de leur suppression. La plupart des entreprises ne savent pas quelle part de leur budget d’ingénierie des données est consacrée à la simple maintenance de l’infrastructure », a ajouté Ashish Chaturvedi. Bhupendra Chopra estime quant à lui qu’une part substantielle des capacités d’ingénierie des données dans les moyennes et grandes entreprises était consacrée aujourd’hui au maintien de la synchronisation entre les systèmes transactionnels et analytiques.

Cependant les implications ne se limitent pas à la productivité des développeurs, à la simplicité architecturale ou aux économies de coûts. « L’enjeu stratégique réside dans la simplification de la gouvernance. Lorsque l’on dispose d’une seule copie des données sous un modèle de gouvernance unique, plutôt que d’avoir ces mêmes données dispersées entre des magasins opérationnels, des répliques, des entrepôts de données et des bases de données vectorielles, on a résolu le problème de la fragmentation de la gouvernance », assure Ashish Chaturvedi. Même son de cloche du côté de Bhupendra Chopra qui pense également que cette simplification aura une importance opérationnelle pour les entreprises déployant plusieurs agents d’IA. Pourquoi ? Parce que slon lui ces workflows peuvent amplifier les lacunes de gouvernance à une vitesse et à une échelle jamais atteintes par aucun workload humain.

LTAP versus HTAP

Malgré tous ses avantages, le LTAP n’est pas la première initiative d’unification des charges de travail opérationnelles et analytiques sous une architecture unique. Un objectif similaire avait déjà été visé au travers de l’architecture HTAP (hybrid transactional and analytical processing) qui visait à combiner les workloads opérationnels et analytiques sur une même infrastructure et à partir d’un même système. « Le LTAP, a contrario, sépare le stockage de la puissance de calcul, ce qui permet à différents moteurs d’accéder à une couche de données commune tout en conservant une évolutivité indépendante », explique Databricks. C’est cette séparation des moteurs de calcul qui conduit les analystes à penser que le LTAP pourrait constituer un meilleur choix que HTAP. « HTAP n’a jamais décollé, car demander à un système étroitement lié d’exceller à la fois dans les transactions et dans l’analyse le rendait généralement médiocre dans les deux domaines, si bien que les clients finissaient par payer un supplément pour ce compromis », a rappelé Michael Leone.

« Séparer le stockage de la puissance de calcul est la bonne approche, et c’est précisément cette stratégie qui a permis au monde moderne des données dans le cloud de fonctionner dès le départ. C’est important car ce qui a causé la perte de l’architecture HTAP, c’est qu’une charge de travail privait l’autre de ressources, et donner à chaque partie son propre moteur dédié est exactement ce qu’il faut pour éviter que cela ne se produise », a affirmé Michael Leone. David Menninger, directeur exécutif de la recherche logicielle chez ISG, attribue aussi l’échec du HTAP dans le fait qu’il obligeait les entreprises à remplacer leurs plateformes de données existantes par une nouvelle architecture. « Le LTAP, en revanche, s’appuie sur la pratique désormais courante consistant à séparer le calcul et le stockage, ce qui fait de l’ajout d’une couche opérationnelle une transformation architecturale moins importante et réduit potentiellement les obstacles à son adoption », souligne David Menninger.

Pas encore d’architecture par défaut pour les agents IA

Cependant, malgré l’enthousiasme suscité par le LTAP, les analystes pensent que les DSI ne devraient pas considérer cette architecture comme le successeur inévitable des architectures de données existantes. « Les DSI devront toujours choisir leur architecture de données en fonction de la latence, de la fiabilité, de l’adéquation avec l’écosystème, du coût, de la conformité et de l’expérience des développeurs », assure Stéphanie Walter. De son côté Ashish Chaturvedi pense que pour que le LTAP devienne la norme de facto du secteur à condition que Databricks aille au-delà d'une architecture bien conçue : « Certes, sur le papier, l’architecture semble solide, mais la preuve viendra des chiffres de latence entre la validation et la requête sous une charge réelle », assure le responsable de la recherche exécutive chez HFS Research.

LTAP devrait être lancé prochainement dans le cadre de Lakebase, mais Databricks n’a à ce jour pas fourni de calendrier précis à ce sujet.