Architecture SI AI-Ready ? Construire un SI conversationnel et agentique piloté par le langage naturel

L’explosion de l’A générative questionne les DSI sur l’avenir de leur système d’information. Le SI sera vraisemblablement piloté par le langage naturel. Pas sous la forme d’un chatbot “en plus”, mais via une interface en langage naturel (Natural Language Interface / NLI) capable de traduire une intention en requêtes, en décisions… et, lorsque c’est autorisé, en actions automatisés. Le sujet n’est pas de “faire de l’IA” mais bien de concevoir dès à présent une architecture SI AI-Ready qui supporte l’usage conversationnel ET l’exécution dans les standards conformes aux exigences d’une DSI.

Dans cet épisode 1, nous posons donc les bases : clarifier les concepts (conversationnel, piloté par le langage naturel, agentique), comprendre le passage du “read” au “write”, puis détailler les six briques qui rendent une architecture SI AI-Ready opérable : composabilité, API-first/headless, data layer gouvernée, knowledge layer, action layer, et Trust & Control.

SI conversationnel, SI agentique ou SI piloté par le langage naturel : on parle de quoi ?

Avec le développement de l’IAGen a vitesse grand V, tout le monde « chatte » avec ses outils et les éditeurs l’ont bien compris en intégrant cette fonctionnalité (avec plus ou moins de pertinence) dans les CRM, ERP, etc.. Mais un SI conversationnel n’a rien à voir avec un simple chatbot ajouté dans une application. C’est un SI dont l’architecture a été repensée pour intégrer une couche d’interface en langage naturel (NLI) capable de piloter les données et les processus. Imaginez une interface qui permet d’accéder aux bonnes données, de déclencher les bons workflows et, demain, d’exécuter certaines actions en production, de façon contrôlée. On se met alors à parler d’une nouvelle génération de SI, capable d’interagir, de prendre des actions en autonomie encadrée et de respecter les standards d’une DSI en matière de sécurité, conformité, traçabilité, qualité… et gouvernance de l’IA.
Science-fiction ? Pas vraiment. Commençons par clarifier quelques termes que l’on voit partout et qui sont souvent confondus. Leur point commun, c’est que la “conversation” masque une énorme complexité. pour que tout cela fonctionne à l’échelle, il faut un SI composable, avec des services métier et des APIs proprement exposés

• SI conversationnel : le SI “répond” et “guide” via une interface en langage naturel en s’appuyant sur des données et des connaissances gouvernées et contextualisées.
• SI piloté par le langage naturel : la conversation devient une interface de commande où l’utilisateur exprime une intention, le SI la traduit en requêtes et en exécution via des APIs et des workflows définis.
• SI agentique (agentic enterprise) : des agents IA spécialisés orchestrent des tâches de bout en bout. Ils collaborent entre eux, interagissent avec le SI et les utilisateurs ; le tout sous contrôle (garde-fous, validations, auditabilité, observabilité, human in the loop).

Couche conversationnelle (conversational layer) : l’interface en langage naturel du SI

La couche conversationnelle est donc cette brique qui permet d’interagir avec le SI via le chat, copilot ou encore la voix et elle est intégrée dans les applications. Elle permet de répondre à des questions en actions SI. Par exemple « Donne-moi la vue 360 de ce client et les derniers échanges », « , « Quel est le chiffre d’affaires par région vs objectif cette semaine ? », « Quels sont les incidents critiques depuis X temps ? », « Quels comptes ont des droits d’accès sur ce domaine de données ? », « Quels contrôles dois-je ajouter pour sécuriser ce pipeline avant mise en production ? » « Propose-moi la meilleure requête pour analyser le churn sur 12 mois », « Ouvre un ticket incident P2 pour la baisse de fraîcheur des données et assigne l’équipe DataOps », « Qui a accès à ces données ? », « Relance automatiquement les pipelines en échec sur les 24 dernières heures. » (…). Elle utilise le Natural Language Interface (NLI) qui permet de comprendre l’intention, le contexte et les droits d’accès spécifiques à l’utilisateur.

1. Comprendre l’intention : identifier le besoin, lever les ambiguïtés, reformuler si nécessaire.
2. Retrouver l’information : interroger les sources autorisées (applications, data platform, référentiels) en respectant le bon niveau de gouvernance.
3. Guider l’utilisateur : proposer une réponse actionnable, suggérer la prochaine étape, et préparer l’exécution (par exemple via une API) quand l’usage l’autorise.

SI agentique (agentic enterprise) : quand le SI répond ET exécute !

Un SI agentique est pensé pour exécuter des actions à partir d’une intention exprimée en langage naturel. Alors que la couche conversationnelle traduit une demande en informations, le SI agentique a la capacité d’agir sur le SI via des services composables et des API.

“Read” vs “Write” : interroger ET modifier l’état du SI

Le concept est simple. Lire n’engage pas le SI alors qu’écrire oui.

• Read : l’agent interroge le SI, agrège le contexte et explique ce qui se passe.
  Exemples : « Où en est la commande X ? », « Quels incidents P1 sur 7 jours ? », « Quel est le lineage de ce KPI ? »
• Write : l’agent déclenche des actions qui modifient l’état du SI, via des API et des workflows, avec des garde-fous.
  Exemples : créer un ticket, ouvrir un accès, relancer un pipeline, lancer un rollback, déclencher un workflow, mettre à jour un référentiel.

Chez Smartpoint, nous avons jusqu’à présent surtout vu et utilisé read-only mais la bascule est engagée sur des périmètres très précis et maîtrisés. C’est là que l’on passe du “copilot” qui commente… à un SI agentique qui opère.

Agents, orchestration, supervision : les trois briques qui rendent le modèle opérable

Un SI agentique s’appuie sur des agents IA capables d’exécuter des tâches outillées (APIs, workflows, moteurs de règles) dans un contexte prédéfini. Dans une architecture AI‑Ready, ces agents ne sont pas “greffés” sur le SI, ils consomment des services et des APIs conçus pour être appelés par des agents, de manière sécurisée et gouvernée.

Chaque agent IA a un rôle précis (support, traitement data, conformité, finance…), des sources autorisées, un périmètre d’action et des règles. Les agents IA sont par nature spécialisés sur un périmètre précis pour éviter toute confusion et autres hallucinations.

L’orchestration permet de distribuer les tâches. Elle séquence les étapes, choisit le bon agent, gère les dépendances et garantit une exécution cohérente. C’est la différence entre une conversation isolée et un processus industrialisable à l’échelle de la DSI, et c’est une brique centrale de toute architecture SI AI‑Ready crédible.

Et bien entendu, la supervision est indispensable (run, contrôle, traçabilité). Dans une architecture AI-Ready, on parle d’observabilité des agents.
Superviser permet de suivre les échanges, de contrôler les actions, de gérer les validations (human-in-the-loop), de suivre la qualité, de surveiller les coûts et de détecter les dérives. Sans supervision, un SI agentique reste un POC !

Pourquoi les systèmes d’informations actuels ne sont pas AI-Ready ?

Les SI ont été conçus pour exécuter des transactions pas pour dialoguer, ni contextualiser et encore moins agir de manière autonome.

Dans la réalité, Le SI est très fragmenté surtout dans les grandes entreprises qui ont un Legacy lourd qui s’est complexifié avec le temps. Entre ERP monolithiques, applications métier cloisonnées et intégrations spécifiques, le SI est loin d’être actionnable par des agents via des API, de façon gouvernée et opérable en production (“agent-callable »). Les workflows sont rigides, couplés au front et aux logiques applicatives ; et non exposés sous forme de services et d’API. Alors qu’un SI Ai-Ready a impérativement besoins de services composables et d’API standardisées pour fonctionner.

Côté données, l’architecture n’est pas “data AI‑ready” non plus. La donnée n’a pas été préparée pour l’IA : jeux de données disparates, définitions de KPI qui varient, fraîcheur incertaine, documentation incomplète. Sans une gouvernance data rigoureuse, des métadonnées exploitables et une traçabilité de bout en bout (sources, transformations, responsabilités), l’IA « répond » toujours… mais on ne peut pas lui faire confiance pour alimenter une vraie décision ni enclencher une action. Une architecture data AI‑Ready suppose au contraire des data products clairement définis, des contrats de données, des métriques de qualité, du lineage et une responsabilité explicite côté métiers et côté DSI.

-> À Lire sur le sujet : Pas d’IA en entreprise sans AI-Ready Data.

Une architecture AI Ready n’est pas qu’un sujet de data ou de modèle. C’est un sujet de Run. Un agent qui appelle des API doit respecter l’IAM (gestion fine des identités et des accès), gérer les secrets, être auditable, observable mais aussi maîtrisé en termes de coûts (FinOps). Tous ces composants doivent être au bon niveau sinon passer au « write » revient à mettre un copilote dans une voiture lancée en pleine vitesse sans frein ni ceinture de sécurité.  

Architecture AI-Ready : les 6 briques d’un SI conversationnel et agentique crédible

Un SI AI-Ready, c’est un SI où une intention exprimée en langage naturel peut être traduite en requêtes (data / applicatives), enrichie par du contexte (données / connaissances), puis, si le cadre le permet, exécutée dans les standards DSI.

1) SI Composable où comment passer du monolithe aux services réutilisables

Un SI agentique a besoin de fonctions “appelables”, c’est-à-dire des apacités exposées via des services/API. Quand l’essentiel de la valeur est enfermée dans des applications monolithiques ou des chaînes de traitements fortement couplées, l’IA se contente de commenter (read only). La composabilité, c’est la capacité à assembler des briques (commande, facturation, identité, référentiels, pricing…) sans réécrire l’ensemble à chaque itération.
Dans certains contextes, une approche event-driven apporte une vraie valeur. Elle réduit le couplage, améliore la résilience, et permet de faire évoluer le SI par itérations. Mais le point clé n’est pas “microservices partout” mais une décomposition utile, au bon niveau, avec des responsabilités claires.

2) API-first & headless où comment rendre le SI réellement “agent-callable” (AI-Ready)

Dans une architecture AI-Ready, un agent ne “pilote” pas des écrans, il consomme des capacités métier exposées via des API. Cela suppose des API propres, standardisées, versionnées, documentées et sécurisées, avec des contrats stables. “Headless” signifie simplement que l’action ne dépend pas d’une interface utilisateur ou d’un parcours applicatif, l’agent appelle un service, pas une IHM.
C’est un point de rupture classique entre POC et mise en production. On peut avoir une IA qui comprend, sans pour autant avoir un SI capable d’exécuter de manière fiable. Une approche API-first permet d’industrialiser l’accès au SI (applications, utilisateurs, partenaires … et demain agents) avec les mêmes exigences d’urbanisation SI et d’exploitation : contrôle d’accès (IAM), quotas, traçabilité, gestion des erreurs et gouvernance des interfaces. Sans ce socle, l’agent devient un contournement et donc un risque : surface d’attaque accrue, dette d’intégration, et difficultés d’audit en production.

3) Data layer gouvernée : un SI AI-Ready commence par des données fiables

Un SI conversationnel tient ses promesses uniquement si la donnée est compréhensible, à jour et fiable. Sinon, il répond vite… mais faux. La brique data, ce n’est pas “un lac de données de plus”. C’est une organisation qui rend la donnée consommable : data products, data contracts, métriques définies, métadonnées, qualité, fraîcheur, lineage et responsabilités.
Dans une architecture data AI‑Ready, ce socle est aussi un sujet d’exploitation. la DSI doit pouvoir piloter la disponibilité, la fraîcheur, la qualité, et comprendre l’impact d’un incident data sur un usage métier (ou agentique). Sans cette gouvernance, la conversation est agréable, mais la décision reste risquée.

4) Knowledge layer : RAG, graph, référentiels, sémantique

Dans une architecture AI-Ready, la “connaissance” ne se résume pas à faire du search dans des PDF ! C’est une brique à part entière qui fournit du contexte gouverné et actionnable aux assistants et aux agents, avec un niveau d’exigence compatible avec la mise en production.

Pour être crédible en production, un SI agentique repose sur trois mécanismes complémentaires.

D’abord, le RAG sert à récupérer le bon contexte opérationnel au bon moment, à partir de sources hétérogènes comme les procédures internes, la documentation, les tickets, les contrats ou les politiques internes, avec traçabilité des sources. Ensuite, un graphe de connaissance ou des référentiels structurent les relations clés du SI (client ↔ contrat ↔ produit ↔ incident ↔ droits d’accès ↔ organisation) pour passer d’un “texte plausible” à une représentation exploitable et cohérente. Enfin, un catalogue et des règles de gouvernance encadrent ce qui est consommable, ce qui fait référence, ce qui est à jour et ce qui est interdit … autrement dit, qui a le droit de voir quoi et sur quelle version de la vérité.

L’objectif est de produire une réponse sourcée, explicable et utilisable, pas une synthèse “belle à lire” qui ne tient pas la route au premier contrôle, audit ou incident.

5) Action layer : outillage, orchestration et garde-fous

C’est la brique qui fait passer le SI du “je réponds” à “j’exécute”. Dans une architecture AI-Ready, l’action ne se fait pas “dans le LLM”, elle se fait via des mécanismes d’exécution industrialisés : APIs, moteurs de workflow, orchestrateurs, règles métier, validations et gouvernance.

Cette couche doit intégrer les garde-fous attendus par une DSI comme le human-in-the-loop sur des actions sensibles, des seuils et des limites d’action, des circuits d’approbation, une séparation stricte des environnements dev / préprod / prod, la gestion des erreurs, idempotence quand nécessaire et surtout des chemins de rollback / compensation pour éviter le drame à chaque incident

Un agent n’agit pas parce qu’il “pense que c’est une bonne idée”. Il agit parce que l’action est définie, autorisée, testée et réversible, sur un périmètre explicite. C’est ce qui permet de démarrer proprement : d’abord des actions simples et fortement outillées (tickets, relances jobs, demandes d’accès, procédures standard) puis une montée en autonomie progressive en s’assurant de la maîtrise opérationnelle.​

6) Trust & Control : sécurité, auditabilité, observabilité, maîtrise des coûts

C’est la brique qui rend un SI agentique exploitable en production et surtout qui conditionne la crédibilité d’une architecture AI-Ready. Elle répond aux contraintes de sécurité (gestion des identités et des accès via RBAC/ABAC, gestion des secrets, chiffrement), de conformité (journalisation, traçabilité, preuves d’exécution) et d’exploitation (supervision, alerting, gestion des incidents).

Elle intègre aussi deux élément indispensables pour une architecture AI-Ready : la maîtrise des coûts (FinOps, suivi consommation LLM/compute, quotas, chargeback/showback) et la qualité de service (SLO/SLI) appliquée non seulement aux APIs et aux plateformes, mais aussi aux agents et aux données qu’ils consomment (disponibilité, fraîcheur, qualité, latence, taux d’erreur).

Avec ce socle Trust & Control, la DSI peut encadrer l’automatisation, piloter les risques, et industrialiser progressivement des cas d’usage “write” sur des périmètres maîtrisés, sans dégrader la sécurité ni l’opérabilité du SI.

Ces six briques permettent de poser une architecture AI-Ready solide : une interface en langage naturel qui n’est pas un gadget, des agents qui n’opèrent pas “dans le vide”, et un SI qui reste pilotable par une DSI.

Alors comment passer à un SI conversationnel ou agentique ?

Un SI conversationnel ou agentique ne se décrète pas à coups de prompts ! Il se conçoit avec une architecture SI AI-Ready, c’est à dire des capacités métier composables, exposées via des API, alimentées par une donnée et une connaissance gouvernées, et opérées avec les standards Run attendus par une DSI (sécurité, traçabilité, observabilité, maîtrise des coûts).

Chez Smartpoint, nous accompagnons les DSI et les CDO dans cette trajectoire de transformation de leurs systèmes d’information : diagnostic de maturité AI-Ready, priorisation des chantiers (API-first, data/knowledge, action layer, Trust & Control) et mise en production progressive de cas d’usage, du read-only vers des périmètres write supervisés.

Sources :

• 5 bonnes résolutions pour bâtir le SI conversationnel de 2030 : https://www.cio-online.com/actualites/lire-5-bonnes-resolutions-pour-batir-le-si-conversationnel-de-2030-16753.html
• De l’IA générative à l’IA agentique : pourquoi les entreprises doivent réinventer leur architecture GenAI : https://www.informatiquenews.fr/de-ia-generative-au-rag-agentique-pourquoi-les-entreprises-doivent-reinventer-leur-architecture-genai-106839
• Adopter les interfaces conversationnelles : guide pratique pour les DSI : https://www.alliancy.fr/fr/adopter-les-interfaces-conversationnelles-guide-pratique-pour-les-dsi-ad867f07-14b6-498e-9433-2be4ad9fa556
• Pas d’IA en entreprise sans AI-Ready Data.
• Les architectures data autonomes et auto-adaptatives : vers l’auto-pilotage de la donnée