Enterprise Architecture : de l’automatisation à l’autonomie

C’est une question audacieuse à quoi bon conserver des applications lorsqu'on peut interagir directement avec des agents intelligents et capables de gérer l'ensemble des tâches nécessaires — à condition de disposer des données, des connaissances et du concours d'agents spécialisés ?

Regardons ce que sont réellement les applications d’aujourd’hui : une interface utilisateur, une logique métier, un accès aux données et des points d’intégration — le tout regroupé dans un paquet. Maintenant, regardons ce que fait un agent : il communique en langage naturel, raisonne dynamiquement sur la logique métier, accède aux données via des outils et des APIs, et orchestre nativement entre les systèmes.

Mais il s’agit d’une vision future, pas de notre réalité actuelle. Les systèmes patrimoniaux (legacy) perdureront encore plusieurs décennies. De nouvelles applications continueront d’être développées. Et pour des tâches qui doivent être réalisées efficacement, à grande échelle et de manière cohérente, les applications pourraient encore garder toute leur pertinence. Néanmoins, le centre de gravité architectural se déplace : des applications comme principale couche d’exécution principale vers les agents comme principale couche d’orchestration.

C’est pourquoi nous les avons regroupés dans un seul domaine : Agents & Applications. Aujourd’hui, agents et applications diffèrent encore dans leur conception, leur intégration et leur gestion. Mais les agents appellent déjà des applications et les intègrent — et commencent à générer leur propre logique applicative. Les deux pourraient bientôt devenir indissociables. 

Les données sont passées d’un rôle de soutien à un rôle central. Pendant des années, elles n’étaient qu’un composant des applications — stockées dans des bases de données, façonnées par la logique applicative et gérées par les équipes dédiées. Leur essor en tant que domaine architectural à part entière marque un tournant majeur : du data warehousing au master data management, puis au data mesh et aux data products.

Les agents transforment encore davantage ce paysage :ils ne se contentent pas d’interroger des bases de données — ils consomment des informations non structurées et des connaissances pour raisonner, planifier et agir. Un document de politique, un échange de courriels, une description de processus — autant d’entrées directes pour le comportement des agents. Il ne suffit plus de rendre la connaissance accessible aux humains via des documents. Il faut désormais la gérer, la structurer et la valoriser explicitement, afin que les agents puissent la lire, la retrouver et l’interpréter correctement — pour le RAG (Retrieval-Augmented Generation, génération augmentée par récupération), pour le contexte et pour la prise de décision autonome.

Cela implique de nouveaux concepts architecturaux :

• Des graphes de connaissances et des ontologies conférant aux agents une compréhension sémantique. 

• Des architectures RAG ancrant les réponses des agents dans la connaissance organisationnelle.

• Une mémoire d’agent et des espaces de contexte permettant aux agents de maintenir un état entre les interactions.

• Des embeddings et des bases de données vectorielles rendant la connaissance non structurée recherchable.

• Des métadonnées — descriptions de processus, règles métier, traçabilité des données (data lineage) — dont les agents ont besoin pour opérer efficacement. 

Voilà pourquoi nous avons rebaptisé le domaine de Data Architecture en Data & Knowledge. Il ne s’agit plus seulement de stocker et de modéliser des données, mais de structurer et de valoriser les métadonnées et le socle de connaissances (knowledge fabric) sur lequel les agents fondent leur raisonnement.

Cette évolution tient moins à l’IA agentique qu’à des tendances structurelles qui se renforcent depuis des années : cloud, virtualisation, everything-as-a-service, zero trust.

Lorsque l’infrastructure est consommée comme un service, l’importance architecturale de modéliser séparément les systèmes, les réseaux et la virtualisation s'amenuise. Avec le zero trust, même le périmètre réseau perd de sa pertinence — la sécurité n’est plus une affaire de topologie, mais d’identité et de politique.

Ce que cela signifie concrètement : les capacités technologiques — architecture des systèmes, des réseaux et de la virtualisation — sont de plus en plus absorbées par les choix de plateformes, la configuration cloud et les politiques de sécurité. Elles ne disparaissent pas, mais leur importance stratégique en tant que domaine architectural autonome s'estompe. Aujourd’hui, c’est dans la conception des capacités métier, des agents & applications, et des données & connaissances qui les alimentent que l'Enterprise Architecture déploie sa plus grande valeur stratégique.

Exemples :

• Une équipe de développement peut désormais accéder au compute, au stockage et au réseau avec un seul appel API — ou adopter une approche serverless. Plus besoin d’architecture serveur.

• Une organisation migre vers une plateforme cloud intégrant infrastructure, sécurité et conformité « prête à l’emploi » (out of the box) — ce qui était autrefois une décision complexe d’architecture technologique devient un simple choix de configuration.

Un modèle de capacités définit ce que nous architecturons. Mais une organisation a également besoin de capacités pour gérer l’Enterprise Architecture, tenir à jour son référentiel et garantir la gouvernance.

Si la gestion de l’Enterprise Architecture et le référentiel restent globalement stables dans un monde agentique, la gouvernance, elle, se transforme en profondeur. Lorsque des agents agissent de façon autonome, de nouvelles questions surgissent : qui est responsable d’un agent ? Qui répond de ses décisions ? Comment garantir la conformité ?

Deux ajouts essentiels au modèle de gouvernance :

• Garde-fous : des limites applicables par la machine, qui restreignent le comportement des agents en temps réel — un concept clé de toute gouvernance agentique.

• Gouvernance des agents & des données : traite de la responsabilité, de la propriété et de la conformité des agents autonomes et des données qu’ils utilisent.

Nous laissons volontairement deux questions ouvertes : comment adapter la gouvernance aux agents autonomes ? Et comment les rôles d’architecture vont-ils évoluer ? Ce sont des sujets que nous aborderons dans un prochain article.