Sathya AG, Senior Principal Architect at Google – Série d’entretiens

Sathya AG est un évangéliste de la technologie, auteur publié de “Enterprise-Grade Hybrid and Multi-Cloud Strategies“, et Senior Principal Architect chez Google (Retail Strategic Industries), avec plus de 19 ans d’expérience dans l’architecture d’entreprise et l’IA. Un leader de pensée mondial reconnu avec le prix Top AI Influencer Award et le prix du président de Google, il est l’auteur de Enterprise-Grade Hybrid and Multi-Cloud Strategies et membre du conseil consultatif du CAIO Circle. Il est fellow de la British Computer Society (FBCS), membre senior de l’IEEE et diplômé de Stanford LEAD. Un conférencier recherché à AI Forward, Google Next et NRF, Sathya enseigne également l’AI/ML aux communautés défavorisées.

Avertissement : Les pensées partagées ci-dessous et les opinions exprimées sont celles de l’auteur et ne reflètent pas nécessairement les vues, les positions ou les opinions de son employeur ou de toute organisation avec laquelle il est affilié.

Vous avez passé plus d’une décennie chez Oracle (ORCL ) avant de rejoindre un rôle d’architecture senior chez Google, où vous travaillez maintenant avec de grandes entreprises de détail. Comment votre vision de l’IA d’entreprise a-t-elle changé à mesure que les entreprises sont passées de projets de modernisation de données traditionnels à des initiatives d’IA générative et d’IA agente ?

À l’époque d’Oracle, en tant qu’architecte d’entreprise, mon objectif principal était toujours de construire des systèmes complexes et solides sur lesquels les organisations comptent pour faire fonctionner leur entreprise. Nous résolvions des défis massifs d’intégration, de gouvernance et de gestion des données pour garantir que l’entreprise avait une source unique et très résiliente de vérité. La modernisation des données traditionnelles était fondamentalement une observation passive, conçue pour livrer des insights fiables aux décideurs humains.

L’évolution de l’IA générative et de l’IA agente a complètement changé le paradigme architectural de l’observation passive à un système d’action autonome. Maintenant, la lentille s’est déplacée vers la question de savoir si nous pouvons laisser un système agir en notre nom (et, correctement, sans surveillance), à grande échelle. C’est une barre beaucoup plus élevée pour la qualité des données, le contexte et le contrôle, car maintenant une mauvaise hypothèse de données ne produit pas seulement un tableau de bord incorrect, mais une action incorrecte. Un agent qui mal interprète les données d’inventaire ne trompe pas seulement quelqu’un, mais passe une commande incorrecte.

C’est là que l’architecture d’entreprise rigoureuse devient critique et fondamentale pour les systèmes d’IA. Pour construire des systèmes autonomes en toute sécurité, nous devons combler sans heurt l’écart entre les systèmes d’entreprise déterministes et les systèmes d’IA probabilistes. Les conversations d’architecture que je mène maintenant sont sur la construction d’un tissu de données fiable, en garantissant que la raison autonome en temps réel est liée à une gouvernance stricte, à une observabilité robuste et à la même intégrité transactionnelle que nous avons toujours exigée des systèmes d’entreprise.

Vous avez soutenu que de nombreux projets d’IA échouent non pas à cause du modèle, mais à cause des décisions d’architecture et de données prises beaucoup plus tôt. Quels sont les choix d’architecture les plus courants qui minent discrètement les projets d’IA plus tard ?

Celui que je vois le plus souvent, ce sont les entreprises qui traitent un entrepôt ou un lac comme la source unique de vérité, alors qu’il ne s’agit en réalité que d’une destination unique. Ils acheminent tout vers un endroit et supposent que cela résout le problème de la « version unique de la vérité », mais ce n’est pas le cas, cela centralise simplement le désaccord. Si trois systèmes source définissent un client actif différemment, les acheminer vers un seul entrepôt vous donne une seule mauvaise réponse au lieu de trois.

Ensuite, il y a le piège de la construction pour exactement ce qui se trouve devant vous. Un pipeline est réglé parfaitement pour un tableau de bord, fonctionne bien, et puis six mois plus tard, un nouveau modèle nécessite les mêmes données plus rapidement ou plus fraîches, et tout doit être détruit plutôt que d’être étendu.

Et celui qui revient toujours pour mordre les gens, c’est de sauter la lignée et les métadonnées parce que cela ressemble à une surcharge que personne n’a demandée. Cela n’a pas de rendement ; jusqu’au jour où quelqu’un demande pourquoi le modèle a fait un appel spécifique et qu’il n’y a pas de moyen de le retracer. C’est alors que cela se transforme en une solution coûteuse au lieu d’une décision de conception peu coûteuse.

Quand vous travaillez avec des entreprises du Fortune 500, quels signaux vous indiquent si une organisation est vraiment prête à mettre à l’échelle l’IA au-delà des pilotes ?

Honnêtement, je peux généralement le dire dans les premières conversations. La différence entre une organisation qui expérimente l’IA et une organisation prête à l’exploiter à grande échelle repose sur quelques signes révélateurs. Je regarde généralement la préparation dans trois principaux domaines : la conviction stratégique, l’intégration commerciale et la maturité opérationnelle.

Voici ce qui signale une véritable préparation pour mettre à l’échelle :

1. Alignement stratégique et conviction exécutive

Une stratégie d’IA claire, et non seulement de l’« envie d’IA » : le leadership de l’organisation démontre une conviction réelle quant à sa stratégie d’IA. Cela est facilement repérable en posant quelques questions pour savoir comment l’IA se rapporte aux objectifs commerciaux. Si ils peuvent articuler la valeur commerciale précise (par exemple, croissance des revenus, amélioration de la marge, ou expérience client) plutôt que de simplement vouloir « utiliser l’IA générative », ils sont prêts.

Financement d’entreprise engagé : ils sont allés au-delà des budgets de R&D isolés. Il y a un budget dédié, transversal, alloué non seulement pour les projets d’IA, mais également pour la gestion du changement, les infrastructures et la maintenance continue de l’MLOps.

2. Adaptation problème-solution et intégration commerciale

Résolution des bons problèmes : un signal d’alarme majeur est de confondre l’automatisation des flux de travail standard ou l’automatisation des processus robotiques (RPA) avec l’IA, et de forcer l’IA sur le dessus simplement pour montrer l’adoption de l’IA au conseil d’administration. Les organisations prêtes comprennent la valeur distinctive de l’IA. Ils se concentrent sur les cas d’utilisation où l’IA offre un changement de paradigme en termes de capacité, plutôt que de simplement cocher une case technologique sur un processus legacy.

Propriété de l’unité commerciale : c’est un signal plus silencieux, mais souvent le plus grand obstacle à la mise à l’échelle. Si l’enthousiasme pour l’IA vit entièrement dans un « laboratoire d’innovation » isolé, sans aucun intérêt de la part des unités commerciales réelles, les pilotes échoueront à décoller. La préparation réelle est signalée lorsque les parties prenantes commerciales développent activement la solution et possèdent le résultat commercial final, plutôt que de lancer un concept de preuve sur le mur des opérations.

3. Maturité opérationnelle et gouvernance

Engagement de la sécurité et de la conformité dès le premier jour : un manque d’implication des équipes de sécurité et de gouvernance, ou essayer de cordoner une utilisation critique de l’IA pour « aller plus vite », est une recette pour l’échec du déploiement. Les organisations matures impliquent les équipes InfoSec, juridiques et de gouvernance des données dès le premier jour. Ils considèrent ces équipes comme des facilitateurs critiques qui construisent les garde-fous nécessaires pour mettre à l’échelle en toute sécurité, et non comme des obstacles.

En fin de compte, les organisations qui mettent à l’échelle avec succès l’IA la traitent non comme une expérience scientifique en IT, mais comme une capacité commerciale transformatrice avec le parrainage approprié, les garde-fous appropriés et l’alignement commercial approprié.

Quelle est la véritable apparence d’une fondation de données prête pour l’IA, en particulier pour les entreprises avec des données fragmentées sur ERP, CRM, commerce, cloud et systèmes legacy ?

La plupart des entreprises n’ont pas un problème de volume de données, mais plutôt un problème de confiance dans les données. C’est ce qui se trouve exacerbé avec l’IA superposée. Il ne s’agit pas d’avoir une plate-forme neuve et brillante, mais plutôt d’une poignée de propriétés peu glamour qui tiennent vrai à travers les systèmes.

Par exemple, le même client, produit ou magasin doit être reconnu comme la même entité, qu’il soit dans un ERP legacy, un CRM moderne ou une plate-forme de commerce. Si vos systèmes ne peuvent pas s’accorder sur qui est un client, vos modèles de personnalisation et de prévision de l’IA travaillent à partir de données fracturées, aboutissant à une image hallucinée. Vous ne pouvez pas prédire la valeur du client à vie si votre IA traite un client comme trois personnes différentes.

Deuxièmement, la fraîcheur des données qui correspond à la décision, et non par défaut à ce que le système source se trouve à faire. Les mises à jour d’inventaire nocturnes sont bonnes pour la planification à long terme et inutiles pour la livraison en temps réel ; une fondation solide prend en charge les deux vitesses sans aplatir tout à la vitesse la plus lente.

Troisièmement, une couche de lignée qui vous permet de répondre à « d’où vient ce chiffre » en quelques minutes, et non après une enquête de plusieurs jours. La plupart des entreprises fragmentées ne manquent pas de données, mais plutôt d’une couche qui rend les données qu’elles possèdent déjà fiables et traçables. C’est la fondation réelle, et non l’outil qui se trouve fixé au-dessus.

Vous discutez souvent des 5 V des données : Volume, Vitesse, Variété, Véracité et Valeur. Lequel de ces aspects les dirigeants d’entreprise tendent-ils à sous-estimer le plus lors de la préparation des données pour l’IA ?

La véracité des données, sans conteste, suivie de près par la valeur des données.

Le volume est acquis dans l’écosystème de données actuel. Tout le monde se noie dans les données. La variété et la vitesse obtiennent un budget car elles sont visibles sur une feuille de route – nouvelles sources, pipelines et flux en temps réel.

La véracité est invisible jusqu’à ce qu’elle coûte quelque chose – généralement, un modèle produit une sortie évidemment incorrecte, et quelqu’un la retrouve jusqu’à des enregistrements de clients en double ou un champ que trois équipes remplissent de trois manières différentes.

Enfin, la valeur est sous-estimée différemment – les dirigeants supposent que si les données existent, elles ont de la valeur, sans se demander si elles déplacent réellement une décision. La plupart des entreprises ont une petite fraction de leurs données qui font vraiment du travail, et personne n’a cartographié quelle fraction est celle-ci.

En particulier dans le domaine de la vente au détail, les cas d’utilisation de l’IA peuvent s’étendre à la personnalisation, à la prévision, à l’inventaire, à la chaîne d’approvisionnement, au service client et aux opérations de magasin. Où voyez-vous le plus grand écart entre l’ambition de l’IA et la préparation des données ?

Alors que l’ambition de l’IA est répartie uniformément dans le commerce de détail, la préparation des données est fortement asymétrique.

La personnalisation et la prévision ont une préparation raisonnable – les détaillants ont collecté des données de transaction et de navigation pendant des années.

L’écart plus important est la chaîne d’approvisionnement et le commerce omnicanal, en particulier la connexion entre les magasins en ligne et physiques. Le commerce omnicanal est incroyablement complexe car il oblige un détaillant à résoudre deux des problèmes de données les plus difficiles en temps réel : l’identité client unifiée et l’inventaire fluide. La plupart des détaillants ont un inventaire en temps réel pour le commerce électronique, mais seulement une visibilité périodique, parfois en fin de journée, sur le stock au niveau du magasin.

Le service client et les opérations de magasin sont encore dans les premiers stades. L’ambition est élevée, mais les données opérationnelles sous-jacentes, c’est-à-dire le personnel, l’achèvement des tâches, les conditions réelles du magasin, sont souvent la partie la moins numérisée de l’entreprise. L’ambition est répartie uniformément sur ces cas d’utilisation ; la préparation ne l’est pas.

Comment les entreprises doivent-elles moderniser leur infrastructure de données legacy sans perturber les systèmes critiques de mission qui sont encore essentiels au fonctionnement quotidien de l’entreprise ?

Les plates-formes de données legacy souffrent souvent de goulets d’étranglement opérationnels, de problèmes graves de qualité des données et de limites de mise à l’échelle organisationnelle. La manière la plus efficace de protéger les opérations quotidiennes pendant un voyage de modernisation est d’éviter strictement une migration unique à haut risque. L’objectif principal de la modernisation de la plate-forme de données doit être de rendre les données démontrablement plus utiles pour la prise de décision organisationnelle, plutôt que de traiter l’effort comme un simple échange de plate-forme IT.

Pour répondre à l’ère de l’IA, les organisations doivent adopter une architecture de données en médaille et en mesh. Cette stratégie crée un pipeline structuré où les données sont raffinées progressivement de brutes à prêtes pour les entreprises, empêchant efficacement les données de mauvaise qualité d’atteindre la prise de décision. En séparant les données en couches logiques distinctes, les organisations établissent une lignée claire, ce qui facilite la traçabilité de la façon dont les informations se transforment de la source à la destination.

En emballant les données vérifiées en produits accessibles, les organisations habilitent leurs équipes à prendre des décisions stratégiques et fondées sur des preuves, plutôt que de s’appuyer sur l’intuition. De manière cruciale, cette approche établit les fondements de la confiance dans les données nécessaires à l’IA d’entreprise. La construction d’agents d’IA sur des produits de données curatifs garantit que les modèles apprennent à partir d’informations sécurisées et exactes, plutôt que de jeux de données désordonnés et non vérifiés.

La gouvernance est souvent ajoutée après qu’un projet d’IA est déjà en cours. Qu’est-ce qui change lorsque la gouvernance, la confidentialité, la sécurité et la qualité des données sont traitées comme des exigences d’architecture dès le premier jour ?

Tout se déplace plus vite, se brise moins et se met à l’échelle mieux. Avec la nature probabiliste de l’IA générative, la gouvernance est extrêmement critique, mais c’est également l’aspect le plus négligé dans de nombreuses organisations.

Lorsque vous traitez ces éléments comme des exigences d’architecture dès le premier jour, plutôt que comme une liste de contrôle d’audit de dernière minute, vous passez de la gestion des dommages à la vitesse. Voici ce qui change :

Tout d’abord, vous évitez la phase douloureuse de « déchirure et remplacement » où des projets d’IA entièrement construits sont mis au rebut parce qu’ils violent les normes de conformité ou de confidentialité.

Ensuite, la sécurité et la qualité des données ne sont pas corrigées ; elles sont intégrées dans le pipeline. Vos modèles s’exécutent sur des données fiables, produisant des sorties que la direction et les utilisateurs font vraiment confiance.

Enfin, au lieu de heurter un mur réglementaire lors du passage de la preuve de concept à la production, le chemin du déploiement est déjà dégagé et automatisé.

En bref, la gouvernance n’est pas un frein à l’innovation ; c’est le système de direction qui vous permet de conduire rapidement en toute sécurité.

En tant que conseiller du CAIO Circle, comment pensez-vous que le rôle du Chief AI Officer devrait évoluer, et où devraient commencer et se terminer ses responsabilités par rapport au CIO, au CDO et aux dirigeants d’unités commerciales ?

Faire partie du CAIO Circle a été une fenêtre vraiment utile pour cela, car actuellement, le rôle est partout parce que de nombreuses entreprises l’ont créé de manière réactive, en réponse à l’hype de l’IA générative, plutôt que de combler un vide opérationnel clair. Je crois que cela va se stabiliser rapidement et qu’il le faut. Pour fonctionner efficacement, la répartition des exécutifs devrait être nette :

Le CIO possède l’infrastructure et la fiabilité du système. Le CDO possède les données en tant qu’actif d’entreprise (sa qualité, sa gouvernance et son accessibilité). Le CAIO possède la couche de traduction entre la capacité brute de l’IA et les résultats commerciaux réels.

Cette couche de traduction signifie prendre explicitement possession du portefeuille d’IA, déterminer ce qui doit être construit, identifier les domaines d’activité qui peuvent être améliorés et mieux servis par la technologie d’IA, et servir d’autorité ultime pour savoir où l’IA doit ou ne doit pas être déployée.

Le plus grand écart dans la plupart des entreprises aujourd’hui est l’évaluation des risques et des compromis entre les unités commerciales concurrentes. Bloquer une initiative d’IA à haut risque que seule une unité commerciale désire ardemment nécessite quelqu’un dont les incitations ne sont pas liées aux cibles à court terme de cette unité et qui est suffisamment technique pour évaluer le risque directement. C’est exactement ce que le rôle du CAIO doit devenir.

En regardant vers l’avenir, qu’est-ce qui séparera les entreprises qui atteignent un avantage durable de l’IA de celles qui expérimentent simplement avec les derniers outils d’IA ?

Ce ne sera pas ceux qui ont accès aux meilleurs modèles. La capacité des modèles converge rapidement, et la technologie brute ne restera pas un facteur de différenciation durable.

Au lieu de cela, la principale épreuve du succès à long terme de l’IA – que ce soit interne ou axé sur le client – repose sur une chose : la confiance.

La confiance est directement proportionnelle à la capacité d’une organisation à construire une fondation prête pour l’IA et un environnement dans lequel de nouvelles capacités peuvent être testées, déployées en toute sécurité et mises à l’échelle à grande vitesse. Concrètement, cela nécessite trois choses :

Une fondation de données fiable : des données propres et fiables, de sorte que chaque nouveau cas d’utilisation ne nécessite pas un projet de nettoyage massif.

Une gouvernance agile : des processus de risque et de conformité suffisamment rapides pour suivre l’évolution des modèles sous-jacents.

Des métriques axées sur les résultats : une culture organisationnelle qui mesure l’IA par la valeur commerciale, et non par la sophistication technologique.

Les entreprises qui seront encore bloquées dans le « mode expérimental » dans trois ans seront celles qui n’ont jamais construit cette fondation – elles continueront à réapprendre les mêmes leçons de données et de gouvernance sur chaque projet d’IA.

Les gagnants avec un avantage durable seront ceux où le dixième cas d’utilisation de l’IA deviendra dramatiquement moins cher et plus rapide à déployer que le premier, parce que la fondation a été construite correctement dès le premier jour.

Je vous remercie pour cette grande interview, les lecteurs peuvent également lire son livre Enterprise-Grade Hybrid and Multi-Cloud Strategies.