(FR) Le 12 juin 2026, le gouvernement américain a émis une directive de contrôle des exportations sans précédent (interdisant l’utilisation par des citoyens non américains) qui a contraint Anthropic à suspendre l’accès à ses derniers modèles d’IA dans le monde entier.
De telles décisions suscitent naturellement de vives réactions et replacent le thème de la souveraineté numérique et de l’IA au cœur des débats. Comment nous protéger contre de telles décisions géopolitiques ? Katy Fokou de Smals Research partage sa vision sur la souveraineté de l’IA et examine les solutions pour mieux nous protéger face à la dépendance étrangère et aux décisions politiques imprévisibles.

Regardez et écoutez ici pour en savoir plus. Des sous-titres sont disponibles.
Attention : cette entretien a été enregistrée avant la directive américaine du 12 juin 2026.

(NL) Op 12 juni 2026 vaardigde de Amerikaanse overheid een ongekende exportcontrole-richtlijn uit (verbod van gebruik door niet-Amerikaanse staatsburgers) die Anthropic dwong om de toegang tot zijn nieuwste AI-modellen wereldwijd op te schorten.
Dergelijke beslissingen lokken begrijpelijkerwijs sterke reacties uit en plaatsen het thema digitale en AI-soevereiniteit opnieuw centraal op de agenda. Hoe wapenen we ons tegen dergelijke geopolitieke besluiten? Katy Fokou van Smals Research deelt haar visie op AI-soevereiniteit en bespreekt welke oplossingen er bestaan om ons beter te beschermen tegen buitenlandse afhankelijkheid en onvoorspelbare beleidskeuzes.

Kijk en ontdek het hier. Ondertitels zijn beschikbaar.
Opgelet: deze talk werd opgenomen vóór de Amerikaanse richtlijn van 12 juni 2026.

(EN) On June 12, 2026, the U.S. government issued an unprecedented export control directive (prohibiting use by non-U.S. citizens) that forced Anthropic to suspend access to its latest AI models worldwide.
Such decisions understandably provoke strong reactions and place the theme of digital and AI sovereignty back at the center of the agenda. How do we protect ourselves against such geopolitical decisions? Katy Fokou of Smals Research shares her vision on AI sovereignty and discusses solutions to better protect us against foreign dependency and unpredictable policy decisions.

Watch and listen here to find out. Subtitles are available.
Note: This talk was recorded prior to the U.S. directive of June 12, 2026.

Il y a presque un an nous avons publié deux articles sur l’IA générative (IAGén) et la sécurité du code [1], [2] et nous avions conclu en soulignant que la plupart des études que nous avions rencontrées montraient des performances incohérentes et une tendance générale à des taux élevés de faux-positifs, dans la détection des failles de sécurité. Mais l’évolution des outils est rapide dans ce domaine. Les agents d’IA combinant un modèle de langage avec des outils d’analyse statique, une mémoire, et une forme de « raisonnement » structuré, ont commencé à découvrir des vulnérabilités dans des logiciels que des décennies de tests automatisés et de revues humaines n’avaient pas détectées.

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’IAGén 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

Bijna een jaar geleden publiceerden we twee artikels over generatieve AI (GenAI) en codeveiligheid [1], [2] en sloten we af met de bemerking dat de meeste studies die we hadden bekeken inconsistente performantie aantoonden en een algemene tendens tot hoge percentages vals positieven lieten zien bij de opsporing van veiligheidslekken. De tools in dit domein evolueren echter snel. AI-agenten die een taalmodel combineren met tools voor statische analyse, een geheugen en een vorm van gestructureerd “redeneren”, zijn kwetsbaarheden gaan ontdekken in software die decennia van geautomatiseerde tests en menselijke beoordelingen niet hadden opgemerkt.

Een extreem snelle evolutie

Vanaf november 2024 [3], en vervolgens opnieuw in juli 2025 [4] heeft het “Big Sleep”-systeem van Google twee belangrijke kwetsbaarheden ontdekt in de SQLite-software, die nochtans grondig getest en op grote schaal gebruikt wordt. Begin 2026 ging de start-up AISLE nog een stap verder: door gebruik te maken van GenAI-modellen in combinatie met zijn eigen analyse-infrastructuur, ontdekte het 12 “zero-day”-kwetsbaarheden – waaronder een kritieke kwetsbaarheid [5], evenals bugs die teruggaan tot code uit de jaren 1990 – in de OpenSSL-library, die nochtans uitgebreid was gecontroleerd [6]. AISLE heeft ook een groot aantal kwetsbaarheden gemeld in meer dan tien gevestigde projecten, waaronder Apache, Chromium, Firefox, de Linux-kernel, OpenVPN en Samba. In maart 2025 ontdekte de tool “Security Copilot” van Microsoft kwetsbaarheden in GRUB2 en U-Boot (bootloaders die door de meeste Linux-systemen worden gebruikt). , georganiseerd door het Amerikaanse agentschap voor geavanceerde defensieonderzoeksprojecten (DARPA), hebben zeven AI-systemen autonoom 54 miljoen regels code doorgenomen, het merendeel van de ingebouwde synthetische kwetsbaarheden opgespoord en 18 tot dan toe onbekende bugs aan het licht gebracht [7], [8].

Deze demonstraties, hoe indrukwekkend ook, hebben meer te maken met de infrastructuur die rond de GenAI is opgezet (integratie van tools, koppelingen met bestaande software voor statische analyse, iteratieve planningscycli) dan met de ruwe performances van de modellen [2]: wat hier dus doorslaggevend is, is het ontwerp van het systeem, in plaats van de capaciteit van het model op zich.

Op de conferentie “CyberSec Europe 2026”, kwam, naast het woord “soevereiniteit” dat al sinds de vorige conferentie steeds weer werd herhaald, ook het woord “Mythos” voor na de meesterlijke marketingzet van het bedrijf Anthropic [9], [10], dat overigens niet aan zijn proefstuk toe is [11]. Op 7 april 2026 verklaarde het bedrijf Anthropic namelijk in zijn aankondiging van de terbeschikkingstelling van “Claude Mythos Preview” – voorbehouden aan een beperkt aantal bedrijven – dat Mythos zelfstandig duizenden “zero-day”-kwetsbaarheden in kritieke software-infrastructuren had geïdentificeerd, een oude OpenBSD-bug had ontdekt en in staat was geweest vier kwetsbaarheden aan elkaar te koppelen om een werkende browser exploit te creëren. Onafhankelijke onderzoeken zijn op dit moment vrijwel onbestaande en alleen het Britse Instituut voor AI-beveiliging (AISI) – een overheidsinstantie die AI-systemen voor en na de implementatie ervan beoordeelt – heeft Mythos Preview kunnen evalueren en bevestigd dat het in 3 van de 10 gevallen een meerstapsaanvalssimulatie op een bedrijfsnetwerk tot een goed einde kon brengen – een scenario dat voor een gekwalificeerde menselijke professional naar schatting 20 uur werk zou vergen [12], [13].

Maar deze bevindingen zijn niet uniek voor Mythos. De door Mythos ontdekte kwetsbaarheden konden ook worden gevonden door het bedrijf AISLE met behulp van goedkopere en kleinere modellen, waarvan de gewichten openbaar zijn en die op consumentenhardware kunnen worden uitgevoerd [10], [14]. . Los daarvan heeft het AISI vastgesteld dat ook het GPT-5.5-model in staat was om een simulatie van een aanval op een bedrijfsnetwerk uit te voeren [15].  Tijdens haar evaluatie heeft de AISI ook een “universele” techniek geïdentificeerd om de veiligheidsbeperkingen van het model te omzeilen, waarbij zij erop wees dat veiligheidsmaatregelen die het gedrag van het model [16] voorschrijven, waarschijnlijk niet zo effectief zijn als architecturale beperkingen.

Bijbenen

Gezien de steeds snellere ontdekking van nieuwe kwetsbaarheden wordt het absoluut noodzakelijk om de pijplijnen voor software-oplossingen te versnellen, met name bij componenten met kritieke externe afhankelijkheden [17]. Het voorbeeld van OpenSSL in januari 2026 laat zien dat geautomatiseerde audits inmiddels een tweesnijdend zwaard zijn dat zowel voor onderzoekers als voor criminelen en overheidsactoren toegankelijk is [18].

Terwijl het aantal CVE’s explosief toeneemt – met een stijging van 263 % tussen 2020 en 2025 – dreigt dit de traditionele correctiecapaciteiten in de meeste organisaties te overbelasten [19], [20]. In zijn aankondiging gaf Anthropic toe dat minder dan 1 % van de door Mythos gevonden kwetsbaarheden gecorrigeerd werd. Het op grote schaal opsporen van kwetsbaarheden zonder deze op dezelfde schaal te corrigeren, leidt alleen maar tot een langere lijst van blootstellingen, maar geen hogere veiligheid. In deze context zullen alleen organisaties die vooraf een autonome en flexibele infrastructuur voor het corrigeren van kwetsbaarheden hebben opgezet, erin slagen hun blootstellingsperiode te verkorten, daar waar handmatige methoden het tempo dat door AI wordt opgelegd niet meer kunnen bijbenen [20], [21].

Terwijl AI-tools, ondanks hun “hallucinaties” [22], tal van nieuwe mogelijkheden bieden voor aanvallers, is de indruk die naar voren komt uit conferenties als CyberSec Europe 2026 of Black Hat Europe 2025 gelukkig dat de verdediging voorlopig nog de overhand lijkt te hebben [23], [24]. De markt voor veiligheidstools voor bedrijven groeit snel en deze tools proberen het werk van analisten te vergemakkelijken. Zo omvat de tool “Security Copilot” van Microsoft de triage van waarschuwingen, het optimaliseren van toegangspolicy’s en het onderzoeken van gegevensbeveiliging, en zou deze het aantal waarschuwingen per incident aanzienlijk kunnen verminderen en conflicten met betrekking tot veiligheidspolicy’s sneller kunnen oplossen. De geautomatiseerde triage van waarschuwingen afkomstig uit het beheer van gebeurtenissen en veiligheidsinformatie (SIEM) via agentgebaseerde orchestration-tools, automatisering en respons voor beveiliging (SOAR) zou toelaten om de benodigde behandelingstijd per incident significant te verlagen [25]. Meer in het algemeen wijzen onderzoeken op een aanzienlijke vermindering van het aantal valse positieven bij waarschuwingen wanneer GenAI wordt ingezet als contextuele triagelaag bovenop traditionele statische analysetools [26].

Het opsporen en corrigeren van kwetsbaarheden is niet de enige invloed van AI op de veiligheid. Door de automatisering van cyberaanvallen via AI kunnen aanvallers met een ongekende snelheid opereren — tot wel 3.600 keer sneller dan mensen — terwijl ze tegelijkertijd een veel groter aantal activa aanvallen [20]. Gezien een ‘operationeel tempo’ waarbij de mediane tijd tussen publicatie en exploitatie is gedaald tot slechts 5 dagen [27], zijn handmatige of lineaire responsmodellen inmiddels achterhaald en niet meer in staat om deze hoogfrequente aanvallen in te perken [20]. Deze ontwikkeling vereist een herziening van de incidentresponshandleidingen (“playbooks”).

Ten slotte brengt ook het gebruik van AI voor (min of meer) productieve doeleinden een reeks veiligheidsproblemen met zich mee binnen bedrijven. Het is belangrijk om precies vast te stellen waar AI binnen een infrastructuur wordt ingezet om de gegevensbeveiliging te waarborgen. Het fenomeen van “shadow AI” — dat gedefinieerd wordt als het gebruik van AI-tools zonder goedkeuring of toezicht van de IT-afdeling – vormt een aanzienlijk risico. Hieronder vallen modellen die via persoonlijke accounts toegankelijk zijn, AI-functionaliteiten die zonder expliciete aankoop zijn geïntegreerd in Software-as-a-Service (SaaS) van derden, of “open-source”-modellen die door programmeurs worden gebruikt buiten elk governanceproces [28] om. Een organisatie kan geen perimeter verdedigen die zij niet heeft gedefinieerd, en het huidige gebrek aan overzicht leidt tot kritieke kwetsbaarheden: naar schatting 91 % van de AI-tools binnen bedrijven zou buiten de controle van het IT-management om functioneren [29]. Zonder een gecentraliseerde inventarisatie en continu toezichtbeleid lopen bedrijven echter het risico op aanzienlijk hogere kosten als gevolg van datalekken [30].

Conclusion

Beveiligingstools op basis van AI zijn in zeer korte tijd van de onderzoeksfase naar operationele toepasbaarheid geëvolueerd, aan beide kanten van het spectrum: terwijl de offensieve capaciteiten van AI de drempel voor middelgrote criminele actoren hebben verlaagd en schaalbaardere inbraakcampagnes mogelijk hebben gemaakt, bevatten de defensieve toepassingen – filteren van waarschuwingen, opsporen van kwetsbaarheden, filteren van valse positieven, autonome penetratietests – AI-functionaliteiten en bieden ze verbeteringen ten opzichte van eerdere generaties. De implementatie van door AI versterkte defensieve workflows markeert een belangrijke overgang in safety engineering.

De uitdaging is niet langer de opsporing, maar de correctie.

Références

[1]          F. A. P. Petitcolas, “AI om de veiligheid van de code te verbeteren? (Deel 1: veiligheid van de gegenereerde code)”, Smals Research, 30 juli 2025. Beschikbaar op: https://www.smalsresearch.be/ai-om-de-veiligheid-van-de-code-te-verbeteren-deel-1-veiligheid-van-de-gegenereerde-code/

[2]          F. A. P. Petitcolas, “AI om de veiligheid van code te verbeteren? (Deel 2: opsporing van kwetsbaarheden)”, Smals Research, 26 aug. 2025. Beschikbaar op: https://www.smalsresearch.be/ai-om-de-veiligheid-van-code-te-verbeteren-deel-2-opsporing-van-kwetsbaarheden/

[3]          R. Lakshmanan, « Google’s AI Tool Big Sleep Finds Zero-Day Vulnerability in SQLite Database Engine », The Hacker News, 11 nov. 2024. Beschikbaar op: 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, juli 2025. Beschikbaar op: https://nvd.nist.gov/vuln/detail/CVE-2025-6965

[5]          “NVD – CVE-2025-15467”, CVE-2025-15467, jan. 2026. Beschikbaar op: 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. Beschikbaar op: 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 aug. 2025. Beschikbaar op: 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 aug. 2025. Beschikbaar op: 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. Beschikbaar op: 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 apr. 2026. Beschikbaar op: https://www.schneier.com/news/archives/2026/04/claude-mythos-is-mostly-marketing-hype.html

[11]       F. Tréguer, “Anthropic, Silicon Valley’s conscience?”, Le Monde diplomatique, 1 mei 2026. Beschikbaar op: https://mondediplo.com/2026/05/12anthropic

[12]       “Our evaluation of Claude Mythos Preview’s cyber capabilities | AISI Work”, AI Securty Institute (AISI), apr. 2026. Beschikbaar op: 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 mar. 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 apr. 2026. Beschikbaar op: 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. Beschikbaar op: https://www.aisi.gov.uk/blog/our-evaluation-of-openais-gpt-5-5-cyber-capabilities

[16]       B. Vanhalst, “Guardrails: hou je AI binnen de lijntjes”, Smals Research, 27 nov. 2025. Beschikbaar op: https://www.smalsresearch.be/guardrails-hou-je-ai-binnen-de-lijntjes/

[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 feb. 2026. Beschikbaar op: 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 apr. 2026. Beschikbaar op: 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, mei 2026. Beschikbaar op: 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 mei 2026. Beschikbaar op: 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. Beschikbaar op: 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. Beschikbaar op: https://www.security.com/expert-perspectives/inside-defenders-ai-advantage

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

[25]       TrendAI, “Experience the AI security revolution”, 22 mei 2026.

[26]       X. Du et al., “Reducing False Positives in Static Bug Detection with LLMs: An Empirical Study in Industry”, 26 jan. 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 mar. 2026. Beschikbaar op: 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. Beschikbaar op: 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 apr. 2026. Beschikbaar op: 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. Beschikbaar op: https://www.gartner.com/document-reader/document/7145930

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.

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.

Dit artikel is ook beschikbaar in het Nederlands.

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

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

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

“Ancien” code : une multitude de possibilités

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

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

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

Utilisation des LLM sur des bases de code legacy

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

Réécriture du code legacy

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

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

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

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

Documentation du code legacy

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

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

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

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

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

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

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

Conclusion : professionnels recherchés

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

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

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

Cet article est aussi disponible en français.

Sinds de hype van grote taalmodellen is losgebarsten, zullen de meeste ontwikkelaars ondertussen al wel geproefd hebben van de productiviteitswinst die deze tools, mits correct gebruik, kunnen bieden. In deze blog onderzoeken we of we verder kunnen gaan dan dat: biedt AI ook voldoende hulp bij het beheersen van Legacy Code?

Het inzetten van Large Language Models (LLM) bij het programmeren is inderdaad ondertussen stilaan goed gekend: het gaat van vragen stellen aan een chatbot (“hoe schrijf ik in Java een algoritme dat … “), overheen steeds slimmere en langer wordende code completion (automatisch aanvullen wat je wil typen in de editor), tot volledige vibe coding (in de IDE, of zelfs gewoon in een terminal): AI agenten, via prompts, hele stukken code – ja, zelfs werkende toepassingen – laten schrijven op je machine.

In een vorige post rond legacy code, gaven we een erg brede definitie. Laten we dus vooreerst iets duidelijker stellen wat we met Legacy bedoelen, en de “moeilijkheidsgraad” van Legacy projecten beter illustreren.

“Oude” code: een spectrum aan mogelijkheden

Er is niet echt een officiële definitie van legacy code; meestal spreekt men van het gebruik van niet langer ondersteunde technologie, moeilijk te onderhouden, of simpelweg “code die je van iemand anders erft”. Het gaat uiteraard altijd wel om code die nog in gebruik, en dus belangrijk is. Ironisch genoeg, zijn het vaak de meest kritische toepassingen, die al jaren meegaan en waar men al jaren “op vertrouwt”, maar dan zonder ze goed te onderhouden.

AI kan ons helpen bij het onderhoud van eender welke code, dus we zullen een spectrum demonstreren dat van de oudste, ergste legacy code gaat, tot code van projecten die slechts een kleine update nodig heeft. Aan de ene kant van het spectrum heb je programma’s, geschreven in ouderwetse programmeertalen, volgens een achterhaalde architectuur, gebruik makend van databases die niet meer van deze tijd zijn, en draaiende op servers met niet langer ondersteunde besturingssystemen: bij deze mastodonten moet men vaak bang zijn dat ze kritisch zullen falen bij de kleinste verkeerde wijziging. Helemaal aan de andere kant heb je vrij goed onderhouden software, waarin een softwarebibliotheek wordt gebruikt die niet meer de meest recente versie is: meestal een koud kunstje om ze weer helemaal up-to-date te krijgen. Ergens in het midden vind je, ten slotte, toepassingen terug waarbij de meeste developers nog niet meteen het woord Legacy in de mond zullen nemen, maar waar wel moeilijke migraties dienen te gebeuren, met b.v. een verouderd framework of twee dat zou moeten worden vervangen.

Wat kunnen we hier nu mee? Bieden LLMs ons andere mogelijkheden naargelang de plaats van het project op dit spectrum? Ons onderzoek heeft zich tot nu toe op de linkerkant van dit spectrum gefocust, dus het vervolg van deze blogpost zal veeleer over de mogelijkheden gaan om “échte” Legacy aan te pakken. Later dit jaar gaan we ook verder uitdiepen wat we met migraties en updates kunnen doen.

Gebruik van LLMs op Legacy Codebases

Het is duidelijk dat de eenvoudige prompt “herschrijf mij dit programma volgens moderne standaarden” niet zal werken (al beweren sommige vendors dat dit eraan zit te komen). We zullen iets concretere zaken gaan vragen, en het werk ook enigszins in stukjes moeten kappen. Verder zijn er eigenlijk twee zaken die we kunnen gaan doen met onze legacy code: ze herschrijven en ze documenteren.

Herschrijven van Legacy Code

Als we beginnen met code herschrijven, zullen we er vaak rekening mee moeten houden dat een heel groot project voldoende goed herbouwen een te moeilijke opgave is. We kunnen “quick wins” behalen door strategisch een aantal zaken te gaan herschrijven van een project, en die stukken dan te gebruiken in een ruimere context, waarbij een team van mensen en AI de toepassing opnieuw bouwen volgens de regels van de kunst. Bij onze experimenten stelden we vast dat het een brug te ver was om van het AI te verwachten een volledig nieuwe architectuur te gebruiken, tegelijk met het vertalen van oude code naar nieuwe. Wat wel mogelijk is, is om heel wat van de typische scaffolding (de standaardcode om tot iets werkend te komen) van een nieuw project te vibe coden, en daar dan gericht een aantal stukken code in te injecteren die vertalingen zijn van stukjes van een legacy project. Als mens is het onze taak om duidelijk aan te geven welke architectuur we verwachten, en wat de kwaliteitsregels zijn van de nieuw geschreven code.

Eén van de grotere uitdagingen bij het herschrijven van code met behulp van AI, is het testen van de correctheid van de vertaling: doet de code nog wat ze vroeger deed (los van het feit of dit wenselijk is, want zelfs de business case kan soms te verouderd zijn in geval van Legacy)? Bij redelijk nieuwe projecten zullen er reeds heel wat testen bestaan die we kunnen uitvoeren om de correctheid na te gaan, maar bij legacy hebben we vaak het probleem dat de toepassing eenvoudigweg wordt getest in productie, of op zijn minst met productiedata: er zijn geen specifieke tests of zelfs maar veilig bruikbare testdata. In dat geval komt het erop neer een omgeving te creëren waarin we de nieuwe code op een veilige manier kunnen testen, wat meestal ad hoc werk is en enige creativiteit vraagt. We mogen namelijk geen productiedata naar de Cloud sturen, dus we moeten ervoor zorgen dat het LLM deze niet kan lezen. Het zou eenvoudiger zijn als we lokaal draaiende LLMs zouden kunnen gebruiken, maar voorlopig zijn deze nog niet krachtig genoeg (als ze al beschikbaar zijn) om dergelijke complexe taken uit te voeren met legacy code.

Een andere uitdaging is de gebruikersinterface: bij oudere projecten is deze vaak achterhaald en moet er, vanaf de grond, een nieuwe GUI (Graphical User Interface) worden opgebouwd. Dat geeft echter het probleem dat je geen basis meer hebt in het oude project om mee te vergelijken: de nieuwe interface zal doorgaans manueel door mensen moeten worden getest. Ik verwacht echter dat we op dit vlak nog vorderingen zullen zien in de nabije toekomst, wat de mogelijkheden van het AI betreft. We zien namelijk al systemen opduiken die je volledige computer kunnen besturen (zoals OpenClaw of het “Computer Use” van Anthropic), en ook integratie met meer traditionele raamwerken voor het testen van een GUI behoort tot de mogelijkheden.

Waar we, ten slotte, ook quick wins mee kunnen halen, zijn kleinere Legacy projecten. Als we een klein tot matig groot legacy programma gebruiken, met beperkte functionaliteit en een eenvoudige GUI of een duidelijke input en output in geval van batch processing, en geen business case om deze te integreren in een andere manier van werken, dan kunnen we een rechttoe rechtaan aanpak proberen om een moderne versie in een nieuwe programmeertaal te bouwen met AI. We moeten dan nog altijd goed testen en een gestructureerde aanpak hebben met bijsturingen door menselijke developers, maar het wordt wel feasible om dit voor niet-kritische toepassingen te gaan uitproberen. Een intern gebruikte toepassing is bijvoorbeeld een typische goede eerste kandidaat.

Documenteren van Legacy Code

Soms is herschrijven van Legacy met AI net iets te ambitieus, óf we hebben meer informatie nodig voor we er ons aan wagen. In dat geval kan het interessant zijn om eerst richting documentatie te kijken: het AI kan ons ook helpen om het verkennen van een legacy codebase net iets minder op archeologie voor gevorderden te doen lijken.

Van een klein tot matig stuk code uitleggen en er de business logica uithalen, of een groter stuk analyseren en de opbouw en architectuur uitleggen: dat kan met de huidige grote taalmodellen zonder meer. We kunnen echter verder gaan: we kunnen het AI tools laten bouwen om zichzelf te helpen de codebase te verkennen, en b.v. diagrammen te voorzien van de afhankelijkheden tussen de stukken code. Of we kunnen het scripts laten maken om de bevindingen na elk stuk analyse netjes te structureren in een tekstbestand voor zichzelf en een pdf voor de menselijke gebruiker.

We kunnen ook hiërarchisch werken: eerst een verkenning van de codebase doen, en dan telkens dieper duiken in de verschillende modules, om meer en meer detail te verkrijgen en de analyse aan te vullen. Dat is de top-down aanpak, die we echter kunnen aanvullen met een bottom-up versie: eens we tot in de diepte zijn gegaan, kunnen we weer zaken laten samenvatten om van het grotere plaatje een beter geïnformeerde uiteenzetting op te bouwen.

Hier is het wel van belang dat we van tevoren weten wat we precies willen bereiken. Een algemene analyse van een codebase door het AI kan interessant zijn wanneer de menselijke gebruikers het systeem nog totaal niet kennen en aanknopingspunten willen hebben om zaken te leren, maar biedt meestal weinig extra aan mensen die de codebase reeds beheersen.

Maar wanneer het doel is om de codebase te kunnen onderhouden, kunnen we eventueel een systeem opbouwen waarbij we een chatbot aanbieden die de specifieke context en bijzonderheden van het legacy project kent, en daar heel gerichte vragen over kan beantwoorden. Dit kan b.v. in CoPilot Studio. Wanneer dat niet goed genoeg werkt, kunnen we nog overwegen om manueel een knowledge base op te bouwen, gebruik makend van het AI, die dan weer door het AI kan worden gebruikt om vragen te beantwoorden.

Nog een andere optie bestaat eruit dat we specifieke informatie uit de codebase willen extraheren, zoals de business logica per afzonderlijke module, of pseudocode die menselijke developers kan helpen om de logica in een ander project te herimplementeren. (En uiteraard kan bij die tweede stap ook weer een AI worden ingezet.)

Kortom, met een beetje creativiteit kunnen we voor de meeste ad hoc analyses een betere aanpak verzinnen dan “analyseer er maar gewoon op los”. En het documenteren van een legacy systeem kan ook gewoon een eerste opstap zijn naar het herschrijven.

Besluit: vakmannen gevraagd

Zoals we hebben aangekaart, bieden LLMs ons stilaan erg krachtige mogelijkheden om onze Legacy Codebases aan te pakken, zéker wanneer we toegang hebben tot de grote en krachtige modellen die vandaag beschikbaar zijn. We zien echter ook dat het eigenlijk een heel goed gevulde gereedschapskoffer is, met een aantal krachtige “power tools”, en dat we moeten weten wat we ermee willen bereiken en hoe we deze best kunnen gebruiken.

We zitten nog niet op het punt dat alles automatisch gaat: we zullen dus nog steeds goede vakmannen nodig hebben om optimaal van dit gereedschap gebruik te maken. Onze raad aan developers is om zeker niet bang te zijn van AI en er geregeld gebruik van te maken bij de analyse en ontwikkeling van software: ervaring is de beste leerschool om de goede vakmannen die we hiervoor nodig hebben, op te leiden.

Voorlopig is dus het besluit: voor legacy code is AI geen wondermiddel, maar een handige gereedschapskist die je best kan uitproberen als deel van een bredere aanpak. Zoals gezegd kijken we later dit jaar eerder naar het midden en de rechterkant van het spectrum van legacy. Wij vermoeden dat hier meer mogelijkheden zijn tot automatisering van een aantal workflows, zeker als we ook dieper gebruik gaan maken van agents. Mogelijks kunnen we, voor iets eenvoudigere en repetitievere projecten, dus toch van “vakman” naar “fabriek” evolueren.

Het opmerkelijke meertalige potentieel van grote taalmodellen (LLM’s) heeft bijgedragen aan de brede verspreiding en integratie ervan binnen AI-gebaseerde toepassingen. Er bestaan echter prestatieverschillen tussen het Engels en andere talen, met name talen met beperkte middelen.

Bij de evaluatie van een door ons ontwikkelde RAG-chatbot stelden we een duidelijk verschil vast in de kwaliteit van de antwoorden, afhankelijk van de gebruikte taal. De chatbot leverde namelijk betere antwoorden in het Frans dan in het Nederlands. De in het Frans gegenereerde antwoorden waren vlotter en betrouwbaarder ten opzichte van de door de gebruiker gevraagde informatie. De antwoorden in het Nederlands waren over het algemeen minder relevant. Deze resultaten wijzen op een cruciale uitdaging bij de ontwikkeling van LLM’s die door chatbots worden gebruikt: hoewel deze indrukwekkende meertalige capaciteiten hebben, vertonen de huidige modellen vaak een uitgesproken voorkeur voor talen met veel middelen, zoals het Engels.

In deze blogpost beschrijven we de resultaten van ons onderzoek naar de door ons vastgestelde taalkloof en tonen we de bevindingen van ons onderzoek.

Prestatieverschil tussen het Engels en de andere talen: oorzaken en factoren

Verschillende factoren dragen bij aan de taalvoorkeur voor het Engels. Deze omvatten:

• Onevenwichtige datasets: het trainingsproces van grote taalmodellen is gebaseerd op omvangrijke tekstcorpora, maar deze worden sterk gedomineerd door het Engels, gevolgd door talen met veel taalkundige middelen zoals het Chinees, het Frans en het Spaans. Daarentegen zijn de data in talen met beperkte middelen vaak van mindere kwaliteit vanwege het beperkte aantal bronnen. Dit onevenwicht in de data leidt tot slechte prestaties in andere talen dan het Engels, met hogere foutpercentages en hallucinaties tot gevolg. Om dit probleem op te lossen, maken modelontwikkelaars gebruik van een techniek die “interlinguïstische overdracht” genoemd wordt. Hierbij verbetert een model zijn prestaties in minder goed uitgeruste talen door universele of gedeelde taalkundige patronen af te leiden uit talen met veel middelen. Hoewel het exacte percentage Engelstalige data in propriëtaire modellen niet openbaar bekend is, is 93% van de data die worden gebruikt om GPT-3 te trainen in het Engels. Leveranciers van grote taalmodellen, zoals OpenAI en Google, maken vaak gebruik van het Common Crawl-webgegevensarchief, dat zelf wordt gekenmerkt door een dataset waarin het Engels overheerst (44% in het Engels, 4% in het Frans, 2% in het Nederlands). Deze vertekening wordt nog versterkt in gespecialiseerde domeinen zoals financiën en gezondheidszorg, waar hoogwaardige data bijzonder schaars is. Het is belangrijk op te merken dat het Nederlands wordt beschouwd als een taal met hoge middelen in het domein van automatische natuurlijke taalverwerking (NLP), hoewel het over minder middelen beschikt dan het Frans of het Engels.
• Morfologie en tokenisatie: modelarchitecturen zijn vaak geoptimaliseerd voor het Engels. Tokenisatieprocessen kunnen ingewikkeld zijn voor talen die niet met het Latijns alfabet worden geschreven, zoals het Chinees of het Japans, alsook voor talen met een gemiddelde tot hoge morfologische complexiteit, zoals het Nederlands. Engelse tokenizers kunnen het moeilijk hebben met het verwerken van samengestelde woorden (de combinatie van meerdere zelfstandige naamwoorden in een woord), wat kan leiden tot grammaticaal foute resultaten wanneer modellen tekst genereren.

Zeer weinig studies hebben de prestaties geanalyseerd van grote taalmodellen in het Frans en het Nederlands. Een onderzoek naar de taalkundige kwaliteit van LLM’s in deze twee talen bracht aan het licht dat de prestaties algemeen beter waren in het Frans dan in het Nederlands, in het bijzonder bij taken waarbij tekst moest worden gegenereerd [1]. Een ander onderzoek rapporteerde betere prestaties van LLM’s in het Engels in vergelijking met het Nederlands bij een vraag-antwoordtaak [2].

In de industrie blijven er grote uitdagingen bestaan met betrekking tot de toepassing van grote taalmodellen op niet-Engelse technische domeinen, met name in de medische en financiële sector. De huidige implementaties vereisen vaak een verfijning van de vooraf getrainde modellen zoals Mistral en Llama om bevredigende prestaties te bereiken.

Een andere bekende uitdaging bij de toepassing van AI-modellen in de Nederlandse taalomgeving is spraakherkenning. Dit is grotendeels een gevolg van de grote variatie in regionale accenten. Onze experimenten met het transcriberen van opnames van Teams-vergaderingen hebben aangetoond dat de Franse transcripties systematisch van betere kwaliteit waren dan de Nederlandse. Gespecialiseerde tools zoals Sembly leveren echter acceptabele transcriptieresultaten in het Nederlands.

Vergelijkende analyse van de prestaties van het Nederlands en het Frans in een chatbot

Er is een vergelijkende analyse van de prestaties uitgevoerd op een chatbot die is ontwikkeld om vragen van burgers te beantwoorden. Voor de eerste evaluatie van de chatbot hebben we een reeks vragen gebruikt die door experts zijn opgesteld. Deze vragen werden in het Frans en het Nederlands aan de chatbot voorgelegd, waarna de antwoorden door dezelfde expert werden beoordeeld en door twee andere personen werden gecontroleerd. Uit de eerste evaluatie blijkt een aanzienlijk verschil in prestaties tussen de twee talen: de chatbot behaalde een nauwkeurigheid van 95% in het Frans, tegenover 82% in het Nederlands.

Na de implementatie van de chatbot in een productieomgeving werd een tweede evaluatiefase uitgevoerd op basis van vragen die door gebruikers waren ingediend en in een database waren opgeslagen. We merkten opnieuw een verschil in prestaties: 82% nauwkeurigheid in het Frans en 69% in het Nederlands.

Verschillende factoren kunnen bijdragen aan deze waargenomen verschillen, waaronder:

• de vooringenomenheid van de beoordelaars – beoordelaars zijn minder of meer streng in hun beoordelingen;
• de variatie in het soort vragen (dubbelzinnig, slecht geformuleerd, niet ter zake) – dezelfde vragen werden niet systematisch in beide talen beoordeeld;
• het kwaliteitsverschil bij het ophalen van de bronnen (retrieval) – er zijn verschillen tussen de talen in de data-bronnen die worden opgehaald om de generatie te voeden;
• de intrinsieke capaciteiten van het generatieve model (GPT-4o) in beide talen.

Er was dus aanvullend onderzoek nodig om de waargenomen verschillen in het Frans en het Nederlands volledig te begrijpen en deze factoren te verminderen.

Test

Om de prestaties van LLM’s in zowel het Frans als het Nederlands grondig te evalueren, werd een experiment uitgevoerd met de chatbot. We selecteerden een aantal vragen waarvan de eerdere antwoorden van LLM’s als onjuist waren beoordeeld, waarbij we ervoor zorgden dat de vragen niet te complex of te simplistisch waren. Het was van cruciaal belang dat elke vraag van een gebruiker tussen het Frans en het Nederlands werd vertaald om een directe vergelijking te vergemakkelijken. Bij het evaluatieproces waren twee onafhankelijke evaluatoren betrokken, een vakexpert en een technisch expert, om vooringenomenheid te beperken en een robuuste evaluatie te garanderen. De evaluatoren beoordeelden de nauwkeurigheid, relevantie en vlotheid van de gegenereerde antwoorden. Daarnaast werden ook andere modellen dan GPT-4o getest.

Naast de tests in het Nederlands en het Frans hebben we ook een test uitgevoerd waarbij vragen in het Nederlands naar het Engels werden vertaald. De antwoorden werden in het Engels gegenereerd en vervolgens opnieuw naar het Nederlands vertaald.

Resultaten

Vraag in het Nederlands, antwoord in het Engels

Het experiment waarbij vragen in het Nederlands naar het Engels werden vertaald en hierna de antwoorden naar het Nederlands werden vertaald leverde een genuanceerd resultaat. Hoewel de vertaling van Nederlandstalige vragen naar het Engels leidde tot ietwat betere antwoorden, van 67% naar 73%, verslechterde de kwaliteit van de antwoorden bij het omgekeerde proces, namelijk het vertalen van de gegenereerde Engelse antwoorden naar het Nederlands.

Nauwkeurigheid van Franse antwoorden versus nauwkeurigheid van Nederlands antwoorden

Tijdens ons experiment hebben we de antwoorden gegenereerd op basis van Nederlandstalige vragen vergeleken met hun Franse equivalenten in verschillende tekstreeksen. We hebben vastgesteld dat de samenstelling van deze reeksen een invloed had op de evaluatie van het model. De scores varieerden namelijk van set tot set voor elk model en elke taal, en de prestatieverschillen tussen de talen kwamen niet altijd tot uiting. Dit onderstreept het belang van het selectieproces van de testvragen: voor onze laatste test hebben we een evenwichtige testset samengesteld met voorbeelden van vragen die door gebruikers in beide talen zijn ingediend en vragen die door domeinexperts zijn opgesteld. In tegenstelling tot wat aanvankelijk werd waargenomen, laten de onderstaande resultaten slechts een klein verschil in nauwkeurigheid zien tussen het Frans en het Nederlands voor onze use case.

Tabel 1. Resultaten van de eindevaluatie van de chatbot.

Opmerking: slecht geformuleerde vragen in het Frans of Nederlands werden uit de testset verwijderd omdat ze moeilijk nauwkeurig in de andere taal te vertalen bleken.

Vergelijking van de LLM’s

GPT-5 presteerde goed op het vlak van nauwkeurigheid en beknoptheid. Het vertoonde echter een groter verschil in nauwkeurigheid tussen het Frans en het Nederlands dan de andere modellen. Gemini presteerde weliswaar beter in zowel het Frans als het Nederlands, maar genereerde aanzienlijk langere antwoorden, wat leidde tot een hoger tokengebruik. We hebben ook vastgesteld dat Claude Sonnet, met een vergelijkbare nauwkeurigheid als Gemini, soms Engelse termen invoegde in het gegenereerde antwoord, en dit vaker in het Nederlands dan in het Frans. Na evaluatie concludeerden de experts op dit gebied dat Gemini het meest geschikte model was voor hun use case.

Effect van de retrieval

Het proces van retrieval bestaat erin om relevante tekstfragmenten te extraheren om een vraag te beantwoorden vanuit de vector database, afhankelijk van de gelijkenis tussen de vraag en deze fragmenten. Deze gelijkenis wordt berekend met behulp van vectorrepresentaties van de teksten, gegenereerd door een embeddingmodel. We hebben vragen geanalyseerd die aanvankelijk betere resultaten opleverden in het Frans dan in het Nederlands en hebben vastgesteld dat ongeveer 50% van de opgehaalde informatie (context) in beide talen voorkwam. Om de impact van de resterende 50% afwijkende informatie te evalueren, hebben we het model (Gemini) aan identieke contexten onderworpen om zowel Franstalige als Nederlandstalige antwoorden te genereren. Ondanks het gebruik van deze identieke contexten bleef het model prestatieverschillen vertonen tussen het Frans en het Nederlands. Het retrievalproces lijkt dus een beperkte invloed te hebben op het waargenomen prestatieverschil tussen de twee talen.

Conclusie en aanbevelingen

Het prestatieverschil tussen het Nederlands en het Engels in grote taalmodellen is een vaststaand feit, dat geworteld is in de overweldigende dominantie van het Engels in de trainingscorpora. Dit verschil wordt nog versterkt door de specifieke morfologie van het Nederlands. Ter vergelijking: als LLM’s over het algemeen betere resultaten opleveren in het Frans, is dat te danken aan een betere vertegenwoordiging van de taal in de trainingscorpora.

Ons experiment heeft waardevolle informatie opgeleverd over de prestaties van LLM’s in een RAG-toepassing (Retrieval Augmented Generation) in het Nederlands en het Frans. Hoewel we aanvankelijk een significant verschil in nauwkeurigheid tussen de antwoorden in het Nederlands en de antwoorden in het Frans constateerden, bleek uit grondig onderzoek dat andere factoren dan de capaciteit van het model de resultaten konden beïnvloeden. Het prestatieverschil is dus minder groot dan we dachten. Bovendien hebben we vastgesteld dat variaties in de samenstelling van de testset kleine schommelingen in de resultaten veroorzaakten. Deze conclusies tonen aan dat de prestaties van LLM’s zeer gevoelig zijn voor de context en de specifieke formulering van de vragen. We hebben ook een lichte kwaliteitsverbetering  van de antwoorden waargenomen bij de Engelse vertaling van Nederlandstalige vragen; dit voordeel werd echter grotendeels tenietgedaan door de daaropvolgende Nederlandse vertaling van deze Engelse antwoorden.

De bovenstaande conclusies gelden voor een chatbot die zorgvuldig opgestelde inhoud in algemene taal gebruikt om vragen te beantwoorden. Ze zijn niet noodzakelijkerwijs van toepassing op andere use cases. Het is daarom essentieel om voor elk geval grondige evaluaties uit te voeren, zeker wanneer men in specifieke domeinen zoals gezondheidszorg, financiën, recht, enzovoort werkt.

Moeten we een eentalig model gebruiken?

We hebben deze vraag niet grondig kunnen onderzoeken. Ons literatuuronderzoek heeft geen overtuigend bewijs opgeleverd dat LLM’s voor het Nederlands de prestaties verbeteren; integendeel, de aanwezigheid van talen met veel bronnen in meertalige modellen lijkt de prestaties van minder goed bedeelde talen tot op zekere hoogte te verbeteren. Er zijn echter verschillende initiatieven genomen om LLM’s voor het Nederlands te ontwikkelen. De meest opvallende zijn:

–           GEITje: model gebaseerd op Mistral 7B en verfijnd voor het Nederlands. Dit model is niet langer beschikbaar vanwege auteursrechtelijke problemen.

–           GPT-NL: lopend initiatief, ondersteund door Nederland, om een LLM te ontwikkelen die is aangepast aan de Nederlandse taal en cultuur.

Referenties

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Test

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

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

Résultats

Question en néerlandais, Réponse en anglais

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

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

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

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

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

Comparaison des LLM

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

Effet de la récupération

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

Conclusions et recommandations

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

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

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

Devrions-nous utiliser un modèle monolingue ?

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

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

Références

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

We hebben waarschijnlijk het moment bereikt waarop de hype over AI op zijn grootst is: men is langs één kant laaiend enthousiast over AI, maar hier en daar raken mensen al gedesillusioneerd. Ook spreekt men meer en meer over een bubbel in de markt van de grote tech-spelers. Maar hoe nuttig zijn LLMs momenteel nu echt? Kunnen we nog veel verbetering verwachten? En hoe zit dat met die hallucinaties?

Waarschijnlijk heb je het zelf al meegemaakt: je praat met ChatGPT of een andere slimme chatbot, en deze vertelt je vol vertrouwen iets waarvan je weet dat het niet klopt. Of je bent een developer, en die coding assistant werkt best wel goed, tot je naar wat meer verlangt, maar die nieuw toegevoegde feature aan je programma hopeloos tekort schiet. En dat zijn nog maar je eigen, bescheiden, ervaringen: wat je hoort van anderen, of op het nieuws of via sociale media, is allicht nog veel extremer: vreugdekreten over hoe we, dankzij AI, een volgende industriële revolutie tegemoet gaan en doemberichten dat mensen hun job erdoor zullen verliezen, versus artikels die vertellen over hoe AI projecten maar blijven mislukken en verhalen over wat voor belachelijke of zelfs gevaarlijke hallucinaties uit de AI chatbots blijven komen. Dus wat moet je er nu van denken?

Om dit enigszins beter te begrijpen: een heel kort, niet te technisch, intermezzo over wat LLMs alweer zijn (mijn excuses dat ik daarbij opzettelijk vaag blijf: voor een betere uitleg raad ik de blogposts van mijn collega’s aan): AI taalmodellen doen voorspellingen over wat het volgende stukje tekst moet zijn, aan de hand van probabiliteiten. Ze zijn getraind op zó veel tekst, dat de in se willekeurige zinnen die eruit rollen, daardoor van een hoge kwaliteit zijn en perfect juist klinken (en het vaak genoeg ook zijn). Echt nadenken zoals een mens doen ze dus niet; het is heel erg “text based”. Het is meer het vinden en herhalen van patronen, dan écht begrip; de intelligentie erin ontstaat als emergent verschijnsel. De leukste naam die ik er al voor gehoord heb is “probabilistische papegaai“.

Volgens Gartner zitten we nu al voorbij de piek van opgeblazen verwachtingen en in de trog van desillusie. Ook andere verslaggevers spreken van een hype of bubbel. Er worden ettelijke miljarden geïnvesteerd in nieuwe datacenters om de AI-machine te voeden, soms zelfs met inbegrip van nieuwe energiecentrales, terwijl de winstgevendheid voorlopig nog ver te zoeken is. Is het effectief een bubbel? Dat hangt af van je definitie van bubbel… Het lijkt in elk geval een grote, soms geostrategische gok, op de volgende technologie die de wereld drastisch kan veranderen en verbeteren, of zelfs veroveren; misschien zelfs vernietigen… En op moment van schrijven deinzen sommigen er niet van terug om te zeggen dat de luchtbel weldra zal barsten, met als belangrijkste argumenten de circulaire investeringen van een aantal grote bedrijven in elkaars capaciteit, en het openstellen van ChatGPT voor erotische inhoud, een zet die meer op cashflow-druk dan op ruimdenkendheid lijkt te duiden.

Bijkomend probleem is dat momenteel ook de investeringen in LLM de wind wegnemen uit de zeilen van een aantal andere zeer nuttige AI-technologieën (maar wanneer de storm is gaan liggen kunnen de datacenters misschien wel van pas komen voor deze laatste). Stemmen gaan trouwens op dat we voor échte intelligentie nóg een andere AI technologie zullen moeten ontwikkelen (al zal het uiteindelijk wel iets zijn dat gebruik maakt van alle rekenkracht die we nu uitrollen), en dat LLMs stilaan op hun limieten botsen, met steeds kleiner wordende incrementele verbeteringen (en opgeklopte testresultaten). Ondanks de bittere les dat meer data en rekenkracht de grootste vooruitgang mogelijk hebben gemaakt, gaan er nu stemmen op dat men met LLMs geen Artificial General Intelligence (AGI) zal kunnen bouwen; men zal nieuwe research moeten aanboren. En ondertussen kan men ook aantonen dat de hallucinaties er gewoon bij horen en allicht nooit volledig weg te krijgen zullen zijn: onkruid vergaat niet.

Maar in een tuin waar onkruid groeit, kan men toch ook goede dingen laten groeien, met wat moeite. En in zo’n tuin hebben LLMs wel degelijk hun nut: daar waar een taak vooral gaat over tekst en taal, zijn ze bijvoorbeeld heel krachtig (denk aan samenvatten, vertalen, zaken verzinnen, zeer eenvoudige redeneringen opbouwen, …). En ook voor programmeren (wat een soort omgaan met een specifiek soort taal is), merken we enthousiasme van vele developers die hun productiviteit zagen stijgen (maar security blijft een aandachtspunt!). Als algemene slimme assistent kan het ook een rol spelen, zolang de gebruiker zelf voldoende onderlegd is in een onderwerp en kritisch is ingesteld. En misschien moeten ze gewoon nog verder evolueren tot de beste tool voor een bepaalde niche van taken.

Ook zelf heb ik een genuanceerd verhaal te vertellen: in mijn vorige blogpost had ik het over een aantal kleine successen met vibe coding, en de beperkingen van het AI, wanneer de taken groter of complexer worden. Hetzelfde zie ik in het werk dat ik sindsdien heb verricht: het analyseren en vertalen van legacy code met behulp van deze taalmodellen. Ook daar dus een gemengd succes: geen toverstokjes, nauwelijks of moeilijk te automatiseren, maar toch een zichtbare tijdswinst bij het begrijpen van middelmatig grote en het herschrijven van kleine stukken code van dit soort projecten (meer details daarover in een komende blogpost).

Conclusie

Een LLM is slechts één van de vele intelligente technologieën die we momenteel aan onze vingertippen hebben, al zij het wel de meest toegankelijke en zichtbare. Misschien vandaar zowel de hype als de controverse?

Zijn LLMs nuttig? Ik zou durven argumenteren van wel. Met de huidige stand van de technologie is het echter van groot belang dit te nuanceren: zet een LLM als powertool ter beschikking van een menselijke expert! De echte waarde ligt dus niet in vervanging, maar in augmentatie. Laten we het komende jaar kijken of alle agent-based systemen hier verandering in brengen…