Inleiding

Detectie van anomalieën (ook wel ‘outliers’ of ‘afwijkende waarden’ genoemd) is een veelvoorkomend probleem binnen data science en machine learning. Dit opsporen wordt vaak gezien als een eenvoudige voorbereidende taak, maar kan ook prima het einddoel van de toepassing zijn:

• Als voorbereidende taak vindt de detectie plaats tijdens de verkennende analyse, om problemen met ‘garbage in, garbage out’ te beperken. Het doel is hier dus om deze anomalieën te corrigeren of te verwijderen om te voorkomen dat ze worden gebruikt tijdens de trainingsfase van het voorspellende model, omdat dit de prestaties ervan negatief zou kunnen beïnvloeden.
• Als hoofdtaak kan het opsporen van waarnemingen met afwijkende profielen bijvoorbeeld dienen om frauduleuze activiteiten, fouten of zelfs inbraken op te sporen (IDS: Intrusion Detection System) [1].

Het opsporen van anomalieën is dus een zeer belangrijke taak die in tal van domeinen veel toepassingen kent [1], en tot doel heeft waarnemingen te vinden die niet in overeenstemming zijn met de rest van de gegevens [2].

Deze blogpost gaat in op het probleem van het opsporen van anomalieën in gegevens en heeft tot doel oplossingen te presenteren die gebaseerd zijn op een machine learning-benadering.

Opmerkelijk is ook dat, hoewel deze twee gebieden met elkaar verband houden, anomaliedetectie verschilt van tools voor datakwaliteit (data quality) zoals Trillium en Open Refine. Bij data quality ligt de nadruk op het opsporen van problemen met incomplete/ongeldige gegevens aan de hand van regels, terwijl anomaliedetectie erop gericht is zeldzame/ongebruikelijke patterns te identificeren (die afwijken van de ‘norm’), maar die vanuit het oogpunt van data quality niet per se ongeldig zijn.

Verschillende soorten anomalieën

Voordat we ingaan op de tools voor het opsporen van anomalieën, zullen we eerst de verschillende soorten anomalieën definiëren die kunnen worden gedetecteerd. In de literatuur wordt vaak uitgegaan van drie soorten anomalieën [3] :

• De incidentele anomalie

Dit is de eenvoudigste vorm van anomalieën: een individueel geval dat als afwijkend wordt beschouwd ten opzichte van de rest van de gegevens.

Deze anomalieën worden soms nog onderverdeeld in twee subcategorieën: globale (die significant verschillen van de rest van de gegevens) en lokale anomalieën (die verschillen van de directe omgeving). Illustratief voorbeeld:

Figuur 1: Voorbeeld van lokale en globale anomalieën (afbeelding uit [4])

In figuur 1 zijn twee anomalieën te zien: o₁, een globale anomalie die sterk verschilt van de andere waarnemingen, en o₂, een lokale anomalie ten opzichte van de omgeving (de C2-groep).

• De contextuele anomalie

Een anomalie wordt als ‘contextueel’ beschouwd als deze in een andere context als normaal kan worden beschouwd. Neem bijvoorbeeld neerslag: een bepaald neerslagniveau dat op een bepaalde plek abnormaal is, kan op een andere plek heel goed als normaal worden beschouwd. We hebben hier dus twee soorten kenmerken: contextuele kenmerken die de context bepalen (vaak temporele of ruimtelijke kenmerken) en gedragsmatige kenmerken waarin we naar anomalieën zoeken (in ons voorbeeld: de neerslag).

• Collectieve anomalie/groepsanomalie

In deze laatste categorie gaat het niet langer om een individuele anomalie, maar om een reeks anomalieën die een groep vormen met ongebruikelijke kenmerken.

Detectiemethodes

Vaak (en vooral wanneer het gaat om een eenvoudige voorbereidende taak als data cleansing) gebeurt het opsporen van anomalieën in de gegevens eenvoudigweg met behulp van statistische tools (bijvoorbeeld door gebruik te maken van standaardanomalieën, kwantielen of statistische toetsen). In dit artikel gaan we niet in op deze statistische benaderingen, maar richten we ons op machine learning-benaderingen voor het opsporen van anomalieën.

Welk soort learning?

Er zijn hoofdzakelijk twee benaderingen om anomalieën op te sporen: methoden op basis van supervised learning (begeleid leren) en methoden op basis van unsupervised learning (onbegeleid leren). Ter herinnering: bij supervised learning wordt gebruikgemaakt van gelabelde data. Dit vereist dat er, naast de data, ook voorbeelden zijn van eerder geïdentificeerde anomalieën, zodat het detectiemodel kan leren deze te onderscheiden van normale data. Omgekeerd is unsupervised learning volledig gebaseerd op de data en vereist het geen set van vooraf geïdentificeerde anomalieën.

In het kader van dit artikel gaan we de unsupervised benaderingen verkennen. Deze hebben namelijk een interessant kenmerk ten opzichte van de supervised modellen (naast het feit dat ze geen gelabelde gegevens vereisen): het ontdekken van nieuwe vormen van anomalieën.

Een supervised model zal namelijk de neiging hebben om anomalieën te identificeren die kenmerken vertonen die vergelijkbaar zijn met die van de gelabelde anomalieën. Daarom is het, zelfs wanneer er gelabelde gegevens beschikbaar zijn, vaak interessant om een supervised model – getraind om bepaalde vooraf gedefinieerde anomalieprofielen nauwkeuriger te detecteren – te koppelen aan een unsupervised model, dat mogelijk anomalieën met totaal andere profielen kan opsporen.

Enkele klassieke algoritmes voor het opsporen van anomalieën

Voordat we beginnen, zullen we algoritmen voor het opsporen van anomalieën in twee categorieën indelen: detectoren en detectiemodellen. Een detectiemodel bouwt, zoals de naam al aangeeft, een model op dat op zichzelf kan worden gebruikt: als we bijvoorbeeld een nieuwe waarneming hebben, kunnen we die gewoon in het model invoeren om te beoordelen of het om een anomalie gaat. Een detector daarentegen heeft geen getraind model dat later kan worden gebruikt: als er een nieuwe waarneming binnenkomt, moet deze opnieuw in de context worden geplaatst door deze tussen de andere gegevens te plaatsen, of zelfs het detectieproces van anomalieën volledig opnieuw starten.

Detectoren zonder modellen

Een eerste intuïtieve benadering om te bepalen of een waarneming een anomalie is of niet, is gebaseerd op het idee dat een anomalie de neiging heeft om ver van zijn buren te liggen. Door dus de gemiddelde afstand (bijvoorbeeld de Euclidische afstand) te meten tussen een waarneming en zijn k dichtstbijzijnde buren (k-NN), of simpelweg de afstand tussen een waarneming en zijn k-de dichtstbijzijnde buur (kth-NN) [5], kan men het risico inschatten dat een waarneming een anomalie is: als de waarneming ver van de andere ligt, kan men aannemen dat het om een anomalie gaat.

Deze op afstand gebaseerde benadering heeft het voordeel dat ze intuïtief, eenvoudig te implementeren en te interpreteren is, maar ze stuit al snel op haar grenzen. Als we het voorbeeld uit Figuur 1, nog eens bekijken, zien we dat alle waarnemingen van cluster C1 verder van elkaar verwijderd zijn dan o₂ van de waarnemingen van C2. Resultaat: een op afstand gebaseerd algoritme zal anomalie o₁ gemakkelijk vinden, maar o₂ niet. Een zeer bekende alternatieve benadering, de Local Outlier Factor (LOF) [4] is gebaseerd op dichtheid in plaats van op afstand. Hiermee kunnen gevallen worden behandeld waarin de gegevens clusters bevatten (C1 en C2 in Figuur 1) die niet dezelfde dichtheid hebben.

Het idee is als volgt: kijken of de dichtheid rond een waarneming consistent is met de dichtheid van de k dichtstbijzijnde buren. Als we dus een waarneming nemen die deel uitmaakt van groep C1, is de dichtheid rond deze waarneming consistent met de dichtheid rond haar naaste buren, terwijl voor waarneming o2 de dichtheid rond o2 verschilt van de dichtheid rond haar naaste buren binnen C2. Het LOF-algoritme bestaat er dus in anomalieën te detecteren door na te gaan of hun dichtheid consistent is met de dichtheid van hun lokale omgeving.

Een laatste type detector dat we zullen bekijken, is gebaseerd op het clusteren van gegevens (clustering). Het bekende doel van clustering is het opsporen van groepen waarnemingen met vergelijkbare kenmerken. Dit maakt het met name mogelijk om:

• Te zoeken naar een waarneming die ver van het zwaartepunt van haar cluster ligt, of die zich in een microcluster bevindt die slechts één waarneming bevat (een incidentele anomalie).
• Zoeken naar abnormale clusters (collectieve anomalieën).

Jiang et al. [6] stellen bijvoorbeeld voor om de gegevens op te splitsen en vervolgens de ‘outlier factor’ van elke cluster te berekenen (gebaseerd op de afstand tussen die cluster en de andere), om zo clusters van anomalieën te vinden. He et al. [7] stellen het FindCBLOF-algoritme (CBLOF: cluster-based local outlier factor) voor, dat de gegevens opdeelt en vervolgens naar anomalieën zoekt door zowel de grootte van de clusters (te kleine clusters kunnen collectieve anomalieën vertegenwoordigen) als de afstanden tussen de waarnemingen en de zwaartepunten van de clusters te gebruiken.

Detectiemodellen

Nu we modelvrije benaderingen hebben bekeken, gaan we kort verder met modelgebaseerde benaderingen voor het opsporen van anomalieën. Dit hoofdstuk zal vrij kort zijn en slechts twee van de bekendste modellen behandelen: de ‘isolation forest’ en de ‘one-class SVM’.

Isolation forest [8] is gebaseerd op het principe dat een anomalie, omdat deze ongebruikelijke kenmerken vertoont, gemakkelijker te isoleren zou moeten zijn dan een normale waarneming.

Het idee is simpel: we kiezen willekeurig een variabele en een waarde (bijvoorbeeld: leeftijd (variabele) en 21.3 (waarde)), en gebruiken die om de gegevens in twee subgroepen (takken) te verdelen. Elk van deze groepen wordt vervolgens op willekeurige wijze onderverdeeld in subgroepen, die op hun beurt weer worden onderverdeeld, enzovoort, op recursieve wijze, waardoor een willekeurig opgebouwde beslissingsboom (decision tree) ontstaat, die een isolation tree wordt genoemd.

Figuur 2: Illustratief voorbeeld van een isolation tree

Tijdens de ontwikkeling van de boom wordt een groep niet meer in subgroepen opgesplitst zodra deze nog maar één waarneming bevat. Een Isolation Forest bestaat dus uit een groot aantal van deze willekeurige bomen, met het idee dat een normale waarneming moeilijker te isoleren zou moeten zijn (en dus gemiddeld meer willekeurige verdelingen van de ruimte zou vereisen) dan een anomalie (zie Figuur 3).

Figuur 3: Voorbeeld van het isoleren van een normale waarneming (x_i) en een afwijkende waarneming (x_j) (afbeelding uit [9])

Om te bepalen of een waarneming een mogelijke anomalie is, volstaat het om te kijken op welke diepte deze in de verschillende bomen geïsoleerd is. Anomalieën zouden gemiddeld genomen vrij dicht bij de top van de bomen moeten staan, omdat ze makkelijker te isoleren zijn.

De One-Class Support Vector Machine (OCSVM) [10] is het tweede detectiemodel waar we in dit artikel naar gaan kijken. Merk op dat het algoritme dat aan de basis ligt van de OCSVM aanzienlijk minder intuïtief en gemakkelijker uit te leggen is dan isolation forest. We zullen dus niet uitgebreid ingaan op de werking ervan. We zullen het echter toch kort toelichten, omdat het een bekend klassiek model is voor detectie van anomalieën.

OCSVM probeert het gebied te vinden waar de gegevens dicht bij elkaar liggen, en de punten buiten dit gebied als afwijkend te beschouwen. Het doel van OCSVM is om de vorm van de ‘normaliteit’ te leren, om zo een grens te bepalen die de normale waarnemingen van de anomalieën scheidt. Het bijzondere aan het OCSVM-algoritme is dat het, in plaats van direct de kenmerken (features) van de waarnemingen te gebruiken om de grens tussen normale en abnormale waarnemingen te bepalen, de waarnemingen projecteert in een getransformeerde ruimte, waardoor complexe grenzen tussen normale en abnormale gegevens kunnen worden getrokken.

Illustratief voorbeeld

Om de opsporing van anomalieën te illustreren, hebben we artificiële gegevens in twee dimensies gegenereerd, bestaande uit:

• ‘Normale’ gegevens: gegenereerd volgens een normale verdeling.
• Anomalieën: willekeurig gegenereerd volgens een uniforme verdeling.

De normale gegevens en de anomalieën zijn door elkaar gemengd en we hebben daarop drie algoritmen voor het opsporen van anomalieën toegepast (OCSVM, Isolation Forest en LOF). De resultaten zijn te zien in de figuren 4 – 6:

• Figuur 4: Een enkele groep van normale waarnemingen;
• Figuur 5: Twee groepen normale waarnemingen die licht uit elkaar liggen
• Figuur 6: Twee groepen normale waarnemingen die ver uit elkaar liggen

In elk van deze grafieken worden normale waarnemingen in het wit weergegeven en anomalieën in het zwart, zodat ze visueel gemakkelijk van elkaar te onderscheiden zijn. Deze labels (normaal versus anomalie) zijn uiteraard niet aan de algoritmen meegedeeld, aangezien deze unsupervised draaien.

Voor elk van deze drie algoritmen hebben we de grens die het algoritme gebruikt om normale gegevens van anomalieën te onderscheiden, in het rood gemarkeerd. De waarnemingen in de oranje zone (binnen de grens) worden door het algoritme als normaal beschouwd, en de waarnemingen in de blauwe zone worden als anomalieën beschouwd (lichtblauw: licht afwijkend; donkerblauw: sterk afwijkend).

Figuur 4: Detectie van anomalieën met een groep normale gegevens

Figuur 5: Detectie van anomalieën met twee licht van elkaar gescheiden groepen normale gegevens

Figuur 6: Detectie van anomalieën met twee duidelijk gescheiden groepen normale gegevens

Detectie evalueren

Het is geen eenvoudige opgave om de kwaliteit van de opsporing van anomalieën te kwantificeren. Laten we beginnen met het eenvoudigste geval: als we beschikken over vooraf geïdentificeerde anomalieën (labels). In deze gevallen kan een algoritme voor het opsporen van anomalieën worden gevalideerd door te controleren of het erin slaagt de reeds bekende anomalieën terug te vinden, met behulp van klassieke maatstaven (recall, precision, F1-measure, enz.).

Zonder labels wordt het ingewikkelder. In dat geval moeten de door het algoritme geïdentificeerde waarnemingen handmatig worden gecontroleerd om te bevestigen of ze daadwerkelijk afwijkend zijn. Dit vereist niet alleen een goede kennis van het domein waaruit de gegevens afkomstig zijn, maar ook inzicht in waarom de waarneming door het algoritme als anomalie is geïdentificeerd. Aangezien er vaak een groot aantal variabelen in de gegevens zit en de grens (tussen normale en afwijkende gegevens) die door het algoritme wordt gebruikt doorgaans complex is, is het soms moeilijk te begrijpen waarom bepaalde waarnemingen door een algoritme als anomalieën zijn geïdentificeerd. Het kan dan nuttig zijn om verklaarbaarheidstools (bijvoorbeeld: SHAP, LIME) te gebruiken om de beslissingen van het algoritme te begrijpen.

Conclusie

In deze blogpost hebben we ervoor gekozen om een selectie van (unsupervised) algoritmen te presenteren die gebaseerd zijn op verschillende aanpakken (afstand, dichtheid, isolatie, enz.) om zo de grote verscheidenheid aan bestaande algoritmen te illustreren. We willen er echter op wijzen dat we geen aandacht hebben besteed aan de supervised methoden (die vaak nauwkeuriger zijn omdat ze gespecialiseerd zijn in de opsporing van vooraf gedefinieerde patronen) en de statistische benaderingen. Opsporing van anomalieën is dus een uitgebreid domein met talrijke tools. Unsupervised algoritmen bieden een grote flexibiliteit omdat ze geen labels vereisen en nieuwe vormen van anomalieën kunnen opsporen. In de praktijk is het soms handig – aangezien elk detectiealgoritme anders is – om meerdere algoritmen te combineren voor het opsporen van anomalieën om een grotere verscheidenheid aan opgespoorde anomalieën te verkrijgen.

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

Une évolution extrêmement rapide

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

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

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

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

Suivre la cadence

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

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

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

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

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

Conclusion

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

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

Références

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(Nederlandstalige tekst : zie onder)

Webinar Smals, WebEx

Koen Vanderkimpen
Smals Research

04/06/2026  10h30 – 11h45

Language: Dutch / Slides in English

Tijdens dit webinar delen we onze eigen onderzoekservaringen uit de praktijk. Aan de hand van concrete voorbeelden, bijvoorbeeld in COBOL-projecten of verouderde Java codebases, laten we zien wat helpt en waar de valkuilen liggen wanneer je AI loslaat op legacy-systemen. We bespreken gerichte strategieën voor zowel het documenteren als het stapsgewijs herschrijven van oude code, en delen praktische tips rond vibe coding in de terminal. Zo kan je beter inschatten wat je vandaag wel én niet van deze technologie mag verwachten.

Of je nu zelf aan de slag wil met het moderniseren van een oude toepassing of simpelweg beter wil begrijpen hoe AI als een slimme gereedschapskist kan bijdragen aan het beheer van bestaande codebases: dit webinar helpt je om een voorzichtige eerste start te maken en schept een realistisch beeld van wat AI vandaag wel én nog niet voor je kan oplossen.

De sessie wordt in het Nederlands gehouden, met Engelstalige slides.

Aujourd’hui déjà, les grands modèles de langage (LLM) et les assistants IA permettent de réaliser des gains de productivité considérables lors de l’écriture de nouveaux logiciels. Mais qu’en est-il du code legacy ? Les applications plus anciennes, souvent critiques, basées sur des architectures obsolètes ou des technologies dépassées, constituent un tout autre défi. L’IA offre-t-elle également une aide suffisante pour comprendre et moderniser ces systèmes existants

Au cours de ce webinaire, nous partagerons nos propres expériences pratiques. À l’aide d’exemples concrets, par exemple dans des projets COBOL ou des bases de code Java vieillissantes, nous montrerons ce qui fonctionne et quels sont les pièges lorsque l’on applique l’IA à des systèmes legacy. Nous aborderons des stratégies ciblées, à la fois pour la documentation et pour la réécriture progressive de code ancien, et partagerons des conseils pratiques autour du vibe coding dans le terminal. Vous pourrez ainsi mieux évaluer ce que vous pouvez attendre ou non de cette technologie aujourd’hui.

Que vous souhaitiez vous lancer dans la modernisation d’une ancienne application ou simplement mieux comprendre comment l’IA, en tant que boîte à outils intelligente, peut contribuer à la gestion des bases de code existantes, ce webinaire vous aidera à faire vos premiers pas en toute prudence et vous donnera un aperçu réaliste de ce que l’IA peut et ne peut pas encore résoudre pour vous aujourd’hui.

La session est tenue en néerlandais, avec des slides en anglais.

Recording

Presentation

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

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

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

Définitions

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

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

On distingue deux courants de jumeaux numériques :

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

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

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

Projets phares

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

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

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

Use Cases administratifs

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Conclusion

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

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

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

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

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

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

Introduction

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.

Il est intéressant de noter que, bien que ces deux domaines soient liés, la détection d’anomalies se distingue des outils de qualité des données (data quality), tels que Trillium et Open Refine. En data quality, on cherche plutôt à retrouver des soucis de données incomplètes/invalides sur bases de règles, là où la détection d’anomalies cherche à détecter des patterns rares/inhabituels (qui s’écartent/dévient de la « normalité »), mais pas forcément invalides d’un point de vue data quality.

Les différents types d’anomalies

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

• L’anomalie ponctuelle

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

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

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

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

• L’anomalie contextuelle

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

• L’anomalie collective/anomalie de groupe

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

Les méthodes de détection

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

Quel type d’apprentissage ?

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

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

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

Quelques algorithmes classiques de détection d’anomalies

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

Les détecteurs sans modèles

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

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

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

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

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

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

Les modèles de détection

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

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

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

Figure 2 : Exemple illustratif d’isolation tree

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

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

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

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

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

Exemple illustratif

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

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

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

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

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

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

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

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

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

Evaluer la détection

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

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

Conclusion

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

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

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

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

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

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

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

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

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

[9] : Isolation forest – Wikipedia

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

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.

Use Case 1 : Simulatie van beleid en uitvoeringsimpact

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

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

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

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

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

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

Use Case 2 : Organisatorische planning in de gezondheidszorg

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

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

Implementatie: een kostelijke affaire?

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

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

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

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

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

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

Conclusie

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

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

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

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.