Ce qu'un MVP Sprint réussit avec les produits IA

La chose la plus difficile dans la construction de produits IA n'est pas le modèle. Je l'ai appris tôt, et chaque projet depuis l'a confirmé. Un MVP Sprint sur un produit IA est un type de sprint différent d'une application CRUD. Le modèle est un composant. Le workflow autour, la logique de vérification, les portes d'approbation, les chemins de secours, c'est le vrai produit. Ratez le workflow et la précision du modèle devient sans importance.

Le modèle n'est pas le produit

Quand j'ai construit Fursa, un outil d'éligibilité de route de visa, la tentation était de traiter le modèle de langage comme la machine à réponses. Posez une question, retournez le résultat, livrez-le. Ç'aurait été une erreur. L'éligibilité de visa est un domaine juridique. Une mauvaise réponse ne frustre pas seulement un utilisateur. Elle peut envoyer quelqu'un au mauvais consulat, lui coûter de l'argent, ou pire. Le modèle est donc devenu un classificateur à l'intérieur d'un pipeline de vérification plus large. Sa sortie était vérifiée par rapport à des données sources structurées avant que quoi que ce soit n'atteigne l'utilisateur. Le modèle a accéléré le raisonnement. Il ne l'a pas remplacé.

C'est le motif auquel je reviens régulièrement. Le modèle fait le travail lourd sur les entrées ambiguës et non structurées. La logique déterministe gère les parties où la correction est binaire. Les deux doivent être composés délibérément, pas câblés ensemble avec de l'espoir.

La vérification n'est pas optionnelle, c'est l'architecture

En 2025 et jusqu'en 2026, l'architecture IA en production s'est éloignée du RAG à invite unique vers des workflows multi-agents. Des frameworks comme LangGraph et CrewAI sont devenus standard pour gérer les tâches avec état et itératives. La raison n'est pas que le RAG à invite unique est mauvais. C'est que les exigences de production, l'auditabilité, la récupération après une défaillance partielle, l'approbation humaine sur les étapes à enjeux élevés, ne peuvent pas être satisfaites par un seul appel à un modèle.

Sur OptimalTax, un système de déclaration fiscale automatisé pour le secteur public, nous avons atteint 99 % de précision de calcul fiscal. Ce chiffre ne venait pas d'un meilleur modèle. Il venait d'un pipeline qui validait les sorties intermédiaires avant de les transmettre en aval, et des portes d'approbation humaines explicites sur les cas limites que le modèle signalait comme incertains. Le modèle savait ce qu'il ne savait pas. Cela a nécessité de l'ingénierie, pas du prompting.

Si vous construisez un produit IA et que votre diagramme d'architecture est juste une boîte étiquetée « LLM » avec des flèches entrantes et sortantes, vous décrivez une démo, pas un produit.

Ce qu'un MVP Sprint scopes réellement

Un MVP Sprint standard pour un produit IA couvre huit à douze semaines. Dans cette fenêtre, je dois prendre des décisions qui seront coûteuses à défaire : quelles étapes du workflow nécessitent une validation déterministe, où l'approbation humaine est requise avant que le système ne procède, comment le produit se comporte quand un appel de modèle échoue ou retourne une sortie de faible confiance.

Ce ne sont pas des décisions de polish. Ce sont des décisions structurelles. Et elles doivent être prises tôt, car le coût de l'intégration rétroactive de la logique de vérification dans un pipeline construit sans elle est élevé. J'ai vu des équipes passer plus de temps à démêler un pipeline naïf qu'elles n'en ont passé à le construire.

Le travail de scoping est aussi l'endroit où je repousse la portée. Un produit IA qui essaie de tout faire dans le premier sprint finit par ne rien faire de manière fiable. La contrainte d'une portée fixe force une question utile : quel workflow unique, s'il fonctionne correctement à chaque fois, rend ce produit digne d'être utilisé ? Commencez là. Construisez ce pipeline correctement. Tout le reste est phase deux.

Gater sur l'approbation humaine est une fonctionnalité, pas une solution de contournement

Il y a une tendance à traiter l'humain dans la boucle comme un correctif temporaire, quelque chose à supprimer une fois que le modèle s'améliore. Je suis en désaccord avec ce cadrage. Pour une classe de décisions, l'approbation humaine est la bonne architecture de manière permanente.

Sur Job Hunter, un tableau d'affichage d'emploi quotidien et un moteur de sensibilisation qui explore plus de 185 pages de carrière, la couche IA génère des brouillons de sensibilisation personnalisés. Ces brouillons ne sont pas envoyés automatiquement. L'utilisateur examine et approuve chacun. Ce n'est pas une limitation du modèle. C'est la conception du produit. Le jugement de l'utilisateur fait partie de la chaîne de valeur. Le supprimer rendrait le produit plus rapide et pire.

La même logique s'applique partout où la sortie a des conséquences réelles : recommandations financières, classifications juridiques, décisions du secteur public. Le modèle surface la réponse. Une personne la confirme. Ce n'est pas une solution de contournement. C'est la responsabilité intégrée à l'architecture.

Ce qui casse dans les deux premières semaines

Chaque produit IA que j'ai construit a heurté le même mur dans les deux premières semaines d'utilisation réelle. Le modèle fonctionne bien sur les entrées pour lesquelles vous avez conçu. Il fonctionne de manière imprévisible sur les entrées que les utilisateurs envoient réellement.

Ce n'est pas un problème de modèle. C'est un problème de distribution. Les données d'entraînement, la conception de l'invite, les exemples d'entrées utilisés pendant le développement, tous reflètent des hypothèses sur ce que les utilisateurs enverront. Les vrais utilisateurs ne lisent pas la documentation. Ils envoient des entrées partielles, des entrées ambiguës, des entrées dans la mauvaise langue, des entrées qui sont techniquement valides mais sémantiquement cassées.

La réponse n'est pas de rendre le modèle plus robuste en isolation. La réponse est de construire le pipeline de sorte que les sorties de faible confiance soient capturées avant d'atteindre l'utilisateur, signalées pour examen, et utilisées pour améliorer le système. Cette boucle de rétroaction est la différence entre un produit IA qui se dégrade au fil du temps et un qui s'améliore.

Construire cette boucle fait partie de ce que je scope dans un MVP Sprint dès le départ. Ce n'est pas une préoccupation de phase deux. Si vous livrez sans elle, vous livrez un produit qui empirera à mesure que l'utilisation augmente.

Où aller à partir d'ici

Si vous construisez un produit IA et que l'architecture n'est pas encore établie, le moment de penser à la vérification, aux portes d'approbation et aux chemins de défaillance est maintenant, pas après la première plainte d'utilisateur. J'ai écrit davantage sur la façon dont cela se déploie dans différents domaines dans le reste des notes.

Si vous avez un workflow spécifique en tête et que vous voulez tester l'architecture avant de vous engager dans une construction, l'engagement de diligence raisonnable technique est le bon point de départ. Portée fixe, deux à trois semaines, axé sur exactement les questions qui importent avant que vous ne passiez huit à douze semaines à construire quelque chose que vous ne pouvez pas facilement modifier.