Plugins et fonctions Semantic Kernel expliqués pour les développeurs .NET et Python

By Mirko Peters · 2026-10-23

Découvrez comment les plugins et les fonctions de Semantic Kernel relient du code personnalisé aux modèles d’IA en toute sécurité. Maîtrisez les descriptions, OpenAPI, les serveurs MCP et les limites d’outils.

Automatically translated with AI from the original post. Read the English original

Les plugins et les fonctions de Semantic Kernel constituent les briques de base permettant aux modèles de langage d’interagir en toute sécurité avec des logiciels externes. En associant des descriptions en langage naturel à du code personnalisé, les développeurs peuvent permettre aux modèles d’IA de découvrir, de planifier et d’exécuter automatiquement des fonctions d’entreprise, sans coder en dur la logique ni risquer une exposition directe de la base de données.

Points clés

• Les plugins Semantic Kernel regroupent des fonctions apparentées afin d’exposer directement les capacités des logiciels personnalisés aux grands modèles de langage.
• Les descriptions de fonctions sont des instructions essentielles pour l’IA : des descriptions vagues ou mal rédigées amènent le modèle à deviner de façon erronée ou à échouer complètement.
• Les plugins peuvent être écrits nativement en C#, Python ou Java, importés à partir de spécifications OpenAPI, ou intégrés via des serveurs Model Context Protocol (MCP).
• Encapsuler les connexions aux bases de données et les clients web dans les plugins empêche le modèle d’IA d’accéder directement à une infrastructure sensible.
• Respecter les recommandations d’OpenAI, qui consistent à limiter les listes d’outils actifs à dix ou vingt fonctions, préserve une grande précision du modèle lors de l’exécution.

Comprendre les plugins et les fonctions

Lorsque les développeurs commencent à créer des applications qui relient les bases de code logicielles traditionnelles aux grands modèles de langage, ils constatent rapidement que ces modèles excellent dans la génération de texte mais sont totalement incapables d’exécuter seuls des commandes opérationnelles. Un modèle ne peut pas interroger une base de données clients, envoyer un e-mail ou allumer les lumières intelligentes d’un bureau sans une couche intermédiaire. Dans l’architecture de Semantic Kernel, ce pont manquant est construit à l’aide de plugins et de fonctions.

Une fonction est simplement un morceau de code standard, écrit en C#, Python ou Java, qui exécute une tâche précise. Ce qui transforme une fonction ordinaire en outil prêt pour l’IA, c’est sa description en langage naturel. Lorsque votre application enregistre une fonction auprès du noyau, vous associez des métadonnées expliquant ce que fait la fonction, les paramètres qu’elle requiert et les données qu’elle renvoie. Le grand modèle de langage lit ces descriptions à l’exécution pour déterminer quand et comment invoquer votre code.

L’anatomie d’une fonction bien décrite

Les débutants considèrent souvent les descriptions de fonctions comme des commentaires facultatifs ou des détails de documentation secondaires, mais dans l’écosystème Semantic Kernel, la description constitue le prompt. Si la description de votre fonction est vague, ambiguë ou trop technique, le modèle de langage risque de mal interpréter son rôle ou de ne pas l’utiliser du tout.

Rédiger des descriptions efficaces pour l’IA

Pour garantir une grande fiabilité dans les environnements de production, rédigez les descriptions de fonctions comme si vous expliquiez la capacité à un nouveau collègue. Par exemple, plutôt que de décrire un utilitaire de recherche sous la forme get_ord_st() sans aucun contexte, votre plugin doit indiquer explicitement que la fonction récupère le statut de commande d’un client à partir d’un identifiant de commande sous forme de chaîne, et renvoie les détails actuels de traitement. Des entrées claires, des types explicites et des explications fonctionnelles précises éliminent les conjectures du modèle.

Sourcer les plugins : code, OpenAPI et serveurs MCP

Semantic Kernel offre une grande souplesse, car il permet aux développeurs de sourcer les plugins à partir de trois origines distinctes. Comprendre d’où proviennent vos plugins détermine la facilité avec laquelle ils peuvent être mis à l’échelle et partagés entre les équipes d’ingénierie.

Plugins de code natif

La méthode la plus directe consiste à écrire les plugins directement dans la base de code de votre application existante, dans le langage natif utilisé par votre projet. Qu’il s’agisse de développer un backend d’entreprise en C# ou un pipeline de traitement de données en Python, vos méthodes personnalisées s’intègrent sans friction au conteneur du noyau.

OpenAPI et Model Context Protocol (MCP)

Au-delà du code natif, vous pouvez importer des fonctionnalités externes à l’aide de formats web standardisés comme OpenAPI. Par ailleurs, les implémentations modernes s’appuient sur des serveurs Model Context Protocol (MCP). Ces serveurs permettent à une équipe centralisée de créer une fonctionnalité sécurisée une seule fois, puis de la partager entre plusieurs applications et environnements de développement, afin que les créateurs low-code et les ingénieurs logiciels accèdent exactement à la même logique métier.

Bonnes pratiques de sécurité et d’architecture

L’un des avantages architecturaux les plus puissants des plugins Semantic Kernel est l’isolation. Un plugin bien conçu fait office de frontière sécurisée entre le modèle de langage et votre infrastructure d’entreprise. Le plugin encapsule en interne les connexions aux bases de données, les clés d’API et les clients web sensibles. Le modèle d’IA n’interagit jamais avec vos identifiants ni avec les tables de données brutes ; il ne voit que la description en texte brut de la fonction et la sortie assainie renvoyée par la boucle d’exécution.

Gérer les limites d’outils pour une précision optimale

Les développeurs sont tentés de constituer des boîtes à outils massives, comprenant des dizaines, voire des centaines de fonctions, mais les données empiriques d’OpenAI invitent à la prudence. La précision du modèle chute nettement à mesure que la liste des outils disponibles s’allonge. Les bonnes pratiques recommandent de limiter à moins de dix les outils actifs dans une même requête, et d’éviter strictement de dépasser vingt au total. Quelques fonctions peu nombreuses mais très ciblées surpassent systématiquement une bibliothèque encombrée d’utilitaires marginaux.

Conclusion

Maîtriser les plugins et les fonctions de Semantic Kernel est la clé pour transformer des modèles de langage statiques en agents dynamiques capables d’exécuter des flux de travail métier réels. En soignant les descriptions de fonctions, en tirant parti des standards OpenAPI et MCP, et en maintenant des frontières de sécurité strictes, les développeurs peuvent créer des applications d’IA robustes et évolutives, sans exposer d’infrastructure sensible. Pour en savoir plus sur la manière dont le noyau orchestre la mémoire, les connecteurs et la planification, écoutez l’épisode complet du podcast M365 FM, une explication détaillée et accessible de la couche d’orchestration de l’IA de Microsoft.

Questions fréquentes

Qu’est-ce qu’un plugin Semantic Kernel ?

Un plugin Semantic Kernel est un ensemble de fonctions apparentées exposées à un grand modèle de langage, qui permet à l’IA de comprendre et d’invoquer automatiquement une logique logicielle personnalisée.

Pourquoi les descriptions de fonctions sont-elles essentielles dans Semantic Kernel ?

Les descriptions de fonctions servent d’instructions pour le modèle d’IA. Le modèle les lit pour décider quelle fonction appeler : des descriptions imprécises entraînent donc des échecs d’exécution ou des choix erronés.

Les modèles d’IA peuvent-ils accéder directement à ma base de données via les plugins ?

Non. Les plugins encapsulent les détails sensibles, comme les connexions aux bases de données et les identifiants, afin que le modèle d’IA n’interagisse qu’avec des descriptions en texte brut et des sorties de fonctions assainies.

Combien de fonctions faut-il inclure dans une seule requête de plugin ?

Il est recommandé de limiter les outils actifs à moins de dix, avec un maximum strict de vingt, afin d’éviter la dégradation de la précision du modèle causée par une surcharge d’outils.