Une évolution extrêmement rapide

Dès novembre 2024 [3], puis à nouveau en juillet  2025 [4] le système « Big Sleep » de Google a découvert deux vulnérabilité importantes dans le logiciel SQLite, pourtant très testé et utilisé. En début d’année 2026, la jeune pousse AISLE est allée plus loin : en utilisant des modèles d’IAGén avec sa propre infrastructure d’analyse, elle a trouvé 12 vulnérabilités « zero-day » – dont une faille critique [5], ainsi que des bogues remontant à des codes des années 1990 – dans  la librairie OpenSSL pourtant largement auditée [6]. AISLE a signalé aussi un grand nombre de vulnérabilités dans plus d’une dizaine de projets établis, notamment Apache, Chromium, Firefox, le noyau Linux, OpenVPN, et Samba. En mars 2025, l’outils « Security Copilot » de Microsoft a découvert des vulnérabilités dans GRUB2 et U-Boot (des chargeurs d’amorçage utilisés par la plupart des systèmes Linux). En août 2025, lors de la compétition « AI Cyber Challenge » organisée par l’agence étatsunienne pour les projets de recherche avancée de défense (DARPA), sept systèmes d’IA y ont travaillé de manière autonome sur 54 millions de lignes de code, ont trouvé la majorité des vulnérabilités synthétiques insérées, et ont révélé 18 bogues jusqu’alors inconnus [7], [8].

Ces démonstrations, certes impressionnantes, tiennes plus à l’infrastructure mise en place autour de l’IAGén (les intégrations d’outils, les connexions aux logiciels d’analyse statique existants, les boucles de planification itératives) qu’aux performances brutes des modèles [2] : ce qui est donc déterminant ici, est la conception du système, plutôt que la capacité du modèle en soi.

À la conférence « CyberSec Europe 2026 », en plus du mot « souveraineté » qui continuait d’être répété de puis la conférence précédente, le mot « Mythos » a fait son apparition après le coup de marketing magistral de la société Anthropic [9], [10], qui n’en est d’ailleurs pas à son premier [11]. En effet, en  7 avril 2026, dans son annonce de la mise à disposition de « Claude Mythos Preview » réservée à quelques entreprises triées sur le volet, la société Anthropic affirmait que Mythos avait identifié de manière autonome des milliers de vulnérabilités « zero-day » dans des infrastructures logicielles critiques, découvert un vieux bogue OpenBSD, et été capable d’enchaîner quatre vulnérabilités pour créer une exploitation de navigateur fonctionnelle. Les études indépendantes sont pour le moment quasiment inexistante et seul l’Institut britannique de sécurité de l’IA (AISI) – un organisme gouvernemental chargé d’évaluer les systèmes d’IA avant et après leur déploiement – a pu évaluer Mythos Preview et a confirmé qu’il pouvait, dans 3 cas sur 10, mener à bien une simulation d’attaque en plusieurs étapes sur un réseau d’entreprise – un scénario estimé à 20 heures de travail pour un professionnel humain qualifié [12], [13].

Mais ces découvertes ne sont pas uniques à Mythos. Les vulnérabilités découvertes par Mythos, ont pu aussi être trouvées par la société AISLE en utilisant des modèles moins couteux et de plus petite taille, dont les poids sont publics et pouvant être exécutés sur du matériel grand public [10], [14]. Indépendamment, l’AISI a constaté que le modèle GPT-5.5, était lui-aussi capable de mener à bien une simulation d’attaque sur un réseau d’entreprise [15]. Lors de son évaluation, l’AISI a également identifié une technique « universelle » pour contourner les restrictions de sécurité du modèle rappelant que des garde-fous imposant un  comportement au modèle [16] ne sont probablement pas aussi efficaces que des contraintes architecturales.

Suivre la cadence

Face à l’accélération de la découverte de nouvelle vulnérabilité, il devient impératif d’accélérer les pipelines de remédiation logicielle, notamment dans les  composant comportant des dépendances externe critiques [17]. L’exemple d’OpenSSL en janvier 2026, démontre que l’audit automatisé est désormais un outil à double usage accessible simultanément tant aux chercheurs qu’aux opérateurs criminels et aux acteurs étatiques [18].

Alors que le volume de CVE explose – avec une augmentation de 263 % entre 2020 et 2025 – il risque de saturer les capacité de correction traditionnelles dans la plupart des organisations [19], [20]. Dans son annonce Anthropic admettait que moins de 1 % des vulnérabilités trouvées par Mythos avaient été corrigées. Découvrir des vulnérabilités à grande échelle sans les corriger à la même échelle ne fait qu’allonger la liste des expositions, sans améliorer la sécurité. Dans ce contexte, seules les organisations ayant prépositionné une infrastructure de correction autonome et agile parviendront à réduire leurs fenêtre d’exposition, là où les méthodes manuelles ne peuvent plus suivre la cadence imposée par l’IA [20], [21].

Heureusement, même si les outils d’IA, malgré leurs « hallucinations » [22], offrent de nombreuses nouvelles possibilité à l’attaque, l’impression qui ressort de conférences comme CyberSec Europe 2026 ou Black Hat Europe 2025 est que la défense semble, pour le moment, conserver l’avantage [23], [24]. Le marché des outils de sécurité pour les entreprises murit rapidement et ces outils tentent de faciliter le travail des analystes. Par exemple, l’outil « Security Copilot » de Microsoft, couvre le triage des alertes, l’optimisation des politiques d’accès et les enquêtes sur la sécurité des données et permettrait de réduire de manière important le nombre d’alertes par incident et de résoudre plus rapidement des conflits de politiques de sécurité. Le triage automatisé des alertes issues de la gestion des événement et des informations de sécurité (SIEM) via des outils agentique d’orchestration, d’automatisation et de réponse pour la sécurité (SOAR) permettrait de réduire le temps d’effort par incident de manière significative [25]. Plus généralement, des études de recherche rapportent des réductions substantielles des faux positifs sur les alertes lorsque l’IAGén est utilisée comme couche de triage contextuel par-dessus les outils traditionnels d’analyse statique [26].

La détection et correction de vulnérabilité, c’est n’est pas le seul impact de l’IA sur la sécurité. L’automatisation des cyber-attaques par l’IA permet aux attaquants d’opérer avec une célérité sans précédent — jusqu’à 3 600 fois plus vite que les humains — tout en ciblant simultanément un volume bien plus important d’actifs [20]. Face à un « rythme opérationnel » où le délai médian d’exploitation après publication est tombé à seulement 5 jours [27], les modèles de réponse manuels ou linéaires sont désormais obsolètes et incapables de contenir ces incursions à haute fréquence [20]. Cette évolution impose une refonte des livrets de réponse aux incidents (« playbooks »).

Enfin, l’utilisation de l’IA à des fins (plus ou moins) productives apporte elle aussi son lot de problèmes de sécurité dans les entreprises. Il est important d’identifier précisément où l’IA opère au sein d’une infrastructure afin de garantir la sécurité des données. Le phénomène de l’« IA fantôme » (« shadow AI ») — défini comme l’utilisation d’outils d’IA sans l’approbation ou la supervision du service informatique – représente un risque important. Cette exposition inclut des modèles accessibles via des comptes personnels, des fonctionnalités IA intégrées dans des logiciels tiers en tant que service (SaaS) sans achat explicite, ou encore des modèles « open-source » utilisés par des programmeurs en dehors de tout processus de gouvernance [28]. Une organisation ne peut pas défendre un périmètre qu’elle n’a pas défini, et l’absence de visibilité actuelle crée des vulnérabilités critiques : environ 91 % des outils d’IA en entreprise fonctionneraient en dehors du contrôle de la direction du service informatique [29]. Or, sans un inventaire centralisé et une politique de surveillance continue, les entreprises s’exposent à des coûts de violation de données nettement plus élevés [30].

Conclusion

Très rapidement les outils de sécurité par IA sont passés de la phase de démonstration de recherche à la pertinence opérationnelle, des deux côtés de la barrière : tandis que les capacités offensives de l’IA ont abaissé la barre pour les acteurs criminels de niveau intermédiaire et permis des campagnes d’intrusion plus évolutives, les applications défensives – triage des alertes, découverte de vulnérabilités, filtrage des faux positifs, tests d’intrusion autonomes – intègrent des fonctionnalités d’IA et apportent des améliorations par rapport aux générations précédentes. La mise en œuvre de flux de travail défensifs augmentés par l’IA marque une transition importante dans l’ingénierie de sécurité.

Le défi n’est plus la détection, mais la correction.

Références

[1]          F. A. P. Petitcolas, « L’IA pour améliorer la sécurité du code ? (Partie 1 : sécurité du code généré) », Smals Research, 30 juill. 2025. Disponible sur: https://staging.smalsresearch.be/ia-pour-ameliorer-securite-du-code-1/

[2]          F. A. P. Petitcolas, « L’IA pour améliorer la sécurité du code ? (Partie 2 : détection de vulnérabilités) », Smals Research, 26 août 2025. Disponible sur: https://staging.smalsresearch.be/ia-pour-ameliorer-securite-du-code-2/

[3]          R. Lakshmanan, « Google’s AI Tool Big Sleep Finds Zero-Day Vulnerability in SQLite Database Engine », The Hacker News, 11 nov. 2024. Disponible sur: https://thehackernews.com/2024/11/googles-ai-tool-big-sleep-finds-zero.html

[4]          « NVD – CVE-2025-6965 », NIST – National Institute of Standards and Technology, juill. 2025. Disponible sur: https://nvd.nist.gov/vuln/detail/CVE-2025-6965

[5]          « NVD – CVE-2025-15467 », CVE-2025-15467, janv. 2026. Disponible sur: https://nvd.nist.gov/vuln/detail/CVE-2025-15467

[6]          A. Muanza, « Douze failles de sécurité découvertes dans OpenSSL par une analyse basée sur l’IA », 29 jan. 2026. Disponible sur: https://www.ictjournal.ch/news/2026-01-29/douze-failles-de-securite-decouvertes-dans-openssl-par-une-analyse-basee-sur-lia

[7]          D. DiMolfetta, « DARPA unveils winners of AI challenge to boost critical infrastructure cybersecurity », Nextgov.com, 8 août 2025. Disponible sur: https://www.nextgov.com/cybersecurity/2025/08/darpa-unveils-winners-ai-challenge-boost-critical-infrastructure-cybersecurity/407337/

[8]          J. Greig, « DARPA announces $4 million winner of AI code review competition at DEF CON », The Record, 9 août 2025. Disponible sur: https://therecord.media/darpa-ai-code-competition-winner-def-con

[9]          B. Vigliarolo, « Anthropic’s bug-hunting Mythos was greatest marketing stunt ever, says cURL creator », The Register, 11 mai 2026. Disponible sur: https://www.theregister.com/security/2026/05/11/anthropics-bug-hunting-mythos-was-greatest-marketing-stunt-ever-says-curl-creator/5238111

[10]       B. Schneier, « Claude Mythos is mostly “marketing hype” », Schneier on Security, 26 avr. 2026. Disponible sur: https://www.schneier.com/news/archives/2026/04/claude-mythos-is-mostly-marketing-hype.html

[11]       F. Tréguer, « La bonne conscience de la Silicon Valley », Le Monde diplomatique, 1 mai 2026. Disponible sur: https://www.monde-diplomatique.fr/2026/05/TREGUER/69543

[12]       « Our evaluation of Claude Mythos Preview’s cyber capabilities | AISI Work », AI Securty Institute (AISI), avr. 2026. Disponible sur: https://www.aisi.gov.uk/blog/our-evaluation-of-claude-mythos-previews-cyber-capabilities

[13]       L. Folkerts et al., « Measuring AI agents’ progress on multi-step cyber-attack scenarios », 17 mars 2026, arXiv: arXiv:2603.11214. doi: 10.48550/arXiv.2603.11214.

[14]       « Smaller and cheaper models also managed to discover the same security bugs as Claude Mythos, says AISLE analysis », OfficeChai, 9 avr. 2026. Disponible sur: https://officechai.com/ai/smaller-and-cheaper-models-also-managed-to-discover-the-same-security-bugs-as-claude-mythos-says-aisle-analysis/

[15]       « Our evaluation of OpenAI’s GPT-5.5 cyber capabilities », AI Security Institute, 30 avr 2026. Disponible sur: https://www.aisi.gov.uk/blog/our-evaluation-of-openais-gpt-5-5-cyber-capabilities

[16]       B. Vanhalst, « Garde-fous : délimitez votre IA », Smals Research, 27 nov. 2025. Disponible sur: https://staging.smalsresearch.be/garde-fous-delimitez-votre-ai/

[17]       « 4th annual software supply chain security report 2026 – How sophisticated malware, AI, and broken trust are reshaping software security », Reversing Labs, 2026.

[18]       B. Schneier, « AI found twelve new vulnerabilities in OpenSSL », Schneier on Security, 18 fév. 2026. Disponible sur: https://www.schneier.com/blog/archives/2026/02/ai-found-twelve-new-vulnerabilities-in-openssl.html

[19]       « NIST updates NVD operations to address record CVE Growth », NIST, 15 avr. 2026. Disponible sur: https://www.nist.gov/news-events/news/2026/04/nist-updates-nvd-operations-address-record-cve-growth

[20]       « The NVD infrastructure crisis: AI discovery overwhelms tracking », CSAI Foundation | Cloud Security Alliance, mai 2026. Disponible sur: https://labs.cloudsecurityalliance.org/wp-content/uploads/2026/05/CSA_whitepaper_NVD_infrastructure_crisis_AI_vulnerability_discovery_20260504-csa-styled.pdf

[21]       « Reddit taps Fleet’s autonomous patching to slash vulnerability exposure », MarketChameleon.com. Consulté le: 27 mai 2026. Disponible sur: https://marketchameleon.com/articles/b/2026/5/15/reddit-autonomous-patch-fleet-ai-cybersecurity

[22]       « Disrupting the first reported AI-orchestrated cyber espionage campaign », Anthropic, nov. 2025. Disponible sur: https://www-cdn.anthropic.com/d7dd50dd1185f59be051b307150d877f2b82bd2c.pdf

[23]       D. O’Brien et P. Miller, « Black Hat Europe 2025: Inside the defender’s AI advantage », Security.com, 15 jan. 2026. Disponible sur: https://www.security.com/expert-perspectives/inside-defenders-ai-advantage

[24]       Discussions privées à CyberSec Europe 2026, mai 2026.

[25]       TrendAI, « Experience the AI security revolution », 22 mai 2026.

[26]       X. Du et al., « Reducing False Positives in Static Bug Detection with LLMs: An Empirical Study in Industry », 26 janvier 2026, arXiv: arXiv:2601.18844. doi: 10.48550/arXiv.2601.18844.

[27]       Rapid7, « Rapid7 2026 global threat landscape rReport shows exploited high and critical-severity vulnerabilities surged 105% as attack timelines collapsed », Rapid7, 18 mars 2026. Disponible sur: https://www.rapid7.com/about/press-releases/rapid7-2026-global-threat-landscape-report-shows-exploited-high-and-critical-severity-vulnerabilities-surged-105-as-attack-timelines-collapsed/

[28]       J. Kisielius, « Shadow AI in IBM’s 2025 cost of a data breach report », 8 oct. 2025. Disponible sur: https://www.nudgesecurity.com/post/shadow-ai-the-emerging-security-threat-in-ibms-2025-cost-of-a-data-breach-report

[29]       « The invisible enterprise: shadow AI and the ungoverned frontier », Lab Space, 2 avr. 2026. Disponible sur: https://labs.cloudsecurityalliance.org/research/csa-whitepaper-shadow-ai-asset-blindness-systemic-risk-20260/

[30]       L. Kornutick, S. Agarwal, A. Litan, S. Sicular, P. Sundararaman, et S. Palit, « Market guide for AI governance platforms », Gartner, G00837249, nov. 2025. Disponible sur: https://www.gartner.com/document-reader/document/7145930

(Nederlandstalige tekst : zie onder)

Webinar Smals, WebEx

Koen Vanderkimpen
Smals Research

04/06/2026  10h30 – 11h45

Language: Dutch / Slides in English

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

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

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

Définitions

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

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

On distingue deux courants de jumeaux numériques :

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

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

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

Projets phares

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

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

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

Use Cases administratifs

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Conclusion

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

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

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

(NL) Maak kennis met het dark web!
Het dark web roept vaak beelden op van illegaliteit, maar wat schuilt er werkelijk achter de anonimiteit? Roald Santens (Smals Academy) en Vandy Berten (Smals Research) nemen je mee op een verkenningstocht door de krochten van het internet. Je leert hoe de techniek achter anonieme netwerken werkt, wat de gevaren zijn voor organisaties, en waarom het dark web ook waardevolle kansen biedt. Kijk en luister hier waarom (Frans gesproken, NL ondertitels zijn beschikbaar).

(FR) À la découverte du dark web !
Le dark web évoque souvent des images d’illégalité, mais que se cache-t-il réellement derrière cet anonymat ? Roald Santens (Smals Academy) et Vandy Berten (Smals Research) vous emmènent explorer les profondeurs de l’internet. Vous découvrirez le fonctionnement technique des réseaux anonymes, les dangers pour les organisations, ainsi que les opportunités précieuses que le dark web peut offrir. Regardez et écoutez ici pour découvrir pourquoi.

(EN) Discover the Dark Web!
The dark web often evokes images of illegal activity, but what truly lies behind that anonymity? Roald Santens (Smals Academy) and Vandy Berten (Smals Research) take you on an exploration through the depths of the internet. You will learn how the technology behind anonymous networks works, the risks organizations face, and why the dark web also offers valuable opportunities. Watch and listen here to find out (French speaking, EN subtitles available).

La détection d’anomalies (aussi souvent appelées « outliers », ou encore « valeurs aberrantes ») est un problème récurrent en data science/machine learning. Cette détection est bien souvent considérée comme une simple tâche préliminaire, mais peut parfaitement être la finalité de l’application :

• En tant que tâche préliminaire, la détection a lieu durant l’analyse exploratoire, afin de limiter les soucis de « garbage in, garbage out ». L’objectif est donc ici de corriger ou d’enlever ces anomalies pour éviter qu’elles ne soient utilisées durant la phase d’entrainement du modèle prédictif, car cela risquerait d’affecter négativement ses performances.
• En tant que tâche principale, la détection d’observations présentant des profils anormaux peut par exemple servir à détecter des activités frauduleuses, des erreurs, ou encore des intrusions (IDS: Intrusion Detection System) [1].

La détection d’anomalies est donc une tâche très importante qui trouve un grand nombre d’applications dans de nombreux domaines [1], visant à trouver des observations qui ne se conforment pas au reste des données [2].

Cet article de blog s’intéresse au problème de la détection d’anomalies dans des données, et a pour objectif de présenter les solutions basées sur une approche machine learning.

Les différents types d’anomalies

Avant de discuter des outils permettant la détection d’anomalies, commençons dans un premier temps par définir les différents types d’anomalies qui peuvent être détectés. Dans la littérature, on considère souvent qu’il y a 3 types d’anomalies [3] :

• L’anomalie ponctuelle

Il s’agit de la forme la plus simple d’anomalies : une instance individuelle considérée comme anormale vis-à-vis du reste des données.

Ces anomalies sont encore parfois divisées en 2 sous-catégories, les anomalies globales (significativement différentes du reste des données) et les anomalies locales (différentes du voisinage local). Exemple illustratif :

Figure 1 : Exemple d’anomalies locale et globale (image extraite de [4])

Dans la Figure 1, on peut voir deux anomalies : o₁, une anomalie globale fortement différente des autres observations, et o₂, une anomalie locale par rapport à son voisinage (le groupe C₂).

• L’anomalie contextuelle

Une anomalie est dite « contextuelle » si, dans un contexte différent, elle peut être considérée comme normale. Par exemple, si l’on s’intéresse aux précipitations : un certain niveau de précipitations, qui est anormal à un endroit donné, pourrait parfaitement être considéré comme normal à un autre endroit. On a donc ici deux types d’attributs : des attributs contextuels qui définissent le contexte (souvent des attributs temporels ou spatiaux) et des attributs comportementaux dans lesquelles on va chercher les anomalies (dans notre exemple : les précipitations).

• L’anomalie collective/anomalie de groupe

Dans cette dernière catégorie, il ne s’agit plus d’une anomalie individuelle mais d’un ensemble d’anomalies, formant un groupe dont les caractéristiques sont inhabituelles.

Les méthodes de détection

Souvent (et particulièrement lorsqu’il s’agit d’une simple tâche préliminaire de data cleansing), la détection d’anomalies dans les données se fait simplement via des outils statistiques (par exemple, en utilisant les écarts-types, les quantiles, ou via des tests statistiques). Dans le cadre de cet article, nous n’allons pas explorer ces approches statistiques et nous concentrer sur les approches machine learning de la détection d’anomalies.

Quel type d’apprentissage ?

Il existe principalement deux approches pour détecter des anomalies, les méthodes basées sur l’apprentissage supervisé et celles basées sur l’apprentissage non-supervisé. Pour rappel, l’apprentissage supervisé utilise des données labélisées : cela nécessite d’avoir, en plus des données, des exemples d’anomalies préalablement identifiées afin que le modèle de détection puisse apprendre à les différencier des données normales. A l’inverse, l’apprentissage non-supervisé se base entièrement sur les données et ne requiert pas de disposer d’un ensemble d’anomalies pré-identifiées.

Dans le cadre de cet article, nous allons explorer les approches non-supervisées. Ces dernières ont en effet une spécificité intéressante par rapport aux modèles supervisés (outre le fait de ne pas nécessiter de données labélisées) : la découverte de nouvelles formes d’anomalies.

En effet, un modèle supervisé aura tendance à identifier des anomalies présentant des caractéristiques similaires à celles des anomalies labélisées. Par conséquent, même dans les cas où des données labélisées existent, il sera souvent intéressant de coupler un modèle supervisé, entrainé pour détecter plus finement certains profils prédéfinis d’anomalies, avec un modèle non-supervisé, qui pourra potentiellement trouver des anomalies présentant des profils complètement différents.

Quelques algorithmes classiques de détection d’anomalies

Avant de commencer, nous allons séparer les algorithmes de détection d’anomalies en 2 catégories : les détecteurs et les modèles de détection. Un modèle de détection va, comme son nom l’indique, construire un modèle qui peut être utilisé de façon isolée : par exemple si l’on dispose d’une nouvelle observation, on peut simplement l’entrer dans le modèle pour estimer s’il s’agit d’une anomalie. A l’inverse, un détecteur n’aura pas de modèle entrainé pouvant être utilisé par la suite : si une nouvelle observation arrive, il faudra la recontextualiser en la plaçant parmi les autres données, voire éventuellement entièrement relancer le processus de détection d’anomalies.

Les détecteurs sans modèles

Une première approche intuitive pour identifier si une observation est une anomalie ou non se base sur l’idée qu’une anomalie a tendance à être éloignée de ses voisins. Ainsi, en mesurant la distance moyenne (distance euclidienne par exemple) entre une observation et ses k plus proches voisins (k-NN), ou simplement la distance entre une observation et son k^ième plus proche voisin (kth-NN) [5], on peut estimer le risque qu’une observation soit une anomalie : si l’observation est loin des autres, on peut supposer qu’il s’agit d’une anomalie.

Cette approche basée sur la distance a l’avantage d’être intuitive, facile à implémenter et à interpréter, mais elle est rapidement limitée. Si on reprend l’exemple de la Figure 1, on observe toutes les observations du cluster C1 sont plus éloignées les unes des autres que o₂ ne l’est des observations de C2. Résultat : un algorithme basé sur la distance retrouvera facilement l’anomalie o₁, mais pas o₂. Une approche alternative très connue, le Local Outlier Factor (LOF) [4] se base sur la densité plutôt que sur la distance. Cela permet de gérer les cas où les données contiennent des clusters (C1 et C2 dans la Figure 1) qui n’ont pas la même densité.

L’idée est la suivante : observer si la densité autour d’une observation est cohérente avec la densité de ses k plus proches voisins. Ainsi, si l’on prend une observation faisant partie du groupe C1, la densité autour de cette observation est cohérente par rapport à la densité autour de ses voisins proches, là où, pour l’observation o₂, la densité autour de o₂ est différente de la densité autour de ses plus proches voisines au sein de C2. L’algorithme LOF consiste donc à détecter des anomalies en regardant si leur densité est cohérente avec la densité de leur environnement local.

Un dernier type de détecteur que nous allons voir se base sur le partitionnement de données (clustering). L’objectif bien connu du clustering va être de détecter des groupes d’observations ayant des caractéristiques similaires. Cela permet notamment de :

• Chercher une observation se trouvant loin du centroïde de son cluster, ou se trouvant dans un micro-cluster qui ne contient qu’une observation (anomalie ponctuelle).
• Chercher des clusters anormaux (anomalies collectives).

Par exemple, Jiang et al. [6] proposent de partitionner les données, puis de calculer « l’outlier factor » de chaque cluster (basé sur la distance entre ce cluster et les autres), afin de trouver des clusters d’anomalies. De leur côté, He et al. [7] proposent l’algorithme FindCBLOF (CBLOF : cluster-based local outlier factor) qui partitionne les données, puis cherche les anomalies en utilisant à la fois la taille des clusters (les clusters trop petits pouvant représenter des anomalies collectives) et les distances entre les observations et les centroïdes des clusters.

Les modèles de détection

Maintenant que nous avons vu des approches sans modèle, nous allons encore rapidement passer à des approches basées sur des modèles de détection d’anomalies. Cette section sera relativement courte et ne présentera que deux modèles parmi les plus connus : « l’isolation forest » et le « one-class SVM ».

L’isolation forest [8] se base sur le principe qu’une anomalie, puisqu’elle présente des caractéristiques inhabituelles, devrait être plus facile à isoler qu’une observation normale.

L’idée est simple : on va piocher au hasard une variable et une valeur (par exemple : âge (variable) et 21.3 (valeur)), et les utiliser pour séparer les données en deux sous-groupes (branches). Chacun de ces groupes sera ensuite lui-même divisé de façon aléatoire en sous-groupes, qui seront à leur tour divisés, et ainsi de suite de manière récursive, formant un arbre de décision (decision tree), construit de manière aléatoire, que l’on appelle un isolation tree.

Figure 2 : Exemple illustratif d’isolation tree

Durant le développement de l’arbre, aussitôt qu’un groupe ne contient plus qu’une seule observation, ce groupe n’est plus divisé en sous-groupes. Une Isolation Forest est donc composée d’un grand nombre de ces arbres aléatoires, avec l’idée qu’une observation normale devrait être plus difficile à isoler (et donc, demander en moyenne plus de divisions aléatoires de l’espace) qu’une anomalie (voir Figure 3).

Figure 3 : Exemple d’isolation d’une observation normale (x_i) et anormale (x_j) (image extraite de [9])

Pour identifier si une observation est une potentielle anomalie, il suffit simplement de regarder à quelle profondeur elle se trouve isolée dans les différents arbres. Les anomalies devraient en moyenne se retrouver isolées peu profondément dans les arbres, car elles sont plus faciles à isoler.

Le one-class SVM (OCSVM) [10] est le second modèle de détection auquel nous allons nous intéresser dans cet article. Notez que l’algorithme sous-jacent à l’OCSVM est nettement moins intuitif et facile à expliquer que l’isolation forest, nous n’allons donc pas nous attarder sur son fonctionnement. Cependant, nous allons tout de même le présenter rapidement, car il s’agit d’un modèle classique bien connu en détection d’anomalies.

L’OCSVM essaie de trouver la région où les données sont densément situées, et de considérer les points en dehors de cette région comme anormaux. L’objectif pour l’OCSVM est d’apprendre la forme de la « normalité », afin de déterminer une frontière qui séparerait les observations normales des anomalies. La spécificité de l’algorithme OCSVM est que, plutôt que d’utiliser directement les caractéristiques (features) des observations pour déterminer la frontière entre observations normales et anormales, il va projeter les observations dans un espace transformé, permettant de dessiner des frontières complexes entre données normales et anormales.

Exemple illustratif

Pour illustrer la détection d’anomalies, nous avons généré des données artificielles en 2 dimensions, contenant :

• Des données « normales » : générées suivant une distribution normale.
• Des anomalies : générées au hasard suivant une distribution uniforme.

Les données normales et les anomalies ont été mélangées et nous avons appliqué 3 algorithmes de détection d’anomalies dessus (OCSVM, Isolation Forest et LOF). Les résultats sont visibles dans les Figures 4 – 6 :

• Figure 4 : Un seul groupe d’observations normales ;
• Figure 5 : Deux groupes d’observations normales légèrement séparés ;
• Figure 6 : Deux groupes d’observations normales bien séparés.

Pour chacune de ces figures, les observations normales sont affichées en blanc et les anomalies en noir, afin de pouvoir facilement les distinguer visuellement. Ces labels (normal vs. anomalie) n’ont évidemment pas été fournis aux algorithmes, qui tournent de façon non-supervisés.

Pour chacun de ces 3 algorithmes, nous avons mis en évidence en rouge la frontière utilisée par l’algorithme pour différencier les données normales des anomalies. Les observations dans la zone orange (à l’intérieur de la frontière) sont considérées par l’algorithme comme normales, et les observations dans la zone bleue sont considérées comme des anomalies (bleu clair : légèrement anormal ; bleu foncé : fortement anormal).

Figure 4 : Détection d’anomalies avec un groupe de données normales

Figure 5 : Détection d’anomalies avec deux groupes légèrement séparés de données normales

Figure 6 : Détection d’anomalies avec deux groupes fortement séparés de données normales

Evaluer la détection

Réussir à quantifier la qualité de la détection d’anomalies n’est pas une tâche aisée. Commençons par le cas le plus facile : si nous disposons d’anomalies pré-identifiées (labels). Dans ces cas, un algorithme de détection d’anomalies pourra être validé en vérifiant si celui-ci parvient à retrouver les anomalies déjà connues, en utilisant des mesures classiques (recall, precision, F1-measure, etc.)

En l’absence de label, c’est là que ça se complique. Dans ce cas, il faudra vérifier manuellement les observations identifiées par l’algorithme, afin de confirmer si celles-ci sont effectivement anormales. Cela demande non seulement d’avoir des bonnes connaissances du domaine d’où sont issues les données, mais aussi de comprendre pourquoi l’observation a été identifiée par l’algorithme comme anomalie. En effet, puisqu’il y a souvent un grand nombre de variables dans les données, et que la frontière (entre données normales et anormales) utilisée par l’algorithme est généralement complexe, il est parfois difficile de comprendre pourquoi certaines observations ont été identifiées comme des anomalies par un algorithme. Il peut alors être utile d’utiliser des outils d’explicabilité (par exemple : SHAP, LIME) pour comprendre les décisions de l’algorithme.

Conclusion

Nous avons choisi, dans cet article de blog, de présenter une sélection d’algorithmes (non-supervisés) basés sur des approches variées (distance, densité, isolation, etc.), afin d’illustrer la grande diversité d’algorithmes qui existent. Cependant, rappelons que nous n’avons pas exploré les méthodes supervisées (souvent plus précises car spécialisées dans la détection de patterns prédéfinis) et les approches statistiques. La détection d’anomalies est donc un domaine vaste offrant de nombreux outils. Les algorithmes non-supervisés offrent une grande flexibilité, car ils ne requièrent pas de labels et peuvent détecter des nouvelles formes d’anomalies. Dans la pratique, puisque chaque algorithme de détection est différent, il est parfois utile de combiner plusieurs algorithmes de détection d’anomalies afin d’avoir une plus grande variété dans les formes d’anomalies détectées.

[1] : Chandola, V., Banerjee, A., & Kumar, V. (2009). Anomaly detection: A survey. ACM computing surveys (CSUR), 41(3), 1-58.

[2] : Samariya, D., & Thakkar, A. (2023). A comprehensive survey of anomaly detection algorithms. Annals of Data Science, 10(3), 829-850.

[3] : Nassif, A. B., Talib, M. A., Nasir, Q., & Dakalbab, F. M. (2021). Machine learning for anomaly detection: A systematic review. Ieee Access, 9, 78658-78700.

[4]: Breunig, M. M., Kriegel, H. P., Ng, R. T., & Sander, J. (2000). LOF: identifying density-based local outliers. In Proceedings of the 2000 ACM SIGMOD international conference on Management of data (pp. 93-104).

[5] : Ramaswamy, S., Rastogi, R., & Shim, K. (2000). Efficient algorithms for mining outliers from large data sets. In Proceedings of the 2000 ACM SIGMOD international conference on Management of data (pp. 427-438).

[6] : Jiang, S. Y., & An, Q. B. (2008). Clustering-based outlier detection method. In 2008 Fifth international conference on fuzzy systems and knowledge discovery (Vol. 2, pp. 429-433). IEEE.

[7] : He, Z., Xu, X., & Deng, S. (2003). Discovering cluster-based local outliers. Pattern recognition letters, 24(9-10), 1641-1650.

[8] : Liu, F. T., Ting, K. M., & Zhou, Z. H. (2008). Isolation forest. In 2008 eighth ieee international conference on data mining (pp. 413-422). IEEE.

[9] : Isolation forest – Wikipedia

[10] : Schölkopf, B., Platt, J. C., Shawe-Taylor, J., Smola, A. J., & Williamson, R. C. (2001). Estimating the support of a high-dimensional distribution. Neural computation, 13(7), 1443-1471.

L’avènement récent de l’intelligence artificielle générative (GenAI) a bouleversé de nombreux secteurs, y compris directement en informatique (assistants de codage, tests automatiques, traduction de langages de programmation…). Le domaine de l’analyse de données, ou data science, n’y fait pas exception. On dit souvent que 80 % du temps d’un data scientist est consacré à la préparation des données (ingestion, transformation, nettoyage, enrichissement…), qui est souvent laborieuse et répétitive, et que seulement 20 % fait appel à ses compétences les plus pointues. Peut-on utiliser le GenAI pour accélérer ces 80 % ? Nous allons voir dans cet article préliminaire que la réponse est largement positive, mais qu’en plus les 20 % restants sont également fameusement entamés. Nous verrons dans quelle mesure un outil comme ChatGPT peut aider à analyser des données : comprendre ce qu’elles contiennent, en extraire des indicateurs statistiques, identifier des anomalies, expliquer des phénomènes particuliers…

Pour illustrer ces propos, nous allons nous baser sur le jeu de données “urgences data”, disponible sur Kaggle. Il s’agit d’un fichier CSV de ~430 MB, comprenant 336 253 lignes et 39 colonnes, sans aucune métadonnée associée. Chaque ligne correspond à la visite d’un patient dans le service d’urgences d’un hôpital (non identifié) du nord de la France, entre le 6 janvier 2016 et le 6 décembre 2020. On y trouve une multitude d’informations : date et heure d’arrivée et de sortie, moyen d’arrivée, motif, âge, un certain nombre de paramètres médicaux, tels que fréquence cardiaque, tension, température, saturation, ainsi que des booléens semblant indiquer si des examens complémentaires ont été prescrits (biologie, radio, échographie, scanner, IRM…)

Nous allons utiliser “Data Analyst”, un des “GPTs” proposé dans ChatGPT. La version gratuite étant limitée à un très petit nombre de questions, nous avons utilisé une version payante (“Personal Plus”). Nous avons interagi en anglais pour cet exercice, mais des résultats semblables auraient probablement été obtenus en français ou en néerlandais.

Analyse préliminaire

Une première étape peut consister à simplement soumettre le fichier à analyser à “Data Analyst”, et lui demander de dire ce qu’il peut y trouver. Plus formellement, une question telle que “What useful insight can you extract from those data?” nous fournit le résultat ci-dessous.

Nous obtenons un résultat qui va suivre une structure que l’on retrouvera dans presque toutes les réponses :

1. Une série de graphiques. Ici, une distribution de l’âge des patients, la répartition moyenne suivant l’heure de la journée, ainsi que la répartition de l’orientation (retour domicile, transfert interne…). Notons que sans qu’on n’ait rien eu à dire, ChatGPT a compris qu’il s’agissait de patients d’un service d’urgences ;
2. Une analyse textuelle structurée de ce qu’il a pu comprendre des données. La démographie des patients, quelles sont les heures de pointe, où vont les patients à la sortie et comment sont-ils arrivés ;
3. Des propositions stratégiques ;
4. Des propositions d’étapes suivantes. “If you’d like, I can next:“, suivi d’une série de prompts pertinents pour continuer l’analyse (qu’il faut malheureusement copier-coller).

Par ailleurs, le texte termine toujours par un lien “</>”, que l’on ne retrouve pas dans un chat ChatGPT “de base” et sur lequel on peut cliquer pour obtenir le code Python sur lequel est basé cette analyse. Celui-ci, réalisé en utilisant la bibliothèque “Pandas” de Python (un des outils open source le plus répandu d’analyse de données/data science), permet de générer les graphiques proposés, ainsi que tous les chiffres utilisés dans les descriptions. Il est donc tout à fait possible non seulement d’utiliser ce code directement, mais aussi de s’assurer que les chiffres ne sont pas totalement inventés sur la base de modèles statistiques généraux et bien calculés à partir des données fournies.

On a donc pu, en une seule phrase et à peine une minute d’attente, obtenir trois graphiques, du code Python et un texte descriptif qu’un data scientist aurait typiquement mis plusieurs heures à obtenir. Il s’agit, bien sûr, d’une première approche très sommaire. Mais on peut aller plus loin.

On peut par exemple demande de fournir une description statistique pour chaque colonne. On obtient ici en résultat une longue description très structurée, par type de variable (numérique ou catégorique) avec une série d’indicateurs : moyenne, minimum/maximum, nombre de valeurs manquantes… ainsi qu’un commentaire (“Not usable for analysis“, “Vital signs moderately complete“, “Excellent for resource utilization analysis“, “Likely categorical indicator”…). L’outil nous propose également quelques observations liées à la qualité des données (Exemple : “Outliers: Age max = 218 (likely error)“).

De façon similaire, on pourrait demander une “EDA” (Exploratory Data Analysis), qui fournira une analyse semblable, en partie redondante mais couvrant d’autres aspects.

Avec ce type de “prompt”, on a donc, en quelques minutes seulement, un premier aperçu détaillé, chiffré mais clair et facile à comprendre d’un jeu de données raisonnablement volumineux. ChatGPT comprend, ou à tout le moins se comporte comme s’il comprenait le contenu des données :

• Il calcule un “length of stay“, interprétant donc bien deux colonnes (DH_arrivee et DH_sortie). Petit bémol cependant : dans les données, l’heure d’arrivée contient une date et une heure, mais le “DH_sortie” uniquement la date (avec 00:00 comme heure), rendant le calcul peu pertinent, surtout pour les courts séjours. Mais si on lui demande comment il a calculé ce “length of stay“, il fait remarquer le problème ;
• Il “comprend” que la colonne “Code_CCMU” (avec les codes 1, 2, 3, 4, 5, P ou D) fait référence à la nomenclature française de la “Classification Clinique des Malades aux Urgences” et dénote la gravité. Il propose de faire une “severity analysis (CCMU code distribution)”, dans laquelle il interprète correctement les codes ;
• Il fait des propositions, certes un peu naïves, mais pertinentes dans le contexte, dont voici deux exemples :

Analyse par catégorie

En observant les données, nous avons remarqué deux colonnes concernant la raison d’arrivée du patient : une colonne “motif_entree”, très peu structurée (“Trauma cheville G”, “A avalé une LED avec une pile”…) et une autre “semi-structurée” : “Cardiologie: Douleur thoracique atypique”, “Pneumologie: Dyspnée sans détresse”, “Toxicologie: Alcoolisation/Ivresse aigue”… Il serait intéressant de pouvoir analyser certains éléments en fonction d’une “catégorie” : “Cardiologie”, “Pneumologie”, “Toxicologie”…

On peut tout simplement demander à ChatGPT “extract categories from motif_venue“, sans lui donner aucune information sur la façon de procéder. On reçoit alors en réponse une distribution de ce nouvel attribut, expliquant comment il l’a réalisé, ainsi que quelques commentaires pertinents sur la qualité des données :

Une question qui viendrait naturellement à l’esprit serait de voir comment celles-ci se comportent dans le temps. On peut par exemple imaginer que les problèmes pulmonaires surviennent surtout en hiver à l’époque des grippes et autres virus. Mais qu’en est-il des autres pathologies ?

Demandons à ChatGPT “Plot occurrence line charts grouped by cleansed categories, for the top 10“. Nous obtiendrons alors le graphique ci-contre, ainsi qu’une série de commentaires. On peut être surpris par la chute vertigineuse des chiffres, toutes catégories confondues, survenue début 2020. Mais toute personne n’ayant pas vécu dans une grotte à cette période en aura rapidement compris la raison… qui n’a pas échappé à ChatGPT, comme en témoigne un de ses commentaires :

“The sharp drop in early 2020 is visible across all categories — a clear COVID shock to ED visit“

Pour obtenir des tendances saisonnières, on peut demander de sommer les trois années pour lesquelles on a des données entières et de lisser les données, en considérant une moyenne glissante sur 7 jours : “For the top 10 cleansed categories, plot the number of visits per date in year (summing up values for 2017, 2018 and 2019, excluding 2016 and 2020), with a moving average of 7 days“.

Après quelques essais-erreurs de prompts pour sortir la légende du graphique ou adapter divers aspects, on obtient le résultat suivant :

Comme on s’y attendait, on peut observer que les pathologies pulmonaires (en brun) sont plus élevées en hiver qu’en été, mais ce qui est surprenant, c’est cet énorme pic à la toute fin de l’année de la stomatologie. Après s’être assuré que le pic se reproduisait bien tous les ans avec quelques prompts que nous passerons sous silence, nous avons demandé “how to explain the peak of total visits for stomatology for the last week?“. Nous avons été clairement bluffés par la pertinence de la réponse.

Deux explications, que ChatGPT n’a pas pu trouver dans le jeu de données, mais uniquement en faisant le lien avec son “savoir général”, nous paraissent très plausibles :

• Les cabinets de dentisteries sont majoritairement fermés pendant les fêtes (ou plus généralement pendant les congés, vu les deux plus petits pics) ;
• Beaucoup de monde veut “épuiser” ses possibilités de remboursement avant la fin de l’année.

Il va sans dire qu’un approfondissement serait nécessaire avant d’en tirer des décisions opérationnelles, mais on a déjà ici à très petits frais une série d’hypothèses à explorer.

Limitations

Si un premier aperçu peut sembler impressionnant, il faut cependant rester prudent. De toute évidence, un tel outil peut être un allié précieux pour un data scientist, et peut même permettre à des profils “métiers” aux compétences techniques limitées d’accéder à une première analyse. Voici quelques points d’attention issus de notre expérience sur ce jeu de données.

• On ne devient pas “data scientist” simplement parce qu’on est capable de produire des beaux graphiques ou livrer des chiffres. Encore faut-il être capable de les interpréter, de s’assurer qu’on n’est pas tombé dans un des nombreux pièges que les statistiques nous tendent ;
• Dans notre exemple, nous avons envoyé tout notre jeu de données à ChatGPT. Nous n’avons aucun contrôle sur ce qu’il en fait. Il s’agissait en l’occurrence de données publiques, mais qu’en sera-t-il avec des données confidentielles ? Il est toujours possible d’installer un LLM on-premise, mais les coûts sont autrement plus élevés et les performances moindres ;
• Nous n’avons testé qu’un exemple avec une seule table. La littérature semble montrer que ça reste valable avec une base de données plus complexe, il nous faudra encore l’expérimenter ;
• Le mode “question-réponse” permet uniquement un long dialogue linéaire. On se retrouve vite avec une longue discussion très désordonnée, plusieurs tentatives pour arriver à faire comprendre à l’outil ce que l’on veut. Si l’on veut par exemple corriger un critère en amont d’une analyse déjà faite (par exemple, la limiter à une période dans le temps, ou éliminer certains types de données), on ne peut pas revenir en arrière. Il sera nécessaire de recommencer un nouveau chat, ou de reposer toutes les questions ;
• Dans le même ordre d’idée, si les données d’entrée sont mises à jour, il sera nécessaire de recommencer toute la conversation ;
• À côté de l’aspect peu structuré, on note aussi un manque de cohérence :
  • Lors de l’extraction de la “catégorie”, nous avons demandé, outre la séparation sur la base du “:”, de corriger également certains problèmes de qualité (pour par exemple remplacer “Cardiovasculaire” par “Cardiologie” ou “Intoxications” par “Toxicologie”). Les questions qui suivaient de près ce nettoyage considéraient la version la plus élaborée. Mais quelques jours après, quand nous évoquions “cleansed categories”, ChatGPT se contentait de la séparation sur la base du “:”,
  • Nous avons posé exactement la même question à un mois d’intervalle. Les valeurs numériques fournies dans la réponse restaient cohérentes, mais le texte était radicalement différent sur la forme (bien que semblable sur le fond) ;
• Le code Python proposé à chaque question est réellement exécuté sur les serveurs de ChatGPT qui se sert du résultat pour générer sa réponse. Mais le temps d’exécution disponible est assez limité. Entraîner un modèle de Machine Learning simple (par exemple “Compute feature importance using Random Forest, with ‘scanner’ as target“) provoque souvent un timeout. Cependant, ChatGPT fait alors une série de propositions, visant à réduire le temps de calcul nécessaire (stratification, réduction du nombre d’arbres, diminution de la cardinalité de certaines variables…).

Conclusion

Une approche pertinente serait probablement d’utiliser ChatGPT ou un de ses concurrents pour découvrir les données, identifier rapidement des anomalies ou des problèmes de qualité, les approches possibles, les modèles de prédiction adaptés… On pourrait aussi demander de générer des graphiques, des tableaux, des chiffres… On pourra ensuite récupérer les morceaux de codes proposés qui pourront être intégrés dans un script ou un notebook consolidé. Notons que l’on peut également interagir avec les API de ChatGPT et autres Gemini. Nous aborderons cette approche dans un prochain article.

En regardant vers l’avenir, nous ne craignons pas que le GenAI remplace les data scientists. De toute évidence, l’augmentation inévitable des volumes de données de plus en plus importants et complexes ne va faire qu’accroître la nécessité de personnel capable de mener leur analyse. Mais le GenAI va indiscutablement changer leur métier. Et le GenAI va certainement remplacer les data scientists qui ne l’utilisent pas par les data scientists qui sauront s’en servir efficacement.

Dans un précédent article, nous avons exposé les avantages des conteneurs confidentiels et leur architecture dans le projet « CoCo. » Dans cet article, nous approfondissons notre propos en détaillant le fonctionnement de certains aspects de CoCo et en décrivant notre installation sur notre propre matériel.

Attestation de conteneurs

Les capsules Kubernetes, utilisées comme abstraction pour les charges de travail conteneurisées confidentielles, introduisent plusieurs défis. Leur nature dynamique — création, suppression, mise à jour de conteneurs — et l’influence de l’environnement Kubernetes (variables d’environnement, contrôleurs d’admission, etc.) rendent difficile la garantie que seul le code prévu par l’utilisateur sera exécuté. Par exemple, l’injection de variables malveillantes ou la modification de la spécification d’une capsule avant son lancement peuvent compromettre la confidentialité.

Le projet CoCo propose une solution élégante qui consiste à utiliser un moteur de politiques de sécurité, intégré à l’environnement d’exécution du conteneur dans l’environnement d’exécution de confiance (EEC), qui applique des règles définies par l’utilisateur. Ce moteur peut, par exemple, autoriser uniquement certaines images ou commandes, et rejeter les appels problématiques (comme l’exécution de processus non autorisés). La Figure 1 montre un exemple d’une telle politique.

package agent_policy

# Seules certaines images de conteneurs peuvent être exécutées
default CreateContainerRequest := false
CreateContainerRequest if {
    every storage in input.storages {
    some allowed_image in policy_data.allowed_images
    storage.source == allowed_image
  }
}

# Seules certaines commandes peuvent être exécutées
# via ‘kubectl exec’ dans les images de conteneurs
default ExecProcessRequest := false
ExecProcessRequest if {
  input_command = concat(" ", input.process.Args)
      some allowed_command in policy_data.allowed_commands
      input_command == allowed_command
}

policy_data := {
    "allowed_commands": [
        "ls",
        "cat",
    ],
    "allowed_images": [
        "pause",
        "my-registry.be/,my-app@sha256:5ed86f469bbc40026a0235dd92e2b0b0c7ce54e3b254132e271a9b9e85d5f220
",
    ],
}

package agent_policy

# Seules certaines images de conteneurs peuvent être exécutées
default CreateContainerRequest := false
CreateContainerRequest if {
    every storage in input.storages {
    some allowed_image in policy_data.allowed_images
    storage.source == allowed_image
  }
}

# Seules certaines commandes peuvent être exécutées
# via ‘kubectl exec’ dans les images de conteneurs
default ExecProcessRequest := false
ExecProcessRequest if {
  input_command = concat(" ", input.process.Args)
      some allowed_command in policy_data.allowed_commands
      input_command == allowed_command
}

policy_data := {
    "allowed_commands": [
        "ls",
        "cat",
    ],
    "allowed_images": [
        "pause",
        "my-registry.be/,my-app@sha256:5ed86f469bbc40026a0235dd92e2b0b0c7ce54e3b254132e271a9b9e85d5f220
",
    ],
}

Figure 1 – Exemple de politique de sécurité (langage REGO) restreignant les images pouvant être exécutées et les commandes pouvant être invoquées dans l’image. Cette politique est appliquée par un agent inclus dans la machine virtuelle confidentielle.

Quatre composants de la machine virtuelle confidentielle invitée sont systématiquement mesurés pour assurer leur intégrité : le micrologiciel (e.g., OVMF), le noyau du système d’exploitation, la ligne de commande du noyau et le système de fichiers racine (Figure 2). Une entité externe de confiance, généralement appelée Trustee, atteste de l’intégrité de l’invité, renforçant ainsi la chaîne de confiance.

Cependant, les conteneurs confidentiels nécessitent généralement des données d’initialisation qui ne peuvent pas être intégrées directement dans l’image de la machine virtuelle ou du conteneur applicatif, comme les certificats, les adresses des services d’attestation ou les politiques de sécurité à appliquer. Ces données, bien que non secrètes, doivent être protégées contre toute altération.

Ces données d’initialisation appelées init-data peuvent être spécifiées sous forme de dictionnaire (e.g., fichiers JSON, TOML, YAML), encodé en base64 et passé à la capsule Kubernetes via une annotation Kubernetes (Figure 3). Afin de garantir leur intégrité, leur valeur de hachage cryptographique est fournie par l’agent d’attestation (fonctionnant dans la machine virtuelle confidentielle) en donnée d’entrée pour le calcul de l’attestation (cela peut se faire en utilisant le champ « HostData » de SEV-SNP). Il est alors possible de comparer les données d’initialisation envoyées à la machine hôte pour le lancement du conteneur avec la valeur de hachage reçue au moment de l’attestation, assurant ainsi que toute modification sera détectée lors de l’attestation à distance.

version = "0.1.0"
algorithm = "sha256"

[data]

# Configuration de l’agent d’attestation
"aa.toml" = '''
[token_configs]
[token_configs.kbs]
url = "${KBS_ADDRESS}"
'''

# Configuration du gestionnaire de données secrètes
"cdh.toml" = '''
[kbc]
name = "cc_kbc"
url = "${KBS_ADDRESS}"

[image]
authenticated_registry_credentials_uri = "kbs:///${REGISTRY_AUTH_KBS_PATH}"
image_security_policy_uri = "${SECURITY_POLICY_KBS_URI}"
'''

# Politique de sécurité restreignant l’environnement du conteneur
"policy.rego"= '''
[Voir Figure 1 ci-dessus]
'''

version = "0.1.0"
algorithm = "sha256"

[data]

# Configuration de l’agent d’attestation
"aa.toml" = '''
[token_configs]
[token_configs.kbs]
url = "${KBS_ADDRESS}"
'''

# Configuration du gestionnaire de données secrètes
"cdh.toml" = '''
[kbc]
name = "cc_kbc"
url = "${KBS_ADDRESS}"

[image]
authenticated_registry_credentials_uri = "kbs:///${REGISTRY_AUTH_KBS_PATH}"
image_security_policy_uri = "${SECURITY_POLICY_KBS_URI}"
'''

# Politique de sécurité restreignant l’environnement du conteneur
"policy.rego"= '''
[Voir Figure 1 ci-dessus]
'''

Figure 3 – Exemple de données d’initialisation fournies (sous forme encodée) via une annotation Kubernetes à l’agent invité CoCo dans la machine virtuelle confidentielle.

Gestion de clés

Un service extérieur de médiation de clés, qui peut être connecté à une boîte noire transactionnelle, permet au conteneur d’obtenir dynamiquement des ressources nécessaires à son fonctionnement. Si le client n’est pas déjà en possession d’un témoin de connexion précédemment obtenu du service de médiation de clés, il doit d’abord s’authentifier et le service de médiation de clés lui répond avec un défi auquel il doit répondre (Figure 4).

Le client génère une paire de clés cryptographiques et demande au processeur de lui fournir une attestation en incluant la valeur de hachage de sa clé publique et une valeur aléatoire unique envoyée par le service dans son défi. L’attestation qui lie clé publique du client, valeur aléatoire unique envoyée par le service et mesure de la VM confidentielle contenant le client est signée par le processeur. Le service fait appel à un agent d’attestation qui vérifie l’attestation en vérifiant la signature et en comparant la mesure à une valeur de référence.

Installation et tests

Afin de tester l’environnement CoCo, nous avons choisi d’utiliser un microprocesseur EPYC 9335 de la société AMD. Il met en œuvre la technologie SEV-SNP de chiffrement et de protection de l’intégrité de la mémoire vive. Nous avons assemblé une machine avec une carte mère prenant en charge ce microprocesseur (Supermicro MBD-H13SSL-NT-O) et 128 Go de mémoire vive. Il a ensuite fallu configurer le BIOS afin que les fonctionnalités souhaitées de sécurité du microprocesseur soient bien activées. Nous avons aussi opté pour la distribution Ubuntu 24.04.3 LTS du système d’exploitation Linux. Avant de pouvoir tester les fonctionnalités de sécurité du processeur, nous avons enfin dû recompiler le noyau du système d’exploitation. L’opération est en fait relativement simple grâce aux scripts fournis par AMD.

Une fois le système configuré, il est alors possible d’y installer la plateforme Docker (afin de pouvoir créer des images de conteneurs), l’interface d’exécution de conteneur containerd (incluse dans la distribution de Docker) et le système de gestion Kubernetes. La configuration de ces outils est assez délicate et sensible aux version. Plusieurs scripts permettant de faciliter cette installation sont fournis ici.

Une fois le système installé, il nous a été possible de déployer une application existante dans des conteneurs confidentiels : il suffit en fait de changer le nom de classe d’exécution utilisé par Kubernetes (runtimeClassName) dans le fichier YAML de configuration de Kubernetes pour l’une des classes de CoCo (e.g., kata-qemu-snp). Bien sûr ce changement simple ne suffit pas à bénéficier des fonctionnalités de sécurité de CoCo. Il est nécessaire de modifier le cycle de production afin d’ajouter les étapes suivantes :

• Chiffrement de l’image du conteneur
• Signature de l’image du conteneur
• Mise à disposition des clés de chiffrement et de signature

Une fois l’image du conteneur créée de la manière habituelle, par exemple avec docker build, celle-ci peut être chiffrée avec l’outil skopeo qui prend en charge différents algorithmes : JWE (RFC7516), PGP (RFC4880), et PKCS7 (RFC2315). Cette image chiffrée peut ensuite être signée avec l’outil cosign et enfin chargée sur un registre d’images.

Au moment du lancement du conteneur, les composants CoCo inclus dans la machine virtuelle confidentielle devront pouvoir vérifier la signature et déchiffrer son image. Pour cela, il est nécessaire de mettre à disposition les clé requises. C’est là que le système de médiation de clés intervient. Comme nous l’avons vu précédemment, celui effectue un protocole d’attestation avant de fournir les clés.

Le déploiement des conteneurs confidentiels est transparent vis-à-vis de l’utilisateur de Kubernetes. Une fois l’invocation de la commande habituelle kubectl apply, une machine virtuelle légère Kata est créée. Celle-ci doit récupérer auprès du médiateur de clés, la clé d’accès au registre d’image (si celui-ci n’est pas public), la politique de sécurité à appliquer, la clé de vérification de signature et la clé de déchiffrement de l’image. Ces informations ne sont fournies qu’après l’attestation de la machine virtuelle (voir plus haut). Les agents inclus dans la machine virtuelle peuvent alors appliquer la politique de sécurité, télécharger l’image, vérifier sa signature et la déchiffrer avant de lancer le conteneur applicatif dans la machine virtuelle.

En ce qui concerne la communication de l’application conteneurisée avec des services extérieurs, il convient d’établir des clés de chiffrement mutuellement reconnues. Une première possibilité est que le conteneur confidentiel crée une paire de clé cryptographiques à son lancement et fournisse la valeur de hachage cryptographique de cette clé publique lors de l’attestation. C’est ce qui est utilisé dans le protocole d’authentification présenté dans la Figure 4. Une autre option est de fournir la clé publique d’une autorité de certification dans l’image chiffrée-puis-signée. Le conteneur pourra alors vérifier les certificats signés par cette autorité et accepter des clés de chiffrement. Une troisième option consiste à s’appuyer sur le service de médiation de clés : celui-ci permet au conteneur de récupérer des secrets de manière sécurisée. En fonction de l’option choisie, il conviendra de modifier plus ou moins le code de l’application.

Protection vis-à-vis d’un administrateur

Que peut faire un administrateur de la machine hôte ? A priori, pas grand-chose, à part lancer le conteneur.

En effet, le mécanisme d’attestation l’empêche de substituer ou de simuler les composants de la machine virtuelle utilisée pour le lancement des conteneurs. Le chiffrement de la mémoire allouée à la machine virtuelle le bloque dans l’observation des données traitées dans la machine virtuelle et le conteneur. Le chiffrement et la signature de l’image du conteneur ne lui permettent ni de substituer un autre conteneur, ni de connaître la nature du conteneur. En supposant que l’application soit configurée pour communiquer de manière chiffrée avec les services extérieurs avec lesquelles elle doit interagir, l’administrateur ne peut pas non plus accéder aux données sensibles en observant le trafic réseau, sauf s’il a également un accès privilégié au système de création des clés. Enfin, il ne peut pas non plus interroger le conteneur via la commande kubectl exec car celle-ci peut être restreinte via une politique de sécurité (voir Figure 1).

En revanche, l’administrateur peut lire les journaux applicatifs enregistrés par Kubernetes sur l’hôte. Par conséquent, il est important que le fournisseur de la charge de travail prenne soin que son code ne divulgue pas des informations sensibles dans les messages journalisés de l’application.

Enfin, comme nous l’avons rappelé dans l’article précédent, les environnements d’exécution de confiance ne sont pas parfaits et leur modèle de sécurité ne tient généralement pas compte des attaques physiques. Dans un environnement comme le G-Cloud, leur ajout offre de nombreuses possibilités. En revanche, dans un environnement où ni SMALS, ni ses clients, ni même l’État belge n’ont le moindre contrôle technique ou juridique sur l’infrastructure, il existe des risques importants qu’il convient d’évaluer sérieusement.

Conclusion

À travers cet article et le précédent, nous avons mis en avant les avantages réels en termes de sécurité que pourraient apporter des microprocesseurs permettant de créer des environnements d’exécution de confiance au sein d’une infrastructure informatique. En particulier, leur utilisation « on-premise » permet de mieux protéger des applications conteneurisées d’administrateurs malveillants ou d’intrus et donc d’offrir des garanties encore plus fortes à nos Membres.

Plus simples d’utilisation que les méthodes cryptographiques avancées, de tels systèmes pourraient aussi nous permettre de résoudre des problèmes plus génériques que la cryptographie ou des problèmes que nous ne pouvions pas résoudre jusqu’à présent.

Dit artikel is ook beschikbaar in het Nederlands.

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 blogue, 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 en 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 d’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 traitement par lots, 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 descendante, que nous pouvons toutefois compléter par une version ascendante : 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 base de connaissances 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 outils 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://staging.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://staging.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://staging.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.