Guide • Développement • Intelligence artificielle

Comment créer un SaaS IA métier : architecture, stack et pièges à éviter

Construire un SaaS qui intègre l’IA comme couche fonctionnelle centrale — pas comme gadget — demande des choix d’architecture spécifiques. Voici ce que nous avons appris en construisant Kaps et Achyl.

Qu’est-ce qu’un SaaS IA métier ?

Un SaaS IA métier n’est pas un outil généraliste avec une case « propulsé par ChatGPT ». C’est un produit logiciel conçu pour un métier précis, où l’IA résout un problème réel de façon structurée et contrôlable.

Les exemples les plus solides partagent trois caractéristiques : un périmètre métier défini (générer un type de document, analyser un type de donnée, assister un type de décision), un pipeline IA maîtrisé (pas un simple appel API), et une validation humaine intégrée dans le produit.

Chez Norolo, nous avons construit deux SaaS IA métier : Kaps (microlearning B2B) et Achyl (documentation clinique pour pédicures-podologues). Voici les enseignements que nous en tirons.

1. Définir le périmètre avant de choisir le modèle

L’erreur la plus fréquente : choisir un LLM, puis chercher un cas d’usage. C’est l’inverse qu’il faut faire. Le métier d’abord, le modèle ensuite.

Pour Achyl, le périmètre était clair dès le départ : générer des documents cliniques structurés (bilan podologique, courrier confraternel, fiche patient) à partir des notes de consultation. Cela a déterminé le choix du modèle (Mistral, via La Plateforme pour le Zero Data Retention), le format de sortie (JSON structuré validé par Zod), et l’architecture du pipeline (3 passes).

Questions à se poser avant de coder :

• Quel problème métier précis l’IA résout-elle ? (pas « améliore la productivité »)
• Quel est le format de sortie attendu ? (texte libre, JSON, PDF, email…)
• Qui valide le résultat avant utilisation ? (humain dans la boucle ou non)
• Quelles contraintes réglementaires s’appliquent ? (HDS, RGPD, MDR, secret professionnel…)

2. Choisir la bonne architecture de pipeline

Un appel API LLM naïf ne suffit pas pour un SaaS métier en production. Selon le niveau de précision requis, trois patterns existent :

Pipeline en une passe

Le plus simple : un prompt → une réponse. Acceptable pour des tâches à faible enjeu (résumé, classification, reformulation). Insuffisant dès que la précision ou la structure de sortie est critique.

Pipeline multi-passes avec validation

C’est le pattern que nous utilisons sur Achyl : trois passes LLM successives avec validation Zod à chaque étape. La première passe extrait les informations brutes, la deuxième structure et complète, la troisième vérifie la cohérence clinique. Chaque passe peut être réessayée indépendamment en cas d’erreur.

RAG (Retrieval-Augmented Generation)

Indispensable quand le modèle a besoin de connaissances spécifiques non présentes dans son entraînement : base documentaire interne, réglementation sectorielle, données propriétaires. Pour Achyl, nous avons construit une base RAG sur les publications podologiques françaises (LiSSa, HAL, HAS, ONPP).

3. Stack technique recommandée en 2025

Après avoir construit plusieurs SaaS IA en production, voici la stack que nous recommandons pour un SaaS B2B français :

4. Les pièges à éviter

• Ne pas valider les sorties LLM. Un LLM peut retourner du JSON mal formé, des champs manquants, ou des valeurs incohérentes. Zod ou un équivalent est non négociable en production.
• Ignorer les contraintes réglementaires. En santé, finance ou RH, elles déterminent l’architecture dès le départ (HDS, RGPD, MDR). Les intégrer en cours de route coûte dix fois plus cher.
• Couplage fort au modèle. Si votre code appelle directement l’API OpenAI partout, migrer vers Mistral ou un autre provider sera douloureux. Abstraire dès le début.
• Sous-estimer le prompt engineering. Un bon pipeline IA passe autant de temps sur les prompts que sur le code. Versionner, tester, évaluer — comme du code.
• Ne pas penser à l’observabilité. Logger les entrées, sorties et erreurs de chaque appel LLM. Sans ça, debugger en production est impossible.

5. Conformité et données sensibles

Si votre SaaS traite des données sensibles (données de santé, données personnelles, données financières), plusieurs points sont non négociables :

• Hébergement HDS certifié pour les données de santé (Scaleway, OVH HDS, Scalingo)
• Zero Data Retention sur l’API LLM : les données envoyées au modèle ne doivent pas être utilisées pour l’entraînement
• DPA (Data Processing Agreement) signé avec chaque sous-traitant IA
• Analyse MDR si le logiciel peut influencer une décision médicale (règlement européen 2017/745)

En résumé

• Définir le problème métier avant de choisir le modèle IA
• Architecturer un pipeline multi-passes avec validation Zod
• Choisir une stack éprouvée : Next.js, TypeScript, Prisma, PostgreSQL, Mistral
• Intégrer les contraintes réglementaires dès la conception
• Logger, tester et versionner les prompts comme du code

Norolo accompagne les entreprises qui veulent construire ce type de produit. Nos réalisations (Kaps, Achyl) sont des exemples concrets de ce que nous délivrons.