Pourquoi 91 % des entreprises adoptent l'IA sans savoir quelles données elles lui confient
L'intelligence artificielle générative est arrivée dans la majorité des organisations non pas par le département technologique, mais par la porte dérobée des applications de productivité. Microsoft 365 Copilot, Gemini, les assistants intégrés dans les plateformes de collaboration : ces outils ont été activés dans des environnements d'entreprise où les employés travaillaient déjà, et c'est ainsi qu'a commencé une expérience silencieuse dont personne n'avait vraiment négocié les termes.
Le problème ne réside pas dans les modèles de langage. Il réside dans ce que ces modèles trouvent lorsqu'ils se connectent à une organisation réelle.
Selon le rapport de Huble sur la préparation des données pour l'IA, seulement 8,6 % des entreprises se considèrent comme entièrement prêtes à opérer avec l'intelligence artificielle. Les 91 % restants se situent quelque part entre l'expérimentation et la stagnation, malgré des engagements en termes de budget, de temps et de réputation interne dans des projets d'adoption. Deloitte, dans son rapport 2026 sur l'état de l'IA en entreprise, note que deux tiers des organisations rapportent des gains de productivité, mais documente également des déficits persistants en matière d'infrastructure, de gestion des données, de talents et de contrôle des risques. La croissance de l'accès des travailleurs aux outils d'IA a été de 50 % en 2025. La préparation à gérer cet accès n'a pas progressé au même rythme.
Cet écart n'est pas accidentel. Il est structurel. Et il a une cause que peu d'organisations sont prêtes à nommer sans euphémismes : les données d'entreprise sont, pour la plupart, dans un état de désordre profond.
Ce que l'assistant trouve quand personne ne regarde
Lorsqu'une entreprise active un copilote d'IA au sein de son environnement de productivité, ce système ne crée pas de nouvelles portes d'accès. Il utilise celles qui existent déjà. Il opère avec les permissions héritées de l'utilisateur qui l'active et accède exactement là où cet utilisateur peut accéder, avec une différence opérationnelle qui change tout : il le fait à la vitesse d'une machine.
Microsoft documente avec précision ce fonctionnement. Son architecture Copilot établit que le système opère à l'intérieur du périmètre du service, limité à l'utilisateur authentifié et aux contenus auxquels cette personne a accès de manière autorisée. Il ne contourne pas les permissions. Il les exécute. Et c'est là le point que de nombreuses équipes de sécurité n'avaient pas calculé avec suffisamment de clarté : si les permissions sont plus ouvertes qu'elles ne devraient l'être, une seule requête peut récupérer ce qui nécessitait auparavant des dizaines de recherches manuelles dispersées.
Des années de dossiers partagés qui n'ont jamais été fermés. Des fichiers copiés pour une analyse ponctuelle et restés sur des lecteurs personnels. Des courriels avec des pièces jointes sensibles archivés sans classification. Des dépôts de documents qui accumulent des enregistrements que personne ne supprime parce que personne ne se souvient qu'ils existent. Voilà la matière première réelle avec laquelle travaille l'assistant d'IA lorsqu'il se connecte à une organisation qui n'a pas audité son environnement avant d'activer l'accès.
Le risque ne naît pas du modèle de langage. Il naît de l'architecture de données que le modèle hérite.
Les équipes de sécurité font face ici à un problème de visibilité que leurs outils traditionnels ne résolvent pas. La prévention des pertes de données a été conçue pour surveiller les points de sortie. Les systèmes de gestion des identités administrent les rôles et les permissions. Les journaux d'activité documentent ce qui s'est déjà produit. Aucun de ces instruments n'a été conçu pour cartographier ce qui se passe lorsqu'une requête d'IA traverse des documents, des boîtes de réception, des bases de données et des référentiels de connaissances en une seule interaction, générant une réponse qui combine des fragments d'information qui n'avaient jamais été connectés auparavant.
Ce qui émerge de ce croisement peut être parfaitement légitime. Il peut aussi s'agir d'une concentration de données sensibles qu'aucun contrôle préalable n'avait anticipée.
Le coût caché d'ignorer l'infrastructure avant le modèle
Le récit dominant sur l'adoption de l'IA en entreprise souffre d'une distorsion originelle : il centre la conversation sur les modèles, les interfaces et les cas d'usage, et reléguant au second plan la question de savoir quelles données alimentent ces décisions et dans quelles conditions d'ordre, de classification et de gouvernance.
Gartner estime que 63 % des organisations ne disposent pas des pratiques de gestion des données nécessaires pour soutenir des projets d'IA. Ce chiffre aide à expliquer pourquoi tant de déploiements s'arrêtent avant d'atteindre la production, non pas en raison des limitations du modèle ni d'un manque de budget, mais parce que l'infrastructure de données sous-jacente ne peut pas soutenir ce dont le modèle a besoin pour opérer de manière cohérente.
Ce décalage a des conséquences financières directes. Les organisations qui investissent dans des licences, des formations et des changements de processus sans résoudre d'abord la couche de données paient pour une capacité qu'elles ne peuvent pas utiliser de manière fiable. Pire encore : elles assument une exposition qu'elles ne peuvent pas quantifier. Si les systèmes d'IA opèrent sur des données non classifiées, avec des permissions excessives et sans inventaire actualisé de ce qui existe et où, la fenêtre d'exposition réglementaire s'élargit de manières que les auditeurs et les équipes juridiques apprennent encore à mesurer.
Persistent Systems, parmi d'autres fournisseurs spécialisés dans ce domaine, structure ses solutions autour de trois axes précis : l'optimisation de l'infrastructure, la qualité des données et la mise à l'échelle sécurisée des charges de travail d'IA. La séquence n'est pas accidentelle. La mise à l'échelle vient en dernier, pas en premier.
Astutis documente dans son rapport 2026 que la grande majorité des travailleurs s'attend à ce que l'IA ait un impact significatif sur leurs fonctions dans les cinq prochaines années, mais qu'une infime fraction seulement l'utilise activement aujourd'hui. La raison n'est pas une résistance culturelle. C'est que l'expérience réelle avec des outils d'IA dans des environnements d'entreprise mal préparés génère des frictions concrètes : des réponses incohérentes, des résultats qui mélangent des informations provenant de contextes différents, une incertitude quant à la fiabilité de ce que le système renvoie. Ces frictions ne se résolvent pas en améliorant le modèle. Elles se résolvent en résolvant les données.
Gouverner l'IA comme on gouverne une identité à haut risque
Il existe un changement conceptuel que les organisations les plus avancées dans ce domaine sont déjà en train d'opérer, et que les autres devront éventuellement effectuer : traiter les agents d'IA comme des identités gouvernées, et non comme des outils utilisateur.
Lorsqu'un copilote ou un agent d'automatisation accède aux systèmes d'entreprise, il le fait via des comptes de service, des interfaces de programmation et des contextes utilisateur. Il dispose de permissions. Il agit sur des données. Il génère des sorties susceptibles de contenir des informations sensibles. Pour toutes ces raisons, il devrait recevoir le même traitement que toute identité à privilèges élevés dans une organisation : révision périodique des accès, application du principe de moindre privilège, surveillance du comportement et traçabilité de ce qu'il touche.
La plupart des programmes de sécurité d'entreprise ne sont pas configurés pour cela. Ils ont été conçus en pensant aux personnes et aux systèmes, non aux agents d'IA qui opèrent avec leur propre logique, combinent des sources d'information et produisent des sorties que leurs opérateurs humains ne peuvent pas toujours anticiper.
La préparation des données pour l'IA, dans son sens opérationnel, requiert au moins quatre actions concrètes. Premièrement, construire un inventaire actualisé des systèmes d'IA actifs dans l'environnement, y compris les copilotes intégrés dans les plateformes de productivité, les modèles personnalisés et les agents d'automatisation, cartographiés par rapport aux sources de données auxquelles ils accèdent. Deuxièmement, classifier les données sensibles de manière cohérente à travers le stockage en nuage, les applications de type logiciel en tant que service et les référentiels hérités, car sans cette classification, les contrôles de conformité ne peuvent pas distinguer entre les informations sensibles et génériques. Troisièmement, appliquer aux agents d'IA le même examen que celui appliqué aux comptes de service à haut risque : leurs permissions devraient refléter un usage réel, et non un héritage accumulé. Quatrièmement, connecter ce contexte de données aux contrôles existants, y compris les systèmes de prévention des pertes de données, la gestion des accès et des identités, et les passerelles d'accès, afin que les politiques reflètent une exposition réelle plutôt que des schémas abstraits.
Aucune de ces étapes ne nécessite d'attendre que les modèles d'IA s'améliorent. Ce sont des décisions concernant l'infrastructure qui existe déjà.
La préparation des données n'est pas une étape préalable, c'est le véritable enjeu
Le marché de l'IA en entreprise croît à des taux supérieurs à 30 % par an et est projeté entre 150 et 200 milliards de dollars d'ici 2030. Dans ce contexte, l'avantage concurrentiel ne résidera pas dans le fait d'avoir adopté l'IA avant les autres, mais dans le fait de l'avoir adoptée sur une base permettant d'opérer en toute confiance et de monter en puissance sans frictions.
Les organisations qui ont traité la préparation des données comme une formalité technique mineure découvrent, en production, que leurs systèmes d'IA produisent des résultats incohérents, que leurs équipes juridiques ne peuvent pas certifier la conformité réglementaire des processus assistés par l'IA, et que leurs équipes de sécurité ne peuvent pas répondre à des questions fondamentales sur les informations qui sont traitées et par qui.
Le déplacement que ce moment révèle n'est pas technologique dans son essence. Il est de l'ordre de la gouvernance. L'intelligence artificielle force les entreprises à confronter des problèmes de données qui existaient déjà avant qu'un seul copilote ne soit activé : des données non classifiées, des permissions accumulées sans révision, des inventaires incomplets, des contrôles conçus pour un monde où les recherches étaient manuelles et lentes. Ce qui a changé, ce n'est pas que ces problèmes sont apparus. Ce qui a changé, c'est qu'il n'est plus possible de les ignorer sans conséquences visibles et rapides.
Les organisations qui sortiront les mieux positionnées de ce cycle sont celles qui ont compris que préparer les données n'est pas une étape préalable à l'adoption de l'IA. C'est, avec précision, le travail de fond qui détermine si l'adoption produit de la valeur ou simplement davantage de surface de risque sur laquelle opère un système plus rapide.
