IA contrôlée

Un modèle qui répond très correctement sur le jeu de test démo se met à produire des réponses hors-sujet en production sur des inputs inhabituels. Pas systématiquement, mais suffisamment pour qu'aucun utilisateur ne fasse plus tout à fait confiance.

Les coûts d'inférence dérapent silencieusement. Le calcul de coût total au token, fait au démarrage du projet, oublie les retries, le multi-step, les prompts qui s'allongent à mesure que le système se complexifie. Six mois plus tard, le coût mensuel observé est dix fois supérieur à l'estimation initiale.

Un incident survient en production, l'utilisateur signale un comportement aberrant. Personne ne peut reconstituer le contexte exact de la requête, ni la décision intermédiaire du modèle, ni l'outil qu'il avait appelé avec quels paramètres. La traçabilité, qu'on n'a pas pensée à la conception, est désormais impossible à rattraper sans refonte.

Une modification de prompt apparemment mineure, déployée sans suite d'évaluation, dégrade silencieusement la qualité des réponses pendant trois semaines. Le drift n'est visible qu'à travers les retours utilisateurs, lents et bruités.

Le fournisseur du modèle de base met à jour son endpoint. Le nom reste identique, le comportement change. Les équipes qui n'avaient pas pinné une version précise ne s'en aperçoivent que lorsque la dérive devient massive.

Il est supervisable en continu. Pas seulement instrumenté avec du monitoring HTTP classique, mais doté de métriques qualité observées en temps réel : distribution des scores d'évaluation automatique sur les appels en production, taux de feedback négatif, anomalies de longueur de réponse, dérive de la distribution des inputs.

L'auditabilité a posteriori est la deuxième. Chaque décision significative du système est traçable avec ses inputs, ses outputs, le modèle et la version utilisés, l'horodatage, les outils appelés en chaîne. Cette journalisation n'est pas un add-on de conformité, c'est ce qui permet de comprendre ce qui s'est passé quand un comportement étrange remonte.

Toute modification du système (prompt, configuration, version de modèle) traverse un pipeline de validation : evals automatisées contre un dataset de référence, shadow mode, déploiement canary par paliers. C'est ce qui le rend évolutif sans régression silencieuse. Aucune mise à jour ne touche la production utilisateur sans avoir été comparée au comportement précédent.

Et il doit être réversible. Un rollback de configuration est possible en quelques minutes, et il couvre aussi les données : ce qui a été écrit par la nouvelle version doit pouvoir être réconcilié avec l'état antérieur.

Quand l'IA s'insère dans un système réglementé (banque, assurance, santé, secteur public), les exigences augmentent significativement. La conformité par design devient une condition structurelle, pas une finalisation.

L'AI Act européen a classé les systèmes IA en quatre niveaux de risque. Pour ceux qui tombent en risque élevé (évaluation de solvabilité, scoring crédit, décisions d'accès à des services réglementés), les obligations couvrent la gestion des risques sur le cycle de vie, la gouvernance des données d'entraînement, la journalisation automatique des décisions, la supervision humaine effective et la documentation technique tenue à jour. Aucune de ces obligations ne s'ajoute par-dessus un système IA existant sans refonte. Ce sont des propriétés du système, pas des process organisationnels.

Aux exigences AI Act s'ajoutent celles déjà présentes dans les secteurs réglementés : RGPD intégré, secret médical, hébergement HDS, certifications ANSSI, archivage probatoire. Un système IA déployé dans un parcours d'onboarding bancaire doit absorber l'ensemble de ces contraintes, et le faire dès sa conception.

L'expérience d'exploitation des systèmes d'information critiques s'étend naturellement à l'IA. Les mêmes questions structurent le travail : que journalise-t-on, comment trace-t-on une décision, comment supervise-t-on en temps réel, comment fait-on évoluer le système sans interrompre l'exploitation. L'IA n'est qu'un nouveau type de composant à intégrer, exploiter et maintenir dans des environnements qui ne tolèrent pas l'à-peu-près.

Le choix entre modèles cloud propriétaires et modèles à poids ouverts auto-hébergés n'est pas idéologique. C'est un arbitrage entre souveraineté des données, coût réel total, capacité opérationnelle de l'équipe à gérer une infrastructure d'inférence, et complexité réelle des tâches que le système doit traiter.

Les modèles à poids ouverts (Llama, Mistral, Qwen, Gemma) sont devenus une option sérieuse pour un nombre croissant de cas d'usage. Sur les tâches simples à moyennement complexes (extraction, classification, génération de contenu standard, code de routine), ils sont comparables aux modèles frontier. Sur les tâches vraiment difficiles, l'écart reste réel, et il vaut la peine de l'évaluer sur les cas concrets de l'organisation plutôt que de généraliser à partir des benchmarks.

L'auto-hébergement devient économiquement intéressant à partir d'un volume d'inférence significatif, typiquement plusieurs millions de tokens par jour. En dessous, les API cloud restent plus économiques quand on intègre tous les coûts cachés : infrastructure GPU, compétences MLOps, mises à jour, gestion des pannes. Le coût total ne se résume pas au prix par token.

La souveraineté est le critère le plus solide en faveur de l'auto-hébergement. Pour des données couvertes par le secret médical, le secret des affaires, ou des informations sous contrainte contractuelle, l'auto-hébergement n'est pas une optimisation, c'est une exigence. Dans les environnements air-gapped (défense, industrie sensible), il n'y a tout simplement pas d'alternative.

Les architectures matures combinent souvent les deux registres : modèles légers auto-hébergés pour le volume et les données sensibles, modèles frontier via API pour les tâches complexes ponctuelles. Un router LLM oriente la requête vers le modèle adapté.

L'accuracy d'un système IA n'est pas un verdict. C'est un indicateur parmi d'autres, qui ne dit rien de la qualité de l'auditabilité, de la stabilité dans le temps, de l'adéquation aux cas d'exception, ou du coût d'exploitation.

L'évaluation d'un système IA exploitable suppose un protocole structuré, défini avant industrialisation. Ce protocole précise les cas de test attendus avec leurs sorties de référence, les erreurs tolérables et les erreurs intolérables (une formulation maladroite n'a pas le même poids qu'une action non autorisée), les seuils d'escalade à partir desquels le système doit acknowledger qu'il ne sait pas, et le comportement attendu en cas de défaillance d'un outil aval.

Le seuil d'automatisation est une décision d'architecture, pas une décision de configuration. Il matérialise un arbitrage entre fluidité, risque et coût d'exploitation. Trop bas, le système ne fait rien d'utile et chaque requête remonte en revue humaine. Trop haut, des décisions sortent en production sans contrôle approprié, et le coût d'un incident dépasse largement les gains d'automatisation.

Une bonne évaluation ne se fait pas une seule fois. Les modèles dérivent, les inputs utilisateurs évoluent, les prompts s'accumulent. Sans evals régulières en production, on n'exploite pas un système IA, on espère qu'il continue de bien répondre. Ce n'est pas la même chose.

Le travail commence avant le choix du framework, avant le choix du modèle, avant l'écriture du premier prompt. Il commence par un cadrage initial qui pose le périmètre fonctionnel du système, les garde-fous qui ne sont pas négociables, les conditions d'escalade vers une revue humaine, le protocole d'évaluation associé, et les contraintes business non négociables (AI Act, secteur réglementé, contrats partenaires). Sans ce cadrage, le choix d'un framework agentique ou d'un modèle reste largement théorique.

Vient ensuite l'instrumentation. L'observabilité du système est conçue dès la première mise en production, pas ajoutée quand un incident la rend nécessaire. Tracing distribué pour reconstituer chaque appel dans son contexte complet, métriques techniques et métriques qualité collectées en continu, signature horodatée de chaque décision significative pour permettre un audit a posteriori. Ce qui s'observe en production alimente la prochaine itération.

La mise en exploitation se fait par bascule progressive. Une modification (nouveau prompt, nouvelle version de modèle, nouvelle chaîne RAG) traverse un pipeline qui passe par des evals automatisées sur dataset de référence, puis par un shadow mode où le nouveau composant traite des requêtes réelles en parallèle de l'ancien sans servir ses réponses, puis par un déploiement canary où une fraction du trafic est progressivement basculée. Une régression à n'importe quel palier déclenche un rollback de configuration instantané.

L'exploitation pilotée vient après. Les evals tournent à intervalle régulier sur les cas en production, la distribution des inputs est surveillée pour détecter les glissements (embedding drift), les mises à jour de modèle proposées par le fournisseur sont cadrées dans le pipeline et pas absorbées en silence. La supervision humaine n'est pas une case à cocher de conformité, c'est un point de contrôle architecturé, avec des interfaces lisibles, des seuils d'alerte effectifs, et la capacité d'arrêter le système en quelques secondes si nécessaire.