Ce qu'on a appris en livrant des produits IA

Pourquoi cet article

Au cours des 24 derniers mois, nous avons mis en production un portfolio de produits. Ils couvrent la fintech, la civic tech, un SaaS de services à domicile, de la prédiction de fantasy sports, de la sci-fi immersive, du trading autonome et des PWA événementielles — la plupart avec de l'IA dans la boucle, l'un entièrement transactionnel.

Ce post, c'est ce qu'on aurait aimé savoir avant le produit 1. Il est orienté vers ce qui nous a surpris — les patterns qui ont tenu à travers tout le portfolio, et ceux qui ont cassé quand on a tenté de les copier à l'aveugle.

La forme du portfolio

Les produits couvrent des domaines très différents — moteurs narratifs et de contenu, plateformes analytiques B2B, SaaS ops avec voix ou chat dans la boucle, UX de prédiction et de raisonnement, outils civic tech, PWA multi-tenant, boucles autonomes sur des données de séries temporelles.

Ils semblent sans rapport. Ils ne le sont pas. Le même ensemble de leçons s'applique à tous.

Leçon 1 : la partie IA est rarement la plus difficile

Quand nous avons commencé, nous supposions que livrer des produits IA impliquait des problèmes ML profonds — sélection de modèle, fine-tuning, évaluation. En réalité, l'IA représente 15 à 25 % du travail. Le reste :

• Auth, facturation, multi-tenant, RBAC
• Pipelines de données (ingestion, normalisation, versioning)
• Observabilité (logs, traces, dérive d'évaluation, suivi des coûts)
• UI/UX pour un produit dont le comportement est non déterministe
• Onboarding client et garde-fous
• Conformité (RGPD pour l'Europe, réglementations sectorielles pour la fintech et la civic tech)

La plupart des "startups IA" livrent des démos IA. Pour livrer des produits IA, les 75 % qui entourent l'IA doivent être là. Nous avons vu des concurrents avec des modèles bien plus sophistiqués perdre face à des équipes avec des modèles plus simples et une meilleure infrastructure.

Leçon 2 : les valeurs par défaut comptent plus que les capacités

Sur un projet d'agent vocal, nous avons passé deux semaines à affiner le prompt LLM. Puis nous avons réalisé que 80 % de la qualité des conversations venait d'une seule décision : la première phrase de l'agent.

Sur une plateforme RAG : la stratégie de chunking comptait plus que le modèle d'embedding.

Sur un moteur quantitatif : le sizing de position par défaut comptait plus que le modèle de prédiction.

La leçon : dans les produits IA, les valeurs par défaut sont le produit. Choisir des défauts sensés et laisser les utilisateurs les surcharger est presque toujours mieux que leur demander de configurer 14 choses au départ.

Leçon 3 : construire l'évaluation avant la fonctionnalité

C'était une leçon difficile. Sur l'un des produits RAG, nous avons livré le système, l'avons démontré, puis n'avions aucun moyen de savoir s'il s'améliorait ou se dégradait au fil du temps. Nous avons ajouté l'évaluation six semaines plus tard. Entre-temps, nous avions fait des changements qu'on ne pouvait plus mesurer.

Désormais, sur chaque produit IA, nous construisons l'évaluation en premier :

• Un petit jeu de données curé (50 à 100 exemples)
• Une fonction de scoring (LLM-as-judge ou à base de règles)
• Un hook CI qui exécute l'évaluation à chaque PR

Sans ça, on vole à l'aveugle. Coût : 1 à 2 jours. Valeur : chaque décision suivante est éclairée.

Leçon 4 : le trafic réel enseigne tout

Nous avions un jeu de tests synthétiques pour l'un des agents vocaux. Il atteignait 92 % en évaluation offline. Nous avons lancé. Le premier jour, les vrais utilisateurs l'ont mis en défaut de façons qu'on n'avait pas anticipées :

• Bruit de fond (enfants, circulation, chiens)
• Forts accents régionaux absents du jeu de tests
• Utilisateurs qui interrompaient constamment
• Utilisateurs qui répondaient aux questions avant qu'elles soient posées

Le correctif n'était pas un meilleur modèle. C'était de meilleurs logs en production pour voir ce qui se passait vraiment, puis une itération sur les cas limites semaine après semaine. Six semaines après le lancement, l'agent atteignait 96 % de taux de complétion. Ce gain venait du trafic réel, pas de l'évaluation synthétique.

Outils utilisés maintenant : Posthog pour les transcriptions + replay, tableaux de bord custom pour la dérive des coûts et de la latence, revue manuelle de 10 appels aléatoires par semaine.

Leçon 5 : la surprise côté coûts, c'est toujours la voix

Dans tout le portfolio, les produits qui génèrent le plus d'appels LLM par minute (boucles autonomes, analytique batch) ne sont pas les plus coûteux à opérer. Les produits vocaux le sont — même s'ils font 100 fois moins d'appels LLM. Ils coûtent plusieurs fois plus par utilisateur actif.

Pourquoi ? La voix. La synthèse vocale est 10 à 100 fois plus chère que le cerveau LLM. Nous en parlons dans notre guide des coûts d'agents vocaux.

Leçon : modélisez soigneusement votre économie unitaire si la voix est dans la boucle. Le LLM est rarement le poste de coût principal — la voix et la téléphonie le sont.

Leçon 6 : choisir une stack et la réutiliser

Pour nos premiers produits, nous choisissions les technologies à la carte. Frontend différent (React puis Vue), backend différent (Express puis Fastify), bases de données différentes.

Résultat : chaque montée en compétence prenait trois semaines. Le code ne se transférait pas entre projets. Les corrections de bugs ne capitalisaient pas.

Nous avons ensuite adopté une stack fixe : Nuxt 4 + Fastify + MongoDB + BullMQ + Redis + Vercel/DO. Nous avons écrit des utilitaires partagés (middleware d'auth, multi-tenancy, facturation, hooks d'observabilité) une fois, et les avons copiés entre produits.

C'est un conseil peu fashionable. Le bon choix de framework dépend de l'équipe. Mais le principe sous-jacent — arrêter d'optimiser par projet, commencer à optimiser entre les projets — est la décision à plus fort levier qu'une agence puisse prendre.

Leçon 7 : la fonctionnalité IA est un argument de vente facile, mais ce n'est presque jamais le vrai fossé concurrentiel

Nous avons vendu à des clients "vous aurez un avantage concurrentiel grâce à l'IA". Nous avions tort à chaque fois.

Les vrais fossés que nous avons vu se construire :

• Propriété des données : un an de données propres et labellisées est plus difficile à copier qu'un modèle
• Intégration dans les workflows : quand l'agent est câblé dans votre CRM, téléphonie et back-office, le coût de migration est élevé
• Confiance : les SLA et les historiques d'uptime se capitalisent

La partie IA est remplaçable. Tout ce qui l'entoure ne l'est pas. Désormais, nous vendons l'intégration, pas le modèle.

Leçon 8 : toujours livrer derrière un flag

Chaque fonctionnalité IA que nous livrons passe derrière un flag (LaunchDarkly, GrowthBook, ou fait maison). Les raisons :

• Mauvaise sortie détectée en prod → on bascule le flag, pas de rollback
• A/B test de la version IA vs le fallback à base de règles → mesurer le gain
• Déploiement à 1 % du trafic pour le suivi coûts/qualité avant généralisation
• Conversations commerciales : "nous l'avons livré la semaine dernière, actuellement en beta avec nos meilleurs clients"

Cette pratique nous a sauvés six fois. C'est la base.

Leçon 9 : écriture duale sur la couche de données

Sur quatre produits, nous utilisons des LLM dans le chemin d'écriture : un agent traite l'input, le structure, et écrit en base. La tentation est de faire confiance à la sortie du LLM.

Ne le faites pas. Nous faisons toujours de l'écriture duale : on stocke à la fois l'input brut ET la sortie structurée par le LLM, avec une version. Quand (pas si) le prompt change et que la structure évolue, on peut re-exécuter sur les données brutes sans perdre l'historique.

Cela ajoute 10 % au stockage. Ça en vaut la peine 100 % du temps.

Leçon 10 : l'équipe avec laquelle on livre compte plus que le modèle

Nous avons livré des produits avec des équipes junior, senior, mixtes. Le seul indicateur le plus fiable de succès n'était pas le modèle, le framework ou le budget — c'était si l'équipe avait quelqu'un qui avait déjà livré.

Concrètement : quelqu'un qui avait accompagné un système de son lancement à sa montée en charge, jusqu'à son retrait. Cette personne sait quels coins sont safe à couper et lesquels cassent plus tard. C'est la différence entre un projet de 6 semaines et un de 6 mois.

Recrutez pour ça. Investissez à le développer.

Leçon 11 : préférer l'approche agentique au RAG quand vos données sont relationnelles

C'est la leçon la plus à contre-courant de la liste, et celle qui nous a fait gagner le plus de semaines.

Dans tout le portfolio, un seul produit a réellement utilisé du RAG — un corpus de moteur narratif où les questions sont vraiment sémantiques ("produire un chapitre cohérent avec tout ce qu'on a établi sur ce personnage"). Les autres traitent des questions comme "combien d'enregistrements actifs ce mois-ci", "quel compte a manqué la facture du mois dernier", "quel est le prochain élément planifié pour cet utilisateur". Ce sont des questions relationnelles, pas sémantiques — et un appel db.find() depuis un agent bat une récupération vectorielle sur du texte fragmenté à chaque fois en termes de précision, latence et coût.

L'architecture qui a fonctionné sur les six produits : un agent construit sur claude-agent-sdk (ou simplement l'API Messages Anthropic pour les flux synchrones), avec des appels d'outils fortement typés qui traduisent la question de l'utilisateur en requêtes structurées. Le contexte documentaire (SOPs, politiques, règles d'escalade) vit dans un petit ensemble de fichiers markdown injectés directement dans le system prompt, avec cache_control: ephemeral pour maintenir les coûts stables tout au long de la journée. Pas d'embeddings, pas de chunking, pas de reranker.

Avant d'embedder un seul chunk, listez vos 20 principales questions utilisateurs. Si la plupart sont relationnelles, vous n'avez pas besoin de RAG. Vous avez besoin d'un agent avec des outils.

Leçon 12 : le tool calling forcé, remède à la phrase "presque juste"

Le mode d'échec qui fait tomber la plupart des chatbots en production n'est pas l'hallucination franche — c'est la phrase qui sonne avec assurance et est presque juste : une fausse escalade, un SLA inventé, une signature qui usurpe l'identité d'un responsable ops, une promesse "je vous réponds avant 17h" que le système ne peut pas tenir. L'ingénierie de prompt standard ne résout pas ça. Ajouter plus de règles au system prompt aide rarement — le LLM excelle à produire du texte qui paraît conforme.

Le correctif qui a fonctionné pour nous : ne pas laisser le LLM écrire la prose visible par l'utilisateur du tout.

Nous utilisons le tool_choice: { type: 'any' } d'Anthropic pour forcer le modèle à choisir exactement un outil dans une palette fermée à chaque tour. La seule sortie du LLM est un nom d'outil et des arguments structurés. La réponse qui atterrit sur l'écran de l'utilisateur est générée par des templates déterministes remplis avec les args structurés. Versionnés, révisables, A/B-testables, et structurellement impossibles à halluciner.

Quand l'outil choisi est "rester silencieux" (accusés de réception, salutations), un second modèle plus petit (Haiku) effectue une re-vérification de sécurité : "y a-t-il un signal actionnable dans le dernier message que le premier modèle vient de supprimer ?" Si oui, le silence est annulé. Cela capture les rares cas où Sonnet décide que "merci, à demain" n'est qu'un accusé de réception, alors que le message plus tôt dans le même tour contenait "je suis malade".

Ce pattern est plus complexe à concevoir qu'un chatbot en texte libre. Il est bien moins coûteux à opérer. Nous le recommandons pour tout agent conversationnel qui parle à des opérateurs, clients ou travailleurs dans un contexte où les mauvaises réponses coûtent cher.

Pour conclure

Si vous livrez votre premier produit IA, la tentation est de passer 80 % de votre temps sur l'IA. Résistez.

Consacrez 25 % à l'IA, 25 % à l'évaluation, 25 % à l'infrastructure qui l'entoure, et 25 % à écouter les 100 premiers vrais utilisateurs. C'est comme ça que les produits se livrent.

Si vous souhaitez appliquer ces leçons à votre projet — contactez-nous. Nous avons fait ces erreurs pour que vous n'ayez pas à les refaire.