L'IA propose, le déterministe dispose : le pattern qui fait tenir une IA en production

Une IA en production n’est pas une IA qui décide. C’est une IA qui propose, à un système qui a le droit de dire non. Tous les systèmes d’IA que j’ai mis en production partagent ce même pattern, en trois couches.

Les trois couches du pattern

L’IA propose. OCR, modèle de langage, extraction : elle lit le document ou la donnée d’entrée, détecte, extrait, et attache un score de confiance à chaque proposition qu’elle formule. Elle n’écrit jamais directement en base de données.

Les règles métier valident. Une couche déterministe, faite de code classique, testable et auditable, vérifie chaque proposition de l’IA : formats attendus, cohérence avec les référentiels existants, seuils métier. Ce qui passe ces contrôles est accepté. Ce qui échoue est bloqué avant d’atteindre le système.

L’humain tranche. Un score de confiance trop bas, une règle métier violée, un cas jamais rencontré auparavant : la proposition part alors en file de validation, et une personne décide. Chaque décision humaine est mémorisée et réinjectée dans le système, qui s’améliore ainsi avec l’usage, sans réentraînement lourd du modèle.

Ce que ce pattern change concrètement

Dans cette architecture, l’hallucination d’un modèle n’est plus un risque diffus et incontrôlable. C’est un cas géré explicitement. Une IA qui se trompe devient une proposition rejetée par la couche de validation, jamais une donnée fausse qui atteint directement une base de production.

C’est exactement de cette façon que fonctionne, au quotidien, le pipeline documentaire que j’ai livré dans un contexte industriel exigeant. Il tient dans la durée non pas parce que l’IA ne se trompe jamais, mais parce que ses erreurs n’ont, structurellement, nulle part où aller sans passer par un contrôle.

Un détail qui n’en est pas un

Dans un tel système, la part réellement occupée par l’intelligence artificielle est petite. Tout ce qui rend le système digne de confiance relève de l’ingénierie logicielle classique : du code .NET testé, une base SQL structurée, des règles métier explicites, des tests automatisés.

La bonne question à se poser

On me demande souvent quel modèle j’utilise pour tel ou tel projet. Ce n’est presque jamais la question la plus utile. La question qui compte réellement est : que se passe-t-il quand cette IA se trompe ? Si la réponse à cette question n’est pas claire avant le premier déploiement, ce n’est pas encore un système prêt pour la production.