Databricks et Infosys : pourquoi les données, non les modèles, bloquent le déploiement de l'IA

Les entreprises discutent de plus en plus d'intelligence artificielle au niveau du conseil d'administration, mais le déploiement réel de l'IA en entreprise est souvent entravé non par les modèles ou les calculs, mais par l'état des données d'entreprise. Alors que les services grand public ont habitué le marché à attendre un impact instantané, au sein des grandes organisations, il devient rapidement clair que sans une infrastructure de données unifiée, gérée et opérationnellement appropriée, l'IA reste une belle démonstration et non un outil fonctionnel. Le problème principal est que les données d'entreprise vivent généralement dans trop de couches différentes.

Certaines résident dans des marts analytiques et des lacs de données, certaines dans des systèmes transactionnels comme CRM, ERP et les applications internes, et le reste est dispersé dans des fichiers, des e-mails, des bases de connaissances, des tickets et des services cloud. Pour les rapports typiques, un tel paysage peut encore être toléré. Mais quand une entreprise veut donner à un modèle un accès en temps réel aux données, intégrer l'IA dans les processus ou lancer des agents qui non seulement répondent aux questions mais exécutent également des actions, la fragmentation devient une limitation directe.

Un modèle peut être puissant, mais s'il ne peut pas voir le contexte actuel, ne comprend pas la lignée des données et ne fonctionne pas dans le cadre de droits d'accès clairs, le résultat devient instable et risqué. C'est précisément pour cette raison que la conversation sur l'IA d'entreprise se déplace de plus en plus des modèles vers l'architecture. L'une des thèses clés est que les entreprises ne ont pas besoin d'un ensemble d'outils IA disparates, mais d'une nouvelle data stack où les données sont stockées dans des formats ouverts, décrites par des métadonnées, accessibles par le biais de politiques unifiées et convenables simultanément pour l'analyse et les scénarios opérationnels.

D'où l'intérêt pour les architectures qui comblent le fossé entre les mondes OLAP et OLTP : d'un côté, les entreprises ont besoin de la profondeur de l'analyse, de l'historique et de l'échelle, de l'autre — de la faible latence, de la transactionnalité et de la capacité à agir rapidement. Dans cette approche, Databricks promeut Lakebase comme une couche Postgres sans serveur pour les charges de travail IA opérationnelles, et Unity Catalog comme une couche unifiée pour la gestion des accès, la traçabilité des données et la gouvernance pour les données et les actifs IA. L'enjeu ne sont pas les produits spécifiques, mais la tendance elle-même : les entreprises ont besoin d'une base sur laquelle l'IA peut fonctionner en production, pas seulement dans un pilote.

Une question à part est comment mesurer l'impact. À un stade précoce, les entreprises se contentent souvent de métriques attrayantes comme le nombre de requêtes de chatbot ou le pourcentage d'employés qui ont ouvert des copilots. Mais au fur et à mesure qu'elles mûrissent, ce n'est plus suffisant.

Si l'IA doit automatiser les processus, réduire les cycles d'opération, augmenter la conversion ou créer de nouvelles sources de revenus, elle doit être évaluée comme un système métier à part entière. Par conséquent, dans la discussion d'une nouvelle data stack, la question de mesurer la valeur apparaît également : l'impact de l'IA doit être lié non au facteur wow, mais aux résultats commerciaux concrets. C'est particulièrement important à mesure que nous passons à l'IA à base d'agents, où le modèle gagne plus d'autonomie, et donc les exigences en matière d'observabilité, de journalisation, de qualité des données et de politique d'accès deviennent beaucoup plus strictes.

L'évolution de l'IA d'entreprise ici semble assez claire. D'abord, les entreprises déploient des outils individuels de productivité — des assistants pour la recherche, la résumé, l'écriture de code ou la préparation de documents. Ensuite, elles passent à l'automatisation des processus : traitement des tickets, routage des tâches, support interne, scénarios financiers et opérationnels.

Et ce n'est qu'après que la troisième phase s'ouvre — le lancement de nouveaux produits et lignes d'activité qui sont construits autour de l'IA dès le départ. À chaque étape successive, les exigences en matière de données augmentent. Ce qui fonctionnait encore pour un copilot personnel ne fonctionne plus pour un processus où la précision, un enregistrement complet des actions et la capacité à exécuter en toute sécurité des opérations au nom de l'entreprise sont nécessaires.

D'où la conclusion principale : la prochaine bataille pour l'IA d'entreprise ne concerne pas la meilleure interface de modèle, mais la restructuration des données pour l'utilisation par des machines. Les entreprises qui gagneront sont celles qui ont réussi à unifier, gérer et rendre les données compatibles avec des scénarios basés sur des agents. Pour les entreprises, cela signifie une vérité inconfortable mais utile : le chemin vers l'IA à l'échelle ne commence pas par le choix d'un modèle, mais par la reconstruction de la data stack.