CodeTheLaw : traduire des obligations MiCA en applications avec des agents IA

Où s'arrête la règle, où commence l'interprétation. J'ai conçu une chaîne d'agents qui a transformé des obligations de MiCA en applications web, puis j'ai fait confronter chaque citation au texte officiel. Ce que cet audit a trouvé, et ce qu'il ne pouvait pas trouver, dit beaucoup de la manière de confier du travail réglementé à des agents.

Le pari

Tout le monde parle de MiCA, le règlement européen sur les marchés de crypto-actifs. Peu l'ont lu en entier. Certains l'ont déjà traduit en code ou en outils de conformité, mais rarement de façon simple et visuelle, qui permette de voir ce qui est en jeu dans chaque article.

CodeTheLaw part de là. Un agent lit un article de MiCA, en extrait une obligation précise (un seuil, un délai, un calcul), écrit une application TypeScript qui l'implémente, la teste et la déploie. Le site en présente aujourd'hui 28 : 27 rattachées à MiCA et une au règlement voisin sur les transferts de fonds, la « Travel Rule ». Elles vont du droit de rétractation sous 14 jours au calcul des fonds propres d'un émetteur de jetons se référant à un ou des actifs. Les fiches existent en français, en anglais et en allemand ; les démonstrations sont en anglais.

CodeTheLaw est un projet personnel, un terrain d'expérimentation. Je n'ai pas codé ces applications à la main : j'ai conçu la chaîne qui les a écrites, puis le dispositif qui les vérifie. Ce projet met à l'épreuve ce que je fais chez GTB : découper un processus métier en tâches vérifiables, orchestrer des agents de code, déployer, et surtout construire les contrôles qui séparent un démonstrateur crédible d'un outil fiable. Le résultat le plus intéressant n'est pas le catalogue, c'est la frontière qu'il rend visible entre ce qu'un agent peut traduire seul et ce qui demande un jugement.

Extrait du catalogue CodeTheLaw, capturé le 9 octobre 2026. Cliquer sur l’image pour l’agrandir.

Partir d'une obligation, pas d'un règlement

Demander à un agent d'« implémenter MiCA » ne produit rien d'utile. Le règlement compte 149 articles, renvoie à des normes techniques qui n'existaient pas encore lors de son adoption, et mêle des règles chiffrées à des principes généraux. On ne peut ni le tester ni le vérifier d'un bloc.

La chaîne travaille donc à l'échelle d'une obligation. Prenons l'article 14, paragraphe 3 : lorsqu'une offre au public de crypto-actifs est annulée, l'offreur doit veiller à ce que les fonds collectés soient restitués au plus tard 25 jours calendaires après la date d'annulation.

Cette phrase se décompose sans ambiguïté :

• un événement déclencheur : l'annulation de l'offre, à une date donnée ;
• un périmètre : les crypto-actifs autres que les jetons se référant à un ou des actifs et les jetons de monnaie électronique ;
• une obligation : restituer les fonds collectés ;
• un délai : 25 jours, calendaires et non ouvrés.

Chacun de ces éléments devient une donnée, une condition ou un calcul de date. Le test s'écrit presque tout seul : une annulation au 1er mars et un remboursement au 26 mars passent ; un remboursement au 27 mars échoue. Surtout, chaque élément du code renvoie à une phrase précise du texte, ce qui le rend vérifiable par quelqu'un qui ne lit pas le TypeScript.

C'est le cas favorable. Une bonne partie de MiCA s'y prête : des seuils (une offre adressée à moins de 150 personnes par État membre, ou d'un montant total d'au plus 1 million d'euros sur douze mois, dispense de certaines obligations liées au livre blanc), des délais (14 jours de rétractation, notification du livre blanc au moins 20 jours ouvrables avant sa publication), des formules (les fonds propres d'un émetteur de jetons se référant à un ou des actifs, dont on reparlera).

Même une règle chiffrée demande des conventions. Le POC sur les fonds propres calcule la réserve moyenne « des six mois précédents » sur une fenêtre de 180 jours, et il signale cette approximation. Traduire, c'est aussi choisir, et le dire.

La chaîne, et ce que chaque étape contrôle

Du 22 mai au 6 juillet 2026, une routine d'agent de code, pilotée par un fichier d'instructions, a choisi une obligation non encore couverte, produit l'application et ses tests, fait relire le tout par un agent de revue, puis l'a versée dans le site par un commit de synchronisation automatique. Elle a produit 32 applications. Pendant cette phase, je suivais la production et contrôlais la cohérence d'ensemble : périmètre, déploiement, doublons. Une campagne de vérification systématique, du 24 au 28 septembre, a ensuite confronté chaque citation et chaque valeur au texte officiel du règlement (UE) 2023/1114.

Cette répartition rend la question utile très nette : pas « est-ce vérifié ? », mais « qu'est-ce que chaque étape vérifie exactement ? ».

Schéma GTB du processus décrit dans cet article. La vérification systématique est intervenue après la phase de génération. Cliquer sur l’image pour l’agrandir.

Les deux lignes qu'on surestime le plus sont les tests et la revue automatique. Des tests écrits par l'agent qui a écrit le code, à partir de sa propre lecture du texte, ne forment pas un oracle indépendant : si la lecture est fausse, le code et le test le sont ensemble, et le test passe. Une seconde revue peut détecter des erreurs, mais quand elle part des mêmes sources et des mêmes hypothèses, ses erreurs peuvent être corrélées avec celles du générateur.

Avant cette vérification, les 32 applications compilaient, passaient leurs tests et portaient toutes un statut de revue contenant « pass » : 25 « pass », 4 « self-review-pass », 3 « conditional_pass ». Pour le POC sur les réclamations, la note du relecteur affirmait : « All thresholds correct (5/15/35 business days) ». On verra qu'aucun de ces chiffres ne vient de MiCA. J'ai depuis retiré ces badges du site : ils reflétaient l'auto-évaluation de l'agent générateur, pas la qualité des POC.

Ce que la vérification a trouvé

Les écarts relevés se rangent en deux catégories très différentes. Les premiers sont des erreurs d'adresse : une partie des références pointait vers le mauvais article, par exemple l'article 22 au lieu de l'article 35 pour les fonds propres. C'est le défaut le plus visible et le moins grave, puisque le contenu décrit était le plus souvent juste ; un script fait désormais échouer l'intégration dès qu'une référence pointe vers un article, un paragraphe ou un point inexistant. Les seconds sont plus instructifs, parce qu'ils passent avec la bonne citation.

Une formule incomplète. L'article 35, paragraphe 1, fixe les fonds propres minimaux d'un émetteur de jetons se référant à un ou des actifs au plus élevé de trois montants : (a) 350 000 euros, (b) 2 % du montant moyen de la réserve d'actifs, (c) un quart des frais généraux fixes de l'année précédente. Le POC ne calculait que les deux premiers. Pour un émetteur dont la réserve moyenne est de 20 millions d'euros et les frais fixes de 4 millions, il affichait 400 000 euros ; le minimum de base exigé par le règlement est de 1 million. Le code exécutait correctement une formule incomplète, et ses tests le confirmaient. L'agent de revue l'avait validé. Une vérification des citations ne suffit pas à le voir : même avec la bonne adresse, il faut relire la formule elle-même.

État actuel du démonstrateur des fonds propres, capturé le 9 octobre 2026. Cette capture illustre l’interface, pas une validation juridique de tous ses calculs. Cliquer sur l’image pour l’agrandir.

Une obligation mal orientée dans le temps. Le POC sur la modification des livres blancs annonçait qu'il fallait notifier l'autorité « dans les sept jours ouvrables ». L'article 12, paragraphe 2, exige l'inverse : notifier le livre blanc modifié au moins sept jours ouvrables avant sa publication. Le chiffre était bon, l'article aussi ; c'est le point de départ du délai qui avait basculé.

Un périmètre à préciser. Deux applications de connaissance client relevaient du droit de la lutte contre le blanchiment, pas de MiCA. Je les ai retirées, avec deux doublons : le catalogue compte aujourd'hui 28 applications.

Ce qu'une vérification des citations ne pouvait pas trouver

Deux POC posaient un problème d'une autre nature.

Le POC sur les réclamations clients appliquait des délais précis : accusé de réception sous 5 jours ouvrés, réponse sous 15 jours, extensible à 35. Or l'article 71 demande un traitement « rapide, équitable et cohérent » des réclamations, et d'en communiquer l'issue « dans un délai raisonnable ». Les valeurs 15 et 35 correspondent à celles de la directive sur les services de paiement (DSP2, article 101) ; le 5 ne vient pas de ce texte. L'agent a vraisemblablement importé une règle voisine, sans le signaler.

Le POC sur le remboursement des jetons de monnaie électronique suivait un délai d'un jour ouvré. L'article 49 impose de rembourser « à tout moment et à la valeur nominale », sans fixer de délai de traitement. Un délai exprimé en jour ouvrable existe bien dans MiCA, mais à l'article 70, paragraphe 3, pour une autre obligation : les fonds des clients doivent être placés auprès d'un établissement de crédit ou d'une banque centrale au plus tard à la fin du jour ouvrable suivant leur réception.

Un contrôle purement mécanique, qui vérifie qu'une référence existe et traite du bon sujet, est ici satisfait : l'article 71 traite bien des réclamations, l'article 49 du remboursement. C'est la relecture de la disposition elle-même qui a montré que les chiffres n'y figuraient pas. Les deux délais sont désormais présentés comme des paramètres de politique interne, explicitement étiquetés comme tels.

La leçon : une vérification qui part du code pour remonter au texte (« l'article cité existe-t-il, et traite-t-il du sujet ? ») laisse passer ce genre d'ajout. Il faut aussi la vérification inverse : chaque valeur du code a-t-elle une source dans le texte ?

Et il faut chercher cette source au-delà du règlement lui-même. En préparant cet article, j'ai relu le règlement délégué (UE) 2025/294, adopté en application de l'article 71, paragraphe 5, de MiCA, qui précise la procédure de traitement des réclamations. Son article 4 demande d'accuser réception de la réclamation « dans les meilleurs délais », sans chiffre ; mais son article 6 impose de communiquer la décision dans un délai de deux mois au plus à compter de la réception de la réclamation, sauf situation exceptionnelle motivée. Le « silence » de MiCA sur ce point n'en était donc pas un : il était comblé par un texte de niveau 2 que la chaîne n'avait pas lu. Le même texte demande d'ailleurs au prestataire de fixer et de publier son propre calendrier de traitement (article 1er, paragraphe 2, point e)). Des délais internes comme 5, 15 et 35 jours ouvrés y ont donc leur place, à condition de respecter, pour chaque réclamation, le plafond de deux mois courant à compter de sa réception ; leur conformité ne se déduit pas d'une conversion approximative en semaines. Depuis le 9 octobre, la fiche du POC et la page de correspondance mentionnent ce plafond, en précisant qu'il vient de ce règlement délégué et non de MiCA lui-même.

Règle, standard, silence

Ces erreurs ne sont pas réparties au hasard. Elles suivent la nature du texte traduit, et c'est sans doute l'enseignement principal du projet. Dans MiCA, comme dans la plupart des règlements, on trouve trois sortes de dispositions.

Les règles. Un seuil, un délai, une formule : 25 jours calendaires, 350 000 euros, le plus élevé de trois montants. Elles se traduisent en code de façon directement vérifiable, à condition d'expliciter les conventions : calendrier, unités, point de départ. Les erreurs y sont des oublis ou des glissements, comme le troisième terme de l'article 35 ou le sens du délai de l'article 12, et une relecture attentive du texte les attrape.

Les standards. « Honnête, équitable et professionnel », « délai raisonnable », compétence et honorabilité des dirigeants. Le texte fixe une exigence qualitative et laisse son appréciation aux entreprises et aux autorités. Un programme ne peut pas les « implémenter » ; il peut seulement proposer une manière de les opérationnaliser. Le POC sur l'aptitude des dirigeants (article 68, paragraphe 1) le fait correctement : il traduit l'exigence en grille de score et précise que ses seuils sont une interprétation illustrative, pas une exigence réglementaire. C'est exactement ce qu'il faut faire : rendre l'interprétation visible au lieu de la présenter comme du droit.

Les silences. Là où le texte ne dit rien, l'agent comble le vide. Il ne le fait pas au hasard : il emprunte une règle plausible à un texte voisin, un délai de paiement, un usage de place. C'est la catégorie la plus dangereuse, parce que le résultat a l'air juste et cite le bon article. Les délais des réclamations et du remboursement en sont deux exemples. Encore faut-il s'assurer que le silence est réel : MiCA renvoie à des dizaines de normes techniques, et un silence du règlement peut être comblé par l'une d'elles, comme le plafond de deux mois fixé pour les réclamations par le règlement délégué 2025/294.

Cette distinction nuance l'hypothèse de départ du site, selon laquelle la réglementation financière pourrait être exprimée de manière équivalente en logiciel. Pour les règles, oui, à condition de vérifier. Pour les standards, le logiciel peut porter une interprétation assumée, pas une équivalence. Pour les silences, aucune traduction n'est neutre : quelqu'un doit décider, et ce quelqu'un ne devrait pas être l'agent.

Ce que j'ai délégué, ce que j'ai gardé

J'ai délégué aux agents la production : choisir une obligation, écrire l'application et ses tests, la déployer, traduire les descriptions, réparer les liens cassés. Sur ces tâches, les erreurs de compilation ou de déploiement se détectent vite. Les erreurs de sens, elles, demandent des contrôles construits pour les chercher.

J'ai gardé trois choses :

1. Le périmètre. Décider ce qui entre dans le catalogue, retirer les doublons et ce qui sort du règlement.
2. La confrontation au texte. Les passes de vérification ont été exécutées par des agents, mais c'est la relecture de leurs résultats, disposition par disposition, qui a permis d'identifier les erreurs, en plusieurs itérations.
3. L'étiquetage de l'interprétation. Savoir quand une valeur vient du texte et quand elle vient d'un choix, et le dire.

Le projet a fait évoluer ma méthode sur deux points. Une référence, aussi structurée soit-elle, doit elle-même être vérifiée contre la source officielle, et de façon automatique. Et la confrontation de chaque valeur chiffrée au texte doit faire partie de la chaîne, avant intégration, au lieu de relever d'une vérification séparée.

Le troisième point est le plus subtil. Un agent sait très bien produire une valeur plausible ; il ne signale pas spontanément qu'elle ne vient pas du texte, et un second agent chargé de le relire ne le signale pas davantage. La règle que j'en tire : toute valeur chiffrée dans le code doit pointer vers une phrase du règlement ou de ses textes d'application, ou être explicitement marquée comme un paramètre de politique interne.

Un POC n'est pas une conformité

Chaque application de CodeTheLaw porte la mention « démonstration éducative uniquement », précisant qu'elle ne constitue pas un conseil juridique, et ce n'est pas une précaution de forme. Pour passer d'un POC à un outil de conformité, il manquerait au moins :

• une revue juridique de chaque règle implémentée, par quelqu'un dont c'est le métier ;
• les normes techniques et orientations qui précisent MiCA (normes de l'ABE et de l'ESMA, positions des autorités nationales), souvent plus déterminantes que le texte lui-même pour les chiffres, comme le montre le délai de deux mois des réclamations ;
• une traçabilité règle par règle, de la phrase du texte à la ligne de code et au test, maintenue à chaque évolution du droit ;
• le contexte de l'entreprise : son statut, ses services, ses choix d'organisation, qui déterminent quelles obligations s'appliquent et comment ;
• l'industrialisation : persistance des données, authentification, archivage durable, intégration aux systèmes existants et surveillance continue, que les démonstrateurs n'ont pas.

Ce que le projet démontre est plus modeste et, je crois, plus utile : une chaîne d'agents peut transformer des obligations réglementaires en applications exécutables, à condition de concevoir la vérification avec autant de soin que la génération.

Ce que cela dit des agents en entreprise

La leçon dépasse le droit des crypto-actifs. Dès qu'on confie à des agents un travail où l'erreur compte, trois questions décident de la qualité du résultat, au-delà du choix du modèle :

1. À quelle échelle découpe-t-on le travail ? Une obligation précise se vérifie ; « tout MiCA » ne se vérifie pas.
2. Qu'est-ce que chaque contrôle établit vraiment ? Des tests fondés sur la même lecture du texte ne constituent pas un oracle indépendant. Un statut « pass » ne mesure pas les erreurs évitées. Une citation exacte ne prouve pas que le code n'ajoute rien.
3. Où passe la frontière entre règle et interprétation, et qui la tient ? C'est là que l'humain reste indispensable, et c'est là qu'il faut le placer, avant la publication plutôt qu'après.

C'est le sens du G de GTB, pour Gouvernance, Transformation, Business : la gouvernance d'un système d'agents ne s'ajoute pas après coup, elle se conçoit en même temps que lui. Si vous cherchez à transformer un processus métier documenté en outils vérifiables, c'est ce type d'architecture que je construis avec GTB.

Les 28 applications sont consultables sur codethelaw.eu, avec la correspondance article par article ; les démonstrations sont en anglais. Le code source est disponible sur demande.

Sources

• CodeTheLaw, catalogue des POC
• Règlement (UE) 2023/1114 (MiCA), texte officiel sur EUR-Lex ; articles cités, dans une présentation article par article : art. 4, art. 8, art. 12, art. 13, art. 14, art. 35, art. 49, art. 68, art. 70, art. 71
• Règlement délégué (UE) 2025/294 sur le traitement des réclamations par les prestataires de services sur crypto-actifs, texte officiel sur EUR-Lex : art. 4, art. 6
• Règlement (UE) 2023/1113 sur les informations accompagnant les transferts de fonds et de crypto-actifs, texte officiel sur EUR-Lex
• Directive (UE) 2015/2366 (DSP2), texte officiel sur EUR-Lex, article 101