Semantic Kernel ou Microsoft Agent Framework : que faire d'une application .NET existante

J’ai obtenu l’Applied Skills AZ-2005, centré sur Semantic Kernel, le 8 avril 2026. Cinq jours plus tôt, Microsoft publiait la version 1.0 de son successeur. Le calendrier dit l’essentiel de la situation : une partie des applications .NET qui intègrent l’IA aujourd’hui repose sur un framework dont Microsoft a déjà désigné la suite. Ce n’est pas une raison de paniquer ni de tout réécrire. C’est une raison de savoir précisément ce qui change, ce qui reste, et à quel moment agir.

Ce guide s’adresse aux équipes qui ont une application .NET en production, ou en cours de développement, avec du Semantic Kernel dedans. Il est tenu à jour : la date de révision figure en tête de page.

Où en sont les deux frameworks

Deux engagements publics de Microsoft encadrent la suite. Semantic Kernel 1.x reste supporté, avec correction des bugs critiques et des failles de sécurité, pendant au moins un an après la sortie d’Agent Framework de la préversion. Et le développement de nouvelles fonctionnalités se fait désormais principalement dans Agent Framework.

Concrètement : une application Semantic Kernel ne va pas s’arrêter de fonctionner. Elle va cesser de progresser. Le support garanti court au moins jusqu’en avril 2027, et rien ne garantit qu’il aille au-delà.

Ce qui ne bouge pas

C’est la partie que les annonces mettent le moins en avant, et c’est pourtant la plus rassurante pour une application existante.

Votre code métier. Les services, les règles, les validations, les accès aux données en Entity Framework ou en SQL, les contrôles d’habilitation : rien de tout cela ne dépend du framework d’orchestration. Si votre intégration IA a été faite proprement, l’IA appelle votre code métier à travers des fonctions exposées comme outils, et ce code ne change pas.

Les abstractions communes de .NET. Microsoft a sorti de Semantic Kernel les briques de base pour en faire des bibliothèques autonomes de l’écosystème .NET : Microsoft.Extensions.AI (l’interface IChatClient pour parler à un modèle, IEmbeddingGenerator pour les vecteurs) et Microsoft.Extensions.VectorData (collections, enregistrements et recherche vectorielle). Agent Framework repose sur ces deux bibliothèques. Un code qui les utilise déjà ne sera presque pas touché.

Votre couche vectorielle. Pour le RAG, Agent Framework en .NET utilise les implémentations de Microsoft.Extensions.VectorData, et la documentation liste SQL Server parmi les bases disponibles, à côté d’Azure AI Search, PostgreSQL, Qdrant ou Redis. Vos collections, vos modèles d’enregistrement et votre ingestion restent en place. Seul change le branchement de la recherche sur l’agent.

Ce qui change : la table de correspondance

La migration porte sur la couche agent. Le guide officiel de Microsoft la détaille ; voici les correspondances qui comptent en pratique.

À cela s’ajoutent des briques qu’Agent Framework apporte en version stable : des workflows à base de graphe pour enchaîner agents et fonctions de façon déterministe, la reprise sur point de contrôle pour les traitements longs, la validation humaine en cours de route, le middleware pour intercepter les appels, et l’observabilité par OpenTelemetry.

Le même agent, avant et après

Prenons un cas simple et courant : un assistant de support qui répond aux questions sur les commandes en appelant le référentiel de commandes de l’application. Le code métier, IOrderRepository, existe déjà et ne change pas.

Avec Semantic Kernel :

using System.ComponentModel;
using Microsoft.SemanticKernel;
using Microsoft.SemanticKernel.Agents;

public sealed class OrderTools(IOrderRepository orders)
{
    [KernelFunction, Description("Returns the current status of a customer order.")]
    public async Task<string> GetOrderStatusAsync(
        [Description("The order number, for example CMD-2026-0142.")] string orderNumber)
        => (await orders.FindAsync(orderNumber))?.Status ?? "unknown order";
}

// The kernel carries the model connector and the plugins.
Kernel kernel = Kernel.CreateBuilder()
    .AddAzureOpenAIChatCompletion(deploymentName, endpoint, credential)
    .Build();
kernel.Plugins.AddFromObject(new OrderTools(orders), "Orders");

ChatCompletionAgent agent = new()
{
    Name = "Support",
    Instructions = "Answer questions about customer orders. Never guess a status: call the tool.",
    Kernel = kernel,
    Arguments = new KernelArguments(new PromptExecutionSettings
    {
        FunctionChoiceBehavior = FunctionChoiceBehavior.Auto(),
    }),
};

AgentThread thread = new ChatHistoryAgentThread();
await foreach (AgentResponseItem<ChatMessageContent> item in agent.InvokeAsync(question, thread))
{
    Console.WriteLine(item.Message.Content);
}

Avec Agent Framework :

using System.ComponentModel;
using Azure.AI.OpenAI;
using Microsoft.Agents.AI;
using Microsoft.Extensions.AI;
using OpenAI.Chat; // AsAIAgent on the OpenAI ChatClient (package Microsoft.Agents.AI.OpenAI)

public sealed class OrderTools(IOrderRepository orders)
{
    // No framework attribute: a plain method, described for the model.
    [Description("Returns the current status of a customer order.")]
    public async Task<string> GetOrderStatusAsync(
        [Description("The order number, for example CMD-2026-0142.")] string orderNumber)
        => (await orders.FindAsync(orderNumber))?.Status ?? "unknown order";
}

var tools = new OrderTools(orders);

// No kernel: the agent is created from the chat client, tools included.
AIAgent agent = new AzureOpenAIClient(endpoint, credential)
    .GetChatClient(deploymentName)
    .AsAIAgent(
        instructions: "Answer questions about customer orders. Never guess a status: call the tool.",
        tools: [AIFunctionFactory.Create(tools.GetOrderStatusAsync)]);

AgentSession session = await agent.CreateSessionAsync();
AgentResponse response = await agent.RunAsync(question, session);
Console.WriteLine(response.Text);

Trois observations. La méthode métier est identique à un attribut près. Le code d’assemblage perd un tiers de ses lignes, parce que le Kernel et le plugin disparaissent. Et l’appel au modèle ne passe plus par un type d’agent propre au fournisseur : changer d’Azure OpenAI vers un autre fournisseur compatible ne touche que la ligne qui crée le client.

Côté injection de dépendances, l’enregistrement devient :

builder.Services.AddKeyedSingleton<AIAgent>("support", (sp, _) =>
    sp.GetRequiredService<IChatClient>().AsAIAgent(
        instructions: "Answer questions about customer orders. Never guess a status: call the tool.",
        tools: [AIFunctionFactory.Create(sp.GetRequiredService<OrderTools>().GetOrderStatusAsync)]));

Et le RAG ?

Si votre application interroge des documents métier, la recherche se branche désormais comme un fournisseur de contexte. TextSearchProvider prend une fonction de recherche, qui peut s’appuyer sur votre collection Microsoft.Extensions.VectorData existante, et l’exécute avant chaque appel au modèle ou l’expose comme outil que le modèle appelle à la demande :

AIAgent agent = chatClient.AsAIAgent(new ChatClientAgentOptions
{
    ChatOptions = new() { Instructions = "Answer from the provided documents and cite them." },
    AIContextProviders = [new TextSearchProvider(SearchDocumentsAsync, new TextSearchProviderOptions
    {
        SearchTime = TextSearchProviderOptions.TextSearchBehavior.BeforeAIInvoke,
    })],
});

La fonction SearchDocumentsAsync est celle que vous écrivez au-dessus de votre base : c’est là que restent le découpage métier des documents et le filtrage par habilitation, deux décisions que je détaille dans le guide RAG sur SQL Server 2025. Le framework change, ces deux décisions ne changent pas.

Que faire, selon votre situation

Le dernier point n’est pas un détail. Une migration est une bonne occasion de retirer de l’IA là où elle n’apporte rien : un calcul, un contrôle de format ou une règle de gestion n’ont rien à faire dans un agent. C’est le principe que je décris dans l’IA propose, le déterministe dispose : le modèle propose, une couche déterministe valide.

Checklist de migration

1. Inventorier. Lister tous les usages de Microsoft.SemanticKernel dans la solution et les classer : connecteurs de modèle, plugins et fonctions, agents, mémoire et recherche, filtres, modèles de prompt.
2. Isoler. Si ce n’est pas déjà fait, placer l’IA derrière une interface de votre domaine (par exemple IOrderAssistant), implémentée dans la couche infrastructure. C’est le même principe que l’extraction documentaire interchangeable que j’utilise en mission : le métier dépend d’un contrat, pas d’un framework.
3. Figer un jeu de référence. Avant de toucher au code, enregistrer une trentaine de questions réelles avec les réponses et les appels d’outils attendus. C’est lui qui dira si la migration a changé un comportement.
4. Basculer les outils. Retirer [KernelFunction], garder [Description], passer les méthodes par AIFunctionFactory.Create.
5. Basculer les agents. Remplacer la création du Kernel et de l’agent par AsAIAgent(...), les AgentThread par AgentSession, InvokeAsync par RunAsync.
6. Reprendre les filtres. Ce que faisaient les filtres de Semantic Kernel (journalisation, contrôle des appels de fonction, masquage de données) se reporte sur le middleware d’Agent Framework.
7. Rebrancher la recherche. Garder la collection vectorielle, remplacer le branchement par un TextSearchProvider ou un outil de recherche.
8. Comparer. Rejouer le jeu de référence, comparer réponses et appels d’outils, activer la télémétrie OpenTelemetry avant la mise en production.

Pour une application où l’IA est bien isolée, les étapes 4 à 7 tiennent dans un seul lot de travail. Pour une application où elle est dispersée, l’étape 2 est le vrai chantier, et c’est un chantier utile même sans migration.

Pour aller plus loin

Le guide de migration de Microsoft couvre aussi les cas propres à Azure AI Foundry et aux assistants OpenAI hébergés, que ce guide laisse de côté. Si votre application .NET intègre l’IA et que vous voulez savoir ce que la migration représente chez vous, c’est exactement le périmètre de l’intégration IA dans les applications .NET.