L’ensemble complet de l’IA agente, couche par couche : de l’interface utilisateur à l’observabilité.
Dix couches derrière un agent de production : interface utilisateur, ingestion, segmentation en blocs, embeddings, recherche vectorielle, récupération d’informations, génération de prompts, le LLM, déploiement et évaluation.
Sources: The Full Stack of Agentic AI: From User Interface to Production-Grade Intelligence
L’intelligence artificielle a depuis longtemps dépassé le stade où quelqu’un tape une requête et lit une réponse. Les produits d’IA modernes sont des systèmes logiciels complets. Ils prennent en charge des documents, transforment des matériaux désorganisés et chaotiques en connaissances utilisables, génèrent des embeddings, récupèrent du contexte, communiquent avec de grands modèles de langage, exécutent des outils, fonctionnent au sein d’infrastructures cloud et surveillent leurs propres performances. Cela est d’autant plus vrai pour l’IA agente. Un agent n’est pas un LLM coincé dans une fenêtre de chat. Une application agente de niveau professionnel nécessite toute une pile technologique autour du modèle, et ce dernier n’en constitue qu’une seule couche.
Un diagramme d’architecture de référence de cette pile offre une carte pratique, allant du frontend, en passant par l’ingestion, la récupération et la formulation des requêtes, jusqu’aux modèles, au déploiement et à la surveillance. Les sections suivantes détaillent chaque couche, son utilité, la raison de son existence et la manière dont les outils s’interconnectent.
Un aperçu des couches
Dans l’ordre, la pile fonctionne ainsi : interface utilisateur, ingestion des documents, segmentation et prétraitement, embeddings, base de données vectorielle, récupération d’informations, ingénierie des prompts, LLM, infrastructure et déploiement, et enfin observabilité et évaluation.
Cette séquence n’est pas un pipeline strict. Dans les systèmes agents réels, les différentes composantes interagissent constamment. Un agent peut récupérer des informations plusieurs fois, appeler des outils externes, invoquer différents modèles, évaluer ses propres réponses et déclencher d’autres workflows avant de produire un résultat final. Il est plus approprié de considérer cette pile comme l’écosystème technologique entourant l’intelligence que comme une simple chaîne demande-réponse.
Couche 1 : l’interface utilisateur
Chaque système d’IA a besoin d’un endroit où les utilisateurs peuvent interagir avec lui. L’interface utilisateur présente cette expérience, qu’il s’agisse d’un chatbot, d’un portail d’entreprise, d’un tableau de bord analytique, d’un outil interne ou d’un espace de travail assisté par l’IA. Les technologies couramment utilisées incluent React, Next.js, Streamlit et Azure App Service. React permet de créer des interfaces interactives, tandis que Next.js constitue un framework plus complet pour les applications web en production. Streamlit est utile pour développer rapidement des applications d’IA et de données sans recourir à une chaîne d’outils d’interface utilisateur traditionnelle. Azure App Service offre un hébergement géré pour les applications web et les API.
Dans une configuration d’entreprise basée sur des agents, l’interface utilisateur va au-delà d’une simple boîte de chat. Elle peut afficher l’avancement de l’agent, les sources consultées, l’état du flux de travail, les résultats des outils, les demandes d’approbation, les documents générés ainsi que les interactions impliquant un humain. C’est là que l’IA devient accessible aux utilisateurs professionnels.
Niveau 2 : ingestion de documents
Un système performant a besoin d’accéder à des informations pertinentes, or les connaissances d’une entreprise sont rarement présentées sous un format ordonné. Elles sont dispersées dans des PDF, des fichiers Word, des diapositives, des scans, des pages web, des bases de données, des e-mails et bien d’autres sources. L’ingestion permet de collecter et d’extraire du contenu à partir de toutes ces sources.
Les outils utilisés à cette fin sont Azure AI Content Understanding, Apache Tika, Microsoft Fabric, LangChain ainsi que des moteurs d’OCR. L’OCR est essentiel lorsque les informations se trouvent à l’intérieur de scans ou d’images. Apache Tika extrait du texte et des métadonnées à partir d’une très grande variété de formats. Microsoft Fabric contribue à des workflows de données d’entreprise plus larges, tandis qu’un framework comme LangChain peut relier les composants d’ingestion aux pipelines d’IA.
L’objectif est simple : transformer les informations d’entreprise dispersées en contenus que les machines peuvent traiter. Sans une couche d’ingestion fiable, même le modèle le plus sophistiqué aura du mal à fournir des réponses pertinentes sur votre organisation.
Couche 3 : segmentation et prétraitement
L’extraction de texte n’est que le début. Un document de 200 pages ne peut pas être intégral dans chaque demande de modèle, il faut donc diviser les documents volumineux en unités plus petites et significatives. Ces segments peuvent être des paragraphes, des sections, des pages ou des unités sémantiques, et LangChain ainsi que d’autres frameworks proposent plusieurs stratégies de segmentation.
Un bon découpage ne consiste pas simplement à diviser le texte tous les quelques centaines de caractères, car un mauvais découpage détruit le contexte. Lorsqu’une définition est séparée de l’explication qui lui donne son sens, la récupération peut fournir des informations incomplètes. Des blocs trop grands rendent la récupération imprécise, tandis que des blocs trop petits font perdre des relations importantes. La stratégie de découpage influence donc directement la qualité de tout ce qui suit.
Le prétraitement consiste à nettoyer le texte, à supprimer le contenu inutile, à normaliser les formats, à extraire des métadonnées, à détecter la structure du document et à enrichir les blocs de informations supplémentaires. La qualité de la récupération ultérieure dépend souvent de ces étapes préliminaires.
Niveau 4 : embeddings
Une fois les documents découpés en blocs, le système a besoin d’un moyen de saisir leur signification. Un modèle d’embedding transforme le texte en un vecteur numérique, de sorte que des concepts similaires se trouvent proches les uns des autres dans l’espace des embeddings.
Comparez une demande de réinitialisation du mot de passe d’un employé à une demande d’information sur la façon de modifier les identifiants d’accès au travail. Le libellé est différent, mais l’intention est similaire, et un bon modèle d’embedding le reconnaît. Parmi les fournisseurs proposés pour cette couche figurent OpenAI, Cohere ainsi que des services d’IA basés sur Azure. Les vecteurs générés servent de base à la recherche sémantique, ce qui en fait l’un des changements les plus importants dans cette architecture : le langage humain devient une représentation mathématique, et cette représentation permet d’évaluer la similarité sémantique.
Couche 5 : la base de données vectorielle
Les embeddings doivent être stockés dans un endroit permettant une recherche rapide de similarité, et c’est là la fonction de la base de données vectorielle. Le schéma mentionne Milvus, FAISS, Azure AI Search, Azure Cosmos DB et Azure Database for PostgreSQL. Ils diffèrent beaucoup en termes de capacités et de modèle de déploiement, mais tous visent une récupération efficace grâce à la similarité sémantique.
Lorsqu’un utilisateur pose une question, la requête est elle-même convertie en un embedding, et le système cherche les vecteurs les plus proches. Les fragments correspondants sont ensuite transmis aux couches suivantes. C’est la base de la plupart des systèmes de génération augmentée par la récupération d’informations.
Couche 6 : la couche de récupération
Une base de données vectorielle stocke des informations, mais c’est la couche de récupération qui décide de ce qui est affiché au modèle. Cette distinction peut facilement être négligée. La récupération peut s’appuyer sur la similarité sémantique, la recherche par mots-clés, le filtrage des métadonnées, la recherche hybride, le réclassement et d’autres techniques ; des outils tels que Azure AI Search, LangChain et LlamaIndex couvrent ces méthodes.
Une configuration avancée combine différentes stratégies. La recherche sémantique permet de trouver des documents conceptuellement liés, tandis que la recherche par mots-clés garantit que les identifiants exacts, les noms de produits, les numéros de politique ou les termes techniques ne soient pas manqués. Il s’agit d’une récupération hybride, et les systèmes RAG d’entreprise intègrent de plus en plus des filtres de métadonnées, un réclassement, des graphes de connaissances et d’autres mécanismes supplémentaires.
Le but n’est pas de récupérer autant d’informations que possible, mais bien d’obtenir les bonnes informations.
Niveau 7 : ingénierie des prompts
Après la récupération, le système doit élaborer des instructions appropriées pour le modèle de langage. Un prompt de production va bien au-delà de la simple question de l’utilisateur ; il peut inclure des instructions système, du contexte récupéré, l’historique de la conversation, des règles métier, des exigences de format de sortie, des contraintes de sécurité, des exemples, des définitions d’outils et des métadonnées. LangChain, Promptify et DSPy sont des exemples d’outils qui aident à structurer et à ajuster ces prompts.
La conception de prompts dépasse également la simple création manuelle de formulations astucieuses. L’attention se porte désormais sur l’ingénierie du contexte, qui pose une question plus large : que doit recevoir le modèle, dans quelle structure et à quel stade du flux de travail ? Cela revêt une importance encore plus grande pour les agents, qui peuvent construire dynamiquement un contexte à partir d’actions antérieures, de matériaux récupérés, de résultats produits par des outils et de résultats intermédiaires.
Niveau 8 : le LLM
Au cœur se trouve le grand modèle de langage, où ont lieu la compréhension du langage, le raisonnement, la génération de texte et l’exécution des instructions. Les plateformes et modèles mentionnés incluent Azure, OpenAI, LLaMA et Mistral AI. Le modèle reçoit la demande ainsi qu’un contexte et des instructions soigneusement préparés.
Un principe mérite d’être rappelé : le LLM n’est pas l’application dans son intégralité. Il s’agit d’un composant au sein d’un système bien plus vaste, et une application en production nécessite des mécanismes de récupération des données, d’orchestration, de sécurité, d’évaluation, de surveillance, d’infrastructure ainsi que de logique métier associés. Cela devient particulièrement évident lors du passage du prototype à la production d’entreprise.
Des applications LLM aux agents
Il est utile de distinguer une application LLM conventionnelle d’une application basée sur des agents. Une application de base suit cette séquence : utilisateur, prompt, LLM, réponse. Une application RAG suit plutôt : utilisateur, récupération des données, contexte, LLM, réponse. Un système basé sur des agents est bien plus dynamique : utilisateur, agent, planification, récupération des données, outils, LLM, évaluation, actions supplémentaires, réponse finale. L’agent décide de ce qu’il faut faire ensuite et ne se contente pas de suivre une séquence fixe.
Supposons que quelqu’un demande pourquoi le pipeline de production d’hier a échoué et ce qu’il convient de faire. Un agent peut consulter l’historique d’exécution, examiner les journaux, interroger les bases de données, analyser les messages d’erreur, se référer aux politiques opérationnelles, identifier la cause probable et éventuellement recommander ou appliquer une correction approuvée. Cela diffère fondamentalement de la simple rédaction d’un paragraphe de texte.
Niveau 9 : infrastructure et déploiement
Un prototype bien fini ne constitue pas pour autant un produit prêt pour la production. Le passage en production exige une infrastructure scalable, des réseaux fiables, des mesures de sécurité, une automatisation du déploiement, une gestion efficace des ressources ainsi que de la résilience. Les architectures concernées sont Azure Container Apps, Azure Kubernetes Service, Docker et Kubernetes.
Docker empaquette les applications dans des conteneurs portables. Kubernetes orchestre les charges de travail conteneurisées dans des environnements distribués. Azure Kubernetes Service est une offre Kubernetes gérée, tandis qu’Azure Container Apps simplifie le déploiement de conteneurs sans avoir à gérer l’ensemble de l’environnement Kubernetes.
Cette couche est importante lorsque un système doit faire face à un fort trafic d’utilisateurs, à de nombreux workflows d’agents simultanés, à des charges liées à l’inférence de modèles, au traitement en arrière-plan, aux pipelines d’ingestion de documents, à des tâches longues, aux intégrations avec des outils externes et aux exigences de sécurité d’entreprise. Un modèle peut être excellent, mais c’est l’infrastructure qui détermine si cette excellence peut être fournie de manière fiable à grande échelle.
Couche 10 : observabilité et évaluation
L’observabilité fait partie des aspects les plus négligés dans l’ingénierie de l’IA. Les applications traditionnelles peuvent être surveillées grâce à l’utilisation du CPU, à la mémoire, à la latence, aux erreurs et au taux de requêtes. Les applications d’IA nécessitent davantage. Les équipes doivent savoir ce que le modèle a reçu, ce qui a été récupéré, quels outils ont été utilisés, quelles décisions en ont résulté, la durée de chaque étape, le nombre de tokens et si la réponse finale a été utile.
Azure AI Foundry, OpenTelemetry et Grafana entrent en jeu ici. OpenTelemetry collecte des données de telemétrie dans les applications distribuées, tandis que Grafana permet de visualiser les métriques opérationnelles et au niveau de l’application.
L’évaluation constitue une autre dimension. Les systèmes de production peuvent avoir besoin de scores relatifs à la pertinence, au fondement des informations, aux hallucinations, à la qualité de la récupération des données, à la latence, au coût, à la sécurité et à la satisfaction des utilisateurs. Les agents élevent la barre, car leurs actions doivent être évaluées en même temps que la réponse finale :
- A-t-il choisi le bon outil ?
- A-t-il récupéré les bonnes informations ?
- A-t-il effectué des appels à des outils inutiles ?
- A-t-il suivi le flux de travail correct ?
- A-t-il cessé son fonctionnement une fois la tâche terminée ?
- A-t-il escaladé correctement la situation lorsqu’une intervention humaine était nécessaire ?
Ces questions font de l’observabilité et de l’évaluation des éléments essentiels dans le développement d’IA en production.
Pourquoi l’ensemble de l’écosystème est important
Une idée reçue courante veut que la création d’une application d’IA signifie simplement choisir un modèle LLM performant et y ajouter une interface utilisateur. Cela peut fonctionner pour une démonstration, mais cela reflète rarement ce qu’exige une plateforme d’IA d’entreprise.
Imaginons qu’un employé demande à un assistant quelles sont les politiques de l’organisation pour gérer un problème client particulier. Le système doit comprendre la demande, trouver les documents de politique appropriés, sélectionner les sections pertinentes, les fournir au modèle, produire une réponse fondée, éventuellement citer sa source, appliquer les politiques de sécurité, surveiller l’interaction et évaluer si la réponse a été utile. Chaque couche joue un rôle : l’interface utilisateur permet l’interaction, l’ingestion fournit les connaissances, le prétraitement les rend utilisables, les embeddings capturent le sens, les bases de données vectorielles stockent des représentations recherchables, le système de récupération trouve le contexte, les prompts structurent l’information, le LLM génère la réponse, l’infrastructure assure échelle et fiabilité, et l’observabilité offre visibilité et responsabilisation. En ce sens, l’IA moderne est full-stack.
Choix des outils
Les technologies présentées dans l’architecture de référence ne constituent pas une liste à suivre intégralement. Chacune représente une option pour son niveau respectif. Une entreprise pourrait choisir React et Next.js dès le départ, Azure AI Content Understanding pour le traitement des documents, LangChain pour l’orchestration, un modèle d’incorporation hébergé, Azure AI Search pour la récupération d’informations, un modèle hébergé sur Azure, ainsi que Azure Container Apps pour faire fonctionner tout cela. Une autre entreprise pourrait opter pour un ensemble complètement différent.
La leçon la plus importante est que l’architecture précède les outils. Les exigences métier déterminent l’architecture, celle-ci définit les capacités nécessaires à chaque niveau, et ce n’est qu’alors que l’on choisit des technologies spécifiques.
Mieux qu’un LLM
La vision full-stack explique également pourquoi les projets agents deviennent rapidement complexes. Un agent a besoin de connaissances métier grâce au RAG, de données structurées issues de bases de données, d’informations externes via des API, de capacités opérationnelles grâce à des outils, ainsi que d’une exécution de workflows via des systèmes d’orchestration. Il nécessite également des mécanismes de contrôle : authentification et autorisation, mesures de protection de la vie privée des données, protection contre l’injection de prompts, permissions pour les outils, étapes d’approbation humaine, traces d’audit et cadres d’évaluation.
Ainsi, l’IA agente se situe à l’intersection de plusieurs disciplines : ingénierie logicielle, ingénierie des données, ingénierie de l’IA, ingénierie cloud, sécurité et observabilité. Créer des agents de niveau production représente un défi d’ingénierie, et non simplement un exercice de rédaction de prompts.
Comment l’architecture des applications a évolué
Le secteur a traversé différentes étapes. Les premières applications d’IA étaient axées sur les modèles. RAG a ensuite relié les modèles à des connaissances externes. Les systèmes renforcés par des outils ont permis aux modèles d’interagir avec des capacités extérieures. Aujourd’hui, l’IA agente combine modèles, récupération d’informations, outils, mémoire, planification, orchestration et évaluation. Cette évolution va du simple LLM à RAG, à l’utilisation d’outils, aux agents, aux systèmes multi-agents, et à mesure qu’elle progresse, l’infrastructure environnante devient de plus en plus importante.
Où commencer
Toute application n’a pas besoin de l’ensemble de ces technologies. Un outil simple de réponse à des questions peut se contenter d’un LLM de base. Si l’application a besoin de connaissances privées ou fréquemment mises à jour, ajoutez RAG. Lorsque les relations entre les entités sont au cœur du problème, envisagez une recherche basée sur des graphes. Lorsque le système doit planifier des tâches, choisir des outils, exécuter plusieurs étapes et prendre des décisions en temps réel, l’IA agente s’avère plus adaptée.
L’objectif ne devrait pas être l’architecture la plus complexe, mais plutôt la plus simple capable de résoudre le problème de manière fiable.
Que vient ensuite ?
Le domaine est encore en évolution. Les graphes de connaissances, les bases de données vectorielles, les cadres d’agents, les moteurs de flux de travail, les modèles multimodaux, les outils d’évaluation et les plateformes cloud risquent de se rapprocher davantage les uns des autres. Les applications prendront en charge des images, de l’audio, de la vidéo, des données structurées, des systèmes d’entreprise et des flux de travail du monde réel, en plus du texte. Surveiller et évaluer un système pèsera autant que le choix de son modèle. Ce qui nous attend concerne moins uniquement des modèles plus intelligents que des systèmes fiables construits autour d’eux.
En résumé
L’IA agente n’est pas une seule technologie, mais un ensemble complet. Du frontend où interagissent les utilisateurs, en passant par l’ingestion et le prétraitement, les embeddings et les bases de données vectorielles, la récupération d’informations et les prompts, jusqu’aux LLM, le déploiement et la surveillance, chaque couche influence l’intelligence que le système finit par afficher. Le LLM n’est qu’une partie. Un système agente de niveau production nécessite les bons données, une stratégie de récupération adaptée, une orchestration efficace, des infrastructures solides et des méthodes d’évaluation fiables. La capacité des modèles importe moins que la qualité de conception des systèmes qui les entourent.
Lectures complémentaires
- Une stack web pour les startups à l’ère des agents IA : Next.js, MUI et Firebase — Quels outils se révèlent efficaces lorsque des agents écrivent une grande partie du code : Next.js, MUI, Firebase, Vercel, PostHog ainsi qu’une configuration d’agent minimale, avec les raisons derrière chaque choix.
- Ce qu’un agent de différenciation de modèle découvre réellement — Un outil d’audit de type boîte noire a comparé un modèle de base avec un LoRA financier : 82 % des tests ont révélé des changements de longueur et de structure, tandis que la modification prévue concernant le raisonnement sur les risques est restée cachée.