L'IA oblige les entreprises à redécouvrir leur système d'information

Les projets d'IA obligent les entreprises à redécouvrir leur système d'information. Comprendre l'existant, les dépendances et les flux devient essentiel avant de choisir un modèle ou une technologie.

Les entreprises accélèrent sur l'intelligence artificielle. Assistants conversationnels, moteurs de recherche documentaire, automatisation de processus ou agents IA se multiplient dans les feuilles de route des DSI.

Pourtant, lorsque ces projets quittent la phase d'expérimentation pour s'intégrer réellement au système d'information, les premières difficultés rencontrées sont rarement liées au modèle de langage ou à la technologie utilisée.

C'est un constat que je retrouve régulièrement sur le terrain. Très vite, les questions deviennent beaucoup plus élémentaires : où sont les données ? Qui en est responsable et comment sont-elles gouvernées ? Cette application est-elle encore utilisée ? Qui connaît ce flux métier ? Pourquoi deux outils semblent-ils remplir la même fonction ? Comment un agent IA peut-il interagir avec un patrimoine applicatif dont certaines dépendances ne sont plus totalement maîtrisées ?

Aucune de ces questions n'est nouvelle. Elles existaient bien avant l'arrivée de l'IA. Ce qui change, c'est qu'il devient beaucoup plus difficile de les contourner.

En cherchant à connecter de nouveaux usages à leur système d'information, les entreprises redécouvrent progressivement un patrimoine qu'elles pensaient connaître. Et ce travail fait souvent apparaître une réalité plus profonde : au fil des années, la connaissance du SI s'est fragmentée.

L'IA révèle une dette d'architecture longtemps restée invisible 

Lorsqu'on parle de dette, on pense spontanément à la dette technique. Pourtant, dans les projets que j'observe, ce n'est pas toujours elle qui ralentit les transformations. Une autre forme de dette s'installe plus discrètement au fil des années : la dette d'architecture.

Elle n'est pas nécessairement le résultat de mauvaises décisions. Une nouvelle application est déployée pour répondre à un besoin métier, une interface est développée pour connecter deux outils, une acquisition apporte un nouvel ERP, une équipe met en place un traitement spécifique pour répondre à une urgence. Individuellement, chacune de ces décisions a du sens. C'est leur accumulation qui finit par rendre le système plus difficile à lire dans son ensemble.

Pendant longtemps, cette complexité peut rester invisible. Le système fonctionne, les utilisateurs travaillent et les applications continuent d'échanger entre elles. Mais dès qu'un projet transverse apparaît, les fragilités remontent : plusieurs applications portent les mêmes données, certaines dépendances ne sont plus connues, des fonctions se chevauchent et une partie de la connaissance repose sur quelques personnes.

L'IA accélère simplement le moment où il faut regarder cette réalité en face. Connecter un agent à plusieurs applications, lui donner accès à des données fiables ou lui permettre d'agir dans un processus métier suppose de savoir précisément quels systèmes font autorité, comment ils communiquent et où se situent les responsabilités. Une architecture que l'on pouvait jusqu'ici comprendre par morceaux doit soudain être regardée comme un ensemble.

Comprendre un système d'information ressemble souvent à un travail d'archéologie 

Lorsqu'on imagine le métier d'architecte d'entreprise, on pense facilement à la conception d'architectures cibles ou à de grands schémas. Dans la réalité, une grande partie de mon travail commence ailleurs : il faut d'abord comprendre ce qui existe réellement.

Cette phase ressemble parfois à un travail d'archéologie. Au fil des ateliers, on découvre une application dont plus personne ne connaît précisément le rôle mais qui reste indispensable à un processus métier. On identifie un serveur FTP qui échange encore des fichiers chaque nuit sans que personne ne sache vraiment pourquoi. Une règle métier importante se révèle enfouie dans un ancien traitement ou dans un fichier Excel maintenu depuis des années par une seule personne.

Il suffit souvent de tirer sur une première ficelle pour faire apparaître toute une série de dépendances absentes de la documentation. C'est là que le travail d'architecture prend une dimension très concrète : confronter les schémas à la réalité, retrouver les personnes qui connaissent encore certaines briques, suivre les flux, comprendre pourquoi un système fonctionne de cette manière et distinguer ce qui relève encore d'un choix de ce qui relève simplement de l'héritage.

C'est pour cette raison que je me méfie des transformations qui commencent directement par la définition d'une cible. Une architecture future n'a de sens que si elle part d'une compréhension suffisamment juste de l'existant. Sinon, on risque de construire une trajectoire sur le système que l'on pense avoir, et non sur celui qui fonctionne réellement.

Une architecture n'a de valeur que si elle est partagée

Une fois cette compréhension reconstruite, encore faut-il qu'elle ne reste pas entre les mains de quelques experts. C'est là, selon moi, que se joue une grande partie de la valeur de l'architecture d'entreprise.

La tentation consiste souvent à répondre à la complexité par davantage de documentation. Pourtant, une cartographie devient rapidement obsolète si elle n'est ni utilisée ni mise à jour. Produire un schéma ne suffit donc pas. Il faut qu'il permette aux équipes de parler du même système avec les mêmes repères.

Les métiers doivent pouvoir comprendre les impacts d'une évolution. Les développeurs doivent identifier les dépendances de leurs applications. Les responsables applicatifs doivent savoir quelles briques portent quelles responsabilités. Cette vision commune évite que chacun prenne des décisions uniquement à l'échelle de son propre périmètre.

C'est aussi pour cette raison que je considère que le rôle de l'architecte n'est pas d'avoir toutes les réponses. Il consiste plutôt à poser les bonnes questions, confronter les points de vue et faire émerger une représentation suffisamment claire pour permettre une décision collective. Une architecture d'entreprise ne se construit jamais seul. Elle se construit avec celles et ceux qui utilisent, exploitent et font évoluer le système au quotidien.

Au fond, la valeur d'une architecture ne réside pas dans le nombre de schémas produits, mais dans la capacité de l'organisation à s'appuyer dessus pour décider.

À l'ère de l'IA, l'architecture d'entreprise redevient un outil de décision 

Je ne pense pas que l'intelligence artificielle change fondamentalement les principes de l'architecture d'entreprise. Elle change en revanche le niveau d'exigence. À mesure que les systèmes accueillent davantage d'agents, d'automatisations et d'interactions entre applications, une décision locale peut avoir des conséquences beaucoup plus larges.

Le sujet n'est donc pas de rechercher une architecture idéale ni de repartir d'une feuille blanche. Cette situation n'existe pratiquement jamais. Il s'agit de faire évoluer un patrimoine existant, avec son histoire, ses contraintes et ses choix passés, tout en évitant que chaque nouveau projet ajoute une dépendance supplémentaire que personne ne maîtrise réellement.

Dans ce contexte, le rôle de l'architecte évolue lui aussi. Il ne s'agit plus seulement de concevoir une cible, mais de créer les conditions d'une décision collective. Poser les bonnes questions, rapprocher les points de vue et maintenir une compréhension commune du système d'information deviennent des compétences aussi importantes que la maîtrise des architectures elles-mêmes.

À quoi ressemblera l'architecture d'entreprise dans trois ans, dans un monde où l'IA, l'automatisation et les systèmes distribués seront omniprésents ? Les fondamentaux de notre métier ne changeront probablement pas. Nous continuerons à chercher à comprendre avant de transformer. En revanche, son rôle deviendra plus stratégique que jamais. Car à mesure que les transformations s'accélèrent, une certitude s'impose : avant de faire évoluer un système d'information, encore faut-il le connaître.