Faire de la GenAI en .NET pur : pourquoi je n'ai pas de stack Python à côté

Le réflexe par défaut — et pourquoi il mérite d'être questionné

"Vous faites de la GenAI ? Donc vous avez un service Python qui tourne à côté de votre app ?"

C'est la question qu'on me pose presque systématiquement. Et la réponse, sur la plupart de mes produits, est non. Le RAG, les embeddings, le scoring, les garde-fous anti-hallucination tournent en C#/.NET pur, dans le même processus que le reste de l'application.

Ce n'est pas du dogmatisme « .NET partout ». C'est un choix d'architecture qui a des raisons précises — et une exception que j'assume.

Ce que coûte vraiment « le Python à côté »

Ajouter un micro-service Python n'est pas gratuit. C'est une deuxième stack complète à porter :

• un autre runtime à déployer, mettre à jour, sécuriser (CVE, dépendances) ;
• une frontière réseau de plus entre votre métier et votre IA — latence, sérialisation, gestion d'erreur, retries ;
• une autre culture d'observabilité, de tests, de CI ;
• et, pour une DSI, deux compétences à recruter et maintenir au lieu d'une.

Pour une boîte dont tout le SI est déjà en .NET, ce sidecar Python est souvent le point le plus fragile et le plus coûteux de l'architecture — alors qu'il n'a parfois aucune justification technique réelle.

Pourquoi .NET suffit pour le cœur GenAI

L'argument « il faut Python pour l'IA » datait d'une époque où l'écosystème .NET n'avait pas les briques. Ce n'est plus le cas :

• Microsoft.Extensions.AI : une abstraction unifiée sur les fournisseurs (OpenAI, Anthropic…), avec gestion native du streaming et des tool-calls.
• pgvector + EF Core : le RAG (recherche sémantique sur vos documents) se fait dans PostgreSQL, là où vivent déjà vos données — pas dans une base vectorielle exotique de plus.
• ML.NET + ONNX Runtime : pour le scoring et les modèles classiques, on charge un modèle ONNX et on l'exécute en .NET, sans process externe.

Sur Vouch, c'est exactement ça : un RAG enterprise-grade (parsing PDF/DOCX, découpage, embeddings, génération avec citation obligatoire) 100 % .NET, où l'invariant « cité ou rejeté » vit dans la couche métier en C# pur — sans aucune dépendance externe. La couche Domain compile dans une console nue. C'est précisément ce qui rend la garantie impossible à contourner.

Sur PromptVault, le masquage des données personnelles (PII) avant envoi au LLM est une couche transverse côté client — encore une fois, pas un service Python à part, mais une brique intégrée au produit.

La seule exception : les foundation models

Je ne vends pas un absolu. Il y a un endroit où je sors du .NET pur, et c'est assumé : les modèles de fondation spécialisés.

Sur SaleCast, le module de prévision fait concourir 12 algorithmes par produit. Les modèles statistiques et ML classiques tournent en .NET (ML.NET, ONNX). Mais pour les foundation models de séries temporelles (Chronos, TiRex, AutoGluon), l'écosystème de référence est en Python — et le réimplémenter en .NET serait de l'orgueil, pas de l'ingénierie.

Là, j'assume un sidecar Python en HTTP, isolé, avec une frontière claire. La règle que je me donne :

Le cœur du produit (métier, garde-fous, orchestration, RAG) reste en .NET. Python n'entre que pour un modèle précis que son écosystème seul fournit — jamais pour de la logique métier.

C'est la différence entre « tout-Python parce que c'est le réflexe » et « .NET par défaut, Python en outil ciblé ». La première fragilise la prod ; la seconde met chaque techno là où elle est la meilleure.

Pourquoi ça compte pour vous

Si vos équipes sont en .NET et qu'on vous a dit que « faire de l'IA » imposait d'ouvrir un chantier Python parallèle, c'est faux dans la majorité des cas. Le RAG, les garde-fous, le scoring et l'orchestration GenAI peuvent vivre dans votre stack actuelle — testés, sécurisés et déployés comme le reste.

Moins de surface, moins de fragilité, une seule plateforme à opérer. C'est exactement le type de garantie qu'un DSI cherche — et le genre d'architecture GenAI que je livre.