Depuis l’essor de l’engouement pour les grands modèles de langage, la plupart des développeurs ont sans doute déjà pu constater le gain de productivité que ces outils peuvent offrir, à condition de les utiliser correctement. Dans cet article de blog, nous explorons la possibilité d’aller plus loin : l’IA offre-t-elle une aide suffisante afin de maîtriser le legacy code ?

Le recours aux grands modèles de langage (Large Language Model – LLM) en programmation est en effet bien connu à présent : cela va de la formulation de questions à un chatbot (“comment écrire un algorithme dans Java qui…”), à un code completion de plus en plus intelligent et étendu (saisie automatique de ce que vous souhaitez taper dans l’éditeur), jusqu’au vibe coding complet (dans l’IDE, ou même simplement dans un terminal) : des agents IA rédigent, à l’aide de prompts, des pans entiers de code sur votre machine – oui, même des applications fonctionnelles.

Nous avons donné une définition très large du code legacy dans un précédent article de blog. Commençons donc par préciser ce que nous entendons par “legacy” et par mieux illustrer le “degré de difficulté” des projets legacy.

“Ancien” code : une multitude de possibilités

Il n’existe pas vraiment de définition officielle du code legacy ; généralement, on parle de l’utilisation d’une technologie qui n’est plus prise en charge, difficile à maintenir, ou simplement de “code dont on hérite de quelqu’un d’autre”. Il s’agit évidemment toujours de code encore en service, et donc important. Ironiquement, les applications les plus critiques sont souvent celles qui existent depuis des années et auxquelles on “fait confiance” depuis longtemps, mais sans les entretenir correctement.

L’IA peut nous aider à entretenir n’importe quel code ; nous allons donc présenter un spectre allant du code legacy le plus ancien et le plus problématique au code de projets ne nécessitant qu’une petite mise à jour. À une extrémité du spectre, on trouve des programmes écrits dans des langages de programmation obsolètes, selon une architecture dépassée, utilisant des bases de données qui ne sont plus d’actualité et fonctionnant sur des serveurs équipés de systèmes d’exploitation qui ne sont plus pris en charge : avec ces géants, on doit souvent craindre une défaillance critique à la moindre modification erronée. À l’autre extrémité, on trouve des logiciels assez bien entretenus, mais qui utilisent une bibliothèque logicielle qui n’est plus la version la plus récente : il est généralement très facile de les remettre entièrement à jour. Enfin, quelque part entre les deux, on trouve des applications pour lesquelles la plupart des développeurs n’utiliseraient pas encore le terme Legacy, mais qui nécessitent néanmoins des migrations complexes, avec par exemple un ou deux frameworks obsolètes à remplacer.

Que pouvons-nous en faire ? Les LLM offrent-ils d’autres possibilités en fonction de la position du projet sur ce spectre ? Jusqu’à présent, nos recherches se sont concentrées sur la partie gauche de ce spectre ; la suite de cet article portera donc davantage sur les possibilités d’aborder le “véritable” legacy. Plus tard dans l’année, nous approfondirons également ce que nous pouvons faire en matière de migrations et d’updates.

Utilisation des LLM sur des bases de code legacy

Il est clair qu’un simple prompt “réécris ce programme selon les normes modernes” ne fonctionnera pas (même si certains fournisseurs affirment que cela sera bientôt possible). Nous devrons poser des questions un peu plus concrètes et décomposer le travail en plusieurs étapes. Il y a en fait deux choses que nous pouvons faire avec notre code legacy : le réécrire et le documenter.

Réécriture du code legacy

Lorsque nous commençons à réécrire du code, nous devons souvent tenir compte du fait que la reconstruction complète d’un très grand projet est une tâche trop difficile. Il est possible d’obtenir des “quick wins” en réécrivant stratégiquement certaines parties d’un projet, qui seront ensuite réutilisées dans un contexte plus large, où une équipe humaine et l’IA reconstruiront l’application dans les règles de l’art. Nos expériences nous ont montré qu’il était trop ambitieux d’attendre de l’IA qu’elle utilise une architecture entièrement nouvelle tout en traduisant l’ancien code vers le nouveau. En revanche, il est possible de “vibe coder” une grande partie de la charpente typique d’un nouveau projet, puis d’y injecter de manière ciblée un certain nombre de morceaux de code qui sont des traductions de parties d’un projet legacy. En tant qu’êtres humains, notre tâche consiste à indiquer clairement quelle architecture nous attendons et quelles sont les règles de qualité du code nouveau.

L’un des principaux défis liés à la réécriture de code à l’aide de l’IA consiste à tester l’exactitude de la traduction : le code fait-il toujours ce qu’il faisait auparavant (indépendamment du fait que cela soit souhaitable, car même le business case peut parfois être trop obsolète dans le cas d’un projet legacy) ? Pour les projets relativement récents, il existe déjà de nombreux tests que nous pouvons effectuer pour vérifier l’exactitude, mais avec les anciens systèmes legacy, nous sommes souvent confrontés au problème que l’application est simplement testée en production, ou du moins avec des données de production : il n’y a pas de tests spécifiques ni même de données de test pouvant être utilisées en toute sécurité. Dans ce cas, il s’agit de créer un environnement dans lequel nous pouvons tester le nouveau code en toute sécurité, ce qui est généralement un travail ad hoc et demande une certaine créativité. Nous ne pouvons pas envoyer de données de production vers le cloud, nous devons donc nous assurer que le LLM ne puisse pas les lire. Ce serait plus simple si nous pouvions utiliser des LLM fonctionnant en local, mais pour l’instant, ceux-ci ne sont pas encore assez puissants (quand ils sont disponibles) pour effectuer des tâches aussi complexes avec du code legacy.

L’interface utilisateur constitue un autre défi : dans les projets plus anciens, celle-ci est souvent obsolète et il faut construire une nouvelle GUI à partir de zéro. Cela pose toutefois le problème de ne plus disposer d’une base de référence dans l’ancien projet : la nouvelle interface devra généralement être testée manuellement par des personnes. J’espère toutefois que nous verrons des progrès dans ce domaine dans un avenir proche, en ce qui concerne les possibilités de l’IA. En effet, nous voyons déjà apparaître des systèmes capables de contrôler l’intégralité de votre ordinateur (comme OpenClawd), et l’intégration avec des frameworks plus traditionnels pour le test d’une interface graphique fait également partie des possibilités.

Enfin, les petits projets legacy constituent également un domaine où nous pouvons obtenir des résultats rapides. Si nous utilisons un programme legacy petit à moyen, doté de fonctionnalités limitées et d’une GUI simple, ou présentant un input et un output clairs en cas de batch processing, et qu’il n’existe aucun business case justifiant son intégration dans une autre méthode de travail, nous pouvons alors tenter une approche directe pour construire une version moderne dans un nouveau langage de programmation à l’aide de l’IA. Dans ce cas, il faudra tout de même bien tester et adopter une approche structurée avec un accompagnement des développeurs humains, mais il est possible d’essayer cette méthode pour des applications non critiques. Une application à usage interne, par exemple, constitue généralement un bon premier candidat.

Documentation du code legacy

Parfois, la réécriture du code legacy avec l’IA est un peu trop ambitieuse, ou nous avons besoin de plus d’informations avant de nous y risquer. Il peut être intéressant de se tourner d’abord vers la documentation : l’IA peut également nous aider à faire en sorte que l’exploration d’une base de code legacy ressemble un peu moins à de l’archéologie de haut niveau.

Expliquer un morceau de code de petite à moyenne taille et en extraire la logique business, ou analyser un morceau plus important et en expliquer la structure et l’architecture, tout cela est tout à fait possible avec les grands modèles de langage actuels. Il est toutefois possible d’aller plus loin : il est possible de créer des outils d’IA pour l’aider à explorer la base de code et, par exemple, à générer des diagrammes illustrant les dépendances entre les segments de code. Ou bien on peut lui faire écrire des scripts afin de structurer soigneusement ses conclusions après chaque analyse dans un fichier texte pour elle-même et un PDF destiné à l’utilisateur humain.

Il est également possible d’adopter une approche hiérarchique : commencer par explorer la base de code, puis approfondir progressivement l’analyse des différents modules afin d’obtenir de plus en plus de détails et de compléter l’analyse. Il s’agit là de l’approche top-down, que nous pouvons toutefois compléter par une version bottom-up : une fois que nous sommes allés en profondeur, nous pouvons à nouveau demander un résumé afin de construire une présentation mieux documentée de la situation dans son ensemble.

Il est toutefois important ici de savoir à l’avance ce que nous souhaitons exactement atteindre. Une analyse générale d’une base de code par l’IA peut s’avérer intéressante lorsque les utilisateurs humains ne connaissent pas du tout le système et souhaitent disposer de points de repère pour se familiariser avec celui-ci.

Cependant, lorsque l’objectif est de pouvoir assurer la maintenance de la base de code, il est préférable de mettre en place un système proposant un chatbot qui connaît le contexte spécifique et les particularités du projet legacy, et qui peut répondre à des questions très ciblées à ce sujet. Cela est possible, par exemple, dans CoPilot Studio. Si cela ne fonctionne pas correctement, il est possible d’envisager de construire manuellement une knowledge base en utilisant l’IA qui pourra ensuite être utilisée par l’IA pour répondre aux questions.

Une autre option consiste à extraire des informations spécifiques de la base de code, telles que la logique business par module individuel, ou du pseudocode pouvant aider les développeurs humains à réimplémenter cette logique dans un autre projet. (Et bien sûr, une IA peut également être mise à contribution lors de cette deuxième étape).

Avec une touche de créativité, nous pouvons concevoir une meilleure approche pour la plupart des analyses ad hoc que celle consistant à “se contenter d’analyser à tout va”. Et la documentation d’un système legacy peut tout simplement constituer une première étape vers sa réécriture.

Conclusion : professionnels recherchés

Comme mentionné précédemment, les LLM nous offrent progressivement des possibilités très puissantes pour traiter nos bases de code legacy, surtout lorsque nous avons accès aux modèles volumineux et puissants disponibles aujourd’hui. Nous constatons toutefois qu’il s’agit en réalité d’une boîte à outils très bien fournie, comprenant plusieurs “power tools” puissants, et que nous devons savoir ce que nous voulons en faire et comment les utiliser au mieux.

Tout n’est pas encore entièrement automatisé : nous aurons donc toujours besoin de bons professionnels pour tirer le meilleur parti de ces outils. Notre conseil aux développeurs est de ne surtout pas avoir peur de l’IA et de l’utiliser régulièrement lors de l’analyse et du développement de logiciels : l’expérience est la meilleure école pour former les bons professionnels dont nous avons besoin dans ce domaine.

Pour l’instant, la conclusion est donc la suivante : pour le code legacy, l’IA n’est pas une panacée, mais une boîte à outils pratique qu’il vaut mieux essayer dans le cadre d’une approche plus large. Comme indiqué, nous nous pencherons plus tard dans l’année sur le milieu et la partie droite du spectre du code legacy. Nous pensons qu’il existe ici davantage de possibilités d’automatisation de certains workflows, surtout si nous exploitons davantage les agents. Il est donc possible que, pour des projets un peu plus simples et répétitifs, nous puissions évoluer du “professionnel” vers “l’usine”.

Et si vos administrateurs système pouvaient accéder à vos données sensibles sans que vous le sachiez ? L’informatique confidentielle propose une solution : isoler les données, même de ceux qui gèrent l’infrastructure. Mais comment ?

L’informatique confidentielle regroupe un ensemble de technologies permettant de protéger les données sensibles de telle sorte qu’il n’est pas nécessaire de les déchiffrer pour les traiter. Alors que certaines, comme le chiffrement homomorphe, sont encore très complexes à mettre en œuvre, les environnements d’exécution de confiance (EEC aussi appelés « trusted execution environment (TEE) » en anglais) ont atteint une bonne maturité, permettant de les considérer comme des composants importants dans la protection des données.

L’objectif premier des EEC est de dresser un rempart contre la curiosité des entités contrôlant l’infrastructure. Toutefois la protection technique ne résout pas tout. Les lois extraterritoriales [1-5] et l’usage de bibliothèques logicielles propriétaires imposées par certains fournisseurs d’infrastructure informatique peuvent fragiliser cette isolation.

Dans cet article et le suivant, nous nous penchons sur la possibilité de déployer des EEC sur notre propre infrastructure (on-premise). L’objectif est triple : bénéficier de la puissance de l’informatique confidentielle pour protéger les données et permettre de nouveaux cas d’usage, tout en gardant un certain contrôle sur la pile logicielle et matérielle, et ainsi renforcer la confiance de nos clients.

Séparation des rôles

Commençons par rappeler les différents acteurs qui interviennent lors du déploiement d’une application sur une infrastructure informatique. Leurs rôles doivent être hermétiquement séparés pour garantir l’intégrité du système.

• L’opérateur d’infrastructure gère le matériel et les infrastructures (calcul, stockage, réseau), incluant la maintenance des environnements d’exécution de confiance. Il contrôle les mises à jour des micrologiciels et l’allocation des ressources, mais ne devrait pas pouvoir accéder aux données ou aux charges de travail exécutées.
• L’opérateur d’orchestration, qui peut être le même que l’opérateur d’infrastructure, est responsable de la gestion des grappes de serveurs et du déploiement des charges de travail. Il configure les ressources nécessaires aux applications et supervise les services associés (journalisation, surveillance). Ses privilèges devraient aussi être strictement limités afin d’éviter toute intrusion dans l’application, tout en permettant l’orchestration essentielle.
• Le fournisseur de la charge de travail conçoit les spécifications des applications et choisit les images de conteneurs adaptées, en garantissant leur conformité et leur intégrité. Il doit prouver aux propriétaires de données (voir ci-dessous) que le code utilisé est sécurisé et respectueux de la confidentialité, sans pour autant accéder directement aux données sensibles.
• Le fournisseur d’images de conteneurs construit, signe et chiffre les images conteneurs, assurant leur provenance et leur sécurité. Il fournit les clés de vérification et de déchiffrement. Sa collaboration avec le fournisseur de l’application est cruciale pour garantir la chaîne d’approvisionnement logicielle et assurer que le code déployé est exactement celui qui a été audité.
• Enfin, le propriétaire des données détient les données traitées par les applications et exige leur confidentialité et leur intégrité. Il accorde sa confiance au code de l’application (le conteneur) et aux preuves cryptographiques fournies par le microprocesseur, excluant de fait les opérateurs d’infrastructure et d’orchestration de son périmètre de confiance. Il peut imposer des vérifications supplémentaires pour s’assurer que ses données ne sont ni visibles ni manipulées par des personnes non autorisées.

Les relations entre ces acteurs soulèvent des enjeux spécifiques : le propriétaire des données, par exemple, doit pouvoir faire confiance au code des conteneurs (fournis par le fournisseur de la charge de travail) pour traiter ses données, tout en protégeant celles-ci contre les autres acteurs comme l’opérateur d’infrastructure ou l’opérateur d’orchestration. Notamment les administrateurs de ces opérateurs ne devraient en aucun cas pouvoir avoir accès aux données traitées par les conteneurs.

Environnement d’exécution de confiance

Les EEC permettent de créer une barrière technique renforçant la confiance du propriétaire des données dans le conteneur applicatif. Nous avons déjà expliqué en détail leur fonctionnement ainsi que leurs avantages et inconvénients dans un rapport technique [6] et des articles de blogues [7], [8]. Dans cette section nous en rappelons les points clés avant de présenter des choix technologiques pour une mise en œuvre sur notre infrastructure de recherche.

Le bon fonctionnement des EEC réside dans le matériel. Certains micro-processeurs modernes permettent de réserver et de chiffrer une portion de la mémoire vive (RAM) dédiée à une machine virtuelle (VM) spécifique. Ainsi, un administrateur de la machine hôte, même avec les privilèges les plus élevés, ne verra que des données chiffrées s’il tente d’inspecter cette zone mémoire. Bien que des attaques par canaux auxiliaires existent (e.g., [9]), leur complexité nécessite généralement un accès physique prolongé et l’ajout de composants matériels malveillants, ce qui les rend extrêmement difficiles à exécuter.

Pour que le propriétaire des données soit certain que son application s’exécute dans un environnement sain, il utilise le mécanisme d’attestation. Ce processus génère une signature cryptographique du contenu de la mémoire de la VM au moment de son lancement. Cette signature est certifiée par le fabricant du micro-processeur.

Ce processus a des limites notamment dans le cas où l’opérateur d’infrastructure est une société étrangère (e.g., Amazon AWS, Google Cloud ou Microsoft Azure) qui impose ses bibliothèques propriétaires dans la VM afin, par exemple, de fournir la bonne couche d’abstraction matérielle.

Cela nous a conduit à vouloir tester ce type de technologie dans notre laboratoire de recherche sur notre propre matériel, anticipant la possibilité de le faire un jour sur G-Cloud. L’intérêt est de permettre à un client de SMALS de faire fonctionner un conteneur applicatif de manière sécurisée, sans qu’un administrateur de SMALS puisse accéder au contenu du conteneur.

Mais l’utilité des EEC dépasse la simple protection contre les administrateurs. Elle ouvre la voie à d’autres cas d’usage.

Cas d’usage

Un premier exemple se trouve dans le cadre de l’infrastructure européenne de services numériques de santé en ligne (eHDSI). Là, les professionnels de santé d’un pays de traitement peuvent demander les données de santé pertinentes du patient au pays d’affiliation de celui-ci. D’un point de vue technique, la demande est transmise par la passerelle du point de contact national pour la santé (NCPeH) du pays où l’événement de santé imprévu se produit, au pays d’affiliation. Les informations demandées doivent ensuite être récupérées auprès de l’infrastructure nationale du pays d’affiliation, traduites en anglais et transcodées (les données de santé sont transformées du système de codification national vers le système de codification communément accepté, par exemple du format FHIR ou KMEHR vers CDA), puis renvoyées et présentées au professionnel de santé du pays de traitement. Compte tenu du caractère sensible des données, les données devraient être chiffrées de bout en bout, depuis la source de données sur l’infrastructure du pays d’affiliation jusqu’au prestataire de soins de santé dans le pays de traitement. Dans la pratique, cela n’est pas encore possible en raison des différences importantes entre les pays européens. Cependant, il devrait être possible, au minimum, de garantir que les données restent chiffrées et inaccessibles à tout utilisateur ou administrateur entre la source des données et la sortie de la passerelle NCPeH. Une possibilité consiste alors à utiliser des EEC pour effectuer la traduction et le transcodage des données.

Un autre exemple d’utilisation des EEC est la collaboration sécurisée entre entités ne souhaitant pas partager leurs données brutes. Dans le secteur de l’éducation et de l’emploi, une expérience menée par Bogdanov et al en Estonie [10] a montré la puissance des techniques d’informatique confidentielle. Les auteurs de cette étude ont cherché à déterminer si le fait de travailler pendant les études supérieures était corrélé à un échec d’obtention du diplôme dans les délais impartis – une question particulièrement cruciale pour le secteur des technologies de l’information et de la communication en Estonie. Pour répondre à cette problématique sans compromettre la confidentialité des données personnelles, les chercheurs ont combiné les registres d’éducation du ministère de l’Éducation et de la Recherche avec les données de paiements d’impôts du Conseil des taxes et des douanes, grâce à une technique particulière d’informatique confidentielle. Mais une variante plus simple avec un EEC eût été tout aussi efficace pour l’analyse tout en respectant le secret fiscal et la protection des données.

CoCo

Plusieurs solutions logicielles sont disponibles pour mettre à profit les EEC sur notre propre infrastructure de recherche. Nous avons choisi d’utiliser le projet « Confidential Containers (CoCo) » dont le code source est ouvert. Il permet en effet une bonne isolation des conteneurs applicatifs et prend en charge le mécanisme d’attestation de manière transparente, tout en préservant la flexibilité de déploiement et la compatibilité avec la plateforme Kubernetes sur laquelle il s’appuie. Chaque capsule Kubernetes est isolée dans une machine virtuelle confidentielle très légère, de manière à garantir que seules les applications autorisées peuvent accéder aux données sensibles.

Les conteneurs CoCo contiennent quelques composants logiciels nécessaires en plus de l’application elle-même. Ceux-ci permettent de télécharger l’image du conteneur à exécuter, de faciliter la vérification de l’attestation et d’appliquer certaines politiques de sécurité. Leur interface de programmation est relativement petite, notamment par rapport à une solution où tout un nœud Kubernetes serait mis à l’intérieur d’une machine virtuelle confidentielle. En outre, l’image de la machine virtuelle invitée est statique et générique sur toutes les charges de travail et même les plateformes, permettant ainsi d’assurer plus simplement des garanties de sécurité. En même temps, le partage entre les conteneurs dans la même capsule Kubernetes est aisé. Par exemple, l’espace de noms du réseau de la capsule ne quitte pas la machine virtuelle confidentielle, autorisant ainsi les conteneurs qu’elle contient à communiquer de manière confidentielle sans coût supplémentaire.

CoCo s’appuie sur les conteneurs Kata, un autre projet de logiciel libre, qui permet de faire fonctionner des capsules Kubernetes à l’intérieur de machines virtuelles confidentielles très légères (voir Figure 1). CoCo ajoute cependant deux composants cruciaux afin d’assurer confidentialité et sécurité (voir Figure 2).

• Le premier concerne la récupération des images des conteneurs : celles-ci sont habituellement téléchargées par le nœud principal Kubernetes avec l’aide d’une interface d’exécution de conteneur (CRI) comme « containerd, » exposant ainsi les images à la machine hôte à travers le système de fichiers. Avec CoCo, les images sont déchiffrées, et décompactées à l’intérieur de la machine virtuelle confidentielle, d’où la nécessité des composants susmentionnés.
• Le second est l’attestation qui est, comme nous l’avons déjà vu, indispensable à l’établissement d’un environnement d’exécution de confiance. Par exemple, afin de déchiffrer une image, l’invité doit pouvoir obtenir la clé secrète de déchiffrement, mais celle-ci n’est fournie que si l’invité peut prouver son authenticité. C’est le rôle de deux composants qui s’appuient sur un système appelé « Trustee, » extérieur à la machine virtuelle et composé de deux services : un service d’attestation permettant de valider la base d’exécution de confiance et un service de médiation de clés permettant de fournir les ressources secrètes nécessaires à la machine virtuelle et à l’application.

CoCo fournit donc les bases pour construire des conteneurs applicatifs confidentiels en permettant d’exécuter ces conteneurs à l’intérieur de machines virtuelles confidentielles, gérant les images chiffrées et signées des conteneurs, les secrets scellés, et d’autres caractéristiques. Chaque conteneur ou groupe de conteneurs de la même application peut être assigné à une machine virtuelle confidentielle, incluant non seulement la charge de travail, mais aussi des processus permettant à l’application d’appeler certains services de sécurité.

Tout ce qui se trouve en dehors de la machine virtuelle confidentielle sur l’hôte est considéré comme non fiable, y compris l’outil kubelet, l’interface d’exécution de conteneurs et le noyau du système d’exploitation de l’hôte. Les échanges d’informations entre les contextes de confiance et non fiables sont strictement contrôlés, notamment via des politiques de sécurité dynamiques et configurables. Enfin, l’orchestration Kubernetes elle-même est considérée comme non fiable, limitant les garanties sur le planning ou l’ordre d’exécution des charges de travail, à l’exception de leur déploiement dans une enclave authentifiée.

Conclusion

Les conteneurs confidentiels s’inscrivent dans une démarche globale de sécurité, combinant attestation, vérification des images et bonnes pratiques de la chaîne d’approvisionnement logicielle. Ils permettent de traiter des cas d’usage plus simplement que la cryptographie avancée (collaboration confidentielle, intersection privée d’ensemble, pseudonymisation avancée, etc.). Certes les puristes argueront qu’une solution basée sur des conteneurs confidentiels est moins sûre, mais dans la pratique, elle sera probablement suffisante dans un cadre « on-premise », d’autant plus qu’elle simplifie beaucoup d’aspect une fois qu’elle est mise en place.

Dans l’article suivant, nous entrerons plus en détails dans l’installation et l’utilisation des conteneurs confidentiels CoCo.

Références

[1]        C. Bômont, « Strategic Brief no.70 – 2024 – Extension of the FISA Law European “digital sovereignty” far from American concerns – IRSEM », Institut de Recherche Stratégique de l’Ecole Militaire. Consulté le: 9 février 2026. [En ligne]. Disponible sur: https://www.irsem.fr/en/strategic-brief-no-70-2024

[2]        D. Michels, « Europeans, forget the US Cloud Act… worry about FISA instead (!) ». Consulté le: 1 juillet 2025. [En ligne]. Disponible sur: https://www.linkedin.com/pulse/europeans-forget-us-cloud-act-worry-fisa-instead-dave-michels-anjze

[3]        M. Rochefort, « Microsoft face au Sénat : l’aveu qui fait vaciller la souveraineté numérique française », clubic.com. Consulté le: 9 février 2026. [En ligne]. Disponible sur: https://www.clubic.com/actualite-573438-microsoft-face-au-senat-l-aveu-qui-fait-vaciller-la-souverainete-numerique-francaise.html

[4]        D. Deridder, « Understanding Sovereignty: Who Rules your Cloud? », Dirk Deridder. Consulté le: 1 juillet 2025. [En ligne]. Disponible sur: https://dirkderidder.wordpress.com/2025/03/13/understanding-sovereignty-who-rules-your-cloud/

[5]        P. Kunert, « Microsoft exec admits it “cannot guarantee” data sovereignty », The Register. Consulté le: 28 juillet 2025. [En ligne]. Disponible sur: https://www.theregister.com/2025/07/25/microsoft_admits_it_cannot_guarantee/

[6]        F. A. P. Petitcolas, « Informatique confidentielle – État de l’art », Smals Research, juill. 2023. [En ligne]. Disponible sur: https://www.smalsresearch.be/publications/document?docid=269

[7]        F. A. P. Petitcolas, « Introduction à l’informatique confidentielle », Smals Research. Consulté le: 9 janvier 2026. [En ligne]. Disponible sur: https://www.smalsresearch.be/introduction-a-l-informatique-confidentielle/

[8]        F. A. P. Petitcolas, « Outils pour l’informatique confidentielle », Smals Research. Consulté le: 9 janvier 2026. [En ligne]. Disponible sur: https://www.smalsresearch.be/outils-pour-linformatique-confidentielle/

[9]        J. De Meulemeester, D. Oswald, I. Verbauwhede, et J. V. Bulck, « Battering RAM: Low-cost interposer attacks on confidential computing via dynamic memory aliasing », présenté à 47th IEEE Symposium on Security and Privacy (S&P), mai 2026.

[10]      D. Bogdanov, L. Kamm, B. Kubo, R. Rebane, V. Sokk, et R. Talviste, « Students and taxes: a Privacy-preserving study using secure computation », Proc. Priv. Enhancing Technol., vol. 2016, n^o 3, p. 117‑135, juill. 2016, doi: 10.1515/popets-2016-0019.

Les données personnelles numériques constituent une source d’informations qui favorise l’innovation, le bien-être et la formulation de politiques. Ces données personnelles se trouvent dispersées dans de nombreuses organisations : l’une détient des données sur le cancer, une autre sur la consommation de médicaments et une autre encore sur les revenus. Dans la pratique, les données personnelles provenant de différentes organisations sont régulièrement regroupées afin de répondre à des questions spécifiques posées par des chercheurs et des décideurs politiques.

Les processus actuels garantissent que le respect de la vie privée dans ce contexte. Il s’agit malheureusement trop souvent d’une opération complexe, coûteuse et chronophage. En collaboration avec des universités de renommée internationale, Smals Research a donc travaillé à l’élaboration d’un prototype visant à simplifier considérablement ces processus à l’aide d’une cryptographie avancée.

Problématique basée sur un cas concret

Nous sommes partis d’une question de recherche concrète :

Les patients atteints de SEP (sclérose en plaques) sous traitement à base de molécules de tériflunomide ou d’alemtuzumab courent-ils un risque accru de cancer par rapport aux patients atteints de SEP traités avec d’autres médicaments ?

Pour répondre à cette question, simple en soi, il est nécessaire de croiser les données médicales relatives aux patients atteints de SEP provenant de deux organisations, à savoir le Registre belge du cancer (BCR) et l’Agence InterMutualiste (AIM).

Les deux organisations gèrent les données sous des pseudonymes distincts pour plus de confidentialité ; des codes uniques remplacent les numéros de registre national.

• Le BCR gère les données relatives au cancer concernant les personnes qui ont reçu un diagnostic de cancer. Le BCR ne sait pas quels enregistrements concernent des patients atteints de SEP.
• L’AIM dispose de données relatives aux médicaments prescrits et peut sélectionner les enregistrements des patients atteints de SEP.

Les chercheurs doivent avoir accès, dans un environnement sécurisé (SPE = Secure Processing Environment), aux données provenant du BCR et de l’AIM concernant tous les patients atteints de SEP. Les données relatives à un même patient mais issues de sources différentes doivent pouvoir être reliées entre elles sur la base d’un pseudonyme unique utilisé uniquement dans le cadre de cette question de recherche spécifique. Ceci est représenté dans l’illustration 1.

La question centrale est la suivante :

Comment le BCR peut-il fournir uniquement des enregistrements sur les patients atteints de SEP à l’environnement sécurisé sans savoir qui est atteint de SEP ou quels enregistrements qu’il gère concernent des patients atteints de SEP ?

Dans une approche classique, soit le BCR enverra trop d’informations à l’environnement sécurisé – notamment des données sur chaque patient atteint d’un cancer –, soit des informations seront divulguées au BCR – qui découvrira alors quels enregistrements concernent des patients atteints de SEP. Une dernière possibilité consiste à faire appel à une entité centrale de confiance qui, certes, aura connaissance des données à caractère personnel, mais à qui l’on peut faire confiance pour ne pas en faire un usage illicite.

Aucune de ces approches n’est idéale. Aujourd’hui, tant au niveau national qu’international, on fait appel à des intermédiaires centraux fortement réglementés ou on opte pour des solutions sur mesure coûteuses et lentes, dans lesquelles un nouveau flux est défini, validé et mis en œuvre pour chaque question de recherche afin de protéger au maximum la vie privée.

De plus, le chercheur a généralement besoin d’accéder aux données brutes, ce qui rend les solutions basées sur le secure multi-party computation inadaptées. 

Notre proposition de solution

Partons d’un scénario fictif dans lequel nous travaillons avec un intermédiaire de confiance et où, pour simplifier, l’AIM et le BCR ne gèrent pas les données à caractère personnel sous des pseudonymes, mais sous des numéros de registre national. L’AIM et le BCR envoient tous deux toutes les données potentiellement pertinentes à l’intermédiaire de confiance.

Le BCR envoie à l’intermédiaire les données identifiées relatives au cancer de tous les citoyens qui ont reçu un diagnostic de cancer, ce qui est bien sûr beaucoup plus que ce dont le chercheur a besoin. L’intermédiaire reçoit également toutes les données identifiées relatives aux médicaments prescrits aux patients atteints de SEP de l’AIM et sait ainsi, sur cette base.

L’intermédiaire reçoit également toutes les données identifiées relatives aux médicaments prescrits aux patients atteints de SEP de l’AIM. Il sait ainsi quels enregistrements fournis par le BCR concernent des patients atteints de SEP et donc quels enregistrements sont pertinents dans le cadre de la question de recherche. L’intermédiaire entreprend alors les étapes suivantes :

1. Il supprime les enregistrements non pertinents, c’est-à-dire les enregistrements concernant tous les citoyens qui ont reçu un diagnostic de cancer mais qui ne sont pas atteints de SEP.
2. Il fusionne les enregistrements concernant les mêmes citoyens et remplace les numéros de registre national par des pseudonymes uniques dans les enregistrements fusionnés.
3. Il envoie le résultat – uniquement les enregistrements fusionnés – vers l’environnement sécurisé.
4. Il supprime toutes les données reçues et dérivées.

Dans ce scénario, il n’y a pas de fuite involontaire de données vers les sources de données et l’environnement sécurisé ne reçoit que les données personnelles pseudonymisées minimales nécessaires.

Notre prototype fait exactement cela, mais sans l’intermédiaire de confiance. Le rôle de l’intermédiaire de confiance est distribué : les détenteurs de données – dans ce cas, l’AIM et le BCR – et un collecteur de données – dans ce cas, l’environnement sécurisé – interagissent pour assumer ensemble le rôle de l’intermédiaire de confiance. Les caractéristiques de sécurité mentionnées dans le paragraphe précédent sont conservées ; aucune information n’est donc divulguée involontairement aux détenteurs de données et le collecteur de données ne prend connaissance que des données pseudonymisées strictement nécessaires. La solution reste néanmoins pratique et efficace. Tout cela est possible grâce à une cryptographie avancée.

Comme nous l’avons mentionné précédemment, l’AIM et le BCR conservent les données sous des pseudonymes. Il existe des procédures permettant de les convertir de manière contrôlée en numéros de registre national. L’entité qui gère les données n’a jamais connaissance des registres nationaux et l’entité qui peut associer les pseudonymes aux numéros de registre national n’a à aucun moment accès aux données à caractère personnel proprement dites. Par souci de simplicité et pour la suite de cet article, nous partons du principe que les détenteurs de données connaissent les données identifiées par les numéros de registre national plutôt que par les pseudonymes. Notre concept peut également s’appliquer de manière sécurisée à des situations plus réalistes où ce n’est pas le cas.

Dans la pratique

Smals Research a développé ce concept en collaboration avec des partenaires universitaires. Initialement baptisé Oblivious Join, il a été renommé LetheLink dans le contexte universitaire. Lethe (Λήθη) est, dans la mythologie grecque, la déesse de l’oubli et l’un des cinq fleuves des enfers, au bord duquel les morts s’abreuvent pour oublier leur vie terrestre. Malgré cet oubli – ou plutôt ce manque de connaissance –, les entités en interaction parviennent à relier entre elles les données nécessaires. La convivialité et l’efficacité ont été au cœur du développement de ce concept.

Smals Research a développé un prototype démontrable qui donne déjà un aperçu du fonctionnement d’une solution entreprise-ready. L’utilisation du prototype est présentée dans l’illustration 2 et comprend les étapes suivantes :

1. Création d’un fichier JSON. Une organisation pouvant servir de point de contact (par exemple, la HDA ou la BCSS) reçoit une demande d’un chercheur. Lorsque la base juridique pour ce traitement de données existe, cette organisation établit un fichier JSON signé numériquement. Ce fichier JSON contient, sous une forme structurée, toutes les informations nécessaires à l’exécution correcte du protocole pour le croisement sécurisé des données des détenteurs de données : les données de connexion des clients des détenteurs de données et du collecteur de données, les paramètres cryptographiques, les clés publiques, les informations sur les données que chaque détenteur de données doit fournir, etc. Dans la pratique, on partira de templates à partir desquels on pourra dériver des fichiers JSON avec un minimum d’effort.
2. Distribution du fichier JSON. Ce fichier JSON est envoyé à la fois au collecteur de données et aux détenteurs de données. Tous vérifient la signature numérique. Toutes les entités concernées savent désormais comment exécuter le protocole et comment contacter les autres entités concernées en toute sécurité.
3. Téléchargement du client. Si ce n’est pas déjà fait, le collecteur de données et les détenteurs de données téléchargent le client LetheLink.
4. Création de fichiers CSV. Sur la base du fichier JSON, chaque détenteur de données génère un fichier CSV contenant toutes les données identifiées potentiellement pertinentes. Dans le scénario décrit précédemment, cela inclurait, pour le BCR, toutes les informations identifiées demandées concernant tous les citoyens ayant reçu un diagnostic de cancer. La création de ce fichier ne relève pas du champ d’application de LetheLink. Notre prototype ne prend en charge que les fichiers CSV, mais cette fonctionnalité peut être étendue.
5. Importation du client. Chaque participant fournit le fichier JSON à son client LetheLink local. Les détenteurs de données fournissent également leur fichier CSV généré localement à leur client. Les données sont livrées en clair et le client se charge du chiffrement.
6. Exécution du protocole. Le protocole est exécuté. Du côté du collecteur (SPE) des données, cela donne un fichier CSV qui ne contient que les données pseudonymisées et minimales nécessaires.

L’avantage de cette approche réside dans sa flexibilité d’utilisation. Certains détenteurs de données ne sont impliqués que très occasionnellement dans de tels projets croisés et tous les détenteurs de données ne disposent pas des mêmes ressources. Grâce à l’approche LetheLink, nul besoin de réaliser d’importants investissements ou préparatifs. Il suffit d’installer le client et de créer le fichier CSV.

L’illustration 3 présente un exemple fictif de tels fichiers CSV. En haut figurent des extraits de fichiers CSV que les détenteurs de données (trois dans le cas présent) fournissent chacun en entrée à leur client LetheLink. Au bas de l’illustration, un extrait du fichier CSV généré en sortie par le client du collecteur de données à la suite de l’exécution du protocole est présenté. Dans notre exemple fictif, le chercheur s’intéresse uniquement aux données transversales, c’est-à-dire aux données relatives aux 50 000 patients atteints de SEP qui ont reçu un diagnostic de cancer et présentent un profil de risque élevé. La personne dont le numéro de registre national est 60.01.05-045.05 appartient à ce groupe. Le collecteur de données voit les informations combinées sur ce citoyen, non pas sous ce numéro de registre national, mais sous le pseudonyme “153807…”.

Performance

Dans le cadre de la collaboration académique, la performance a été considérablement améliorée au cours de plusieurs itérations, tant au niveau de l’algorithme qu’au niveau de la mise en œuvre. Les principaux résultats des tests sont présentés dans le tableau 1. Quelques précisions :

• Les tests ont été effectués sur des machines virtuelles AWS EC2 r7i.8xlarge, avec 32 vCPU (Intel Xeon Platinum 8588C @ 3,2 GHz) et 256 Go de RAM.
• Une distinction est opérée entre une exécution sur un LAN à une vitesse de 1 Gbps et sur un WAN à une vitesse de 150 Mbps.
• La variable m représente le nombre d’enregistrements fournis par chacune des sources de données. Dans nos tests, elle est comprise entre un minimum de 2¹⁶= 65.536 et maximum de 2²⁴= 16.777.216. En réalité, le nombre d’enregistrements varie bien sûr selon la source de données, mais ces résultats fournissent déjà une limite supérieure.
• La variable κ (kappa) représente le niveau de sécurité computationnel. Une sécurité de 128 bits est suffisante aujourd’hui, mais une sécurité de 192 ou même de 256 bits est recommandée pour les données qui restent sensibles pendant une longue période. La variable λ (lambda) représente le paramètre de sécurité statique correspondant. 
• La variable n représente le nombre de détenteurs de données. Nous avons effectué des tests avec 3, 5 et 7 détenteurs de données, mais il n’y a aucune limitation technique pour un nombre beaucoup plus important.

Maintenant que nous savons comment interpréter ce tableau, nous constatons par exemple qu’il faut 25 secondes pour exécuter le protocole lorsque trois sources de données fournissent chacune 1 million (2²⁰) d’enregistrements sur un WAN. La quantité de données fournies a également un impact sur le temps d’exécution, mais pour cela, nous vous renvoyons au tableau 3 de notre publication commune. En résumé, tant le protocole que sa mise en œuvre sont particulièrement efficaces. Pour conclure, l’illustration 4 donne une idée générale de la réalisation des tests.

Relation avec le service de pseudonymisation à l’aveugle d’eHealth

Smals Research a développé le service de pseudonymisation à l’aveugle pour eHealth au cours de la période 2021-2022. Ce service permet de convertir les numéros de registre national en pseudonymes (codes uniques) et vice versa. Cette conversion est effectuée par un service de pseudonymisation qui est toutefois aveugle : il ne voit ni les numéros de registre national ni les pseudonymes. Ce service peut également être utilisé pour pseudonymiser et croiser des données. Quelles sont les différences ?

• Statut. Le service de pseudonymisation à l’aveugle est déjà en production, tandis que LetheLink n’est qu’un prototype.
• Fuite de données. Pour les projets de recoupement plus complexes, tels que ceux évoqués dans cet article, le service de pseudonymisation à l’aveugle ne pourra pas toujours empêcher les fuites de données. Il y aura notamment des fuites de données lorsqu’une source de données ne peut pas déterminer de manière autonome quels enregistrements sont pertinents pour répondre à la question de recherche. Selon le use case, il peut s’agir d’une fuite de données résiduelle acceptable ou de fuites de données plus substantielles, qui portent effectivement atteinte à la vie privée des personnes concernées. D’autre part, LetheLink présente des risques lorsqu’une seule entité est à la fois détentrice et collectrice de données.
• Rapidité. Le service de pseudonymisation à l’aveugle d’eHealth est certes très rapide – il peut effectuer des milliers de conversions par seconde -, mais LetheLink est ultra-rapide – il effectue des dizaines de milliers de conversions par seconde et, dans certaines circonstances, peut dépasser les cent mille. Tout dépendra bien sûr de l’infrastructure utilisée.
• Infrastructure. Le service de pseudonymisation à l’aveugle d’eHealth est dans tous les cas une entité centrale qui doit disposer d’une capacité suffisante. LetheLink, en revanche, est distribué, ce qui rend inutile une telle entité centrale : il suffit que chaque entité exécute le client LetheLink sur ses machines existantes. Il peut même s’agir d’ordinateurs portables classiques.
• Intégration. Afin d’utiliser le service de pseudonymisation à l’aveugle, une organisation doit intégrer une logique dans son application client. Nous savons par expérience que cela est relativement simple, mais cela reste néanmoins un investissement. LetheLink est un client autonome et ne nécessite donc aucun processus d’intégration.
• Types de demandes. Le service de pseudonymisation à l’aveugle d’eHealth peut traiter tant les demandes en batch que les demandes qui doivent être traitées en temps réel. LetheLink ne prend en charge que les traitements en batch.

Ce positionnement respectif de LetheLink et du service de pseudonymisation à l’aveugle d’eHealth devrait aider les organisations à déterminer la technologie la plus adaptée à leurs use cases.

Extensions

Un certain nombre d’extensions de LetheLink seront nécessaires pour pouvoir l’utiliser dans la pratique. Toutes les extensions proposées sont déjà conceptuellement possibles, mais ne sont pas toujours intégrées dans le prototype. Cela ne se fera que si une demande concrète est formulée.

• Taille minimale de l’ensemble de résultats. Si l’ensemble de résultats pseudonymisés pour le collecteur de données ne contient pas suffisamment d’enregistrements, il existe un risque pour la vie privée des personnes concernées et il est impossible de mener des recherches statistiquement pertinentes. C’est pourquoi le prototype prend déjà en charge la possibilité d’indiquer une taille minimale dans le fichier JSON.
• Réidentification contrôlée. Si les chercheurs constatent qu’un citoyen donné présente un risque élevé de développer une certaine maladie, il doit être possible d’en informer ce citoyen. De même, lorsqu’une enquête sur une fraude révèle une forte suspicion de fraude de la part de certains citoyens, il doit être possible d’en informer l’autorité compétente. Il doit donc être possible, dans des situations exceptionnelles, de vérifier l’identité d’un citoyen de manière contrôlée.
• Pseudonymes des détenteurs de données. Comme indiqué précédemment dans cet article, les détenteurs de données n’ont souvent pas eux-mêmes accès au numéro de registre national des citoyens dont ils gèrent les données. Dans de tels cas également, le protocole doit pouvoir être mis en œuvre efficacement.
• Divulgation sélective. Actuellement, le prototype se concentre sur des moyennes ; ce n’est que si tous les détenteurs de données fournissent des enregistrements sur un même citoyen que l’enregistrement composite devient visible pour le collecteur de données. Dans la pratique, une plus grande flexibilité est requise, comme l’indique l’illustration 5. Dans le cas d’utilisation présenté en introduction de cet article, le chercheur avait besoin de données pseudonymisées sur tous les patients atteints de SEP, alors que notre prototype ne fournit actuellement que des données pseudonymisées sur tous les patients atteints de SEP ayant également reçu un diagnostic de cancer.
• Transfert multi-batch. Dans certains cas, les détenteurs de données doivent fournir des données à plusieurs reprises au collecteur de données, par exemple dans le cadre d’une étude longitudinale. Le collecteur de données doit être capable de relier entre elles les données relatives à un même citoyen au fil du temps.
• Communication simplifiée. Dans le prototype, tous les détenteurs de données concernés communiquent entre eux, puis envoient individuellement des données cryptées au collecteur de données. Dans un protocole adapté, les détenteurs de données n’échangeraient des données qu’avec et via le collecteur de données, par exemple via une interface REST. Dans la pratique, cette approche est plus souhaitable.

Veuillez nous faire part de toute autre extension utile que vous pourriez envisager.

Références

Le concept initial ainsi que le prototype et les tests de performance ont été réalisés par Smals Research. Les partenaires universitaires, notamment le groupe COSIC et le groupe DistriNet de la KU Leuven, ainsi que le groupe CrySP de l’université de Waterloo au Canada, se sont concentrés sur l’élaboration théorique. Cela a donné lieu à deux publications en 2025 :

• Publication de Springer :Privacy-By-Design in the Belgian Public Sector Ce document accessible traite de deux solutions innovantes conçues par Smals Research pour la pseudonymisation et le croisement des données à caractère personnel : Lethelink et le service de pseudonymisation à l’aveugle d’eHealth.
• Publication de Springer :Privacy-By-Design in the Belgian Public Sector Ce document accessible traite de deux solutions innovantes conçues par Smals Research pour la pseudonymisation et le croisement des données à caractère personnel : Lethelink et le service de pseudonymisation à l’aveugle d’eHealth.

Je vous invite également à consulter ma contribution à la conférence Devoxx et mon webinaire de 2024 intitulé “Privacy in Practice with Smart Pseudonymisation”. LetheLink/Oblivious Join est l’une des trois techniques de pseudonymisation que j’y aborde.

Enfin, des slides sont disponibles pour ceux qui souhaitent se faire rapidement une idée intuitive des principes de base de l’Oblivious Join. Les notes correspondantes fournissent des explications supplémentaires.

Conclusion

L’utilisation secondaire des données à caractère personnel peut nous fournir de nombreuses informations qui soutiennent l’élaboration des politiques et stimulent la recherche scientifique. Pour exploiter ces informations, les données provenant de différentes sources doivent pouvoir être collectées de manière efficace, dans le respect de la vie privée. Cela signifie que seules les données à caractère personnel nécessaires sont pseudonymisées et croisées et que les autres entités participant à ce processus n’ont pas accès aux données à caractère personnel. Dans la pratique, cela était loin d’être évident.

En collaboration avec des universités de renommée internationale, Smals Research a donc élaboré un concept qui, grâce à une cryptographie avancée, permet de le faire de manière efficace. Un prototype démontrable a également été construit, ce qui constitue une première étape vers une mise en œuvre effective dans la pratique.

Au cours des dernières années, nous avons rencontré de nombreuses entités. Tout le monde considère qu’il s’agit d’un outil très utile, mais nous ne disposons pour l’instant pas de l’engagement de nos partenaires pour le mettre en pratique.

Le défi principal aujourd’hui est donc de rendre cette solution prête à la production. N’hésitez pas à nous contacter si cette solution vous intéresse et si vous souhaitez éventuellement y contribuer.

Le potentiel multilingue remarquable des grands modèles de langage (LLM) a contribué à leur adoption et à leur intégration généralisées au sein des applications basées par l’IA. Cependant, des disparités de performance existent entre l’anglais et d’autres langues, notamment les langues à faibles ressources.

Lors de l’évaluation d’un agent conversationnel (chatbot) RAG que nous avons développé, nous avons constaté une différence nette en termes de qualité des réponses selon la langue utilisée. Plus précisément, le chatbot a produit des réponses de meilleure qualité en français par rapport au néerlandais. Les réponses générées en français se caractérisaient par une plus grande fluidité et une meilleure fidélité aux informations requises par l’utilisateur. Les réponses en néerlandais ont tendance à être moins pertinentes. Ces résultats soulignent un défi crucial dans le développement des LLM utilisés par les chatbots : bien que ceux-ci présentent des capacités multilingues impressionnantes, les modèles actuels manifestent souvent un biais prononcé en faveur des langues à ressources élevées telles que l’anglais.

Cet article de blogue détaille les résultats de notre recherche sur l’écart linguistique que nous avons identifié, présentant les résultats de notre investigation.

Écart de performance entre l’anglais et les autres langues : causes et facteurs

Plusieurs facteurs contribuent au biais linguistique en faveur de l’anglais. Ceux-ci incluent :

• Déséquilibre des données : Le processus d’entraînement des grands modèles de langage repose sur des corpus textuels importants, mais ces derniers sont massivement dominés par l’anglais, suivi par les langues bien dotées en ressources linguistiques telles que le chinois, le français ou l’espagnol. En revanche, les données dans les langues à faibles ressources sont souvent de mauvaise qualité en raison d’un nombre limité de sources. Ce déséquilibre des données entraîne de faibles performances dans les langues autres que l’anglais, donnant des taux d’erreur plus élevés et des hallucinations. Afin de remédier à ce problème, les développeurs de modèles s’appuient sur une technique appelée “transfert inter linguistique”, où un modèle améliore ses performances dans les langues moins dotées en déduisant des schémas linguistiques universels ou partagés à partir des langues à ressources élevées. Bien que le pourcentage exact de données en langue anglaise dans les modèles propriétaires ne soit pas publiquement connu, 93 % des données utilisées pour entraîner GPT-3 sont en anglais. Les fournisseurs de grands modèles de langage, tels qu’OpenAI et Google, utilisent fréquemment l’archive de données web Common Crawl, qui est lui-même caractérisé par un ensemble de données ou l’anglais est prédominant (44 % en anglais, 4 % en français, 2 % en néerlandais). Ce biais est exacerbé dans des domaines spécialisés, tels que la finance et la santé, où les données de haute qualité sont particulièrement rares. Il est important de noter que le néerlandais est considéré comme une langue à ressources élevées dans le domaine du traitement automatique du langage naturel (NLP) bien que disposant de moins de ressources que le français ou l’anglais.
• Morphologie et tokenisation : Les architectures de modèles sont souvent optimisées pour l’anglais. Les processus de tokenisation peuvent être difficiles pour les langues à écriture non latine, telles que le chinois et le japonais, ainsi que pour les langues à morphologie de complexité moyenne à élevée, telles que le néerlandais. Les tokeniseurs centrés sur l’anglais peuvent éprouver des difficultés à traiter les mots composés (la combinaison de plusieurs noms en un seul mot), ce qui peut mener à un résultat grammaticalement incorrect lorsque les modèles génèrent du texte.

Très peu d’études comparatives ont analysé les performances des grands modèles de langage en néerlandais et en français. Une étude analysant la qualité linguistique des LLM dans ces deux langues a révélé que les performances étaient généralement meilleures en français qu’en néerlandais, en particulier dans les tâches de génération d’articles [1]. Une autre étude a rapporté de meilleures performances des LLM en anglais comparativement au néerlandais dans une tâche de question-réponse [2].

Des défis importants persistent dans l’industrie concernant l’application des grands modèles de langage à des domaines techniques non anglais, en particulier dans des secteurs tels que la médecine et la finance. Les déploiements actuels nécessitent souvent un affinage des modèles pré-entrainés tels que Mistral et Llama pour atteindre des performances satisfaisantes.

Un autre défi bien connu dans l’application de modèles d’IA dans l’environnement linguistique néerlandais est la reconnaissance vocale, largement due à la grande variation des accents régionaux. Nos expériences de transcription d’enregistrements de réunions Teams ont révélé que les transcriptions françaises étaient systématiquement de meilleure qualité que les transcriptions néerlandaises. Cependant, des outils spécialisés tels que Sembly fournissent des résultats de transcription en néerlandais acceptables.

Analyse comparative des performances du néerlandais et du français dans un chatbot

Une analyse comparative des performances a été menée sur un chatbot développé pour répondre aux questions formulées par les citoyens. Pour l’évaluation initiale du chatbot, nous avons utilisé un ensemble de questions proposées par les experts métier. Ces mêmes questions ont été présentées au chatbot en français et en néerlandais, les réponses ont été évaluées par le même expert et revues par deux autres personnes. Les premières évaluations ont révélé une différence significative de performance entre les deux langues : le chatbot a obtenu un taux de précision de 95 % en français, contre 82 % en néerlandais.

Suite au déploiement du chatbot dans un environnement de production, une seconde phase d’évaluation a été réalisée en utilisant des questions soumises par les utilisateurs et enregistrées dans une base de données. Nous avons de nouveau relevé une divergence de performances : 82 % de précision en français et 69 % en néerlandais.

Plusieurs facteurs pourraient contribuer à ces écarts observés, notamment :

• Les biais introduits par les évaluateurs – les évaluateurs sont plus ou moins sévères dans leurs évaluations;
• La variation dans les types de questions (ambiguës, mal formulées, hors sujet) – les mêmes questions n’ont pas été systématiquement évaluées dans les deux langues;
• La différence de qualité dans la récupération des sources (retrieval) – on observe des variations entre les langues dans les sources de données récupérées pour alimenter la génération;
• Les capacités intrinsèques du modèle génératif (GPT-4o) dans les deux langues.

Des investigations supplémentaires étaient donc nécessaires pour pleinement comprendre les différences observées en français et en néerlandais et atténuer ces facteurs.

Test

Afin d’évaluer rigoureusement les performances des LLM à la fois en français et en néerlandais, une expérience a été menée avec le chatbot. Nous avons sélectionné un échantillon de questions où les réponses précédentes des LLM avaient été jugées inexactes, en nous assurant que les questions étaient ni trop complexes, ni trop simplistes. Il était crucial que chaque question formulée par un utilisateur soit traduite entre le français et le néerlandais pour faciliter une comparaison directe. Le processus d’évaluation a impliqué deux évaluateurs indépendants, un expert métier et un expert technique, afin de réduire les biais et d’assurer une évaluation robuste. Les évaluateurs ont évalué l’exactitude, la pertinence et la fluidité des réponses générées. De plus, d’autres modèles que GPT-4o ont été testés.

En plus des tests en néerlandais et en français, nous avons également réalisé un test où des questions en néerlandais ont été traduites en anglais. Les réponses ont été générées en anglais puis traduites à nouveau en néerlandais.

Résultats

Question en néerlandais, Réponse en anglais

L’expérience consistant à traduire des questions posées en néerlandais en anglais et à traduire ensuite des réponses en néerlandais a révélé une performance nuancée. Si la traduction des questions néerlandaises en anglais a entraîné une légère amélioration de la qualité des réponses, passant de 67 % à 73 %, le processus inverse, traduisant les réponses anglaises générées en néerlandais, a davantage dégradé la qualité des réponses.

Précision des réponses françaises versus précision des réponses néerlandaises

Lors de notre expérience, nous avons comparé les réponses générées à partir de questions en néerlandais et leurs équivalents en français sur plusieurs ensembles de test. Nous avons observé l’influence de la composition de ces ensembles sur l’évaluation du modèle. En effet, Les scores variaient d’un ensemble à l’autre pour chaque modèle et chaque langue, et les disparités de performance entre les langues ne se manifestaient pas toujours. Cela souligne l’importance du processus de sélection des questions de test: pour notre dernier test, nous avons constitué un ensemble de test équilibré intégrant des échantillons de questions soumises par les utilisateurs dans les deux langues et des questions élaborées par des experts du domaine. Contrairement à ce qui avait été initialement observé, les résultats présentés ci-dessous ne révèlent qu’une différence légère en termes de précision entre le français et le néerlandais pour notre cas d’utilisation.

Table 1. Résultats de l’évaluation finale du chatbot.

Note : Les questions mal formulées en français ou en néerlandais ont été exclues de l’ensemble de test car elles se sont révélées difficiles à traduire avec précision dans l’autre langue.

Comparaison des LLM

GPT-5 a démontré de bonnes performances en termes de précision et de concision, cependant il a présenté un écart de précision plus important entre le français et les néerlandais que les autres modèles. Gemini, bien qu’il affiche de meilleures performances tant en français qu’en néerlandais, a généré des réponses notablement plus longues, ce qui a entraîné une utilisation de jetons plus élevée. Nous avons également observé que Claude Sonnet, qui présente une précision similaire à celle de Gemini, avait quelques fois intégré de l’anglais dans la réponse générée, plus souvent en néerlandais qu’en français. Après évaluation, les experts du domaine ont conclu que Gemini était le modèle le plus adapté à leur cas d’utilisation.

Effet de la récupération

Le processus de récupération consiste à extraire des fragments de texte pertinents pour répondre à une question à partir de la base de données vectorielle, en fonction de la similarité entre la question et ces fragments. Cette similarité est calculéee à l’aide des représentations vectorielles des textes, générées par un modèle d’embedding. Nous avons analysé des questions qui avaient donné initialement de meilleurs résultats en français qu’en néerlandais et avons observé qu’environ 50 % de l’information récupérée (contexte) était partagée entre les deux langues. Afin d’évaluer l’impact des 50 % restants d’informations divergentes, nous avons soumis le modèle (Gemini) à des contextes identiques pour générer des réponses tant en français qu’en néerlandais. Malgré l’utilisation de ces contextes identiques, le modèle a continué à présenter des disparités de performance entre le français et le néerlandais. Par conséquent, le processus de récupération semble avoir une influence limitée sur l’écart de performance observé entre les deux langues.

Conclusions et recommandations

L’écart de performance des grands modèles de langage rapporté entre le néerlandais et  l’anglais est un fait établi, enraciné dans la domination écrasante de l’anglais dans les corpus d’entraînement. Cet écart est exacerbé par la morphologie spécifique du néerlandais. Comparativement, si les LLM produisent généralement de meilleurs résultats en français, cela est dû à une meilleure représentation de la langue au sein des corpus d’entraînement.

Notre expérience a fourni des informations précieuses sur les performances des LLM dans une application RAG (Retrieval Augmented Generation) en néerlandais et en français. Bien que nous ayons initialement observé une différence significative en termes de justesse entre les réponses en néerlandais et les réponses en français, des investigations approfondies ont révélé que d’autres facteurs que la capacité du modèle pouvaient influencer les résultats. L’écart de performance est donc moins important que ce que nous pensions. De plus, nous avons constaté que les variations dans la composition de l’ensemble de test introduisaient de légères fluctuations dans les résultats. Ces conclusions démontrent que la performance des LLM est très sensible au contexte et à la formulation spécifique des questions. Nous avons également observé une légère amélioration de la qualité des réponses lors de la traduction des questions néerlandaises en anglais; cependant, cet avantage a été largement annulé par la traduction ultérieure de ces réponses anglaises en néerlandais.

Les conclusions présentées ci-dessus sont valables lorsqu’on considère un chatbot utilisant des contenus soigneusement rédigées dans un langage commun pour répondre à des questions. Elles ne sont pas nécessairement applicables à d’autres cas d’utilisation, il est donc essentiel de réaliser des évaluations approfondies pour chaque cas, en particulier lorsqu’on travaille dans des domaines spécifiques tels que la santé, la finance, le droit…

Devrions-nous utiliser un modèle monolingue ?

Nous n’avons pas été en mesure d’examiner cette question de manière approfondie. Notre recherche dans la littérature n’a pas révélé de preuves solides indiquant une amélioration des performances grâce aux LLM dédiés au néerlandais ; a contrario, la présence de langues à ressources élevées dans les modèles multilingues semble améliorer la performance de langues moins dotées jusqu’à un certain degré. Cependant, plusieurs initiatives ont été lancées pour le développement de LLM en néerlandais. Les plus notables sont :

• GEITje : Un modèle basé sur Mistral 7B et affiné sur le néerlandais. Ce modèle n’est plus disponible en raison de problèmes de droits d’auteur.
• GPT-NL : Une initiative en cours, soutenue par les Pays-Bas, visant à développer un LLM adapté à la langue et à la culture néerlandaise.

Références

1. Exploratory Study on the Impact of English Bias of Generative Large Language Models in Dutch and French(Rigouts Terryn & de Lhoneux, HumEval 2024)
2. Performance of Large Language Models in Domain-Specific and Underrepresented Languages: A Case Study on the Transportation Domain and Dutch Language (UHasselt)
3. MEGA: Multilingual Evaluation of Generative AI (Ahuja et al., 2023)
4. A Dutch Financial Large Language Model (Sander Noels, Jorne De Blaere & Tijl De Bie, 2024)
5. Multilingual LLMs: Progress, Challenges, and Future Directions (article de blogue PremAI)
6. https://hogent-cads.github.io/blog/posts/vlaamse-spraakherkenning/ (article de blogue HoGent)

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.

(FR) Dans ce Research Talk (en Néerlandais, sous-titres FR sont disponibles), Joachim Ganseman, chercheur chez Smals, est interrogé sur ses expériences avec les systèmes « Rules as Code » (RaC) et leur mise en œuvre au sein du domaine — complexe — de la sécurité sociale. Joachim émet quelques réserves quant à l’applicabilité directe de ces systèmes dans notre contexte. Regardez et écoutez ici pourquoi.

(EN) In this Research Talk (Dutch speaking, EN subtitles available), Joachim Ganseman, researcher at Smals, is interviewed about his experiences with “Rules as Code” (RaC) systems and their implementation within the complex domain of social security. Joachim places some reservations regarding the direct applicability of these systems in our context. Watch and listen here to find out why. 

Où est Charlie ? est un jeu bien connu qui consiste à trouver un personnage spécifique – appelé Charlie – dans un dessin très détaillé où figurent de nombreux autres personnages. Comment Paula (fournisseur de preuve ou prouveur) peut-elle prouver à Victor (vérificateur) qu’elle sait où se trouve Charlie sans révéler de détails sur sa position dans l’image ? Paula peut se servir d’un cache dont la hauteur et la largeur sont deux fois plus grandes que celles de l’image dans laquelle est caché Charlie. Au centre du cache se trouve un trou de la taille de Charlie. En positionnant le cache de manière à ce que le trou laisse entrevoir Charlie uniquement, Paula prouve à Victor qu’elle a localisé Charlie sans révéler d’informations sur son emplacement.

Il s’agit là d’un exemple de preuve à divulgation nulle de connaissance (en anglais zero-knowledge proof), ou preuve ZK, qui permet à une partie de prouver une affirmation à une autre partie sans divulguer plus de détails sur cette affirmation. À strictement parler, l’exemple de Charlie n’est pas tout à fait sans divulgation de connaissance, car des informations sur la posture et l’expression faciale de Charlie sont également divulguées, ce qui peut aider à le retrouver.

Un autre exemple, pour lequel une preuve de concept a été élaborée, permettrait de prouver au public que l’ADN d’un candidat à la présidence n’est pas répertorié dans une base de données ADN médico-légale. La police exécuterait un code accessible au public sur des données qui resteraient cachées au public : la base de données ADN et le profil ADN du candidat à la présidence. Le résultat pourrait être “aucune correspondance“, “correspondance partielle” ou “correspondance complète“. Le public – du moins les cryptographes parmi eux – serait alors convaincu que le résultat est l’exécution correcte du code sur les données confidentielles. L’affirmation prouvée ici à l’aide d’une preuve ZK concerne l’intégrité des calculs sur des données confidentielles .

Les titres numériques anonymes, abordés dans un précédent article, permettent en revanche aux citoyens de prouver de manière sélective certaines caractéristiques les concernant, telles que leur majorité, leur nationalité ou la détention d’un permis de conduire valide. Les titres numériques anonymes recourent intensivement aux preuves ZK. Comme nous le verrons plus loin dans cet article, les ZKP peuvent également être utilisés pour la divulgation sélective de données à caractère personnel.

En résumé, les preuves ZK permettent à une partie, le prouveur, de prouver des affirmations à une autre partie, le vérificateur, sans intermédiaire de confiance. Ces affirmations peuvent donc porter sur des calculs sur des données confidentielles, mais aussi sur des caractéristiques (attributs) d’un citoyen (ou même d’un animal ou d’un objet).

Formellement, une preuve ZK doit répondre à trois critères :

1. Complétude (completeness). Si l’affirmation est vraie, un vérificateur en sera convaincu.
2. Robustesse (soundness). Si l’affirmation est fausse, le prouveur ne peut pas, dans la pratique, convaincre à tort le vérificateur du contraire.
3. Zéro-connaissance (zero-knowledge). Si l’affirmation est vraie, le vérificateur n’apprend rien de plus que cette affirmation.

Cet article aborde deux cas d’utilisation importants pour les ZKP : l’amélioration de l’évolutivité et de la confidentialité des applications blockchain d’une part, et la gestion de l’identité des citoyens dans le respect de la vie privée d’autre part.

Blockchain

De nombreux cas d’usage potentiels ont déjà été définis dans la littérature, même si, à ce jour, seul un nombre limité d’entre eux ont été mis en pratique. L’un des principaux domaines d’application est celui de la blockchain et des monnaies virtuelles (cryptomonnaies).

Les preuves ZK y sont utilisées pour améliorer la confidentialité des transactions. Dans le Bitcoin et quelques autres monnaies virtuelles, l’adresse (le numéro de compte) de l’expéditeur, l’adresse du destinataire et le montant transféré sont visibles par tous pour chaque transaction ; tout est publié sur la blockchain. Une situation loin d’être idéale sur le plan de la confidentialité…

La monnaie virtuelle Zcash permet aux utilisateurs de dissimuler ces trois éléments à l’aide de preuves ZK. Pour ce faire, elle recourt aux zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge), développés en 2012 et appliqués pour la première fois par Zcash. Le S dans zk-SNARKs signifie “succint“, soit “concis” en français. Les preuves ZK dans Zcash peuvent “être vérifiées en quelques millisecondes et ne font que quelques centaines d’octets”.

Outre la confidentialité, les preuves ZK sont également utilisées pour augmenter l’évolutivité des blockchains. La capacité limitée des blockchains a incité la communauté à rechercher activement des moyens d’améliorer l’évolutivité sans compromettre la sécurité ou la vitesse. Une meilleure évolutivité signifie qu’une transaction nécessite moins de ressources avec, à la clé, une baisse des coûts de transaction. L’une des approches les plus prometteuses est celle des zk-rollups, utilisés sur la blockchain Ethereum par Starknet, ZKsync et Polygon entre autres. Au lieu de placer chaque transaction séparément sur la blockchain, celles-ci sont regroupées hors chaîne, exécutées et seul le résultat, accompagné d’une preuve ZK de bonne exécution, est placé sur la blockchain. Cela permet de réduire le nombre d’octets écrits sur la blockchain, et la vérification de la preuve ZK est plus rapide que la vérification de toutes les transactions individuelles. Un espace de stockage et une puissance de calcul moindres sont donc requis.

Parallèlement, des preuves ZK sont en cours d’élaboration pour démontrer qu’un smart contrat (code) a été correctement exécuté. Là encore, la raison est l’évolutivité : chaque fois qu’une fonction d’un smart contract (code sur la blockchain) est appelée aujourd’hui, chaque nœud de la blockchain exécute exactement le même code. L’idée est qu’un seul nœud exécute le smart contract et prouve sa bonne exécution. Les autres nœuds vérifient la preuve. Si une preuve ZK est plus efficace que l’exécution du smart contract, on augmente l’évolutivité.

Gestion de l’identité

Les titres numériques anonymes – qui font appel aux preuves à divulgation nulle de connaissance (zero knowledge proof – ZKP) – permettent à un citoyen de divulguer de manière sélective des informations le concernant, par exemple sa majorité. Dans la réalité, malheureusement, aucun pays ou région n’a massivement adopté les titres numériques anonymes dans les documents d’identité. Aussi des recherches plus récentes se sont-elles penchées sur d’autres pistes, à savoir la génération d’une ZKP sur la base d’un document d’identité existant. Des travaux académiques récents se sont concentrés sur le passeport et le permis de conduire aux États-unis.

Durant l’été 2025, la VUB a publié une étude consacrée à la carte d’identité belge.
Cette étude s’inscrit dans le cadre du projet SDM financé par Innoviris. S’il s’agit d’un travail prometteur, il comporte toutefois divers défis. Un premier défi concerne la faible efficacité : il faut 22 secondes à un ordinateur portable pour générer une preuve, délai qui sera encore plus long sur un téléphone. La révocation représente un deuxième défi : lorsqu’une carte eID est perdue ou volée et que les certificats sur la carte sont révoqués en conséquence, il ne doit plus être possible de générer des ZKP.  

La VUB souhaite aller encore plus loin, à savoir utiliser les ZKP pour démontrer qu’un citoyen dispose de certains droits, sans divulguer d’autres données à caractère personnel. À l’avenir, un citoyen pourrait ainsi prouver qu’il remplit les conditions pour bénéficier d’un loyer modéré, sans avoir à donner de plus amples informations à ce sujet.

Itsme a récemment annoncé son Itsme Qualify, qui autorise une divulgation sélective de données à caractère personnel au moyen de ZKP. Actuellement, seule la vérification de l’âge est prise en charge, mais itsme prévoit d’étendre cette fonctionnalité. Malheureusement, votre auteur n’a pas pu trouver de détails accessibles au public sur cette fonctionnalité et n’est pas parvenu à obtenir plus d’informations auprès d’itsme. Il est à espérer que ce manque de transparence ne soit que temporaire, car les ZKP, comme toute autre cryptographie, sont plus sûrs lorsque tous les détails sont publics et peuvent être validés par des experts.

Enfin, sachez qu’il existe des solutions de gestion d’identité qui combinent la « blockchain » et les ZKP. Privado ID est l’une des initiatives les plus visibles qui était jusqu’à récemment connue sous le nom de Polygon ID. Un émetteur y confirme les attributs personnels d’un citoyen – par exemple la date de naissance – en plaçant une valeur de hachage spécialement formée à partir de l’ensemble des attributs sur un réseau blockchain comme Ethereum. Le citoyen peut alors s’en servir pour prouver de manière sélective à un tiers des informations à caractère personnel le concernant, telles que sa majorité. Notez que tous les ZKP qui utilisent la même valeur de hachage comme base peuvent être liés entre eux. 

Résistance quantique

Comme déjà expliqué en détail dans des articles précédents de Smals Research, il existe un risque que de puissants ordinateurs quantiques puissent à l’avenir briser la cryptographie moderne à clé publique.

Les technologies telles que zk-SNARK et Bulletproofs, qui permettent de prouver l’exactitude des calculs, ne sont pas résistantes aux ordinateurs quantiques. C’est notamment pour cette raison que les zk-STARKs (Zero-Knowledge Scalable Transparent Arguments of Knowledge) ont vu le jour en 2018. Comme l’illustre la figure ci-dessous, l’efficacité computationnelle reste élevée, mais les preuves sont beaucoup plus volumineuses. Néanmoins, elles sont déjà utilisées à des fins d’évolutivité et de confidentialité entre autres par StarkNet et StarkEx, qui sont tous deux des solutions d’évolutivité pour Ethereum.

Comparaison de trois solutions ZK pour prouver des calculs (source)

Des preuves ZK résistantes à l’informatique quantique pour les calculs sont donc possibles, même si les preuves deviennent beaucoup plus volumineuses. Leur adoption par la communauté blockchain reste pour l’instant limitée ; les zk-SNARKs demeurent la technologie ZK dominante dans le contexte de la blockchain. Le travail de la VUB sur la gestion d’identité utilise également aujourd’hui les zk-SNARKs.

Conclusion

Les preuves à divulgation nulle de connaissance existent depuis plusieurs décennies et ont déjà fait l’objet de nombreux développements et recherches. Dans cet article, nous avons identifié les deux principaux cas d’utilisation :

• Confidentialité et évolutivité sur les réseaux blockchain. La technologie ZKP permet de prouver qu’un calcul sur des données confidentielles a été effectué correctement. Ceci peut se faire relativement rapidement et contribue à accroître l’évolutivité des réseaux blockchain. Bien qu’elle puisse en théorie être appliquée en dehors de la blockchain, on n’y assiste pas (encore ?) dans la pratique. Travailler avec des parties centrales et la législation est aujourd’hui plus facile à mettre en œuvre et à expliquer.
• Gestion d’identité dans le respect de la vie privée. La technologie ZKP permet de divulguer de manière sélective des données à caractère personnel vous concernant. Cela peut se faire sur la base de documents d’identité classiques, tels que la carte d’identité électronique belge. De même, des documents d’identité peuvent être délivrés sous la forme de titres numériques anonymes. Les ZKP peuvent être très lourds sur le plan computationnel, surtout lorsque l’on utilise une technologie résistante à l’informatique quantique et que l’on part de documents d’identité officiels existants. 

L’utilisation de la technologie pour les ZKP et les titres numériques anonymes pour améliorer la confidentialité pose un certain nombre de défis. Nous avons déjà évoqué la performance, la résistance à l’informatique quantique et la révocation. Il faut également tenir compte de l’absence de normes, du risque que des informations contextuelles, telles qu’une adresse IP, compromettent la confidentialité, ainsi que de l’impact potentiel sur l’expérience utilisateur pour le citoyen, qui doit passer par une fenêtre supplémentaire.

C’est peut-être en partie pour cette raison que Gartner a déclaré en 2024 que la technologie ZKP était obsolète, ce qui a suscité une certaine indignation parmi les cryptographes. Malgré l’utilisation des preuves ZK dans Web3 (blockchain) et un nombre limité de configurations pour l’identité numérique, l’intérêt pour cette technologie stagne selon Gartner. Cela a été confirmé plus tôt cette année lorsque Sovrin a supprimé son réseau d’identité auto-souveraine (SSI – self-sovereign identity). L’avenir nous dira si Gartner a raison. Ce serait tragique, compte tenu de la puissance et de la polyvalence de cette technologie, sur laquelle les chercheurs travaillent depuis plusieurs décennies et qui devrait pourtant avoir un potentiel considérable dans le secteur public.

N’hésitez pas à nous contacter si vous êtes intéressé !

Nous avons probablement atteint le point culminant du battage médiatique autour de l’IA : d’un côté, l’IA suscite l’enthousiasme, de l’autre, elle commence déjà à créer la désillusion. On parle aussi de plus en plus d’une bulle sur le marché des grands acteurs technologiques. Mais quelle est réellement l’utilité des LLM à l’heure actuelle ? Pouvons-nous encore espérer de nombreuses améliorations ? Et qu’en est-il des hallucinations ?

Vous avez probablement déjà vécu cette situation : vous discutez avec ChatGPT ou un autre robot conversationnel « intelligent » et celui-ci produit sans détour une affirmation que vous savez fausse. Ou vous êtes développeur et votre assistant de codage fonctionne plutôt bien, jusqu’à ce que vous en demandiez plus, mais la nouvelle fonctionnalité ajoutée à votre programme est loin d’être à la hauteur. Et ce ne sont là que vos propres expériences, modestes. En effet, les expériences relatées par les autres ou celles relayées dans la presse ou sur les réseaux sociaux sont sans doute bien plus extrêmes : d’un côté, des cris de joie à l’idée que l’IA amorce une nouvelle révolution industrielle et des messages alarmistes selon lesquels elle entraînera des pertes d’emploi, de l’autre, des articles qui disent que les projets d’IA ne cessent d’échouer et des récits sur les hallucinations ridicules, voire dangereuses que ne cessent de produire les robots conversationnels basés sur l’IA. Que faut-il dès lors en penser ?

Pour une meilleure compréhension, un bref intermède, pas trop technique, sur ce que sont les LLM (je vous prie de m’excuser de rester volontairement vague à ce sujet : pour une meilleure explication, je vous recommande les articles de blog de mes collègues) : les modèles de langage d’IA prédisent ce que doit être le prochain morceau de texte, en se basant sur des probabilités. Ils ont été entraînés sur une telle quantité de texte que les phrases aléatoires qu’ils produisent sont de grande qualité et semblent parfaitement cohérentes (et le sont souvent). Ils ne réfléchissent donc pas comme un être humain : leur fonctionnement est très “basé sur le texte”. Il s’agit davantage de trouver et de répéter des modèles que de faire preuve d’une véritable compréhension ; l’intelligence qui s’en dégage est un phénomène émergent. Le nom le plus cocasse que j’ai entendu jusqu’à présent est “perroquet stochastique“.

Selon Gartner, nous avons déjà dépassé le pic des attentes déraisonnables et nous sommes désormais dans la phase de désillusion. D’autres journalistes parlent d’un effet de mode ou d’une bulle.
Des milliards sont investis dans de nouveaux centres de données pour alimenter la machine IA, parfois même avec de nouvelles centrales électriques, alors que la rentabilité est encore loin d’être atteinte. S’agit-il réellement d’une bulle ? Tout dépend de votre définition d’une bulle… En tout cas, cela ressemble à un pari énorme, parfois géostratégique, sur la prochaine technologie qui pourrait changer et améliorer radicalement le monde, voire le conquérir, voire le détruire… Tandis que j’écris ces lignes, certains n’hésitent pas à affirmer que la bulle est sur le point d’éclater, avec comme principaux arguments les investissements circulaires d’un certain nombre de grandes entreprises dans leurs capacités respectives et l’ouverture de ChatGPT au contenu érotique, une décision qui semble davantage refléter une pression sur les flux de trésorerie qu’une ouverture d’esprit.

Un autre problème réside dans le fait qu’actuellement, les investissements dans les LLM freinent également le développement d’un certain nombre d’autres technologies d’IA très utiles (mais lorsque la tempête se sera calmée, les centres de données pourraient bien s’avérer utiles pour ces dernières). Certains pensent d’ailleurs que pour obtenir une véritable intelligence, nous devrons développer une autre technologie d’IA (même si, au final, celle-ci utilisera toute la puissance de calcul que nous déployons actuellement ), et que les LLM atteignent peu à peu leurs limites, avec des améliorations incrémentielles de plus en plus faibles (et des résultats de tests gonflés). Malgré la leçon amère que davantage de données et de puissance de calcul ont permis les plus grands progrès, des voix s’élèvent maintenant pour dire qu’on ne pourra pas construire une Intelligence Artificielle Générale (AGI) avec les LLM ; il faudra se tourner vers de nouvelles recherches. Et entre-temps, on peut aussi démontrer que les hallucinations en font tout simplement partie et qu’elles ne disparaîtront probablement jamais complètement : les mauvaises herbes ne disparaissent jamais.

Mais dans un jardin envahi par les mauvaises herbes, de belles plantations sont tout de même possibles, moyennant quelques efforts. Et dans un tel jardin, les LLM ont bel et bien leur utilité : lorsqu’une tâche concerne principalement le texte et le langage, ils sont par exemple très performants (pensez au résumé, à la traduction, à la création, à la construction de raisonnements très simples…). Et même pour la programmation (qui est une sorte de manipulation d’un langage spécifique), nous constatons l’enthousiasme de nombreux développeurs qui ont vu leur productivité augmenter (mais la sécurité demeure un point d’attention !). En tant qu’assistant intelligent général, les LLM peuvent également jouer un rôle, à condition que l’utilisateur soit suffisamment informé sur un sujet et ait l’esprit critique. Et peut-être doivent-ils simplement continuer à évoluer pour devenir le meilleur outil pour une certaine niche de tâches.

J’ai moi-même une histoire nuancée à raconter : dans mon précédent article de blog, j’ai évoqué quelques petits succès avec le vibe coding, ainsi que les limites de l’IA lorsque les tâches deviennent plus importantes ou plus complexes. Je constate la même chose dans le travail que j’ai effectué depuis : l’analyse et la traduction de code hérité à l’aide de ces modèles de langage. Là aussi, le succès est mitigé : pas de baguette magique, difficile voire impossible à automatiser, mais tout de même un gain de temps visible dans la compréhension des codes de taille moyenne et la réécriture des petits morceaux de code de ce type de projets (plus de détails à ce sujet dans un prochain article de blog).

Conclusion

Un LLM n’est qu’une des nombreuses technologies « intelligentes » disponibles actuellement, même s’il s’agit de la plus accessible et la plus visible. C’est peut-être ce qui explique à la fois l’engouement et la controverse qu’elle suscite.

Les LLM sont-ils utiles ? J’oserais dire que oui. Cependant, compte tenu de l’état actuel de la technologie, il est fondamental de nuancer cette affirmation : mettez un LLM à la disposition d’un expert humain en tant qu’outil puissant ! La véritable valeur ne réside donc pas dans le remplacement, mais dans l’augmentation. Nous verrons si tous les systèmes basés sur des agents changeront la donne au cours de l’année à venir.

(NL) Neosemantics is een Java plug-in voor Neo4J, ontworpen om RDF-semantische tools toegankelijk te maken voor direct gebruik binnen Neo4J.

La politique de cryptographie en tant que code ou Crypto Policy as Code (CPaC) est un principe très récent qui permet de respecter automatiquement les recommandations en matière de cryptographie. Cet article vise à concrétiser nos idées concernant la CPaC. Une représentation des politiques cryptographiques en JSON est proposée et utilisée à titre de base pour quelques expériences. L’objectif est de rendre le potentiel de la CPaC plus tangible et plus compréhensible, et ainsi d’inspirer certains lecteurs.

« Everything as Code »

L’approche Everything as Code (tout en tant que code) vise à exprimer tous les composants d’un système informatique (infrastructure, réseau, sécurité, pipelines de déploiement…) sous forme de code. Elle autorise un haut degré d’automatisation des processus et de la gestion. Elle nous offre un meilleur aperçu et nous permet de mieux anticiper et d’intervenir en cas de besoin. Il en résulte également une cohérence et une évolutivité accrues grâce à une moindre intervention humaine. Il nous semble non seulement utile, mais aussi nécessaire à terme d’adopter cette approche dans le cadre de la gouvernance cryptographique. 

Lorsque Smals Research a débuté l’étude du CPaC début 2025, il n’existait pratiquement aucune information à ce sujet. Depuis, le CPaC semble également avoir attiré l’attention de plusieurs entreprises, notamment Garantir.

Un premier aspect de la CPaC est l’expression des actifs cryptographiques (algorithmes, clés, certificats, hardware, bibliothèques…) sous forme de code. Cela permet de gérer et d’interroger automatiquement l’inventaire des actifs cryptographiques d’une organisation. Un tel inventaire est systématiquement recommandé dans le contexte de l’état de préparation quantique et de l’agilité cryptographique.

Le modèle CBOM (Cryptography Bill of Materials ou nomenclature de cryptographie) permet d’exprimer les actifs cryptographiques d’une organisation en code JSON. Bien qu’il soit encore très récent, nous pensons qu’il sera largement adopté dans les années futures. Nous prévoyons qu’à l’avenir, les services cloud, les bibliothèques, les systèmes d’exploitation et le hardware, entre autres, seront fournis avec une description de la cryptographie appliquée et supportée, exprimée selon le modèle CBOM. Une organisation pourra ensuite importer ces descriptions dans son inventaire cryptographique.

Eu égard à cette perspective, nous intégrons autant que possible nos propositions de CPaC dans le modèle CBOM. L’illustration ci-dessous est le résultat d’une analyse statique du code et montre dans le code CBOM que RSA-2048 est utilisé à trois endroits dans une application.  

« Crypto Policy as Code »

Smals dispose d’une politique cryptographique qui indique quels algorithmes et paramètres cryptographiques sont recommandés, lesquels sont sûrs bien que non recommandés, lesquels doivent être progressivement supprimés et lesquels ne sont pas sûrs. Actuellement, ces recommandations sont exprimées de manière classique, que seuls les humains peuvent facilement comprendre. Nous nous sommes demandé comment exprimer ces recommandations sous forme de code.

Penchons-nous sur AES-128-GCM. AES est le chiffre de bloc ; il chiffre ou déchiffre des blocs de 128 bits. Le nombre 128 dans AES-128-GCM fait référence à la longueur en bits de la clé utilisée. Grâce au mode GCM, il est également possible de chiffrer et déchiffrer de plus grandes quantités de données.

Dans la partie gauche de l’illustration ci-dessous, la description de l’AES-128-GCM est présentée selon le modèle CBOM. On y trouve notamment des informations sur le niveau de sécurité classique et le niveau de sécurité quantique. Dans la partie droite de l’illustration se trouve notre proposition de formulation des recommandations sous forme de code. Nous maximisons ainsi la compatibilité avec CBOM ; la structure, la nomenclature et les clés d’identification sont conservées. Dans le même temps, nous évitons la duplication des données que nous trouvons déjà dans la description CBOM.

Les recommandations se trouvent dans le bloc recommendation. Il contient au minimum le niveau de recommandation recommended, secure, phase-out ou insecure. En outre, ce bloc peut contenir des informations supplémentaires facultatives, telles que :

• la date à laquelle le mécanisme cryptographique doit disparaître progressivement ;
• la date de la dernière révision de la recommandation ;
• les conditions d’utilisation correcte du mécanisme cryptographique ;
• les remarques, par exemple sur les raisons pour lesquelles le mécanisme cryptographique n’est plus considéré comme sûr.

À titre expérimental, l’équipe Smals Research a déjà exprimé certaines recommandations cryptographiques sous forme de code, notamment les fonctions de hachage cryptographiques, le chiffrement symétrique, les message authentication codes (MAC), les key derivation functions (KDF) et TLS. Ces recommandations cryptographiques sont relativement simples et compatibles avec CBOM. De plus, un schéma JSON a été défini afin de valider l’exactitude de la syntaxe et de la structure de nos recommandations.

Dérogations sous forme de code

Idéalement, chaque partie qui sollicite nos services, notamment les hôpitaux, les pharmaciens et les CPAS, doit mettre à jour son logiciel en temps utile afin qu’il prenne en charge la cryptographie la plus récente et la plus sûre. Dans la pratique cependant, cette opération n’est pas toujours exécutée aussi rapidement et une dérogation à la politique cryptographique doit être autorisée exceptionnellement afin de ne pas compromettre les services essentiels aux citoyens.

L’illustration ci-dessous montre un exemple fictif d’une telle dérogation (deviation), où la structure proposée par Smals Research est suivie. Elle se compose de quatre blocs :

• Scope. La dérogation peut s’appliquer à un service entier ou à certains modules spécifiques de celui-ci.
• Approval. Nous trouvons ici la référence à l’approbation par le management, ainsi que la justification et la durée de la dérogation. 
• Assessment. Il s’agit de l’évaluation du risque. Une dérogation ne peut être approuvée qu’après une estimation préalable du risque, telle que décrite dans cette section.
• Allow. Cette section énumère les algorithmes ou suites cryptographiques autorisés. La structure de ce bloc provient directement du modèle CBOM.

Scripts expérimentaux

L’équipe Smals Research a rédigé plusieurs scripts afin d’illustrer la puissance de la CPaC. Les recommandations sous forme de code, les dérogations sous forme de code et/ou les descriptions CBOM constituent l’input.

Script 1 : configuration TLS

TLS (Transport Layer Security) est un protocole populaire de communication sécurisée entre deux parties. Avant d’échanger des données, les parties conviennent de la suite cryptographique (combinaison d’algorithmes) qu’elles utiliseront à cette fin. OpenSSL est un client TLS populaire.

Notre premier script génère la configuration OpenSSL relative à la cryptographie sur la base de la politique en tant que code et, le cas échéant, d’une déviation en tant que code. Le code produit, dont vous trouverez un exemple ci-dessous, peut ensuite être intégré dans openssl.cnf, qui est le fichier de configuration openSSL. La dernière ligne de notre exemple contient la liste des suites cryptographiques ; la dernière provient d’une dérogation, les autres sont sécurisées selon la politique cryptographique. L’ordre est important ici ; la dérogation a la priorité la plus faible.

[default_conf]
ssl_conf = ssl_section

[ssl_section]
system_default = system_default_section

[system_default_section]
MinProtocol = TLSv1.3
CipherString = # Sets the ciphersuite list for TLSv1.2 and below to value. This list will be combined with any configured TLSv1.3 ciphersuites.
Ciphersuites = TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_CCM_8_SHA256

À terme, cela pourrait servir de base pour maintenir à jour de manière coordonnée la configuration cryptographique pour le TLS de milliers de machines. Bien évidemment, cela nécessite la mise en place des procédures pour éviter les erreurs.

Nous proposons que la politique et les déviations en tant que code soient gérées par un service central. La politique peut être accessible à l’ensemble de l’organisation, tandis que les déviations doivent être protégées par un contrôle d’accès strict.

Script 2 : génération d’un PDF

Pour la plupart des gens, un PDF bien structuré reste plus lisible qu’un fichier JSON. À partir de fichiers JSON, il n’est pas sorcier de générer de tels documents. C’est ce que réalisent nos deux scripts suivants.

Un PDF généré à titre expérimental contenant des recommandations de chiffrement symétrique peut être téléchargé ici. Il est parti du principe policy as code, mais il est fait également appel à CBOM pour enrichir le PDF ; les niveaux de sécurité classique et quantique en sont extraits.

Un deuxième fichier PDF généré à titre expérimental peut être téléchargé ici. Il contient des recommandations pour les suites cryptographiques TLS, complétées par des informations supplémentaires issues de la politique de cryptographie en tant que code. Un exemple de ce type d’informations est la date limite à laquelle une suite cryptographique peut être utilisée. Si un tel document était partagé avec les partenaires, cela leur permettrait d’anticiper en temps utile.

Script 3 : OPA policy verification

CPaC est un concept puissant. Les scripts précédents nous permettaient de générer des fichiers PDF et des configurations TLS. CPaC nous permet également de valider les artefacts existants, en vérifiant si un chiffrement sûr est utilisé.

OPA signifie Open Policy Agent. Il s’agit d’un moteur de politiques open source qui permet de séparer la logique applicative et les politiques. OPA permet aux organisations de centraliser leurs politiques et de les appliquer en temps réel. Différents services (Kubernetes, pipelines CI/CD, API gateways…) envoient des requêtes (queries) au format JSON au moteur de politiques afin de savoir si une action demandée par un client est autorisée. Sur la base d’une politique exprimée dans le langage Rego, le moteur de politiques indique au service si la requête doit recevoir une réponse positive ou négative. Par exemple, le moteur de politiques peut recevoir la requête d’une application demandant si une personne âgée de 15 ans est autorisée à utiliser l’application, alors que la politique stipule que l’âge minimum est de 18 ans. Le moteur de règles peut également être interrogé pour déterminer si une configuration réseau est conforme à la politique OPA. Par exemple, il peut exiger que les ports Telnet ne soient jamais ouverts.

Les services peuvent également poser des questions au moteur OPA concernant la cryptographie : la valeur donnée est-elle la valeur de hachage correcte (également appelée fingerprint ou digest) d’une charge utile donnée ? Une valeur est-elle le MAC correct pour une donnée d’entrée et une clé donnés ? Un certificat est-il signé par une autorité de confiance ? Un certificat utilise-t-il une courbe elliptique sécurisée ? …

Vous trouverez ci-dessous un exemple d’une telle requête et la politique correspondante. La politique stipule que la valeur de hachage de la charge utile est calculée à l’aide de la fonction de hachage (non sécurisée) MD5.

Input by service to policy engine
{
  "payload": {
    "user": "alice",
    "action": "read",
    "resource": "/api/users"
  },
  "expected_digest": "ea99819f665c10c744cbbf8da651c37a"
}

OPA Policy (in Rego) applied by the policy engine 
package crypto_digest_verification
payload_json := json.marshal(input.payload)
computed_digest := crypto.md5(payload_json)
digest_valid := computed_digest == input.expected_digest

Une organisation souhaitant mettre en place CPaC devra vérifier que ses politiques OPA existantes sont conformes à la dernière version de la politique cryptographique. Notre script final vérifie donc si la cryptographie utilisée dans la politique OPA est conforme à notre politique cryptographique centrale. En entrée est la crypto policy as code et une politique OPA. En sortie on obtient soit un message indiquant que la politique OPA est conforme, soit, comme dans le cas ci-dessus, un avertissement précisant également quel algorithme non sécurisé a été utilisé. À long terme, nous souhaitons également pouvoir déduire directement de notre CPaC les politiques OPA relatives à la cryptographie.

Conclusions

Cet article met en lumière le potentiel d’une approche everything as code pour stimuler la maturité cryptographique d’une organisation. À l’aide d’un certain nombre de scripts relativement simples, nous montrons comment une politique cryptographique centralisée, exprimée sous forme de code, peut soutenir une organisation dans divers domaines, de l’automatisation des processus à la création de documentation, en passant par la vérification de l’utilisation de la cryptographie appropriée, par exemple dans les politiques OPA.

À terme, nous souhaitons permettre l’accès aux informations sous forme de code via des API REST. Ainsi, les informations les plus récentes seront affichées clairement sur des tableaux de bord interactifs pour les utilisateurs autorisés. Les systèmes et applications pourront également accéder aux informations en temps réel via cette API REST. Idéalement, nous travaillerons avec une politique et un inventaire unifiés sous forme de code, la cryptographie n’étant qu’un aspect de ce système.

Dans un monde idéal, une politique de cryptographie en tant que code  pourrait être proposée par une organisation nationale ou européenne faisant autorité et pourrait être utilisée tant par le secteur public que par le secteur privé. Pour l’instant, cela reste une utopie. Au cours des prochaines années, nous pouvons nous attendre à une forte évolution dans ce domaine.

N’hésitez pas à nous contacter si vous souhaitez échanger vos idées avec nous à ce sujet !