Pourquoi j'ai choisi Semantic Kernel plutôt que Python pour l'IA en .NET
Titulaire du Microsoft Applied Skills AZ-2005, j'ai fait le choix d'intégrer l'IA dans l'existant .NET plutôt que de tout réécrire en Python. Le raisonnement, et le pattern Semantic Kernel.

La majorité des formations et des experts en intelligence artificielle partent de Python. C’est un choix logique : l’écosystème IA (notebooks, bibliothèques, communauté) s’est construit là. Mais après quinze ans à livrer des systèmes d’information en .NET et Angular, dans des contextes aussi différents que la banque privée, l’industrie offshore ou le secteur public, je vois un problème que le réflexe « tout en Python » ne résout pas : le patrimoine applicatif des entreprises n’est pas en Python. Il est en .NET, en Java, en SQL Server, dans des applications métier qui tournent depuis dix ou quinze ans.
Le problème que je vois chez mes clients
Une entreprise qui veut « faire de l’IA » se retrouve devant un choix mal posé : soit elle confie le sujet à des spécialistes Python qui ne connaissent pas son SI existant, soit elle laisse ses équipes .NET improviser sans culture IA. Dans les deux cas, le résultat est le même : un prototype qui reste un prototype, ou une intégration bricolée à côté du système d’information au lieu d’être dedans.
Semantic Kernel : brancher, pas réécrire
C’est pour répondre à ce problème que j’ai obtenu le Microsoft Applied Skills AZ-2005 (« Develop generative AI apps with Azure OpenAI and Semantic Kernel »), une évaluation pratique en laboratoire qui porte sur le développement de solutions d’IA générative avec Azure OpenAI et Semantic Kernel. Ce qui m’intéresse dans Semantic Kernel n’est pas la nouveauté technique : c’est qu’il ne demande pas de réécrire l’existant. Le framework permet de brancher des modèles de langage, du RAG (voir le RAG sur un SI .NET existant) et des agents directement sur une logique métier déjà écrite, testée et auditée en C#.
Concrètement, cela veut dire que les règles métier qui protègent une application (contrôles, validations, workflows) restent en place. L’IA vient s’y ajouter comme une nouvelle capacité, pas comme un chatbot posé à côté du système, déconnecté des règles qui font tenir l’application au quotidien.
Le pattern que j’applique en mission
C’est exactement l’approche de mon offre d’intégration IA dans les applications .NET : extraction documentaire automatisée (c’est le pipeline documentaire IA que j’ai mis en production), boucle de correction qui apprend des erreurs, règles métier configurables sans redéploiement, persistance directe dans les bases existantes. Ce pattern (l’IA propose, une couche déterministe valide, l’humain tranche sur les cas ambigus) est celui qui fait tenir une IA en production sur la durée. Je le détaille dans l’IA propose, le déterministe dispose.
La suite
Cet Applied Skills n’est qu’une étape : la feuille de route continue avec AI-103 (Azure AI Agent Developer). Ce blog documente ces retours d’expérience au fil des missions, avec un seul fil conducteur : l’IA qui crée de la valeur en entreprise est celle qui s’intègre dans l’existant, pas celle qui l’ignore.
Mise à jour du 30 septembre 2026. Microsoft a publié le 3 avril 2026 Agent Framework 1.0, successeur de Semantic Kernel, qui passe en maintenance. Le raisonnement ci-dessus tient : brancher l’IA sur le patrimoine .NET plutôt que le réécrire. Ce qui change dans le code, et quand migrer, est détaillé dans le guide Semantic Kernel ou Microsoft Agent Framework.
Sources et références
- Documentation Semantic Kernel Microsoft