Application IA
Un produit dont une fonction centrale repose sur un modèle : résumer, classer, extraire, générer, comprendre une image ou un document (multimodal).
Build With Me / IA
Un assistant qui répond à partir de vos documents, une automatisation qui supprime une tâche répétitive, une fonction IA dans votre SaaS : utile quand le problème est réel et que le résultat se vérifie.
Pour construire un produit IA, commencez par vérifier que le problème a besoin d’IA : des règles, une recherche ou un formulaire bien fait suffisent souvent. Si l’IA est utile, appelez le modèle depuis votre serveur, donnez-lui le contexte nécessaire (récupération de documents, outils limités), exigez une sortie structurée, mesurez la qualité sur un jeu d’exemples avant chaque changement, plafonnez les coûts, et gardez une validation humaine avant toute action irréversible. Un agent IA ne remplace pas le jugement humain : il l’outille.
Vérifié le
En bref
Trois façons de construire
Cette page donne l’architecture, les garde-fous et un parcours en étapes, avec la documentation officielle des fournisseurs de modèles. Pour décider si vous pouvez construire votre produit avec des outils d’IA ou s’il vaut mieux déléguer, le diagnostic gratuit construire, acheter ou déléguer aide à trancher. Build School enseigne à construire un produit web avec un agent de code — un outil IA en fait partie des types de produit.
Vous construisez, Bynilson relit l’architecture, le jeu d’évaluation, les coûts et les risques, par écrit ou en session. Pour un produit centré sur un LLM (agent, chatbot), une demande est étudiée au cas par cas : pas de forfait, pas de promesse avant d’avoir vu le problème.
Aucun produit Bynilson en production ne dépend aujourd’hui d’un LLM. La réalisation s’appuie sur ce qui est prouvé — des moteurs de règles et des workflows, comme ceux d’Atamatax, d’Horvera et de Vellaci — et ajoute l’IA là où son résultat se mesure. L’engagement automatisation de processus métier existe ; un agent ou un chatbot centré sur un LLM est étudié au cas par cas, via la qualification de projet.
Aucun produit Bynilson en production ne dépend aujourd’hui d’un LLM : la réalisation s’appuie sur des moteurs de règles et des workflows prouvés, et l’IA y est ajoutée là où elle se mesure.
Les produits
Six formes de produit. Pour chacune, la façon raisonnable de la construire, et le piège qui la fait échouer en production.
Un produit dont une fonction centrale repose sur un modèle : résumer, classer, extraire, générer, comprendre une image ou un document (multimodal).
Un modèle qui enchaîne des étapes et appelle des outils (rechercher, lire, créer un brouillon) pour atteindre un objectif, orchestré par votre code.
Répondre à des questions à partir de vos documents ou de votre base de connaissance — pour vos clients (support) ou pour votre équipe (assistant interne).
Un SaaS classique — comptes, données, abonnement — avec une fonction IA qui apporte une valeur mesurable.
Extraire des champs d’une facture, classer des pièces, vérifier qu’un dossier est complet, comparer un document à des règles.
Un enchaînement qui se déclenche seul entre vos outils : une commande crée une facture, une demande est triée et attribuée, un rapport part chaque lundi.
Le vrai problème
La question qui fait économiser le plus d’argent. Un modèle est utile pour comprendre ou produire du langage ; pour le reste, des outils plus simples sont plus fiables et moins chers.
| Votre besoin | Souvent suffisant | Quand l’IA devient utile |
|---|---|---|
| Appliquer des conditions connues (éligibilité, calcul, tarif) | Un moteur de règles déterministe et testé | Presque jamais pour la décision ; parfois pour lire l’entrée en texte libre |
| Retrouver une information | Une recherche plein texte et de bons filtres | Quand les questions sont formulées librement et que les mots ne correspondent pas |
| Collecter des informations | Un formulaire bien conçu | Quand l’information arrive en texte libre, en emails ou en documents |
| Classer ou extraire | Des règles si le format est stable | Quand les documents varient et qu’une relecture humaine est prévue |
| Rédiger un brouillon | Des modèles de texte | Quand chaque cas est différent et qu’une personne relit avant l’envoi |
Écrivez le problème en une phrase, avec la personne qui l’a et ce que lui coûte la situation actuelle. Si une règle écrite résout 90 % des cas, commencez par elle : l’IA pourra traiter le reste plus tard, sur une base mesurable.
L’architecture
La qualité
Les coûts
Sécurité et données
En production
Le parcours
Écrire le problème
Qui, quelle tâche, combien de temps ou d’erreurs elle coûte aujourd’hui.
DisponibleQuand un SaaS doit-il utiliser l’IA ?
Vérifier qu’il faut de l’IA
Règles, recherche, formulaire : la solution la plus simple d’abord.
DisponibleDiagnostic gratuit : construire, acheter ou déléguer
Rassembler les exemples
De vrais cas, avec la bonne réponse : votre futur jeu d’évaluation.
Choisir le modèle
Comparer deux ou trois modèles sur vos exemples : qualité, coût, latence, traitement des données.
Construire le premier appel
Côté serveur, avec une sortie structurée validée par un schéma.
DisponibleDocumentation AI SDKVercel
Ajouter le contexte
Récupération dans vos contenus, avec les droits d’accès appliqués.
Limiter les outils
Privilèges minimaux, validation humaine avant les actions irréversibles.
DisponibleOWASP Top 10 des applications LLMOWASP
Évaluer
Relancer le jeu d’évaluation, corriger, recommencer — avant chaque déploiement.
DisponibleLes limites de l’IA en développement web
Plafonner les coûts
Quotas, limitation de débit, cache, coût par tâche mesuré.
DisponibleCalculateur du coût d’un SaaS
Vérifier la protection des données
Ce qui part chez le fournisseur, combien de temps, sur quelle base.
DisponiblePFPDT — Préposé fédéral à la protection des donnéesSwiss Confederation
Mettre en production et surveiller
Erreurs, latence, coût, signalements, version de modèle figée.
DisponibleVérifier une application construite avec l’IA avant le lancement
Définissez une tâche précise, donnez au modèle quelques outils aux droits minimaux, plafonnez le nombre d’étapes, journalisez chaque appel et exigez une validation humaine avant toute action irréversible. Commencez souvent par un workflow fixe, où votre code décide de l’ordre des étapes : il est plus prévisible qu’un agent libre.
Avec un jeu d’évaluation écrit avant de construire : de vrais exemples et les critères d’une bonne réponse. Relancez-le à chaque changement de prompt, de modèle ou de récupération, ajoutez les cas difficiles et les erreurs signalées par les utilisateurs, et ne déployez pas une version qui fait baisser le score.
Pour répondre à partir de vos documents, la récupération (RAG) est en général le premier choix : les contenus restent à jour, les sources sont citables, et les droits d’accès s’appliquent à la recherche. Le fine-tuning sert plutôt à apprendre un format ou un style constant ; il n’est pas un bon moyen de faire connaître des faits qui changent.
Si les règles sont connues et stables, un logiciel classique est plus fiable, plus rapide et moins cher. L’IA est utile pour l’étape qui demande de comprendre du texte libre ou des documents variables, avec des contrôles et une relecture humaine autour.
Deux coûts distincts : la construction (dépend du périmètre, comme tout logiciel) et l’usage (chaque appel au modèle se paie). Mesurez le coût d’une tâche complète sur vos exemples avant de fixer un prix. Aucun chiffre générique ne remplace cette mesure ; le calculateur de coût SaaS aide pour la partie construction.
Cela dépend du fournisseur et de sa configuration : vérifiez où les données sont traitées, combien de temps elles sont gardées et si elles servent à l’entraînement. N’envoyez que ce que la tâche exige, et appliquez les droits d’accès avant la récupération. En Suisse, la nLPD s’applique ; ce n’est pas un conseil juridique.
Non. Un agent peut préparer, trier, rédiger et proposer ; la décision qui engage — envoyer, payer, refuser, publier — reste à une personne qui voit ce que l’agent a fait et pourquoi.