Je conçois des systèmes d'IA
qui ne lâchent pas.

La plupart des équipes blâment le modèle. Le mode de défaillance réel est presque toujours architectural : aucun contrat d'état entre les étapes, donc l'agent perd son contexte en cours de flux ; aucune porte de validation, donc les sorties hallucinées circulent en aval sans contrôle ; aucun checkpoint, donc un plantage à l'étape 7 signifie repartir de l'étape 1. Le modèle n'est pas le maillon faible. La plomberie autour de lui l'est. Le cadre STATE existe précisément pour diagnostiquer ça.

Le LLMOps couvre la couche de déploiement et d'évaluation — hébergement de modèles, versionnement, suivi de prompts, évaluations. L'architecture de fiabilité IA est la couche en dessous : les contrats d'état, la traçabilité complète d'exécution, la tolérance aux pannes qui reprend là où elle a planté, et les portes de validation explicites qui interceptent les mauvaises sorties LLM avant qu'elles deviennent des actions réelles. Vous pouvez avoir d'excellents outils LLMOps au-dessus d'un système qui continue de défaillir silencieusement. C'est là l'écart.

L'observabilité n'est pas un tableau de bord. C'est la capacité à reconstituer intégralement ce que votre agent a fait lors d'une exécution passée précise — quel prompt a tourné, quelle version de modèle, quelle était la sortie à chaque étape, où était le flux quand il a planté ou réussi. La plupart des équipes journalisent les entrées et sorties. Ça vous dit ce qui est entré et ce qui est sorti. Ça ne vous dit pas pourquoi l'agent a pris la décision qu'il a prise à l'étape 4. Si vous ne pouvez pas répondre à cette question pour une exécution de mardi dernier, vous n'avez pas encore d'observabilité.

Lorsqu'une décision affectant un individu est prise exclusivement par traitement automatisé, les organisations doivent notifier cette personne. Sur demande, elles doivent divulguer les données personnelles utilisées, les facteurs principaux ayant influencé la décision, et le droit de la personne à une révision humaine. En pratique, cela signifie que votre système a besoin d'enregistrements de décisions structurés — pas des fichiers de log, mais des enregistrements explicites reliant chaque résultat aux données et à la version du modèle qui l'a produit. Les pénalités atteignent 10 M$ CAD ou 2 % du chiffre d'affaires mondial. Ce n'est pas une case de conformité à cocher. C'est une exigence architecturale que votre système satisfait ou ne satisfait pas.

Seul le pilier Auditable est directement lié aux exigences réglementaires comme la Loi 25 ou l'OSFI. Les quatre autres — Structuré, Traçable, Tolérant, Explicite — s'attaquent à des problèmes d'architecture qui affectent tout système d'IA en production. Non-déterminisme, dégradation du contexte, redémarrages complets après des échecs partiels, hallucinations circulant sans validation : ce ne sont pas des problèmes de conformité. Ce sont des problèmes de fiabilité en production. La réglementation est une raison de construire des systèmes avec état et observables. La raison la plus courante est que les systèmes sans ces propriétés sont coûteux à déboguer et dangereux à faire confiance.