Livrer de l'IA dans des systèmes réglementés

La plupart des démos d’IA meurent au contact d’une revue de conformité. Le modèle fonctionne dans la démo ; le déploiement autour, non. Les journaux d’audit manquent, les prompts ne sont pas versionnés, la résidence des données est une réflexion après coup, et il n’y a pas de réponse à la seule question que pose chaque relecteur : qu’a décidé le système, et pourquoi ?

Livrer de l’IA dans un environnement réglementé — santé, finance, juridique — n’est pas une version plus difficile d’un chatbot. C’est un autre métier. Le modèle en représente peut-être 20 %. Les 80 % restants sont l’ingénierie ingrate qui permet à une organisation prudente de mettre réellement la chose devant des utilisateurs.

Concevoir les réponses dès le départ

On ne greffe pas la conformité sur une fonctionnalité IA terminée. Les propriétés qui intéressent un relecteur doivent être des décisions d’architecture prises tôt :

• Des prompts versionnés, pilotés par configuration. Les prompts font partie du comportement du système. Leur place est dans le contrôle de version et la configuration, pas codés en dur dans une fonction — pour pouvoir les relire, les comparer et les annuler comme tout autre changement.
• Un journal d’audit pour chaque décision. Chaque interaction IA doit écrire un enregistrement : l’entrée, la version du prompt, la sortie du modèle et ce qui a suivi. Quand on vous demandera pourquoi le système a fait quelque chose il y a six semaines, il vous faudra une vraie réponse.
• L’isolation des tenants au niveau de la base. Dans des produits santé ou fintech multi-tenants, une isolation assurée uniquement par le code applicatif est un bug qui attend de fuiter des données entre clients. Imposez-la dans la couche de données.
• Une frontière claire entre proposer et décider. Le schéma le plus sûr en environnement réglementé est une IA qui propose et un humain qui valide. Rendez cette frontière explicite dans le produit, pas implicite dans les bonnes intentions.

L’évaluation n’est pas optionnelle

Une démo prouve que le modèle peut réussir une fois. La production exige de savoir à quelle fréquence il échoue, et à quel point. Avant toute mise en ligne, nous construisons un jeu d’évaluation à partir de cas réels et mesurons dessus — pour que « l’IA s’est améliorée » soit un chiffre, pas une impression. Après le lancement, le même harnais détecte les régressions quand un modèle ou un prompt change.

Les garde-fous font partie du produit

Les entrées sont validées. Les sorties sont vérifiées par des règles avant d’atteindre l’utilisateur. Les actions sensibles sont verrouillées. Rien de tout cela n’est excitant, et c’est toute la différence entre une fonctionnalité IA qui survit à une revue de sécurité et une autre qu’on éteint discrètement après le premier incident.

C’est la version ingrate qui arrive en production

Il serait plus amusant d’écrire sur le prompting astucieux. Mais les projets qui atteignent la production dans les secteurs réglementés ne se gagnent pas sur l’ingéniosité — ils se gagnent sur la discipline autour du modèle : revue, audit, isolation, évaluation, et un humain dans la boucle là où ça compte.

Moins glamour que la démo. Et la seule version qui est livrée.