L'IA est un catalyseur, pas une solution miracle pour l'optimisation

La plupart des équipes avec lesquelles j'ai travaillé arrivent au même moment. Le modèle est intégré, la démo est impressionnante, et puis les données de production arrivent et rien ne se comporte comme prévu. L'optimisation basée sur l'IA qu'elles attendaient s'avère nécessiter trois autres choses qu'elles n'avaient pas construites. J'ai moi-même vécu ce moment, plus d'une fois. Ce qui a changé mon approche, c'est d'accepter que le modèle n'est pas le produit. C'est une partie d'un système composé, et les autres parties comptent tout autant.

L'hypothèse de la solution miracle vous coûte des semaines

L'hypothèse est la suivante : remplacer un modèle, le pointer vers le problème, le regarder optimiser. C'est une hypothèse raisonnable si vous n'avez vu l'IA que dans des démos. En production, cela s'effondre rapidement. Le modèle n'a pas de mémoire de votre domaine à moins que vous ne lui en donniez une. Il ne peut pas vérifier ses propres résultats à moins que vous n'écriviez la couche de vérification. Il dérivera de sa tâche à moins que vous ne le contraigniez avec du code déterministe autour de lui.

L'industrie a changé sur ce point entre 2025 et 2026. Le terme qui s'est imposé était systèmes d'IA composés, ce qui signifie que le modèle est un nœud dans un pipeline qui inclut également des bases de données structurées, des API externes, des validateurs basés sur des règles et une logique d'orchestration. Ce cadre est utile car il vous dit où consacrer votre temps d'ingénierie. La plupart ne concerne pas le modèle lui-même.

Ce que j'ai réellement construit au lieu de simplement intégrer un modèle

Quand j'ai construit Fursa, un outil d'éligibilité aux routes de visa, le composant IA était responsable de l'interprétation du langage politique non structuré et de sa cartographie vers des critères d'éligibilité structurés. Cela semble être un problème d'IA. C'est aussi un problème de modélisation de données, un problème de moteur de règles et un problème de confiance des utilisateurs.

Le modèle seul hallucinerait les cas limites. Il produirait avec confiance des verdicts d'éligibilité pour des combinaisons de documents qu'il n'avait jamais vues. Je l'ai donc enveloppé. Un validateur déterministe a vérifié chaque résultat par rapport à une matrice connue de catégories de visa avant que quoi que ce soit n'atteigne l'utilisateur. L'IA a fait le travail d'interprétation auquel elle était réellement bonne. Le code environnant a appliqué la correction.

Ce modèle, modèle plus validateur plus couche de données structurées, est ce que je traite maintenant comme la base de référence pour tout problème d'optimisation basée sur l'IA.

Les trois composants qui rendent l'optimisation réellement efficace

Après avoir construit dans des contextes fintech, secteur public et SaaS, le système composé qui tient en production tend à avoir les mêmes trois couches.

Contexte structuré. Le modèle doit connaître des choses qu'il ne peut pas déduire du prompt. Les règles du domaine, l'historique des utilisateurs, les contraintes métier. Cela doit être conçu. Cela ne vient pas du fournisseur de modèle.

Garde-fous déterministes. Tout résultat qui touche l'argent, la conformité ou les décisions orientées vers l'utilisateur a besoin d'une vérification basée sur des règles avant son déploiement. Sur OptimalTax, une plateforme de déclaration fiscale automatisée que j'ai construite pour un client du secteur public, l'IA gérait la classification des types de revenus et des catégories de déductions. Chaque calcul a ensuite été vérifié par rapport aux règles statutaires dans une couche séparée. Cette séparation est la raison pour laquelle la plateforme a atteint 99% de précision de calcul fiscal. Le modèle n'était pas responsable de la précision. L'architecture l'était.

Boucles de rétroaction. Le modèle doit s'améliorer au fil du temps, et cela ne se produit pas automatiquement. Vous devez enregistrer les cas où il s'est trompé, les catégoriser et décider si la correction est un changement de prompt, un changement de données ou un changement de règles. La plupart des équipes ignorent cela. Elles déploient le modèle et passent à autre chose. Six mois plus tard, les résultats ont dérivé et personne ne sait pourquoi.

Où l'effort d'ingénierie va réellement

Si vous cartographiez le travail sur un vrai produit d'IA, l'intégration du modèle représente généralement dix à vingt pour cent de l'effort total. Le reste est :

• —Les pipelines de données qui alimentent le modèle avec un contexte propre et structuré
• —La logique de validation des résultats qui détecte les erreurs avant que les utilisateurs ne les voient
• —La surveillance et la journalisation qui rendent la dérive visible
• —Les chemins de secours pour quand le modèle se trompe ou n'est pas disponible
• —L'UX qui communique l'incertitude honnêtement

Sur Job Hunter, un tableau d'affichage d'emplois quotidien et un moteur de sensibilisation, la couche IA correspondait les candidats aux rôles et rédigeait les messages de sensibilisation. Le travail d'ingénierie plus difficile était l'explorateur qui gardait les données d'emploi fraîches sur 185+ pages de carrière, la logique de déduplication et le système de planification qui s'assurait que les résultats arrivaient au bon moment pour chaque utilisateur. Le modèle était peut-être quinze pour cent de la base de code. L'infrastructure autour était le produit.

La contrainte qui rend cette discipline durable

La raison pour laquelle la plupart des équipes ne construisent pas de systèmes composés dès le départ est la vitesse. Un MVP qui n'est qu'un modèle et une interface utilisateur se déploie en jours. Ajouter des validateurs, des couches de contexte structuré et des pipelines de rétroaction ajoute des semaines. Ce compromis est réel et parfois le bon choix.

Mais les équipes que j'ai vues ignorer l'infrastructure le paient d'une manière spécifique. Elles finissent par reconstruire le système six mois plus tard sous pression, avec une base d'utilisateurs qui a déjà perdu confiance dans les résultats. Cette reconstruction coûte plus que l'infrastructure d'origine n'aurait coûté.

La discipline que j'essaie d'appliquer est celle-ci : décidez tôt quels résultats sont porteurs de charge. Si le résultat pilote une décision financière, une action de conformité ou un engagement utilisateur, il reçoit le traitement composé complet. S'il s'agit d'une suggestion que l'utilisateur peut ignorer, une approche plus légère est acceptable. Pas tous les résultats d'IA n'ont besoin de la même architecture. Mais vous devez prendre cette décision délibérément, pas par accident.

Le point de départ pratique pour votre prochaine fonctionnalité d'IA

Avant d'intégrer un modèle, notez les trois choses qui rendraient ce résultat faux d'une manière qui compte. Ensuite, construisez la couche qui détecte chacun de ces modes de défaillance avant que le résultat n'atteigne l'utilisateur. Cet exercice prend généralement une après-midi. Il vous en dira plus sur vos véritables exigences d'ingénierie que n'importe quelle évaluation de modèle.

Si vous construisez quelque chose où l'optimisation basée sur l'IA est centrale au produit, je serais heureux d'examiner l'architecture avec vous. L'image complète de ce à quoi ressemble ce type d'engagement se trouve sur la page d'ingénierie, ou vous pouvez me contacter directement et décrire ce sur quoi vous travaillez.