Semantic Kernel a fourni à de nombreuses équipes une couche d’orchestration entre leurs applications et les modèles de langage. Son Kernel centralise les connecteurs de modèles, les plugins, les fonctions et les services transverses. Le projet reste disponible et continue de recevoir des versions, mais Microsoft présente désormais Microsoft Agent Framework comme son successeur pour les nouveaux développements.
Ce qui reste utile dans Semantic Kernel
Une application existante peut rester parfaitement exploitable si elle est stable, testée et alignée sur une version supportée. Semantic Kernel conserve un écosystème riche en Python, .NET et Java, ainsi que des connecteurs vers différents modèles et magasins vectoriels.
Le conserver évite une migration sans bénéfice immédiat. Figez alors les dépendances, surveillez les correctifs de sécurité et documentez les composants expérimentaux. Les tests doivent couvrir les appels de plugins, la sérialisation des messages et le comportement face aux erreurs des fournisseurs.
Pourquoi Agent Framework change la décision
Microsoft Agent Framework reprend les apprentissages de Semantic Kernel et d’AutoGen dans une API unifiée pour les agents et workflows. Microsoft annonce des API stables et un support à long terme. Pour un nouveau projet, il réduit donc le risque de devoir changer rapidement de socle.
Le nouveau framework simplifie la création des agents, sépare les fournisseurs en paquets dédiés et utilise des sessions explicites. Il ajoute aussi une orchestration de workflows, du middleware et des intégrations modernes comme MCP et A2A.
Choisir selon le contexte
Conservez Semantic Kernel lorsque l’application produit déjà de la valeur et qu’aucune limitation concrète ne justifie le chantier. Préparez néanmoins un inventaire des agents, fonctions, connecteurs, états et dépendances afin d’évaluer la migration.
Pour un nouveau produit, commencez avec Microsoft Agent Framework sauf contrainte particulière non couverte. Pour un prototype lié à un composant historique de Semantic Kernel, isolez cette dépendance derrière votre propre interface.
La bonne décision n’est pas dictée uniquement par le nom du framework. Comparez la maturité des fonctions dont vous avez réellement besoin, la qualité des traces, le coût d’exploitation et la capacité de retour arrière. Une migration progressive fondée sur des tests apporte plus de sécurité qu’une réécriture globale.