Le modèle est un composant, pas le produit

Chaque produit IA que j'ai déployé a exigé le même changement de perspective : arrêter de traiter le modèle comme la chose et commencer à le traiter comme une étape. Le modèle génère. Le flux de travail décide. Cette limite est l'endroit où la plupart des produits IA se maintiennent ou s'effondrent, et bien la maîtriser est le vrai problème d'ingénierie pour construire des produits IA qui fonctionnent en production.

Le modèle est un générateur, pas un décideur

Un modèle de langage est bon pour produire rapidement du texte plausible. Il n'est pas bon pour savoir quand il se trompe. Cette asymétrie compte plus que n'importe quel score de benchmark. Quand j'ai construit Fursa, le moteur d'éligibilité des routes de visa, le modèle devait raisonner sur les règles d'immigration pour quatre pays de destination. Les règles sont spécifiques, elles changent, et une mauvaise réponse a des conséquences réelles pour une vraie personne. Laisser le modèle répondre directement n'a jamais été une option. Le modèle produisait une réponse candidate structurée. Une couche de vérification vérifiait cette réponse par rapport aux règles sources. Seul un résultat valide atteignait l'utilisateur. Le modèle était un composant. Le flux de travail était le produit.

C'est le changement que l'industrie a opéré au cours de 2025 et jusqu'en 2026. Les pipelines RAG à une seule invite cèdent la place à des architectures multi-agents, des frameworks comme LangGraph et LlamaIndex Workflows, des graphes avec état où chaque nœud a une responsabilité définie. Le modèle ne possède pas le résultat. Le graphe le possède.

Les sorties structurées sont un contrat, pas une commodité

Les sorties structurées natives ont changé ma façon de penser l'intégration des modèles. Quand un modèle retourne un objet typé plutôt qu'une chaîne de prose, le code en aval peut le traiter comme n'importe quel autre appel de fonction. Vous le validez, vous routez sur ses champs, vous le passez à l'étape suivante. Le modèle devient composable.

J'ai utilisé ce motif dans Job Hunter, le tableau d'affichage d'emploi quotidien et le moteur de sensibilisation. Le système explore plus de 185 pages de carrière, extrait les enregistrements d'emploi, puis personnalise la sensibilisation. Chaque étape d'extraction retourne un objet structuré. Si un champ manque ou est mal formé, le pipeline le signale avant qu'il n'atteigne l'étape de personnalisation. Le modèle ne touche jamais au texte de sensibilisation jusqu'à ce que l'enregistrement d'emploi soit propre. Ce séquençage n'est pas astucieux. C'est juste de la discipline d'ingénierie appliquée à un composant probabiliste.

La règle pratique que je suis : toute sortie de modèle qui alimente une autre étape automatisée doit être typée et validée. La sortie en prose est pour l'humain à la fin de la chaîne, pas pour la machine au milieu de celle-ci.

L'approbation humaine n'est pas un contournement, c'est une porte architecturale

Il y a un motif auquel je reviens constamment, que j'ai écrit dans les notes sur la chaîne de garde : chaque action conséquente dans un flux de travail agentique doit passer par une porte d'approbation humaine avant son exécution. Ce n'est pas une question de méfiance envers le modèle. C'est une question de responsabilité. Quand un système agit au nom d'un utilisateur, cet utilisateur a besoin d'un moment pour confirmer que l'action est celle qu'il a l'intention de faire.

ProPost AI génère 365 brouillons de posts par utilisateur par an. Le modèle produit les brouillons. L'utilisateur examine et approuve chacun avant sa publication. Cette porte n'est pas un point de friction. C'est le produit. Les utilisateurs font davantage confiance à la sortie parce qu'ils l'ont touchée. L'étape d'approbation génère aussi un signal : quels brouillons sont acceptés, lesquels sont modifiés, lesquels sont rejetés. Ce signal alimente l'itération suivante.

Dans la fintech, les enjeux sont plus élevés et les portes plus formelles. La plateforme de services financiers que j'ai construite gère des flux de transactions où une instruction mal routée est un événement de conformité, pas juste un bug. Chaque décision automatisée dans ce système a une piste d'audit. Les étapes assistées par modèle sont enregistrées avec leurs entrées, sorties et l'action humaine qui a suivi. Ce journal n'est pas optionnel. C'est ce qui rend le système auditable, et l'auditabilité est ce qui le rend déployable dans un contexte réglementé.

La vérification n'est pas un post-traitement, c'est une étape de première classe

La plupart des équipes que j'ai vues traitent la vérification comme quelque chose qu'on ajoute après que le modèle fonctionne. C'est le mauvais ordre. La vérification doit être conçue avant l'intégration du modèle, car le rôle du modèle dépend de ce qui peut être vérifié.

La question à se poser d'abord est : à quoi ressemble une sortie correcte, et puis-je la tester par programmation ? Si la réponse est oui, vous pouvez la valider. Si la réponse est non, vous avez besoin d'un humain dans la boucle ou vous devez repenser la tâche. Certaines tâches ne conviennent pas à une automatisation complète à n'importe quel niveau de qualité. Reconnaître cela tôt économise beaucoup de rework.

Pour OptimalTax, le système de déclaration fiscale automatisé, la correction était mesurable. Les calculs fiscaux correspondent soit aux règles, soit non. Le système a atteint 99 % de précision de calcul parce que la couche de vérification exécutait chaque sortie par rapport aux règles statutaires avant de présenter un résultat. Le modèle accélérait l'extraction et l'interprétation. Le moteur de règles confirmait la réponse. Aucun composant seul n'aurait été suffisant.

La composabilité plutôt que les monolithes

Un prompt monolithique qui essaie de tout faire, récupérer le contexte, raisonner à ce sujet, formater la réponse et appliquer les règles métier, est fragile. Changez la récupération et le raisonnement se casse. Changez le formatage et les règles se cassent. Décomposer le flux de travail en étapes discrètes avec des interfaces typées entre elles rend chaque étape testable et remplaçable indépendamment.

C'est de l'ingénierie logicielle standard. Le fait que l'un des composants soit un modèle de langage ne change pas le principe. Un nœud de modèle dans un graphe doit avoir une responsabilité unique, un schéma d'entrée défini et un schéma de sortie défini. S'il a plus d'une responsabilité, divisez-le.

J'applique cela dans chaque produit IA que je construis. Les graphes deviennent plus complexes à mesure que le produit mûrit, mais les nœuds individuels restent étroits. Un nœud étroit est facile à surveiller, facile à remplacer par un meilleur modèle quand un devient disponible, et facile à expliquer à une partie prenante non technique qui a besoin de comprendre pourquoi le système a pris une décision.

Où aller à partir d'ici

Ces principes ne viennent pas de la lecture sur l'IA. Ils viennent du déploiement de systèmes où une mauvaise réponse avait un coût : une demande de visa rejetée, une déclaration fiscale mal classée, une violation de conformité. La contrainte était l'enseignant.

Si vous construisez un produit IA et que le flux de travail semble fragile, le problème est généralement architectural. Le modèle fait probablement trop. Si vous voulez voir comment ces motifs se déploient dans différents secteurs et contraintes, l'enregistrement complet des études de cas est à /work. Si vous voulez discuter de l'architecture de quelque chose que vous construisez, engagez une conversation avec Kadon.