La conformité-en-tant-que-code s'installe en douce

Un responsable conformité dans un cabinet de gestion de patrimoine et un ingénieur principal du même cabinet font des métiers similaires. Les deux empêchent des humains de livrer des choses qui violent un livre de règles. Le livre de l'ingénieur, c'est la politique de sécurité et de style; celui du responsable, c'est le manuel marketing. Celui de l'ingénieur est lisible par machine depuis quinze ans. Celui du responsable est encore un PDF de 60 pages. Cela change, en douce, en 2026.

Ce que les ingénieurs ont compris il y a quinze ans

À la fin des années 2000, les équipes de génie logiciel ont cessé de faire confiance à la revue de code comme principale défense contre le mauvais code. Elles ont codé leurs guides de style et leurs consignes de sécurité dans des linters et des vérifications CI. ESLint, Rubocop, SonarQube, Snyk. Le livre de règles est passé d'une page wiki que personne ne lisait à un outil qui s'exécutait à chaque commit. Les réviseurs ont arrêté d'attraper les virgules manquantes et ont commencé à attraper les erreurs d'architecture.

Une fois les règles devenues code, elles étaient testables, versionnées et applicables à l'écriture. Les équipes de conformité ont regardé cela avec envie, sans les outils pour le reproduire. Jusqu'à récemment.

Les moteurs de politique qui ont grandi en silence

Des moteurs de politique-en-tant-que-code sont passés à l'adoption généralisée pendant que les équipes de conformité regardaient ailleurs. Open Policy Agent, donné à la CNCF en 2018, a été diplômé en janvier 2021, et 91 pour cent des organisations sondées disent l'utiliser, avec des déploiements en production chez Goldman Sachs, Netflix, Pinterest et T-Mobile. Les politiques OPA s'écrivent dans un langage déclaratif appelé Rego.

Kyverno est sorti diplômé de la CNCF à KubeCon Europe en mars 2026, avec des déploiements en production chez Bloomberg, Coinbase, LinkedIn, Spotify et Wayfair. HashiCorp Sentinel siège dans Terraform Cloud et bloque les changements d'infrastructure avant qu'aucune ressource cloud ne soit créée. Aucun n'a été conçu pour les responsables conformité. Tous y sont maintenant réorientés, parce que le motif qu'ils appliquent, une règle déclarative et une vérification déterministe, est ce qu'est un manuel de conformité une fois qu'on lâche le PDF.

Le déclic de 2026 : la politique à la génération

En 2024 et 2025, la conversation sur la politique-en-tant-que-code vivait presque entièrement côté infrastructure. Bloquer un plan Terraform qui ouvre un bucket S3 public. Refuser un déploiement Kubernetes sans limites. Important, mais invisible côté conformité.

Le déclic de 2026, c'est de brancher les mêmes moteurs sur l'étape de génération des outils d'IA. Une passerelle IA siège entre l'application et le modèle. Chaque prompt et chaque sortie passe par la passerelle, qui consulte une bibliothèque de politiques écrite en Rego ou YAML et qui réécrit, bloque ou annote l'appel. La boîte à outils de gouvernance des agents de Microsoft, publiée en avril 2026, prend en charge YAML, OPA Rego et Cedar pour la gouvernance d'agent à l'exécution. Pulumi a livré un soutien Rego de première classe en mars 2026.

Si chaque équipe construit sa propre vérification dans le code applicatif, les règles divergent. Si elles vivent dans une seule bibliothèque et tournent à chaque appel de modèle, elles ne peuvent pas diverger. Le moteur de politiques est à la génération IA ce qu'ESLint était à JavaScript : une vérification déterministe qui fait d'un livre de règles écrit une propriété du système. Sans cela, chaque artefact généré finit dans une file de révision humaine, et l'IA n'épargne rien.

À quoi cela ressemble en marketing réglementé

Nous avons frappé ce mur directement avec LeadLord. Un gestionnaire de patrimoine a des règles sur quels chiffres de rendement peuvent paraître sur quel ciblage d'auditoire sur quelle plateforme. Des règles sur le moment où un avertissement est exigé et son contenu. Des règles sur quels témoignages sont permis, et sur la façon de formuler le langage de risque pour un auditoire québécois versus ontarien. Vérifier à la main chaque variante générée contre ces règles, c'est le goulot qu'on essayait d'enlever. Nous avons codé les règles une seule fois dans un fichier de politique lisible par machine, exécuté la politique à la génération, exécuté de nouveau au post-contrôle, et refusé de livrer toute variante qui ne passait pas les deux. L'équipe conformité écrit la politique. La personne au marketing livre les campagnes. Personne ne révise chaque variante à la main. Voilà à quoi ressemble la conformité-en-tant-que-code à la couche applicative. Détails à /fr/projects/leadlord.

La même forme fonctionne pour les allégations médicales dans le contenu pharma, le langage de divulgation dans les lettres d'investissement, la formulation conforme à HIPAA dans les communications patients, et la copie publicitaire en cannabis et alcool. Chaque verticale réglementée a la même structure : un livre de règles fini et un flux infini d'artefacts. Un problème en forme de moteur de politiques.

Le motif à trois couches

À travers les implémentations qui se livrent aujourd'hui, les mêmes trois couches reviennent.

La première couche, c'est la bibliothèque de politiques lisible par machine, soignée et versionnée par la conformité. L'unité de travail est le fichier, pas la réunion. Les responsables écrivent les règles dans un format structuré, les exécutent contre des artefacts historiques, et comparent un changement contre la politique du dernier trimestre.

La deuxième couche, c'est l'outil de génération qui consulte la bibliothèque à chaque étape. La passerelle IA, l'agent LLM, le copilote intégré, tous lisent depuis le même fichier. Une ébauche qui échoue à la politique n'atteint jamais le réviseur; le modèle révise, demande clarification, ou refuse.

La troisième couche, c'est la vérification déterministe a posteriori qui garde la sortie. Une fois le modèle terminé, une seconde passe exécute la politique contre l'artefact final. L'audit devient un effet secondaire du flux. Chaque artefact porte une trace de la version de politique contre laquelle il a été évalué et des règles qu'il a passées. La révision trimestrielle devient une requête sur base de données, pas un échantillon tiré au hasard.

Ce qu'il faut surveiller pendant que la pile se stabilise

Deux choses bougent encore. D'abord, les langages de politique. Rego, Cedar, YAML et une poignée de cadres spécifiques à un domaine sont tous en course. Le motif d'un seul moteur qui gagne par domaine (Terraform a eu Sentinel et OPA, Kubernetes a eu Kyverno) suggère que la même chose arrivera pour la génération IA, mais ce n'est pas encore le cas. Ensuite, la position du régulateur. Est-ce que la FINRA, l'Autorité des marchés financiers, la FDA et l'OCRI accepteront la politique-en-tant-que-code comme diligence raisonnable de premier passage, ou insisteront pour qu'un humain licencié lise chaque artefact peu importe. Le motif ne se déverrouille pleinement que si le régulateur l'autorise.

Le signal encourageant, c'est que les ingénieurs et la conformité travaillent du même primitif. Les règles sont code. Ce qui se construit par-dessus est la partie intéressante.