Quand un SaaS doit-il utiliser l’IA ?

Quand une tâche est faite aujourd’hui à la main sur du texte ou des documents, que l’erreur est rattrapable ou relisible, et qu’il existe des exemples réels pour évaluer. Pas quand la réponse est déjà une requête de base de données, ni quand la décision doit être justifiable ligne par ligne.

Quand faut-il utiliser le RAG — et quand non ?

Le RAG est utile quand la réponse dépend d’un corpus de documents qui change et qu’il faut citer. Il est inutile quand les données sont structurées et qu’une requête suffit, et dangereux quand les documents contiennent des versions contradictoires sans gouvernance. Souvent, un bon schéma de données rend le RAG superflu.

Comment garantir qu’une sortie d’IA est correcte ?

On ne garantit pas ; on mesure et on encadre. Sortie structurée validée par schéma, règles déterministes pour les cas sensibles, jeu d’évaluation exécuté à chaque changement, relecture humaine sur les faibles confiances, et journal de chaque appel pour comprendre les erreurs.

Combien coûte une fonctionnalité IA ?

Deux coûts distincts. Le développement : une fonctionnalité d’extraction ou de classification bien encadrée tient dans un forfait de v1 ou un sprint dédié de 2 à 4 semaines. L’exploitation : de quelques centimes à quelques francs par document selon le modèle, plafonnés par des budgets explicites. Les deux sont chiffrés avant de commencer.

Mes données sont-elles envoyées à OpenAI ou Anthropic ?

Seulement ce qui est nécessaire, vers le fournisseur choisi pour la tâche, sous un contrat qui exclut l’entraînement sur vos données, avec la région d’hébergement et la rétention documentées. Pour des données sensibles, l’option « pas de fournisseur externe » est étudiée en cadrage.

Quel modèle utilisez-vous ?

Celui qui passe l’évaluation au meilleur coût pour la tâche — souvent un modèle rapide pour la classification et un modèle plus capable pour l’extraction complexe. L’architecture rend le modèle interchangeable par configuration, avec un fallback si le fournisseur est indisponible.

Quelle différence entre un ingénieur IA et un consultant en automatisation ?

Le consultant recommande des outils et des processus ; l’ingénieur construit le système et répond de son fonctionnement : données, règles, intégrations, évaluation des sorties du modèle. Je fais le second, au forfait.

Avez-vous des fonctionnalités IA en production ?

Pas dans mes propres produits à ce jour : ils reposent sur des moteurs de règles déterministes. C’est dit ici plutôt que de présenter un moteur de règles comme de l’IA. Ce que je construis autour d’une étape IA — validation, évaluation, revue humaine, journal — est la même discipline que ces moteurs.

Développement IA · Suisse

Développeur IA en Suisse.

J’intègre des modèles de langage dans des produits destinés à la production : extraction de données à partir de documents, classification, génération structurée, automatisation de workflows, recherche augmentée quand elle est justifiée — avec une validation déterministe des sorties, une évaluation mesurable, une observabilité des appels et un contrôle des coûts. Je ne vends pas « de l’IA » ; je construis le produit autour. Pour être exact : aucun de mes produits en production ne dépend aujourd’hui d’un LLM. Ce qu’ils prouvent, ce sont les moteurs de règles et les workflows dans lesquels une étape IA s’insère.

Parler d’un projet IA Lire : quand un SaaS doit utiliser l’IA ↓Formulaire de contact

Mis à jour le 17 oct. 2026

En bref

Où: Zürich, Suisse — à distance dans toute la Suisse et en Europe
Cas d’usage: Extraction · classification · génération structurée · workflows · RAG · human-in-the-loop
Modèles: API Anthropic, OpenAI, Google, Mistral — choisis par tâche, remplaçables, avec fallback
Garde-fous: Sorties typées et validées · évaluation sur jeu de tests · observabilité · budgets par appel
Format: Forfait, prix convenu à l’avance — souvent une fonctionnalité dans un v1 ou un système d’automatisation
Données: Hébergement et fournisseurs choisis selon nLPD / RGPD ; pas d’entraînement sur vos données
Preuve: Aucun produit en production ne dépend aujourd’hui d’un LLM — les produits cités montrent la structure déterministe

La plupart des projets IA échouent pour une raison qui n’a rien à voir avec le modèle : personne n’a construit le système autour. Où vont les documents, qui a le droit de les voir, que se passe-t-il quand la sortie est fausse, combien coûte chaque requête, comment sait-on que la version d’hier était meilleure. C’est ce système que je construis.

Mon point de départ est celui d’un développeur full-stack qui a construit des moteurs de décision déterministes — fiscalité, droit aérien, scoring — et qui sait donc où un modèle probabiliste apporte quelque chose et où il détruirait la confiance. Le résultat visé est un produit avec de l’IA dedans, pas une démo de chatbot ; quand le besoin est d’abord un processus à automatiser, la page automatisation des processus métier est la bonne porte d’entrée.

01 — Cas d’usage

Ce que l’IA fait bien dans un produit

Les tâches où un modèle de langage remplace des semaines de règles manuelles ou du travail humain répétitif, et où l’erreur est rattrapable.

Extraction structurée: Transformer un PDF, un email, une facture, un relevé ou un formulaire en champs typés — avec un schéma de sortie imposé, une confiance par champ et une relecture humaine quand la confiance est basse.
Classification et routage: Trier des demandes, des tickets, des documents ou des réponses vers la bonne file ou le bon traitement. Le modèle propose, une règle déterministe tranche les cas sensibles.
Génération structurée: Produire un courrier, un résumé, une proposition ou un rapport à partir de données validées — avec un gabarit, des contraintes et une sortie JSON qui alimente le reste du système, pas un texte libre.
Automatisation de workflows: Enchaîner extraction, décision et action (créer un dossier, envoyer un email, mettre à jour un statut) avec des étapes reprises en cas d’échec et un journal de ce qui a été fait.
Workflows agentiques — quand c’est justifié: Un agent qui appelle des outils a du sens quand la tâche est ouverte et vérifiable. Sinon, un pipeline déterministe avec un appel LLM par étape coûte moins, se teste mieux et s’explique.
Recherche augmentée (RAG) — quand c’est justifié: Répondre à partir de vos documents : découpage, embeddings dans Postgres (pgvector), recherche hybride, citations. Utile quand le corpus change souvent ; inutile quand une base de données relationnelle et une requête suffisent.
Human-in-the-loop: Une file de validation où un humain approuve, corrige ou rejette — et où chaque correction devient un exemple d’évaluation. C’est ce qui permet de déployer avant que le modèle ne soit parfait.

02 — Limites

Quand l’IA ne doit pas être utilisée

Un modèle probabiliste n’a pas sa place partout. Ces cas reviennent dans presque chaque cadrage.

Décisions qui doivent être justifiables: Éligibilité, calcul d’impôt, montant d’indemnisation, conformité : la réponse doit être reproductible et traçable. Sur Horvera et Atamatax, la décision est un moteur de règles versionné qui montre sa trace. L’IA peut préparer les faits, jamais rendre le verdict.
Ce qu’une requête SQL fait déjà: Si la question est « combien de clients ont payé ce mois-ci », la réponse est une requête, pas un modèle. Ajouter un LLM ajoute du coût, de la latence et une source d’erreur.
Quand l’erreur coûte plus que le gain: Un résumé faux dans un outil interne se corrige ; une clause fausse dans un contrat envoyé au client ne se corrige pas. Sans relecture humaine possible, on n’automatise pas.
Quand vous ne pouvez pas évaluer: 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 régresse. L’évaluation se construit avant la fonctionnalité.
Données que vous n’avez pas le droit d’envoyer: Données de santé, d’identité, secrets d’affaires : le fournisseur, la région d’hébergement et la rétention se décident avant la première ligne de code — parfois la réponse est « pas de LLM externe ».

03 — Implémentation

Comment j’implémente une fonctionnalité IA

Chaque appel à un modèle est une fonction typée : une entrée validée, un prompt versionné dans le code, un schéma de sortie (JSON) validé avec Zod, un modèle choisi pour la tâche et remplaçable par configuration, un fallback si le fournisseur tombe ou si la sortie est invalide. Le reste de l’application n’a jamais affaire à du texte libre.

L’évaluation vient avec la fonctionnalité, pas après : un jeu d’exemples réels, un score, et l’exécution à chaque changement de prompt ou de modèle. Chaque correction humaine en production rejoint ce jeu. C’est ce qui permet de changer de modèle en confiance quand un meilleur ou moins cher apparaît.

L’observabilité couvre chaque appel : entrée, sortie, modèle, latence, tokens, coût, version du prompt — dans PostHog ou un journal Postgres selon la sensibilité. Les budgets sont explicites : plafond par utilisateur, par jour, par fonctionnalité, avec dégradation gracieuse plutôt que facture surprise.

Le déterministe entoure le probabiliste. Les règles métier, les seuils, les permissions et les calculs restent du code testé ; le modèle remplit les trous que les règles ne peuvent pas remplir. Ce qui vaut pour un moteur d’éligibilité vaut pour un extracteur de factures : la structure est fixe, seule la lecture est apprise.

04 — Stack

La stack pour un produit IA en production

Next.js (App Router) et TypeScript — l’application, les server actions, les routes de webhook.
Postgres — les données, l’historique des appels, pgvector pour la recherche sémantique quand le RAG est justifié.
API de modèles — Anthropic, OpenAI, Google ou Mistral via une couche d’abstraction (Vercel AI SDK ou client direct), avec sorties structurées et outils typés.
Zod — validation de chaque entrée et de chaque sortie de modèle.
Files et tâches — traitement asynchrone des documents longs, reprises, idempotence.
PostHog ou journal Postgres — traces, coûts, évaluations, feedback humain.
Stripe, Resend, Vercel — comme pour tout SaaS : la fonctionnalité IA vit dans un produit complet.

05 — Recruter ?

Recruter un ingénieur IA, ou confier une fonctionnalité ?

Recrutez un ingénieur IA si l’IA est au cœur de ce que vous vendez et que vous livrerez des fonctionnalités IA chaque mois : évaluer, changer de modèle, surveiller les coûts est un travail continu. Pour une fonctionnalité définie — extraire des champs d’un type de document, classer des demandes — un projet au forfait livre la fonctionnalité, son jeu d’évaluation et sa documentation.

Un ingénieur IA et un consultant en automatisation ne font pas le même métier : le consultant recommande des outils, l’ingénieur construit le système et répond de son fonctionnement. Le guide recruter ou externaliser aide à trancher.

Est-ce le bon service ?

Ce service a du sens si

Vous avez un flux de documents, de demandes ou de textes que des humains traitent aujourd’hui à la main, et des exemples réels pour évaluer.
La fonctionnalité IA s’inscrit dans un produit — comptes, données, paiements — que vous voulez construire ou étendre correctement.
Vous voulez savoir, chiffres à l’appui, si le modèle fonctionne, ce qu’il coûte et ce qui se passe quand il se trompe.
Vous avez besoin d’un jugement honnête sur ce qui doit rester déterministe.

Ce n’est pas le bon service si

Vous cherchez un chatbot générique posé sur un site — des outils sans code le font pour quelques francs par mois.
Vous voulez entraîner ou affiner un modèle de fondation — c’est un autre métier, et rarement nécessaire.
La décision finale doit être prise par le modèle sans possibilité de relecture ni de trace.
Vous n’avez aucun exemple réel et aucun moyen d’en obtenir.

Preuves — produits construits et exploités

Mes propres produits, avec leur état réel. Aucun projet client n’est publié à ce jour.

Méthode

Quatre étapes, scope fixe, prix convenu à l’avance.

01
Diagnostic
20 minutes, gratuit. Modèle économique, workflows, risques, périmètre produit. Si je ne suis pas la bonne personne, je le dis.
02
Architecture et proposition
Sous 48h : modèle de données, frontières du système, intégrations, UX — et un seul prix forfaitaire avec des jalons datés. Pas de « à partir de ».
03
Construction
4 à 6 semaines d’itérations contrôlées. Démo chaque vendredi sur une preview Vercel. Vous voyez le système grandir en direct — pas de boîte noire.
04
Mise en production
Paiements, analytics, déploiement, workflows opérationnels. Vous repartez avec le repo, les comptes, le pipeline — et 30 jours de réponses sous 24h.
05
Amélioration
Itération mesurée sur l’usage réel : un nouveau forfait par périmètre, ou rien si votre équipe reprend. Pas de dépendance cachée.

Le déroulé complet, les garanties et les prix →

Questions fréquentes

Quand un SaaS doit-il utiliser l’IA ?
Quand une tâche est faite aujourd’hui à la main sur du texte ou des documents, que l’erreur est rattrapable ou relisible, et qu’il existe des exemples réels pour évaluer. Pas quand la réponse est déjà une requête de base de données, ni quand la décision doit être justifiable ligne par ligne.
Quand faut-il utiliser le RAG — et quand non ?
Le RAG est utile quand la réponse dépend d’un corpus de documents qui change et qu’il faut citer. Il est inutile quand les données sont structurées et qu’une requête suffit, et dangereux quand les documents contiennent des versions contradictoires sans gouvernance. Souvent, un bon schéma de données rend le RAG superflu.
Comment garantir qu’une sortie d’IA est correcte ?
On ne garantit pas ; on mesure et on encadre. Sortie structurée validée par schéma, règles déterministes pour les cas sensibles, jeu d’évaluation exécuté à chaque changement, relecture humaine sur les faibles confiances, et journal de chaque appel pour comprendre les erreurs.
Combien coûte une fonctionnalité IA ?
Deux coûts distincts. Le développement : une fonctionnalité d’extraction ou de classification bien encadrée tient dans un forfait de v1 ou un sprint dédié de 2 à 4 semaines. L’exploitation : de quelques centimes à quelques francs par document selon le modèle, plafonnés par des budgets explicites. Les deux sont chiffrés avant de commencer.
Mes données sont-elles envoyées à OpenAI ou Anthropic ?
Seulement ce qui est nécessaire, vers le fournisseur choisi pour la tâche, sous un contrat qui exclut l’entraînement sur vos données, avec la région d’hébergement et la rétention documentées. Pour des données sensibles, l’option « pas de fournisseur externe » est étudiée en cadrage.
Quel modèle utilisez-vous ?
Celui qui passe l’évaluation au meilleur coût pour la tâche — souvent un modèle rapide pour la classification et un modèle plus capable pour l’extraction complexe. L’architecture rend le modèle interchangeable par configuration, avec un fallback si le fournisseur est indisponible.
Quelle différence entre un ingénieur IA et un consultant en automatisation ?
Le consultant recommande des outils et des processus ; l’ingénieur construit le système et répond de son fonctionnement : données, règles, intégrations, évaluation des sorties du modèle. Je fais le second, au forfait.
Avez-vous des fonctionnalités IA en production ?
Pas dans mes propres produits à ce jour : ils reposent sur des moteurs de règles déterministes. C’est dit ici plutôt que de présenter un moteur de règles comme de l’IA. Ce que je construis autour d’une étape IA — validation, évaluation, revue humaine, journal — est la même discipline que ces moteurs.