On parle partout de l’IA. Dans les comités de direction, dans les plans de développement des compétences, dans les démonstrations commerciales, dans les discours publics sur la compétitivité.
À en juger par le ton général, une chose semble acquise : l’entreprise de demain sera automatisée par des agents IA.
Sur le principe, l’idée est séduisante.
Un agent IA ne se contente pas de répondre à une question comme le fait l’IA générative. Il peut en théorie enchaîner des actions : lire un document, extraire une information, compléter un tableau, produire un compte rendu, déclencher une procédure, alimenter un reporting, ou faire circuler une donnée d’un outil à l’autre.
C’est cette capacité d’action, et non seulement de génération de texte, qui nourrit aujourd’hui la promesse de gains de productivité massifs.
Mais entre la promesse et la pratique, il existe un verrou beaucoup moins visible que les performances des modèles : l’accès réel aux données de travail.
Et c’est ici qu’apparaît un problème encore sous-estimé. Dans beaucoup d’entreprises, la transition vers l’IA est ralentie non pas par manque d’intérêt, ni même par manque de cas d’usage, mais par une dépendance au sentier à l’écosystème bureautique Microsoft.
Autrement dit, les choix techniques accumulés au fil du temps peuvent aujourd’hui compliquer l’automatisation des processus par agents IA, surtout lorsque les données restent hébergées localement.
L’agent IA n’est utile que s’il peut accéder aux données de l’entreprise
L’automatisation par IA est souvent présentée comme presque immédiate : il suffirait, en apparence, d’assembler quelques briques dans un outil no-code comme n8n, ou dans l’interface dédiée de Mistral ou ChatGPT, de connecter un modèle de langage à ses applications, puis de laisser l’agent travailler.
Cette représentation est trompeuse, ou du moins incomplète ; en réalité, un agent IA n’automatise rien s’il n’a accès à rien !
Dans une entreprise, les processus à automatiser reposent sur des données et sur des documents très concrets : fichiers Word, tableaux Excel, présentations PowerPoint, dossiers partagés, procédures internes, états financiers, fiches clients, rapports d’activité, documents qualité, documents RH, archives projet. Ces documents bureautiques structurent une part considérable du travail quotidien.
En pratique, cela signifie qu’un agent IA n’a d’intérêt opérationnel que s’il peut lire, exploiter et parfois modifier ces ressources. Sans cet accès, l’IA reste cantonnée à des usages périphériques : reformuler un texte, résumer une note, proposer un brouillon, répondre à une question générale. Ces usages ont leur utilité, mais ils ne suffisent pas à automatiser en profondeur les processus.
L’automatisation devient possible lorsque l’agent IA accède aux données réelles de l’entreprise, et donc à ces documents.
Pourquoi l’accès aux données de l’entreprise est plus compliqué qu’il n’y paraît
Pour qu’un agent puisse interagir avec un document, il lui faut un point d’entrée technique. Ce point d’entrée prend généralement la forme d’une API, c’est-à-dire une interface qui permet à un logiciel d’accéder à un autre logiciel ou à des données de façon standardisée. Or ces API dépendent des choix des éditeurs, de l’architecture des systèmes d’information, et du lieu où les données sont réellement stockées.
C’est ici que la situation se tend. Dans la majorité des entreprises, l’environnement bureautique dominant est celui de Microsoft. Les fichiers de travail sont donc, le plus souvent, produits dans Word, Excel et PowerPoint.
Or, dans les configurations les plus simples à exploiter par les outils no-code d’automatisation ou d’orchestration d’agents, l’accès aux fichiers Microsoft est surtout fluide lorsque ces fichiers sont déjà hébergés dans le cloud.
Dès que l’entreprise conserve ses données sur ses propres serveurs, dans des partages réseau internes, dans des architectures historiques ou dans des environnements localement maîtrisés, l’intégration devient plus difficile. Elle demande des développements spécifiques, des arbitrages de sécurité, parfois des refontes d’architecture.
Ainsi, la mise en place d’agents IA afin d’automatiser les processus se heurte à une contrainte souvent sous-estimée : l’accès effectif et sécurisé aux données de travail.
Le problème n’est pas seulement technique : il est organisationnel et historique
Pour comprendre pourquoi ce point est si important, il faut introduire une notion classique des sciences de gestion et de l’économie des organisations : la dépendance de sentier (path dependence).
La dépendance au sentier désigne une situation dans laquelle les choix passés orientent fortement les possibilités présentes. Plus précisément, une organisation ne choisit jamais ses outils, ses routines et ses infrastructures à partir d’une feuille blanche. Elle compose avec une histoire : des investissements déjà réalisés, des compétences déjà distribuées, des procédures déjà stabilisées, des formats déjà adoptés, des contraintes déjà incorporées dans le travail quotidien.
Un choix ancien peut donc continuer à produire des effets longtemps après avoir été fait parce qu’il a structuré un ensemble de pratiques, de compatibilités et d’habitudes qui rendent coûteux tout changement de trajectoire. C’est exactement ce que l’on observe dans le cadre de la transition IA.
Le recours massif, pendant des années, à la suite Microsoft a été rationnel pour une majorité d’entreprises. Il a offert un environnement bureautique commun, facilitant le travail quotidien, la circulation des documents et la coordination des activités. Mais ce même héritage produit aujourd’hui un effet secondaire : il peut compliquer l’entrée dans une logique d’automatisation par agents IA lorsque les données associées à cet écosystème restent localisées hors des environnements cloud les plus facilement connectables.
Du sentier au verrouillage : quand l’héritage devient lock-in
L’autre notion utile ici est celle de lock-in, ou verrouillage, naturellement très liée à celle de dépendance de sentier. Le verrouillage apparaît lorsque les coûts techniques, organisationnels, économiques ou cognitifs d’un changement deviennent suffisamment élevés pour freiner fortement l’exploration d’alternatives. L’entreprise ne reste pas dans une trajectoire uniquement parce qu’elle la préfère encore ; elle y reste aussi parce qu’en sortir devient difficile.
Dans le cas présent, le verrouillage est double. D’un côté, l’entreprise dépend d’un écosystème bureautique omniprésent dans son fonctionnement quotidien. De l’autre, elle ne souhaite pas toujours faire migrer ses données dans le cloud, souvent pour des raisons sérieuses : confidentialité, souveraineté, conformité, sécurité, contrôle des accès, dépendance fournisseur, ou encore tout simplement par prudence.
Le résultat est paradoxal : les cas d’usage IA sont identifiés, mais l’accès aux données nécessaires à la mise en place d’agents IA n’est pas toujours possible.
Le risque : beaucoup d’IA visible, peu de gains de productivité
Une telle situation peut conduire à une forme contemporaine de paradoxe de la productivité.
L’expression renvoie classiquement au constat dressé par l’économiste Robert Solow à propos de certaines innovations technologiques, qui peuvent se diffuser largement dans les discours, dans les équipements ou dans les expérimentations, sans produire immédiatement des gains de productivité visibles à grande échelle.
Solow indiquait par exemple en 1987 qu’on voyait « des ordinateurs partout, sauf dans les statistiques de productivité ».
Ce paradoxe rappelle qu’une technologie ne produit pas mécaniquement des gains de productivité : l’IA est un dispositif socio-technique dont l’impact dépend de variables organisationnelles, infrastructurelles et institutionnelles.
Nous allons probablement voir de plus en plus d’IA dans les entreprises, mais cette diffusion peut rester superficielle si l’IA n’est pas utilisée au sein des processus-clés de l’entreprise, là où elle permettrait réellement des gains de productivité. En effet, ces gains ne viendront pas seulement de la capacité à utiliser l’IA générative pour mieux écrire un mail ou résumer une réunion.
Si les processus-clés de l’entreprise reposent sur des documents locaux que celle-ci ne veut pas exposer dans le cloud, alors la promesse de l’agent IA se heurte à une limite structurelle.
C’est en ce sens que l’on peut parler d’un paradoxe de la productivité : l’IA risque d’être un sujet omniprésent, sans être réellement un levier de productivité.
Pourquoi les approches no-code et low-code montrent vite leurs limites
Les outils no-code ou low-code, tels que n8n, jouent un rôle important dans la transition IA, en facilitant les expérimentations et la réalisation de POC. Ils permettent de créer des agents IA sans coder tout aussi puissants que ceux écrits avec des technologies telles que le framework python LangChain.
Ils ont donc une vraie utilité, mais ils fonctionnent particulièrement bien lorsque l’environnement est déjà compatible avec leurs connecteurs standards.
Dès que l’entreprise travaille avec des données locales, sensibles, ou réparties dans des infrastructures hétérogènes, la réalité change. On ne résout plus le problème par simple assemblage visuel. Il faut entre autres traiter la question des accès, de l’authentification, des droits, ou encore des formats documentaires. Les développements spécifiques et l’ingénierie deviennent donc rapidement nécessaires.
C’est sans doute l’un des angles morts les plus importants du débat actuel sur la transition IA des entreprises.
On parle beaucoup de la simplicité supposée des agents IA ; on parle moins des infrastructures qu’il faut construire pour qu’ils puissent réellement travailler dans les environnements biens réels des entreprises.
Comment adopter l’IA dans votre entreprise en tenant compte de sa dépendance aux outils bureautiques disponibles ? Trois voies se dessinent
Le sujet n’est pas d’opposer cloud et on-premise de manière idéologique, ni de disqualifier l’écosystème Microsoft, qui reste central et performant dans d’innombrables usages. Le sujet est plus précis : certaines trajectoires techniques passées créent aujourd’hui des coûts d’entrée cachés pour l’automatisation par agents IA.
Une fois ce constat établi, trois voies d’évolution sont envisageables :
- La première consiste à accepter l’environnement cloud du fournisseur dominant. Il s’agit certainement de la voie la plus simple sur le plan technique. Elle permet de bénéficier plus rapidement des connecteurs, des API standardisées et des chaînes d’intégration déjà prévues pour l’automatisation. Pour certaines entreprises, ce sera effectivement le meilleur choix.
- La deuxième consiste à rechercher des solutions intermédiaires : cloud souverain, architectures hybrides, exposition limitée de certaines ressources seulement permettant de concilier automatisation et exigences de sécurité. Cette voie est souvent plus complexe, mais aussi plus réaliste pour les organisations qui ne veulent ni renoncer à l’IA, ni à leurs exigences de contrôle de leurs données.
- La troisième voie repense plus largement la compatibilité de l’environnement bureautique et documentaire avec l’automatisation par IA. Cela peut conduire à développer des intégrations spécifiques, à revoir certaines briques du système d’information, voire à envisager, à terme, des outils plus facilement compatibles avec des architectures d’IA maîtrisées.
Des initiatives comme Euro-Office s’inscrivent dans cette troisième perspective, probablement la plus ambitieuse : le projet se présente comme une solution bureautique collaborative souveraine, open source, conçue pour être intégrée à d’autres plateformes documentaires, avec l’ambition de proposer une alternative européenne compatible avec les formats bureautiques dominants. Sans préjuger de sa viabilité future, son apparition signale que la question n’est plus seulement celle des outils d’IA, mais aussi celle du socle bureautique et documentaire sur lequel ces outils pourront effectivement s’appuyer.
Le choix entre ces trois voies n’est pas seulement technique : il engage un arbitrage entre coûts de transition, maîtrise des risques, dépendance fournisseur et possibilité d’automatisation.
La transition IA dépasse l’intelligence artificielle et nécessite de repenser les infrastructures informatiques et les outils bureautiques
La transition IA ne dépend pas uniquement de la qualité des modèles, ni de la volonté des dirigeants. Elle dépend aussi de la capacité concrète des agents à accéder, de manière sécurisée et exploitable, aux données de travail de l’entreprise.
C’est pourquoi l’ancrage dans l’écosystème Microsoft mérite d’être pensé comme un enjeu stratégique de dépendance au sentier. Non parce que Microsoft serait en soi un problème, mais parce que l’histoire bureautique des entreprises, combinée à des contraintes légitimes de sécurité et d’hébergement, peut aujourd’hui ralentir l’appropriation productive de l’IA.
Le principal risque n’est pas une absence d’IA, mais l’essor d’une IA très visible, très commentée, et pourtant peu génératrice de gains de productivité faute d’un système d’information adapté.
L’enjeu est non seulement technologique, mais aussi organisationnel, économique et politique au sens de la gouvernance des choix techniques. La promesse des agents IA ne sera tenue que si l’on traite également le problème de l’infrastructure documentaire, des connecteurs et du lock-in sociotechnique.
