L'IA d'entreprise devient un projet d'architecture de données

Au cours de leur première phase, les programmes d’IA d’entreprise se sont concentrés sur les modèles. Les dirigeants ont comparé les fournisseurs, les équipes techniques ont testé des invites et les services ont recherché des applications capables de résumer des documents, de répondre aux questions des employés ou d’automatiser les tâches répétitives. Alors que les entreprises passent de projets pilotes isolés à des systèmes de production, un problème technologique de longue date prend de plus en plus d’importance : les données organisationnelles ont rarement été conçues pour être analysées en continu par des machines.

Une démonstration de faisabilité peut masquer cette faiblesse, car les équipes choisissent généralement un ensemble de documents facile à gérer, corrigent les incohérences manifestes et fournissent au modèle des informations qu’elles maîtrisent déjà. Les environnements de production se comportent différemment. Les données clients sont réparties sur plusieurs systèmes, les noms de produits ont évolué au fil du temps, les documents comportent des versions contradictoires et les droits d’accès reflètent des structures organisationnelles que personne n’a revues depuis des années.

L'IA générative met rapidement en évidence ces incohérences, car le modèle traite les informations récupérées comme faisant partie intégrante des données à partir desquelles il élabore une réponse. Si deux textes réglementaires se contredisent, l'IA doit choisir entre les deux ou les concilier ; si personne ne sait lequel fait autorité, même un raisonnement plus performant du modèle ne peut remédier de manière fiable à la défaillance de gouvernance sous-jacente.

La propriété des données fait donc partie intégrante de l'architecture de l'IA. Il faut que quelqu'un soit chargé de déterminer quelles informations sont à jour, qui est habilité à les modifier et comment réagir en cas de divergence entre les systèmes. Les organisations qui n'ont jamais défini ces responsabilités peuvent tout de même mener des analyses, car les collaborateurs expérimentés savent souvent à quel rapport se fier, tandis qu'un système automatisé nécessite que ces conventions tacites soient explicitement formulées.

Les informations non structurées aggravent le problème. Les connaissances de l'entreprise se trouvent dans des présentations PowerPoint, des fils de discussion par e-mail, des fichiers PDF, des comptes-rendus de réunion et des espaces de stockage partagés, ainsi que dans des bases de données soigneusement gérées. L'IA permet de rechercher et d'exploiter ces ressources à grande échelle, ce qui explique précisément pourquoi des incohérences qui restaient auparavant enfouies dans des dossiers distincts commencent à affecter les résultats générés automatiquement.

Les métadonnées revêtent une importance particulière, car un modèle a besoin de plus que le document lui-même. La date de création, le propriétaire, le niveau de confidentialité, le produit, la juridiction et la durée de validité peuvent déterminer si une information doit figurer dans une réponse donnée, ce qui permet aux systèmes de recherche d'affiner le contexte avant que le modèle ne commence son raisonnement.

Les autorisations doivent faire l'objet d'une attention tout aussi grande. Donner à un assistant IA l'accès à tous les documents qu'un employé pourrait théoriquement trouver risque de révéler des informations que les systèmes existants maintenaient dans l'ombre, non pas par un contrôle d'accès délibéré, mais par simple inconvénient. Dès lors que l'IA est capable d'effectuer des recherches dans des milliers de fichiers en quelques secondes, les organisations se rendent compte que l'autorisation technique et le besoin métier légitime sont deux concepts distincts.

L'architecture des données doit donc contrôler l'accès avant que les informations n'atteignent le modèle. Un système doit savoir quel employé, agent ou application a émis la requête et ne récupérer que les données que cette entité est autorisée à utiliser, plutôt que de compter sur le modèle linguistique pour ignorer les informations sensibles après leur réception.

Les infrastructures héritées compliquent la transition, car de nombreuses entreprises ne peuvent pas simplement transférer des décennies de données vers une seule plateforme moderne. Les systèmes centraux peuvent assurer le bon fonctionnement des entreprises malgré des architectures conçues bien avant l’apparition de l’IA générative, tandis que des contraintes réglementaires ou opérationnelles rendent une migration totale irréaliste.

Les architectures hybrides permettent aux organisations de laisser les informations là où elles se trouvent déjà, tout en créant des couches régies par des règles de gouvernance à travers lesquelles les applications d’IA peuvent y accéder. Cette approche privilégie la praticité au détriment de la pureté architecturale, même si elle exige une cohérence en matière d’identité, de métadonnées et de gouvernance dans tous les environnements, qui peuvent inclure le cloud public, une infrastructure privée et des bases de données existantes.

Les données en temps réel imposent une nouvelle exigence, car les agents commencent à agir plutôt que de se contenter de répondre à des questions. Un assistant IA chargé de résumer les ventes du dernier trimestre peut tolérer un certain délai, tandis qu’un agent qui doit vérifier la disponibilité d’un article avant de promettre une livraison a besoin d’informations opérationnelles en temps réel. Plus l’IA s’intègre aux processus métier, moins les instantanés de connaissances statiques sont utiles.

La qualité des données doit également être évaluée en fonction de l'application. Un assistant marketing peut se contenter d'une description incomplète d'un client, tandis qu'un processus automatisé de conformité ne peut pas considérer en toute sécurité les informations manquantes comme un simple désagrément. Les organisations doivent donc définir des seuils de qualité liés aux conséquences d'une utilisation incorrecte des données par le système d'IA.

Il peut être difficile de justifier financièrement les travaux d'infrastructure, car les dirigeants se sont lancés dans l'IA en espérant une automatisation plutôt qu'un énième programme de gestion des données s'étalant sur plusieurs années. Les équipes techniques doivent éviter de transformer chaque déploiement en prétexte pour refondre l'architecture d'entreprise de A à Z, tout en rejetant l'idée selon laquelle des modèles de plus en plus performants pourraient compenser indéfiniment le manque d'organisation des informations.

Les améliorations modestes et ciblées s'avèrent souvent plus efficaces. Une entreprise peut identifier un processus clé, définir les sources faisant autorité dont elle a besoin, corriger les autorisations et les métadonnées associées à ces sources, puis étendre le projet une fois qu'elle a démontré la fiabilité du système.

Ce processus permet de créer une infrastructure réutilisable, car la deuxième application d’IA peut s’appuyer sur le travail déjà réalisé en matière d’identité, de gouvernance et de qualité des données pour la première. Au fil du temps, l’organisation met en place une couche d’informations prête pour l’IA grâce à des cas d’utilisation déployés, plutôt que de chercher à perfectionner chaque ensemble de données avant que quiconque n’en tire de la valeur.

Le marché des modèles continuera d'évoluer rapidement, et le système qui domine aujourd'hui pourrait perdre cette position en l'espace de quelques mois. Les données d'entreprise évoluent beaucoup plus lentement, car les dossiers clients, les contrats et l'historique des opérations appartiennent à l'entreprise plutôt qu'au fournisseur de modèles.

Les entreprises qui traitent modèles La stratégie globale en matière d'IA risque donc de privilégier l'optimisation de l'élément le plus facile à remplacer. Le véritable travail consiste à veiller à ce que les informations organisationnelles soient suffisamment encadrées, accessibles et fiables pour que le prochain modèle, quel qu'il soit, puisse les exploiter correctement.