La conformité comme politique exécutable
La plupart des organisations traitent la conformité comme un document. Une politique est écrite, revue, signée, classée. Le système est construit séparément, et quelque part entre les deux un propriétaire de contrôle atteste que les deux sont alignés. Pour du logiciel déterministe, mis à jour selon un calendrier de releases, cet arrangement fonctionne globalement.
Sauf qu'un agent ne lit pas votre PDF de politique, et qu'il ne s'arrête pas pour votre revue trimestrielle des contrôles. Il agit sur du contexte vivant, de façon probabiliste, potentiellement des milliers de fois par jour, et il peut se comporter différemment après une mise à jour de modèle nocturne pour laquelle personne n'a déposé de demande de changement. Un régime de conformité qui vit dans un document à côté du système ne peut pas gouverner un système qui va aussi vite. L'obligation doit tourner dans le système, sinon elle ne tourne pas du tout.
C'est le basculement que l'EU AI Act, DORA et le RGPD imposent discrètement aux entreprises réglementées : la conformité cesse d'être un PDF pour devenir du code qui s'exécute, produit des verdicts auxquels le workflow doit obéir, et laisse des preuves qu'un régulateur peut reconstituer.
La politique est du code que votre équipe conformité possède
L'instinct des ingénieurs est d'enfouir la logique de conformité dans le code de l'agent. C'est le mauvais propriétaire. Les personnes responsables devant le régulateur sont votre équipe conformité, elle doit donc posséder les règles, et pouvoir le prouver.
En pratique, cela veut dire de la politique-as-code : un point de décision de politique, un moteur OPA ou Rego, que votre équipe conformité versionne, teste, signe cryptographiquement et approuve avant déploiement. Le mécanisme est proprement séparé de la décision. Les ingénieurs construisent la machinerie qui demande au moteur de politique « est-ce que cela peut continuer ? ». L'équipe conformité possède les règles qui répondent. Ni l'un ni l'autre ne peut discrètement passer outre, et la séparation est elle-même auditable.
Le dividende, c'est qu'une règle de conformité est désormais un artefact testable et versionné, avec une signature et un propriétaire, plutôt qu'une interprétation dans la tête de quelqu'un ou enfouie dans le code applicatif. Quand un régulateur demande « qui a décidé que c'était permis, et quand ? », la réponse est une version de politique signée, pas une réunion dont personne n'a fait le compte rendu.
Les politiques expirent aussi par durée de vie. Chaque règle doit être revue, réapprouvée et resignée selon un calendrier, ce qui rend l'obsolescence visible et gouvernable au lieu de silencieuse. Une règle discrètement devenue caduque cesse d'être un risque invisible pour devenir un point signalé que quelqu'un doit resigner.
Chaque gate se résout en l'un de quatre verdicts
Pour que le workflow obéisse à la politique, la politique doit parler en verdicts sur lesquels le workflow peut agir. Chaque gate de conformité se résout en l'un de quatre.
- ALLOW. Toutes les conditions sont satisfaites. L'agent continue sans intervention humaine.
- ALLOW-WITH-CONDITIONS. Partiellement satisfaites. L'agent continue sous contraintes documentées : journalisation supplémentaire, limite de périmètre ou marqueur de revue.
- DENY. Une condition ferme échoue. La transaction est bloquée, sans voie de dérogation.
- REQUIRE-HUMAN. La décision porte un poids réglementaire qui ne peut pas être délégué. L'agent se contente d'analyser ; une personne décide.
Les quatre verdicts sont ce qui convertit « le système est conforme » d'une assurance en un mécanisme. Une assurance ne se teste pas. Un verdict, si : vous pouvez pointer n'importe quelle transaction et voir quel verdict s'est déclenché, sous quelle version de politique, et pourquoi.
REQUIRE-HUMAN est le verdict porteur du travail réglementé
Des quatre, un porte le poids du cas d'usage réglementé, et il vaut la peine de le relier directement à la loi.
Au titre de l'article 22 du RGPD, une personne a le droit de ne pas faire l'objet d'une décision fondée exclusivement sur un traitement automatisé produisant des effets juridiques ou l'affectant de manière significative. La décision de crédit, le refus de sinistre, le visa de conformité : ceux-là ne peuvent pas être entièrement délégués à une machine. Dans cette architecture, ils se résolvent en REQUIRE-HUMAN par politique. L'agent prépare, vérifie et orchestre. La décision réglementée reste avec une personne.
On lit facilement cela comme une limite ajoutée pour satisfaire un juriste. C'est l'inverse. C'est la conception qui rend tout le système licite. Un agent qui prendrait lui-même la décision à conséquence serait plus rapide et illégal. Un agent qui fait tout le travail jusqu'à la décision et remet à une personne un dossier complet et étayé est à la fois rapide et licite. REQUIRE-HUMAN n'est pas la faiblesse de l'agent. C'est la frontière qui rend l'autonomie défendable partout ailleurs.
Pas de preuve, pas de décision
Une politique qui tourne n'est que la moitié de l'obligation. L'autre moitié consiste à prouver, après coup, ce qui s'est passé. Au titre des attentes de tenue de registres de l'EU AI Act (article 12), vous devez pouvoir reconstituer pourquoi une décision a été prise.
Chaque décision d'agent laisse donc une piste de preuves append-only, chaînée par hachage, sur un stockage write-once, écrite avant que la décision ne s'engage. L'ordre compte : l'enregistrement est écrit d'abord, et seulement ensuite la décision prend effet. Si la preuve ne peut pas être écrite, la décision n'a pas lieu. Le système échoue en fermé.
Cette seule règle, pas de preuve pas de décision, est ce qui rend un agent inspectable plutôt que boîte noire. L'enregistrement de toute décision capte qui a agi, sous quelle autorité, sur quelles entrées, contre quelle version signée de politique, à quel niveau d'autonomie et avec quelles preuves. Le chaînage par hachage signifie que la trace ne peut pas être discrètement modifiée après coup : l'altération brise la chaîne. Quand vos auditeurs pointent une transaction, vous leur remettez un enregistrement, pas une reconstitution.
C'est aussi la réponse à la question qu'un comité des risques pose vraiment : comment signer pour une boîte noire ? La réponse honnête est que ce n'est pas une boîte noire pour le comité. C'est un système où chaque décision arrive déjà étayée, contre une politique que l'équipe conformité a signée, avec les décisions à conséquence réservées aux personnes. Le comité signe pour un contrôle documenté et testable, pas pour une promesse.
Construit pour l'horizon réglementaire, pas seulement pour la règle du jour
Les réglementations ne restent pas immobiles, et c'est l'argument final pour rendre la conformité exécutable plutôt que documentaire.
L'article 4 de l'EU AI Act est déjà en vigueur : depuis février 2025, les organisations qui déploient de l'IA doivent s'assurer que leurs opérateurs ont une maîtrise suffisante de l'IA, et les autorités nationales ont commencé à le superviser en août 2025. Les obligations haut risque, les règles de résilience opérationnelle au titre de DORA, le droit à l'explication et les exigences de résidence des données arrivent selon leurs propres calendriers. Un régime de conformité encodé en politique signée, versionnée et expirante s'adapte à mesure que les règles évoluent, parce que changer un contrôle veut dire changer un artefact de politique, pas reconstruire le système. Un régime de conformité qui vit dans des PDF s'adapte à la vitesse d'un cycle de revue documentaire, c'est-à-dire trop lentement.
Le recadrage à emporter dans votre prochain audit n'est donc pas « sommes-nous conformes à la règle actuelle ? ». C'est : pouvons-nous exécuter nos obligations comme une politique signée et testable, prouver chaque décision par une preuve écrite avant son engagement, et changer un contrôle sans reconstruire le système ? Si la conformité vit encore dans un document à côté du système, vous attestez d'un alignement que vous ne pouvez pas démontrer sur demande.
Si vous voulez voir une obligation transformée en contrôle qui tourne sur un processus réel, prenez rendez-vous.