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. Une bibliothèque commune réduit cette divergence, mais l'interprétation juridique, la couverture, l'implémentation et les mises à jour doivent encore être validées. 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. Réussir ces contrôles n'autorise pas à omettre une approbation exigée par le régime applicable. Par exemple, la règle 2210 de la FINRA exige généralement l'approbation préalable des communications de détail de ses membres par un responsable qualifié, sous réserve des exceptions prévues. Voilà à quoi ressemble la conformité-en-tant-que-code à la couche applicative. Détails à /fr/projects/leadlord.

Ce modèle peut contrôler certaines allégations et divulgations en pharma, dans les communications d'investissement, le cannabis ou l'alcool. Un régime juridique ne se résume toutefois pas à une liste finie de formulations permises. HIPAA encadre notamment l'utilisation et la communication de renseignements de santé protégés; un filtre de mots ne suffit pas à rendre conforme une communication patient. Le contexte et les devoirs hors du texte demeurent.

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. Ces traces soutiennent la révision périodique; interroger les contrôles réussis ne vérifie pas si la politique a omis une règle ou manqué une allégation trompeuse.

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. La question est de savoir comment la FINRA, l'Autorité des marchés financiers, la FDA et l'OCRI évaluent des usages précis des contrôles automatisés selon leurs règles existantes respectives. Il n'y a pas de test unique d'approbation pour toutes ces industries. L'OCRI a succédé à l'ancienne structure de l'OCRCVM en 2023.

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.