Ce qu'un ingénieur logiciel freelance fait avec un workflow IA

Un ingénieur logiciel freelance travaillant sur des produits IA en 2026 n'écrit pas principalement des prompts. Le modèle est un composant. Le reste du travail consiste à construire le workflow qui rend la sortie du modèle sûre à utiliser, vérifiable par rapport à une source, et contrôlée avant que quelque chose de conséquent ne se produise. Cette distinction compte plus qu'il n'y paraît.

L'industrie s'est développée rapidement. Les premières configurations de génération augmentée par récupération étaient simples : intégrer un document, récupérer des chunks, les insérer dans un prompt, retourner du texte. Cela fonctionnait assez bien pour les démos. Cela s'est cassé sous charge de production, sous les cas limites, et sous toute exigence que la sortie soit auditable. Les architectures agentiques, des frameworks comme LangGraph et CrewAI, et les sorties structurées natives via Pydantic ont changé ce que la production IA ressemble réellement. Le changement n'est pas cosmétique. Il change la façon dont vous concevez le système dès le premier jour.

Le modèle n'est pas le produit

Chaque produit IA que j'ai construit traite le modèle comme un composant avec un contrat, pas comme la chose qui se déploie. Le contrat est simple : étant donné cette entrée, retourner une structure valide et typée. Rien d'autre. OpenAI, Anthropic et Gemini appliquent tous le schéma JSON au niveau de l'API maintenant. Cela élimine les erreurs d'analyse qui ont plagié les premiers pipelines, où vous recevriez une réponse qui ressemblait à du JSON, n'était pas tout à fait du JSON, et cassait votre logique en aval d'une manière difficile à reproduire.

Les sorties structurées signifient que le modèle retourne soit ce que vous avez demandé, soit il échoue explicitement. L'échec explicite est mieux que la corruption silencieuse. Vous pouvez réessayer, enregistrer et alerter sur un échec explicite. La corruption silencieuse atteint l'utilisateur.

Le reste du produit est l'orchestration, la vérification et les portes. L'orchestration décide quels outils le modèle peut appeler et dans quel ordre. La vérification vérifie la sortie par rapport à une source de vérité avant qu'elle ne se déplace en aval. Les portes décident si un humain doit approuver avant que le workflow ne continue.

Ce que la vérification ressemble réellement en pratique

Sur Fursa, le workflow IA couvre l'admissibilité des itinéraires de visa dans plus de 170 pays de destination. Le modèle raisonne sur les règles d'immigration. Les règles d'immigration changent. Un modèle qui était correct le mois dernier peut être faux aujourd'hui si un pays a mis à jour sa politique de visa.

La vérification ici n'est pas optionnelle. La sortie du modèle est vérifiée par rapport au document source ou au flux de données officiel avant d'être présentée à l'utilisateur. Si la réponse du modèle ne correspond pas à la source vérifiée, le workflow ne procède pas. Il signale la divergence et l'achemine pour examen humain. L'utilisateur ne voit jamais une réponse confiante produite par un raisonnement obsolète.

C'est le modèle : la sortie du modèle est un candidat, pas un résultat. Le résultat est ce qui survit à la vérification.

Les portes humaines ne sont pas un signe que l'IA a échoué

Une porte dans un workflow est une pause délibérée. Le workflow atteint un état, vérifie si la sortie répond à un seuil, et soit continue automatiquement, soit attend un humain. Obtenir ce seuil correct est la plupart du travail d'ingénierie.

Sur Job Hunter, le moteur de sensibilisation explore plus de 185 pages de carrière quotidiennement et génère des matériaux de candidature personnalisés. Le modèle rédige. Un humain examine avant que quoi que ce soit ne sorte sous le nom de l'utilisateur. Ce n'est pas une limitation de l'IA. C'est la bonne conception. Le coût d'un mauvais email de sensibilisation est réel. Le modèle est rapide et cohérent. L'humain est le contrôle sur le contexte que le modèle n'a pas.

L'erreur que je vois le plus souvent est de traiter les portes comme un échafaudage temporaire à retirer une fois que le modèle s'améliore. Certaines portes devraient rester permanentes. Elles existent parce que la décision a des conséquences qui justifient un humain dans la boucle, pas parce que le modèle est immature.

Comment l'architecture agentique change la construction

Un pipeline de prompt unique a un mode de défaillance : le modèle retourne quelque chose de faux. Un workflow agentique en a plusieurs. Un agent appelle un outil. L'outil retourne des données. L'agent raisonne sur les données et appelle un autre outil. Chaque étape peut échouer, retourner des données inattendues, ou produire un résultat qui est localement correct mais globalement faux.

LangGraph gère cela avec des machines d'état explicites. Chaque nœud du graphe est une fonction. Chaque arête est une condition. Vous pouvez inspecter l'état à tout moment, rejouer à partir de n'importe quel point de contrôle, et ajouter une porte à n'importe quelle arête. Cette observabilité n'est pas un plus. C'est comment vous déboguez un workflow qui a fonctionné 500 fois correctement et a ensuite échoué sur l'entrée 501.

Sur GritGateway, la plateforme d'intelligence des talents couvre plus de 25 pays africains. Le workflow de correspondance exécute plusieurs agents : un pour analyser le profil du candidat, un pour noter par rapport aux critères du rôle, un pour vérifier les signaux de conformité régionale. Chaque agent a un schéma d'entrée défini et un schéma de sortie défini. Si un agent retourne en dehors de son schéma, le workflow s'arrête. Rien en aval ne voit un résultat partiel.

Cette architecture signifie également que vous pouvez remplacer un agent sans toucher aux autres. Le contrat est le schéma. L'implémentation peut changer.

Ce qu'un ingénieur logiciel freelance déploie réellement

Déployer un produit IA signifie déployer le workflow, la couche de vérification, les portes, l'observabilité et les chemins de secours. Le modèle est presque la partie facile. OpenAI et Anthropic ont rendu le modèle assez fiable pour que les problèmes difficiles soient maintenant dans le système environnant.

Le système environnant comprend :

• —La gestion d'état sur plusieurs exécutions d'agents
• —L'application du schéma à chaque limite d'agent
• —La vérification de la source avant que toute sortie ne soit présentée
• —Les portes d'approbation humaine sur les actions conséquentes
• —L'enregistrement qui vous permet de rejouer et d'inspecter n'importe quelle exécution
• —La dégradation gracieuse quand un outil ou un appel de modèle échoue

Aucun de cela n'est glamour. Tout cela est ce qui sépare une démo de quelque chose qui fonctionne en production pendant un an sans surprendre ses utilisateurs.

J'ai construit ces systèmes pour la fintech, pour des clients du secteur public, et pour des produits natifs IA. La contrainte qui a rendu chacun difficile était différente. Pour OptimalTax, la contrainte était la précision : le système atteint 99% de précision de calcul fiscal parce que chaque calcul assisté par modèle est vérifié par rapport aux propres règles de l'autorité fiscale avant d'être écrit à la déclaration. Pour Fursa, c'était la devise : les données d'immigration changent plus vite que n'importe quel ensemble de données statique ne peut suivre. Pour Job Hunter, c'était la confiance : la réputation professionnelle de l'utilisateur est en jeu avec chaque sensibilisation.

Dans chaque cas, le modèle n'a pas résolu le problème difficile. Le workflow autour du modèle l'a fait.

Si vous construisez quelque chose où la sortie du modèle a des conséquences réelles, la section travail montre comment ces modèles ont été appliqués dans différents secteurs et contraintes. Si vous voulez discuter de l'architecture d'une construction spécifique, le formulaire de contact est le moyen le plus rapide de commencer.