La NASA affirme avoir été la première à appliquer le concept de jumeau numérique (“Digital Twin”). Afin de mieux prédire le comportement des objets qu’elle envoyait dans l’espace, elle avait besoin d’une copie sur Terre – non seulement physique, mais aussi numérique. Certains scénarios sont tout simplement difficiles à reproduire sur Terre, mais doivent pouvoir être simulés de manière aussi détaillée que possible.  Cette approche s’est répandue dans d’autres secteurs, comme l’aéronautique, où des erreurs de conception pourraient avoir des conséquences catastrophiques, ou encore là où une méthode par essais et erreurs serait trop coûteuse ou pratiquement impossible.   

Le jumeau numérique n’est toutefois apparu sur le radar de Gartner qu’à la fin de l’année 2016. La page Wikipédia consacrée à ce sujet est aussi relativement récente, puisqu’elle a été créée en 2015, bien plus tard que celles dédiées à la réalité virtuelle (2001) et à l’Internet des objets (2007). L’idée des jumeaux numériques a toutefois rapidement gagné en popularité, aidée en cela par le programme européen Horizon 2020 qui y a vu un potentiel et a financé divers projets sur ce thème à hauteur de plusieurs millions d’euros ([1], [2], [3], [4]). En Flandre, cette opportunité a été saisie avec empressement, avec l’IMEC dans un rôle central, soutenu par un Digitaal Vlaanderen enthousiaste, sans oublier VITO, qui est également convaincu.

D’un point de vue marketing, le jumeau numérique a donc déjà fait ses preuves. Mais peut-il apporter une valeur ajoutée concrète aux administrations publiques ? Dans ce domaine également, les flux opérationnels deviennent rapidement complexes, les modifications peuvent s’avérer coûteuses, et l’on souhaite peut-être pouvoir simuler certaines choses avant de les mettre en œuvre. Dans cet article, nous examinerons ce que le jumeau numérique peut apporter dans un contexte administratif.

Définitions

Il existe de nombreuses interprétations du jumeau numérique. L’essence même du concept n’est en tout cas pas nouvelle : un système est représenté numériquement afin de pouvoir être observé, testé et amélioré sans impact direct sur son fonctionnement réel. La principale caractéristique distinctive est la synchronisation continue (ou du moins régulière) entre le système réel (l’entité cible ou target entity) et son homologue numérique. Le Centre commun de recherche de l’UE adopte un modèle de maturité qui distingue différents niveaux d’intégration ; ce n’est que dans le cas d’un échange bidirectionnel de données entre l’entité cible et le jumeau que l’on parle véritablement de jumeau. À l’échelle internationale, des efforts sont entrepris pour standardiser la terminologie.

Pour être utile, un jumeau numérique doit être développé avec suffisamment de détails. Le niveau de granularité ou de résolution variera en fonction de l’application. Le jumeau doit pouvoir représenter fidèlement l’entité cible tout au long de son cycle de vie, mais cela ne signifie pas que chaque détail doive être simulé dans les moindres détails. Dans le secteur médical, on voit apparaître des jumeaux numériques au niveau de la cellule, de l’organe, d’un individu ou de la population. Rien n’empêche non plus qu’un jumeau numérique ne constitue qu’une partie d’un système plus vaste ; il peut, par exemple, n’être élaboré que pour un seul composant critique.

On distingue deux courants de jumeaux numériques :

• Les jumeaux technologiques de haut niveau (aéronautique, industrie, infrastructure), où le jumeau est utilisé pour le diagnostic, la maintenance prédictive ou la conception itérative sur la base de données opérationnelles – à la NASA, pour la distribution d’électricité…
• Les jumeaux de systèmes d’information ou sociotechniques (villes, organisations, services), dans lesquels l’entité cible n’est pas tant une machine qu’un système complexe impliquant plusieurs parties prenantes, composé de processus, de règles, de personnes et de flux de données. C’est dans ce deuxième courant que s’inscrit le secteur public, mais c’est aussi là que les définitions deviennent floues et que le “jumeau numérique” est parfois utilisé comme terme marketing pour désigner une structure “tableau de bord + modèle“.

Alors que le flou est peut-être inévitable sur le plan politique, nous souhaitons néanmoins une interprétation plus opérationnelle dans la pratique. Nous pourrions définir un jumeau numérique administratif comme une représentation numérique de la réalité de la prestation de services, continuellement actualisée et testable. Cela inclut les processus, les dossiers et leur état d’avancement, un système applicable des règles en vigueur, ainsi que l’ensemble des flux de données nécessaires au bon fonctionnement de l’ensemble. Cela doit permettre de suivre de près la situation actuelle et de simuler à l’avance les modifications éventuelles avant leur application.

Pour un processus industriel piloté par des données de capteurs et les lois immuables de la physique, cela s’avère plus facile que pour le secteur public, où l’on traite souvent des données sensibles et où l’on dépend de règles changeant régulièrement qui laissent place à l’interprétation (voir également nos articles précédemment publiés sur les Rules As Code). Les préoccupations liées à la gouvernance des données (RGPD, etc.) peuvent compliquer la mise en place d’une synchronisation avec les données en temps réel. La logique décisionnelle est souvent étroitement liée au code des applications, ce qui complique les ajustements et les contrôles de conformité. C’est pourquoi, dans le contexte public, la mise en place d’un Digital Shadow, que l’on peut situer quelque part entre un “bête” modèle et un véritable jumeau synchronisé, constitue souvent déjà un exploit en soi.

Projets phares

En Europe, les projets de jumeaux numériques les plus marquants concernent principalement le climat et la science :

• Destination Earth ou DestinE combine des données à grande échelle provenant de satellites (météorologiques) et de Copernicus dans un lac de données. Sur cette base, deux jumeaux numériques ont vu le jour : Climate Change Adaptation (long terme) et Weather-induced Extremes (court terme). Pour ce faire, ils ont développé leur propre Digital Twin Engine. Le projet se poursuit, l’objectif étant de faciliter davantage les “applications en aval” d’utilisateurs externes qui peuvent approfondir certains aspects ou des questions de recherche spécifiques. Tout cela doit être partagé via une plateforme unique coordonnée par l’ESA.
• Le projet EDITO vise à atteindre des objectifs similaires, mais dans le domaine des océans.
  À cette fin, les données d’EMODnet et de Copernicus sont mises en commun. L’accès passe par un Datalab qui propose également une série d’autres modules et services, et les applications qui y sont développées peuvent être hébergées sur la plateforme numérique de l’initiative.
• Plusieurs use cases sont également répertoriés dans le cadre du projet de recherche interTwin, récemment achevé (et financé par l’Union européenne), qui visait à développer une architecture quelque peu standardisée avec des composants réutilisables pour les jumeaux numériques. Ils ont abordé le sujet plutôt sous l’angle du CERN, et indépendamment des deux initiatives mentionnées précédemment. Au fil du temps, ils ont toutefois pris conscience de l’existence les uns des autres et une interopérabilité potentielle avec le projet DestinE, lié à l’ESA, a déjà été étudiée.

Dans un contexte administratif, les données issues de satellites ou d’accélérateurs de particules nous sont moins utiles. En raison des exigences en matière de gouvernance, l’accent est plutôt mis sur une interopérabilité et un échange de données corrects, conformément à tous les cadres juridiques en vigueur. À cet égard, les initiatives européennes les plus utiles sont peut-être encore les Espaces européens des données – pour un “jumeau politique”, par exemple, l’Espace européen des données juridique. Il existe également des points communs avec le concept de bacs à sable réglementaires tel qu’il apparaît notamment dans le Règlement pour une Europe interopérable ou, plus récemment, dans la législation sur l’intelligence artificielle : un jumeau numérique administratif peut remplir le rôle d’un tel bac à sable s’il existe de bons mécanismes de développement et d’évaluation de scénarios.

Use Cases administratifs

Avant de nous lancer dans des secteurs complexes tels que les soins de santé et la sécurité sociale, nous devons tout de même nous demander si les jumeaux numériques peuvent apporter une réelle valeur ajoutée à ce qui existe déjà aujourd’hui – car l’engouement en soi n’apporte rien.

Use Case 1 : Simulation des politiques et de leur impact opérationnel

En matière de modélisation de politiques pour la sécurité sociale, il existe par exemple déjà une base solide avec le modèle de microsimulation EUROMOD, dont la variante belge s’appelle BELMOD. Il s’agit de microsimulations statiques dans lesquelles des données très détaillées sont combinées à des règles codifiées, permettant de simuler des réformes des paramètres de la sécurité sociale (cotisations, allocations…). Ces études sont généralement menées dans les universités. On peut se faire une idée de ce que cela implique via EUROMOD Online.

D’une certaine manière, ce type de modèle s’apparente déjà à un jumeau numérique pour la politique sociale, mais il lui manque encore deux éléments essentiels :

• des liens en temps réel avec les données administratives : cela permettrait de simuler les effets budgétaires et distributifs sur la situation actuelle, plutôt que sur des données obsolètes datant de plusieurs années.
• des informations sur les processus de prestation de services (délais de traitement des dossiers, capacité de traitement…) : cela permettrait également d’évaluer l’impact opérationnel des réformes sur les services exécutifs.

Il ne serait pas du tout simple d’ajouter cela : les données en question sont de nature très sensible. L’utilisation des données réelles comme source de données en temps réel pour les simulations nécessiterait certainement une anonymisation poussée (conformément au RGPD), en plus d’une série d’autres mesures de sécurité. Il s’agit là d’un exercice complexe en soi, qui pourrait également entraîner la perte d’informations utiles.

Le statut d’une personne au sein de la sécurité sociale est en outre déterminé par une succession d’événements susceptibles d’avoir des répercussions à long terme et d’interagir entre eux (emploi, licenciement, maladie, accident, pension, naissance d’un enfant…). Pour être vraiment utile, un jumeau devrait pouvoir modéliser l’ensemble du parcours d’un individu au sein du système. Non seulement le statut individuel, mais aussi celui des dossiers (les délais sont-ils respectés ?) et de l’administration (y a-t-il un retard dans le traitement ?) évoluent au fil du temps.

Si, aujourd’hui, une bonne ombre numérique (digital shadow) d’un service est déjà disponible, l’ajout de données évolutives relatives à la répartition de la charge de travail, aux capacités, à l’avancement des dossiers… permettrait de franchir une nouvelle étape, comme une simulation du flux de dossiers. De telles simulations sélectives peuvent servir à des analyses contrefactuelles (“et si”) qui permettent de mieux évaluer l’impact d’un changement (au niveau organisationnel ou réglementaire). À l’inverse, on peut également y voir un cadre pour des tests de régression : les calculs effectués sur des échantillons représentatifs peuvent être répétés chaque fois qu’un élément change, afin de localiser l’impact le plus important.

Use Case 2 : Planification organisationnelle dans les soins de santé

L’administration des soins de santé a d’autres priorités : le suivi des patients et des consultations est urgent, l’affectation du personnel et des ressources est un casse-tête de planification complexe, sans parler des divers remboursements et assurances… Pour évoluer vers le jumeau numérique, les espaces européens des données de santé pourraient jouer un rôle important, tout comme les nouvelles solutions que l’on s’efforce actuellement de mettre au point pour l’utilisation secondaire des données de santé.

Nous sommes encore loin du rêve des soins de santé optimisés individuellement sur la base d’un jumeau numérique personnel du patient, une idée qui s’accompagne d’ailleurs de nombreux risques non négligeables sur les plans de l’éthique et de la confidentialité. À plus court terme, les possibilités se situent plutôt au niveau de l’organisation. En ajoutant à une ombre numérique existante des données relatives aux admissions, aux listes d’attente, à l’affectation du personnel et à l’activité, il devient possible de mieux absorber les évolutions stratégiques et opérationnelles.

La mise en œuvre: une opération couteuse ?

Pour rester concentrées sur ce qui est possible aujourd’hui ou à court terme, les administrations peuvent s’inspirer des “piles de référence” de composants technologiques, développées dans le cadre de jumeaux numériques existants. Nous en avons déjà mentionné quelques-unes précédemment et ne les répéterons pas ici.

Un jumeau numérique doit pouvoir contenir une représentation de l’état actuel d’un système et traiter les événements qui ont un impact sur celui-ci. À cette fin, dans le cadre des initiatives européennes FIWARE (Future Internet), le groupe de travail Context Information Management au sein de l’ETSI (l’Institut européen des normes de télécommunications) a développé le standard et l’API NSGI-LD.  Il semble toutefois que ce standard ne soit pas encore très répandu en dehors de son propre réseau composé principalement des initiatives Smart City et IoT.

Les systèmes administratifs ne se résument pas à de simples décisions. Les processus impliquent des interactions, des documents et, parfois, une certaine marge d’appréciation. Les standards ouverts issus du business process management s’avèrent ici utiles. DMN (decision modeling), BPMN (business processes) et CMMN (case management) sont complémentaires et permettent de modéliser ces aspects. Des extensions voient également le jour à partir de ces initiatives, comme Constraint DMN (cDMN), développé à la KULeuven, qui permet une logique plus complexe. Nous pouvons alors composer un jumeau numérique à partir d’un moteur de décision DMN qui calcule “ce que disent les règles” (c’est là que l’approche Rules As Code peut éventuellement trouver sa place), enrichi de couches qui prennent en charge les processus et le flux de dossiers (statut, délais, documents de support), et enfin d’une synchronisation régulière pour pouvoir mettre à jour l’état opérationnel (ou le contexte). Cette approche est compatible avec le modèle de maturité du CCR (model -> shadow -> twin).

Les jumeaux numériques ne sont pas coûteux parce qu’ils intègrent beaucoup de visualisation ou des capacités de reporting. Ils sont coûteux parce qu’ils constituent une réplique du système cible qui, tout comme l’original, doit continuer à fonctionner correctement au fil du temps. Pour aller au-delà de l’engouement, ils nécessitent un investissement constant en maintenance. Ces coûts récurrents comprennent au moins les éléments suivants :

• surveillance et validation : un jumeau numérique doit suivre chaque modification apportée au système cible avec la plus grande précision possible, ce qui nécessite des mises à jour régulières ;
• maintenance des règles et traçabilité : cela représente un coût important, surtout lorsque les règles changent fréquemment. C’est là que la gestion des versions, les suites de tests et la gestion des changements jouent un rôle ;
• fonctionnement des pipelines de données et interopérabilité : cela englobe également la sémantique, le contrôle des accès, la qualité des données, la précision et la sécurité.
• confidentialité et conformité : indispensables, certainement pour les systèmes qui traitent des données à caractère personnel (santé, revenus, famille).

Pour un cas d’utilisation administratif, la meilleure première étape consiste donc à mettre en place de manière systématique ce que l’on pourrait appeler une “ombre numérique respectueuse de la vie privée” : initialement limitée à des fonctionnalités de surveillance et de répétition, avec un contrôle d’accès strict et une minimisation des données. On peut ensuite envisager une extension à des simulations sur des jeux de données anonymisées ou synthétiques. Une éventuelle synchronisation en temps quasi réel avec les données du système cible réel, afin de créer un véritable jumeau numérique, ne peut intervenir qu’à la fin du processus et s’avère souvent assez complexe à mettre en œuvre.

Conclusion

Un jumeau numérique est-il la solution adéquate, ou existe-t-il une alternative plus simple ?
En résumé, les jumeaux numériques ne doivent être envisagés que si toutes les conditions suivantes sont remplies (sinon, une autre approche peut s’avérer plus efficace et mieux adaptée) :

• Le système cible modélisé est dynamique : les résultats dépendent de situations en constante évolution (flux de dossiers, files d’attente, cycle de vie des événements), et pas uniquement de contrôles d’éligibilité ou de formulaires.
• Il est possible d’identifier des sources de données de référence et de maintenir une synchronisation continue. Sans mises à jour régulières avec des données opérationnelles, on construit un modèle et non un jumeau.
• Les simulations mènent à de vraies décisions. Si l’organisation ne dispose pas d’une liberté suffisante pour intervenir (modification des politiques, adaptation du flux de dossiers, priorisation, tâches du personnel…), une série de tableaux de bord suffira probablement.
• Il existe un plan crédible d’audit et de contrôle qualité permanent. Cela ne doit pas être une considération a posteriori, mais un critère d’acceptation. Il est inutile de construire un jumeau qui se détériore plus vite que le système cible.
• L’environnement juridique et de conformité est compatible. Si des données à caractère personnel sont impliquées, le RGPD et l’AI Act peuvent entraîner des obligations qui influencent fortement la faisabilité et le coût. Cela peut limiter un jumeau à un simple système de test amélioré au lieu d’apporter une véritable contribution à l’automatisation opérationnelle.

Un système non jumeau peut également s’avérer utile : avec des règles codifiées, un harnais de test et une surveillance, on dispose déjà d’une configuration transparente permettant d’obtenir toutes sortes d’informations, sans la complexité ni le coût d’une synchronisation complète ou d’une infrastructure de simulation. Dans un environnement administratif, un tel modèle de politique peut déjà répondre à de nombreux besoins sans jumeau numérique opérationnel, même si cela risque d’être décevant pour ceux qui aiment s’appuyer sur des mots à la mode.

Van het concept Digital Twin claimt de NASA dat zij het als eersten toepasten. Om beter het gedrag te kunnen voorspellen van wat ze de ruimte in schoten, had men nood aan een kopie op aarde – niet alleen fysiek, maar ook digitaal. Sommige scenario’s zijn nu eenmaal moeilijk na te bootsen op aarde, maar moeten wel zo gedetailleerd mogelijk doorgerekend kunnen worden. Deze aanpak vond navolging in andere industrieën, zoals de luchtvaart, waar ontwerpfouten catastrofale gevolgen zouden kunnen hebben, of waar een trial-and-error methodiek te duur of praktisch onmogelijk zou zijn.

Digital Twin verschijnt echter pas als onderwerp op de radar van Gartner eind 2016. Ook de Wikipedia-pagina over het onderwerp is een relatief recent gegeven, aangemaakt in 2015, veel later dan die over Virtual Reality (2001) en Internet of Things (2007). Het idee van Digital Twins werd echter snel populair, daarbij geholpen door het Europese Horizon-2020 programma dat er brood in zag en verschillende projecten rond het thema financierde voor miljoenen euro’s ([1], [2], [3], [4]). Alvast in Vlaanderen heeft men die kans gretig gegrepen, met IMEC in een centrale rol, bijgestaan door een enthousiast Digitaal Vlaanderen, en ook VITO is overtuigd.

Marketinggewijs heeft de Digital Twin zijn waarde dus alvast bewezen. Maar kan het een concrete meerwaarde zijn voor publieke administraties? Ook daar worden workflows snel complex, kunnen wijzigingen duur zijn, en wil men misschien éen en ander kunnen simuleren alvorens het effectief te implementeren. In dit artikel onderzoeken we wat de Digital Twin kan betekenen in een administratieve context.

Definities

Er bestaan nogal wat verschillende interpretaties van Digital Twin. De essentie is alleszins niet nieuw: een systeem wordt digitaal weergegeven zodat het kan worden geobserveerd, getest en verbeterd zonder de daadwerkelijke werking direct aan te tasten. Het belangrijkste onderscheidende kenmerk is de continue (of in ieder geval regelmatige) synchronisatie tussen het reële systeem (de ‘doelentiteit’ of ‘target entity’), en zijn digitale tegenhanger. De EU JRC adopteert een maturiteitsmodel dat verschillende niveau’s van integratie onderscheidt; enkel in het geval van tweerichtings-datauitwisseling tussen target en twin wordt echt van een twin gesproken. Op internationaal vlak worden pogingen ondernomen tot standaardisering van terminologie.

Om nuttig te kunnen zijn moet een Digital Twin uitgewerkt zijn in voldoende detail. Al naargelang de toepassing zal het niveau van granulariteit of resolutie variëren. De twin moet de doelentiteit gedurende diens volledige life cycle getrouw kunnen weergeven, maar dat betekent niet dat elk detail tot in de puntjes gesimuleerd moet zijn. In de medische sector zien we digital twins opduiken op het niveau van de cel, van het orgaan, van een persoon of van de populatie. Niets belet ook dat een Digital Twin slechts een onderdeeltje vormt van een groter systeem – het kan bijvoorbeeld alleen maar uitgewerkt zijn voor 1 kritische component.

We kunnen twee stromingen van Digital Twins onderscheiden:

• Hoogwaardige technologische twins (luchtvaart, industrie, infrastructuur), waarbij de twin wordt gebruikt voor diagnostiek, voorspellend onderhoud of iteratief ontwerp op basis van operationele gegevens – bij NASA, voor elektriciteitsdistributie, …
• Informatiesysteem- of socio-technische twins (steden, organisaties, dienstverlening), waarbij de doelentiteit niet zozeer een machine is maar eerder een complex systeem met meerdere belanghebbenden, bestaande uit processen, regels, mensen en gegevensstromen. Deze tweede stroom is waar de publieke sector in past, maar het is ook waar de definities vaag worden en Digital Twin soms wordt gebruikt als marketingterm voor ‘dashboard+model’.

Waar beleidsmatig enige vaagheid misschien onvermijdelijk is, willen we in de praktijk toch een meer operationele interpretatie. We zouden een administratieve digital twin kunnen definiëren als: een continu geüpdatete, testbare, digitale representatie van de realiteit van de dienstverlening. Dit omvat processen, dossiers en de status waarin die zich bevinden, een uitvoerbaar systeem van de regels die van toepassing zijn, en alle dataverkeer dat nodig is om het geheel te doen werken. Dat moet toelaten de huidige realiteit van nabij te monitoren, en eventuele wijzigingen vooraf te simuleren voordat ze worden toegepast.

Voor een industrieel proces gedreven door sensordata en de onveranderlijke wetten van de fysica, ligt dat gemakkelijker dan voor het overheidswezen, waar men vaak gevoelige gegevens verwerkt en afhangt van regelmatig wijzigende regels die ruimte laten voor interpretatie (zie ook onze eerder gepubliceerde artikels over Rules As Code). Bezorgdheden rond data governance (GDPR etc.) kunnen het moeilijk maken om synchronisatie met real-time gegevens op te zetten. Beslissingslogica is vaak nauw verweven met de code van applicaties, wat aanpassingen en compliance checking bemoeilijkt. Het is daarom vaak al een hele prestatie als men in overheidscontext tot een Digital Shadow komt, die we ergens kunnen situeren tussen een “dom” model en een echte gesynchroniseerde twin.

Toonaangevende projecten

In Europa gaan de opvallendste Digital Twin projecten overwegend over klimaat en wetenschap:

• Destination Earth of DestinE combineert grootschalige gegevens van (weer)satellieten en Copernicus in een data lake. Op basis daarvan zagen 2 Digital Twins het licht: Climate Change Adaptation (langetermijn) en Weather-induced Extremes (kortetermijn). Daarvoor ontwikkelden ze hun eigen Digital Twin Engine. Het project wordt voortgezet, waarbij men gemakkelijker “downstream applicaties” van externe gebruikers wil faciliteren die deelaspecten of specifieke onderzoeksvragen verder kunnen uitdiepen. Dat alles moet gedeeld worden via 1 platform gecoördineerd door ESA.
• Het EDITO project probeert gelijkaardige doelstellingen te bereiken maar dan voor oceanen. Hiervoor wordt data van EMODnet en Copernicus samengebracht. Toegang verloopt via een Datalab dat ook een reeks andere bouwblokken en services aanbiedt, en de applicaties die erop gebouwd worden kunnen een plaats krijgen op het digitaal platform van het initiatief.
• Verschillende use cases worden ook opgelijst in het kader van het recent afgelopen (en Europees gefinancierde) interTwin onderzoeksproject, dat een enigszins gestandaardiseerde architectuur met herbruikbare componenten voor Digital Twins trachtte ontwikkelen. Zij benaderden het onderwerp eerder vanuit de wereld van het CERN, en onafhankelijk van de twee eerder vermelde initiatieven. Onderweg leerden ze wel van elkaars bestaan en werd een mogelijke interoperabiliteit met het ESA-gelinkte DestinE alvast onderzocht.

In een administratieve context hebben we minder boodschap aan gegevens van satellieten of deeltjesversnellers. Omwille van de governance-vereisten komt de nadruk veeleer te liggen op correcte interoperabiliteit en data-uitwisseling, conform alle geldende wettelijke kaders. In dat opzicht zijn de nuttigste Europese initiatieven misschien nog de Data Spaces – voor een “policy twin” bijvoorbeeld de Legal Data Space. Er zijn ook raakvlakken met het idee van Regulatory Sandboxes zoals dat opduikt in o.a. de Interoperable Europe Act of recenter de AI Act: een administratieve digital twin kan de rol van zo’n sandbox vervullen als er goede mechanismen voor scenario-ontwikkeling en -evaluatie zijn.

Administratieve Use Cases

Voordat we zelf aan de slag zouden gaan in complexe sectoren zoals gezondheidszorg en sociale zekerheid, moeten we ons toch afvragen of Digital Twins echt iets kunnen toevoegen aan wat vandaag al bestaat – want hype op zich draagt niets bij.

Use Case 1 : Simulatie van beleid en uitvoeringsimpact

Inzake policy modeling voor sociale zekerheid, is er bijvoorbeeld al een sterke basis met het EUROMOD microsimulatie model, waarvan de Belgische variant BELMOD heet. Dit zijn statische microsimulaties waarbij gegevens op fijnmazig niveau worden gecombineerd met gecodeerde regels zodat het mogelijk wordt om hervormingen aan de parameters van de sociale zekerheid te simuleren (bijdragen, uitkeringen, etc.). Zulke studies worden typisch uitgevoerd aan universiteiten, men kan een idee krijgen van wat dat inhoudt via EUROMOD Online.

In zekere zin komt dit type model al in de buurt van een digital twin voor sociaal beleid, maar het mist nog twee cruciale lagen:

• actuele/live koppelingen met administratieve gegevens: hiermee kan men dan budgettaire en verdelingseffecten simuleren op de situatie van vandaag, in plaats van op verouderde data van enkele jaren geleden.
• procesinformatie over de dienstverlening (doorlooptijden van dossiers, behandelingscapaciteit etc): dit zou toelaten ook de operationele impact van hervormingen op de uitvoerende diensten in te schatten.

Het zou allerminst eenvoudig zijn om dat toe te voegen: de gegevens in kwestie zijn zeer gevoelig van aard. De echte data gebruiken als real-time databron voor simulaties zou al zeker verregaande anonymisering vereisen (voortvloeiend uit de GDPR), naast een resem andere veiligheidsmaatregelen. Dat is een complexe oefening op zich, waarbij mogelijk ook nuttige informatie verloren gaat.

De status van een persoon binnen de sociale zekerheid wordt daarenboven bepaald door een opeenvolging van gebeurtenissen die lang kunnen doorwerken en met elkaar interageren (werk, ontslag, ziekte, ongeval, pensioen, geboorte van een kind, …). Om echt waardevol te kunnen zijn zou een twin de hele weg moeten kunnen modelleren die een individu aflegt in het systeem. Niet alleen de individuele status, maar ook die van dossiers (worden er deadlines gemist) en administratie (is er behandelingsachterstand) evolueert doorheen de tijd.

Als er vandaag al een goede digital shadow beschikbaar is van een dienst, dan kan met de toevoeging van evolutieve gegevens over werklastverdeling, capaciteit, dossiervoortgang, … een volgende stap gezet worden, zoals de simulatie van dossierdoorstroming. Zulke selectieve simulaties kunnen dienen voor tegenfeitelijke (“wat-als”) analyses die de impact van verandering (organisatorisch, of in de regelgeving) beter in te schatten maakt. Andersom kan men zoiets ook zien als een framework voor regressietesten: berekeningen op representatieve steekproeven kunnen herhaald worden telkens iets wijzigt, om na te gaan waar de grootste impact ligt.

Use Case 2 : Organisatorische planning in de gezondheidszorg

De administratie van de gezondheidszorg kent andere prioriteiten: opvolging van patiënten en consultaties is tijdskritisch, de toekenning van mensen en middelen is een complexe planningspuzzel, allerlei terugbetalingen en verzekeringen, … Om daarin richting Digital Twin te evolueren kan er een grote rol weggelegd zijn voor de European Health Data Spaces, en voor nieuwe oplossingen die men momenteel tracht uit te denken voor secundair gebruik van gezondheidsdata.

We staan nog ver van de droom van individueel geoptimaliseerde gezondheidszorg op basis van een persoonlijke digital twin van een patiënt – idee dat trouwens ook gepaard gaat met heel wat niet triviale risico’s inzake ethiek en privacy. Op kortere termijn liggen de mogelijkheden eerder op niveau van de organisatie. Met gegevens over opnames, wachtlijsten, personeelsinzet en activiteit, toegevoegd aan een bestaande digital shadow, kunnen strategische en operationele wijzigingen mogelijk beter opgevangen worden.

Implementatie: een kostelijke affaire?

Om de focus te behouden op wat vandaag of op korte termijn mogelijk is, kunnen administraties zich inspireren op “reference stacks” van technologische componenten, die uitgebouwd zijn in het kader van bestaande digital twins. Enkele daarvan haalden we reeds eerder aan en herhalen we hier niet.

Een Digital Twin moet een representatie kunnen bevatten van de huidige staat van een systeem, en moet gebeurtenissen kunnen verwerken die daarop een impact hebben. In het kader van de Europese FIWARE initiatieven (Future Internet) werd daarvoor door een werkgroep Context Information Management bij ETSI de NSGI-LD standaard en API ontwikkeld. Het lijkt er echter op dat er nog niet veel adoptie is van deze standaard buiten het eigen netwerk van voornamelijk Smart City en IoT-initiatieven.

Administratieve systemen bestaan niet louter uit beslissingen. De processen omvatten interactie, documenten, en soms ook enige beoordelingsvrijheid. Open standaarden uit de business process management wereld komen hier van pas. DMN (decision modeling), BPMN (business processes) en CMMN (case management) zijn complementair aan elkaar en laten het modelleren van deze aspecten toe. Op deze initiatieven verschijnen ook uitbreidingen, zoals het aan de KULeuven ontwikkelde Constraint DMN (cDMN) dat complexere logica toelaat. Een Digital Twin kunnen we dan samenstellen uit een DMN beslissingsmotor die berekent “wat de regels zeggen” (hier kan Rules As Code eventueel een plaats krijgen), verrijkt met lagen die de processen en caseflow voor hun rekening nemen (status, deadlines, ondersteunende documenten), en tot slot een regelmatige synchronisatie om de operationele status (of context) te kunnen updaten. Dit is compatibel met het JRC maturiteitsmodel (model -> schaduw -> twin).

Digital Twins zijn niet duur omdat ze veel visualisatie bevatten of rapporteringsmogelijkheden ingebouwd hebben. Ze zijn duur omdat ze een duplicaat vormen van het doelsysteem, dat net zoals het origineel, doorheen de tijd correct moet blijven werken. Om meer te zijn dan enkel hype, is constante investering in onderhoud nodig. Die recurrente kosten omvatten ten minste het volgende:

• monitoring en validatie: een digital twin moet elke verandering aan het doelsysteem zo accuraat mogelijk volgen, dit vraagt regelmatige updates,
• onderhoud van de regels en traceerbaarheid: zeker wanneer regels vaak wijzigen is dit een grote kost. Hier spelen versionering, test suites en veranderingsmanagement een rol,
• functioneren van data pipelines en interoperabiliteit: omvat ook semantiek, toegangscontrole, datakwaliteit, accuraatheid en beveiliging,
• privacy en compliance: onontbeerlijk, zeker voor systemen die persoonsgegevens verwerken (gezondheid, inkomen, familie)

Voor een administratieve use case is de beste eerste stap daarom een stelselmatige uitbouw van wat we een privacy-aware digital shadow zouden kunnen noemen: initieel beperkt tot monitoring + replay functionaliteit, met strikte toegangscontrole en dataminimalisatie. Daarna kan gedacht worden aan uitbreiding met simulaties op geanonimiseerde of synthetische datasets. Eventuele near-real-time synchronisatie met gegevens uit het echte doelsysteem, om een echte Digital Twin te vormen, kan pas op het einde volgen, en heeft vaak nogal wat voeten in de aarde.

Conclusie

Is een Digital Twin het juiste type oplossing, of kan het ook eenvoudiger? Samengevat zijn Digital Twins pas te overwegen als al het volgende waar is (anders kan een andere aanpak efficiënter zijn en beter aansluiten):

• Het doelsysteem dat gemodelleerd wordt is dynamisch: uitkomsten hangen af van evoluerende situaties (caseflow, wachtrijen, levenscyclus van gebeurtenissen), niet enkel van eligibility checks of formulieren.
• Je kan referentiedatabronnen identificeren en doorlopende synchronisatie volhouden. Zonder regelmatige updates met operationele data, bouw je een model en geen twin.
• Simulaties leiden tot echte beslissingen. Als de organisatie niet voldoende vrijheid heeft om in te grijpen (beleid veranderen, caseflow wijzigen, prioritisering, personeelstaken, …), zal een reeks dashboards waarschijnlijk volstaan.
• Er is een geloofwaardig plan voor audit en permanente kwaliteitsbewaking. Dit mag niet achteraf komen maar moet een acceptatiecriterium zijn. Het heeft geen zin een twin te bouwen die sneller rot dan het doelsysteem.
• De wettelijke/compliance omgeving is compatibel. Als er persoonsgegevens aan te pas komen kunnen GDPR en AI Act verplichtingen met zich meebrengen die de haalbaarheid en de kostprijs erg beïnvloeden. Dat kan een Twin limiteren tot een veredeld testsysteem in plaats van een echte bijdrage tot operationele automatisering te leveren.

Een niet-Twin kan ook waardevol zijn – met gecodeerde regels + testharnas + monitoring heb je ook al een transparante setup waarmee allerlei inzichten verworven kunnen worden, zonder de complexiteit en kost van volledige synchronisatie of simulatie-infrastructuur. In een administratieve omgeving kan zulk policy model al veel noden lenigen zonder operationele digital twin, al zal dat misschien teleurstellend zijn voor wie graag uitpakt met trendy buzzwords.

Dans un article précédent, nous avons examiné Rules as Code, une approche visant à réduire l’écart entre les réglementations et les logiciels. Nous avons illustré qu’il existe de nombreux obstacles pratiques à surmonter, malgré l’objectif louable. L’encodage uniforme des règles avec leur historique, leurs interdépendances et leurs dépendances est un défi qui peut nécessiter un investissement considérable en termes de personnel et de ressources. De plus, une gestion active permanente est nécessaire pour prendre en compte chaque modification apportée aux règles. Même à petite échelle, une collaboration étroite entre juristes et développeurs est indispensable, car des décisions motivées devront régulièrement être prises en matière d’interprétation. En l’absence de normes industrielles et alors que les meilleures pratiques sont encore en cours d’élaboration, les early adopters risquent de devoir payer la pioneer tax. La complexité des compétences gouvernementales ne facilite pas une éventuelle application en Belgique.

Partiellement sous l’impulsion du rapport détaillé de l’OCDE de 2020, certaines administrations se sont déjà pleinement engagées dans l’élaboration de proof-of-concepts, parfois à grande échelle. Il existe donc aujourd’hui plusieurs cadres relativement matures. La France est sans aucun doute le pays pionnier ; l’initiative que nous allons présenter ci-dessous vient de France. Les Pays-Bas ne sont pas en reste : l’administration fiscale néerlandaise utilise depuis un certain temps déjà son propre langage de domaine, RegelSpraak, qu’elle interprète et traite à l’aide du rule engine ALEF. Cependant, le code source publié à ce sujet semble pour l’instant se concentrer davantage sur la méthodologie que sur les applications.

OpenFisca

OpenFisca a vu le jour en 2011 en tant que moteur de microsimulation open source permettant de convertir les règles fiscales et sociales (“tax & benefit system”) en code exécutable. Les effets de cette réglementation, et les éventuelles modifications, peuvent alors être simulés tant pour des cas individuels que pour des populations entières. Parmi les sites web utilisant OpenFisca en arrière-plan, on peut citer LexImpact (simulation des modifications de la législation socio-fiscale), Mes droits sociaux (simulation des droits sociaux) et 1jeune1solution (mesures de soutien diverses). Parmi les exemples étrangers, citons BenefitMe (Nouvelle-Zélande), Les meves ajudes (Barcelone) ou PolicyEngine (Royaume-Uni/États-Unis) – ces derniers ayant toutefois nécessité des modifications importantes du moteur.

Afin de modéliser notre propre système fiscal et/ou de sécurité sociale, nous devons créer une fourche du Template country OpenFisca générique. Plusieurs autres pays ont déjà expérimenté cette approche, comme le Sénégal, le Paraguay et la Tunisie, qui figurent dans la liste des repositories. La législation régionale ou locale peut être ajoutée grâce à des extensions pluginà un système national, comme celui de Paris. Une fois le repository initialisé, nous pouvons commencer à travailler sur ce qui pourrait un jour devenir openfisca-belgium. La modélisation dans OpenFisca se fait en écrivant des classes et des méthodes Python, qui représentent les entités, les variables et les formules de calcul issues de la réglementation.

Malheureusement, c’est à peu près là que s’arrête la partie facile. Le repository du country template est minimaliste et, bien qu’il existe une documentation avec un petit tutoriel pour créer sa propre version, celle-ci se concentre principalement sur les premières étapes. Les directives sur la manière de structurer au mieux notre propre fourche dès que le nombre de variables et de paramètres augmente font largement défaut. Le repository du projet parent openfisca-france peut certes servir d’exemple, mais il est très volumineux et ne permet pas vraiment de comprendre les raisons de leurs choix structurels ou architecturaux.

L’aspect d’une GUI ou d’une interface web reste également sous-estimé. Pourtant, l’interface de LexImpact simulator pour l’impôt sur le revenu en France, par exemple, est justement un point fort. Comme guide pour la construction d’une interface web, on se réfère à tutoriels et slides d’un workshop, où les premières étapes sont présentées dans Svelte, React et VueJS. Cependant, le fait qu’une GUI ou une application web doive encore être construite from scratch en plus d’une instance OpenFisca propre constitue un obstacle supplémentaire à l’adoption. La construction d’une GUI est en effet chronophage. Il serait utile de disposer de bibliothèques OpenFisca-GUI avec des composants réutilisables pour les principaux frameworks web, afin qu’un serveur OpenFisca puisse éventuellement être associé à une interface web générique par défaut. Un plugin Drupal semble actuellement être le seul à aller quelque peu dans cette direction.

L’IA à la rescousse ?

Étant donné qu’OpenFisca, Svelte, React et Vue sont tous nouveaux pour l’auteur, et que les outils d’IA promettent d’accélérer l’intégration des développeurs, nous saisissons l’occasion pour tester simultanément l’IDE Cursor alimenté par l’IA. Ce clone de Visual Studio Code est enrichi de la possibilité d’appeler des LLM (dans notre cas, basés sur le cloud public). De plus, des sélections issues de fichiers du projet peuvent être marquées comme contexte pour la question. Cursor peut fournir des suggestions d’ajouts ou de modifications à apporter aux fichiers qui, une fois approuvées, peuvent être directement intégrées dans la base de code.

Interagir avec des modèles d’IA comporte des risques pour la confidentialité. Cette expérience est principalement possible car nous travaillons avec du code open source, des réglementations publiées et leur documentation également publique, qui ne sont pas sensibles. Cependant, étant donné que tout ce qui se trouve dans l’IDE peut être envoyé au modèle de langage, nous devons toujours veiller à ne pas ouvrir dans l’IDE des fichiers contenant des identifiants, des clés API ou des informations personnelles. Cela reste la responsabilité de chaque développeur. Dans tous les cas, il est recommandé d’être prêt à faire tourner les clés API ou les credentials, car dans le feu de l’action d’un debugging, il est facile de partager trop d’informations avec un LLM.

Enfin, il convient de mentionner que cette expérience a été réalisée avec les versions 1.6 et 1.7 de Cursor en septembre-octobre 2025, avec le modèle de langage sous-jacent GPT-4.5 d’OpenAI, puis GPT-5.0, utilisé avec une clé API dédiée (et non via Cursor). Les versions ultérieures disposent de nombreuses fonctionnalités plus récentes (notamment des workflows agentic) et il est possible que l’expérience soit aujourd’hui (janvier 2026) très différente. Cependant, les principaux enseignements restent généralement valables pour tout développement alimenté par l’IA, que ce soit via IDE, ligne de commande ou les deux (par exemple, Anthropic Claude Code).

Dans un premier temps, nous ajoutons la documentation nécessaire à notre projet. Nous prenons comme exemple la loi du 26 mai 2002 concernant le droit à l’intégration sociale. Avec tous les autres arrêtés royaux, lois et circulaires pertinents, elle est clairement répertoriée sur le site web du SPP Intégration sociale. Afin de faciliter la recherche et l’interprétation du texte pour un LLM dans un IDE, nous l’enregistrons sous forme de fichier texte plat sans mise en forme, que nous ajoutons à un nouveau dossier contenant les sources pertinentes dans l’arborescence source du projet. Nous ne pouvons que supposer que cette approche est optimale, mais il faut bien commencer quelque part.

Entités

Les entités dans OpenFisca indiquent pour qui nous effectuons le calcul. Il peut s’agir d’individus, de familles ou d’autres groupes de personnes (entreprises, organisations, etc.). Ce sont les fondements sur lesquels nous pourrons ensuite spécifier des variables qui, ensemble, formeront une “situation” pour laquelle nous pourrons effectuer un calcul. Les entités Person et Household sont déjà présentes dans le code. Une question logique se pose donc : sur la base du texte de loi donné, pouvons-nous définir d’autres entités qui seraient utiles ?

Après avoir posé la question à GPT-5 dans Cursor, avec le texte de loi sélectionné comme contexte, il nous est proposé d’ajouter les entités suivantes :

• Eligible Person for Societal Integration
• Living Wage Recipient
• Employment Project Participant

Les modifications proposées au code sont syntaxiquement correctes. Cependant, aucune de ces trois modifications n’est utile ou nécessaire : dans les trois cas, il s’agit de variantes de Person. Les propriétés qui leur permettraient, par exemple, de percevoir un revenu d’intégration sont plutôt des variables ajoutées à l’entité Person déjà existante. La valeur de ces variables dépend en outre d’autres variables également liées à ce même individu, telles que les revenus du travail ou le statut d’invalidité. Les entités, qui servent principalement à des concepts autonomes, ne sont pas le bon choix dans ce cas. 

En outre, GPT-5 semble avoir mal interprété le concept de “rôle” au sein d’une entité de groupe OpenFisca. Il tente de construire “Eligible Person for Societal Integration” avec différents “rôles” comme composants : “Belgian National”, “EU Citizen”, “Foreigner”, “Stateless”, “Refugee”… Sans doute parce que ces possibilités apparaissent à l’Art.3, 3°, de la loi. Dans OpenFisca, cependant, une entité de groupe est composée de personnes qui se voient chacune attribuer un rôle. Un Household comprend ainsi des rôles Adult et Child. Il est assez absurde qu’une EligiblePerson puisse comprendre plusieurs Foreigners. La nationalité ou l’origine, ou d’autres conditions fixées dans cette loi, sont également ici des variables liées à la personne, et non à une entité en soi. 

À un autre moment, une entité distincte a été créée pour le CPAS. Bien qu’il semble logique de modéliser les CPAS et de les considérer comme une entité – ils sont en effet mentionnés dans la loi –, ce n’est pas (encore) le cas ici. Il n’existe en effet pas différents types de CPAS avec des caractéristiques ou des rôles différents, pour lesquels nous devrions effectuer des calculs différents à chaque fois. Dans le contexte de cette loi, où c’est le citoyen pour lequel nous calculons le droit à l’aide sociale, le CPAS est avant tout une donnée constante et invariable. Dans OpenFisca, nous pouvons donc pour l’instant ignorer cet aspect. (Un type d’entité “institut” n’est pas non plus prévu.) 

Nous constatons ici que Cursor ne peut pas répondre “non” à la question de savoir si d’autres entités utiles peuvent être ajoutées. Il ne peut pas critiquer ou corriger de son propre chef le raisonnement qui sous-tend cette question. Tout au long de l’expérience, Cursor et GPT-5 ont également montré une tendance à la complexité inutile. Cela représente un risque important pour les développeurs qui travaillent avec du code ou des frameworks inconnus : si l’on suit trop rapidement ces suggestions, on risque de perdre le contrôle par la suite et de devoir apporter des corrections très difficiles aux fondements du projet. Une fois qu’une mauvaise voie a été empruntée, il s’avère également difficile de revenir en arrière et de faire oublier ces étapes. Surtout si on les a d’abord acceptées par ignorance, elles s’inscrivent dans le contexte et sont reprises dans les questions suivantes. Ce “context rot” insidieux est désormais un problème bien connu et une cause importante de perte de temps avec le AI enabled coding.

Variables

Le cœur du modèle réside dans les variables qui représentent les droits et les conditions prévus par la loi. L’article 2 de la loi énumère les différentes formes d’intégration sociale auxquelles une personne peut avoir droit (notamment l’emploi, le revenu d’intégration, le projet individualisé). L’article 3 contient les conditions qu’une personne doit remplir pour exercer ce droit. Nous avons transposé ces dispositions étape par étape dans le code.

Dans la pratique, le droit à l’intégration sociale signifie qu’un CPAS doit soutenir une personne par le biais (1) d’un emploi ou d’une formation, (2) d’un revenu d’intégration, ou (3) d’un projet individualisé d’intégration sociale. Cela peut se traduire par trois variables booléennes sur l’entité Personne, par exemple employment_right, living_wage_right et individualized_project_right. Cursor fournit ici une suggestion de code pertinente et propose une formule placeholder simple : tant qu’une personne “est éligible à l’intégration” (une autre variable), le droit s’applique. Nous obtenons ainsi la définition suivante de employment_right :

class employment_right(Variable):
  value_type = bool
  entity = Person
  definition_period = MONTH
  def formula(person, period, parameters):
    return person("eligible_for_integration", period)

class employment_right(Variable):
  value_type = bool
  entity = Person
  definition_period = MONTH
  def formula(person, period, parameters):
    return person("eligible_for_integration", period)

Le contenu de cette formule placeholder est abordé dans l’article 3 ci-dessous. Celui-ci modélise les conditions suivantes pour être éligible :

• Séjour en Belgique (selon les règles à déterminer par arrêté royal).
• Âge : la personne est majeure (18 ans et plus) ou, si elle est mineure, assimilée à une personne majeure selon les exceptions prévues par la présente loi.
• Nationalité ou statut de séjour : la personne est belge, citoyenne de l’UE (après 3 mois de séjour), étrangère enregistrée, apatride, réfugiée ou bénéficiaire d’une protection subsidiaire.
• Ressources insuffisantes
• Disposition à travailler (sauf si cela est impossible pour des raisons de santé ou d’équité).
• Épuisement des droits issus d’autres régimes

Toutes ces conditions sont regroupées dans une variable booléenne centrale societal_integration_right. Cette variable indique si une personne, compte tenu de sa situation personnelle, peut prétendre à l’intégration sociale. En fait, il s’agit de la traduction de “la personne remplit-elle toutes les conditions de l’article 3 ?“. La formule combine toutes les sous-conditions :

class societal_integration_right(Variable):
  value_type = bool
  entity = Person
  definition_period = MONTH
  label = "Right to societal integration"
  def formula(person, period, parameters):
    residency = person("residency_status", period)
    is_major = person("is_major", period)
    nationality = person("nationality_status", period) in ["belgian", "eu_citizen", "registered_foreigner", "stateless", "refugee"]
    insufficient_income = not person("has_sufficient_income", period)
    willing_to_work = person("willing_to_work", period)
    claiming_benefits = person("claiming_benefits", period)
    return (residency and is_major and nationality and insufficient_income and willing_to_work and claiming_benefits)

class societal_integration_right(Variable):
  value_type = bool
  entity = Person
  definition_period = MONTH
  label = "Right to societal integration"
  def formula(person, period, parameters):
    residency = person("residency_status", period)
    is_major = person("is_major", period)
    nationality = person("nationality_status", period) in ["belgian", "eu_citizen", "registered_foreigner", "stateless", "refugee"]
    insufficient_income = not person("has_sufficient_income", period)
    willing_to_work = person("willing_to_work", period)
    claiming_benefits = person("claiming_benefits", period)
    return (residency and is_major and nationality and insufficient_income and willing_to_work and claiming_benefits)

Notons ici quelques lacunes étranges dans la suggestion de Cursor. Ainsi, le nom de la variable societal_integration_right n’est pas identique au placeholder eligible_for_integration défini précédemment, alors que c’était pourtant l’intention. En outre, la condition de nationalité omet tout simplement la possibilité d’une protection subsidiaire. Enfin, la sixième condition, qui stipule que la personne doit d’abord faire valoir ses droits à d’éventuelles prestations sociales, est mentionnée de manière très rudimentaire sous le nom de claiming_benefits, un nom de variable qui ne reflète pas vraiment ce qui est visé.

Nous pouvons donc accepter cette suggestion, mais nous sommes immédiatement obligés d’apporter trois corrections. Nous pouvons facilement détecter la non-conformité du nom de la variable, car les tests ne fonctionneront pas s’il reste des variables non déclarées dans le code. Un élément manquant dans la formule, tel qu’une condition oubliée, est cependant beaucoup plus facile à négliger et, s’il n’est pas détecté, entraîne à coup sûr des erreurs d’exécution. Nous constatons donc ici la nécessité de se référer au texte de loi afin de vérifier que le code généré correspond bien à ce que dit le texte de loi. Cette vérification doit être effectuée avec suffisamment d’attention pour pouvoir identifier les appellations malheureuses ou les interprétations subtiles erronées du texte.

Les corrections éventuelles doivent également être effectuées le plus rapidement possible. Si un code erroné reste présent dans l’éditeur, il fera en effet partie du contexte utilisé par le modèle d’IA et servira lui-même de base pour les suggestions suivantes. Cela peut conduire à une situation où l’on continue à recevoir des suggestions contenant toujours les mêmes erreurs, qu’il faut donc corriger à chaque fois, ce qui n’est pas propice à la productivité.

Les variables utilisées dans la méthode formula() de societal_integration_right ci-dessus doivent bien sûr être définies à leur tour : pour chacune de ces variables, nous devons écrire une classe. Cela peut donner lieu à des chaînes complexes de dépendances. Ainsi, is_major pourrait être une simple variable d’entrée booléenne, mais nous pouvons également la calculer sur la base de la date du jour et d’une nouvelle variable birthdate. Le calcul de la formule des variables peut également utiliser les paramètres d’une loi – ainsi, en Belgique, la majorité n’est atteinte qu’à partir de 18 ans depuis le 1^er mai 1990. Cela nous ramènerait alors au Code civil et à son histoire – pour rester concis, nous n’approfondirons pas cette question pour l’instant.

Dernière remarque : le modèle tel qu’il est construit ici est bien sûr une représentation simplifiée. Notez toutefois que même dans ce cas, après seulement trois articles de loi, nous avons déjà défini une dizaine de classes Python, avec la possibilité d’en ajouter d’autres si nous souhaitons approfondir le sujet. Cursor et GPT-5 écrivent un code relativement verbeux, avec de nombreuses variables et méthodes auxiliaires, qui pourraient parfois être simplifiées. Certains détails de la loi, tels que le délai d’attente de trois mois pour les citoyens de l’UE ou les exceptions qui existent pour certaines catégories de mineurs (art. 7), nécessiteraient de nombreuses variables ou conditions supplémentaires dans un modèle complet.

IA et code : quelques pièges

En ce qui concerne les meilleures pratiques pour l’utilisation de l’IA dans le cadre de tels projets, nous identifions encore quelques pièges, en plus de ceux que nous avons déjà mentionnés.

Ajouter trop de documentation au début conduit rapidement à une “confusion contextuelle“, dans laquelle les suggestions ou les réponses du LLM sont basées sur des informations qui ne sont pas (encore) pertinentes. Il est préférable d’ajouter la documentation progressivement, au fur et à mesure que la fonctionnalité se développe, plutôt que d’ajouter l’analyse complète et le contexte à l’IDE dès le départ. Dans le cas de la réglementation, ajoutez les règles article par article à l’IDE, au fur et à mesure de l’avancement du projet, et résistez à la tentation d’intégrer à l’avance l’ensemble du texte de loi dans l’IDE en tant que “référence encyclopédique”.

Le “context rot” ou “context poisoning” survient lorsque l’IA s’engage dans une mauvaise voie, s’y enlise et finit par oublier des informations plus pertinentes, ce qui rend la récupération plus difficile. Le “context quarantining“, qui consiste à diviser le problème en sous-problèmes plus petits, chacun avec son propre contexte, est un remède logique à ce problème. C’est également la voie empruntée par la plupart des systèmes de “deep research” ou “multi agentic“. Dans un IDE, cela impliquerait qu’un système d’IA devrait segmenter la base de code et la documentation à partir d’une certaine taille. La mise en œuvre technique de cette solution en arrière-plan semble être un défi de taille, et différents IDE développeront probablement leur propre approche à cet égard dans un avenir proche.

Une autre source de frustration était que l’IA plaçait parfois le code ou les fichiers au mauvais endroit ou supposait que certaines choses existaient. Par exemple, les formules générées faisaient référence à des variables qui n’étaient pas encore définies. Cela génère bien sûr des messages d’erreur lors des tests. Nous devions alors ajuster l’IA ou insérer nous-mêmes des variables supplémentaires pour couvrir ces références. Même des détails mineurs, tels que le formatage de la documentation ou la création ou non des importations nécessaires, nécessitaient parfois une correction manuelle. Ce type d’incohérences démontre qu’il n’est pas possible de se fier aveuglément aux suggestions de l’IA. Un développeur doit constamment vérifier si le code généré correspond à l’intention et, dans le cas contraire, intervenir immédiatement.

publi.codes

Nous souhaitons également signaler l’existence de publi.codes comme alternative possible à OpenFisca. Plus récent et plus moderne, ce dernier exige que les règles soient codées au format YAML, ce qui est beaucoup plus pratique que l’écriture de sous-classes en Python et beaucoup plus lisible pour les non-développeurs. En contrepartie, on est toutefois limité aux opérations autorisées par le moteur sous-jacent. Ce n’est qu’à partir de la version 2, encore en cours de développement, que des possibilités d’encoder des barèmes ou des abattements (montants exonérés), très fréquents en Belgique, seront ajoutées.

La version actuelle de publi.codes dépend en outre de l’écosystème NPM, qui est actuellement régulièrement affecté par des attaques du supply chain. Publi.codes v2 serait quant à lui compilé vers OCaml, un langage de programmation que nous n’utilisons pas chez Smals. Étant donné qu’il y a peu de chances que Smals souhaite introduire ce langage de programmation dans son portefeuille (et mettre en place une équipe de support à cet effet), il ne semblait pas très utile d’examiner publi.codes en profondeur dans le cadre de cet exercice. Il convient toutefois de noter que publi.codes dispose de quelques libraries prêtes à l’emploi en matière de composants UI.

Conclusion

OpenFisca et publi.codes sont deux systèmes particulièrement performants lorsque les règles peuvent être modélisées sous forme de calculs explicites et testables. Ils sont moins adaptés aux réglementations qui font appel aux décisions discrétionnaires, à la libre interprétation, aux exceptions sans paramètres clairs ou aux workflows de “case management”. Il s’agit avant tout de systèmes de calcul et de règles, et non de plateformes de traitement de dossiers. Ils peuvent donc éventuellement servir de moteur pour des applications capables de calculer les impôts ou les allocations au niveau de la personne/du ménage (droit à quelque chose + montant), ou pour simuler l’impact politique d’éventuelles modifications (“combien coûte cette réforme ?”, “qui y gagne/y perd ?”). Cela peut être intéressant tant pour les législateurs que pour les citoyens.

Cependant, un projet OpenFisca ne se met pas en place rapidement. Sur le plan conceptuel, OpenFisca est quelque peu déroutant pour un développeur : bien qu’OpenFisca utilise des classes Python, celles-ci ne servent pas à modéliser des objets, mais à enregistrer de manière déclarative des entités, des variables et des règles de calcul issues de la réglementation. Étant donné que par variable, il faut écrire une classe et que des dizaines de variables peuvent facilement entrer en jeu dans un article de loi complexe, on se retrouve avec une pile de code qui s’accumule rapidement et qui est difficile à organiser de manière claire. En outre, le développement d’une interface graphique nécessite également beaucoup de travail supplémentaire. Le projet manque encore de tooling nécessaire pour atténuer ces problèmes récurrents. (Bien sûr, cela n’aide pas lorsque l’administration publique, qui semble considérer que les projets open source peuvent par définition s’autofinancer, décide soudainement de fermer les vannes en 2020.

Enfin, nous pouvons ajouter que cette expérience a été à la fois un reality check utile et instructif sur ce que les LLM peuvent apporter, et gâcher, à un environnement de travail de développeur. Le meilleur conseil reste de garder les rênes fermement en main et de travailler par petites étapes incrémentielles. Certains outils d’IA seront plus performants que d’autres dans divers domaines. Donner des réponses négatives ou détecter des erreurs dans les questions reste un défi pour les LLM, ce qui comporte certains risques. Cependant, l’assistance IA dans les IDE évolue rapidement, et une expérience similaire se déroulera sans doute différemment l’année prochaine.

Rules As Code ne signifie certainement pas qu’aujourd’hui, nous pouvons fournir un texte de loi à une IA pour qu’elle déploie un programme. Cependant, dans les années à venir, les forums spécialisés accorderont sans aucun doute une grande attention à l’interaction entre la loi, la mise en œuvre et les outils d’IA. Pour l’instant, la complexité de la réglementation elle-même, même avec une IA de plus en plus performante, reste le principal obstacle aux projets Rules As Code.

In een vorig artikel fileerden we Rules as Code, een aanpak die erop gericht is om de kloof tussen regelgeving en software te verkleinen. We illustreerden daarbij dat er heel wat praktische obstakels te overkomen zijn, niettegenstaande het lovenswaardige doel. De uniforme encodering van regels met hun geschiedenis, verwevenheden en afhankelijkheden is een uitdaging die een aanzienlijke investering van mensen en middelen kan vergen. Permanent actief beheer is daarenboven nodig om elke wijziging aan de regels op te vangen. Zelfs op kleine schaal is een nauwe samenwerking tussen juristen en ontwikkelaars onontbeerlijk, want regelmatig zullen gemotiveerde beslissingen genomen moeten worden over interpretatie. Omdat industriestandaarden nog ontbreken en best practices nog volop in ontwikkeling zijn, riskeer je als early adopter de zogenaamde pioneer tax te moeten betalen. De complexe lasagna van overheidsbevoegdheden maakt een eventuele toepassing in België niet eenvoudiger.

Mede onder impuls van het uitgebreide rapport van de OESO uit 2020, hebben enkele overheden toch al volop ingezet op het uitwerken van, soms vrij grootschalige, proof-of-concepts. Er bestaan vandaag dan ook enkele frameworks die relatief matuur zijn. Ongetwijfeld is Frankrijk het voortrekkersland; het initiatief dat we hieronder zullen toelichten komt van Franse bodem. Ook in Nederland beweegt er wel wat: de Nederlandse fiscus gebruikt al enige tijd haar eigen domeintaal RegelSpraak die zij met de rule engine ALEF interpreteert en verwerkt, echter lijkt de daarover gepubliceerde broncode vooralsnog meer op methodologie dan op applicaties te focussen.

OpenFisca

OpenFisca is ontstaan in 2011 als open-source microsimulatie-motor om belasting- en uitkeringsregels (“tax & benefit system”) om te zetten naar uitvoerbare code. De effecten van die regelgeving, en eventuele wijzigingen, kunnen dan gesimuleerd worden voor zowel individuele cases als hele populaties. Websites met OpenFisca in de achtergrond zijn onder andere LexImpact (simulatie van wijzigingen in socio-fiscale wetgeving), Mes droits sociaux (simulatie van sociale rechten), en 1jeune1solution (allerhande steunmaatregelen). Buitenlandse voorbeelden zijn BenefitMe (Nieuw-Zeeland), Les meves ajudes (Barcelona), of PolicyEngine (UK/USA) – deze laatsten wel met grondige aanpassingen aan de engine.

Om ons eigen belasting- en/of sociale-zekerheidsstelsel te modelleren, moeten we een fork maken van het generieke OpenFisca country-template. Verschillende andere landen hebben er tenminste al mee geëxperimenteerd, zo vinden we in de lijst van repositories o.a. Senegal, Paraguay en Tunesië. Regionale of lokale wetgeving kan middels plugin-extensies toegevoegd worden aan een nationaal systeem, zoals deze voor Parijs. Eens de repository geïnitialiseerd, kunnen we beginnen werken aan wat misschien ooit openfisca-belgium kan worden. De modellering in OpenFisca gebeurt door het schrijven van Python-klassen en -methodes, die de entiteiten, variabelen en berekeningsformules uit de regelgeving vertegenwoordigen.

Helaas houdt het gemakkelijke deel daar ongeveer op. De country-template repository is minimalistisch en hoewel er wel documentatie, met een kleine tutorial, beschikbaar is om een eigen versie uit te bouwen, focust deze vooral op de eerste stappen. Richtlijnen over hoe we onze eigen fork best zouden structureren zodra het aantal variabelen en parameters groeit, ontbreken grotendeels. De repository van moederproject openfisca-france kan weliswaar als voorbeeld dienen, maar is dan weer erg groot, en het waarom van hun structurele of architecturale keuzes is er niet echt uit af te leiden.

Ook het aspect van een GUI of webinterface blijft onderbelicht. Nochtans is de interface van bijvoorbeeld de LexImpact simulator van de Franse inkomstenbelasting, net een sterk punt. Als leidraad voor bouwen van een webinterface verwijst men naar tutorials en slides van een workshop, waar men de eerste stappen toont in Svelte, React en VueJS. Het is echter een extra barrière voor adoptie, dat een GUI of webapp nog from scratch zelf te bouwen is bovenop een eigen OpenFisca-instantie. Het bouwen van een GUI is immers tijdrovend. Het zou nuttig zijn om OpenFisca-GUI-libraries te hebben met herbruikbare componenten voor de belangrijkste web frameworks, zodat een OpenFisca server misschien met een generieke default webinterface gebundeld kan worden. Een Drupal-plugin lijkt momenteel het enige project dat enigszins in die richting gaat.

AI to the rescue?

Gezien OpenFisca, Svelte, React en Vue allen nieuw zijn voor de auteur, en AI-tooling belooft om developers sneller te laten onboarden, grijpen we de kans om de AI-powered IDE Cursor tegelijk uit te testen. Deze kloon van Visual Studio Code is verrijkt met de mogelijkheid tot het aanroepen van (in ons geval public-cloud-gebaseerde) LLMs. Daarbij kunnen selecties uit bestanden in het project worden gemarkeerd als context bij de vraag. Cursor kan suggesties geven voor toevoegingen of wijzigingen aan bestanden die, eens goedgekeurd, direct geïntegreerd kunnen worden in de codebase.

Interageren met AI-modellen houdt privacy-risico’s in. Dit experiment vooral mogelijk omdat we werken met open-source code, gepubliceerde regelgeving, en de eveneens openbare documentatie daarvan, wat niet gevoelig is. Maar gezien alles wat zich in de IDE bevindt naar het taalmodel gestuurd kan worden, moeten we er nog steeds op letten dat we geen bestanden openen in de IDE die credentials, API keys of persoonlijke informatie bevatten. Dat blijft de verantwoordelijkheid van de individuele developer. Sowieso is het goede praktijk om voorbereid te zijn op het roteren van API keys of credentials, want in het heetst van een debugging-strijd is oversharing met een LLM snel gebeurd.

Tot slot moeten we vermelden dat dit experiment nog werd uitgevoerd met Cursor versies 1.6 en 1.7 in september-oktober 2025, met OpenAI’s GPT-4.5 en later GPT-5.0 als achterliggend taalmodel, gebruikt met een eigen API key (niet via Cursor). Latere versies hebben heel wat nieuwere features (waaronder meer agentic workflows) en het zou kunnen dat de ervaring vandaag (januari 2026) al heel anders zou zijn. De belangrijkste lessen blijven echter algemeen gelden voor alle AI-powered development, of dat nu via IDE, command line of beide gebeurt (vb. Anthropic Claude Code).

Als eerste stap voegen we de nodige documentatie toe aan ons project. Als case nemen we de Wet op de Maatschappelijke Integratie van 26 mei 2002. Samen met alle andere relevante wetten, koninklijke besluiten en omzendbrieven is die overzichtelijk geïnventariseerd op de website van de POD Maatschappelijke Integratie. Om de tekst gemakkelijk doorzoekbaar en interpreteerbaar te maken voor een LLM in een IDE, slaan we hem op als plat tekstbestand zonder opmaak, en dat voegen we toe aan een nieuw mapje voor relevant bronmateriaal in de source tree van het project. Of dat optimaal is, daar hebben we het raden naar, maar we moeten ergens beginnen.

Entiteiten

Entiteiten in OpenFisca drukken uit voor wie we de berekening maken. Dat kunnen individuen, gezinnen of andere groeperingen van mensen zijn (bedrijven, organisaties, …). Het zijn de basisbouwstenen waarvoor we later variabelen zullen kunnen specifiëren die samen een “situatie” vormen waarvoor we een berekening zullen kunnen doen. Person en Household zijn al aanwezig in de code. Een logische vraag is dus of we, op basis van de gegeven wettekst, andere entiteiten kunnen definiëren die nuttig zouden zijn.

Na het stellen van de vraag aan GPT-5 in Cursor, met de wettekst geselecteerd als context, wordt voorgesteld de volgende entiteiten toe te voegen:

• Eligible Person for Societal Integration
• Living Wage Recipient
• Employment Project Participant

De voorgestelde aanpassingen aan de code zijn syntactisch correct. Geen van deze 3 zijn echter nuttig of noodzakelijk: het gaat in alledrie de gevallen om varianten van Person. De eigenschappen die maken dat ze bijvoorbeeld een leefloon zouden ontvangen, zijn veeleer variabelen toegevoegd aan de reeds bestaande Person entiteit. De waarde van die variabelen hangt bovendien af van andere variabelen die eveneens aan datzelfde individu gebonden zijn, zoals een inkomen uit werk of een handicapstatus. Entiteiten, die vooral dienen voor op zichzelf staande concepten, zijn hiervoor niet de juiste keuze.

Daarnaast lijkt GPT-5 het concept van een “rol” binnen een OpenFisca groepsentiteit verkeerd te hebben begrepen. Hij probeert “Eligible Person for Societal Integration” op te bouwen met verschillende “rollen” als onderdelen: “Belgian National”, “EU Citizen”, “Foreigner”, “Stateless”, “Refugee”… Dit ongetwijfeld omdat deze mogelijkheden verschijnen in Art.3, 3° lid, van de wet. In OpenFisca is een groepsentiteit echter samengesteld uit Personen die elk een rol krijgen. Een Household bevat zo Adult en Child rollen. Het is vrij nonsensicaal dat een EligiblePerson meerdere Foreigners zou kunnen bevatten. Nationaliteit of herkomst, of andere voorwaarden die gesteld worden in deze wet, zijn ook hier variabelen die gebonden zijn aan de persoon, geen entiteit op zich.

Op een ander moment werd nog een aparte entiteit gecreëerd voor het OCMW. Hoewel het logisch lijkt om de OCMWs te modelleren en als een entiteit te beschouwen – ze worden immers vermeld in de wet – is het dat hier (nog) niet. Er zijn immers geen verschillende types OCMWs met verschillende eigenschappen of rollen, waarvoor we telkens andere berekeningen moeten maken. In de context van deze wet, waarbij het de burger is voor wie we het recht op maatschappelijke steun berekenen, is het OCMW vooral een constant, invariant gegeven. In OpenFisca kunnen we dat dus vooralsnog overslaan. (Een entiteitstype “instituut” is ook niet voorzien.)

We merken hier dus dat Cursor niet “nee” kan antwoorden op de vraag of er nuttige andere entiteiten kunnen toegevoegd worden. Het kan de denkrichting achter die vraag niet bekritiseren of corrigeren uit eigen beweging. Doorheen het hele experiment bleken Cursor en GPT-5 ook een neiging te vertonen tot onnodige complexiteit. Dit is voor developers die met onbekende code of frameworks werken een groot risico: indien men te snel te ver meegaat met zulke suggesties, dreigt men later de pedalen te verliezen en achteraf erg moeilijke correcties te moeten aanbrengen aan de fundamenten van het project. Eens een verkeerde route is ingeslagen, blijkt het ook moeilijk om op de stappen terug te keren en deze weer te doen vergeten. Zeker als men ze eerst onwetend heeft toegelaten, komen ze terecht in de context en wordt er in vervolgvragen op verdergebouwd. Deze sluipende “context rot” is ondertussen een bekend probleem en een belangrijke oorzaak van tijdverlies met AI-enabled coding.

Variabelen

De kern van het model zit in de variabelen die de rechten en voorwaarden uit de wet voorstellen. Artikel 2 van de wet somt de verschillende vormen van maatschappelijke integratie op waarop iemand recht kan hebben (o.a. tewerkstelling, leefloon, geïndividualiseerd project). Artikel 3 bevat de voorwaarden waaraan een persoon moet voldoen om van dat recht gebruik te maken. We hebben deze bepalingen stap voor stap in code omgezet.

Recht op maatschappelijke integratie betekent in de praktijk dat een OCMW een persoon moet ondersteunen via (1) een job of opleiding, (2) een leefloon, of (3) een geïndividualiseerd project voor maatschappelijke integratie. Dit kan vertaald worden naar drie boolean variabelen op de Persoon-entiteit, bijvoorbeeld employment_right, living_wage_right en individualized_project_right. Cursor geeft hier een goede code-suggestie, en voorziet een eenvoudige placeholder-formule: zolang iemand “in aanmerking komt voor integratie” (een andere variabele) zou het recht gelden. We bekomen een definitie van employment_right als volgt:

class employment_right(Variable):
  value_type = bool
  entity = Person
  definition_period = MONTH
  def formula(person, period, parameters):
    return person("eligible_for_integration", period)

class employment_right(Variable):
  value_type = bool
  entity = Person
  definition_period = MONTH
  def formula(person, period, parameters):
    return person("eligible_for_integration", period)

De invulling van deze placeholder-formule komt aan bod in het daaropvolgende Artikel 3. Die modelleert de volgende voorwaarden om in aanmerking te komen:

• Verblijf in België (volgens de regels nader te bepalen bij KB).
• Leeftijd: De persoon is meerderjarig (18+), of als minderjarige gelijkgesteld aan een meerderjarige volgens de uitzonderingen in deze wet.
• Nationaliteit of verblijfsstatuut: De persoon is Belg, EU-burger (na 3 maanden verblijf), ingeschreven vreemdeling, staatloze, vluchteling of subsidiair beschermde.
• Onvoldoende bestaansmiddelen
• Werkbereidheid (tenzij onmogelijk om gezondheidsredenen of billijkheidsredenen).
• Rechten uit andere stelsels uitgeput

Al deze voorwaarden komen samen in één centrale boolean variabele societal_integration_right. Die variabele geeft aan of iemand, gegeven zijn persoonlijke situatie, recht kan hebben op maatschappelijke integratie. In feite is dit de vertaalslag van “voldoet de persoon aan alle voorwaarden van art.3?”. De formule combineert alle subvoorwaarden:

class societal_integration_right(Variable):
  value_type = bool
  entity = Person
  definition_period = MONTH
  label = "Right to societal integration"
  def formula(person, period, parameters):
    residency = person("residency_status", period)
    is_major = person("is_major", period)
    nationality = person("nationality_status", period) in ["belgian", "eu_citizen", "registered_foreigner", "stateless", "refugee"]
    insufficient_income = not person("has_sufficient_income", period)
    willing_to_work = person("willing_to_work", period)
    claiming_benefits = person("claiming_benefits", period)
    return (residency and is_major and nationality and insufficient_income and willing_to_work and claiming_benefits)

class societal_integration_right(Variable):
  value_type = bool
  entity = Person
  definition_period = MONTH
  label = "Right to societal integration"
  def formula(person, period, parameters):
    residency = person("residency_status", period)
    is_major = person("is_major", period)
    nationality = person("nationality_status", period) in ["belgian", "eu_citizen", "registered_foreigner", "stateless", "refugee"]
    insufficient_income = not person("has_sufficient_income", period)
    willing_to_work = person("willing_to_work", period)
    claiming_benefits = person("claiming_benefits", period)
    return (residency and is_major and nationality and insufficient_income and willing_to_work and claiming_benefits)

Let hier vooral op enkele vreemde lacunes in de suggestie van Cursor. Zo is de naam van de variabele societal_integration_right niet gelijk aan de eerder gedefinieerde placeholder eligible_for_integration, hoewel dat wel de bedoeling is. Daarnaast wordt in de nationaliteitsvoorwaarde de mogelijkheid van subsidiair beschermden simpelweg vergeten! Tot slot is de zesde voorwaarde, dat men eerst zijn rechten laat gelden op eventuele sociale uitkeringen, wel erg rudimentair benoemd als claiming_benefits – een variabelenaam die niet echt dekt wat bedoeld wordt.

We kunnen deze suggestie dus wel aanvaarden, maar we zijn al direct verplicht om 3 correcties door te voeren. De niet-overeenkomst van de variabelenaam kunnen we daarbij nog gemakkelijk detecteren omdat de tests niet zullen werken als er nog ongedeclareerde variabelen in de code zitten. Een mankerend element in de formule, zoals een vergeten voorwaarde, is echter veel gemakkelijker over het hoofd gezien, en leidt wanneer dat ongedetecteerd blijft gegarandeerd tot fouten in de uitvoering. Hier merken we dus echt wel de noodzaak om terug te koppelen naar de wettekst om te verifiëren dat de gegenereerde code wel degelijk overeenkomt met wat de wettekst zegt. Deze terugkoppeling moet aandachtig genoeg gebeuren om ook ongelukkige benamingen of subtiele misinterpretaties van te tekst te kunnen identificeren.

Eventuele correcties kunnen daarnaast ook best zo snel mogelijk gebeuren. Als foutieve code in de editor aanwezig blijft, gaat ze immers deel uitmaken van de context die het AI-model gebruikt en dient ze zelf als fundament voor daaropvolgende suggesties. Dit kan leiden tot een situatie waarbij men suggesties blijft ontvangen waarin steeds dezelfde fouten terugkomen, die men dus ook telkens weer moet corrigeren, wat niet bevorderlijk is voor de productiviteit.

De variabelen gebruikt in de formula() methode van societal_integration_right hierboven, moeten uiteraard op hun beurt ook gedefinieerd worden: voor elk van deze variabelen moeten we een klasse schrijven. Dit kan aanleiding geven tot complexe kettingen van afhankelijkheden. Zo zou is_major een eenvoudige booleaanse inputvariabele kunnen zijn, maar we kunnen dat ook berekenen op basis van de datum van vandaag en weer een nieuwe variabele birthdate. De berekening van de formule van de variabelen kan daarnaast ook gebruik maken van de parameters van een wet – zo is de meerderjarigheid in België pas vanaf 18 jaar sinds 1 mei 1990. Dat zou ons dan weer bij het Burgerlijk Wetboek brengen, en haar geschiedenis – om het beknopt te houden gaan we daar nu niet verder op in.

Laatste opmerking: het model zoals hier gebouwd is uiteraard een vereenvoudigde weerspiegeling. Merk wel op dat we zelfs dan, slechts 3 artikels ver in een wet, al snel 10 Python-klassen hebben gedefinieerd hebben, met potentieel voor meer als we echt in de diepte zouden willen gaan. Cursor en GPT-5 schrijven daarbij relatief verbose code, met vele hulpvariabelen en -methodes, die soms echt wel eenvoudiger kan. Sommige details uit de wet, zoals de 3-maanden wachttijd voor EU-burgers, of de uitzonderingen die bestaan voor bepaalde categorieën van minderjarigen (Art. 7), zouden in een volwaardig model nog heel wat extra variabelen of condities vergen.

AI en code: enkele valkuilen

Wat betreft best practices voor de inzet van AI-hulp bij zulke projecten, identificeren we nog enkele valkuilen, naast diegene die we tot nu toe al genoemd hebben.

Teveel documentatie toevoegen in het begin leidt snel tot “context confusion“, waarbij de suggesties of de antwoorden van de LLM gebaseerd gaan zijn op stukken informatie die (nog) niet relevant zijn. Het is beter de documentatie geleidelijk toe te voegen, in gelijke tred met de functionaliteit, in plaats van de volledige analyse en achtergrond op voorhand toe te voegen aan de IDE. In het geval van regelgeving: voeg de regels artikel per artikel toe aan de IDE, naarmate de projectontwikkeling vordert, en weersta de verleiding om de hele wettekst op voorhand als “encyclopedische referentie” te integreren in de IDE.

Context rot of context poisoning ontstaat dan weer wanneer de AI een verkeerde weg is ingeslagen,  daarop voortboomt, en uiteindelijk relevantere informatie vergeet zodat het ook moeilijker wordt om ervan te herstellen. “Context quarantining“, het opdelen van het probleem in kleinere deelproblemen elk met hun eigen context, is daarvoor een logische remedie. Dit is ook de weg die de meeste “deep research” of “multi-agentic” systemen inslaan. In een IDE zou dat impliceren dat een AI-systeem de codebase en de documentatie vanaf een zekere grootte zou moeten segmenteren. Hoe dat technisch uitgewerkt kan worden achter de schermen lijkt een uitdaging van formaat, en verschillende IDEs zullen daar in de nabije toekomst waarschijnlijk hun eigen approach voor ontwikkelen.

Een andere frustratie was dat de AI soms code of bestanden verkeerd plaatste of aannam dat bepaalde dingen bestonden. Zo refereerden gegenereerde formules naar variabelen die nog helemaal niet gedefinieerd waren. Dit zorgt bij het testen natuurlijk voor foutmeldingen. We moesten de AI dan bijsturen of zelf extra variabelen invoegen om die referenties af te dekken. Ook kleine zaken, zoals de formattering van documentatie of het wel/niet aanmaken van noodzakelijk imports, vergden manuele correctie. Dit soort inconsistenties tonen aan dat je AI-suggesties niet blindelings kunt vertrouwen. Een developer moet voortdurend valideren of de code die gegenereerd wordt strookt met de bedoeling, en zo niet, onmiddellijk ingrijpen.

publi.codes

We willen ook nog wijzen op het bestaan van publi.codes als eventueel alternatief voor OpenFisca. Recenter en moderner, moeten de regels daar gecodeerd worden in een YAML-formaat, wat veel hanteerbaarder is dan het schrijven van subklassen in Python, en veel leesbaarder voor niet-developers. Men is in ruil daarvoor echter wel beperkt tot de bewerkingen die zijn toegelaten door de achterliggende motor. Pas vanaf de nog in ontwikkeling zijnde versie 2 komen daar mogelijkheden bij om barema’s te encoderen, of abattementen (vrijgestelde bedragen), die in België erg veelvuldig voorkomen.

De huidige versie van publi.codes is bovendien afhankelijk van het NPM ecosysteem dat tegenwoordig regelmatig geplaagd wordt door supply chain aanvallen. Publi.codes v2 zou dan weer gecompileerd worden naar OCaml, een programmeertaal die we bij Smals niet gebruiken. Gezien de kans klein is dat Smals deze programmeertaal zou willen introduceren in haar portfolio (en een ondersteunend team ervoor zou willen uitbouwen), leek het weinig nuttig om voor deze oefening ook publi.codes in de diepte te bekijken. Het valt echter wel op dat op het vlak van UI-componenten, publi.codes wel enkele libraries heeft klaarliggen.

Conclusie

Zowel OpenFisca als publi.codes zijn als platform vooral sterk wanneer je regels kunt modelleren als expliciete, testbare berekeningen. Minder ideaal is het voor regels die vooral draaien op discretionaire beslissingen, vrije interpretatie, bewijswaardering, uitzonderingen zonder heldere parameters, of “case management”-workflows. Het zijn primair reken- en regelsystemen, geen dossierbehandelingsplatformen. Daarmee zijn ze eventueel wel geschikt als motor voor apps die belastingen of uitkeringen op niveau van persoon/huishouden kunnen berekenen (recht op iets + bedrag), of om beleidsimpact te simuleren van eventuele wijzigingen (“wat kost deze hervorming?”, “wie wint/verliest?”). Dat kan voor beleidsmakers én burgers interessant zijn.

Toch is een OpenFisca-project niet snel even opgezet. Conceptueel is OpenFisca enigszins verwarrend voor een developer: hoewel OpenFisca gebruikmaakt van Python-klassen, dienen deze niet om objecten te modelleren, maar om entiteiten, variabelen en berekeningsregels uit de regelgeving declaratief vast te leggen. Gegeven dat er 1 klasse per variabele moet geschreven worden, en er vlotjes tientallen variabelen kunnen meespelen in een fijnmazig wetsartikel, zit men met een snel groeiende stapel code die een uitdaging is om overzichtelijk georganiseerd te krijgen. Daarnaast vergt ook de ontwikkeling van een GUI veel extra werk. Het project mist nog de nodige tooling om deze recurrente problematieken te verlichten. (Het helpt natuurlijk niet wanneer de opdrachtgevende overheid in 2020 plots de kraan dichtdraait, schijnbaar van mening dat open-source projecten per definitie zelfbedruipend kunnen zijn.)

Tot slot kunnen we nog zeggen dat dit experiment tegelijk een nuttige en leerzame reality check was over wat LLMs kunnen bijdragen, en kunnen verknoeien, aan een developer-werkomgeving. Zelf de regie stevig in handen blijven houden en werken met kleine incrementele stapjes, blijft de beste raad. De ene AI tool zal daarbij al wat minder steken laten vallen dan de andere op allerlei vlakken. Het geven van negatieve antwoorden of het detecteren van fouten in de vraagstelling blijft erg uitdagend voor LLMs en dat brengt wat risico met zich mee. AI-assistentie in IDEs evolueert echter razendsnel, en een gelijkaardig experiment zal volgend jaar ongetwijfeld anders verlopen.

Rules As Code betekent zeker niet dat we vandaag een wettekst aan een AI kunnen geven om er een programma te laten uitrollen. Wel zal er op gespecialiseerde fora de komende jaren ongetwijfeld veel aandacht gaan naar de interactie tussen wet, implementatie, en AI-tooling. Vooralsnog blijft de complexiteit van de regelgeving zelf, ook met steeds betere AI, de grootste hinderpaal voor Rules As Code projecten.

Le monde de l’IA évolue à une vitesse vertigineuse et l’émergence du Retrieval-Augmented Generation (RAG) ouvre de nouvelles possibilités pour combiner intelligemment des données et des modèles de langage.

Les systèmes RAG combinent la capacité générative des LLM avec l’extraction d’informations pertinentes et actualisées dans des sources de données. Cela les rend plus puissants, mais aussi plus complexes, car ils dépendent de la qualité du modèle et des données utilisées, et sont susceptibles de diffuser des informations obsolètes, incorrectes ou inappropriées.

Dans un précédent article de blog, nous avons expliqué comment les évaluations automatiques peuvent aider à mesurer la qualité d’un système RAG et à l’améliorer de manière interactive. Mais la qualité seule ne suffit pas. Pour que les systèmes d’IA fonctionnent non seulement correctement, mais aussi de manière sûre et responsable, des garde-fous s’imposent. Par garde-fous, nous entendons les directives, les restrictions techniques et les cadres éthiques qui garantissent que les systèmes d’IA opèrent dans des limites acceptables. Ils empêchent un résultat indésirable ou préjudiciable et assurent la conformité des systèmes d’IA avec les valeurs humaines et les normes sociales.

Que sont exactement ces garde-fous et comment les utiliser efficacement ? C’est ce que nous allons explorer dans cet article.

La nécessité des garde-fous

Les applications basées sur des LLM comportent divers risques qui soulignent la nécessité de garde-fous solides. Sans protection adéquate, les instructions du système peuvent être dérobées. Celles-ci donnent un aperçu de la logique interne et des mécanismes de sécurité, que vous préférez ne pas voir divulgués. Il existe également un risque d’atteinte à la vie privée lorsque des données à caractère personnel parviennent à des fournisseurs de modèles externes. En outre, les modèles peuvent générer des réponses préjudiciables, allant de propos haineux à des conseils d’automutilation, ou des informations incorrectes en raison d’un résultat hallucinatoire. Les questions hors sujet peuvent entraîner une utilisation abusive de l’application et augmenter les coûts, tandis que des réponses inappropriées ou non conformes peuvent nuire à la réputation.

Pour toutes ces raisons, il est essentiel de mettre en place des mécanismes de sécurité solides, car ils constituent un rempart contre ces risques divers et contribuent à la sûreté et à la fiabilité des applications d’IA ainsi qu’à leur conformité avec les attentes des utilisateurs et des organisations.

Méthodes et techniques

Les garde-fous sont généralement déployés à deux niveaux : juste avant que les données d’entrée ne soient envoyées au modèle de langage (filtre à l’entrée) ou juste après la génération des résultats en sortie, mais avant qu’elle ne parvienne à l’utilisateur final (filtre à la sortie).

Garde-fous d’entrée et de sortie – source : https://github.com/guardrails-ai/guardrails

Il existe globalement quatre techniques pour concrètement mettre en œuvre les garde-fous.

• Les garde-fous natifs LLM sont des mécanismes de sécurité intégrés dans les services proposés par les fournisseurs des modèles eux-mêmes, celui inclut par exemple le filtrage des résultats préjudiciables ou l’exclusion de certaines instructions. Ils constituent une première ligne de défense, et doivent généralement être complétés par une ou plusieurs des techniques ci-dessous.
• Dans le cas des garde-fous basés sur le prompt, des instructions spécifiques sont ajoutées au prompt afin d’influencer le comportement du modèle. Un exemple typique consiste à obliger le modèle à répondre exclusivement sur la base des informations contextuelles fournies (via RAG) afin qu’il ne génère pas de résultats incontrôlés ou indésirables. Un autre exemple consiste à ajouter des instructions pour éviter que le système d’IA ne donne des conseils médicaux. L’exemple ci-dessous montre les instructions ajoutées au prompt pour éviter que l’application ne donne des conseils médicaux, avec un exemple de conversation dans laquelle l’application produit la réponse souhaitée.

• Les garde-fous basés sur des règles agissent de manière déterministe avec des filtres basés sur des mots exacts ou des expressions régulières. Ils permettent d’effectuer un screening sur certains mots ou sujets et de filtrer des formes simples d’informations confidentielles, telles que des identifiants, des numéros de téléphone ou des adresses e-mail.
• Les garde-fous basés sur le ML/LLM utilisent des modèles de machine learning ou des LLM-judges qui sont beaucoup plus aptes à gérer les nuances, l’intention et le contexte. Ils peuvent évaluer à la fois les entrées et les sorties et les classer, par exemple pour détecter les contenus préjudiciables ou les prompt injections (tentatives des utilisateurs de manipuler le comportement de l’application via le prompt). En outre, ils peuvent filtrer les informations sensibles et vérifier les faits en s’assurant que toutes les affirmations générées en sortie sont étayées par le contexte fourni, comme dans le cas de la RAG.

Chaque technique a son utilité, sa complexité et son coût. Aussi est-il recommandé d’évaluer d’abord les risques spécifiques à un cas d’utilisation particulier, puis de déterminer les garde-fous réellement nécessaires. Commencez par les méthodes les plus simples (basées sur un prompt et des règles) et ne passez à des techniques plus complexes (basées sur le ML/LLM) que lorsque cela est nécessaire. Ces dernières entraînent en effet une latence et des coûts supplémentaires.

Outils

Il existe de nombreux outils qui prennent en charge ces techniques et facilitent l’intégration de garde-fous dans une application. Les frameworks procurent un environnement complet pour définir, combiner et orchestrer des garde-fous. Ils vous permettent de configurer des règles, des workflows et des étapes de validation sans devoir tout construire vous-même. Exemples : Guardrails AI, LLM Guard et NVIDIA NeMo Guardrails.

Il existe également des API et des services qui offrent des fonctionnalités spécifiques, telles que la détection des contenus préjudiciables, le filtrage des données sensibles ou la détection des jailbreaks. Vous pouvez les appeler directement depuis votre application. Nous pouvons citer Azure AI Content Safety ou OpenAI Moderation API.

Sous le capot, ces outils utilisent une combinaison de modèles ML, de LLM-judges et de techniques basées sur des règles. Llama Guard et Prompt Guard sont des exemples de modèles ML.

Notre propre expérience montre que certains outils de protection sont nettement moins précis en néerlandais et en français qu’en anglais. Nous constatons parfois des faux positifs, par exemple lorsque la détection d’automutilation identifie à tort des phrases inoffensives comme risquées. Pour les applications simples présentant un faible profil de risque et utilisant exclusivement des données publiques, la valeur ajoutée des outils de protection supplémentaires semble limitée. Dans de tels cas, les mécanismes de sécurité intégrés au LLM, associés à un prompt RAG bien conçu, sont généralement suffisants.

Conclusion

En résumé, il est important de toujours utiliser les garde-fous de manière ciblée et stratifiée. Commencez par identifier les risques dans le cas d’utilisation spécifique, puis choisissez les techniques appropriées, en privilégiant les méthodes simples et en n’ajoutant des solutions plus complexes que lorsque cela est vraiment nécessaire. Bien qu’une combinaison de garde-fous natifs LLM, basés sur des prompts, basés sur des règles et basés sur le ML/LLM offre une protection plus robuste, il reste essentiel de comprendre qu’aucun système ne garantit une sécurité absolue. Les filtres à l’entrée et à la sortie peuvent produire à la fois des faux positifs et des faux négatifs. De plus, les garde-fous basés sur le ML/LLM occasionnent des coûts et une latence supplémentaires. Un monitoring continu de l’application d’IA est recommandé afin de détecter et de traiter rapidement les nouvelles vulnérabilités.

De wereld van AI evolueert razendsnel, en met de opkomst van Retrieval-Augmented Generation (RAG) openen zich nieuwe mogelijkheden om data en taalmodellen slim te combineren.

RAG-systemen combineren het generatieve vermogen van LLM’s met het ophalen van relevante, actuele informatie uit databronnen. Dit maakt ze krachtiger, maar ook complexer: ze zijn afhankelijk van de kwaliteit van zowel het model als de gebruikte data, en lopen risico op het verspreiden van verouderde, onjuiste of ongepaste informatie.

In een vorige blogpost bespraken we hoe automatische evaluaties kunnen helpen om de kwaliteit te meten van een RAG-systeem en het interatief te verbeteren. Maar kwaliteit alleen is niet genoeg. Om AI-systemen niet alleen goed te laten functioneren, maar ook veilig en verantwoord, zijn guardrails nodig. Onder guardrails verstaan we de richtlijnen, technische beperkingen en ethische kaders die ervoor zorgen dat AI-systemen binnen aanvaardbare grenzen opereren. Ze voorkomen ongewenste of schadelijke output en zorgen ervoor dat AI-systemen aansluiten bij menselijke waarden en maatschappelijke normen.

Wat zijn die guardrails precies en hoe zet je ze effectief in? Dat verkennen we in deze blogpost.

De nood aan guardrails

LLM-gebaseerde toepassingen brengen verschillende risico’s met zich mee die de nood aan sterke guardrails duidelijk maken. Zonder passende bescherming kunnen de systeeminstructies ontfutseld worden. Die geven inzicht in interne logica en beveiligingsmechanismen, en die zie je dus liever niet onthuld. Ook bestaat het risico op privacy­schendingen wanneer persoonlijke gegevens bij externe modelproviders terechtkomen. Daarnaast kunnen modellen schadelijke antwoorden genereren, variërend van haatspraak tot zelfbeschadigingsadviezen, of incorrecte informatie door hallucinerende output. Off-topic vragen kunnen leiden tot misbruik van de toepassing en de kosten doen oplopen, terwijl ongepaste of niet-conforme antwoorden reputatieschade kunnen veroorzaken.

Om al deze redenen zijn robuuste guardrails essentieel, omdat ze een buffer vormen tegen deze uiteenlopende risico’s en helpen garanderen dat AI-toepassingen veilig, betrouwbaar en conform de verwachtingen van gebruikers en organisaties functioneren.

Methodes en technieken

Guardrails worden doorgaans op twee niveaus ingezet: vlak vóór de input het taalmodel bereikt (inputfilter), of net na het genereren van de output maar vóór die bij de eindgebruiker terechtkomt (outputfilter).

Input & output guardrails – bron: https://github.com/guardrails-ai/guardrails

In grote lijnen bestaan er vier technieken om guardrails concreet te implementeren.

• LLM-native guardrails zijn ingebouwde veiligheidsmechanismen die modelproviders zelf voorzien, zoals het vermijden van schadelijke outputs of beperkingen bij het volgen van bepaalde instructies. Ze bieden een eerste verdedigingslinie, maar moeten doorgaans aangevuld worden met één of meerdere van de technieken hieronder.
• Bij prompt-gebaseerde guardrails worden specifieke instructies toegevoegd aan de prompt om het gedrag van het model te beïnvloeden. Een typisch voorbeeld is om het model te verplichten om uitsluitend te antwoorden op basis van aangeleverde contextinformatie (via RAG) zodat het geen ongecontroleerde of ongewenste output genereert. Een ander voorbeeld is het toevoegen van instructies om te vermijden dat het AI-systeem medisch advies geeft. In het voorbeeld hieronder zijn instructies te zien die toegevoegd worden aan de prompt om te vermijden dat de toepassing medisch advies geeft, samen met een voorbeeld van een conversatie waarbij de toepassing het gewenste antwoord geeft.
  

  

  
  
• Regelgebaseerde guardrails werken deterministisch met filters op basis van exacte woorden of reguliere expressies. Op die manier kan gescreend worden op bepaalde woorden of onderwerpen, en kunnen eenvoudige vormen van vertrouwelijke informatie gefilterd worden, zoals ID’s, telefoonnummers of e-mailadressen.
• LLM/ML-gebaseerde guardrails maken gebruik van machine learning modellen of zogenaamde LLM-judges die veel beter overweg kunnen met nuance, intentie en context. Ze kunnen zowel input als output beoordelen en kunnen deze classificeren, bijvoorbeeld om schadelijke inhoud of prompt injections te detecteren (dit zijn pogingen van gebruikers om het gedrag van de toepassing te manipuleren via de prompt). Daarnaast kunnen ze gevoelige informatie filteren en fact-checking uitvoeren door na te gaan of alle uitspraken in de output effectief worden ondersteund door de aangeleverde context, zoals bij RAG.

Elke techniek heeft een eigen nut, complexiteit en kost. Het is daarom aangeraden om eerst de specifieke risico’s voor een bepaalde usecase te evalueren en daarna te bepalen welke guardrails echt nodig zijn. Begin met de eenvoudigste methodes (prompt-gebaseerd en regelgebaseerd) en schakel pas over op complexere technieken (LLM/ML gebaseerd) wanneer dat noodzakelijk is. Deze laatste brengen namelijk extra latency en kosten met zich mee.

Guardrail tools

Er bestaan heel wat tools die deze technieken ondersteunen en het eenvoudiger maken om guardrails in een toepassing te integreren. Frameworks bieden een volledige omgeving om guardrails te definiëren, combineren en orkestreren. Ze laten je regels, workflows en validatiestappen configureren zonder alles zelf te moeten bouwen. Voorbeelden zijn Guardrails AI, LLM Guard en NVIDIA NeMo Guardrails.

Daarnaast zijn er API’s en services die specifieke functionaliteiten aanbieden, zoals het detecteren van schadelijke inhoud, het filteren van gevoelige gegevens of het opsporen van jailbreaks. Deze kun je rechtstreeks vanuit je toepassing aanroepen. Denk hierbij aan Azure AI Content Safety of OpenAI Moderation API.

Onder de motorkap maken deze tools gebruik van een mix van ML-modellen, LLM-judges en regelgebaseerde technieken. Voorbeelden van ML-modellen zijn Llama Guard en Prompt Guard.

Uit onze eigen ervaringen blijkt dat bepaalde guardrailtools merkbaar minder nauwkeurig presteren in het Nederlands en Frans ten opzichte van het Engels. We zien daarbij soms ook false positives, bijvoorbeeld wanneer selfharm-detectie onschadelijke zinnen foutief als risicovol markeert. Voor eenvoudige toepassingen met een laag risicoprofiel en uitsluitend publieke data lijkt de meerwaarde van extra guardrailtools beperkt. In zulke gevallen volstaan doorgaans de ingebouwde veiligheidsmechanismen van de LLM in combinatie met een goed ontworpen RAG-prompt.

Conclusie

Samengevat is het belangrijk om guardrails steeds risicogestuurd en gelaagd in te zetten. Begin met het identificeren van de risico’s binnen de specifieke usecase en kies vervolgens de passende technieken, waarbij eenvoudige methodes de voorkeur krijgen en complexere oplossingen pas worden toegevoegd wanneer dat echt nodig is. Hoewel een combinatie van LLM-native, prompt-gebaseerde, regelgebaseerde en ML/LLM-gebaseerde guardrails een robuustere bescherming biedt, blijft het essentieel om te beseffen dat geen enkel systeem volledige veiligheid garandeert. Input- en outputfilters kunnen zowel false positives als false negatives opleveren. ML/LLM-gebaseerde guardrails brengen bovendien extra kosten en latency met zich mee. Een continue monitoring van de AI-toepassing is aangeraden om nieuwe kwetsbaarheden tijdig op te sporen en aan te pakken.

Sauf indication contraire, cet article fait référence à la législation belge en vigueur au 15 octobre 2025. Les interprétations des textes législatifs dans cet article sont fournies à titre indicatif uniquement et ne font en aucun cas autorité.

Dans une utopie administrative, le parlement vote une loi ou le gouvernement prend une décision qui modifie quelque chose, et le logiciel utilisé pour sa mise en œuvre pratique peut être adapté presque automatiquement à la modification. Le concept d’un lien étroit entre la réglementation et sa mise en œuvre logicielle est également connu sous le nom de Rules as Code, ou RaC.

Au départ, il a surtout été exploré dans le monde juridique, dans les milieux universitaires, dans les incubateurs du secteur, parmi les professionnels du droit ou chez les innovateurs intéressés par la LegalTech. Un nouvel élan est apparu en 2020 lorsque l’OCDE a publié un rapport volumineux dans lequel elle fait le point sur la situation du point de vue des pouvoirs publics, en se référant à des preuves de concept provenant de différents pays. Cela venait à point nommé, car la pandémie de COVID-19 cette même année avait confronté les gouvernements et leurs fournisseurs informatiques à des directives et des mesures en constante évolution à mesure que les connaissances scientifiques sur la maladie progressaient, et à une pression temporelle sans précédent pour mettre en œuvre chaque update le plus rapidement possible. Une technologie capable de faciliter la mise en œuvre harmonieuse de nouvelles réglementations est donc la bienvenue.

Certains pays sont donc passés à la vitesse supérieure. La France est en tête en matière de preuves de concept fonctionnelles, notamment avec les simulateurs Mes Droits Sociaux, LexImpact et divers projets basés sur des publicodes. Des initiatives sont également en cours au Canada, en Australie, en Nouvelle-Zélande et aux Pays-Bas. L’UE a publié un article thématique informatif sur sa plateforme GovTech Connect, mentionnant plusieurs autres sources, et aux États-Unis également, des voix s’élèvent pour attirer l’attention sur ce sujet. Enfin, une étude néerlandaise approfondie nous fournit un aperçu pratique et récent des solutions Rules as Code.

Domaines d’application

Ce serait bien de pouvoir convertir une loi de manière semi-automatique en un logiciel (de préférence correct). Cependant, les expériences menées en Nouvelle-Zélande nous ramènent à la réalité et démontrent de manière convaincante qu’une correspondance parfaite entre la loi et le logiciel correspondant, si tant est qu’elle soit réalisable, est même indésirable dans de nombreux cas.

L’application des règles nécessite en effet une interprétation. Ainsi, la formulation de nombreuses lois est délibérément maintenue quelque peu abstraite, afin de les rendre largement applicables ou d’éviter que des lacunes n’apparaissent trop rapidement lorsque la société évolue. Pour chaque application pratique, ces concepts abstraits doivent être concrétisés. Ce n’est pas toujours facile : quand les petites réparations d’une maison louée sont-elles “de nature structurelle” (et donc à la charge du propriétaire) ? Quand les mesures RGDP sont-elles “suffisantes” ? Une dépense est-elle ou non une “dépense professionnelle déductible” ? Et qui sont exactement ces vagues “autorités compétentes” auxquelles le texte de loi fait référence ? Tout cela fait l’objet de discussions.

Les circulaires ou les décisions administratives permettent parfois aux autorités publiques de clarifier l’interprétation souhaitée, mais il est rare d’aboutir à un ensemble complet et cohérent de règles. En cas d’ambiguïté, une différence minime d’interprétation peut faire toute la différence. Si nous imaginons une conversion entièrement automatique du texte de loi en logiciel, nous risquons de sauter ces étapes d’interprétation ou de les laisser remplir sans beaucoup de finesse par des valeurs par défaut préprogrammées. Tout juriste frémirait à cette idée, et à juste titre.

Rules as Code n’est donc pas la panacée et trouve surtout des applications lorsque les règles sont sans ambiguïté et ne nécessitent que peu d’interprétation, ou lorsque les imprécisions sont acceptables et peuvent être conservées dans le résultat final. L’exemple classique est un ensemble de règles qui peuvent être réduites à un arbre de décision basé sur des critères objectivement calculables. Les applications associées sont, par exemple, les formulaires de demande, les simulateurs ou les modules de calcul. Les réglementations de nature plutôt normative, telles que les règlements de l’UE qui utilisent fréquemment des termes vagues tels que “suffisant”, “adéquat”, “approprié”, “pertinent”, etc. ne s’y prêtent pas, ce que certains universitaires ont judicieusement formulé ainsi : “la justice ne peut être automatisée“.

Obstacles

Dès que l’on commence à transposer la réglementation en code, on se heurte rapidement à la complexité des liens internes entre toutes sortes de lois et de décisions. Un bon exemple est l’âge de la retraite aux Pays-Bas : bien que défini de manière assez simple à l’article 7a de la loi concernée, il affecte ou est cité dans au moins 100 autres lois ou statuts néerlandais. Si l’on y touche, on risque donc rapidement de provoquer un effet domino important.

En outre, le législateur fait preuve de créativité lorsqu’il s’agit de trouver des solutions à certaines situations rares. Il est courant de revoir ou d’élargir les définitions, ou d’ajouter des exceptions ou des conditions supplémentaires. Chaque amendement peut à son tour renvoyer à d’autres règles ou lois, ce qui entraîne toute une série de dépendances.

Prenons le concept de majorité. En théorie, c’est une règle simple : toute personne âgée de 18 ans ou plus est majeure et donc capable d’exercer ses droits civils (art. 488 de l’ancien Code civil). Cependant, ce tout petit article est suivi d’une série d’articles beaucoup plus longs sur les exceptions à cette règle (art. 488/1 et suivants), jusqu’à l’administration (art. 494–502). Si cela ne suffit pas, le juge de paix peut également intervenir (art. 492) et statuer sur une longue liste de capacités qui, au moment de la rédaction du présent document, comprend déjà 42 éléments distincts (art. 492/1 §2 + §3) .

Supposons qu’un service public soit autorisé à octroyer des subventions sur la base d’un règlement qui impose la majorité comme condition et que nous souhaitions créer un site web permettant aux citoyens de vérifier leur éligibilité. Dans ce cas, programmer if (x≥18) n’est pas toujours suffisant. Une personne sous tutelle qui n’est pas autorisée à gérer ses propres finances peut devoir obtenir une autre réponse. Cela n’est pas nécessairement explicitement mentionné dans le règlement relatif aux subventions, mais découle de l’application de la définition de la majorité civile telle qu’elle figure dans le code civil.

Mais ce n’est pas tout : les lois peuvent étendre ou modifier les définitions antérieures. Ainsi, le concept de majorité est élargi dans la loi sur l’intégration sociale : les personnes mineures mariées, enceintes ou ayant des enfants à charge sont assimilées à des personnes majeures (art. 7), mais uniquement pour l’application de cette loi. En résumé : toute personne majeure a plus de 18 ans, mais toutes les personnes âgées de plus de 18 ans ne sont pas pleinement indépendantes, et la notion de majorité peut en outre varier selon le domaine d’application.

L’aspect temporel introduit une dimension de complexité supplémentaire. En effet, toutes ces règles n’ont pas toujours été en vigueur. En Belgique, la majorité à 18 ans n’est entrée en vigueur que le 1er mai 1990 (loi du 19 janvier 1990, publiée au Moniteur belge le 30 janvier 1990). Auparavant, il fallait avoir 21 ans. La tutelle générale mentionnée ci-dessus a été précédée par différents statuts spéciaux, dont la “minorité prolongée” et la “tutelle provisoire”. Ces derniers ont été supprimés en 2014, mais en raison d’une disposition transitoire, ils n’ont disparu dans la pratique que le 1er septembre 2019. Des changements surviennent également en raison de fusions communales, de réformes de l’État, de pays qui n’existent plus, de règles temporaires telles que les mesures de soutien COVID, etc.

Même si une ancienne législation a été abrogée depuis des années, ses effets peuvent encore se faire sentir longtemps. Nous voyons ainsi sur notre déclaration d’impôts de 2025 une déduction pour “cotisations spéciales de sécurité sociale des années 1982 à 1988” (cadre VIII, code 1388-67). Les droits sociaux acquis dans le cadre de statuts ou de régimes qui n’existent plus aujourd’hui continuent également de compter. Si un calcul dépend d’une situation passée et de la législation en vigueur à l’époque, il peut donc être nécessaire d’implémenter dans un logiciel non seulement la réglementation actuelle, mais aussi tout son historique.

Toute cette complexité, même dans des concepts simples, ne peut que donner lieu à des lacunes ou des incohérences. Le Conseil d’État a fort à faire pour conseiller le législateur et corrige régulièrement les erreurs dans les projets de texte. Même dans ce cas, le Moniteur belge doit souvent publier des errata. Le gouvernement est parfois chargé de définir les détails du contenu, mais les arrêtés royaux ou ministériels se font attendre, ce qui crée un vide pendant un certain temps. D’autres fois, la formulation n’est pas assez précise : par exemple, on ne précise pas s’il s’agit de jours calendaires ou de jours ouvrables.

Lorsque des lacunes, des contradictions apparentes ou des interprétations donnent lieu à des discussions, la Cour de cassation doit parfois clarifier certaines choses. Bien que cela ne garantisse pas une réduction de la confusion linguistique à l’avenir, comme en témoigne ce récent arrêt dans lequel il est précisé qu’un véhicule à moteur au sens de la loi sur la circulation routière ne doit pas être compris comme un véhicule à moteur tel que défini dans le code de la route…

Enfin, il existe des cas où le texte de loi lui-même est grammaticalement ambigu. Ainsi, dans l’arrêté d’exécution du Gouvernement de la Région de Bruxelles-Capitale relatif aux travaux exemptés de permis d’urbanisme, il est mentionné à l’article21/1, 3° : “[…] la pose d’isolation […] sur un mur mitoyen ou une façade non visible depuis l’espace public […]”. Il n’est pas clair ici si la phrase subordonnée (“non visible depuis l’espace public”) se rapporte uniquement à la façade ou à la fois à la façade et au mur mitoyen. Sans doute au grand dam de homegrade.brussels, qui doit conseiller les particuliers à ce sujet et qui doit admettre dans sa fiche d’information sur le sujet : “Cet article est sujet à diverses interprétations”.

Cela représente déjà un défi de taille dans le cadre du développement d’applications classiques. La tâche serait-elle plus simple si nous construisions notre application autour d’un framework Rules as Code ? Pas vraiment : un framework RaC peut fournir une méthodologie ou une approche fixe, mais cela ne suffit pas à éliminer la complexité : la même quantité d’informations doit toujours être programmée, et les ambiguïtés continuent de poser les mêmes problèmes. Certains moteurs RaC permettent de détecter les lacunes dans les règles, mais il faut encore décider quoi en faire. Bien définir le projet et fixer des limites reste nécessaire pour éviter d’être submergé par une avalanche de dépendances, de références et d’historique des modifications.

La base : l’analyse législative

Supposons que nous voulions créer un logiciel qui mette en œuvre une certaine législation et qui calcule, par exemple, si vous avez droit à une subvention spécifique et, si oui, à quel montant.

Tout d’abord, il faut trouver un moyen de convertir cette loi en une forme structurée qui facilite la conversion en code. Grâce à une analyse législative, nous essayons de décomposer chaque règle de cette loi en ses différents éléments. Le schéma d’analyse ci-dessous, provenant du ministère néerlandais de l’Intérieur, est générique et prévoit une division en 15 classes :

Les variables sont des caractéristiques qui peuvent varier pour chaque sujet de droit (personne ou entité) : pour une personne, il s’agit par exemple du sexe, du lieu de résidence, du nom, de l’état civil. Les paramètres, en revanche, sont les caractéristiques de la règle qui sont identiques pour tout le monde : un champ d’application, une date de début, une valeur d’indice, etc. Ainsi, une circulaire aura souvent pour objectif d’adapter des paramètres tels que la valeur de l’indice, tandis qu’une loi définira quelles variables peuvent être prises en compte dans l’application d’une règle et dans quelles conditions. Il est parfois difficile de déterminer si un terme relève des variables ou des paramètres. Les créateurs de cette méthode fournissent pour chaque catégorie une description et des exemples qui clarifient la manière dont ils peuvent être exprimés dans un texte législatif.

Prenons l’exemple du droit au congé de maternité, régi par le chapitre IV, art.39 et suivants de la loi sur le travail. En résumé, la règle de base est qu’une femme enceinte a droit à ce congé à partir de 6 semaines avant la date prévue de l’accouchement estimée par le médecin (8 semaines en cas de grossesse multiple), plus 9 semaines après l’accouchement. Une analyse rudimentaire de cette règle selon le schéma ci-dessus peut être commencée comme suit :

• La femme, son employeur et son médecin sont tous des sujets de droit, liés entre eux par une relation de travail ou une relation médecin-patient qui sont des relations juridiques.
• L’une des conditions de cette loi est que la date de l’accouchement soit estimée par un médecin dans un certificat médical remis à l’employeur. Ce certificat est ici un objet juridique.
• Les variables applicables à la femme sont notamment : le nombre d’enfants qu’elle attend, son lieu de résidence, son lieu de travail, la date prévue pour l’accouchement… Elles sont différentes pour chaque femme.
• Les paramètres de cette loi sont notamment les délais minimaux et maximaux mentionnés : 6 semaines, 8 semaines, 9 semaines… Ils sont identiques pour toutes les femmes.
• L’indication de la durée et du lieu précise où et quand la règle s’applique : sur le territoire belge, et depuis les dernières modifications législatives, c.à.d. à partir du 1er juillet 2004 pour la partie prénatale et du 1er mars 2009 pour la partie postnatale du congé de maternité. L’historique des paramètres peut également être consigné. Les variables peuvent également comporter des indications temporelles si elles évoluent dans le temps.

La réglementation effective prévoit notamment des situations exceptionnelles pour les enfants prématurés, malades ou mort-nés, etc. En tenir compte dans l’analyse peut conduire à l’ajout de nombreux paramètres et variables supplémentaires afin de couvrir toutes ces exceptions.

La règle de déduction prend alors la forme d’un calcul, dans lequel :

• l’input consiste en une “situation” décrite comme un ensemble de variables,
• les conditions permettent d’activer ou non certains composants du calcul,
• les paramètres donnent un poids aux composants du calcul,
• l’output peut être une valeur catégorielle ou numérique,
• le calcul peut s’appuyer sur d’autres règles de déduction avec leurs propres paramètres, conditions et variables.

Nous sommes libres de choisir le niveau de granularité ou la profondeur de notre analyse. Nous pouvons pinailler et essayer d’encoder chaque détail de la réglementation, mais nous pouvons tout aussi bien nous contenter de faire quelques généralisations, ne serait-ce que pour éviter que le logiciel final ait plus de boutons qu’un cockpit d’avion. Nous avons donc pris la femme comme point de départ ci-dessus, mais en réalité, la loi parle d’employée. Cela implique un contrat de travail valide. Nous pouvons intégrer cela avec des variables et des conditions supplémentaires, et même avec des règles supplémentaires sur les contrats de travail, mais cela apporte-t-il une valeur ajoutée ? Il peut suffire de laisser les choses telles quelles et d’indiquer dans une clause de non-responsabilité que l’application ne s’applique qu’aux employées.

Traduire correctement la législation en code n’est donc pas chose aisée et nécessite de prendre en compte certains éléments. Il est utile à cet égard d’établir une collaboration étroite entre les juristes, qui peuvent expliquer clairement les règles, et les développeurs de logiciels qui doivent les traduire en code informatique, avec ou sans approche RaC. Il en résulte également de nouveaux profils combinant des compétences juridiques et techniques : nous assistons progressivement à l’émergence de “legal engineers” et de “programmateurs politiques”. 

L’approche Rules as Code

L’objectif d’une approche Rules as Code est de traduire les lois, les règles, les politiques, etc. dans un format structuré compréhensible par une machine. Cela peut ensuite être directement intégré dans des applications ou des sites web. L’idée est que ces applications puissent ainsi être plus facilement adaptées à une réglementation en constante évolution et que les utilisateurs puissent compter sur une plus grande transparence grâce au lien direct avec la législation.

Il n’existe pas de normes internationalement reconnues pour l’analyse législative, ni pour l’encodage des textes législatifs. L’exemple néerlandais ci-dessus est applicable de manière générique, mais cette initiative est encore jeune. Les moteurs Rules as Code existants utilisent d’autres conventions, qui peuvent varier considérablement les unes des autres. Ils définissent généralement leur propre encodage, sous la forme d’un Domain-Specific Language ou d’un Controlled Natural Language, dans lequel la réglementation doit d’abord être convertie. Ce n’est qu’une fois cette étape franchie que d’autres applications peuvent être développées.

L’absence de formats, de modèles et d’ontologies standardisés rend difficile l’adoption de Rules as Code. Entre les différents preuves de concept dans différents pays, parfois même au sein d’un même pays, l’interopérabilité reste encore assez faible. Chaque pays ou chaque département risque ainsi d’utiliser son propre langage, approche ou méthodologie, ce qui entraîne une fragmentation et une duplication des efforts. Idéalement, il faudrait viser un vocabulaire standardisé et des règles publiées dans un format uniforme, afin qu’elles puissent être réutilisées et échangées entre différents systèmes et services publics.

Parmi les outils Rules as Code existants d’une certaine importance, on trouve OpenFisca, PubliCodes, Català et RegelSpraak. Nous nous tenons délibérément à distance des BPMN, CMMN, langages de programmation logiques et rule engines classiques, qui ne sont pas adaptés aux textes juridiques. Dans un prochain article, nous approfondirons notre analyse en nous focalisant sur les outils spécialement conçus pour la législation, et nous en choisirons un pour l’étudier en détail sur le plan technique.

Conclusion provisoire

Les frameworks Rules as Code fournissent une méthode uniforme et générique pour analyser la législation. Ils offrent aux programmeurs une bibliothèque contenant les éléments de base nécessaires pour mettre en œuvre la réglementation et créer des scénarios de test, quel que soit le domaine dans lequel ils travaillent. En analysant la réglementation et en la convertissant en un domain-specific language, celle-ci peut être traitée par un rule engine ou un interpreter. Il est important de noter que cette conversion nécessite pour l’instant un travail humain minutieux et analytique, car elle implique une interprétation. (L’externalisation de cette étape à de grands modèles de langage ne donne pas de résultats entièrement positifs, mais nous y reviendrons dans un prochain article).

Le niveau de détail de nombreuses réglementations rend l’analyse et la conversion vers un format Rules as Code rarement aisée. Si l’on souhaite aboutir à un système complet et cohérent qui tienne compte de nombreuses dépendances et situations exceptionnelles, on se retrouve confronté à une quantité impressionnante de paramètres et de variables. Si les calculs doivent pouvoir être rétroactifs et que l’historique de la législation joue également un rôle, cela ajoute une dimension supplémentaire. Les interdépendances internes entre toutes les règles font que, pour mettre en place une application Rules as Code, il faut rapidement s’attendre à un effort initial important.

L’un des arguments en faveur du Rules as Code est qu’il permettrait de développer certains types d’applications de manière générique pour n’importe quel domaine : eligibility checkers, compliance tools, tax/benefit calculators, formulaires web, simulateurs de calcul, gestion de dossiers, etc. Tant que la législation sous-jacente est suffisamment claire et concrète, une même application template pourrait être utilisée sans trop de modifications dans tous les départements gouvernementaux. Cette idée louable se heurte toutefois à des difficultés pratiques liées à la législation elle-même, qui se réinvente presque dans chaque domaine : il est ainsi difficile de développer des composants communs pour la majorité ou les véhicules à moteur lorsque ces termes ont des définitions différentes dans différentes lois.

Une autre promesse de Rules as Code est que les applications développées sur la base de tels frameworks restent étroitement liées à la législation, ce qui peut également être rendu visible. Ce lien doit offrir des garanties plus transparentes qu’une application est bien conforme à la législation et qu’elle le restera si cette législation venait à changer demain. En outre, il existe un potentiel pour aider à l’élaboration de règles. Un processus itératif dans lequel une version RaC des règles est élaborée parallèlement à la version préliminaire du texte peut permettre de détecter et de combler rapidement les lacunes, voire de faciliter l’analyse politique ex ante en simulant d’abord l’impact de modifications législatives hypothétiques (voir également le rapport de l’OCDE à ce sujet). Il n’en reste pas moins que, même avec le framework RaC, la mise en œuvre de ce processus nécessite les mêmes investissements importants.

Pour rassurer ceux qui craignent que les ordinateurs ne prennent bientôt le contrôle du système judiciaire, nous en sommes encore très loin. Rappelons également que le RGPD, dans son article 22, fixe des limites claires à la prise de décision automatique. En outre, une version codifiée d’une loi n’a pour l’instant aucun statut juridique ni aucune validité légale : seul le texte original de la loi est contraignant. En d’autres termes, même si nous convertissons la réglementation en code, le contrôle humain reste indispensable et le Moniteur belge a toujours le dernier mot.

Affaire à suivre…

Noot: dit artikel refereert naar Belgische wetgeving zoals deze gold op 15 oktober 2025, tenzij waar anders aangeduid. De interpretaties van wetteksten in dit artikel dienen slechts ter illustratie en zijn in geen geval autoritatief.

In een administratief utopia stemt het parlement een wet, of neemt de regering een besluit, dat iets wijzigt, en kan de software gebruikt voor de praktische uitwerking ervan haast automatisch aangepast worden aan de wijziging. Het concept van een nauwe koppeling tussen regelgeving en de softwarematige implementatie ervan, staat ook bekend onder de naam Rules as Code, afgekort RaC.

Initieel werd het vooral verkend in de juridische wereld, in academia, in incubatoren in de sector, onder juridische professionals, of bij innovatoren met interesse in LegalTech. Een hernieuwd elan kwam er in 2020 toen de OESO een lijvig rapport publiceerde waarin ze een stand van zaken geeft vanuit overheidsperspectief, daarbij refererend naar proof-of-concepts uit verschillende landen. Goed getimed, want de COVID-pandemie in datzelfde jaar had overheden en hun IT-leveranciers geconfronteerd met snel wijzigende richtlijnen en maatregelen naarmate de wetenschappelijke kennis over de ziekte toenam, en een ongeziene tijdsdruk om elke update zo snel mogelijk in de praktijk om te zetten. Technologie die een soepele implementatie van nieuwe regulering kan faciliteren, klinkt dan als muziek in de oren.

Sindsdien zijn enkele landen dan ook een versnelling hoger geschakeld. Frankrijk loopt op kop wat betreft werkende proof-of-concepts, waaronder simulatoren op Mes Droits Sociaux, LexImpact, en verscheidene projecten gebaseerd op publicodes. Ook in Canada, Australië, Nieuw-Zeeland en Nederland lopen er initiatieven. De EU publiceerde een informatief thema-artikel op haar GovTech Connect platform met vermelding van verschillende andere bronnen, en ook in de VS gaan stemmen op om er aandacht aan te besteden. Een diepgaande Nederlandse studie tenslotte voorziet ons van een handig en recent overzicht van Rules as Code oplossingen.

Toepassingsdomein

Het klinkt mooi om een wet semi-automatisch te kunnen omzetten in (liefst correcte) software. Ervaringen uit Nieuw-Zeeland zetten ons echter met de voeten op de grond en tonen overtuigend aan dat een 1-op-1 mapping tussen wet en bijhorende software, als dat al haalbaar is, in veel gevallen zelfs onwenselijk is.

De toepassing van regels vereist immers interpretatie. Zo wordt de verwoording van veel wetgeving met opzet enigszins abstract gehouden, om ze breed toepasbaar te maken, of om te voorkomen dat er te snel mazen ontstaan wanneer de samenleving evolueert. Voor elke praktische toepassing moeten die abstracte concepten concreet ingevuld worden. Dat is niet altijd gemakkelijk: wanneer zijn kleine reparaties aan een huurhuis “structureel van aard” (dus voor rekening van de huisbaas)? Wanneer zijn GDPR-maatregelen “voldoende”? Is een uitgave wel of niet een “aftrekbare beroepskost”? En wie zijn nu exact die vage “bevoegde instanties” waar de wettekst naar verwijst? Allemaal voer voor discussie.

Via omzendbrieven of rulings wordt de gewenste interpretatie soms wel verder verduidelijkt van overheidswege, maar dan nog kom je zelden tot een volledige en sluitende verzameling regels. Is er onduidelijkheid, dan kan een miniem verschil in interpretatie een zaak maken of kraken. Beelden we ons een volautomatische omzetting van wettekst naar software in, dan riskeren we deze interpretatieve stappen over te slaan of zonder veel finesse te laten invullen door voorgeprogrammeerde default-waarden. Elke jurist zal huiveren bij dat idee, en terecht.

Rules as Code is dus niet zaligmakend en vindt vooral toepassingen waar regels ondubbelzinnig zijn en weinig interpretatie behoeven, of wanneer vaagheden aanvaardbaar zijn en behouden kunnen blijven in het eindresultaat. Het klassieke voorbeeld is een set regels die te herleiden zijn tot een beslisboom op basis van objectief berekenbare criteria. Applicaties die daarmee gepaard gaan zijn bijvoorbeeld aanvraagformulieren, simulatoren of rekenmodules. Regelgeving die eerder normatief van aard is, zoals EU-verordeningen met hun veelvuldig gebruik van vage termen zoals “voldoende”, “adequaat”, “geschikt”, “relevant”, … leent zich er niet toe – wat enkele academici gevat verwoord hebben als: “rechtvaardigheid kan men niet automatiseren”.

Hindernissen

Eens men begint aan de oefening om regelgeving om te zetten in code, botst men al snel op de complexe interne verwevenheden tussen allerlei wetten en besluiten. Een mooie illustratie is de Nederlandse pensioenleeftijd: zelf vrij rechttoe rechtaan gedefinieerd in artikel 7a van de betreffende wet, heeft ze impact op, of wordt ernaar verwezen in, minstens 100 andere Nederlandse wetten of statuten. Als daaraan gemorreld wordt, riskeer je dus al snel grote domino-effecten.

Daarnaast komt de wetgever creatief uit de hoek als er oplossingen gevonden moeten worden voor bepaalde zeldzame situaties. Het herbekijken of uitbreiden van definities, of toevoegen van uitzonderingsbepalingen of extra voorwaarden, is courante praktijk. Elk amendement kan op zijn beurt verwijzen naar weer andere regels of wetten, wat een hele keten aan afhankelijkheden met zich meebrengt.

Neem het concept van meerderjarigheid. In theorie is dat een eenvoudige regel: wie 18 is of ouder, is meerderjarig en bijgevolg handelingsbekwaam (art. 488 oud B.W.). Dat piepkleine artikeltje wordt echter gevolgd door een resem veel langere artikels over de uitzonderingen daarop (art.488/1 e.v.), tot en met bewindvoering (art. 494–502). Als dat niet voldoet, kan ook de vrederechter ingrijpen (art.492) en oordelen over een waslijst aan bekwaamheden die op moment van schrijven al 42 afzonderlijke items bevat (art.492/1 §2 + §3).

Stel dat een overheidsdienst subsidies mag uitdelen op basis van een reglement dat meerderjarigheid als voorwaarde stelt, en we willen een website bouwen waar burgers een eligibility check kunnen doen, dan is if (x≥18) programmeren niet altijd voldoende. Iemand die onder bewindvoering staat en zijn eigen geldzaken niet mag beheren, moet mogelijk alsnog een ander antwoord krijgen. Dat staat niet noodzakelijk expliciet in dat subsidiereglement, maar is een gevolg van het hanteren van de definitie van meerderjarigheid uit het burgerlijk wetboek.

Daarmee is de kous nog niet af: wetten kunnen eerdere definities uitbreiden of wijzigen. Zo wordt het concept van meerderjarigheid in de wet op de Maatschappelijke Integratie verruimd: minderjarigen die gehuwd zijn, zwanger zijn, of kinderen ten laste hebben worden gelijkgesteld aan meerderjarig (Art. 7) – maar enkel voor de toepassing van die wet. Samengevat: elke meerderjarige is 18+, maar niet elke 18+er is ten volle zelfstandig meerderjarig, en wat begrepen mag worden onder meerderjarigheid kan bovendien per toepassingsgebied nog verschillen.

Het temporele aspect voegt daar nog een hele dimensie van complexiteit aan toe. Niet al deze regels golden immers altijd. De meerderjarigheid op 18 jaar is in België pas in werking getreden op 1 mei 1990 (wet van 19 januari 1990, gepubliceerd in het Belgisch staatsblad op 30 januari 1990). Voordien moest men 21 zijn. De hierboven aangehaalde algemene bewindvoering werd dan weer voorafgegaan door verschillende speciale statuten, waaronder “verlengde minderjarigheid” en “voorlopige bewindvoering”. Deze werden afgeschaft in 2014, maar door een overgangsbepaling doofden ze pas uit in de praktijk op 1 september 2019. Wijzigingen gebeuren ook door gemeentelijke fusies, staatshervormingen, landen die niet meer bestaan, tijdelijke regels zoals de COVID-steunmaatregelen, …

Al is oude wetgeving al jaren opgeheven, de effecten ervan kunnen nog lang nazinderen. Zo zien we op onze belastingaangifte in 2025 nog een aftrekpost voor “bijzondere bijdragen voor de sociale zekerheid van de jaren 1982 tot 1988” (vak VIII, code 1388-67). Ook sociale rechten opgebouwd in statuten of regimes die vandaag niet meer bestaan, tellen nog steeds mee. Als een berekening afhangt van een situatie uit het verleden en de destijds geldende wetgeving, kan het dus nodig zijn om in een applicatie naast de huidige regelgeving ook de hele voorgeschiedenis ervan te implementeren.

Met al deze complexiteit in zelfs eenvoudige concepten, kan het niet anders of er duiken onvolledigheden of inconsistenties op. De Raad van State heeft haar handen vol met het adviseren van de wetgever, en haalt regelmatig fouten uit ontwerpteksten. Zelfs dan moet het Staatsblad vaak nog errata publiceren. Soms wordt de invulling van inhoudelijke details overgelaten aan de regering, maar laten de Koninklijke of ministeriële besluiten lang op zich wachten, waardoor er een tijd lang een vacuüm ontstaat. Andere keren is men niet exact genoeg in de verwoording: men verduidelijkt bijvoorbeeld niet of men spreekt over kalenderdagen of werkdagen.

Daar waar onvolledigheid, ogenschijnlijke tegenspraak of interpretatie voor discussie zorgt, moet het Hof van Cassatie soms één en ander ophelderen. Al is dat geen garantie op minder spraakverwarring in de toekomst, getuige dit recente arrest waarin ze aanstippen dat een motorvoertuig in de Wegverkeerswet, niet begrepen mag worden als een motorvoertuig zoals gedefinieerd in de Wegcode…

Tot slot zijn er nog gevallen waar de wettekst zelf grammaticaal ambigu is. Zo wordt in het uitvoeringsbesluit van de Brusselse Hoofdstedelijke Regering over werken die vrijgesteld zijn van stedenbouwkundige vergunning, vermeld in art. 21/1, 3° lid: “[…] de plaatsing van isolatie […] op een mandelige muur of een gevel die niet zichtbaar is vanaf de openbare ruimte […]”. Het is hier onduidelijk of de bijzin (aangevat met die) enkel betrekking heeft op de gevel, of zowel op de gevel als op de gedeelde muur. Ongetwijfeld tot ergernis van homegrade.brussels, dat particulieren hierover moet adviseren, en in haar informatiefiche over het onderwerp moet toegeven: “Dit artikel is voor verschillende interpretaties vatbaar”.

Dit alles is bij klassieke applicatie-ontwikkeling al een hele kluif. Wordt het dan eenvoudiger als we onze app bouwen rond een Rules as Code-framework? Niet echt: een RaC-framework reikt misschien een vaste methodiek of werkwijze aan, maar dat neemt de complexiteit niet weg: dezelfde karrevracht informatie moet er nog steeds ingeprogrammeerd worden, en ambiguïteiten blijven voor dezelfde problemen zorgen. Sommige RaC-engines zullen toelaten om lacunes in de regels te detecteren, maar dan nog moet je beslissen wat je ermee doet. Het project goed afbakenen en grenzen stellen is nog steeds noodzakelijk, om te vermijden overdonderd te worden door een lawine van afhankelijkheden, verwijzingen, en wijzigingshistoriek.

De basis: wetsanalyse

Stel dat we een app willen maken die een bepaalde wetgeving implementeert, en bijvoorbeeld berekent of je recht hebt op een specifieke subsidie en zo ja, hoeveel.

Allereerst is dan een manier nodig om die wet om te zetten in een gestructureerde vorm die de omzetting naar code faciliteert. Via een wetsanalyse trachten we elke regel uit die wet te ontleden in haar onderdelen. Het analyseschema hieronder, afkomstig van het Nederlands ministerie van Binnenlandse Zaken, is generiek toepasbaar en voorziet een opdeling in 15 klassen:

De variabelen zijn eigenschappen die voor elk rechtssubject (persoon of entiteit) kunnen verschillen: voor een persoon zijn dat bijvoorbeeld het geslacht, de woonplaats, de naam, de burgerlijke staat. De parameters daarentegen zijn de eigenschappen van de regel die gelijk zijn voor iedereen: een toepassingsgebied, een startdatum, een indexwaarde, … Zo zal een omzendbrief vaak tot doel hebben om parameters zoals de indexwaarde aan te passen, en zal een wet definiëren welke variabelen onder welke voorwaarden bij de toepassing van een regel in rekening gebracht mogen worden. Het is soms moeilijk te beoordelen of een term nu onder de variabelen of de parameters valt. De makers van deze methode geven bij elke klasse een omschrijving en voorbeelden die verduidelijken hoe ze uitgedrukt kunnen worden in een wettekst.

Nemen we als voorbeeld het recht op het moederschapsverlof, geregeld in hoofdstuk IV, art. 39 e.v. van de Arbeidswet. De basisregel daarvan is, bondig samengevat, dat een zwangere vrouw recht heeft op dit verlof vanaf 6 weken vóór de door de arts geschatte datum van de bevalling (8 weken bij meerlingen), plus 9 weken na de bevalling. Een rudimentaire analyse van deze regel volgens bovenstaand schema kunnen we als volgt aanvangen:

• De vrouw, haar werkgever en haar arts zijn allen rechtssubjecten, met elkaar verbonden door een arbeidsrelatie resp. arts-patiëntrelatie die rechtsbetrekkingen zijn.
• Een van de voorwaarden in deze wet is dat de bevallingsdatum is ingeschat door een arts in een geneeskundig attest dat aan de werkgever wordt overgemaakt. Dat attest is hier een rechtsobject.
• De variabelen van toepassing op de vrouw zijn onder andere: hoeveel kinderen ze verwacht, haar woonplaats, arbeidsplaats, bevallingsdatum… dit is voor elke vrouw anders.
• Parameters van deze wet zijn o.a. de minimum- en maximumtermijnen waarvan sprake: 6 weken, 8 weken, 9 weken, … die zijn gelijk voor elke vrouw.
• Tijds– en plaatsaanduiding zeggen waar en wanneer de regel geldt: op Belgisch grondgebied, en sinds de laatste wetswijzigingen vanaf 1 juli 2004 voor het prenatale en 1 maart 2009 voor het postnatale deel van het moederschapsverlof. De voorgeschiedenis van parameters kan ook worden vastgelegd. Variabelen kunnen ook tijdsaanduidingen hebben als ze evolueren doorheen de tijd.

De eigenlijke regelgeving voorziet o.a. nog in uitzonderingssituaties voor kinderen die te vroeg, ziek, of levenloos geboren worden,… Dat meenemen in de analyse kan leiden tot de toevoeging van vele extra parameters en variabelen om al deze uitzonderingen te vatten.

De afleidingsregel neemt dan de vorm aan van een berekening, waarbij:

• de input bestaat uit een “situatie” die beschreven wordt als een verzameling variabelen,
• de voorwaarden toelaten om bepaalde componenten van de berekening te activeren of niet,
• de parameters aan componenten van de berekening een gewicht geven,
• de output zowel een categorische als numerieke waarde kan zijn,
• de berekening kan steunen op andere afleidingsregels met hun eigen parameters, voorwaarden en variabelen.

Het staat ons vrij om te kiezen hoe granulair we daarin willen zijn, of hoe diep we willen gaan in onze analyse. We kunnen pietje precies zijn en elk detail van de regelgeving proberen encoderen, maar even goed kunnen we vrede nemen met het maken van enkele veralgemeningen, al was het maar om te vermijden dat de uiteindelijke app meer knopjes heeft dan een vliegtuigcockpit. Zo namen we hierboven de vrouw als startpunt, maar eigenlijk spreekt de wet van werkneemster. Dat impliceert een geldig arbeidscontract. Dat kunnen we integreren met extra variabelen en voorwaarden, en zelfs met extra regels over arbeidscontracten, maar biedt dat ook meerwaarde? Het kan voldoende zijn om het zo te laten en in een disclaimer te zeggen dat de app enkel van toepassing is voor werkneemsters.

Wetgeving correct in code vertalen is dus niet eenvoudig, en vergt de nodige afwegingen. Het is daarbij nuttig om een nauwe samenwerking op te zetten tussen juristen, die de regels helder kunnen uitleggen, en de software-ontwikkelaars die dat in code moeten gieten, met of zonder RaC-framework. Daaruit komen ook nieuwe profielen voort met zowel juridische als technische vaardigheden: we zien stilaan “legal engineers” en “beleidsprogrammeurs” opduiken. 

de Rules as Code aanpak

Het opzet van een Rules as Code benadering is om wetten, regels, policies, … te hertalen in een gestructureerd formaat dat door een machine begrepen kan worden. Dit kan dan op zijn beurt direct geïntegreerd worden in applicaties of websites. Het idee is dat deze applicaties zo gemakkelijker kunnen aangepast worden aan snel evoluerende regelgeving, en dat ook gebruikers ervan door de directe link met de wetgeving op meer transparantie kunnen rekenen.

Er bestaan geen internationaal aanvaarde standaarden voor wetsanalyse, noch voor encodering van wettekst. Het Nederlandse voorbeeld hierboven is generiek toepasbaar, maar is nog een jong initiatief. Bestaande Rules as Code engines hanteren andere conventies, die sterk van elkaar kunnen verschillen. Ze definiëren meestal hun eigen encodering, in de vorm van een Domain-Specific Language of Controlled Natural Language, waarin de regelgeving eerst omgezet moet worden. Pas als die stap is gebeurd, kunnen er verder applicaties op worden gebouwd.

Het gebrek aan gestandaardiseerde formaten, modellen en ontologieën bemoeilijkt de adoptie van Rules as Code. Tussen de verschillende proof-of-concepts in verschillende landen, soms ook binnen hetzelfde land, is de interoperabiliteit nog steeds vrij laag. Ieder land of ieder departement dreigt zo een eigen taal, aanpak of methodiek te gaan hanteren, wat leidt tot fragmentatie en dubbel werk. Idealiter zou gestreefd moeten worden naar een gestandaardiseerd vocabularium, en regels gepubliceerd in een uniform formaat, zodat ze hergebruikt en uitgewisseld kunnen worden tussen verschillende systemen en overheidsdiensten.

Onder de bestaande Rules as Code tools van enige grootte vinden we OpenFisca, PubliCodes, Català en RegelSpraak. We houden met opzet wat afstand van BPMN, CMMN, logische programmeertalen en klassieke rule engines, die niet toegespitst zijn op juridische teksten. In een volgend artikel verdiepen we onze analyse met een focus op tools die wel specifiek gebouwd zijn voor wetgeving, waarbij we er eentje zullen kiezen om technisch in detail te bekijken.

Tussentijdse conclusie

Rules as Code frameworks voorzien in een uniforme, generieke manier om aan wetsanalyse te doen. Voor programmeurs bieden ze een library met fundamentele bouwblokken om regelgeving te implementeren en testscenario’s op te zetten, ongeacht het domein waarin men actief is. Door de regelgeving te analyseren en om te zetten naar een domain-specific language, kan die door een rule engine of interpreter verwerkt worden. Belangrijk te noteren is dat deze omzetting vooralsnog minutieus analytisch mensenwerk vergt, omdat er interpretatie bij komt kijken. (Deze stap uitbesteden aan Large Language Models leidt niet tot onverdeeld positieve resultaten, maar daarover meer in een volgend artikel).

De mate van detail in veel regelgeving, maakt een analyse en omzetting naar een Rules as Code-formaat zelden een sinecure. Wil men tot een compleet en sluitend systeem komen dat rekening houdt met vele afhankelijkheden en uitzonderingssituaties, dan wordt men geconfronteerd met overdonderende hoeveelheden parameters en variabelen. Als berekeningen retroactief moeten kunnen zijn en ook de voorgeschiedenis van de wetgeving een rol speelt, komt daar nog een extra dimensie bij. De interne verwevenheden tussen alle regels maken dat men, om een Rules as Code-app van de grond te krijgen, al snel aankijkt tegen een grote initiële inspanning.

Eén van de argumenten voor Rules as Code is dat men bepaalde soorten apps generiek zou kunnen ontwikkelen voor eender welk domein: eligibility checkers, compliance tools, tax/benefit calculators, webformulieren, rekensimulatoren, dossierbeheer,… Zolang de onderliggende wetgeving maar duidelijk en concreet genoeg is, zou dan eenzelfde template-app zonder veel aanpassingen over de grenzen van overheidsdepartementen heen benut kunnen worden. Dit lovenswaardige idee stuit in de praktijk echter op moeilijkheden door de wetgeving zelf, die zichzelf haast heruitvindt in elk domein: zo kan je moeilijk gedeelde componenten ontwikkelen voor meerderjarigheid of motorvoertuigen als die termen verschillende definities hebben in verschillende wetten.

Een andere belofte van Rules as Code is dat apps ontwikkeld op basis van zulke frameworks een nauwe koppeling behouden met de wetgeving, die ook zichtbaar gemaakt kan worden. Deze koppeling moet transparantere garanties bieden dat een app wel degelijk conformeert aan de wetgeving, en dat dat ook zo blijft als die wetgeving morgen wijzigt. Daarnaast is er potentieel om te helpen bij het opstellen van regels. Een iteratief proces waarbij een RaC-versie van de regels wordt ontwikkeld in parallel met de ontwerpversie van de tekst, kan het mogelijk maken om vroegtijdig lacunes op te sporen en te verhelpen, of kan zelfs ex ante beleidsanalyse faciliteren door de impact van hypothetische wetswijzigingen eerst te simuleren (zie daarvoor ook het OESO-rapport). Maar ook hier komt men er niet onderuit dat de uitwerking daarvan, ook mét RaC-framework, dezelfde grote investeringen vergt.

Wie vreest dat computers het rechtssysteem binnenkort gaan overnemen kunnen we dus geruststellen, daar zijn we nog heel ver van weg. We herinneren ook nog even aan de GDPR, die in art.22 duidelijke grenzen stelt aan automatische besluitvorming. Daarnaast heeft een gecodeerde versie van een wet vooralsnog geen juridische status of rechtsgeldigheid – alleen de oorspronkelijke geschreven wettekst is bindend. Met andere woorden, zelfs al zetten we regelgeving om in code, is behoud van menselijk overzicht nog steeds een must, en heeft het Staatsblad nog steeds het laatste woord.

Wordt vervolgd!

Graphs, en meer bepaald knowledge graphs, maken het mogelijk om informatie op een gestructureerde manier weer te geven. Zo krijgt een persoon een visuele samenvatting van de inhoud van een of meerdere documenten en kan een machine deze structuur gebruiken om bijvoorbeeld de inhoud ervan te analyseren (met behulp van graphalgoritmen) en/of redeneringen te maken op basis van de graph (bijvoorbeeld in het kader van een graphRAG-toepassing of om impliciete informatie te ontdekken (af te leiden)).

Dit artikel gaat in op de manieren waarop een graph kan worden verkregen op basis van tekstuele data, de verschillende soorten graphs die kunnen worden geëxtraheerd en de tools die vaak worden gebruikt, afhankelijk van het type extractie dat men wil uitvoeren.

Aangezien grote taalmodellen (LLM’s) bijzonder geschikt zijn voor tekstverwerking, zal dit artikel zich voornamelijk richten op de presentatie van LLM-gebaseerde benaderingen en vervolgens kort ingaan op verschillende alternatieve benaderingen.

Knowledge graphs: een kort overzicht

Een graph is een structuur die bestaat uit een reeks nodes en bogen (die paren van nodes met elkaar verbinden). Een knowledge graph voegt een extra semantische laag toe aan een klassieke graph, waarbij elke node een concept vertegenwoordigt (entiteit, persoon, enz.) en elke boog een relatie tussen twee concepten vertegenwoordigt (“werkt voor”, “is bevriend met”, enz.). Het is dus een weergave van kennis in de vorm van een reeks onderling verbonden entiteiten. Meer details over de verschillende soorten graphs en de bijbehorende tools vindt u hier.

Voorbereiding van het documentcorpus

Voor de eenvoud gaan we ervan uit dat de tekstdocumenten die worden gebruikt om de graph op te bouwen, correct zijn opgeschoond. Dit artikel is namelijk niet bedoeld om de voorbewerking van tekstdocumenten (scrapen van webpagina’s, extraheren van tekst uit pdf-bestanden, enz.) te bespreken, aangezien deze voorbewerking op zich al een uitgebreid onderwerp is dat ongetwijfeld een apart artikel verdient.

Fragmentatie van de tekst in “chunks”

Een belangrijke stap in de voorbereiding van tekstdata voordat entiteiten en relaties worden geëxtraheerd, is het opsplitsen van de tekst in fragmenten (meestal ‘chunks’ genoemd). We hebben het concept van chunking al meerdere keren besproken in vorige blogposts. Wanneer een document te lang is (meer dan enkele paragrafen), is het raadzaam om het op te splitsen in chunks (tekstfragmenten van redelijke omvang) die één voor één door de LLM worden verwerkt. Deze procedure maakt het mogelijk om de hoeveelheid informatie in elke chunk te beperken, zodat deze niet te veel entiteiten en relaties bevat die moeten worden geëxtraheerd. Deze opsplitsing in chunks kan op verschillende manieren gebeuren, hetzij op basis van het aantal woorden in de chunk, hetzij op basis van een vooraf gedefinieerd scheidingsteken (bijvoorbeeld een regeleinde dat het einde van de paragraaf aangeeft).

De informatie weergeven of de structuur weergeven

Laten we beginnen met de twee belangrijkste soorten graphs die kunnen worden geconstrueerd op basis van een reeks tekstdocumenten.

De eerste is een graph die de structuur van het document weergeeft (document structure graph), en niet de informatie die in de tekst staat. Bijvoorbeeld door de chunks te koppelen aan het document waaruit ze zijn gehaald en de volgorde waarin ze in het document voorkomen:

Dit type graph kan ook worden verrijkt door relaties toe te voegen tussen semantisch vergelijkbare chunks of, indien van toepassing, door de hiërarchische organisatie van het document weer te geven in secties, subsecties, enz. Dit gebeurt via nodes die de secties/subsecties vertegenwoordigen en relaties van het type “HAS_SECTION”, “HAS_SUBSECTION”, evenals relaties die de volgorde van de secties/subsecties aangeven. Zodra de graph is opgebouwd, kan deze bijvoorbeeld worden gebruikt in RAG-toepassingen voor indexeringsdoeleinden om context te bieden aan de gebruikte chunks (zie onze blogpost over graphRAG).

Het tweede type graph bestaat uit het opnemen van de informatie in de documenten in de vorm van nodes en relaties:

In het kader van deze blogpost zullen we ons concentreren op dit tweede type graph. Merk op dat beide benaderingen elkaar niet uitsluiten. Als men voor het tweede type graph kiest, is het trouwens vaak nuttig om ook de documentstructuur weer te geven. Zo kan men indien nodig teruggaan naar de bron van de informatie in de graph.

Opbouw van een knowledge graph met behulp van een LLM

Eerst zullen we de algemene procedure voor het aanmaken van een knowledge graph op basis van tekstdocumenten via LLM voorstellen, alvorens te bekijken hoe deze aan de eigen behoeften kan worden aangepast.

LLM’s ontvangen standaard tekst als input (prompt) en sturen tekst terug als output in reactie op de prompt. Afhankelijk van de instructies bieden LLM’s echter de mogelijkheid om gestructureerde outputs te genereren, zoals JSON-bestanden. Vaak wordt deze functionaliteit gebruikt als basis voor het extraheren van kennis naar een graph, omdat deze gestructureerde output systematisch kan worden verwerkt.

Een script (bv. Python) haalt de chunks op en stuurt ze een voor een naar de LLM door een gestructureerd antwoord op te leggen (bv. LangChain met de methode llm.with_structured_output()), met instructies over de taak, het type informatie dat in de tekst moet worden gedetecteerd en de structuur van het verwachte antwoord in de output. De gestructureerde output (meestal in JSON) wordt vervolgens eenvoudigweg ontleed in Python om de door de LLM gedetecteerde informatie (nodes/relaties) op te halen, die vervolgens rechtstreeks aan de graph kan worden toegevoegd (via een databasedriver).

Interessant is dat LLM’s een grote verscheidenheid aan antwoorden kunnen geven en dat het gebruik van gestructureerde output niet altijd nodig is. In sommige gevallen is het nog steeds het eenvoudigst om de LLM te vragen zijn extracties te leveren in de vorm van queries (bijvoorbeeld queries die de gedetecteerde nodes/relaties direct toevoegen), die als zodanig kunnen worden uitgevoerd, of in de vorm van RDF triples.

Na de algemene procedure, kijken we nu meer in detail naar de verschillende manieren om de informatie in de chunks binnen een graph te extraheren en weer te geven, te beginnen met de eenvoudigste benadering (thema-extractie) tot de meest complete (extractie van entiteiten en relaties).

Thematische extractie

In deze eerste benadering richten we ons op het opsporen en extraheren van de thema’s die in het document aan bod komen. We bouwen dus een thematische weergave van de verschillende documenten in het corpus om een structuur te verkrijgen van het type:

De graph heeft dus een lichte structuur en wordt gebruikt voor referentiedoeleinden, om gemakkelijk en snel documenten te identificeren die betrekking hebben op een (of meerdere) bepaald(e) onderwerp(en) van belang. Met dit type graph kunnen ook gelijkenissen tussen documenten (of tussen chunks) worden vastgesteld op basis van de gemeenschappelijke onderwerpen, of kan eenvoudigweg een schematische weergave worden gegeven van hun corpus van documenten en de thema’s die daarin aan bod komen.

Dit kan op een niet-gestuurde manier (de LLM vrij laten bepalen welke thema’s in de chunk aan bod komen) of op een gestuurde manier gebeuren (de LLM kiest een of meer thema’s uit een vooraf gedefinieerde lijst met thema’s die in de instructies van de prompt wordt gegeven).

Extractie van named entities

De extractie (of herkenning) van named entities (named-entity recognition, vaak afgekort tot NER) is een bekend domein van natuurlijke taalverwerking (natural language processing (NLP)) dat bestaat uit het detecteren en categoriseren van entiteiten (personen, organisaties, plaatsen, enz.) die in een tekst worden genoemd. Het doel is dus vergelijkbaar met dat van thematische extractie: een graph maken door tekstfragmenten te koppelen aan de entiteiten die erin worden genoemd. We krijgen dus een graph met het volgende standaard schema:

Met dit type graph kunnen ook gelijkenissen tussen documenten (of tussen chunks) worden vastgesteld op basis van de entiteiten die ze gemeenschappelijk hebben. Het is interessant om op te merken dat deze extractie vergelijkbaar is met een volledige extractie (inclusief entiteiten en relaties, zie onderstaande paragraaf), behalve dat hier alleen de entiteiten worden geëxtraheerd en niet de relaties die ze met elkaar verbinden. Dit is een lichtere en gemakkelijker te implementeren oplossing wanneer een volledige extractie niet nodig is.

Dit soort extractie kan gemakkelijk worden uitgevoerd met behulp van een LLM met gestructureerde outputs. Met het pydantic-pakket kunnen op maat gemaakte templates worden gemaakt voor de verwachte outputstructuur. Bijvoorbeeld:

from pydantic import BaseModel, Field
from typing import List
class Entity(BaseModel):
    category: str = Field(description="The category of the entity.")
    name: str = Field(description="The name of the entity.")
class Extraction(BaseModel):
    entityList: List[Entity] = Field(description="The list of extracted entities.")
structured_llm = llm.with_structured_output(Extraction)
extracted=structured_llm.invoke(myPrompt)

from pydantic import BaseModel, Field
from typing import List
class Entity(BaseModel):
    category: str = Field(description="The category of the entity.")
    name: str = Field(description="The name of the entity.")
class Extraction(BaseModel):
    entityList: List[Entity] = Field(description="The list of extracted entities.")
structured_llm = llm.with_structured_output(Extraction)
extracted=structured_llm.invoke(myPrompt)

In dit eenvoudige voorbeeld wordt de LLM gevraagd om een gestructureerde output van het type “Extraction” terug te geven, met als attribuut “entityList”, een lijst van “Entity”-objecten “ die net daarvoor zijn gedefinieerd.

Het is interessant om op te merken dat dit type template kan worden uitgebreid wanneer we extra informatie willen extraheren of het type gedetecteerde entiteiten willen beperken. Als we bijvoorbeeld alleen entiteiten van het type “persoon” en “onderneming” willen detecteren, kan de template worden aangepast door de klassen “ Persoon” en “Onderneming” aan te maken, waarin de attributen worden opgesomd die voor elke instantie van deze entiteiten moeten worden geëxtraheerd, en door het veld ”entityList“ te vervangen door twee velden “personList” en ”enterpriseList” in het uiteindelijke object dat moet worden teruggegeven.

Het voordeel van het gebruik van de methode with_structured_output is dat LangChain automatisch controleert of de output van de LLM overeenkomt met de template.

Extractie van entiteiten en relaties

Het doel hier is het bouwen van een graph die de kennis in het document of de documenten weergeeft in de vorm van onderling verbonden entiteiten (nodes) en relaties. Dit is de meest uitgebreide (en meest ingewikkelde) taak die we in detail zullen bekijken.

Laten we het volgende stukje tekst nemen om te illustreren wat voor soort extractie we hier willen uitvoeren:

“The San Fransisco-based 9th U.S. Circuit Court of Appeals rejected the legal challenge by the Federal Trade Commission to Microsoft’s $69 billion acquisition of Activision Blizzard, the developer of “Call of Duty.” A three‑judge panel unanimously upheld a lower court’s decision denying a preliminary injunction, finding that the FTC had not demonstrated a likelihood of success in proving the merger would harm competition. The acquisition, completed in late 2023 following UK regulatory approval, is the largest ever in the video gaming industry.”
(Source: adapted from Reuters, 2025).

Zodra de informatie is geëxtraheerd, is dit een voorbeeld van een graph die op basis van deze tekst kan worden gemaakt:

Dit type extractie kan op veel verschillende manieren worden uitgevoerd. Het volgende deel is speciaal gewijd aan de verschillende benaderingen om een volledige extractie uit te voeren, en aan de voor- en nadelen daarvan.

Welke benaderingen zijn er voor het extraheren van entiteiten en relaties?

Handmatige extractie versus speciale tools

Een dergelijke graph kan manueel worden opgebouwd volgens de techniek die in het vorige deel werd voorgesteld (een prompt met instructies en de chunk naar de LLM sturen, de gestructureerde output ophalen en ontleden, en vervolgens de graph bijwerken via queries), ofwel biedt LangChain een tool aan om deze verschillende taken te automatiseren via de LLM Graph Transformer.

Deze tool vereenvoudigt de procedure door de instructies aan de LLM, het opstellen van de template en de verwerking van de gestructureerde output voor zijn rekening te nemen. De tool biedt verschillende instelmogelijkheden, zoals de mogelijkheid om de soorten nodes die gedetecteerd moeten worden te beperken (bv. alleen nodes van het type “Person”, “Company” en “Location”), de soorten relaties te beperken of de instructieprompt aan te passen.

Bovendien geeft een LLMGraphTransformer-instantie een lijst terug met objecten van het type GraphDocument, die de gedetecteerde nodes en relaties bevat en die direct kan worden gebruikt door verschillende LangChain-drivers naar graph-gerichte databases (zoals Memgraph, TigerGraph, Neo4j, enz.), om de geëxtraheerde entiteiten en relaties direct in de graph te importeren.

Hieronder volgt een voorbeeld van het extraheren van data uit een lijst met chunks met behulp van de LLMGraphTransformer-tool, gevolgd door het importeren van de entiteiten en relaties naar Neo4j:

doc_transformer=LLMGraphTransformer(llm=llm)
graph_docs=doc_transformer.convert_to_graph_documents(listOfChunks)

from langchain_neo4j import Neo4jGraph
graph=Neo4jGraph(
    url='XXXXX',
    username='YYYYY',
    password='ZZZZZ'
)
graph.add_graph_documents(graph_docs)

doc_transformer=LLMGraphTransformer(llm=llm)
graph_docs=doc_transformer.convert_to_graph_documents(listOfChunks)

from langchain_neo4j import Neo4jGraph
graph=Neo4jGraph(
    url='XXXXX',
    username='YYYYY',
    password='ZZZZZ'
)
graph.add_graph_documents(graph_docs)

Er bestaat ook een gratis alternatief voor Neo4j, waarvoor geen programmering nodig is: de Neo4j LLM Knowledge Graph Builder. Deze online tool neemt alle stappen voor zijn rekening, van de voorbewerking van documenten (pdf, webpagina) tot de opbouw van de resulterende knowledge graphs, en biedt tal van personaliseringsopties (het beperken van de te detecteren entiteit- en/of relatietypes, enz.). Zie hier voor meer details.

Vrije extractie versus begeleide extractie

Merk op dat als er met deze tools geen beperkingen (op de soorten entiteiten en relaties die moeten worden geëxtraheerd) worden gedefinieerd, ze in alle vrijheid alle informatie zullen extraheren die ze kunnen vinden. Dit soort “blinde” extractie kan eventueel worden gebruikt voor kleine documenten, of in gevallen waarin men van tevoren niet weet wat voor soort structuur men kan extraheren, maar het is over het algemeen beter om van tevoren de gewenste ontologie voor de graph vast te leggen.

Vrije extractie is namelijk vaak een probleem om verschillende redenen:

Explosie van entiteitstypen en relaties 

Naarmate de omvang of het aantal documenten toeneemt, bestaat het risico dat er al snel een zeer groot aantal verschillende soorten entiteiten en relaties in de graph terechtkomen, waardoor deze moeilijk te gebruiken kan worden (bijvoorbeeld voor RAG-toepassingen).

Inconsistentie van types

Bij gebrek aan een ontologie die een duidelijke nomenclatuur biedt, bestaat het risico van inconsistentie in de gedetecteerde types (een bedrijf kan bijvoorbeeld worden gelabeld als “Enterprise”, een ander als “Company” en een derde als “Organization”). In de praktijk kunnen dit soort problemen achteraf worden opgelost door alle soorten nodes op te sommen en semantisch verwante soorten te groeperen.

Problemen met reïficatie

Per definitie verbindt een relatie in een graph een node met een ander node. Er kan een probleem ontstaan wanneer een entiteit moet worden gekoppeld aan informatie die in de vorm van een relatie is gemodelleerd. Om het probleem te illustreren, nemen we als voorbeeld de overname van Activision Blizzard door Microsoft. Stel dat een eerste stuk tekst alleen deze overname vermeldt zonder verdere details, dan wordt deze hoogstwaarschijnlijk opgeslagen in de vorm:

(Microsoft)-[ACQUIRES]->(Activision Blizzard)

Stel dat de volgende chunk de informatie “The FTC challenged the acquisition…” vermeldt, dan hebben we een probleem omdat het niet meer mogelijk is om

(FTC)-[CHALLENGES]->(Acquisition)

te modelleren, aangezien de overname eerder werd gemodelleerd in de vorm van een relatie en niet als een node waarnaar door een relatie kan worden verwezen.

In dit geval kan de relatie bijvoorbeeld worden verwijderd en vervolgens worden vervangen door een node, zodat ernaar kan worden verwezen:

(Microsoft)-[INITIATES]->(Acquisition)-[TARGETS]->(Activision Blizzard)

Dit proces, dat reïficatie wordt genoemd, verloopt niet automatisch en vereist een extra verrijkingsstap om mogelijke verwijzingen naar informatie die in de vorm van relaties is gemodelleerd, op te sporen en indien nodig te reïficeren.

Enkele alternatieven voor LLM’s

Nu we een reeks benaderingen hebben bekeken die specifiek op LLM’s zijn gebaseerd, worden in dit gedeelte enkele alternatieve tools voorgesteld die zijn gebaseerd op klassieke NLP-methoden.

Voor wie alleen named entities wil extraheren, is hier een blogpost over dit onderwerp te vinden, evenals een voorbeeld van de toepassing van NER bij PII-filtering.  Er zijn tal van vooraf getrainde NER-modellen beschikbaar op platforms zoals Hugging Face.

Het extraheren van entiteiten en relaties kan doorgaans op twee verschillende manieren gebeuren:

• Extractie in twee afzonderlijke stappen: eerst wordt een NER gebruikt voor het detecteren en categoriseren van entiteiten, gevolgd door een extractie van relaties op basis van de tekst en de gedetecteerde entiteiten, om de relaties tussen deze entiteiten te bepalen. Enkele voorbeelden van tools voor het extraheren van relaties zijn openNRE, spacy-relation-extraction en GliREL.
• End-to-end-extractie: tools die entiteiten en relaties in één stap extraheren, zoals OpenIE, Relik, REBEL of Diffbot (commerciële oplossing).

Nagaan of de gedetecteerde gegevens conform zijn

De grote kracht van LLM’s voor dit soort extractietaken is hun begrip van natuurlijke taal, waardoor de extractie kan worden gepersonaliseerd door de instructieprompt aan te passen. Als er bijvoorbeeld geen outputtemplate bestaat voor het gestructureerde antwoord (waar de LLM moeite mee kan hebben als de template te ingewikkeld wordt), is het mogelijk om ontologieconforme nodes en relaties te verkrijgen door de ontologie rechtstreeks in de instructieprompt te beschrijven, maar het is belangrijk om alert te blijven voor extracties. Er is namelijk geen garantie dat de LLM geen fouten maakt en geen niet-conforme relatie/entiteit als output teruggeeft.

In het algemeen geldt dat wanneer een LLM (of een andere tool) wordt gebruikt om automatisch informatie uit een tekst te extraheren naar een knowledge graph, het nuttig is om te controleren of datgene dat is geëxtraheerd wel degelijk in overeenstemming is met de ontologie en trouw is aan de informatie in de bron.

1. Controleren of de extractie voldoet aan de ontologie

In een vorige blogpost hebben we al vermeld dat het mogelijk is om de structuur en inhoud van een knowledge graph te valideren met behulp van de SHACL-standaard. Dit is een taal die de verschillende beperkingen bevat die van toepassing zijn op een knowledge graph. Het is mogelijk om ofwel een definitieve validatie van de graph uit te voeren, om te controleren of de inhoud daadwerkelijk voldoet aan de in SHACL geformuleerde beperkingen (en de data die deze beperkingen overtreden op te sommen), ofwel deze validaties transactioneel uit te voeren bij elke nieuwe toevoeging van informatie, om elke nieuwe onrechtmatige toevoeging te weigeren. Hoewel SHACL oorspronkelijk bedoeld was voor graphs in RDF, kunnen sommige databases toch SHACL-beperkingen interpreteren en de graph valideren, zoals Neo4j met het neosemantics package (n10s).

2. Nagaan of de extractie correct is

Het risico van automatische extractie is dat informatie die in de graph wordt ingevoerd feitelijk onjuist is ten opzichte van de oorspronkelijke tekst, wat in het bijzonder problematisch kan zijn als deze graph wordt gebruikt als potentiële informatiebron (bijvoorbeeld voor een graphRAG-toepassing). Er kunnen verschillende benaderingen worden gevolgd. De eenvoudigste is een menselijke controle van de geëxtraheerde informatie, maar dit kan moeilijk of zelfs onhaalbaar worden wanneer de documenten te lang/talrijk worden. De andere aanpak bestaat erin een tweede LLM te gebruiken om te controleren wat uit elk fragment is geëxtraheerd. Zoals we in de post over de evaluatie van LLM’s hebben vermeld, is het voor LLM’s gemakkelijker om achteraf fouten op te sporen dan ze te vermijden.

Conclusie

Deze technologieën zijn weliswaar krachtig, maar nooit perfect. Behalve vrije (blinde) extractie, die kan resulteren in een moeilijk bruikbare graph, vormt het opstellen van een knowledge graph op basis van tekst een taak die veel werk vereist. En dit zowel vooraf (voorbewerking van teksten, opstellen van een ontologie voor de graph op basis van de inhoud van de tekst), als achteraf (validatie van de structuur van de graph ten opzichte van de ontologie en controle van de juistheid en betrouwbaarheid van de inhoud).

Dit is een ingezonden bijdrage van Pierre Leleux, data scientist et network data analyst bij Smals Research. Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

Les graphes, et plus particulièrement les graphes de connaissances, permettent de représenter l’information de manière structurée. Cela permet, pour un humain, d’avoir une représentation (synthèse visuelle) du contenu d’un ou de plusieurs documents et, pour une machine, d’exploiter cette structure afin, par exemple, d’en analyser le contenu (via l’utilisation d’algorithmes de graphe) et/ou de raisonner sur le graphe (par exemple dans le cadre d’une application de graphRAG ou pour découvrir (inférer) de l’information implicite).

Cet article s’intéresse aux façons dont une représentation graphe peut être obtenue à partir de données textuelles, les différents types de graphe qui peuvent être extraits, et les outils fréquemment utilisés suivant le type d’extraction que l’on souhaite effectuer.

Il est à noter que, puisque les grands modèles de langage (LLM) sont particulièrement adaptés pour le traitement de texte, cet article se concentrera principalement sur la présentation d’approches basées sur les LLM et discutera rapidement, dans un second temps, de différentes approches alternatives.

Les graphes de connaissances : un rappel rapide

Un graphe est une structure composée d’un ensemble de nœuds et d’arcs (qui lient des paires de nœuds). Un graphe de connaissances ajoute une couche sémantique supplémentaire à un graphe classique, où chaque nœud représente un concept (entité, personne, etc.) et chaque arc représente une relation entre deux concepts (« travaille pour », « est ami avec », etc.). Il s’agit donc d’une représentation de la connaissance sous forme d’un ensemble d’entités interconnectées. Plus de détails sur les différentes formes de graphes et les outils associés peuvent être trouvés ici.

Préparation du corpus de documents

Il est à noter que, pour des raisons de simplicité, nous faisons l’hypothèse que les documents de texte utilisés pour construire le graphe ont été correctement nettoyés. En effet, cet article n’a pas pour but de discuter de l’aspect relatif au prétraitement des documents de texte (scrapping de pages web, extraction de texte à partir de fichiers pdf, etc.), car ce prétraitement est déjà, en tant que tel, un vaste sujet méritant sans doute un article dédié.

Fragmentation du texte en « chunks »

Une étape importante de la préparation des données de texte avant d’en extraire les entités et relations est la division du texte en fragments (généralement appelés « chunks »). Nous avons déjà mentionné le concept de chunking à plusieurs reprises dans de précédents articles. Si un document est trop long (plus de quelques paragraphes…) il convient de le séparer en chunks (fragments de texte de taille raisonnable) qui seront traités un à un par le LLM. Cette procédure permet de limiter la quantité d’information présente dans chaque chunk, pour éviter que celui-ci ne contienne une quantité trop importante d’entités et de relations à extraire. Cette séparation en chunks peut se faire de différentes manières, soit sur la base du nombre de mots dans le chunk, soit sur la base d’un séparateur prédéfini (par exemple : un passage à la ligne qui indiquerait la fin du paragraphe).

Représenter l’information ou représenter la structure

Commençons par regarder les deux principaux types de graphe qui peuvent être construits à partir d’un ensemble de documents textuels.

Le premier est un graphe qui va présenter la structure du document (document structure graph), et non pas l’information qui est contenue dans le texte. Par exemple, en reliant les chunks au document d’où ils sont tirés ainsi que l’ordre d’apparition de ceux-ci dans le document :

Ce type de graphe peut aussi être enrichi en ajoutant des relations entre chunks sémantiquement similaires ou, le cas échéant, en représentant l’organisation hiérarchique du document en sections, sous-sections, etc. Cela se fait via des nœuds représentant les sections/sous-sections et des relations de type « HAS_SECTION », « HAS_SUBSECTION », ainsi que des relations indiquant l’ordre des sections/sous-sections. Une fois le graphe construit, il peut par exemple être utilisé dans des applications de RAG à des fins d’indexation pour fournir du contexte aux chunks utilisés (voir notre article sur le graphRAG).

Le second type de graphe consiste à capturer l’information contenue dans les documents sous la forme de nœuds et de relations :

Dans le cadre de cet article, nous nous concentrerons sur ce second type de graphe. Il est à noter que les deux approches ne sont pas mutuellement exclusives. D’ailleurs, il est souvent utile, si l’on souhaite opter pour le deuxième type de graphe, de représenter également la structure des documents. Cela permet, si nécessaire, de pouvoir remonter à la source des informations présentes dans le graphe.

Construction d’un graphe de connaissances à l’aide d’un LLM

Dans un premier temps, nous allons présenter la procédure générale à suivre pour la création d’un graphe de connaissances à partir de documents textuels via LLM, avant de voir comment l’adapter suivant ses besoins.

Les LLMs, par défaut, reçoivent en entrée du texte (prompt) et renvoient en sortie du texte généré en réponse au prompt. Cependant, suivant les instructions, les LLM offrent la possibilité de générer des outputs structurés tels que des fichiers JSON. C’est souvent sur la base de cette fonctionnalité que se base l’extraction de connaissances vers un graphe, car cet output structuré pourra être traité de façon systématique.

Un script (par ex. python) va récupérer les chunks et les envoyer un à un au LLM en imposant une réponse structurée (par ex. langchain avec la méthode llm.with_structured_output()), avec des instructions concernant la tâche, le genre d’information à détecter dans le texte, et la structure de la réponse attendue en sortie. L’output structuré (typiquement en JSON) est ensuite simplement décomposé en python afin de récupérer les informations (nœuds/relations) détectées par le LLM, qui peuvent ensuite être directement ajoutées au graphe (via un database driver).

Il est intéressant de noter que les LLM peuvent fournir une grande diversité de réponses, et l’utilisation d’une sortie structurée n’est pas forcément toujours nécessaire. Dans certains cas, le plus simple est encore de demander au LLM de fournir ses extractions sous la forme de requêtes (par exemple, de requêtes qui ajoutent directement les nœuds/relations détectées), qui peuvent être exécutées telles quelles, ou sous forme de triplets RDF.

Maintenant que nous avons vu la procédure générale, nous allons regarder plus en détail les différentes façons d’extraire et de représenter l’information contenue dans les chunks au sein d’un graphe, en commençant par l’approche la plus simple (extraction de thèmes) jusqu’à la plus complète (extraction d’entités et de relations).

Extraction thématique

Dans cette première approche, on va s’intéresser à la détection et l’extraction des thèmes abordés dans le document. On y construit donc une représentation thématique des différents documents du corpus de sorte à obtenir une structure de type :

Le graphe a donc une structure légère et est utilisé à des fins de référencement, afin d’identifier facilement et rapidement les documents traitant d’un (ou plusieurs) sujet(s) d’intérêt donné(s). Ce type de graphe permet aussi d’établir des similarités entre documents (ou entre chunks) sur la base des sujets qu’ils ont en commun, ou simplement d’avoir une représentation schématique du corpus de documents et des thèmes qui y sont abordés.

Cela peut se faire soit de façon non-dirigée (laisser le LLM déterminer librement de la liste des thèmes abordés dans le chunk), soit dirigée (le LLM choisit un ou plusieurs thèmes parmi une liste prédéfinie de thèmes fournie dans les instructions du prompt).

Extraction d’entités nommées

L’extraction (ou reconnaissance) d’entités nommées (named-entity recognition, souvent abrégé en NER) est un domaine bien connu du traitement du langage naturel (natural language processing (NLP)) qui consiste à détecter et catégoriser les entités (personne, organisation, lieu, etc.) qui sont nommées dans un texte. L’objectif va donc être similaire à celui de l’extraction thématique : créer un graphe en liant les chunks de texte aux entités qui y sont mentionnées. Nous obtenons donc un graphe avec le schéma-type suivant :

Ce type de graphe permet aussi d’établir des similarités entre documents (ou entre chunks) sur la base des entités qu’ils ont en commun. Il est intéressant de noter que cette extraction est similaire à une extraction complète (incluant entités et relations, voir section ci-dessous), si ce n’est qu’ici seules les entités sont extraites, et pas les relations qui les interconnectent. Il s’agit d’une solution plus légère et facile à mettre en place, lorsqu’une extraction complète n’est pas nécessaire.

Ce genre d’extraction peut se faire facilement par l’utilisation de LLM avec outputs structurés. Le package pydantic permet de créer des templates sur mesure pour la structure attendue en sortie. Par exemple :

from pydantic import BaseModel, Field
from typing import List
class Entity(BaseModel):
    category: str = Field(description="The category of the entity.")
    name: str = Field(description="The name of the entity.")
class Extraction(BaseModel):
    entityList: List[Entity] = Field(description="The list of extracted entities.")
structured_llm = llm.with_structured_output(Extraction)
extracted=structured_llm.invoke(myPrompt)

from pydantic import BaseModel, Field
from typing import List
class Entity(BaseModel):
    category: str = Field(description="The category of the entity.")
    name: str = Field(description="The name of the entity.")
class Extraction(BaseModel):
    entityList: List[Entity] = Field(description="The list of extracted entities.")
structured_llm = llm.with_structured_output(Extraction)
extracted=structured_llm.invoke(myPrompt)

Dans cet exemple simple, on demande au LLM de retourner une sortie structurée de type « Extraction », avec comme attribut « entityList » qui est une liste d’objets « Entity » définis juste avant.

Il est intéressant de noter que ce type de template peut être enrichi si l’on souhaite extraire des informations supplémentaires ou contraindre le type d’entités détectées. Par exemple, si l’on souhaite uniquement détecter des entités de type « personne » et « entreprise », le template peut être modifié en créant des classes « Personne » et « Entreprise », dans lesquelles on listera les attributs que l’on souhaite extraire pour chaque instance de ces entités, et en remplaçant le champs « entityList » par deux champs « personList » et « enterpriseList » dans l’objet final à retourner.

L’avantage d’utiliser la méthode with_structured_output est que langchain vérifiera automatiquement que la sortie du LLM est bien conforme au template.

Extraction d’entités et de relations

L’objectif ici est la construction d’un graphe qui va représenter la connaissance contenue au sein du ou des documents sous la forme d’entités (nœuds) interconnectées (relations). Il s’agit de la tâche la plus complète (et la plus compliquée), sur laquelle nous allons nous pencher le plus en détail.

Prenons le chunk de texte suivant, afin d’illustrer le genre d’extraction que nous souhaitons réaliser ici :

“The San Fransisco-based 9th U.S. Circuit Court of Appeals rejected the legal challenge by the Federal Trade Commission to Microsoft’s $69 billion acquisition of Activision Blizzard, the developer of “Call of Duty.” A three‑judge panel unanimously upheld a lower court’s decision denying a preliminary injunction, finding that the FTC had not demonstrated a likelihood of success in proving the merger would harm competition. The acquisition, completed in late 2023 following UK regulatory approval, is the largest ever in the video gaming industry.”
(Source: adapted from Reuters, 2025).

Une fois l’information extraite, voici un exemple de graphe qu’il est possible de construire depuis ce texte :

Ce type d’extraction peut se faire de nombreuses façons différentes. La prochaine section sera spécialement dédiée aux différentes approches qui peuvent être adoptées pour réaliser une extraction complète, leurs avantages et inconvénients.

Quelles approches pour réaliser une extraction d’entités et de relations ?

Extraction manuelle VS outils dédiés

La construction d’un graphe de ce type peut se faire de manière manuelle en suivant la technique présentée dans la section précédente (envoyer un prompt incluant les instructions et le chunk au LLM, récupérer et décomposer l’output structuré renvoyé en sortie, puis mettre à jour le graphe via requêtes), ou alors langchain propose un outil permettant d’automatiser ces différentes tâches via le LLM Graph Transformer.

Cet outil permet de simplifier la procédure, en prenant en charge les instructions au LLM, la construction du template et le traitement de la sortie structurée. Il offre plusieurs possibilités de personnalisation, comme la possibilité de restreindre les types de nœud que l’on souhaite détecter (par ex. uniquement des nœuds de type « Person », « Company » et « Location »), de restreindre les types de relation, ou encore de personnaliser le prompt d’instructions.

De plus, une instance LLMGraphTransformer renvoie en sortie liste d’objets de type GraphDocument, contenant les nœuds et relations détectés, qui est exploitable directement par plusieurs drivers langchain vers des bases de données orientées graphe (telles que Memgraph, TigerGraph, Neo4j, etc.), afin de réaliser directement l’importation des entités et relations extraites vers le graphe.

Ci-dessous, un exemple illustratif de l’extraction des données depuis une liste de chunks via l’outil LLMGraphTransformer, suivie de l’importation des entités et relations vers Neo4j :

doc_transformer=LLMGraphTransformer(llm=llm)
graph_docs=doc_transformer.convert_to_graph_documents(listOfChunks)

from langchain_neo4j import Neo4jGraph
graph=Neo4jGraph(
    url='XXXXX',
    username='YYYYY',
    password='ZZZZZ'
)
graph.add_graph_documents(graph_docs)

doc_transformer=LLMGraphTransformer(llm=llm)
graph_docs=doc_transformer.convert_to_graph_documents(listOfChunks)

from langchain_neo4j import Neo4jGraph
graph=Neo4jGraph(
    url='XXXXX',
    username='YYYYY',
    password='ZZZZZ'
)
graph.add_graph_documents(graph_docs)

Il existe aussi une alternative gratuite pour Neo4j, qui ne requiert aucune programmation, le Neo4j LLM Knowledge Graph Builder. Cet outil en ligne prend toutes les étapes en charge, en allant du prétraitement des documents (pdf, page web) jusqu’à la construction du graphe de connaissances résultant, et offre de multiples options de personnalisation (contraindre les types d’entité et/ou de relation à détecter, etc.). Voir ici pour plus de détails.

Extraction libre VS extraction supervisée

Il est à noter que si aucune contrainte (sur les types d’entité et de relation à extraire) n’est définie avec ces outils, ils vont librement extraire toutes les informations qu’ils peuvent trouver. Ce genre d’extraction « à l’aveugle » peut éventuellement être utilisée pour des petits documents, ou dans des cas où l’on ne sait pas à l’avance le genre de structure que l’on peut extraire, mais il est généralement préférable d’établir à l’avance l’ontologie que l’on souhaite adopter pour le graphe.

Une extraction libre est en effet souvent problématique pour plusieurs raisons :

Explosion des types d’entité et de relation 

Lorsque la taille ou le nombre de documents augmente, l’on risque rapidement de se retrouver avec un très grand nombre de types différents d’entités et de relations au sein du graphe, ce qui peut le rendre difficile à exploiter (par ex. pour des applications de RAG).

Incohérence de types

En l’absence d’une ontologie fournissant une nomenclature claire, il y a des risques d’incohérence dans les types détectés (par exemple, une entreprise pourra être labelisée comme « Enterprise », une autre comme « Company », et une troisième comme « Organization »). En pratique, ce genre de soucis peut potentiellement être réglé a posteriori en listant tous les types de nœud et en rassemblant les types sémantiquement proches.

Soucis de réification

Par définition, une relation dans un graphe relie un nœud à un autre nœud. Un souci peut émerger lorsqu’une entité doit se connecter à une information qui a été modélisée sous la forme d’une relation. Pour illustrer le problème, reprenons en guise d’exemple l’acquisition d’Activision Blizzard par Microsoft. Supposons qu’un premier chunk de texte mentionne simplement cette acquisition sans plus de détails, elle sera fort potentiellement enregistrée sous la forme :

(Microsoft)-[ACQUIRES]->(Activision Blizzard)

Si maintenant le chunk suivant mentionne l’information « The FTC challenged the acquisition… », nous avons un problème car il n’est plus possible de modéliser

(FTC)-[CHALLENGES]->(Acquisition)

puisque l’acquisition a été précédemment modélisée sous la forme d’une relation, et non d’un nœud pouvant être référencé par une relation.

Dans ce cas, la relation peut par exemple être supprimée puis remplacée par un nœud, afin de la rendre référençable :

(Microsoft)-[INITIATES]->(Acquisition)-[TARGETS]->(Activision Blizzard)

Ce processus, appelé réification, n’est pas automatique et demande l’ajout d’une étape d’enrichissement pour détecter de potentielles références à des informations modélisées sous forme de relations, et les réifier si nécessaire.

Quelques alternatives aux LLM

Maintenant que nous avons vu une série d’approches basées spécifiquement sur les LLM, cette section propose quelques outils alternatifs basés sur des méthodes de NLP classique.

Si l’objectif est uniquement de faire l’extraction d’entités nommées, vous pouvez trouver ici un article de blog dédié à ce sujet, ainsi qu’un exemple d’application de NER en PII filtering. Il existe de nombreux modèles de NER préentrainés disponibles sur des plateformes telles que Hugging Face.

Concernant l’extraction d’entités et de relations, elle peut se faire typiquement de 2 façons distinctes :

• L’extraction en 2 étapes séparées : l’on commence par l’utilisation d’un NER pour la détection et la catégorisation des entités, suivie d’une extraction de relations sur la base du texte et des entités détectées, afin de déterminer les relations entre ces dernières. Quelques exemples d’outils pour l’extraction de relations incluent openNRE, spacy-relation-extraction ou encore GliREL.
• L’extraction conjointe (end-to-end)  : il s’agit d’outils qui réalisent l’extraction d’entités et de relations en une seule étape, tels que OpenIE, Relik, REBEL ou Diffbot (solution commerciale).

Vérifier la conformité de ce qui a été détecté

La grande force des LLM pour ce genre de tâche d’extraction est leur compréhension du langage naturel, ce qui permet de personnaliser l’extraction en adaptant le prompt d’instructions. Par exemple, en l’absence de template de sortie pour la réponse structurée (que le LLM peut peiner à respecter si le template devient trop compliqué), il est possible d’obtenir des nœuds et relations conformes à l’ontologie en décrivant l’ontologie directement dans le prompt d’instructions, mais il est important de rester vigilant aux extractions. En effet, il n’y a aucune garantie que le LLM ne fasse pas d’erreur, et ne renvoie pas en sortie une relation/entité non-conforme.

De manière générale, lorsqu’un LLM (ou tout autre outil) est utilisé pour extraire de l’information de façon automatique depuis un texte vers un graphe de connaissances, il est utile de vérifier que ce qui a été extrait est bien conforme à l’ontologie et fidèle à l’information qui se trouve dans la source.

1. Vérifier que l’extraction respecte l’ontologie

Comme nous l’avons déjà mentionné dans un précédent article de blog, il est possible de valider la structure et le contenu d’un graphe de connaissances à l’aide du standard SHACL. Il s’agit d’un langage qui va contenir les différentes contraintes qui s’appliquent sur un graphe de connaissances. Il est possible soit d’effectuer une validation finale du graphe, pour vérifier que le contenu respecte effectivement les contraintes énoncées en SHACL (et de lister les données qui violent ces contraintes), soit d’effectuer ces validations de façon transactionnelle à chaque nouvelle information qui est ajoutée, afin de refuser tout nouvel ajout illégal. Bien qu’initialement prévu pour des graphes en RDF, certaines bases de données peuvent tout de même interpréter des contraintes en SHACL et valider le graphe, comme neo4j avec le package neosemantics (n10s).

2. Vérifier que l’extraction est correcte

Le risque d’une extraction automatique est qu’une information introduite dans le graphe soit factuellement incorrecte vis-à-vis du texte d’origine, ce qui peut être particulièrement problématique si ce graphe est utilisé comme potentielle source d’information (par exemple pour une application de graphRAG). Plusieurs approches peuvent être suivies. La plus simple est une vérification humaine des informations extraites, mais cela peut devenir difficile, voire infaisable, lorsque les documents deviennent trop longs/nombreux. L’autre approche consiste à utiliser un second LLM afin de vérifier ce qui a été extrait de chaque chunk. Comme nous l’avons mentionné dans l’article d’évaluation de LLM, il est plus facile, pour les LLM, de détecter les erreurs a posteriori que de les éviter.

Conclusion

Ces technologies, bien que performantes, ne sont jamais parfaites. Sauf extraction libre (à l’aveugle), mais qui risque d’aboutir à la création d’un graphe difficilement exploitable, la construction d’un graphe de connaissances à partir de texte est une tâche qui demande du travail, tant en amont (prétraitement des textes, établissement d’une ontologie pour le graphe sur la base du contenu du texte) qu’en aval (validation de la structure du graphe vis-à-vis de l’ontologie et vérification de la véracité et la fiabilité de son contenu).

Ce post est une contribution individuelle de Pierre Leleux, data scientist et network data analyst chez Smals Research. Cet article est écrit en son nom propre et n’impacte en rien le point de vue de Smals.