Ce qu'il y a sous une application d'IA dans Azure

Une application d'IA utilise des techniques comme la vision, la voix ou l'extraction d'informations pour des tâches qui demandent généralement une intelligence humaine, et son moteur est un modèle d'apprentissage automatique qui, en recevant une entrée, réalise l'inférence en appliquant ce qu'il a appris à l'entraînement. Tout le reste autour de ce moteur — la plateforme où il tourne et la façon de lui parler — est de l'ingénierie conventionnelle avec ses propres règles. Le module Microsoft Learn « Introduction to AI in Azure » parcourt cette pile complète. Ce post la parcours pareil : le modèle qui infère, la structure d'Azure, les fondations d'identité et de secrets, Microsoft Foundry avec sa paire ressource/projet, et comment on lui parle depuis le code par un point de terminaison.

Le moteur est un modèle

La distinction centrale vaut d'être posée d'abord : le modèle est le moteur de l'application. L'app orchestre l'entrée et la sortie ; le modèle fait la prédiction ou la génération. C'est pourquoi les applications d'IA se décrivent comme basées sur modèles (elles utilisent des modèles entraînés pour convertir des entrées en sorties) et dynamiques (elles peuvent s'améliorer avec le temps grâce au réentraînement ou au fine-tuning), à la différence des programmes statiques.

Ce « peuvent s'améliorer » est la différence de fond avec le logiciel classique. Un programme fait aujourd'hui ce que vous l'avez programmé à faire hier ; une application basée sur modèle peut changer de comportement quand les données avec lesquelles on l'entraîne à nouveau changent. Les domaines où elle est déjà en usage sont les habituels et ils grandissent : santé, finance, retail, fabrication et éducation.

Azure en quatre catégories

Azure groupe son offre en quatre catégories, et savoir dans laquelle tombe ce dont vous avez besoin accélère toute décision ultérieure :

Calcul : exécuter des charges dans le cloud.
Stockage : garder et administrer les données.
Réseaux : connecter les ressources entre elles, à Internet et à l'organisation.
App Services : construire et héberger des applications sans administrer les serveurs sous-jacents.

La quatrième est celle que vous utiliserez le plus en construisant des agents : vous décrivez l'application et la plateforme s'occupe de ce qu'il y a dessous.

La hiérarchie de l'accès

L'offre s'administre dans une structure à quatre niveaux, et chaque niveau répond à une question différente. Le tenant est l'espace dédié et isolé d'une organisation dans le cloud de Microsoft. L'abonnement est le conteneur de facturation qui lie l'usage à un moyen de paiement et applique des limites de coût et des quotas. Les groupes de ressources regroupent des ressources liées pour les administrer ensemble. Et une ressource est n'importe quel objet individuel qui est créé, avec type de ressource, région, niveau de performance et permissions.

flowchart LR
    I[Tenant<br/>l'espace isolé de l'organisation] --> S[Abonnement<br/>facturation, limites et quotas]
    S --> G[Groupe de ressources<br/>ressources liées]
    G --> R[Type de ressource · région<br/>niveau de performance · permissions]

La logique est administrative avant d'être technique : l'abonnement sépare les budgets, le groupe de ressources sépare les projets, et la ressource est ce qui touche le quotidien. En pratique, la structure sépare les départements, regroupe des ressources pour appliquer des politiques conjointes et facilite le contrôle des coûts. Toute la gouvernance des permissions d'Azure se suspend à cette hiérarchie.

Identité, secrets et hébergement

Les fondations d'une application d'IA dans Azure sont quatre pièces et aucune n'est optionnelle.

Identité et accès. Microsoft Entra ID contrôle qui accède aux ressources d'IA et le RBAC (role-based access control : qui a le droit de faire quoi) limite l'accès aux déploiements, aux ressources et aux données du modèle.

Secrets. Un secret est toute valeur confidentielle qui donne accès à un système, un service ou des données : clés d'API, chaînes de connexion, tokens OAuth, mots de passe. Dans Azure il se stocke dans Azure Key Vault, jamais dans le code ni sur GitHub, et l'application le récupère à l'exécution via une méthode sûre comme l'identité managée. L'exemple du chat classique le montre, et le trajet de la clé a quatre étapes :

L'application appelle le point de terminaison du modèle.
La requête inclut une clé pour s'authentifier.
Cette clé vit dans Key Vault comme secret.
À l'exécution l'app la récupère, sans que personne ne l'ait jamais écrite dans le dépôt.

La conséquence pratique est simple à énoncer et facile à enfreindre : la clé voyage par un canal qui n'est pas le dépôt. Si quelqu'un la colle dans le code, tout l'échafaudage de Key Vault reste pour la décoration.

Hébergement. Un host est l'environnement où tourne l'application. AKS organise les conteneurs et App Service héberge les applications web, les API et les tâches d'arrière-plan.

Escalade. Escaler signifie ajuster combien de machine reçoit l'application, et il y a deux chemins : la mise à l'échelle horizontale ajoute des instances de l'application ; la mise à l'échelle verticale augmente le CPU ou la mémoire de l'instance existante. Dans le cloud, l'autoscaling répond au CPU, aux requêtes ou à des métriques personnalisées, donc la question de « combien de machine » cesse d'être une décision manuelle.

Les données dont l'app a besoin

Secrets et identité sont la moitié visible ; l'autre moitié, c'est la donnée. Une application d'IA manie sept types, et chacun soutient une partie différente du cycle : données d'entraînement (avec lesquelles le modèle a été construit), données d'entrée d'inférence (ce qui arrive en production), sorties du modèle (ce qu'il renvoie), état de l'application, données de configuration et système, journaux et télémétrie, et données de sécurité et d'accès. Les trier importe : si vous mélangez les données d'entraînement avec celles de production, ensuite vous ne pourrez pas auditer ce qui s'est passé.

Microsoft Foundry et ses quatre domaines

C'est ici qu'apparaît la plateforme où tout converge. Microsoft Foundry est une plateforme unifiée as a service (PaaS : le cloud gère l'infrastructure et vous consommez le service) de niveau entreprise pour construire, déployer et administrer des applications et agents d'IA. Ses quatre domaines sont :

Models : un catalogue unifié de modèles tiers, tiers d'origine et open source.
Agents : des agents orientés tâches avec orchestration intégrée des messages, des outils et de la sécurité.
Tools : des services comme Azure Vision, Azure Language et Azure Speech.
Connaissance : ce qu'apporte Foundry IQ.

Les quatre couvrent le cycle complet d'un produit d'IA : choisir le modèle, monter l'agent, brancher des capacités spécialisées et lui donner votre propre connaissance. Les autres posts de cette série sur Foundry IQ, les agents et les outils couvrent chaque domaine à part.

Ressource et projet

Dans Foundry, il vaut distinguer deux niveaux qui se confondent souvent. La ressource Foundry est la ressource Azure : elle donne accès aux modèles, au service d'agents, à la gouvernance des déploiements, à la supervision, aux limites de sécurité et aux quotas. Le projet Foundry est l'espace de travail à l'intérieur de cette ressource, où l'on crée agents, évaluations, fichiers et jeux de données, index vectoriels, flows et connexions.

La relation est de conteneur à espace de travail : une ressource peut contenir plusieurs projets, un par cas d'usage. La ressource s'administre une fois ; les projets s'ouvrent par projet réel.

Client et serveur

Une application cliente est un programme avec lequel l'utilisateur interagit sur son appareil, et la division des responsabilités est nette. L'interface montre l'interface (écran ou ligne de commandes), recueille l'entrée en texte, voix ou image, la formate en prompt ou requête d'API, l'envoie au serveur et montre la sortie. Dans Foundry, le serveur est le déploiement du modèle : il reçoit le prompt, exécute l'inférence, applique les instructions système et les contrôles de sécurité, et renvoie la sortie.

flowchart LR
    U[Utilisateur] --> C[App cliente<br/>interface · formate la requête]
    C --> E[Point de terminaison<br/>clé ou token Entra]
    E --> S[Serveur Foundry<br/>inférence avec instructions et contrôles]
    S --> C

Le voyage complet d'une question suit cet ordre : l'utilisateur écrit, le client transforme le texte en une demande structurée en JSON, le point de terminaison vérifie que l'appelant apporte la bonne credential, le serveur infère en appliquant ses règles et renvoie la réponse, et le client la représente à l'écran. Quand la sortie n'est pas du texte (une image, un audio ou un JSON structuré), le dernier tronçon est le même : le serveur renvoie ce que le client a demandé et c'est tout.

Cette frontière explique des décisions qu'on voit ensuite sur la facture et dans la sécurité : ce qui est sensible (instructions, contrôles) vit côté serveur ; ce que l'utilisateur touche, côté client.

Le point de terminaison

Ce que le client parle avec le serveur est un point de terminaison : l'adresse HTTP par laquelle le code accède à une ressource Foundry, distincte des interfaces web pour les humains. Les interfaces exposées sont REST : des requêtes avec des en-têtes (format et authentification) et un corps JSON, et des réponses aussi en JSON.

Le point de terminaison est protégé : on n'y accède qu'avec la bonne clé d'API ou un token d'identité Microsoft Entra valide. Et il en existe deux types avec des destinations différentes : les points de terminaison au niveau projet servent à travailler avec le projet et ses ressources ; les points de terminaison du modèle envoient des messages aux modèles déployés. Choisir l'un ou l'autre dépend de ce que fait l'app : si elle touche des fichiers, des index ou des flows du projet, elle passe par celui de projet ; si elle envoie seulement des messages à un modèle déployé, par celui du modèle. Personne n'ouvre un point de terminaison dans le navigateur : c'est une adresse pensée pour le code, et c'est pourquoi elle est verrouillée.

Un appel typique est un POST vers un point de terminaison de projet avec les en-têtes Content-Type: application/json et Authorization: Bearer <token>, et un corps JSON avec le modèle et le message d'entrée ; la réponse revient en JSON avec la sortie du modèle. Pour le quotidien, la recommandation est d'utiliser les SDK (kits de développement logiciel) en Python, JavaScript ou C# plutôt que d'écrire les appels REST à la main, car ils abstraient l'interface REST.

De la lecture à l'exécution

Ce qui n'a pas été exécuté est l'exercice de bout en bout : créer et explorer un projet Microsoft Foundry et connecter une application cliente contre son point de terminaison. La théorie a été couverte entière, du modèle qui infère à l'en-tête d'autorisation ; il reste à le faire avec un vrai projet et à voir la première réponse JSON revenir par le canal.

Mon avis

La pièce voyante d'une application d'IA, c'est le modèle, et celle qui décide si le projet survit, c'est tout le reste : où vit le secret, qui détient le rôle, dans quel groupe de ressources se facture et quelle frontière il y a entre client et serveur. Azure met cet ordre en place avant que vous écriviez la première ligne de l'agent. Si vous allez lancer un projet d'IA, commencez par la hiérarchie et l'identité, pas par le modèle : le modèle se change ; les fondations coûtent cher à refaire.

---

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