Quand un SaaS doit-il utiliser l’IA ? Et quand il ne doit surtout pas

Trois de mes produits sont, au fond, des moteurs de décision : Atamatax mappe une situation fiscale vers des formulaires, Horvera décide si un vol donne droit à une indemnisation, Wabiro transforme des réponses en score. Aucun des trois n’utilise un modèle de langage pour rendre la décision. Ce n’est pas de la méfiance envers l’IA ; c’est la conséquence d’une question que je pose avant chaque fonctionnalité.

La question n’est pas « peut-on » mais « que se passe-t-il quand c’est faux »

Un modèle de langage peut à peu près tout faire de manière plausible. La question utile est celle du coût de l’erreur. Si une sortie fausse est rattrapée par un humain, corrigée en un clic, ou sans conséquence — l’IA a sa place. Si une sortie fausse envoie une réclamation erronée à une compagnie aérienne, déclare un fonds comme non-PFIC alors qu’il l’est, ou facture le mauvais montant — elle n’en a pas, quelle que soit sa précision moyenne.

Cette question en entraîne une deuxième : pouvez-vous mesurer ? Sans une cinquantaine d’exemples réels avec la bonne réponse connue, vous ne saurez jamais si le système fonctionne, ni s’il a régressé après un changement de modèle. Un projet IA sans jeu d’évaluation est un projet où personne ne sait si ça marche.

Trois cas où l’IA a sa place

L’extraction structurée. Transformer un PDF, un email, un relevé ou une facture en champs typés est le cas le plus rentable que je connaisse : des semaines de règles manuelles remplacées par un appel avec un schéma de sortie imposé, une confiance par champ et une relecture humaine quand la confiance est basse. Le résultat alimente ensuite le reste du système comme n’importe quelle donnée validée.

La classification et le routage. Trier des demandes, des tickets, des documents ou des réponses vers la bonne file. Le modèle propose ; une règle déterministe tranche les cas sensibles ; un humain reprend ce que le modèle marque comme incertain. Lire la réponse d’une compagnie aérienne et la classer — accepte, refuse, demande des pièces — est exactement ce type de tâche : l’IA prépare, la règle décide de l’étape suivante.

La génération structurée. Produire un courrier, un résumé ou un rapport à partir de données déjà validées, avec un gabarit, des contraintes et une sortie JSON — pas un texte libre. La lettre de réclamation d’Horvera est générée à partir des faits du dossier ; ce qui compte est que les faits viennent du moteur, pas du modèle.

Trois cas où elle n’en a pas

La décision qui doit être justifiable. Éligibilité, calcul d’impôt, montant, conformité : la réponse doit être reproductible, traçable, et identique demain pour les mêmes faits. Le moteur d’Horvera produit chaque réponse avec ses identifiants de règles et ses sources ; celui d’Atamatax affiche ses hypothèses et son niveau de confiance. Un modèle probabiliste ne peut pas tenir ce contrat. Il peut préparer les faits ; il ne rend pas le verdict.

Ce qu’une requête fait déjà. « Combien de clients ont payé ce mois-ci » est une requête SQL. Ajouter un modèle pour y répondre ajoute du coût, de la latence et une source d’erreur, sans rien apporter. Une part surprenante des demandes « d’IA » sont des demandes de meilleure base de données.

Ce qu’on ne peut pas évaluer. Sans exemples réels, sans moyen de savoir si la sortie est bonne, on ne construit pas. On collecte d’abord — parfois avec une version manuelle du processus — et on revient quand il y a de quoi mesurer.

Quand ne pas utiliser le RAG

La recherche augmentée — découper des documents, les vectoriser, retrouver les passages pertinents et laisser le modèle répondre en citant — est devenue la réponse par défaut à « nos données dans un chatbot ». Elle est utile quand le corpus est vaste, change souvent, et que la question est ouverte. Elle est superflue dans trois cas fréquents.

• Quand les données sont structurées. Si l’information vit dans des tables, une requête est plus précise, moins chère et vérifiable. Un bon schéma rend le RAG inutile plus souvent qu’on ne le croit.
• Quand le corpus tient dans le contexte. Un modèle actuel lit des centaines de pages en un appel ; pour un corpus modeste et stable, passer les documents directement bat une infrastructure de recherche.
• Quand les documents se contredisent. Sans gouvernance des versions, le RAG retrouve la bonne réponse et l’ancienne, et le modèle choisit. Le problème est éditorial avant d’être technique.

Quand le RAG est justifié, il vit dans Postgres avec pgvector, en recherche hybride, avec des citations vérifiables — pas dans un service de plus.

Le contrat de sortie : ce que l’IA doit respecter pour entrer dans un moteur

Ce qui rend un moteur déterministe fiable est son contrat de sortie : une structure fixe, une confiance, des hypothèses nommées, une trace. Quand une étape IA s’insère dans ce moteur, elle respecte le même contrat. Chaque appel est une fonction typée — entrée validée, prompt versionné, schéma de sortie validé avec Zod, modèle remplaçable par configuration, fallback si le fournisseur tombe. Le reste de l’application ne voit jamais de texte libre.

L’évaluation vient avec la fonctionnalité : un jeu d’exemples, un score, une exécution à chaque changement. Chaque correction humaine en production rejoint le jeu. L’observabilité couvre chaque appel — entrée, sortie, modèle, tokens, coût, version du prompt — et les budgets sont explicites, par utilisateur et par jour, avec une dégradation prévue plutôt qu’une facture surprise.

Décider en vingt minutes

• Que se passe-t-il aujourd’hui quand cette tâche est mal faite ? Si la réponse est « on perd un client » ou « on viole une règle », la décision reste déterministe.
• Existe-t-il cinquante exemples réels avec la bonne réponse ? Sinon, collectez d’abord.
• La réponse est-elle déjà une requête ? Alors c’est une requête.
• Un humain peut-il relire avant l’effet ? Si oui, l’IA peut préparer ; si non, elle ne peut pas décider.
• Quelles données partent, où, et sous quel contrat ? À régler avant la première ligne de code.

En une ligne

L’IA remplace le travail humain répétitif sur du texte et des documents quand l’erreur est rattrapable et mesurable ; elle ne remplace pas une règle qui doit être justifiable ni une requête qui existe déjà. Le déterministe entoure le probabiliste. C’est ainsi que j’intègre l’IA dans un produit en production.