Qu'est-ce que Semantic Kernel ? Le SDK de Microsoft pour l'orchestration d'IA

Si vous développez sur la pile Microsoft et voulez intégrer de l’IA sans ajouter un service Python séparé, Semantic Kernel est une option à considérer. Ce SDK open source connecte votre code, vos API et vos modèles de langage en C#, Python ou Java. Dans ce guide, vous allez voir comment structurer un noyau, exposer des fonctions sous forme de plugins et transformer une spécification OpenAPI en outils appelables par un modèle.

Essayez Apidog aujourd’hui

Qu’est-ce que Semantic Kernel ?

Semantic Kernel est un SDK léger et open source de Microsoft pour intégrer des modèles d’IA dans une application existante.

Son rôle est celui d’un middleware :

1. votre application enregistre des modèles, plugins et fonctions ;
2. le modèle reçoit une demande utilisateur ;
3. Semantic Kernel décide, avec le modèle, quelles fonctions appeler ;
4. votre code ou vos API sont exécutés ;
5. le résultat est renvoyé au modèle pour produire la réponse finale.

Vous écrivez donc du code applicatif classique. Semantic Kernel s’occupe de l’exposer au modèle sous une forme exploitable.

Semantic Kernel se distingue surtout par trois points :

• Support multi-langage : SDK officiels pour C#/.NET, Python et Java.
• Agnosticisme modèle : connexion possible à OpenAI, Azure OpenAI et d’autres fournisseurs via des connecteurs.
• Fonctionnalités orientées entreprise : télémétrie, filtres, hooks et points d’interception pour auditer les appels IA.

Si votre backend est déjà en .NET ou Java, SK évite souvent d’introduire une pile Python uniquement pour orchestrer des agents.

Le modèle mental : kernel, plugins et fonctions

L’objet central est le kernel. Vous pouvez le voir comme un conteneur d’orchestration pour l’IA.

Il contient :

• les connecteurs vers les modèles ;
• les plugins exposés au modèle ;
• la logique d’appel de fonctions ;
• les hooks, filtres et paramètres d’exécution.

Un plugin est un groupe nommé de fonctions. Une fonction est une capacité que le modèle peut appeler.

Semantic Kernel prend en charge deux types de fonctions :

• Fonctions natives : méthodes C#, fonctions Python ou méthodes Java exposées au modèle.
• Fonctions de prompt : prompts paramétrés utilisés pour résumer, classer, transformer ou réécrire du texte.

Exemple minimal en C# :

var builder = Kernel.CreateBuilder();

builder.AddOpenAIChatCompletion(
    modelId: "gpt-4o",
    apiKey: apiKey
);

builder.Plugins.AddFromType<LightsPlugin>("Lights");

Kernel kernel = builder.Build();

var result = await kernel.InvokePromptAsync(
    "Turn the kitchen light blue"
);

Dans cet exemple :

1. le kernel est créé ;
2. un modèle de chat est enregistré ;
3. un plugin Lights est ajouté ;
4. le modèle peut appeler les fonctions de ce plugin pendant l’exécution.

Un plugin natif peut ressembler à ceci :

public class LightsPlugin
{
    [KernelFunction("change_light_state")]
    [Description("Change the color and power state of a light")]
    public string ChangeLightState(
        [Description("The room where the light is located")] string room,
        [Description("The target color")] string color,
        [Description("Whether the light should be on")] bool isOn
    )
    {
        return $"Light in {room} set to {color}, power: {isOn}";
    }
}

Les descriptions sont importantes : elles aident le modèle à choisir la bonne fonction et les bons arguments.

Transformer une API OpenAPI en plugin Semantic Kernel

La fonctionnalité la plus pratique de SK pour les applications existantes est l’import OpenAPI.

Au lieu d’écrire manuellement un wrapper pour chaque endpoint REST, vous pouvez importer une spécification OpenAPI. Semantic Kernel transforme alors les opérations en fonctions appelables par le modèle.

En C#, utilisez ImportPluginFromOpenApiAsync :

await kernel.ImportPluginFromOpenApiAsync(
    pluginName: "lights",
    uri: new Uri("https://example.com/v1/swagger.json"),
    executionParameters: new OpenApiFunctionExecutionParameters
    {
        EnablePayloadNamespacing = true
    }
);

Le flux est le suivant :

1. SK lit la spécification OpenAPI.
2. Il extrait les chemins, opérations, paramètres, descriptions et schémas.
3. Chaque opération devient une fonction.
4. Le modèle choisit l’opération pertinente.
5. SK construit et envoie la requête HTTP.
6. La réponse est renvoyée au modèle.

En Python, le même modèle existe avec add_plugin_from_openapi.

await kernel.add_plugin_from_openapi(
    plugin_name="lights",
    openapi_document_path="https://example.com/v1/swagger.json"
)

Semantic Kernel prend en charge OpenAPI 2.0 et 3.0, et peut dégrader certaines spécifications 3.1 vers 3.0 lorsque c’est possible.

Préparer une spécification OpenAPI exploitable par un modèle

Une spécification OpenAPI lisible par un humain n’est pas toujours suffisante pour un modèle. Si les noms d’opérations sont vagues ou si les paramètres sont mal décrits, l’agent risque d’appeler le mauvais endpoint ou de générer de mauvais arguments.

Avant d’importer votre API dans Semantic Kernel, vérifiez ces points :

• utilisez des operationId explicites ;
• ajoutez des descriptions utiles aux paramètres ;
• évitez les noms génériques comme getData ou process;
• préférez les types stricts aux chaînes libres ;
• utilisez des énumérations quand les valeurs possibles sont connues ;
• limitez le nombre d’endpoints exposés à l’agent ;
• testez les réponses réelles par rapport au schéma.

Exemple d’opération plus exploitable :

paths:
  /lights/{room}/state:
    post:
      operationId: changeLightState
      summary: Change the state and color of a room light
      parameters:
        - name: room
          in: path
          required: true
          schema:
            type: string
          description: Room name, for example kitchen, bedroom, or office
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              required:
                - color
                - isOn
              properties:
                color:
                  type: string
                  enum: [red, blue, green, white]
                  description: Target light color
                isOn:
                  type: boolean
                  description: Whether the light should be turned on

Une bonne spécification devient un contrat d’exécution pour votre agent.

Agents et planification dans Semantic Kernel

Semantic Kernel a d’abord proposé des planificateurs explicites capables de décomposer un objectif en étapes. Avec les modèles modernes, l’approche recommandée s’oriente davantage vers l’appel de fonctions : le modèle décide quelles fonctions invoquer et dans quel ordre.

SK fournit aussi une couche Agent Framework pour construire des agents avec :

• état de session ;
• boucles agentiques ;
• modèles multi-agents ;
• support du Model Context Protocol, ou MCP, pour connecter des outils externes.

Si vous comparez SK à d’autres frameworks d’agents, voici le positionnement général :

Framework	Langages principaux	Modèle d’orchestration	Meilleure adéquation
Semantic Kernel	C#/.NET, Python, Java	Appel de fonctions + agents	Équipes .NET et entreprises
LangGraph	Python, JS	Graphe d’état explicite	Flux d’agents complexes et ramifiés
Google ADK	Python	Modèle agent + outil	Piles Google Cloud et Gemini
OpenAI Agents SDK	Python, JS	Agents + transferts	Applications centrées sur OpenAI

Le bon choix dépend surtout de votre pile, de votre fournisseur de modèle et du niveau de contrôle souhaité sur l’orchestration.

Semantic Kernel et Microsoft Agent Framework

Microsoft a introduit le Microsoft Agent Framework, ou MAF, décrit comme le successeur de Semantic Kernel et d’AutoGen. Il combine les abstractions d’agents d’AutoGen avec certaines capacités d’entreprise de SK, et ajoute des workflows basés sur des graphes pour l’orchestration multi-agents.

En pratique :

• les applications Semantic Kernel existantes restent supportées ;
• l’engagement de compatibilité 1.0+ reste important pour les SDK ;
• Microsoft oriente les nouveaux projets d’agents vers l’Agent Framework ;
• le modèle OpenAPI-vers-outil reste pertinent dans les deux approches.

Si vous avez déjà une application en SK, il n’y a pas d’urgence à migrer. Si vous démarrez un nouveau projet agentique, consultez aussi la documentation MAF avant de choisir votre socle.

Quand utiliser Semantic Kernel ?

Utilisez Semantic Kernel si :

• votre application est principalement en .NET ou Java ;
• vous voulez éviter un service Python séparé pour l’orchestration IA ;
• vous avez déjà des API REST documentées avec OpenAPI ;
• vous voulez exposer ces API comme outils d’agent ;
• vous avez besoin de télémétrie, hooks, filtres et audit ;
• vous souhaitez pouvoir changer de fournisseur de modèle sans réécrire toute l’application.

Cherchez une autre option si :

• votre équipe travaille uniquement en Python ;
• vous voulez un graphe d’orchestration très explicite ;
• vous démarrez un nouveau projet multi-agent et souhaitez suivre la dernière direction Microsoft avec MAF.

Tester les API derrière un agent Semantic Kernel

Semantic Kernel n’améliore pas automatiquement la qualité de vos API. Il les appelle. Si vos endpoints sont instables, mal décrits ou incohérents avec leur schéma, l’agent produira des résultats imprévisibles.

C’est ici qu’un outil comme Apidog devient utile dans le workflow.

Avant d’exposer une API à Semantic Kernel, mettez en place une checklist simple.

1. Valider la spécification OpenAPI

Vérifiez que :

• la spécification est valide ;
• chaque endpoint a un operationId clair ;
• les paramètres sont typés ;
• les réponses documentées correspondent aux réponses réelles ;
• les erreurs sont décrites.

SK utilise directement ces métadonnées pour présenter les outils au modèle. Une spécification faible produit des appels faibles.

2. Tester chaque endpoint comme un contrat

Pour chaque opération importée comme fonction :

• envoyez des requêtes nominales ;
• testez les cas d’erreur ;
• vérifiez les codes HTTP ;
• validez le corps de réponse ;
• comparez la réponse au schéma OpenAPI.

Vous pouvez utiliser les assertions API pour détecter les changements qui casseraient silencieusement le comportement de l’agent.

3. Simuler les dépendances

Pendant le développement, vous pouvez simuler :

• une API REST pas encore disponible ;
• un endpoint instable ;
• une réponse de modèle ;
• un cas d’erreur difficile à reproduire.

Créer une API simulée permet de développer l’orchestration sans attendre tous les services backend. Vous pouvez aussi consulter ce guide sur la simulation d’appels API.

4. Séparer les environnements

Ne codez pas vos clés en dur.

Préparez au minimum :

• un environnement local ;
• un environnement de staging ;
• un environnement de production.

Séparez les clés LLM et les clés API par environnement. Cela facilite les tests, limite les risques et évite d’utiliser accidentellement des ressources de production pendant le développement.

5. Tester les appels d’outils de bout en bout

Un test utile consiste à vérifier toute la chaîne :

1. prompt utilisateur ;
2. sélection de fonction par le modèle ;
3. appel HTTP généré par SK ;
4. réponse API ;
5. réponse finale du modèle.

Pour aller plus loin, ce guide explique comment tester les appels d’outils d’un agent avec Apidog.

Questions fréquentes

Semantic Kernel est-il gratuit et open source ?

Oui. Semantic Kernel est open source et publié par Microsoft sur GitHub sous une licence permissive. Vous payez l’utilisation du modèle, par exemple OpenAI ou Azure OpenAI, mais pas Semantic Kernel lui-même.

Quels langages Semantic Kernel prend-il en charge ?

Semantic Kernel prend en charge C#/.NET, Python et Java. Le SDK C# est le plus mature, mais les SDK Python et Java couvrent les fonctionnalités principales : kernel, plugins, fonctions et import OpenAPI.

Comment Semantic Kernel utilise-t-il OpenAPI ?

Vous importez une spécification avec ImportPluginFromOpenApiAsync en C# ou add_plugin_from_openapi en Python. Semantic Kernel analyse les opérations et les expose comme fonctions appelables par le modèle. Comme le modèle s’appuie sur les noms, descriptions et schémas, il est recommandé de valider et tester la spécification avant l’import. Vous pouvez le faire avec Apidog.

Dois-je utiliser Semantic Kernel ou Microsoft Agent Framework ?

Si vous avez déjà une application Semantic Kernel, continuez à l’utiliser : elle reste supportée. Pour un nouveau projet, Microsoft positionne l’Agent Framework comme la direction la plus récente. Consultez la documentation actuelle avant de choisir. Dans les deux cas, testez les API que vos agents appellent. Vous pouvez par exemple suivre ce guide pour tester l’API ChatGPT avec Apidog.

En résumé

Semantic Kernel fournit une façon pratique d’intégrer l’IA dans une application Microsoft ou enterprise : un kernel pour orchestrer, des plugins pour exposer des capacités, des fonctions pour appeler votre code, et un import OpenAPI pour transformer vos API REST en outils d’agent.

La partie critique reste votre contrat API. Plus vos spécifications, endpoints et réponses sont propres, plus l’agent peut appeler les bons outils avec les bons arguments. Pour concevoir, simuler et tester les API utilisées par vos agents, vous pouvez télécharger Apidog et valider le contrat avant de l’exposer au modèle.