Créer un agent RAG avec Azure AI Foundry

Dans un précédent article, Créer son premier assistant IA RAG avec Node.js, je montrais comment construire un RAG de zéro, à la main, en passant par le code et les principales briques techniques.

Cette fois, l'angle est différent : il s'agit d'observer comment Azure AI Foundry permet d'arriver plus vite à un résultat exploitable, sans reconstruire soi-même toute la mécanique.

L'objectif est simple : créer un projet, déployer un modèle, ajouter une knowledge base, configurer l'agent, lancer quelques tests, puis brancher le monitoring. À ce stade du POC, le coût affiché côté plateforme est de €0.00.

Avant de commencer : qu'est-ce que Azure AI Foundry ?

Azure AI Foundry est la plateforme de Microsoft pensée pour concevoir, tester, déployer et superviser des applications IA, en particulier des agents. L'idée n'est pas seulement de proposer un simple écran de chat, mais de réunir dans un même environnement les modèles, les services de recherche, les garde-fous de sécurité, l'observabilité et l'intégration avec le reste d'Azure.

Le schéma montre assez bien la logique d'ensemble. Sur la gauche, on retrouve les points d'entrée pour les développeurs, comme Copilot Studio, Visual Studio, GitHub ou le Foundry SDK. Au centre, Azure AI Foundry joue le rôle de couche d'orchestration avec les modèles, le service d'agents, la recherche, les services IA Azure, le machine learning, la content safety et l'observabilité. En dessous, toute la partie sécurité, gouvernance et options de déploiement rappelle que la plateforme est profondément liée à l'infrastructure Azure.

Autrement dit, Azure AI Foundry ne remplace pas Azure : la plateforme s'appuie dessus. C'est justement ce lien qui permet de passer plus facilement d'un test rapide à quelque chose de plus structuré. Par exemple, lorsqu'il faudra ajouter de l'observabilité à un agent, il suffira de le relier à des services Azure comme Application Insights et Azure Monitor, au lieu de repartir de zéro pour toute la partie supervision.

Étape 1 : créer un nouveau projet Foundry

La première chose à faire, c'est créer un projet dans Azure AI Foundry. Un projet, c'est votre espace de travail. C'est là que vous allez rattacher vos modèles, configurer vos agents, brancher vos données et suivre ensuite ce qui se passe.

Depuis la page d'accueil de Foundry, il suffit de cliquer sur New project, de choisir un nom, puis de le rattacher à un hub Azure existant, ou d'en créer un nouveau.

PS : pour l'instant, je ne bascule pas sur la V2 de la nouvelle interface Foundry. On en reparlera un peu plus bas.

Le hub, lui, joue un rôle plus large. On peut le voir comme la ressource parente qui regroupe les connexions, les accès et, derrière, une partie de la logique de facturation. C'est important à comprendre, parce qu'on n'est pas obligé de recréer tout cet environnement à chaque nouveau test.

À retenir : si vous faites plusieurs POC ou que vous travaillez à plusieurs, vous pouvez très bien garder un seul hub et créer plusieurs projets à l'intérieur.

Étape 2 : déployer un modèle

Une fois le projet prêt, il faut déployer le modèle qui servira de cerveau à l'agent. Sans surprise, c'est lui qui va recevoir les questions, exploiter le contexte récupéré par le RAG, puis générer la réponse finale.

Dans Build > Models, on clique sur Deploy model, on choisit le modèle voulu, puis on lui donne un nom de déploiement.

Dans mon test, j'ai choisi gpt-4.1-mini. Pour un POC RAG ou un usage interne, c'est un choix très raisonnable : on reste sur un modèle solide, moins coûteux qu'un plus gros modèle, sans tomber non plus dans quelque chose de trop limité. Pour celles et ceux qui ont surtout connu gpt-4o, on peut le voir ici comme un choix plus léger et plus économique pour ce type de scénario.

Le déploiement prend peu de temps. Une fois actif, le modèle devient directement utilisable dans le Playground ou via l'API. Et ça, franchement, c'est agréable : on passe vite de la configuration au test réel.

Étape 3 : ajouter une knowledge base

C'est à ce moment-là que le RAG commence vraiment à exister. Tant qu'on n'a pas branché de source documentaire, on a juste un agent conversationnel classique. Dès qu'on ajoute une knowledge base, l'agent peut aller chercher de l'information dans nos propres documents avant de répondre.

Dans Build > Knowledge, on ajoute une source de données. Cela peut être des PDF, des documents Word ou d'autres formats pris en charge par la plateforme. En revanche, à ce stade, les fichiers Excel n'en font pas partie.

On remarque aussi dans l'interface qu'il sera possible d'ajouter assez facilement d'autres sources ou outils, par exemple SharePoint ou Tripadvisor. Tout cela ne repose pas forcément sur MCP : dans Foundry, certaines intégrations sont proposées nativement ou via des partenaires.

Pour ce premier test, j'ai simplement choisi File upload, puis j'ai envoyé un petit fichier Markdown contenant des villes fictives. C'est un très bon point de départ pour un RAG, parce que le but est justement de vérifier que l'agent répond à partir de la base de connaissance fournie, et non à partir de ce que le modèle connaissait déjà pendant son entraînement. Avec un jeu de données inventé, le test devient tout de suite plus propre.

Voir le fichier Markdown utilisé pour le test

# Villes de France

Ce fichier contient des villes de France.

## Liste

- Montelune
- Riveciel
- Valdoré
- Clairbois
- Rochebrume
- Bellenac
- Aigleval
- Port-Émeraude
- Saint-Lysor
- Novacourt
- Villedor
- Brisemer
- Hauterive
- Lunévia
- Cornebrise

## Quartier

| Ville | Quartier |
| --- | --- |
| Montelune | Les Amandiers |
| Riveciel | Quartier des Brumes |
| Valdoré | Hauts de Valdoré |

Une fois ce fichier envoyé, on arrive sur Agents playground, où la base de connaissance nouvellement ajoutée apparaît directement dans la configuration de l'agent.

Ce que j'aime bien ici, c'est que Foundry masque une bonne partie de la mécanique technique sans l'empêcher d'exister. Derrière cette étape, la plateforme va :

• découper les documents en morceaux
• générer des embeddings
• stocker le tout dans un vector store

Dans mon cas, le vector store créé s'appelait AgentVectorStore_87451.

Ensuite, quand l'agent reçoit une question, il commence par chercher dans ce vector store les passages les plus pertinents. Puis il injecte ces extraits dans le contexte envoyé au modèle. C'est exactement ça, le principe du RAG : ne pas répondre seulement avec la mémoire générale du modèle, mais avec un appui explicite sur une base documentaire ciblée.

Il y a aussi un autre point important à remarquer dans l'image précédente : le champ Instructions. Ce champ sert à définir le comportement de base de l'agent. Autrement dit, la knowledge base ne suffit pas à elle seule. Il faut aussi expliquer clairement au modèle comment il doit s'en servir.

Dans mon test, j'ai utilisé les instructions suivantes :

Tu es un assistant qui répond uniquement en te basant sur les documents fournis dans la base de connaissance attachée à cet agent.
Si la réponse n'est pas présente dans les documents, réponds exactement : "Je ne sais pas à partir des documents fournis."
N’invente jamais d’information.
Quand c’est possible, cite le nom du fichier ou le passage utilisé.
Réponds en français.

Ce type d'instructions est particulièrement utile dans un RAG, parce qu'il aide à cadrer le modèle : répondre à partir des documents, admettre quand l'information manque, et éviter autant que possible les réponses inventées.

Étape 4 : tester l'agent dans le Playground

Une fois l'agent prêt, le plus simple est de le tester directement dans Build > Agents.

Dans mon test, je lui ai demandé : okey donne moi la liste des ville de france. Le résultat m'a tout de suite rassuré : l'agent a bien répondu à partir du fichier fourni, avec les villes fictives de la base de connaissance. Paris, par exemple, n'apparaissait pas dans la réponse, alors que le modèle la connaît évidemment déjà. C'est un bon signal : cela montre qu'il s'appuie bien sur la base documentaire attachée à l'agent.

Le Playground intégré permet justement de faire ce type de vérification très vite, sans écrire une ligne de code. C'est souvent l'étape la plus itérative du processus, mais aussi celle où l'on voit si l'agent commence réellement à devenir fiable.

Étape 5 : brancher le monitoring

Construire un agent, c'est bien. Savoir ce qu'il fait en conditions réelles, c'est mieux.

Pour cela, Azure AI Foundry s'appuie sur deux ressources Azure : Application Insights et Azure Monitor. Pour les relier au projet, il suffit d'aller dans les Settings du projet Foundry puis dans Tracing, d'y connecter une ressource Application Insights existante, ou d'en créer une nouvelle, puis de faire la même chose avec une ressource Azure Monitor. Ce sont ces deux ressources, à créer et brancher côté portail Azure, qui permettent aux métriques de remonter correctement dans la plateforme.

Une fois ce branchement fait, on commence à récupérer des indicateurs utiles :

• le nombre de runs de l'agent
• la consommation de tokens
• le taux de succès
• le nombre d'appels aux outils
• les erreurs éventuelles

À partir de là, l'étape suivante devient assez naturelle : sortir du Playground et brancher l'agent dans une vraie application. On peut très bien imaginer un petit intranet d'entreprise en Angular, avec une interface de chat côté front, tout en envoyant correctement les traces vers Foundry pour garder le monitoring en place.

Étape 6 : passer du Playground au code

L'avantage de Foundry, c'est qu'il ne faut pas repartir d'une page blanche. Dans Playground > View code, la plateforme propose déjà des exemples de code prêts à l'emploi en Python, C# et JavaScript. On peut donc récupérer cette base, puis l'intégrer assez facilement dans sa propre application.

Dans mon cas, j'ai testé le sample C#, puis j'y ai ajouté ce qu'il fallait pour envoyer les traces. La configuration de départ ressemblait à ceci :

{
  "Foundry": {
    "ProjectEndpoint": "https://your-foundry-resource.services.ai.azure.com/api/projects/your-project",
    "AgentId": "your-agent-id",
    "Message": "Bonjour",
    "TenantId": "your-tenant-id",
    "ClientId": "your-client-id",
    "ClientSecret": "your-client-secret"
  }
}

Pour récupérer ces valeurs rapidement dans Azure :

• ProjectEndpoint et AgentId se récupèrent côté projet Foundry
• TenantId et ClientId se récupèrent dans Microsoft Entra ID > App registrations > Overview
• ClientSecret se crée dans Certificates & secrets

Attention à un point classique : il faut copier la valeur du secret, pas le Secret ID. Et l'application enregistrée doit aussi avoir un rôle sur la ressource Foundry, typiquement Azure AI User via Access control (IAM).

Concrètement, j'avais surtout ajouté la couche OpenTelemetry avec l'export Azure Monitor, puis quelques Activity et tags autour de la session et des tours de chat pour envoyer les traces utiles.

Ici, le but n'était pas de coder pour coder. L'exemple de code fourni dans l'onglet Foundry suffit largement pour démarrer vite. En revanche, dès qu'on veut faire évoluer le code proprement, la séparation des responsabilités devient bien plus intéressante que la démo brute.

Dans mon test, cela donnait une structure de ce genre :

Foundry/
├── Rag.cs
├── Auth/
│   └── FoundryCredentialFactory.cs
├── Configuration/
│   └── FoundrySettingsLoader.cs
├── Conversation/
│   ├── FoundryConversationContext.cs
│   ├── FoundryConversationService.cs
│   ├── FoundryMessagePrinter.cs
│   └── FoundryRunService.cs
└── Telemetry/
    └── FoundryMonitoring.cs

L'exemple de code fourni par Foundry mélange souvent le démarrage, l'authentification, la conversation et l'observabilité dans le même flux. L'intérêt de cette structure, ce n'est pas d'écrire plus de code, mais de rendre chaque responsabilité explicite : configuration, authentification, exécution RAG, rendu et monitoring.

Voici ensuite le résultat, avec une expérience assez proche de ce qu'on obtient dans l'interface Foundry. À partir de là, il devient facile d'imaginer ce type de brique branchée dans un intranet d'entreprise, une boutique en ligne, ou n'importe quelle application métier, tout en gardant l'infrastructure côté Foundry. Et ça, c'est quand même assez cool.

Le new Foundry et l'onglet Monitor

Jusqu'ici, les captures de l'article reposaient sur l'ancienne interface de Foundry. Et il faut bien le dire : la nouvelle version change pas mal de choses.

On sent que Microsoft a cherché à simplifier l'expérience. La navigation est plus claire, les sections sont mieux rangées, et surtout on comprend plus vite où aller selon ce qu'on veut faire. Là où l'ancienne interface donnait parfois l'impression d'être une superposition de services Azure, la nouvelle ressemble davantage à un outil pensé pour piloter un agent de bout en bout.

Sur cette capture, on voit bien ce que cela apporte. L'onglet Monitor rassemble au même endroit les informations utiles pour suivre la vie de l'agent :

• le nombre de runs
• les tokens consommés
• les appels aux outils
• le taux d'erreur

Et c'est là que le lien avec la partie code devient intéressant. Les insights et les traces envoyés depuis l'application remontent ensuite ici. Autrement dit, ce qu'on a pris le temps de brancher côté code devient visible presque immédiatement dans une interface propre, lisible, et franchement agréable à consulter.

Et c'est probablement le point qui m'a le plus fait aimer Foundry. Quand on développe soi-même un RAG, on se dit souvent au départ qu'on va réduire les coûts. Ce n'est pas faux. Mais dès qu'on veut faire les choses proprement, il faut ajouter de quoi observer les runs, suivre les erreurs, tracer les appels, stocker les métriques. Et petit à petit, on recommence à empiler de la ressource chez son provider.

Au final, le raisonnement "je code tout moi-même pour payer moins cher" devient un peu moins évident. Parce qu'il faut aussi compter ce qu'on ajoute autour, et le temps passé à relier tout ça. Sur ce point précis, je trouve que Foundry commence à avoir un vrai argument qualité-prix.

Pour celles et ceux qui débutent sur le sujet et veulent mieux comprendre ce qu'il se passe sous le capot, mon article Créer son premier assistant IA RAG avec Node.js reste un bon complément. J'y prends davantage le temps de poser les définitions, d'expliquer le RAG lui-même, et de montrer comment les briques s'assemblent lorsqu'on choisit de tout piloter manuellement.