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 workflows 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 CCR 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 “dashboard + 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 data lake. 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 Data Spaces – pour un “jumeau politique”, par exemple, le Legal Data Space. Il existe également des points communs avec le concept de Regulatory Sandboxes tel qu’il apparaît notamment dans l’Interoperable Europe Act ou, plus récemment, dans l’AI Act : 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 la hype en soi n’apporte rien.

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 un 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.

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 European Health Data Spaces 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 coûteuse?

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 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 JRC  (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 la hype, ils nécessitent un investissement constant en maintenance. Ces coûts récurrents comprennent au moins les éléments suivants :

• monitoring 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 monitoring et de replay, 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 un monitoring, 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 voit 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 que 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.

Cet article est aussi disponible en français.

De recente opkomst van generatieve artificiële intelligentie (GenAI) heeft tal van sectoren op hun kop gezet, waaronder de IT-sector zelf (coding assistants, geautomatiseerd testen, vertaling van programmeertalen…). Het domein van de data-analyse, of data science, vormt hierop geen uitzondering. Vaak wordt gezegd dat 80% van de tijd van een data scientist wordt besteed aan het pre-processing van data (ingestion, transformatie, opschoning, verrijking…), wat vaak arbeidsintensief en repetitief is, en dat slechts 20% een beroep doet op zijn meest geavanceerde vaardigheden. Kan GenAI worden ingezet om deze 80% te versnellen? Aan de hand van dit inleidende artikel zullen we aantonen dat het antwoord grotendeels positief is, maar dat bovendien ook de resterende 20% al in belangrijke mate is aangepakt. We bekijken in hoeverre een tool als ChatGPT kan helpen bij het analyseren van data: begrijpen wat ze bevatten, statistische indicatoren extraheren, afwijkingen identificeren, specifieke fenomenen verklaren….

Om dit te illustreren, baseren we ons op de dataset “urgences data”, beschikbaar op Kaggle.
 Het betreft een CSV-bestand van ~430 MB, bestaande uit 336.253 rijen en 39 kolommen, zonder bijbehorende metadata. Elke rij komt overeen met een bezoek van een patiënt aan de spoeddienst van een (niet nader genoemd) ziekenhuis in Noord-Frankrijk, tussen 6 januari 2016 en 6 december 2020. Het bevat een schat aan informatie: datum en tijdstip van aankomst en vertrek, vervoermiddel, oorzaak, leeftijd, een aantal medische parameters, zoals hartslag, bloeddruk, temperatuur, zuurstofsaturatie, evenals booleaanse waarden die lijken aan te geven of aanvullende onderzoeken zijn voorgeschreven (bloedonderzoek, röntgenfoto, echografie, CT-scan, MRI…)

We gaan gebruikmaken van “Data Analyst”, een van de “GPT’s” die in ChatGPT worden aangeboden. Aangezien de gratis versie beperkt is tot een zeer klein aantal vragen, hebben we een betaalde versie (“Personal Plus”) gebruikt. Voor deze oefening hebben we in het Engels gecommuniceerd, maar vergelijkbare resultaten zouden waarschijnlijk ook in het Frans of Nederlands zijn verkregen.

Voorafgaande analyse

Een eerste stap kan bestaan uit het simpelweg indienen van het te analyseren bestand bij “Data Analyst” en hem te vragen wat hij daarin kan vinden. Meer formeel levert een vraag als “What useful insight can you extract from those data?” ons het onderstaande resultaat op.

We verkrijgen een resultaat dat een structuur volgt die in bijna alle antwoorden terug te vinden is:

1. Een reeks grafieken. Hier zien we een leeftijdsverdeling van de patiënten, de gemiddelde verdeling per tijdstip van de dag, evenals de verdeling van de bestemming (terug naar huis, interne overplaatsing…). Merk op dat ChatGPT, zonder dat wij daar iets over hebben gezegd, begrepen heeft dat het om patiënten van een spoeddienst ging;
2. Een gestructureerde tekstanalyse van wat het uit de gegevens heeft kunnen opmaken. De demografische gegevens van de patiënten, de piekuren, waar de patiënten na vertrek naartoe gaan en hoe ze zijn aangekomen;
3. Strategische voorstellen;
4. Voorstellen voor de volgende stappen. “If you’d like, I can next:”, gevolgd door een reeks relevante prompts om de analyse voort te zetten (die je helaas moet kopiëren en plakken).

Bovendien eindigt de tekst altijd met een link “</>”, die niet voorkomt in een “standaard” ChatGPT-chat en waarop je kan klikken om de Python-code te verkrijgen waarop deze analyse is gebaseerd. Deze code, die is gemaakt met behulp van de Python-library “Pandas” (een van de meest gebruikte open-source tools voor data-analyse en data science), maakt het mogelijk om de voorgestelde grafieken te genereren, evenals alle cijfers die in de beschrijvingen worden gebruikt. Het is dus volkomen mogelijk om deze code niet alleen direct te gebruiken, maar ook om er zeker van te zijn dat de cijfers niet volledig verzonnen zijn, maar gebaseerd zijn op algemene statistische modellen en zorgvuldig berekend zijn op basis van de verstrekte gegevens.

Zo konden we met één enkele zin en na amper een minuut wachten drie grafieken, Python-code en een beschrijvende tekst verkrijgen, waar een data scientist normaal gesproken meerdere uren over zou hebben gedaan. Dit is natuurlijk een zeer beknopte eerste benadering. Maar we kunnen nog verder gaan.

We kunnen bijvoorbeeld vragen naar een statistische beschrijving voor elke kolom. Het resultaat is hier een lange, zeer gestructureerde beschrijving, per type variabele (numeriek of categorisch), met een reeks indicatoren: gemiddelde, minimum/maximum, aantal ontbrekende waarden… evenals een opmerking (“Not usable for analysis”, “Vital signs moderately complete”, “Excellent for resource utilization analysis”, “Likely categorical indicator”…). De tool biedt ons ook enkele opmerkingen met betrekking tot de kwaliteit van de gegevens (bijvoorbeeld: “Outliers: Age max = 218 (likely error)”).

Op dezelfde manier kunnen we een “EDA” (Exploratory Data Analysis) aanvragen, die een vergelijkbare analyse oplevert, die deels overlapt maar ook andere aspecten behandelt.

Met dit soort “prompt” hebben we dus binnen enkele minuten een eerste gedetailleerd, cijfermatig maar duidelijk en begrijpelijk overzicht van een redelijk omvangrijke dataset. ChatGPT begrijpt, of gedraagt zich in ieder geval alsof het de inhoud van de gegevens begrijpt:

• De tool berekent een “length of stay” en interpreteert dus duidelijk twee kolommen (DH_arrivee en DH_sortie). Er is echter een klein probleempje: in de gegevens bevat het aankomsttijdstip een datum en een uur, maar de “DH_sortie” bevat alleen de datum (met 00:00 als uur), waardoor de berekening weinig relevant is, vooral voor korte verblijven. Maar als we hem vragen hoe hij deze “length of stay” heeft berekend, wijst hij op het probleem;
• Hij ‘begrijpt’ dat de kolom ‘Code_CCMU’ (met de codes 1, 2, 3, 4, 5, P of D) verwijst naar de Franse nomenclatuur van de ‘Classification Clinique des Malades aux Urgences’ en de ernst aangeeft. Hij stelt voor om een “severity analysis (CCMU code distribution)” uit te voeren, waarin hij de codes correct interpreteert;
• Hij komt met voorstellen die weliswaar enigszins naïef zijn, maar relevant in deze context. Hier volgen twee voorbeelden:

Analyse per categorie

Bij het bekijken van de gegevens viel ons op dat er twee kolommen zijn die betrekking hebben op de reden van opname van de patiënt: een kolom “motif_entree”, die zeer weinig gestructureerd is ( “Trauma cheville G”, “A avalé une LED avec une pile”…) en een andere “semi-gestructureerde” kolom: “Cardiologie: Douleur thoracique atypique”, “Pneumologie: Dyspnée sans détresse”, “Toxicologie: Alcoolisation/Ivresse aigue”… Het zou interessant zijn om bepaalde elementen te kunnen analyseren op basis van een “categorie”: “Cardiologie”, “Pneumologie”, “Toxicologie”…

We kunnen ChatGPT eenvoudigweg vragen “extract categories from motif_venue”, zonder het enige informatie te geven over hoe dit moet gebeuren. Als antwoord krijgen we dan een overzicht van deze nieuwe attributen, met uitleg over hoe dit tot stand is gekomen, evenals enkele relevante opmerkingen over de kwaliteit van de gegevens:

Een vraag die dan natuurlijk in ons opkomt, is hoe deze zich in de loop van de tijd gedragen. We kunnen ons bijvoorbeeld voorstellen dat longproblemen vooral in de winter voorkomen, in de periode waarin griep en andere virussen heersen. Maar hoe zit het met de andere aandoeningen?

Laten we ChatGPT vragen: “Plot occurrence line charts grouped by cleansed categories, for the top 10“. We krijgen dan de grafiek tegenover deze tekst te zien, samen met een reeks opmerkingen. Men kan verrast zijn door de duizelingwekkende daling van de cijfers, over alle categorieën heen, die zich begin 2020 voordeed. Maar iedereen die in deze periode niet onder een steen heeft geleefd, zal de reden hiervoor snel hebben begrepen… wat ChatGPT ook niet is ontgaan, zoals blijkt uit een van zijn opmerkingen:

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

Om seizoensgebonden trends te verkrijgen, kunnen we vragen om de drie jaren waarvoor we volledige gegevens hebben bij elkaar op te tellen en de gegevens af te vlakken, waarbij we uitgaan van een voortschrijdend gemiddelde over 7 dagen: “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“.

Na wat vallen en opstaan met prompts om de grafieklegende weer te geven of diverse aspecten aan te passen, verkrijgen we het volgende resultaat:

Zoals verwacht merken we dat longziekten (in het bruin) in de winter vaker voorkomen dan in de zomer, maar wat verrassend is, is die enorme piek in de stomatologie helemaal aan het einde van het jaar. Nadat we ons ervan hadden verzekerd dat de piek zich inderdaad elk jaar voordeed, met enkele uitschieters die we hier buiten beschouwing laten, stelden we de vraag: “how to explain the peak of total visits for stomatology for the last week?”.We waren duidelijk onder de indruk van de relevantie van het antwoord.

Twee verklaringen, die ChatGPT niet in de dataset heeft kunnen vinden, maar alleen door een verband te leggen met zijn “algemene kennis”, lijken ons zeer aannemelijk:

• Tandartspraktijken zijn tijdens de feestdagen grotendeels gesloten (of meer in het algemeen tijdens de vakantie, gezien de twee kleinere pieken);
• Veel mensen willen hun vergoedingsmogelijkheden vóór het einde van het jaar ‘volledig benutten’.

Het spreekt voor zich dat nader onderzoek nodig is alvorens hieruit operationele beslissingen te trekken, maar we hebben hier al tegen zeer lage kosten een reeks hypothesen om te onderzoeken.

Beperkingen

Hoewel een eerste overzicht indrukwekkend kan lijken, is voorzichtigheid geboden. Het is duidelijk dat een dergelijk hulpmiddel een waardevolle bondgenoot kan zijn voor een data scientist, en zelfs professionals met beperkte technische vaardigheden in staat kan stellen toegang te krijgen tot een eerste analyse. Hier volgen enkele aandachtspunten uit onze ervaring met deze dataset.

• Je wordt geen “data scientist” alleen omdat je mooie grafieken kunt maken of cijfers kunt leveren. Je moet ze ook kunnen interpreteren en ervoor zorgen dat je niet in een van de vele valkuilen van de statistiek trapt;
• In ons voorbeeld hebben we onze volledige dataset naar ChatGPT gestuurd. We hebben geen enkele controle over wat ermee gebeurt. In dit geval ging het om openbare gegevens, maar hoe zit het met vertrouwelijke gegevens? Het is altijd mogelijk om een LLM on-premise te installeren, maar de kosten zijn aanzienlijk hoger en de prestaties lager;
• We hebben slechts één voorbeeld met één tabel getest. De literatuur lijkt aan te geven dat dit ook geldt voor een complexere database, maar we zullen dit nog moeten uitproberen;
• De modus “vraag-antwoord” maakt alleen een lange, lineaire dialoog mogelijk. Al snel ontstaat er een lange, zeer rommelige discussie, met meerdere pogingen om de tool duidelijk te maken wat we willen. Als we bijvoorbeeld een criterium willen aanpassen voorafgaand aan een reeds uitgevoerde analyse (bijvoorbeeld door deze te beperken tot een bepaalde periode of bepaalde soorten gegevens te verwijderen), kunnen we niet teruggaan. Je moet dan een nieuwe chat starten of alle vragen opnieuw stellen;
• In dezelfde lijn: als de invoergegevens worden bijgewerkt, moet het hele gesprek opnieuw worden gevoerd;
• Naast het weinig gestructureerde karakter valt ook een gebrek aan consistentie op:
  • Bij het extraheren van de “categorie” hebben we gevraagd om, naast de scheiding op basis van de “:”, ook bepaalde kwaliteitsproblemen te corrigeren (bijvoorbeeld door “Cardiovasculaire” te vervangen door “Cardiologie” of “Intoxications” door “Toxicologie”). De vragen die kort na deze opschoning volgden, hielden rekening met de meest uitgebreide versie. Maar enkele dagen later, toen we het hadden over “cleansed categories”, hield ChatGPT het bij splitsen op basis van de “:”,
  • We hebben precies dezelfde vraag met een onderbreking van een maand gesteld. De numerieke waarden in het antwoord bleven consistent, maar de tekst was qua vorm radicaal anders (hoewel qua inhoud vergelijkbaar);
• De Python-code die bij elke vraag wordt voorgesteld, wordt daadwerkelijk uitgevoerd op de servers van ChatGPT, dat het resultaat gebruikt om zijn antwoord te genereren. Maar de beschikbare uitvoeringstijd is vrij beperkt. Het trainen van een eenvoudig machine learning-model (bijvoorbeeld “Compute feature importance using Random Forest, with ‘scanner’ as target”) leidt vaak tot een time-out. ChatGPT doet dan echter een reeks voorstellen om de benodigde rekentijd te verminderen (stratificatie, vermindering van het aantal bomen, vermindering van de cardinaliteit van bepaalde variabelen…).

Besluit

Een relevante aanpak zou waarschijnlijk zijn om ChatGPT of een van zijn concurrenten te gebruiken om de gegevens te verkennen, snel afwijkingen of kwaliteitsproblemen te identificeren, mogelijke benaderingen te vinden, geschikte voorspellingsmodellen te selecteren… Je zou ook kunnen vragen om grafieken, tabellen en cijfers te genereren… Vervolgens kunnen de voorgestelde stukjes code worden opgehaald en geïntegreerd in een script of een geconsolideerd notebook. Merk op dat er ook kan worden geïnterageerd met de API’s van ChatGPT en anderen, zoals Gemini. We zullen deze aanpak in een volgend artikel bespreken.

Als we naar de toekomst kijken, zijn we niet bang dat GenAI data scientists zal vervangen. Het is duidelijk dat de onvermijdelijke toename van steeds grotere en complexere datavolumes de behoefte aan personeel dat deze analyse kan uitvoeren alleen maar zal vergroten. Maar GenAI zal hun beroep ongetwijfeld veranderen. En GenAI zal zeker de data scientists die het niet gebruiken, vervangen door data scientists die er effectief mee kunnen omgaan.

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

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

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

Definities

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

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

We kunnen twee stromingen van Digital Twins onderscheiden:

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

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

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

Toonaangevende projecten

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

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

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

Administratieve Use Cases

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

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

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

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

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

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

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

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

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

Implementatie: een kostelijke affaire?

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

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

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

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

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

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

Conclusie

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

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

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

(Nederlandstalige tekst : zie onder)

Webinar Smals, WebEx

Koen Vanderkimpen
Smals Research

04/06/2026  10h30 – 11h45

Language: Dutch / Slides in English

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.

In een vorige blogpost hebben we de voordelen besproken van confidential containers en hun architectuur in het CoCo-project. In deze blogpost gaan we dieper in op het onderwerp door bepaalde aspecten van CoCo in detail te beschrijven en onze installatie op onze eigen hardware toe te lichten.

Containercertificering

Het gebruik van Kubernetes-pods als abstractielaag voor vertrouwelijke container-workloads introduceert diverse uitdagingen. Door hun dynamische karakter – het maken, verwijderen, updaten van de containers – en de invloed van de Kubernetesomgeving (omgevingsvariabelen, toelatingscontrollers, enz.) valt het moeilijk te garanderen dat enkel de door de gebruiker bedoelde code wordt uitgevoerd. Zo kan het injecteren van kwaadaardige variabelen of het wijzigen van de specificatie van een pod voordat deze wordt gestart, de vertrouwelijkheid in gevaar brengen.

Het CoCo-project stelt een elegante oplossing voor, namelijk het gebruik van een engine voor beveiligingsbeleid, geïntegreerd in de containerruntime-omgeving binnen de trusted execution environment (TEE), die de door de gebruiker gedefinieerde regels toepast. Deze engine kan bijvoorbeeld alleen bepaalde images of commando’s toestaan en problematische verzoeken (zoals het uitvoeren van ongeoorloofde processen) afwijzen. Figuur 1 toont een voorbeeld van zo’n beleid.

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
",
    ],
}

Figuur 1 – Voorbeeld van een beperkend beveiligingsbeleid voor images die kunnen worden uitgevoerd en de commando’s die in de image kunnen worden aangeroepen. Dit beleid wordt toegepast door een agent die in de vertrouwelijke VM zit.

Vier componenten van de vertrouwelijke virtuele guestmachine worden altijd gecontroleerd om te bepalen of ze nog goed werken: de firmware (bijvoorbeeld OVMF), de kernel van het besturingssysteem, de kernel commandoregel en het rootbestandssysteem (Figuur 2). Een vertrouwelijke externe entiteit, vaak Trustee genoemd, zorgt ervoor dat de vertrouwensketen versterkt wordt.

Vertrouwelijke containers hebben echter meestal initialisatiedata nodig die niet direct in de image van de virtuele machine of de toepassingscontainer kunnen worden opgenomen, zoals certificaten, adressen van certificeringsdiensten of toe te passen beveiligingsbeleidsregels. Deze data zijn weliswaar niet geheim, maar moeten wel worden beschermd tegen wijzigingen.

Deze initialisatiedata, ook wel init-data genoemd, kunnen worden opgegeven in de vorm van een woordenboek (bijv. JSON-bestanden, TOML, YAML), gecodeerd in base64 en doorgegeven aan de Kubernetes-pod via een Kubernetes annotation (Figuur 3). Om de integriteit ervan te garanderen, wordt hun cryptografische hashwaarde door de certificeringsagent (die in de vertrouwelijke virtuele machine draait) als data voor de berekening van de certificering verstrekt (dit kan worden gedaan met behulp van het veld “HostData” van SEV-SNP). Het is dan mogelijk om de initialisatiedata die naar de hostmachine zijn gestuurd voor het starten van de container te vergelijken met de hashwaarde die op het moment van de certificering is ontvangen, zodat elke wijziging tijdens de certificering op afstand kan worden gedetecteerd.

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]
'''

Figuur 3 – Voorbeeld van initialisatiedata die (in gecodeerde vorm) via een Kubernetes-annotatie aan de CoCo-guestagent in de vertrouwelijke virtuele machine worden geleverd.

Sleutelbeheer

Een externe sleutelbemiddelingsdienst (key broker service), die kan worden gekoppeld aan een transactionele ‘black box’, stelt de container in staat om dynamisch de resources op te halen die nodig zijn voor de werking ervan. Indien de client nog niet in het bezit is van een eerder verkregen authenticatietoken van de sleutelbemiddelingsdienst, moet hij zich eerst authenticeren, waarna de sleutelbemiddelingsdienst hem een challenge stuurt die hij moet beantwoorden (Figuur 4).

De client genereert een paar cryptografische sleutels en vraagt de processor om een certificaat te verstrekken met daarin de hashwaarde van zijn openbare sleutel en een unieke willekeurige waarde die door de dienst in zijn challenge is verzonden. Het certificaat dat de openbare sleutel van de client, de unieke willekeurige waarde die door de service is gestuurd en de meting van de vertrouwelijke VM die de client bevat aan elkaar koppelt, wordt door de processor ondertekend. De service gebruikt een certificeringsagent die het certificaat controleert door de handtekening te verifiëren en de meting te vergelijken met een referentiewaarde.

Installatie en testen

Om de CoCo-omgeving te testen, hebben we gekozen voor een EPYC 9335-microprocessor van AMD. Deze maakt gebruik van SEV-SNP-technologie voor versleuteling en bescherming van de integriteit van het RAM-geheugen. We hebben een machine geassembleerd met een moederbord dat deze microprocessor ondersteunt (Supermicro MBD-H13SSL-NT-O) en 128 GB RAM-geheugen. Vervolgens moesten we het BIOS configureren om ervoor te zorgen dat de gewenste beveiligingsfuncties van de microprocessor goed waren geactiveerd. We hebben ook gekozen voor de Ubuntu 24.04.3 LTS-distributie van het Linux-besturingssysteem. Voordat we de beveiligingsfuncties van de processor konden testen, moesten we ten slotte de kernel van het besturingssysteem opnieuw compileren. Dit is eigenlijk vrij simpel dankzij de scripts die AMD heeft meegegeven.

Eenmaal het systeem is ingesteld, kun je het Docker-platform installeren (om containerimages te maken), de containeruitvoeringsinterface containerd (inbegrepen in de Docker-distributie) en het Kubernetes-beheersysteem. Het instellen van deze tools is best lastig en afhankelijk van de versie. Er zijn verschillende scripts beschikbaar om deze installatie te vergemakkelijken.

Nadat het systeem was geïnstalleerd, konden we een bestaande toepassing in vertrouwelijke containers zetten: je hoeft alleen maar de naam van de runtimeklasse die Kubernetes gebruikt (runtimeClassName) in het YAML-configuratiebestand van Kubernetes te veranderen in een van de CoCo-klassen (bijvoorbeeld kata-qemu-snp). Natuurlijk is deze simpele wijziging niet genoeg om te profiteren van de beveiligingsfuncties van CoCo. Je moet de productiecyclus aanpassen om de volgende stappen toe te voegen:

• Versleuteling van de containerimage
• Ondertekening van de containerimage
• Beschikbaar stellen van versleutelings- en ondertekeningssleutels

Zodra de containerimage op de gebruikelijke manier is gemaakt, bijvoorbeeld met docker build, kan deze worden versleuteld met de tool skopeo, die verschillende algoritmen ondersteunt: JWE (RFC7516), PGP (RFC4880) en PKCS7 (RFC2315). Deze versleutelde image kan vervolgens worden ondertekend met de tool cosign en ten slotte worden geüpload naar een imageregister.

Bij het opstarten van de container moeten de CoCo-componenten in de vertrouwelijke virtuele machine de handtekening kunnen verifiëren en de image kunnen ontsleutelen. Hiervoor moeten de benodigde sleutels beschikbaar worden gesteld. Hier komt het sleutelbemiddelingssysteem om de hoek kijken. Zoals we eerder hebben gezien, voert dit systeem een certificeringsprotocol uit voordat het de sleutels verstrekt.

De implementatie van confidential ccontainers is transparant voor de gebruiker van Kubernetes. Zodra het gebruikelijke commando kubectl apply wordt aangeroepen, wordt een lichte Kata-virtuele machine aangemaakt. Deze moet bij de sleutelbemiddelaar de toegangssleutel tot het imageregister (als dit niet openbaar is), het toe te passen beveiligingsbeleid, de sleutel voor handtekeningverificatie en de sleutel voor het ontsleutelen van de image ophalen. Deze informatie wordt pas verstrekt nadat de virtuele machine is geverifieerd (zie hierboven). De agents in de virtuele machine kunnen dan het beveiligingsbeleid toepassen, de image downloaden, de handtekening controleren en deze decoderen voordat de toepassingscontainer in de virtuele machine wordt gestart.

Wat betreft de communicatie van de gecontaineriseerde toepassing met externe diensten, moeten wederzijds erkende versleutelingssleutels worden ingesteld. Een eerste mogelijkheid is dat de vertrouwde container bij het opstarten een cryptografisch sleutelpaar aanmaakt en de cryptografische hashwaarde van deze openbare sleutel bij de certificering verstrekt. Dit wordt gebruikt binnen het authenticatieprotocol dat in Figuur 4 wordt beschreven. Een andere optie is om de openbare sleutel van een certificeringsinstantie in de versleutelde en vervolgens ondertekende image te verstrekken. De container kan dan de certificaten checken die deze autoriteit heeft ondertekend en de encryptiesleutels aanvaarden. Een derde optie bestaat erin om te steunen op de sleutelbemiddelingsdienst: hiermee kan de container op een veilige manier geheimen ophalen. Afhankelijk van de gekozen optie moet de code van de toepassing al dan niet worden aangepast.

Bescherming tegen een beheerder

Wat kan een beheerder van de hostmachine doen?  In principe niet veel, behalve de container opstarten.

Het certificeringsmechanisme zorgt er namelijk voor dat hij niets kan vervangen of simuleren wat betreft de onderdelen van de virtuele machine die wordt gebruikt om de containers te starten. Door de versleuteling van het geheugen dat aan de virtuele machine is toegewezen, heeft hij geen toegang tot de data die in de virtuele machine en de container worden verwerkt. Door de versleuteling en ondertekening van de containerimage kan hij geen andere container vervangen of de aard van de container achterhalen. In de veronderstelling dat de toepassing geconfigureerd is om versleuteld te communiceren met externe diensten waarmee ze moet interageren, kan de beheerder ook geen toegang krijgen tot gevoelige data door het netwerkverkeer te observeren, tenzij hij ook bevoorrechte toegang heeft tot het systeem voor het aanmaken van sleutels. Ten slotte kan hij de container ook niet ondervragen via het commando kubectl exec, omdat het kan worden beperkt door een beveiligingsbeleid (zie Figuur 1).

De beheerder kan daarentegen de toepassingslogboeken lezen die door Kubernetes op de host zijn opgeslagen. Daarom is het belangrijk dat de workload provider ervoor zorgt dat zijn code geen gevoelige informatie onthult in de gelogde berichten van de toepassing.

Tot slot, zoals we in de vorige blogpost al stelden, zijn vertrouwde uitvoeringsomgevingen niet perfect en houdt hun beveiligingsmodel meestal geen rekening met fysieke aanvallen. In een omgeving zoals de G-Cloud biedt de toevoeging ervan tal van mogelijkheden. In een omgeving waar echter noch SMALS, noch haar klanten, noch zelfs de Belgische Staat enige technische of juridische controle hebben over de infrastructuur, zijn er aanzienlijke risico’s die serieus moeten worden geëvalueerd.

Conclusie

In deze blogpost en de vorige hebben we de echte voordelen belicht op het gebied van beveiliging die microprocessors kunnen bieden om “vertrouwde uitvoeringsomgevingen” binnen een IT-infrastructuur te creëren. Vooral het “on-premise” gebruik ervan  maakt het mogelijk om gecontaineriseerde toepassingen beter te beschermen tegen kwaadwillige beheerders of indringers en zo onze leden nog meer garanties te bieden.

Omdat ze eenvoudiger in gebruik zijn dan geavanceerde cryptografische methoden, kunnen dergelijke systemen ons ook helpen om meer generieke problemen op te lossen dan met cryptografie alleen, of problemen die we tot nu toe simpelweg niet konden oplossen.

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”.