Intégrer la GenAI dans un SaaS .NET : coûts réels, délais, pièges

La question qu'on me pose vraiment

Quand un CTO ou un fondateur me contacte pour « mettre de l'IA » dans son produit, la question derrière la question est presque toujours la même : combien ça coûte, combien de temps ça prend, et qu'est-ce qui peut mal tourner ?

Cet article répond aux trois, sans détour. Il s'appuie sur ce que j'ai construit et opéré : un Privacy Shield qui masque les PII avant tout appel LLM (PromptVault), un pipeline de scoring CV plafonné en coût par candidat (Matchr), un moteur de citation « cité ou rejeté » anti-hallucination (Vouch), et du forecasting où le LLM a perdu face à ML.NET (SaleCast).

Les trois postes de coût — dont deux invisibles au POC

1. Le développement (celui qu'on voit)

Appeler un LLM, c'est trois lignes de code. Ce qui prend du temps, c'est tout ce qui rend l'appel digne d'une production :

• le prompt et son contexte : assembler les bonnes données métier, dans la bonne fenêtre, sans y glisser ce qui ne doit pas sortir de chez vous ;
• la sortie structurée : un LLM renvoie du texte ; votre produit a besoin d'objets typés, validés, avec un comportement défini quand le modèle répond à côté ;
• les fallbacks : timeout, rate-limit du provider, réponse invalide — chaque chemin d'échec doit avoir une réponse produit, pas une stack trace ;
• l'abstraction provider : pouvoir basculer OpenAI → Claude → Azure OpenAI sans réécrire la feature. En .NET, Microsoft.Extensions.AI rend ça propre — c'est l'équivalent de ILogger pour les LLM.

2. Les tokens (celui qu'on sous-estime)

Le coût unitaire d'un appel paraît dérisoire. Multiplié par vos utilisateurs, par requête, par jour, il devient une ligne de COGS qui bouge avec votre usage — et que personne ne plafonne au moment du POC.

Sur Matchr, chaque analyse de CV a un coût plafonné par construction : modèle dimensionné à la tâche, contexte tronqué à ce qui sert le scoring, cache sur les invariants. Ce n'est pas de l'optimisation prématurée : c'est ce qui permet d'afficher un prix par candidat sans découvrir sa marge a posteriori.

Deux règles qui tiennent :

• le modèle le plus cher n'est presque jamais nécessaire partout — on route les tâches simples (classification, extraction) vers un modèle rapide et on réserve le gros modèle aux étapes qui créent la valeur ;
• chaque feature IA doit avoir un budget tokens par opération, mesuré et alerté — sinon vous découvrez le dépassement sur la facture, six semaines plus tard.

3. L'évaluation continue (celui qu'on découvre trop tard)

C'est le poste le plus négligé. Un prompt n'est pas du code : il n'y a ni compilateur ni typage pour vous dire qu'une modification a cassé un cas. Sans jeu d'évaluation (des entrées réelles, des sorties attendues, un score), chaque amélioration de prompt est une régression potentielle invisible.

Concrètement, il vous faut dès la mise en production :

• un jeu d'évals versionné avec le code, rejoué à chaque changement de prompt ou de modèle ;
• un suivi de drift : les providers mettent à jour leurs modèles, et une mise à jour silencieuse peut dégrader vos sorties sans qu'aucune ligne de votre code n'ait changé ;
• des garde-fous applicatifs : sur Vouch, chaque affirmation générée doit citer sa source documentaire, sinon elle est rejetée — le modèle n'a pas le droit d'improviser dans un contexte d'audit de conformité.

Build vs API : la vraie question n'est pas celle-là

« On utilise une API ou on héberge notre modèle ? » est rarement la bonne première question. Pour l'écrasante majorité des SaaS, la réponse est API d'un provider (directement ou via Azure) — l'auto-hébergement ne se justifie que sur des contraintes fortes de souveraineté ou un volume qui change l'ordre de grandeur de la facture.

Les vraies questions de cadrage sont :

1. Quelles données partent chez le provider, et sous quelle forme ? Si vos prompts contiennent des données personnelles, vous avez un sujet RGPD avant d'avoir un sujet IA. C'est exactement ce que résout un masquage PII avant l'appel — réversible au retour, pour que l'utilisateur voie la vraie donnée mais pas le modèle.
2. Le LLM est-il le bon outil ? Sur SaleCast, j'ai fait concourir neuf algorithmes sur du forecasting e-commerce : le ML classique (ML.NET) bat le LLM sur cette tâche, pour une fraction du coût d'inférence. Un LLM n'est pas un réflexe, c'est un choix qui se justifie tâche par tâche.
3. Que se passe-t-il quand le modèle se trompe ? Pas « si » — « quand ». La réponse définit votre niveau d'exigence sur les garde-fous, et donc une part significative du budget.

Les délais réalistes

Ordres de grandeur constatés sur mes projets, pour une équipe .NET existante :

• POC honnête : ~2 semaines. « Honnête » = sur vos données réelles, avec les cas moches, et un mini-jeu d'évals. Un POC sur trois exemples choisis ne prouve rien — il ne sert qu'à obtenir le budget du vrai POC.
• Feature en production : 6 à 10 semaines. Le delta entre les deux, c'est tout ce que cet article décrit : sorties structurées, fallbacks, plafonds de coût, évals, monitoring, et l'intégration propre dans votre existant.
• Industrialisation (plusieurs features IA) : c'est une plateforme. Abstraction provider, observabilité des prompts, gestion centralisée des budgets — mutualisée une fois, amortie sur chaque feature suivante.

Les cinq pièges qui coûtent le plus cher

1. La démo pilote la roadmap. Une démo LLM est toujours spectaculaire. Décider sur la démo plutôt que sur un jeu d'évals, c'est acheter le sommet de la courbe d'enthousiasme.
2. Aucun plafond de coût par opération. Le COGS découvert sur facture, après le lancement, quand le prix public est déjà annoncé.
3. Les PII partent dans les prompts. Le sujet n'apparaît dans aucune démo et ressort au premier audit — ou au premier incident. Masquage avant l'appel, journalisation de ce qui sort, point.
4. Pas de stratégie de sortie provider. Les prix et les modèles bougent vite. Sans couche d'abstraction, chaque évolution du marché est un chantier au lieu d'un changement de configuration.
5. L'IA plaquée là où une règle suffit. Si la tâche est déterministe, un LLM ajoute du coût, de la latence et de l'incertitude. La moitié de la valeur d'un audit de cadrage, c'est la liste de ce qui n'a pas besoin d'IA.

Quand je réponds « pas d'IA ici »

Trois cas où je le dis explicitement en cadrage :

• la tâche est déterministe — une règle métier fait mieux, pour rien ;
• le coût d'une erreur est inacceptable et inverifiable — si aucun garde-fou ne permet de valider la sortie, le LLM n'a pas sa place sur ce chemin critique ;
• le volume rend l'inférence absurde — du ML classique entraîné sur vos données fait le travail à coût marginal quasi nul.

Dire non à l'IA sur un périmètre, c'est souvent ce qui rend crédible le oui sur le reste.

Ce qu'il faut retenir

• Budgétez trois postes : développement, tokens, évaluation continue. Le POC ne montre que le premier.
• Exigez un POC sur vos données réelles avec un jeu d'évals — 2 semaines bien cadrées valent mieux qu'une démo parfaite.
• Plafonnez le coût par opération avant le lancement, pas après la première facture.
• Traitez les PII avant l'appel LLM, pas dans un ticket post-incident.
• Et acceptez qu'une partie du périmètre n'ait pas besoin d'IA — c'est un signe de cadrage sain, pas un échec.

Si vous avez un sujet GenAI dans une stack .NET et que vous voulez un avis franc sur ce qui en vaut la peine — le premier échange est gratuit.