L'agile est mort. Les meilleures équipes tech ne sont plus que 3 personnes. | Zaid Al Hamami, Boost Security

Nectar : Zaid, merci d’être au podcast. Vraiment content de te parler aujourd’hui. Comme on en discutait avant l’enregistrement, je suis un peu biaisé pour notre conversation. J’aimerais commencer là où on s’est rencontrés pour la première fois, et je dois avouer que cette histoire me gêne un peu. C’était à l’époque d’Immunio : on était tous les deux locataires chez WeWork, ce que j’avais complètement oublié jusqu’à ce que tu me le rappelles sur scène. Alors peux-tu nous parler d’Immunio, pourquoi tu l’as lancée, et ce que c’était ?

Zaid : Merci d’abord de m’accueillir au podcast. Avant de parler d’Immunio, je vais me présenter rapidement et expliquer comment j’ai abouti là. Comme beaucoup de gens dans notre industrie, je suis tombé amoureux du code très jeune. À 10 ou 11 ans, je codais énormément. J’économisais mon argent pour acheter des livres de programmation, et je passais des heures à coder chaque jour. Je savais très jeune que je voulais faire carrière en construisant des logiciels et des entreprises.

Les applications que je trouvais les plus intéressantes à construire, c’étaient surtout des outils de cybersécurité et de hacking. Il y avait bien un jeu vidéo de temps en temps, mais ce qui me fascinait, c’était de faire faire à un ordinateur ce que les gens ne voulaient pas qu’il fasse.

Cette passion m’est restée. Originaire du Moyen-Orient, je suis né et j’ai grandi en Jordanie. Je suis ensuite venu au Canada, j’ai étudié à McGill, j’ai fait un diplôme en génie, et j’ai travaillé comme professionnel en développement logiciel pendant 10 ou 12 ans. Pas en cybersécurité, mais le cyber est toujours resté ma passion. C’est ce qui m’a gardé connecté à la tech.

Pour en arriver à Immunio : mon dernier emploi avant de devenir entrepreneur, c’était chez Canonical. Canonical est très connue dans le monde de l’open source. C’est l’entreprise derrière la distribution Linux Ubuntu. J’y dirigeais la gestion de produit. Il y avait la distribution gratuite et open source, mais l’entreprise avait aussi plusieurs offres commerciales vendues à des clients comme Google, Salesforce ou IBM. C’étaient souvent des outils pour gérer des milliers de machines. Le logiciel gratuit, tu peux le télécharger, mais quand tu en as des dizaines de milliers à gérer, il te faut autre chose. Un de nos produits commerciaux servait exactement à ça.

On avait construit ce produit, les clients l’adoraient, ça se vendait bien. Notre job, c’était de s’assurer qu’il était sécurisé, qu’on ne pouvait pas lui faire faire ce pour quoi il n’était pas conçu. Parce que si un hacker arrivait à le détourner, il pouvait faire des dommages énormes — ce produit gérait des milliers de machines.

On faisait donc des tests de sécurité sur ces produits. Un de nos ingénieurs vedettes trouvait des failles à n’en plus finir avant même qu’on sorte le produit. Avec un autre ingénieur de mon équipe, on s’est dit : ces bugs-là, ils les ont trouvés, mais on ne va jamais tout trouver. Et on déploie en continu — CI/CD, DevOps, Agile, on livre vite. C’était avant que ce soit à la mode. Donc comment ajouter une couche de sécurité et de protection ?

À l’époque, on utilisait ce qu’on appelait des web application firewalls — des dispositifs de couche réseau qui vérifient les entrées. Si ça paraît suspect, ça bloque. C’était l’idée. Mais en 2011-2012, la technologie n’était vraiment pas bonne. C’était lourd à gérer, difficile à déployer, à configurer, à maintenir, et ça ne fonctionnait pas très bien. Les gens arrivaient à contourner ces technologies assez facilement.

Avec cet ingénieur, Mike — qui est devenu mon cofondateur chez Immunio —, on a eu une idée. À l’époque, il y avait une entreprise qui s’appelait New Relic, très populaire et qui réussissait très bien, avec une approche basée sur l’instrumentation. C’était fondamentalement différent du travail de couche réseau. On a écrit un prototype. Ça marchait très bien. On avait l’impression que ça cochait toutes les cases.

On s’est dit : il y a toute une industrie d’applications à protéger, et on vient de construire quelque chose de beaucoup mieux que ce qui était considéré comme l’état de l’art. Il y avait un intérêt pour le cyber, un attachement à ce domaine, et un vrai problème qu’on venait de rencontrer en essayant de sécuriser une application critique. C’est de là qu’est née Immunio.

On a pitché l’idée à plusieurs VCs. On a été financés assez rapidement. On a monté l’entreprise, et en quelques années, on avait déjà de bons clients qui utilisaient notre techno — des entreprises comme SurveyMonkey, CareerBuilder, et ainsi de suite.

Nectar : Était-ce difficile de faire le saut ? Était-ce une décision facile, du genre « je quitte cette entreprise stable pour lancer quelque chose » ? Tu n’avais jamais fait ça avant, c’est ça ?

Zaid : Pour être honnête, je ne dirais pas que c’était facile. Mais pour moi, ça avait toujours fait partie du chemin. Depuis l’adolescence, je savais qu’un jour j’allais bâtir ma propre entreprise de logiciels, parce que je trouvais ça fascinant. Beaucoup des entrepreneurs et des entreprises que j’admirais avaient pris ce chemin-là, et je savais que je l’avais en moi.

L’expérience que j’avais accumulée jusque-là m’a donné la confiance. J’avais dirigé la gestion de produit dans une entreprise qui avait beaucoup de succès, assez jeune, et j’avais beaucoup appris en route. Je me suis rendu au point où j’étais convaincu que tout ce que je ne savais pas, on finirait par le résoudre.

C’est ça le plus dur pour la plupart des gens. La différence entre les entrepreneurs et ceux qui veulent vraiment l’être mais n’arrivent pas à faire le saut, c’est le facteur peur. C’est toujours plus sécuritaire d’avoir un emploi stable, de ne pas prendre de risque. Mais certaines personnes savent juste qu’elles doivent le faire, elles l’ont en elles.

Nectar : Je peux vraiment me reconnaître dans ça. Je vais partager ma perspective sur Immunio. Mon ancienne entreprise, on était les premiers locataires chez WeWork avec vous. On voyait tout le temps les T-shirts bleus d’Immunio, et votre équipe ne cessait de grandir. À un moment, vous étiez en train de prendre tout WeWork. Vous étiez 20, 30 personnes. Et nous, on était une petite entreprise de quatre, cinq personnes à l’époque. Et c’est drôle : quand je disais que tu étais gêné, c’est moi qui étais gêné, parce qu’à notre lancement, tu m’as rappelé qu’on était voisins. J’avais complètement oublié. Et ça, même après qu’on avait investi dans ton entreprise. J’aurais dû m’en souvenir. À l’époque, je me souviens que mon impression d’Immunio, c’était : « cette entreprise est en feu ». Vous embauchiez sans arrêt.

Zaid : L’histoire d’Immunio, c’est qu’on avait cette innovation, cette idée de faire quelque chose de mieux, on l’avait construite, on l’avait prouvée, on avait même des brevets dessus. L’année suivante, Gartner, le célèbre cabinet d’analystes, a créé une catégorie et nous y a placés.

La catégorie s’appelait RASP — Runtime Application Self-Protection. La première année, il n’y avait que nous et deux autres fournisseurs. Ça a donné à la catégorie une certaine légitimité : on n’était pas les seuls à réfléchir à ce problème.

Les clients ont commencé à poser des questions. Une fois qu’on a eu nos deux ou trois premiers gros clients dans la baie de San Francisco — ils adoraient la techno, qui marchait vraiment bien et résolvait des vrais problèmes —, on s’est lancés dans une vague d’embauches. On a fait grandir l’entreprise.

Il y a eu l’inévitable virage. On avait démarré avec un go-to-market développeur : offre gratuite, les développeurs utilisent en self-serve, puis on essaie d’en convertir une partie. Mais en 2013-2014, deux ans après le lancement, le marché n’était pas encore prêt pour ça, surtout en sécurité.

La sécurité était encore gérée comme une fonction séparée dans la plupart des entreprises, loin des développeurs. Kubernetes n’existait pas encore. DevOps était à peine adopté. C’étaient les premiers jours. Trois ou quatre ans plus tard, vers 2016-2017, le marché global a réussi à obtenir quelques clients de prestige, mais on n’a pas vu de croissance en bâton de hockey.

C’était en grande partie parce qu’il y avait beaucoup de friction au déploiement. On vendait une technologie de type développeur, mais le bénéfice se manifestait quand la technologie était déployée en production. Aujourd’hui, c’est beaucoup plus acceptable : tu as l’automatisation Kubernetes, tu déploies vite, les ingénieurs DevOps sont partout.

Mais à l’époque, cette transition n’en était qu’à ses débuts. C’est devenu clair que ce marché allait être un long marathon pour tout le monde. Et la réalité, c’est qu’on s’est dit : bon, ça va prendre trop de temps.

Nectar : Alors vous avez provoqué la sortie, la voie M&A, en gros ?

Zaid : Plusieurs acquéreurs nous parlaient depuis un moment, parce qu’ils trouvaient la technologie intéressante. Ils avaient besoin de quelque chose pour la sécurité Kubernetes. L’entreprise qui nous a finalement acquis, c’était Trend Micro — une excellente entreprise. Tu peux les voir comme des concurrents de CrowdStrike et SentinelOne. Ils vendent des produits qui s’installent sur des serveurs, sur des endpoints. Mais tout ce qui tourne à l’intérieur d’un cluster Kubernetes, par exemple, leur est invisible.

Ils avaient donc besoin d’une technologie capable de surveiller au niveau applicatif, ce qui était exactement le rôle des technologies RASP. Dans les deux ou trois années suivant notre acquisition, à peu près tous les autres fournisseurs RASP ont aussi été acquis. La catégorie s’est essentiellement fondue dans une catégorie beaucoup plus large.

Nectar : Donc il y a eu consolidation. Et l’exit avec Trend Micro, c’était en 2018, 2019 ?

Zaid : C’était fin 2017, début 2018. Comme je l’ai dit, on parlait avec eux depuis longtemps, on avait bâti une relation. Excellente entreprise. C’était intéressant de passer d’une plus petite structure. Avant Immunio, je dirigeais la gestion de produit dans une entreprise open source d’environ 1 000 personnes, mais qui opérait vraiment comme une startup — pensée décentralisée, on bougeait vite, pratiques de développement modernes. Puis Immunio, qui était une petite startup.

Puis chez Trend Micro — encore une fois, excellente entreprise avec une belle culture —, ce que j’ai appris rapidement, c’est que les grandes entreprises ont des milliers de clients. C’est une bonne chose : en grandissant, on accumule des milliers de clients. Le défi, c’est qu’une part énorme des ressources, des budgets et des gens va à la protection de cette base existante.

Donc, au lieu que le focus soit sur l’innovation, la prochaine génération, les problèmes de demain, c’est : comment on s’assure de renouveler notre plus gros client, parce qu’une bonne partie de nos revenus en vient. Il y a toujours cette tension entre bâtir et innover pour les problèmes de demain, et l’entreprise qui a vraiment besoin de protéger l’existant.

C’est probablement pour ça que les grandes entreprises doivent acquérir des startups sans arrêt. Cette tension est à la fois inévitable et saine. Et j’ai réalisé que la partie pour laquelle je suis vraiment câblé, c’est l’innovation.

Nectar : Le zéro à un, comme tu dis.

Zaid : Oui, le zéro à un, le un à dix — c’est là que je m’éclate.

Nectar : Après la sortie, tu parlais d’une intuition de marché. Quelle était cette intuition pour Boost, juste après ton exit ?

Zaid : Au fond, c’était une continuation d’Immunio. Je dis parfois aux gens : c’est la même mission, simplement le prochain ensemble de problèmes. La façon dont j’aime en parler, c’est que la voie sur laquelle on était, même à l’époque d’Immunio et de la catégorie RASP, c’était que le développement logiciel demande des efforts. Faire un bon développement, ça prend des efforts. S’assurer que le logiciel produit est sûr, sécurisé, durci, pas facile à hacker, ça prend encore plus d’efforts. Ça demande de la pratique, de l’expertise technique.

L’intuition chez Immunio, c’était : on ne fera jamais une job parfaite avant la mise en production, alors mettons en production quelque chose qui ajoute une armure supplémentaire. C’était l’intuition principale. Mais comme je l’ai dit, on était dans les premiers jours. Il n’y avait pas de plateformes d’observabilité Kubernetes, pas d’instrumentation runtime, et donc passer du déploiement à la perception du bénéfice par les clients, c’était un gros travail.

Mais en 2019-2020, le marché avait évolué. Beaucoup plus d’entreprises faisaient de l’agile et du DevOps. Le DevSecOps était devenu une pratique. Kubernetes était partout, ce qui permettait beaucoup d’automatisation et d’instrumentation — tu pouvais déployer rapidement. J’ai contacté beaucoup de gens que je connaissais dans l’industrie et je leur ai demandé : « Qu’avez-vous essayé de résoudre en DevSec ? Est-ce que ça fonctionne pour vous ? »

Le concept, c’était : peut-on sécuriser le logiciel à la vitesse à laquelle on le développe ? Et la réponse, sans appel, c’était : tout le monde essaie, personne n’y arrive — sauf Google, Apple, Meta, les grandes entreprises tech qui construisent essentiellement tout à l’interne.

Donc l’intuition, c’était que ce problème devait être résolu, et qu’il pouvait l’être. On pouvait amener les pratiques de développement sécuritaire de Google, Facebook, Meta, Apple, et les livrer en service à n’importe quelle organisation, en SaaS. C’est de là que Boost est né.

Pourquoi j’insiste là-dessus : avec Immunio, c’était « on n’y arrivera jamais en amont, alors ajoutons une protection en runtime, en production ». Maintenant, on dit : le marché a changé, la technologie a changé, les pratiques de développement ont changé. Tu peux faire un assez bon travail dès le début. C’est juste que ce n’est pas facile. Donc rendons ça facile. C’est l’origine de Boost.

Et ça se relie naturellement à où on est aujourd’hui. Les entreprises faisaient déjà une forme de sécurité applicative — c’est comme aller de un à dix : tu fais déjà quelque chose, tu essaies juste de le faire plus vite parce que tu développes plus vite avec les nouvelles pratiques. Mais maintenant, avec les agents qui écrivent du code et l’ingénierie agentique, c’est la même chose, mais beaucoup plus vite, à un rythme différent.

C’est passer de dix à cent. Mais c’est fondamentalement le même problème : le code est généré à un rythme de plus en plus rapide, c’est du code plus complexe. Comment ne pas ralentir l’innovation tout en s’assurant qu’on produit du logiciel qui ne va pas finir dans les manchettes, avec des fuites client, des poursuites collectives, des dommages réputationnels ?

Nectar : Il y a tellement d’angles d’attaque possibles. Revenons à pourquoi je suis enthousiaste par rapport à ce que tu fais chez Boost. Mais je voudrais parler de la cybersécurité dans son ensemble. À cause de ce grand changement dont tu parles, et on en discutait avant — je pense que Mythos est la meilleure chose qui soit arrivée à la cybersécurité depuis longtemps. C’est au sommet des préoccupations de tous les CISOs. La surface d’attaque pour les hackers — dans ton entreprise, vous protégez essentiellement contre les attaques —, comment ce nouveau vibe coding, cette nouvelle façon de construire du logiciel, a augmenté cette surface pour les attaquants ?

Zaid : De plusieurs façons. Je vais donner des exemples concrets. J’ai donné une fois une conférence à un auditoire qui n’était pas du tout dans l’industrie du cyber, et quelqu’un m’a demandé : avec tout ce financement qui va dans les entreprises de cybersécurité, comment ça se fait qu’on entend encore parler de fuites ?

La trame générale est la suivante. La technologie et l’innovation ne s’arrêtent jamais. Il y a toujours un nouveau standard, une nouvelle technologie qui prend feu et se fait adopter comme une traînée de poudre. Que ce soit le courriel, l’Internet, les applications mobiles — il y a eu un jour où tout le monde voulait une stratégie d’applis mobiles —, le cloud computing, et maintenant les agents qui écrivent du code.

Ces technologies se font adopter à un rythme fou quand c’est le bon format, le bon prix, le bon moment. Mais la recherche en sécurité avance à un rythme beaucoup plus lent. La recherche, jusqu’à maintenant, demande à des experts de passer des heures, des semaines, des mois, des années à comprendre comment une technologie peut être détournée.

Donc, depuis presque la naissance de la tech, les technologies se font adopter beaucoup plus vite qu’on ne peut y trouver les failles. Et tu te retrouves toujours dans le même scénario : il y a déjà des dizaines de millions de choses déployées dont on commence à peine à comprendre comment les hackers peuvent les attaquer.

L’industrie a toujours fonctionné comme ça. On découvre que tout le monde a un téléphone mobile, mais on n’a pas pensé à la sécurité mobile. Les hackers commencent à hacker parce que c’est facile, puis une industrie de sécurité mobile émerge pour colmater les trous. Pareil pour le cloud, les conteneurs, Kubernetes, et ainsi de suite.

On est maintenant à l’ère des agents et du vibe coding. Ça a pris feu, plus vite que l’industrie n’a pu suivre. Personne ne s’est arrêté pour dire : « assurons-nous d’abord de construire ça de façon sécuritaire. » Ça ne s’est pas produit. Ça a été déployé, poussé, tout le monde l’utilise, et chaque semaine, des chercheurs trouvent de nouvelles façons de subvertir ton agent de codage. Si tu télécharges une skill d’agent malicieuse, des mauvaises choses peuvent arriver. Et au passage, tu connectes ce serveur MCP qui fait ceci ou cela.

Ce que je veux dire, c’est qu’il n’y a rien de spécial au vibe coding en soi. C’est la façon naturelle dont la technologie se fait adopter et dont la recherche en sécurité se rattrape. Ce sera toujours le cas. Ce qui est spécifique au codage agentique, par contre, c’est le rythme auquel les choses se font intégrer — c’est fou.

Nectar : Donc une partie, c’est la vitesse. L’agent va dans le dépôt GitHub, prend ce qu’il y a, ne vérifie pas s’il y a du code malicieux à l’intérieur.

Zaid : Oui, les agents peuvent être détournés très facilement. Il faut beaucoup d’efforts pour s’assurer qu’ils ne fassent pas ce que des acteurs malveillants veulent qu’ils fassent. Que ce soit en téléchargeant un package open source avec de mauvaises instructions pour l’agent, ou — il y a deux jours, GitHub a été piraté. L’entreprise sur laquelle on s’appuie tous pour le développement logiciel s’est elle-même fait pirater. Un ingénieur de GitHub a téléchargé une extension pour son IDE, VS Code, et il y avait un malware dedans. Une attaque de chaîne d’approvisionnement, on en reparlera. Ça a mené à une brèche des dépôts de code source internes.

Ça peut arriver aux meilleurs. Que GitHub ou n’importe quelle entreprise soit victime, ce n’est pas une honte : c’est juste que cette technologie est utilisée à un rythme et à une cadence telle qu’on n’a pas eu le temps de réfléchir à toutes les implications de sécurité. L’industrie essaie maintenant de rattraper et de cataloguer tous les chemins par lesquels les mauvaises choses peuvent arriver.

Détourner les agents, c’est un. Les attaques de chaîne d’approvisionnement, je pense que c’est le danger dormant. C’est celui que nous, dans l’industrie…

Nectar : Peux-tu expliquer ce que c’est, une attaque de chaîne d’approvisionnement ?

Zaid : Oui. Depuis 25, 30 ans, l’open source ne fait que gagner en popularité, et il y a des projets open source pour tout. Tes frameworks front-end, tes APIs, tes librairies de sécurité — tu construis probablement sur de l’open source d’une façon ou d’une autre.

On a vu des exemples où des attaquants ont réalisé que les gens font simplement confiance au fait qu’un projet open source est utilisé par d’autres. Peut-être qu’on peut trouver un moyen d’injecter du code malicieux dans le projet, et attendre que des développeurs le tirent chez eux.

On en voyait quelques exemples ces dernières années, mais depuis un an et demi, c’est devenu un problème majeur. Chaque mois, il y a des centaines, voire des milliers d’incidents de ce type qui touchent tout le monde. Ça peut être des outils de développeur que tu utilises, des librairies open source, des extensions Chrome. Il y a plein de variations, mais c’est ça, une attaque de chaîne d’approvisionnement : tu introduis dans ta chaîne, ou dans ta façon de construire du logiciel, quelque chose qui contient des portes dérobées, du malware, du code malicieux.

Nectar : Et ça revient aux agents qui vont chercher…

Zaid : Ça peut être des agents, ça peut être des humains aussi. Ce n’est pas unique aux agents. Mais les agents ont les mêmes modes de défaillance que les humains. Ils téléchargent des outils open source. Ils installent des choses sans vraiment se demander si c’est sécuritaire. Ils peuvent être victimes de ce type d’attaques.

On fait de la recherche dans ce domaine depuis plusieurs années, et je vais en parler. Il y a un acteur particulier qui s’appelle TeamPCP, qui s’est spécialisé dans les attaques de chaîne d’approvisionnement. Ils causent énormément de dommages depuis mars de cette année. Ils avaient fait quelques attaques avant, mais depuis mars, c’est non-stop, fuite majeure après fuite majeure avec ce type de techniques.

Le cas typique d’une attaque de chaîne d’approvisionnement : Nectar veut vibe coder une nouvelle application pour Amiral Ventures. Il lance Claude Code et commence à écrire du code. Claude, à un moment, va télécharger une librairie open source pour faire sa job. Mais cette librairie est compromise. Elle a été compromise la semaine dernière par TeamPCP ou un attaquant du genre, qui a inséré du code malicieux. Claude installe le package. Le malware regarde quelles clés sont configurées sur la machine, et trouve peut-être tes identifiants GitHub. Il s’en va dans tes dépôts GitHub et insère du code qui se propage. Les autres personnes qui travaillent avec toi sur le projet, la prochaine fois qu’elles vont essayer de le compiler, vont être infectées. Et ainsi de suite.

On voit ces attaques se propager comme une traînée de poudre. Des dizaines de milliers, peut-être plus, d’identifiants GitHub ont déjà été exposés. Parmi les dommages publics qu’on connaît, Cisco a perdu des codes source propriétaires — des centaines, en fait —, incluant certains de ses derniers produits IA. Il y a de gros recours collectifs. J’ai mentionné GitHub plus tôt : c’est une entreprise à laquelle on fait tous confiance pour bien faire son travail. C’est un exemple parmi beaucoup d’autres, mais en résumé, c’est très dangereux.

Nectar : Peux-tu expliquer ce qu’est la sécurité de l’endpoint développeur ? Comment le développeur s’insère dans tout ça ?

Zaid : Depuis que les attaquants se sont mis à cibler les développeurs ou les infrastructures de développeur — ces attaques de chaîne d’approvisionnement ciblent typiquement les développeurs. Ils empoisonnent les packages open source, de plein de façons, et attendent que les développeurs les téléchargent et les installent.

Tu ne peux pas attendre que l’application soit en production, ou que le code soit poussé sur GitHub, pour le scanner là. Parce que le dommage est déjà en train de se produire sur ton portable la seconde où tu installes ce package, ou cette extension d’IDE. Le dommage est déjà fait. Ce n’est pas juste que tu as installé quelque chose : c’est là que tu as perdu tes accès GitHub, tes tokens, ton accès à une API cloud quelconque. C’est sur la machine du développeur.

Les machines de développeur sont plus spéciales que, disons, une machine au département marketing de l’entreprise. On donne typiquement aux développeurs la capacité d’installer et de désinstaller des logiciels. On ne bloque pas autant leur accès réseau, parce que leur travail l’exige — ils doivent télécharger, installer, tester. Et ils ont généralement plus de privilèges : ils peuvent pousser sur Kubernetes, se connecter à Datadog. Ils ont des clés d’API sur leurs machines, pas toujours stockées de la façon la plus sécuritaire. C’est pour ça qu’elles sont des cibles aussi attrayantes pour les hackers.

On a donc reconnu qu’une machine de développeur n’est pas n’importe quelle machine. Ce n’est pas Jane du marketing. Elle a ses propres risques uniques, et il faut les prendre en compte pour la protéger. On a développé cette technologie, la sécurité de l’endpoint développeur, qui repose sur le principe « assume the breach » — pars du principe que le développeur va, à un moment ou un autre, être victime d’une attaque de chaîne d’approvisionnement. Que peux-tu faire en amont pour limiter les dommages, le blast radius ? Et que peux-tu faire en aval pour t’assurer, si un incident se produit, que les dommages restent contenus ?

Nectar : Typiquement, c’est de la rotation de clés et ainsi de suite. C’est peut-être un bon moment pour parler de votre innovation spécifique chez Boost. Parce que ce n’est pas qu’une seule chose — vous avez plusieurs produits intéressants. Avec tout ce qui se passe dans ce monde, comment vous protégez les clients contre ces attaques ? J’ai l’impression que vous êtes aussi à la fine pointe de cet espace. Ce n’est pas commun pour une startup de votre taille d’avoir une équipe de recherche, avec François, super focalisée sur ça. Comment Boost aide ses clients à éviter de se faire pirater ?

Zaid : D’abord, on est très fiers des clients qu’on a. Certaines des plus grandes entreprises aux États-Unis, certaines des plus grandes entreprises de logiciels au monde, nous font confiance pour les aider à construire du logiciel sécuritaire et à construire du logiciel de façon sécuritaire.

On a toujours eu une équipe de recherche. François, notre VP de la recherche en sécurité, a été l’un des premiers ingénieurs à se joindre à l’entreprise — en fait, le premier. Il dirige une fonction de recherche depuis le début.

On a eu une équipe de recherche dès le jour un. Il y a eu deux incidents majeurs. L’entreprise a été fondée en 2020, mais on a vraiment été financés et démarrés fin 2021, début 2022. Deux événements se sont produits en 2020, les deux liés à la chaîne d’approvisionnement. Le premier, c’était Log4j. C’était un package très commun, utilisé par tout le monde, avec une vulnérabilité folle exploitable avec une facilité déconcertante. Toute l’industrie a essayé de trouver où elle l’utilisait. Il fallait corriger. Si tu ne corrigeais pas vite, tu devais présumer que tu étais piraté.

Le deuxième, c’était un incident très célèbre de chaîne d’approvisionnement touchant une entreprise américaine appelée SolarWinds. Les deux étaient des événements de magnitude 9 à l’échelle de Richter. L’industrie s’est réveillée. On a concentré notre recherche sur l’industrie de la chaîne d’approvisionnement dès ce moment-là.

On est très fiers du travail que l’équipe a fait. On a produit les premiers modèles d’attaque au monde — vraiment modéliser la théorie de comment les attaquants peuvent pirater l’infrastructure de développeur. On a publié plusieurs outils open source, et on a appris que certaines des plus grandes entreprises de sécurité au monde les utilisent à l’interne pour tester leurs propres produits, ainsi que certaines des plus grandes firmes de consultation. On a même découvert que Google les utilise à l’interne.

D’ailleurs, tous ces outils portent des noms de cuisine montréalaise. Un s’appelle Poutine, un autre Bagel, un autre Smoked Meat. Ce sont les trois outils open source dont on est très fiers.

On croit à la recherche en sécurité. Je pense que les bonnes entreprises de sécurité ont cette fonction. Je dis toujours : la recherche éclaire les décisions de produit. On se tient à la frontière de ce qui est possible — comment les hackers pensent, ce qu’ils peuvent faire — et on remonte le fil : comment sécuriser, comment protéger.

Maintenant, comment on aide concrètement les clients, ça se fait de plusieurs façons. La mission n’a pas changé : on veut aider les entreprises à construire du logiciel de façon sécuritaire, et à construire du logiciel sécuritaire. Il y a cinq ans, c’était DevOps, DevSecOps, le shift left, et le fait que les développeurs déploient du code 30 fois par jour. Peut-on scanner 30 fois par jour et dire aux développeurs quoi corriger, ce qui vaut la peine d’être corrigé ?

Maintenant, on a les agents qui écrivent du code, et les attaquants qui passent par le monde open source. Ce sont les deux plus gros risques. Nos technologies, nos produits, tentent vraiment d’adresser ces deux zones.

On est allés dans la machine du développeur parce que c’est là que Claude travaille. C’est là que les agents génèrent du code. Il faut être là, juste avant même que le code soit écrit, à dire à Claude comment écrire du code de façon sécuritaire. Avant que Claude décide d’amener une librairie ou un package, tu dois lui dire : « laisse-moi d’abord vérifier si c’est sécuritaire à utiliser, s’il y a du malware connu ou des signaux étranges, ou s’il y a quelque chose de mieux à utiliser. »

Une fois que le code est écrit, il y a toute une série de vérifications à faire. Et on veut aussi regarder la machine et dire : « Pourquoi ce développeur laisse-t-il ces 30 identifiants ouverts ? Si jamais il était victime d’une attaque de chaîne d’approvisionnement, les dommages seraient énormes. Disons au développeur comment corriger et améliorer la posture de la machine. »

Une fois que le code est généré et poussé dans le pipeline CI/CD habituel, on a le même type de moteur, les mêmes agents qui travaillent avec des technologies de scan à la fine pointe — certaines qu’on a construites, certaines qu’on a acquises — pour donner le même niveau de confort et de garanties à l’organisation.

Où que le code soit généré, qu’il soit écrit par un humain ou par un agent, peu importe : du point d’origine jusqu’à la production, on est là.

Nectar : Comment tu penses la question classique d’investisseur du TAM ? Parce que tu l’as mentionné, certaines des plus grandes entreprises de logiciels au monde utilisent ton produit aujourd’hui. Mais alors que le coût du logiciel tend vers zéro et que toute entreprise devient une entreprise de logiciels, il y a beaucoup plus d’entreprises de logiciels. Est-ce que c’est ça le TAM — toutes les entreprises du monde avec le temps ? Ou tu penses ça plus niche, ça doit être enterprise, plus gros, avec plusieurs développeurs ?

Zaid : Aujourd’hui, le marché est très enterprise. Les entreprises qui dépensent vraiment des montants importants pour produire du logiciel sécuritaire sont typiquement les grandes entreprises. Il y a des raisons historiques pour ça — souvent réglementaires. Si tu es dans les services financiers, on s’attend à ce que tu respectes certaines réglementations qui disent essentiellement que tu ne peux pas juste sortir du logiciel et le balancer par-dessus la clôture s’il manipule de l’information financière client. Tu dois démontrer que tu travailles à t’assurer que le logiciel ne peut pas être piraté facilement. Pareil pour la santé, et ainsi de suite. Ça tend donc à être enterprise.

Maintenant, avec l’évolution du monde, surtout avec les modèles qui deviennent très bons aux brèches et au piratage, je pense que le marché ne fait que s’étendre. Il ne va jamais rétrécir. En fait, quand les nouvelles sur Mythos sont sorties, c’était à double tranchant. D’un côté, certaines voix disaient : « c’est la fin de l’AppSec. Les modèles vont prendre le dessus. Ils savent écrire du code, ils sauront pirater du code, donc ils seront les meilleurs pour te dire comment corriger ton code. »

L’autre suite de voix disait : « le modèle qui a écrit le code ne peut pas être le modèle qui sécurise le code. » Il est entraîné d’une certaine façon, donc il faut un modèle différent pour ça.

Nectar : J’allais y venir, sur Mythos. On parlait de comment je pense que c’est une bonne chose, parce que ça met beaucoup d’emphase. À quoi Mythos est-il vraiment bon en cybersécurité, et où est-il surévalué ? Tu l’as mentionné un peu, mais peut-être qu’on peut creuser.

Zaid : On n’a pas accès à Mythos — très peu d’entreprises y ont accès —, mais on peut se fier à ce que certaines entreprises qui ont fait leurs tests ont publié. Il y a des études de cas publiques comparant Mythos et ChatGPT-5 sur les capacités cyber. À ce stade, c’est un fait : Mythos et les modèles comparables à Mythos sont très bons pour regarder du code source, trouver une série de petites choses qu’un humain aurait beaucoup de difficulté à enchaîner pour en faire un exploit fonctionnel, et créer cet exploit.

C’est acquis maintenant. C’est une bonne innovation, c’est une bonne technologie, et ça aura certainement sa place. Maintenant, écrire du logiciel, c’est complexe. Cette classe de choses que Mythos et les modèles comme Mythos peuvent trouver et prouver exploitables, c’est une fraction de tout ce qu’il faut faire pour produire du logiciel sécuritaire. Tout ce qu’on a parlé — la chaîne d’approvisionnement développeur, par exemple — ce n’est pas quelque chose dans lequel Mythos est impliqué.

Ce que je dis aux clients, c’est que Mythos et les modèles comme Mythos font partie de l’histoire, et ils devraient faire partie de l’histoire de tout le monde. Aucun fournisseur ne devrait revendiquer qu’il a construit une meilleure version de ça et qu’il faut utiliser sa solution maison. C’est un argument difficile à défendre.

Mais en même temps, Mythos est extrêmement cher. Pour te donner un exemple, récemment, un de nos clients est passé de 15 000 pull requests par mois à 30 000 dans les trois derniers mois. Ils ont doublé la quantité de code qu’ils produisent, parce qu’ils sont passés à une structure organisationnelle différente, avec plus d’agents qui écrivent du code. L’estimation pour faire tourner Mythos sur chacun de ces pull requests, c’est de l’ordre des millions de dollars — des dizaines de millions, en fait. Parce que ça coûte cher de faire tourner ce modèle qui tourne pendant des heures, en consommant d’énormes bases de code.

Ce n’est pas quelque chose que tu veux faire tourner chaque jour sur chaque ligne de code générée par un agent. Pas pour l’avenir prévisible, en tout cas. La question n’est pas « Mythos est-il une bonne technologie ? » Bien sûr que oui. La question est : comment l’utiliser de la meilleure façon en complément de tout le reste ?

Nectar : C’est une façon très éloquente de le présenter — la première fois que j’entends ce cadrage. Revenons à Boost et à ce qu’on disait sur toutes les opportunités à cause du timing de marché. Vous êtes au bon endroit, au bon moment. Pour revenir à pourquoi je suis biaisé et optimiste : pour toi, qu’est-ce qui est le plus excitant en ce moment pour les perspectives de Boost, maintenant que vous avez bouclé votre ronde et que vous avancez ? Qu’est-ce qui t’enthousiasme ?

Zaid : Beaucoup de choses nous enthousiasment. On a touché à Mythos. Une chose qu’on entend beaucoup en ce moment — et c’est pour le mieux —, c’est que la menace que les modèles IA rendent l’exploitation très rapide force les entreprises à se dire : « il faut qu’on rehausse notre niveau, et vite. » Il y a une sorte d’approbation générale : il faut devenir « Mythos-ready », s’assurer que d’ici quelques mois, quand cette technologie sera accessible aux mauvais acteurs, ce ne soit pas trivial pour eux d’entrer. Il y a donc ce gros mandat. Qu’est-ce que ça prend ? C’est une zone d’innovation.

L’autre zone où on est très actif, c’est l’endpoint développeur. On voit beaucoup de traction. C’est une préoccupation majeure. Les CISOs nous disent : « Tout le monde dans mon entreprise code. Je n’ai aucune idée de ce qu’ils téléchargent, de ce qu’ils utilisent, de comment ils le font. Il faut que je comprenne d’abord ce qui s’y passe, puis que je commence à sécuriser. » Cette zone est très prometteuse.

La dernière zone où on est aussi, je pense, assez différenciés, c’est la sécurité CI/CD. On a parlé des attaques de chaîne d’approvisionnement. Le modèle le plus courant : tu utilises des packages open source, un hacker en empoisonne un, tu l’utilises, tu es affecté, tu perds tes identifiants, et maintenant on peut t’usurper. Mais il y a plusieurs autres saveurs d’attaques de chaîne d’approvisionnement. Une d’elles : quand les entreprises pensent au logiciel qu’elles construisent, elles pensent à l’application principale, l’app qu’elles bâtissent. Ce qu’elles ne réalisent pas, c’est que ce sont aussi les apps qu’on utilise pour construire ces apps — les pipelines CI/CD. Elles ont leurs propres technologies. Les plus connues, ce sont les GitHub Workflows, GitHub Actions. C’est du code : des instructions pour prendre l’input du développeur, le tester, et si les tests passent, construire l’artefact, et si ça marche, le pousser en production.

Il s’avère que ces choses peuvent aussi être piratées. C’est juste du logiciel, et tout logiciel peut être contourné si on n’y met pas beaucoup d’efforts. On est considérés comme des experts dans ce domaine. En fait, plusieurs des outils open source que j’ai mentionnés sont spécialisés là-dedans. Et les hackers s’y mettent — ils commencent à abuser de ce type de surface d’attaque. Comme je l’ai dit, certaines des plus grandes entreprises de logiciels au monde nous font confiance pour les aider en continu à trouver, corriger et adresser ce type de problèmes de sécurité.

Il n’y a pas de pénurie. Le paysage technologique change tellement vite, et bien plus vite que la recherche en sécurité ne peut suivre. Résultat : l’industrie est obligée de monter d’un cran et de trouver des réponses innovantes à ces problèmes.

Nectar : Je pourrais continuer longtemps, mais peut-être un dernier sujet sur lequel je veux capoter avec toi : tu as mentionné le développement agile, et on dirait qu’agile n’est plus pertinent. Tu en as parlé un peu avec Fred — ce nouveau monde de comment on crée du logiciel. Donc je veux égoïstement piger dans ta tête : comment tu penses la structure d’équipe ? Avec Boost, tu as cette page blanche pour créer une nouvelle équipe. Comment les fondateurs devraient-ils penser construire des équipes logicielles aujourd’hui ?

Zaid : Excellente question, vraiment d’actualité. J’ai parlé à beaucoup de fondateurs, à de grandes entreprises, même à de grandes compagnies aériennes qui font ce dont je suis sur le point de parler. Pour les 10-15 dernières années, les meilleures équipes d’ingénierie étaient généralement structurées en pyramide fonctionnelle. Tu avais un chef d’ingénierie, puis des directeurs ou des gestionnaires, puis des « two-pizza teams » de huit à 12 personnes. Elles possédaient un projet. Elles faisaient des sprints de deux semaines, à peu près. Si tu étais vraiment fancy, tu faisais des sprints d’une semaine. C’était agile, DevOps, ship vite, ship souvent. C’était évidemment avant que les agents fassent beaucoup de travail. On n’avait pas d’agents de codage.

L’industrie s’est réveillée et a dit : « comment écrit-on du logiciel à une époque où les agents peuvent en écrire une grande partie ? Quelle est la bonne taille d’équipe ? La bonne structure d’équipe ? » Là où je vois beaucoup de convergence, c’est que les équipes de huit à 12 personnes sont trop grosses. C’est devenu le consensus général. Parce qu’on présume qu’un bon développeur, bon avec l’IA et les agents de codage, devrait être capable de piloter deux à cinq agents en continu. Il y a des outliers qui construisent des systèmes d’agents qui prompt d’autres agents, mais pour la grande majorité, on parle d’un ingénieur qui a trois à cinq agents qui travaillent en tout temps. Et donc une équipe de trois à quatre ingénieurs travaillant ensemble sur un projet, avec une bonne utilisation de l’IA, devrait pouvoir faire le travail de ce qui prenait 10 ou 12 personnes avant.

Pourquoi trois ou quatre, et pas huit ? Parce que la surcharge de communication devient un gros enjeu. Les dynamiques changent. Avant, on avait besoin de sprints de deux semaines, avec une journée de planification pour remplir le travail, parce que le goulot d’étranglement était qu’on avait besoin de temps pour écrire le code. Maintenant, dans beaucoup d’organisations restructurées, les gens te disent : « on planifie le sprint en une journée et demie, le travail est fait en une journée et demie. » Ça n’a plus de sens de garder la même vieille structure.

Tout est en train d’être renversé. J’ai parlé à des organisations très performantes — certaines des meilleures équipes d’ingénieurs sur la planète. Elles sont restructurées en équipes de trois personnes. Il n’y a plus de sprints. C’est : « voici nos objectifs pour le trimestre. » Ces petites équipes sont autonomes et habilitées. Tu travailles très étroitement avec une organisation produit, un product owner. Il n’y a plus de silos, plus de remontée puis redescente dans la chaîne de communication. Il s’agit de reconnaître que le goulot d’étranglement n’est plus l’écriture du code. C’est la vitesse à laquelle tu peux apprendre, à laquelle tu peux répondre aux demandes des clients, au feedback du marché. Et ça change tout.

Nectar : Est-ce que l’équipe logicielle est ailleurs ? Doit-elle encore être un silo ?

Zaid : Je ne pense pas que ce soit un silo. Je peux te donner un exemple — sans nommer l’entreprise — d’une grande compagnie aérienne avec laquelle on travaille. C’est une entreprise de plus de 50 ans. Elle a, à ce stade, 600 développeurs après la dernière année. Avant, elle avait une structure traditionnelle. Aujourd’hui, c’est 200 équipes de trois, complètement autonomes. Chacune possède une petite portion du produit, et on s’attend à ce qu’elles soient autonomes et qu’elles trouvent l’information où elles en ont besoin. Elles relèvent encore d’un chef d’ingénierie, juste à cause de la taille, mais en pratique, ce n’est plus centré autour d’un centre d’excellence fonctionnel.

Il y aura toujours un élément de centralisation des pratiques d’ingénierie pour rester cohérent. Mais c’est plus : organisons-nous pour la performance. Quelle est la structure organisationnelle, le corpus de connaissances, les pratiques et la culture qui nous donnent le maximum d’output ? C’est ce que tout le monde essaie de comprendre, parce qu’on présume que les entreprises qui figurent ça plus tôt auront un tel avantage en capacité d’innovation que tu n’as pas le choix. Il faut devenir bon vite, sinon tu deviens trop lent et tu deviens non pertinent.

Nectar : Ça ressemble à l’effet de la Reine rouge, non ? Tu cours plus vite pour rester à la même place. Mais il y a quelques personnes qui réussissent à se détacher.

Zaid : Exactement.

Nectar : Zaid, je pourrais te garder beaucoup plus longtemps. Peut-être une dernière question. Les leçons apprises de ta première entreprise que tu portes maintenant à Boost ? Des leçons de fondateur, du tissu cicatriciel que tu as ramené.

Zaid : Trop pour les compter, honnêtement. Pour la première entreprise, j’avais les cicatrices typiques d’un premier fondateur. « If you build it, they will come. » La tech est plus importante que de figurer le go-to-market. C’étaient les deux plus grosses. À Boost, on a démarré en travaillant avec des clients dès le jour un. J’ai écrit le prototype moi-même, avec mon cofondateur, et six mois après, il était déjà en production live chez un client. Trois ou quatre mois plus tard, il était chez six entreprises. Là, le voyage a commencé. C’était vraiment : travailler de près avec les clients dès le début, figurer le go-to-market tôt.

Même s’il y a des cicatrices et des leçons apprises, les temps ont changé. À l’époque, le cyber était encore jeune, c’était plus facile de se démarquer. Maintenant, il y a beaucoup d’entreprises de cyber en général, et il y en a qui sont très bonnes en marketing et moins en tech, mais il faut quand même compétitionner avec elles. Et l’agentique change tout. Beaucoup de leçons peuvent être transposées, mais ce qui importe le plus, c’est la compétence — parce qu’il faut s’adapter. Les conditions ne seront pas les mêmes, peu importe les leçons que tu portes avec toi.

Nectar : Zaid, j’apprécie vraiment ton temps aujourd’hui. Dernière question : si les gens veulent te joindre, en apprendre plus sur Boost et suivre l’aventure, ou se connecter avec toi ?

Zaid : Avec plaisir. boostsecurity.io, c’est l’entreprise. Si tu es plus intéressé par le côté sécurité — moins commercial, plus de la recherche intéressante —, tu peux tout trouver sur labs.boostsecurity.io. Sur LinkedIn, c’est Zaid Al Hamami. Très facile de me trouver : pas beaucoup de gens avec ce nom en cybersécurité, associés à Boost Security.

Nectar : Merci beaucoup.

Zaid : Merci à toi.