Du modèle à l'agent : instructions, outils et connaissance

Utiliser un grand modèle de langage (LLM) dans un chat est facile ; en choisir un pour la production, moins. « Introduction to generative AI and agents in Azure » sur Microsoft Learn parcourt ce saut dans un ordre sensé : d'abord comprendre ce qu'est l'IA générative, ensuite choisir et évaluer un modèle dans le catalogue Microsoft Foundry, seulement ensuite le déployer, tester ses paramètres, et à la fin l'empaqueter dans un agent. Ce post suit ce parcours (du catalogue à l'agent) et se ferme sur la différence qui compte : un modèle produit du texte, un agent agit.

Ce qu'est l'IA générative et ce qu'elle n'est pas

L'intelligence artificielle générative est le sous-ensemble de l'IA centré sur la création de contenu nouveau. Ses applications habituelles sont la création de contenu marketing, le service client avec des agents virtuels, la génération de code, la génération d'images et de vidéos, et l'apprentissage personnalisé. Ça la sépare des applications d'IA qui classifient, détectent ou prédisent : les génératives produisent quelque chose qui n'existait pas avant (un texte, une image, un plan) et c'est pourquoi elles servent à assister une personne plutôt qu'à lui signaler quelque chose.

Elles sont la base des solutions d'IA générative et aussi des solutions agéntiques : les premières créent du contenu, les secondes agissent avec des outils sur l'environnement. Le choix dépend du besoin : une application légère peut très bien fonctionner avec un petit modèle, tandis qu'un cas spécialisé peut demander un modèle de domaine. La bonne réponse dépend de chaque charge de travail.

Choisir un modèle : catalogue, familles et tâche

Microsoft Foundry réunit un catalogue de modèles avec deux origines distinctes : des modèles vendus directement par Azure (hébergés par Microsoft, avec des accords de niveau de service de niveau entreprise, sécurité préconfigurée et alignement de conformité) et des modèles de partenaires et de la communauté open source, qui admettent une expérimentation plus large et des tâches spécialisées. La distinction est d'opération et de portée : l'un priorise l'intégration et la conformité ; l'autre, la variété et l'innovation rapide pour des cas concrets. Le choix pratique sort de cette phrase : si le modèle doit cohabiter avec des exigences de conformité et des accords de service déjà clos, ce sont les hébergés par Microsoft qui conviennent ; s'il faut expérimenter avec une nouvelle famille ou un modèle spécialisé pour un cas concret, partenaires et communauté ouvrent le même catalogue sans changer de processus. Ce qui change en choisissant d'une origine ou de l'autre n'est ni la fiche ni la comparaison : c'est le type d'engagement que vous prenez envers qui fournit le modèle. Chaque entrée du catalogue décrit des capacités, des comparatifs de performance, des tâches d'inférence et d'ajustement fin, et une documentation d'IA responsable avec cartes de modèle, restrictions et avertissements. Les modèles se groupent par familles avec architecture ou lignée commune : GPT-5.x, Claude, Mistral Large, et GPT-4.1 quand la priorité est la faible latence. La liste fonctionne comme une carte : la famille adéquate dépend de ce que la tâche récompense (capacité générale ou latence courte).

Par type de tâche, le chemin est plus direct. Pour le chat, GPT-5.x, Claude Sonnet ou Opus, Mistral Large 3, DeepSeek ou de petits modèles comme Phi-4. Pour la codification, GPT-5.1-codex ou Claude Sonnet. Pour le résumé, des modèles de raisonnement comme GPT-5.x ou Claude. Pour les embeddings, text-embedding-3-small ou d'autres. Pour les tâches multimodales, Phi-4 multimodal, le chat multimodal de GPT-5.x ou Mistral Large 3. Pour un domaine spécifique, des modèles ajustés du catalogue. Et chaque déploiement qui en sort se caractérise par son type de point de terminaison, ses aspects clés et ses limites.

Évaluer avant de choisir

Choisir à l'œil du catalogue, c'est comment tout le monde commence et comment on se retrouve avec un modèle qui échoue en silence. Le processus qui fonctionne part de la compréhension de la charge de travail, du type de tâche et des contraintes ; le catalogue offre des tables de classement par qualité, sécurité et performance, et des comparaisons côte à côte filtrables par secteur, cas d'usage, type de modèle ou licence.

Le scoring utilise deux familles de métriques. Les classiques de NLP (traitement du langage naturel : precision, recall et F1) mesurent sur des jeux de données à réponse connue. Celles assistées par IA (solidité, pertinence, cohérence, fluidité et similarité GPT) évaluent la qualité du texte généré quand il n'existe pas de réponse unique correcte. Les évaluateurs de Foundry détectent, examinent et notent les problèmes de qualité et de sécurité, y compris la recherche de contenu nuisible ou de biais, mais ne les corrigent pas activement : ils signalent, ils ne réparent pas.

Un score général à lui seul ne suffit pas : deux modèles peuvent égaliser et se comporter différemment sur les documents, le jargon et les cas réels du projet. C'est pourquoi l'ordre du processus compte (d'abord la charge de travail, ensuite les comparaisons du catalogue, à la fin les tests avec vos propres données) ; à l'envers, on finit par choisir par popularité.

Déployer et appeler depuis le code

Choisir un modèle dans le catalogue, c'est le sélectionner ; le déployer, c'est le transformer en un service accessible par un point de terminaison stable, évolutif et sûr, avec une performance et une fiabilité cohérentes et sans usage non autorisé. En clair : choisir, c'est choisir ; déployer, c'est le publier pour que les applications l'appellent par API de façon prévisible et gouvernée. Les paramètres de déploiement sont le type de déploiement (performance standard, batch global ou performance provisionnée régionale), la version du modèle et la limite de tokens par minute. Un token est l'unité minimale de texte ou de données que le modèle traite ; la limite par minute est, en pratique, la bande passante du service.

Pour l'appeler depuis une application, le SDK (kit de développement logiciel) de Foundry expose un client Project avec des opérations Foundry et un client compatible OpenAI pour l'API de responses ; la plupart des applications utilisent les deux. Le schéma de départ est un client de chat léger dans un seul fichier Python : un client OpenAI pointé vers le point de terminaison du projet (base_url + /openai) avec sa clé, et un appel à responses.create avec le modèle déployé, un message système, un message utilisateur, max_output_tokens et temperature, en imprimant la sortie texte. L'état et le processus vivent côté serveur ; la configuration du client se réduit à des variables d'environnement et un script court.

Le playground de Foundry ferme la boucle. Là vous testez le prompt avec la température, le maximum de tokens de sortie et les instructions système, et quand ça vous convient le code équivalent sort prêt pour l'API de responses compatible OpenAI. L'expérience et le code de production commencent au même endroit, donc ce que vous avez réglé à l'œil ne se perd pas au passage au dépôt.

Les paramètres qui contrôlent la réponse

Trois boutons gouvernent ce que le modèle renvoie. La température contrôle créativité versus déterminisme : proche de zéro elle répond presque toujours pareil ; plus haute, elle prend plus de risques. Le maximum de tokens de sortie limite la longueur de la réponse et affecte directement la consommation. Les instructions système fixent le rôle et le comportement du modèle, et se distinguent de la demande de l'utilisateur : tandis que la question de l'utilisateur est ce qu'il demande, le message système fixe le ton, les outils et les limites de protection, et sa valeur se réutilise pareil dans le code. Une instruction système typique : « You are a helpful, step-by-step tutor. Cite sources. Refuse medical advice. » Ces mêmes lignes que vous testez dans le playground sont celles qui ensuite vont dans le fichier de configuration de l'app.

L'agent : modèle, instructions, outils et connaissance

Voici la différence centrale. Le modèle apporte ce qu'on appelle l'intelligence brute : de l'inférence pure sur une instruction. L'agent est le travailleur empaqueté et orienté tâches construit sur cette intelligence : un composant réutilisable qui réunit un modèle, des instructions (un prompt système avec rôle, style, contraintes et règles) et des outils. Les agents appellent des outils externes, divisent les objectifs en étapes, gardent une mémoire de travail et produisent des sorties structurées.

flowchart LR
    M[Modèle<br/>inférence pure] & I[Instructions<br/>rôle, style, règles] & H[Outils<br/>actions] & K[Connaissance<br/>RAG avec citations] --> A[Agent<br/>orienté tâches]
    A --> P[Project API avec l'agent-id]

La recette en un coup d'œil : quatre pièces qui se réunissent en un seul composant, et une unique porte de sortie, la Project API avec son agent-id.

Les outils sont des fonctionnalités invocables : interpréteur de code, fonctions ou API personnelles, un serveur MCP, recherche web. Ils permettent au modèle de réaliser de vraies actions, et s'administrent de façon centralisée dans le Catalogue d'outils de Foundry. La connaissance est l'autre couche : du contexte récupérable via RAG (génération augmentée par récupération) sur des documents ou jeux de données (PDF internes, SharePoint, Azure Storage, bases de connaissances multi-sources) avec ingestion, indexation, recherche et réponses fondées qui citent le dépôt utilisé. La règle qui résume la distinction : l'outil est l'action, la connaissance est le contexte. Lu comme diagnostic : si l'agent doit faire quelque chose, ça va dans les outils ; s'il doit savoir quelque chose, ça va dans la connaissance.

En construire un suit une séquence directe, et elle mérite d'être dite étape par étape parce que chaque maillon se teste séparément :

Choisir le modèle.
Écrire les instructions (« You are a helpful scheduling programming assistant that returns answers in concise bullets »).
Ajouter des outils et, si besoin, de la connaissance.
Enregistrer le modèle, les instructions et les outils comme agent.
Le tester dans le playground et l'appeler depuis le code avec le Project API en utilisant l'agent-id.

Foundry accompagne ce cycle avec des espaces de travail pour jouer et tester, construire, déployer, opérer et évaluer ; et il faut se rappeler que chaque projet est une ressource Azure avec un groupement de ressources sous-jacent (l'agent ne vit pas dans les airs, il vit dans un compte avec coûts et permissions). Pour l'utiliser depuis le code, le Foundry Projects SDK se connecte au projet et le Project API invoque l'agent avec l'identifiant qui apparaît dans la vue code du playground ; ce même chemin permet de l'intégrer dans du web, des bots ou des flux back-end et d'exécuter des tâches multi-étapes à l'échelle.

De la lecture à l'exécution

L'exercice de déploiement est resté en lecture : créer un modèle dans Foundry et l'utiliser dans un agent avec des outils de connaissance, avec la pratique complète d'ingestion et de réponses fondées, n'a pas été exécuté. Ce qui a été vérifié dans ce parcours, c'est le cadre (catalogue, évaluation, paramètres, déploiement et la différence modèle/agent) ; ce qui manque à tester, c'est le flux complet avec connaissance sur un abonnement à soi, et la raison est simple : ça exige de déployer de vraies ressources côté Azure, pas seulement de lire dessus.

Avec ça l'arc se ferme : du catalogue au modèle déployé, du modèle à l'agent avec instructions, outils et connaissance, et de l'appel depuis le code avec son identifiant. L'intelligence générative produit le contenu ; l'agent décide quoi faire pour le produire.

---

*Source : le module « Introduction to generative AI and agents in Azure » de Microsoft Learn.*