Shannon McWilliams, responsable de la distribution mondiale chez Orca Security – Série d’entretiens

Shannon McWilliams est responsable de la distribution mondiale chez Orca Security, où ses fonctions couvrent l’écosystème de partenaires de l’entreprise et les outils qui le soutiennent. Ayant auparavant fondé une société de développement logiciel, il sait traduire les besoins de l’entreprise en applications. Plus récemment, il s’est servi d’outils de développement par IA pour créer une première version de la Partner Success Platform d’Orca, en travaillant avec l’équipe de sécurité pour faire passer le projet du prototype réalisé en un week-end à un système prêt pour la mise en production.

Orca Security propose une plateforme de sécurité cloud qui aide les organisations à repérer leurs actifs, à identifier et à hiérarchiser les risques, ainsi qu’à protéger leurs environnements cloud. Ses fonctionnalités couvrent notamment les vulnérabilités, les erreurs de configuration, les identités et les autorisations, les données sensibles et la sécurité de l’IA. Dans cet entretien, McWilliams explique comment l’IA permet aux utilisateurs métier de créer des logiciels, pourquoi les applications fonctionnelles doivent tout de même faire l’objet d’un examen indépendant en matière de sécurité, et comment la découverte continue, le principe du moindre privilège et la supervision humaine peuvent aider les entreprises à gérer ce nouveau modèle de développement.

Vous avez rejoint Orca Security en tant que responsable de la distribution mondiale et, en quelques mois, vous vous êtes retrouvé à créer vous-même une nouvelle plateforme pour les partenaires à l’aide de l’IA. Quel problème cherchiez-vous initialement à résoudre, et à quel moment le projet est-il passé du stade expérimental à celui d’un outil qu’Orca pouvait réellement mettre en production ?

À mon arrivée chez Orca, on m’a notamment demandé d’examiner l’expérience globale des partenaires. Nous utilisions une plateforme tierce, mais j’ai vu qu’il était possible de proposer à nos partenaires une solution plus moderne et plus simple. J’avais une certaine expérience du développement d’applications, mais je n’étais pas développeur. Plus tôt cet été-là, j’avais travaillé sur des applications grand public avec un fournisseur tiers de plateforme de génération d’applications ; j’ai donc décidé d’expérimenter et de voir ce que je pouvais créer moi-même à l’aide de l’IA.

En un week-end, j’ai réussi à créer une première version de base de ce qui est devenu notre Partner Success Platform. Elle proposait des fonctionnalités qui allaient au-delà de celles que j’avais vues dans les portails traditionnels pour partenaires, notamment des fonctions reposant sur l’IA, comme la mise en relation avec les clients idéaux et l’accompagnement dans la conclusion des contrats. Nous avons ensuite ajouté de nombreuses autres applications à la plateforme, comme le suivi des certifications et des quiz générés par l’IA, et ludifié l’ensemble du processus de certification pour nos partenaires. Puis, nous avons commencé à synchroniser les données avec notre plateforme Salesforce. Le tournant est survenu lorsque notre PDG a vu la première version et en a reconnu le potentiel. C’est aussi à ce moment-là que nous sommes passés de l’expérimentation à la question de savoir ce qu’il faudrait concrètement pour rendre un tel outil sécurisé et prêt pour la mise en production. Notre équipe de sécurité s’est impliquée, et j’ai commencé à travailler en étroite collaboration avec Dudi Peretz pour sécuriser l’environnement, avant que ce travail soit finalement vérifié de manière indépendante par une société externe.

Vous avez auparavant fondé une société de développement logiciel et savez donc comment les applications étaient traditionnellement conçues. En quoi la création de logiciels à l’aide d’instructions en langage naturel adressées à l’IA diffère-t-elle de la gestion d’une équipe de développeurs, et dans quels domaines votre expertise du métier a-t-elle été la plus importante ?

La principale différence, c’était la rapidité. Dans le développement logiciel traditionnel, plusieurs étapes séparent généralement le moment où l’on a une idée de celui où l’on la traduit en exigences techniques, où les développeurs la réalisent, puis où l’on améliore le résultat. Avec l’IA, je pouvais décrire ce que je voulais, voir le projet prendre forme et continuer à l’affiner presque immédiatement. Le processus d’itération prend quelques minutes plutôt que les journées de réunions avec les développeurs nécessaires pour définir l’interface utilisateur souhaitée et toutes les correspondances avec les bases de données afin de créer les fonctionnalités. Avec le développement par IA, il suffit d’une consigne de 2 phrases, et non de 2 jours de réunions.

Mais cela ne supprime pas le besoin d’expertise. Cela change simplement les domaines dans lesquels cette expertise est importante. L’IA peut considérablement réduire les compétences techniques nécessaires pour créer une application, mais la personne qui la pilote doit toujours comprendre le problème à résoudre, ce qui constitue une expérience utile et ce que l’application doit, en définitive, permettre à l’entreprise d’accomplir. Ce qui m’a le plus surpris, c’est la rapidité avec laquelle on pouvait passer d’une idée à un outil fonctionnel. Des tâches comme l’analyse de données, qui pouvaient auparavant prendre des semaines, peuvent désormais éventuellement être réalisées en une journée.

Orca a décrit la première version fonctionnelle de la plateforme pour partenaires comme un outil que vous aviez créé en un seul week-end. Qu’est-ce que l’IA a pu accélérer considérablement, et quels aspects de la création d’une application prête pour la mise en production se sont révélés plus difficiles que prévu ?

L’IA a considérablement réduit le délai entre une idée et une application fonctionnelle. J’ai pu créer en un week-end des fonctionnalités qui auraient traditionnellement nécessité un processus de développement bien plus long, et continuer à ajouter et à modifier des fonctionnalités à une vitesse extraordinaire. Cette rapidité est à la fois incroyable et un peu terrifiante.

L’IA n’a pas supprimé tout ce qu’il faut faire pour qu’une application puisse être utilisée en toute sécurité en production. Dès que nous avons décidé que le projet pouvait aboutir à un véritable outil, notre équipe de sécurité a dû évaluer l’environnement, résoudre les problèmes de sécurité et s’assurer que l’application était correctement sécurisée. Nous avons finalement fait appel à une société externe pour ajouter un niveau de validation supplémentaire. L’IA a donc rendu la création incroyablement rapide, mais « ça fonctionne » et « c’est prêt à être utilisé en toute sécurité dans une entreprise » restent deux critères très différents.

Les outils de sécurité intégrés à la plateforme de développement de l’IA indiquaient que l’application était sécurisée. Pourtant, l’examen mené ensuite par Orca a révélé des problèmes liés aux autorisations et à l’accès aux données. Qu’avez-vous appris de cette expérience sur le degré de confiance que les utilisateurs métier devraient accorder aux garanties de sécurité fournies par les plateformes de développement de l’IA ?

C’est probablement l’une des principales leçons que j’ai tirées de cette expérience. La plateforme disposait de ses propres fonctions d’analyse de sécurité, qui m’ont fourni un premier niveau de référence pendant la création de l’application. Mais le processus d’examen mené avec notre équipe de sécurité m’a montré l’intérêt d’ajouter un niveau de contrôle supplémentaire, en particulier pour des aspects comme les autorisations et l’accès aux données. Cela m’a confirmé que les outils de sécurité intégrés jouent un rôle important dans le processus de développement, mais qu’ils sont plus efficaces lorsqu’ils s’accompagnent du contexte approfondi et de l’expertise qu’une équipe de sécurité dédiée peut apporter.

C’est d’autant plus important que beaucoup de personnes capables de créer aujourd’hui des applications avec l’IA ne sont pas des spécialistes de la sécurité. Elles ne savent pas forcément quelles questions poser, quelles autorisations sont trop étendues ni quelles configurations risquent d’exposer des données. Le fait que la plateforme de développement indique qu’une application est sécurisée ne peut pas marquer la fin du processus. Avant d’être publiée ou connectée à des systèmes d’entreprise sensibles, une application doit toujours faire l’objet d’un examen de sécurité complet, qui ne se limite pas à vérifier si elle satisfait simplement aux propres contrôles de la plateforme.

Lorsque l’équipe de sécurité repérait des vulnérabilités, vous pouviez souvent réinjecter ces constats dans l’environnement de développement de l’IA et générer des correctifs en quelques minutes. L’IA peut-elle transformer en profondeur la correction des problèmes de sécurité, en faisant passer celle-ci d’un long cycle de développement à un dialogue continu entre les personnes qui créent les applications et les équipes de sécurité ?

C’est l’une des possibilités les plus enthousiasmantes. Lorsque Dudi et l’équipe de sécurité repéraient des problèmes, je pouvais reprendre leurs commentaires, les intégrer directement dans l’environnement de développement de l’IA et faire générer des correctifs très rapidement. Cela pourrait créer une boucle de rétroaction beaucoup plus étroite entre la personne qui crée une application et l’équipe chargée de la sécuriser.

Par le passé, la création et la mise en production d’un logiciel pouvaient prendre beaucoup plus de temps. Aujourd’hui, quelqu’un peut apporter et publier des modifications tous les jours. La sécurité doit suivre le même rythme. L’enjeu est d’intégrer l’évaluation continue de la sécurité au processus de développement, afin de pouvoir repérer un problème, en informer la personne qui crée l’application, le corriger et réévaluer l’application beaucoup plus rapidement.

Mais corriger plus vite ne signifie pas que nous pouvons réduire le niveau d’exigence en matière de validation. L’IA peut générer rapidement un correctif ; les équipes de sécurité doivent toujours pouvoir vérifier qu’il a bien éliminé le risque et n’en a pas créé un autre.

La Partner Success Platform qui en résulte intègre des assistants d’IA, des outils d’analyse du pipeline, la génération de campagnes et l’accompagnement des ventes. Comment avez-vous déterminé quelles tâches l’IA devait prendre en charge directement et quelles décisions devaient rester entre les mains du partenaire ou du commercial ?

Pour moi, l’objectif n’était pas d’écarter l’humain du processus de partenariat ou de vente. Il s’agissait d’utiliser l’IA pour aider les personnes à avancer plus vite et à mieux exploiter les informations déjà à leur disposition. L’accompagnement des ventes en est un bon exemple : l’IA peut aider à trouver des moyens de faire progresser une occasion qui stagne dans le pipeline et fournir davantage de contexte ou suggérer une prochaine étape.

À mon sens, la distinction devient importante lorsque l’IA peut rapidement extraire des informations de systèmes disparates, en analyser la pertinence, puis les présenter sous une forme permettant à l’utilisateur d’agir. La plateforme doit rendre le partenaire ou le commercial plus efficace, tandis que l’humain reste responsable des décisions qui exigent un jugement métier. L’objectif est de réduire, grâce à l’engagement sur la plateforme, le délai entre la découverte d’une occasion et sa conclusion avec succès.

L’IA permet désormais aux employés des ventes, du marketing, des finances et d’autres services de créer leurs propres applications sans passer par l’équipe d’ingénierie. Quels contrôles minimaux de sécurité et de gouvernance devraient être mis en place avant d’autoriser ces applications à se connecter aux données clients, aux systèmes internes ou à l’infrastructure infonuagique ?

La première exigence est la visibilité. Les politiques de l’organisation devraient encourager ce type d’exploration et d’innovation, mais il est impossible de sécuriser une application dont on ignore l’existence. Encourager l’innovation incite donc davantage les employés à présenter leurs projets plutôt qu’à les développer dans l’ombre. Ensuite, les organisations doivent savoir quelles identités et quelles autorisations l’application détient, à quelles données elle peut accéder, avec quels systèmes tiers elle communique et si ces privilèges sont réellement nécessaires. Il faut ouvrir la voie à l’innovation, tout en mettant en place un processus qui accompagne les personnes innovatrices et répond aux exigences de sécurité.

Le principe du moindre privilège est particulièrement important. Nous constatons notamment que certaines applications obtiennent un accès plus étendu que nécessaire. Par ailleurs, la sécurité ne peut pas se limiter à une vérification unique avant le lancement. Lorsque les applications peuvent évoluer en permanence, les organisations doivent aussi pouvoir les réévaluer continuellement.

La gouvernance traditionnelle des logiciels était conçue pour des équipes d’ingénierie, des demandes de fusion, des cycles de publication et des pipelines de déploiement relativement contrôlés. Si les utilisateurs métier peuvent désormais modifier et déployer des applications en continu, comment le cycle de développement logiciel en entreprise doit-il évoluer ?

Le principal défi, c’est que le rythme a changé. Traditionnellement, les logiciels étaient développés et publiés au fil du temps, selon des processus relativement bien établis. Avec les outils de développement par IA, quelqu’un peut potentiellement créer et publier quelque chose de nouveau chaque jour. Dans ce contexte, les processus de sécurité et de gouvernance fondés sur des vérifications périodiques ne suffiront pas.

Nous devons évoluer vers une sécurité qui fonctionne en continu et suit le rythme du cycle de développement. Cela implique de détecter ce qui est en cours de création, de comprendre comment les applications sont configurées et connectées, de les analyser à mesure qu’elles évoluent et de fournir aux personnes qui les développent des retours exploitables qu’elles peuvent rapidement mettre en œuvre. La solution ne peut pas consister à empêcher les employés d’utiliser ces outils : les gains de productivité sont trop importants. Le défi consiste à mettre en place des garde-fous qui permettent à cette innovation de se développer en toute sécurité.

Vous avez comparé l’essor des applications créées par l’IA à une version encore plus difficile de « l’informatique fantôme ». Qu’est-ce qui rend cette nouvelle génération de logiciels fantômes potentiellement plus problématique, et comment les organisations peuvent-elles détecter des applications dont les équipes de sécurité ou informatiques ignorent peut-être même l’existence ?

Autrefois, l’informatique fantôme consistait souvent pour les employés à adopter une application SaaS que le service informatique n’avait pas approuvée. La différence aujourd’hui, c’est que les employés peuvent créer eux-mêmes l’application, et très rapidement. Quelqu’un peut concevoir une application à partir d’un compte personnel, l’intégrer à des systèmes tiers et éventuellement la connecter aux données de l’entreprise avant même que l’équipe de sécurité ne sache qu’elle existe.

C’est ce qui rend la situation particulièrement difficile : la création d’applications est devenue si facile que leur nombre et la vitesse à laquelle elles évoluent peuvent rapidement dépasser les capacités de la gouvernance traditionnelle. Les RSSI sont confrontés à la même question fondamentale : comment sécuriser quelque chose si l’on ignore peut-être jusqu’à ce qui a été créé ou comment cela est configuré ?

La détection doit donc devenir un élément central de la stratégie de sécurité. Soutenir les innovateurs, les encourager à explorer tout en leur demandant d’enregistrer leurs projets est un excellent moyen d’y parvenir. Les organisations doivent avoir une visibilité non seulement sur le code, mais aussi sur les applications qui fonctionnent dans leur environnement, les identités et les autorisations qui leur sont associées, les données auxquelles elles accèdent et les systèmes externes avec lesquels elles communiquent.

Dans quelques années, pensez-vous que la plupart des travailleurs du savoir seront devenus, d’une manière ou d’une autre, des créateurs de logiciels grâce à l’IA ? Si c’est le cas, comment cela va-t-il modifier les rôles des développeurs professionnels, des équipes de sécurité et des dirigeants d’entreprise ?

Nous nous dirigeons vers un monde où la définition de « créateur de logiciels » s’élargit considérablement. L’IA permet à des personnes qui comprennent un problème métier, mais ne sont pas des développeurs traditionnels, de transformer très rapidement une idée en application fonctionnelle. J’en ai fait l’expérience directement.

Je ne pense pas que cela rende les développeurs professionnels ou les équipes de sécurité moins importants. Cela change les domaines dans lesquels leur expertise est nécessaire. Les utilisateurs métier peuvent de plus en plus créer eux-mêmes des solutions, tandis que les développeurs peuvent se concentrer sur des problèmes techniques plus complexes et que les équipes de sécurité doivent mettre en place la visibilité et les garde-fous qui permettent à cette nouvelle génération de créateurs d’innover en toute sécurité. Le soutien et la maintenance des applications prennent également une nouvelle dimension. Les « créateurs » ne sont pas toujours les mieux placés pour en assurer la « maintenance ». Ils apportent la vision et répondent au besoin métier, mais le soutien à long terme d’une application reste une tâche qui convient mieux aux services informatiques et aux équipes applicatives. Pour les dirigeants d’entreprise, cela ouvre des perspectives considérables, mais crée aussi de nouvelles responsabilités. Si vos équipes peuvent créer des logiciels, vous devez intégrer les risques liés aux logiciels à votre réflexion sur l’activité, au lieu de les considérer comme un sujet qui ne concerne que l’ingénierie.

Merci pour cet excellent entretien. Les lecteurs qui souhaitent en savoir plus sur la sécurité du cloud, les applications créées par l’IA et la sécurisation des environnements d’entreprise peuvent consulter Orca Security.