Ce qu'un consultant en développement logiciel fait avec un workflow IA

Le travail qui compte dans les produits IA en ce moment n'est pas l'appel au modèle. C'est tout ce qui l'entoure. Un consultant en développement logiciel qui construit dans cet espace apprend rapidement que le prompt est la partie facile. La partie difficile est le workflow : ce qui alimente le modèle, ce qui vérifie sa sortie, ce qui valide le résultat avant qu'il ne touche un vrai utilisateur ou une vraie décision.

L'industrie a dépassé les interfaces de chat à prompt unique. Les architectures multi-agents sont maintenant la norme pour tout ce qui est stateful ou complexe. Des frameworks comme LangGraph et CrewAI gèrent l'orchestration, l'état et la coordination asynchrone entre agents. C'est une véritable amélioration. Mais cela signifie aussi que les modes de défaillance se sont multipliés. Un seul agent qui hallucine est une gêne. Une hallucination qui se propage à travers quatre agents en aval avant que quelqu'un ne la remarque est un incident de production.

J'ai construit assez de ces systèmes pour avoir un principe directeur : le modèle est un composant, et le workflow doit être juste.

Le modèle n'est pas le produit

Cela semble évident. Ce ne l'est pas, en pratique. Les équipes passent des semaines à affiner les prompts et presque pas de temps sur l'échafaudage qui détermine si la sortie est utilisable. J'ai vu ce schéma se répéter : un modèle capable enrobé dans un pipeline fragile, sans validation, sans fallback, et sans point de contrôle humain avant que le résultat ne sorte.

Le produit est le workflow. Le modèle est une étape à l'intérieur.

Sur Fursa, le moteur d'éligibilité des routes de visa, le travail du modèle était de raisonner sur des données de politique structurées et de retourner une recommandation. Cette recommandation devait être vérifiable. Nous avons construit la couche de récupération en premier, sourcé les documents de politique, et défini le schéma de sortie avant d'écrire un seul prompt. L'application native de la sortie structurée signifiait que le modèle ne pouvait pas retourner une chaîne de caractères libre là où un booléen était attendu. Le schéma était le contrat. Le modèle devait le respecter.

La vérification est un problème d'ingénierie

Quand la sortie affecte une vraie décision, vous ne pouvez pas faire confiance au modèle pour avoir raison. Vous devez construire la vérification dans le pipeline.

Cela signifie différentes choses dans différents contextes. Parfois cela signifie ancrer le modèle dans une couche de récupération pour que chaque affirmation soit mappée à un document source. Parfois cela signifie une deuxième passe de modèle qui vérifie la sortie primaire contre un schéma connu et bon. Parfois cela signifie une porte d'approbation humaine, une vraie personne qui voit la sortie avant qu'elle ne soit actée.

Sur OptimalTax, le système de déclaration fiscale automatisée, nous avons atteint 99% de précision de calcul. Ce nombre ne venait pas d'un meilleur modèle. Il venait d'une couche de calcul qui fonctionnait indépendamment du modèle, contre des tables de règles fiscales vérifiées, et une étape de réconciliation qui comparait les deux sorties avant la soumission. Le modèle gérait l'interprétation. Un moteur déterministe gérait l'arithmétique. Aucun ne faisait confiance à l'autre aveuglément.

C'est l'architecture vers laquelle je me tourne quand la correction est non-négociable : utiliser le modèle pour ce que les modèles font bien, utiliser des composants déterministes pour ce qu'ils font bien, et construire un handoff explicite entre eux.

La sortie structurée n'est pas optionnelle

En 2026, la plupart des grands fournisseurs de modèles supportent l'application native de la sortie structurée. Utilisez-la. Ne parsez pas du texte libre quand vous pouvez déclarer un schéma et faire en sorte que le modèle s'y conforme au moment de la génération.

Cela compte plus que cela ne semble. Un contrat de sortie structurée vous force à penser précisément à ce que le modèle est censé retourner. Cette précision fait remonter l'ambiguïté tôt, avant qu'elle ne devienne un bug en production. Cela rend aussi le reste du pipeline plus simple. Les composants en aval reçoivent des données typées. La validation est bon marché. La gestion des erreurs est explicite.

Sur ProPost AI, le moteur de présence LinkedIn, chaque étape de génération de contenu retournait un objet typé : texte brouillon, classification de ton, références sources. Le pipeline pouvait se brancher sur le ton, signaler les brouillons qui sortaient de la plage approuvée, et les mettre en queue pour examen, tout sans parser une chaîne. La porte d'approbation humaine ne voyait que les brouillons qui avaient déjà passé la validation du schéma. Cela gardait la queue d'examen gérable et gardait les examinateurs concentrés sur le jugement, pas le format.

Les portes d'approbation humaine appartiennent à la conception, pas à la roadmap

L'erreur la plus courante que je vois dans les builds de produits IA est de traiter la surveillance humaine comme une fonctionnalité future. Les équipes livrent d'abord le chemin automatisé et planifient d'ajouter des outils d'examen plus tard. Plus tard arrive rarement, et quand c'est le cas, c'est du travail de retrofit sur un pipeline qui n'a pas été conçu pour cela.

Constructuisez la porte en premier. Même si c'est juste une simple queue qu'un humain vide chaque matin. La porte vous force à définir ce que le modèle est autorisé à décider seul et ce qui nécessite une personne. Cette limite est une décision de produit, pas une décision technique, et elle devrait être prise explicitement.

Sur Job Hunter, le moteur quotidien de tableau d'affichage d'emplois et de sensibilisation, le pipeline de crawl-and-match fonctionnait automatiquement. Mais les brouillons de sensibilisation allaient dans une queue d'examen avant que tout message ne soit envoyé. Le modèle ne pouvait pas envoyer seul. Cette contrainte était dans l'architecture depuis le premier jour. Cela signifiait que les utilisateurs faisaient confiance à la sortie parce qu'ils l'avaient vue avant qu'elle ne sorte.

Ce qu'un consultant en développement logiciel livre réellement ici

Le rôle que je joue sur ces builds n'est pas ingénieur de prompt et pas data scientist. C'est la personne qui pense au système entier : les sources de données, les contrats de schéma, les couches de validation, les points de contrôle humains, les modes de défaillance, et les chemins de récupération.

C'est ce qu'un consultant en développement logiciel fait dans cet espace. Le modèle est un donné. L'ingénierie est le travail.

Je travaille dans les produits IA, la fintech et le secteur public, des secteurs où la sortie d'un système a des conséquences réelles. La contrainte qui a rendu chaque build difficile n'était pas le modèle. C'était l'exigence d'être juste, d'être auditable, et d'échouer gracieusement quand le modèle ne l'était pas.

Si vous construisez un produit IA et que la correction de la sortie compte, le reste de ces notes couvre les schémas spécifiques que j'utilise. Si vous voulez discuter de votre architecture, le formulaire de contact est le moyen le plus rapide de commencer.