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

Si vous développez des logiciels sur la pile Microsoft et souhaitez ajouter de l'IA sans greffer un service Python à côté, Semantic Kernel est le SDK que Microsoft a conçu pour vous. C'est un kit open-source qui connecte votre code existant et vos API aux grands modèles de langage, et il fonctionne en C#, Python et Java. Ce guide explique ce qu'il est, comment le noyau et les plugins s'articulent, et comment son support de la spécification OpenAPI transforme toute API REST en quelque chose qu'un modèle peut appeler.

Qu'est-ce que Semantic Kernel, concrètement ?

Le Semantic Kernel (SK) est un kit de développement léger et open-source de Microsoft pour créer des agents IA et intégrer des modèles dans votre codebase. Microsoft le décrit comme un middleware : il se positionne entre votre application et le modèle, traduit les requêtes du modèle en appels de fonctions réels, les exécute et renvoie les résultats. Vous écrivez du code normal. Le modèle décide quand l'appeler.

Trois choses distinguent SK de la multitude de bibliothèques d'agents.

Premièrement, il est véritablement multilingue. SK propose des SDK officiels pour C#/.NET, Python et Java, avec des engagements de stabilité de version 1.0+ pour les trois. La plupart des frameworks d'agents sont "Python-first" et traitent les autres langages comme une réflexion après coup. Si votre backend est en .NET, SK est l'une des rares options matures qui semble native.

Deuxièmement, il est agnostique au modèle. SK se connecte à OpenAI, Azure OpenAI et d'autres fournisseurs via un ensemble de connecteurs. Lorsque vous souhaitez changer de modèle, vous modifiez la configuration, et non l'ensemble de votre application.

Troisièmement, il est conçu avec les préoccupations d'entreprise à l'esprit. La télémétrie, les hooks et les filtres sont de première classe, vous permettant de journaliser, auditer et intercepter ce que l'IA fait. C'est cette approche qui explique pourquoi Microsoft et plusieurs équipes du Fortune 500 l'ont adopté.

Le noyau, les plugins et les fonctions

L'objet central est le noyau (kernel). Pensez-y comme un conteneur d'injection de dépendances pour l'IA. Vous enregistrez vos connecteurs de modèle et vos plugins sur le noyau, puis vous lui demandez d'exécuter des actions. Le noyau gère l'orchestration : prompt, appel de modèle, appel de fonction, résultat, et ainsi de suite.

Un plugin est un groupe nommé de fonctions que vous exposez au modèle. Une fonction est une capacité unique que le modèle peut invoquer. Les fonctions se présentent sous deux formes :

• Les fonctions natives sont des méthodes régulières dans votre code (une méthode C#, une fonction Python) que vous annotez afin que le noyau puisse les décrire au modèle.
• Les fonctions de prompt sont des prompts basés sur des modèles qui appellent le modèle lui-même, utiles pour résumer, classer ou réécrire du texte.

Voici comment cela se présente en C#. Vous construisez un noyau, enregistrez un modèle de chat, ajoutez un plugin et laissez le modèle appeler des fonctions quand il en a besoin.

var builder = Kernel.CreateBuilder();
builder.AddOpenAIChatCompletion("gpt-4o", apiKey);
builder.Plugins.AddFromType<LightsPlugin>("Lights");
Kernel kernel = builder.Build();

// The model can now invoke LightsPlugin functions during a chat
var result = await kernel.InvokePromptAsync("Turn the kitchen light blue");

Lorsque le modèle renvoie un résultat et que le noyau détecte qu'il souhaite appeler `change_light_state`, le noyau exécute votre code, capture le résultat et le transmet au modèle. Cette boucle est le cœur de SK.

Le modèle OpenAPI-vers-plugin

C'est la fonctionnalité la plus importante à connaître, et c'est le pont le plus élégant vers vos services existants. SK peut importer une spécification OpenAPI et transformer automatiquement chaque opération en une fonction appelable. Vous n'écrivez pas de code d'encapsulation. Vous indiquez à SK une spécification, et chaque chemin/opération devient une fonction que le modèle peut invoquer.

En C#, l'appel est `ImportPluginFromOpenApiAsync`. En Python, c'est `add_plugin_from_openapi`. Java dispose d'un importateur équivalent. Voici la version C# chargeant une spécification depuis une URL :

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

En coulisses, SK analyse la spécification, extrait le nom, la description, le type et le schéma de chaque paramètre, et transmet ces métadonnées au modèle. Le modèle détermine quelle opération appeler et quels arguments transmettre. SK construit ensuite la requête HTTP, applique votre rappel d'authentification, l'envoie et lit la réponse. SK prend en charge OpenAPI 2.0 et 3.0, et dégrade les spécifications 3.1 vers 3.0 lorsque cela est possible.

Le problème est que les spécifications écrites pour les humains ne sont pas toujours claires pour un modèle. Les propres conseils de Microsoft sont d'ajouter des ID d'opération descriptifs, d'écrire des descriptions de paramètres utiles, de maintenir le nombre de points de terminaison faible et de préférer les énumérations et les paramètres typés aux chaînes de caractères lâches. La qualité de votre spécification influence directement la manière dont l'agent appelle votre API. Cela fait de la spécification elle-même un élément à concevoir et à tester soigneusement, et non une réflexion après coup.

Agents et planification

SK a commencé avec des planificateurs explicites qui décomposaient un objectif en étapes. Le framework s'est depuis orienté vers l'appel de fonctions, où le modèle lui-même décide quelles fonctions invoquer et dans quel ordre, ce qui est plus fiable avec les modèles modernes. De plus, SK a ajouté une couche Agent Framework pour construire des agents et des modèles multi-agents, avec un état basé sur la session, des boucles agentiques et un support du Protocole de Contexte de Modèle (MCP) pour connecter des outils externes.

Si vous comparez les approches, voici comment SK se positionne par rapport aux autres SDK d'agents présentés sur ce blog.

Aucun de ces éléments n'est strictement meilleur. Le bon choix dépend de votre langage, de votre fournisseur de modèle et du degré de contrôle explicite que vous souhaitez sur l'exécution.

Où Semantic Kernel s'intègre avec le Microsoft Agent Framework

Cette partie évolue rapidement, voici donc l'état actuel des choses. Microsoft a introduit le Microsoft Agent Framework (MAF), et la documentation le décrit comme le successeur direct de Semantic Kernel et d'AutoGen, construits par les mêmes équipes. MAF combine les abstractions d'agents d'AutoGen avec les fonctionnalités d'entreprise de SK et ajoute des workflows basés sur des graphes pour l'orchestration multi-agents.

Ce que cela signifie en pratique :

• Semantic Kernel est stable et toujours supporté. Les applications SK existantes continuent de fonctionner, et l'engagement de compatibilité ascendante 1.0+ est maintenu.
• Pour les tout nouveaux projets d'agents, Microsoft vous oriente vers l'Agent Framework et publie un guide de migration pour le transfert de code SK.
• L'idée OpenAPI-vers-plugin est conservée. Donner à un agent l'accès à vos API REST via une spécification est un modèle partagé par les deux frameworks.

Considérez donc SK comme un choix solide, éprouvé en production et toujours maintenu, tout en sachant que les investissements les plus récents vont vers MAF. Si vous décidez aujourd'hui et que votre code est déjà en SK, il n'y a pas d'urgence. Si vous partez de zéro et que vous voulez la dernière orientation, lisez la documentation de MAF avant de vous engager.

Quand utiliser Semantic Kernel

Optez pour SK lorsque :

• Votre pile technologique est .NET ou Java et vous souhaitez une orchestration IA qui semble native plutôt qu'un "sidecar" Python.
• Vous disposez d'un portefeuille d'API REST existantes et souhaitez qu'un modèle puisse les appeler via leurs spécifications OpenAPI.
• Vous avez besoin d'une infrastructure d'entreprise : télémétrie, filtres, hooks et la capacité d'auditer ce que l'IA a fait.
• Vous souhaitez rester agnostique aux modèles et changer de fournisseurs sans réécrire votre application.

Cherchez ailleurs si votre équipe est uniquement Python et que vous souhaitez les toutes dernières fonctionnalités multi-agents, auquel cas MAF ou une bibliothèque axée sur les graphes pourrait mieux vous convenir.

Tester les API derrière votre agent Semantic Kernel

C'est là que les outils API sont importants, et où Apidog s'intègre parfaitement. SK ne construit ni ne remplace vos API. Il les appelle. Un agent SK dépend de deux types de points de terminaison : le point de terminaison LLM auquel il communique, et les API REST que vous importez comme plugins OpenAPI. Les deux doivent être corrects, bien décrits et fiables, sinon l'agent effectuera de mauvais appels.

Quelques tâches pratiques :

• Concevez et testez la spécification OpenAPI avant de l'importer. Puisque SK transforme chaque opération en une fonction et fournit au modèle vos descriptions de paramètres, une spécification bâclée produit des appels d'outils bâclés. Validez la spécification, testez chaque point de terminaison et confirmez que les réponses correspondent au schéma. Un contrat propre, un meilleur agent.
• Simulez les dépendances pendant le développement. Vous pouvez créer une API simulée pour un point de terminaison qui n'est pas encore construit, ou simuler le point de terminaison LLM pour éviter de gaspiller des jetons et d'atteindre les limites de débit pendant que vous déboguez la boucle d'orchestration. Voir comment simuler des appels API pour le modèle.
• Affirmez les formes de réponse. Utilisez les assertions API pour vérifier que les points de terminaison d'outil appelés par votre agent renvoient exactement la structure attendue par le modèle, afin qu'un changement côté backend ne brise pas silencieusement le comportement de l'agent.
• Gérez les clés par environnement. Séparez vos identifiants LLM et API entre les environnements de développement, de staging et de production plutôt que de les coder en dur.

Il s'agit d'un travail API ordinaire, effectué avant et autour de l'agent, et non à sa place. Si vous souhaitez une explication plus détaillée, tester les appels d'outils d'un agent avec Apidog couvre le harnais en détail.

Questions fréquemment posées

Semantic Kernel est-il gratuit et open source ?

Oui. Semantic Kernel est open-source et publié par Microsoft sur GitHub sous une licence permissive, avec des SDK pour C#/.NET, Python et Java. Vous payez pour l'utilisation du modèle (OpenAI, Azure OpenAI, etc.), et non pour SK lui-même.

Quels langages Semantic Kernel prend-il en charge ?

C#/.NET, Python et Java, tous avec des engagements de stabilité de version 1.0+. Le SDK C# est le plus mature, mais les SDK Python et Java couvrent les fonctionnalités principales du noyau, des plugins et de l'importation OpenAPI.

Comment Semantic Kernel utilise-t-il les spécifications OpenAPI ?

Vous importez une spécification avec `ImportPluginFromOpenApiAsync` (C#) ou `add_plugin_from_openapi` (Python). SK analyse la spécification, transforme chaque opération en une fonction appelable avec ses métadonnées de paramètres, et permet au modèle d'invoquer ces opérations. Étant donné que le modèle s'appuie sur vos descriptions, il est judicieux de valider la spécification au préalable. Vous pouvez le faire, et tester les points de terminaison en direct, avec Apidog.

Dois-je utiliser Semantic Kernel ou le Microsoft Agent Framework ?

Si vous avez déjà une application SK, continuez de l'utiliser ; elle est supportée et stable. Pour les nouveaux projets, Microsoft positionne l'Agent Framework comme le successeur et fournit un guide de migration. Consultez la documentation MAF actuelle avant de commencer un nouveau projet, car ce domaine évolue rapidement. Pour tester les API appelées par l'un ou l'autre, consultez comment tester l'API ChatGPT avec Apidog.

En résumé

Semantic Kernel offre aux équipes travaillant avec la pile Microsoft un moyen propre d'orchestrer l'IA : un noyau qui connecte les modèles à votre code, des plugins et des fonctions que le modèle peut appeler, et un chemin d'importation OpenAPI qui expose vos API REST existantes comme outils d'agent. Il est stable et éprouvé en production, l'Agent Framework portant désormais la nouvelle direction. Quel que soit votre choix, les API sous-jacentes doivent rester solides. Pour concevoir, simuler et tester les spécifications et les points de terminaison dont votre agent dépend, téléchargez Apidog et construisez le contrat avant que l'agent ne l'appelle.