Willem Delbare, Co-Fondateur et PDG d’Aikido – Série d’entretiens

Willem Delbare, cofondateur et PDG d’Aikido, est un entrepreneur en série dans le SaaS et un fondateur au profil technique, fort d’une solide expérience dans la création d’entreprises de logiciels destinés aux développeurs. Avant de lancer Aikido en 2022, il a cofondé la plateforme RH Officient, l’initiative de développement durable FutureproofedCities et l’entreprise de CRM Teamleader. Il y a été directeur technique et a contribué à en faire l’une des réussites SaaS marquantes de Belgique. Tout au long de sa carrière, il s’est attaché à simplifier les défis techniques complexes liés aux infrastructures cloud, à la capacité de montée en charge du SaaS et à la cybersécurité. Sous sa direction, Aikido est rapidement devenue l’une des jeunes entreprises de cybersécurité à la croissance la plus rapide en Europe, en misant sur des solutions pratiques adaptées aux équipes de développement modernes.

Aikido est une entreprise belge de cybersécurité qui aide les développeurs et les équipes d’ingénierie à protéger leurs applications et leurs environnements cloud au moyen d’une plateforme unifiée. Elle réunit l’analyse du code et des dépendances, la gestion de la posture de sécurité cloud, la protection à l’exécution et les tests assistés par l’IA dans un système simplifié. Son approche vise à réduire la complexité et les faux positifs, tout en évitant aux organisations de gérer un assemblage fragmenté de solutions de plusieurs fournisseurs. Conçue avant tout pour les développeurs, Aikido privilégie l’automatisation, la surveillance continue et des procédures de correction simplifiées pour intégrer la sécurité directement au cycle de développement logiciel.

Quelles expériences acquises en créant et en développant des entreprises comme Teamleader et Officient vous ont conduit à fonder Aikido Security en 2022 ? Comment votre profil de fondateur technique a-t-il façonné votre vision d’une cybersécurité plus adaptée aux développeurs ?

Au cours de la dernière décennie, j’ai trouvé ma vocation dans le SaaS B2B. J’ai été cofondateur technique et directeur technique de trois startups, avec trois opérations de sortie dans les technologies RH, la facturation et la comptabilité carbone. Des univers très différents, mais toujours la même obsession : créer des logiciels qui ne donnent pas envie de jeter son ordinateur portable par la fenêtre.

Dans chacune de ces entreprises, pourtant, la sécurité m’empêchait de dormir. La crainte d’une fuite de données était bien réelle, et les outils censés nous aider ressemblaient au cockpit d’un F-16 : coûteux, intimidants et conçus pour un titulaire de doctorat en informatique, pas pour une équipe de développement qui cherche à livrer vite.

Nous avons fondé Aikido Security pour résoudre précisément ce problème. Aikido propose aux organisations de toutes tailles une plateforme unifiée de sécurité logicielle, conçue d’abord pour les développeurs. Elle rassemble les fonctions essentielles de sécurité du code, du cloud et de l’exécution pour faciliter la livraison de logiciels sûrs.

Depuis, l’IA a encore accéléré la livraison des logiciels et élargi la surface d’attaque. Notre prochaine étape consiste à permettre aux organisations de suivre le rythme grâce à des logiciels capables d’assurer leur propre sécurité.

En février, nous avons lancé Aikido Infinite, notre solution de tests d’intrusion continus par IA. Elle vérifie l’exploitabilité des failles et mène le cycle de correction à son terme avant que le code n’arrive en production.

Les environnements de développement sont maintenant décrits comme l’un des principaux angles morts de la sécurité. Qu’est-ce qui a changé récemment pour en faire une question si critique ?

Les postes des développeurs ont toujours été des cibles précieuses. Ils contiennent des identifiants cloud, des clés SSH, des jetons de publication npm, des configurations Kubernetes et un accès direct au code source. Ce qui a changé ces 6 à 12 derniers mois, c’est que les attaquants ont compris combien il était facile de les compromettre par les outils auxquels les développeurs font déjà confiance. Nous l’avons suivi tout au long de l’année : Trivy, TanStack, Bitwarden CLI, l’extension Nx Console de VS Code et, maintenant, GitHub. Dans chaque cas, la compromission est passée par les outils de développement et l’appareil était la cible.

Le problème est que la plupart des équipes de sécurité ne voient pas ce qui s’exécute réellement sur ces machines. L’EDR surveille les applications, mais pas les paquets, extensions et outils d’IA qui tournent à l’intérieur. Les développeurs, eux, ajoutent chaque jour de nouveaux paquets, extensions et outils d’IA avec très peu de vérifications. Les LLM ont aussi facilité la création de logiciels malveillants convaincants, abaissant globalement le seuil d’entrée pour les attaquants. Toutes ces attaques exploitent l’écart entre le contenu des postes de développement et ce que les équipes de sécurité peuvent réellement voir.

Nous assistons à une vague d’attaques de la chaîne d’approvisionnement au moment où l’IA est de plus en plus adoptée. Comment l’IA modifie-t-elle l’équilibre entre les attaquants et les défenseurs ?

L’IA a considérablement facilité la création de logiciels malveillants ciblant la chaîne d’approvisionnement. Concevoir des charges utiles convaincantes, masquer le code et comprendre assez bien les registres de paquets pour les détourner exigeait auparavant de véritables compétences techniques. Il suffit désormais d’un abonnement à un LLM. Nous l’avons observé directement avec TeamPCP, à l’origine de la plupart des grandes attaques de cette année, dont la récente compromission de GitHub. Ce groupe n’est pas particulièrement avancé techniquement, mais il multiplie les attaques, et l’IA joue un rôle majeur dans son changement d’échelle. Il y a un an, nous traitions des compromissions de paquets isolés. Aujourd’hui, nous voyons des vers autoréplicatifs comme Shai-Hulud et des campagnes en chaîne qui passent d’un registre à l’autre, en utilisant les identifiants volés lors d’une compromission pour alimenter la suivante.

L’IA aide aussi la défense, autrement. Les équipes peuvent effectuer des tests d’intrusion continus sur des bases de code entières avec des agents qui testent des centaines de chemins d’attaque en parallèle. Cela libère du temps pour les décisions qui exigent encore un jugement humain. Au niveau des appareils, l’IA aide aussi à détecter plus tôt les paquets malveillants, en analysant les éléments à installer avant leur arrivée sur le poste du développeur. Mais, honnêtement, les attaquants bénéficient actuellement davantage de l’IA que les défenseurs. Le seuil de difficulté pour créer un logiciel malveillant a baissé plus vite que celui de sa détection.

Aikido parle de déplacer la sécurité en amont. Qu’est-ce que cela signifie en termes pratiques pour les équipes qui construisent et livrent des logiciels aujourd’hui ?

Une grande partie du secteur a passé des années à déplacer la sécurité vers la gauche, c’est-à-dire plus tôt dans la chaîne CI/CD. Or la surface d’attaque s’est déplacée encore plus en amont : sur le poste du développeur lui-même. La compromission de GitHub l’illustre bien. Ce n’était pas du code non sécurisé arrivé en production, mais une extension VS Code compromise sur le portable d’un développeur qui exfiltrait des identifiants avant même la première ligne de code.

Concrètement, la sécurité doit fonctionner en continu là où le code est écrit et les outils installés. Il faut vérifier ce qui tourne sur les appareils des développeurs, intercepter les paquets et extensions malveillants avant leur arrivée et tester automatiquement les risques exploitables à chaque changement du code, sans attendre un examen programmé. L’objectif est un cycle fermé où détection, validation et correction font partie du travail de développement, plutôt que d’un processus distinct exécuté après coup.

Étant donné que les agents d’IA téléchargent automatiquement les dépendances et les outils, comment les entreprises devraient-elles repenser la confiance dans le code open source et le code tiers ?

Par défaut, les agents d’IA récupèrent automatiquement des dépendances et des outils avec très peu de supervision humaine. Cela transforme le modèle de confiance : du code que personne n’a explicitement choisi d’installer s’exécute sur les postes des développeurs.

La compromission de Vercel montre bien comment les choses peuvent mal tourner. Vercel n’a pas été piraté directement. Une extension d’IA légitime disposait d’un accès OAuth au compte Google d’un employé ; elle avait été compromise en amont par un logiciel voleur d’informations du côté du fournisseur. C’est le schéma récurrent de l’open source : du code tiers jugé fiable devient le point d’entrée. Le risque s’amplifie, car un poste de développement compromis donne à l’attaquant les mêmes accès qu’à un ingénieur de confiance. Il peut modifier le code, insérer des dépendances malveillantes ou publier des versions altérées de logiciels légitimes. Ces changements sont repris par les chaînes de compilation et diffusés en aval par des mises à jour considérées comme fiables.

Les entreprises doivent considérer tout ce qui s’exécute sur le poste d’un développeur comme une partie de leur surface d’attaque : les agents d’IA, les outils qu’ils installent, les extensions dont ils dépendent, absolument tout. Une visibilité limitée aux paquets open source connus laisse dans l’ombre les couches où ces attaques ont réellement lieu.

Le concept de logiciel auto-sécurisant est convaincant. Quelles sont les capacités de base requises pour que cette vision fonctionne à grande échelle ?

Il faut un cycle fermé. À chaque modification du code, le système doit tester des chemins d’attaque réels, confirmer l’exploitabilité d’un problème ou écarter le signalement s’il n’est pas exploitable, puis générer et appliquer les correctifs dans le travail de développement. Il doit ensuite retester pour vérifier l’efficacité de la correction. Ce cycle entier doit fonctionner en continu, sans attendre qu’une personne le programme. Il ne s’agit pas de retirer les humains de la sécurité, mais de prendre en charge le travail permanent pour que les équipes se concentrent sur les décisions exigeant réellement leur jugement.

Les développeurs ont souvent du mal à gérer le trop-plein d’alertes et les faux positifs des outils de sécurité. Comment Aikido aide-t-il les équipes à se concentrer sur ce qui compte vraiment ?

Les deux tiers des responsables de sécurité interrogés dans notre enquête State of AI in Security & Development ont déclaré que leurs équipes avaient contourné des procédures, écarté des signalements ou retardé des correctifs à cause de faux positifs. C’est le véritable coût des outils qui produisent trop de bruit. Ils ne font pas que perdre du temps : ils dégradent activement la sécurité, car les gens cessent de croire aux alertes.

Chez Aikido, nous utilisons l’analyse d’accessibilité et le triage automatique. Au lieu de signaler chaque vulnérabilité et de laisser l’équipe décider de son importance, nous vérifions si elle est effectivement accessible dans le code et exploitable dans l’environnement concerné. Sinon, l’équipe ne la voit jamais. Cela réduit fortement le nombre d’alertes et rend celles qui passent réellement dignes d’une intervention.

Votre plate-forme combine la sécurité du code, la sécurité du cloud, la sécurité du runtime et les tests de pénétration automatisés. Pourquoi une approche unifiée est-elle plus efficace que l’utilisation de plusieurs outils autonomes ?

Notre étude State of AI in Security & Development a révélé un résultat contre-intuitif : les équipes ayant subi des incidents utilisaient davantage d’outils de fournisseurs que celles qui n’en avaient pas subi. Plus d’outils ne signifiait pas une meilleure sécurité, mais plus de bruit, de signalements en double et de temps passé à rapprocher les alertes de différents tableaux de bord au lieu de corriger les problèmes.

C’est pourquoi nous avons construit Aikido comme une plateforme unique pour le code, le cloud, l’exécution, les dépendances et les pipelines. Réunir tous ces signaux permet de supprimer les doublons, de déterminer si une vulnérabilité du code est réellement accessible dans le cloud et de prioriser selon le risque réel, au lieu de traiter tous les résultats de chaque analyseur comme aussi urgents. Les équipes consacrent moins de temps au triage entre les outils et davantage aux corrections importantes. Chaque fonction doit aussi être solide à elle seule. Une plateforme médiocre dans tous les domaines ne fait que regrouper le problème. Chacune de ses parties doit égaler ou dépasser la solution indépendante correspondante ; sinon, l’argument en faveur de la consolidation ne tient plus.

Aikido s’est développée rapidement et a gagné beaucoup de terrain en peu de temps. Quels ont été les principaux défis pour créer et faire grandir une entreprise de cybersécurité à ce rythme ?

Le plus évident est d’être une entreprise belge de cybersécurité. Le secteur s’est traditionnellement développé à Tel-Aviv et dans la Silicon Valley. Au début, certains doutaient qu’une plateforme de niveau mondial puisse venir d’ailleurs. Mais cette distance est devenue un avantage. Nous ne répétions pas les mêmes recettes. Nous sommes partis des besoins des développeurs, avec un produit intégré que les équipes pouvaient adopter seules. C’est ainsi que nous sommes devenus discrètement la plateforme dominante de sécurité des développeurs pour les PME.

Le plus grand défi est le rythme. Nous avons atteint le statut de licorne en janvier 2026 avec notre série B, notre chiffre d’affaires a été multiplié par cinq l’an dernier et plus de 100 000 équipes nous font désormais confiance, dont la Premier League, Revolut et SoundCloud. Cette année seulement, nous avons lancé Device Protection pour la sécurité de la chaîne d’approvisionnement, Infinite pour les tests d’intrusion par IA et un partenariat avec Lovable pour intégrer la sécurité aux processus de vibe coding. Avancer aussi vite tout en maintenant une qualité élevée dans chaque partie de la plateforme reste un défi constant. Mais c’est un défi appréciable.

À mesure que le développement natif de l’IA devient la norme, à quoi ressemble l’avenir de la sécurité des logiciels au cours des prochaines années ?

La réponse honnête est que les procédures de sécurité traditionnelles peinent déjà à suivre. Les examens périodiques, les tests d’intrusion planifiés et les analyses après coup supposent tous un rythme de développement qui n’existe plus vraiment. Le code généré par l’IA et les agents autonomes introduisent des changements plus vite que ces procédures ne peuvent les valider.

Nous pensons que la sécurité doit devenir une boucle de rétroaction continue, directement intégrée au développement des logiciels. Nous appelons cela des logiciels capables d’assurer leur propre sécurité. Chaque modification du code est testée face à des chemins d’attaque réels, les signalements sont validés selon leur exploitabilité effective, puis les correctifs sont générés et retestés, sans attendre qu’un humain le planifie. Des versions initiales existent déjà, et nous construisons cette approche pour le code, le cloud, l’exécution et la chaîne d’approvisionnement.

L’étape suivante serait un logiciel qui assure sa propre maintenance : la sécurité ne se limiterait pas à détecter et à corriger les problèmes, mais entretiendrait activement la santé de la base de code dans la durée. C’est plus lointain, mais les fondations se posent aujourd’hui. Une certitude : l’IA a déjà fait s’effondrer l’obstacle à la réalisation d’attaques sophistiquées. La défense doit donc avancer à la même vitesse.

Merci pour cet entretien. Les lecteurs qui souhaitent en savoir plus peuvent consulter Aikido.