Formation Sécurité Applicative pour les Startups

Par Jonathan Marcil.

Mise en contexte

En 2025, Cybereco a ajouté un volet de sécurité applicative à son offre destinée aux partenaires d’innovation qui composent le Carrefour Cyber.

Différentes ressources liées au démarrage d’entreprise, au financement et au développement logiciel étaient également disponibles.

La particularité de la sécurité applicative est que son apport et ses bénéfices sont indirects, contrairement aux opportunités de financement, qui sont à la base de l’existence d’une entreprise et constituent une préoccupation quotidienne pour ses dirigeants.

La sécurité applicative permet toutefois de réduire les risques de perte de réputation ou même de perte de clients. Comme les entreprises du Carrefour Cyber œuvrent dans le domaine de la cybersécurité, plusieurs possèdent déjà une certaine expertise en la matière. Toutefois, leur capacité d’obtenir un point de vue externe, particulièrement utile pour des sujets pointus comme la sécurité applicative, est souvent limitée par le temps et le budget.

Une communauté de pratique a donc été mise en place pour réunir les développeurs des différentes startups. Pour animer les rencontres, un conseiller expert en sécurité applicative, auteur du présent article, a reçu le mandat d’appuyer les partenaires d’innovation dans leur cheminement.

Un autre de ses objectifs principaux était de créer une formation en sécurité applicative adaptée aux startups.

Pour bien comprendre la réalité des startups, puisque ses dernières expériences concrètes se situaient dans de grandes entreprises depuis dix ans, les rencontres et interactions régulières avec différentes startups sont devenues une source importante d’information et d’inspiration.

Ainsi, au cours de l’année 2025, l’ensemble des activités réalisées au sein de la communauté de pratique « Développement et Sécurité Applicative » de Cybereco a servi de base à la création du contenu de la formation.

Le présent article présente la démarche suivie et explique comment celle‑ci a façonné les éléments de la formation, en plus d’avoir contribué à l’émergence d’innovations dans son exécution.

Méthodologie

L’objectif était clair : produire d’ici la fin de l’année 2025 une formation pertinente offrant une valeur concrète pour les startups.

Pour ce faire, au cours de l’année, un suivi constant de l’expert en sécurité applicative a permis des interactions, des discussions et des occasions de soutien aux startups intéressées par la sécurité applicative.

Les raisons de leur intérêt variaient grandement : certaines étaient motivées par une simple curiosité pour le sujet, d’autres par une volonté d’échanger des connaissances entre pairs. Chose certaine, il existe un biais de sélection quant aux participants, et la formation est conçue en tenant compte de ce biais : peu importe pourquoi ils s’y intéressent, les startups doivent choisir d’en apprendre davantage sur la sécurité applicative. La formation n’a pas pour objectif de convaincre qu’elle est importante; ce rôle revient aux dirigeants ou aux personnes chargées de leur démontrer qu’il vaut la peine d’y consacrer du temps, même si cela entraîne une courte pause dans le cycle de développement.

Ultimement, le choix a été fait d’offrir la formation sur deux journées complètes, ce qui représente tout de même un investissement de temps important pour de petites équipes de développement. Puisqu’elle était soutenue par Cybereco, un rabais substantiel a été accordé, sans quoi la participation de la majorité des startups aurait été compromise.

Voici donc des détails sur les activités effectuées au cours de l’année.

Rencontres communauté de pratique

Chaque semaine, une discussion ouverte portant sur des sujets d’actualité en sécurité ou sur les préoccupations techniques des participants avait lieu en ligne. En moyenne, environ huit personnes y participaient chaque semaine. La participation était entièrement optionnelle, sans aucune attente quant à la présence. Certaines startups n’y ont assisté qu’une ou deux fois, d’autres à plusieurs reprises, et certaines étaient présentes chaque semaine dès leur arrivée dans le groupe. Au total, plus d’une trentaine de personnes différentes ont échangé au cours de l’année.

Les sujets abordés étaient variés, certaines semaines étant consacrées entièrement à l’analyse de failles de sécurité affectant les produits des startups et/ou ayant une portée mondiale. Un exemple fréquent portait sur la chaîne d’approvisionnement npm et le cadre d’applications React. La liste suivante, loin d’être exhaustive, illustre le niveau parfois très avancé des discussions :

Authentification et identité (NIST et Passkeys)
Sécurité Applicative et vulnérabilités (React CVE-2025-55182 et CVE-2025-66478)
Validation de schémas de données pour les API
Gestion des paquets NPM et sécurité de la chaîne d’approvisionnement
Sécurité des LLM et développement Web
Protection des modèles AI/ML et API
Architecture et sécurité avec Next.js
Débat : Modèles d’hébergement (VPS versus Cloud)
Gestion des secrets avec Docker
Fin du support OCSP par Let’s Encrypt
Micro-services, monolithe, et mono repo

Des notes comprenant des liens et un sommaire étaient publiées sur le canal de communication commun aux participants. Ce partage offrait un aperçu des pratiques techniques des autres équipes, des outils qu’elles utilisaient, etc. Ainsi, même sans participer aux sessions en direct, les startups pouvaient bénéficier d’une vue d’ensemble sur les pratiques des autres.

Sondage technique

Un sondage technique a été envoyé et comportait plusieurs questions, dont les suivantes :

Nombre de développeurs équivalent à temps plein
Avez-vous déjà fait un partage de connaissances au niveau technique avec d’autres entreprises du Carrefour Cyber?
Avez-vous déjà eu besoin d’une certification ou de prouver votre diligence en sécurité pour compléter une vente?
Quel budget temps pourriez-vous allouer à l’amélioration de la sécurité de votre application?
Quel est votre plus grand défi à surmonter en développement et sécurité applicative?
Quel(s) LLM utilisez-vous pour assister au développement?
Est-ce que vous payez pour l’accès à un LLM?
Quel est votre outil de communication primaire à l’intérieur de votre équipe de développement?
Quelles sont les composantes de votre application incluant langage et Framework?
Quelles solutions de stockage de données utilisez-vous?
Quel est le cloud provider principal que vous utilisez?
Quelles sont vos dépendances externes principales?
Dans quelle(s) catégorie(s) est votre infrastructure?
Qui est en contrôle administratif de l’infrastructure?
Quel est votre environnement de développement local?
Quel est votre environnement DevOps?
Quels sont les outils de sécurité utilisés durant votre cycle de développement?
Nous avons notre infrastructure en tant que code?

Ceci a permis de savoir exactement quelles technologies étaient utilisées par les douze (12) startups qui ont répondu, ainsi que d’obtenir des détails sur leurs façons de fonctionner.

Analyse de besoins

L’expert a rencontré les startups pour comprendre leur position par rapport à la sécurité applicative. La startup se présente, et on discute des besoins de sécurité qu’elle pense avoir, ou encore on la guide sur ceux qui semblent prioritaires.

Ces rencontres ont permis de clarifier certaines réponses du sondage et d’en apprendre davantage sur les technologies utilisées. Elles ont aussi permis de déterminer les autres activités décrites ci‑après.

Environ six (6) startups ont été rencontrées à cette phase.

Revue de l’architecture

Pour un minimum de trois startups, un besoin de réviser les décisions internes liées à l’architecture a été soulevé lors de la phase d’analyse. Une ou deux rencontres ont été planifiées afin de mieux comprendre leur architecture et d’identifier les points à améliorer en matière de sécurité.

Pour que cette activité soit pertinente, voire même possible, il fallait qu’une startup soit justement en période de questionnement sur ses choix architecturaux au moment de la rencontre initiale, ce qui explique le faible nombre de participations. Nous avons poussé jusqu’à deux rencontres avec une seule startup, alors que les autres ont discuté des détails de leur architecture dans d’autres rencontres non dédiées à ce sujet.

Ces rencontres ont permis d’entrer dans les détails et de comprendre le niveau de compétence ainsi que les défis présents dans les startups.

Revue des pratiques de sécurité applicative

Deux autres startups ont préféré revoir leurs pratiques générales plutôt que leur architecture. Les pratiques peuvent être modifiées et adaptées plus facilement que les architectures, surtout lorsqu’il s’agit d’améliorations.

Dans ce cas, nous avons examiné les environnements des développeurs, l’utilisation des outils de sécurité, des cadres d’applications et des langages de programmation. Nous avons observé et noté leur influence sur les risques liés à la sécurité applicative.

AppSec sur le support en développement

Cybereco offrait aussi des ressources en développement supplémentaires aux effectifs présents dans les startups. Leur objectif était de fournir des modules de code, des démos ou encore une expertise en développement. Dans certains cas, une revue de sécurité applicative a été effectuée sur les livrables, et plusieurs rencontres organiques ont également eu lieu pour discuter de technologie, de choix à prendre et de certains enjeux de sécurité.

Donc, au cours de l’année, cette relation entre les développeurs et le conseiller en sécurité applicative a apporté une vision sur les besoins de certaines startups, ainsi que sur les méthodologies utilisées, reflétant leur niveau de vélocité et les limitations propres au contexte d’une startup.

Mentorat

Pour une startup, la présence d’une personne elle‑même en croissance dans l’équipe était moins alignée avec les sujets des rencontres de la communauté de pratique, qui étaient souvent de niveau avancé. Nous avons donc opté pour des rencontres ponctuelles sur plusieurs semaines, dans le but de soutenir cette personne. La réalité de celle‑ci l’amenait à suivre les décisions technologiques des dirigeants et autres responsables, tout en souhaitant apporter sa propre contribution à la sécurité.

Des designs et certaines sections d’architecture ont été revus, ainsi que des décisions liées aux choix technologiques. La liberté de choix dans une startup est très grande, ce qui rend difficile pour un débutant de savoir quoi privilégier ou comment penser sécurité applicative au moment de prendre des décisions.

Ces rencontres ont également couvert le développement professionnel et l’acquisition d’un instinct en sécurité applicative permettant d’identifier les opportunités d’action.

Résultats

Un document intérimaire sous forme de guide intitulé « Sécurité Applicative pour les Startups » a été produit avant la formation elle‑même. Ce guide propose un exemple et une vue d’ensemble des concepts de sécurité applicative sous forme d’objectifs, de priorités et d’actions recommandées.

Pour ce qui est de la formation elle‑même, elle a été divisée en plusieurs modules, qui couvrent la majorité des sujets retenus à la suite des activités effectuées durant l’année, tels que définis dans la section précédente.

Voici une description initiale des sujets présentés aux participants, que nous couvrirons ensuite plus en détail pour présenter les résultats de la méthodologie.

Sécurité Applicative et bonnes pratiques

Introduction aux concepts de sécurité applicative ainsi que survol des bonnes pratiques. Un exercice de partage des connaissances et discussion entre les participants aura lieu.

Développement sécuritaire – OWASP Top 10 Proactive Controls

Parcours d’une liste de contrôles de sécurité concrets à implémenter pour les développeurs dans le but de bâtir des applications sécuritaires dès le départ.

Outils de Sécurité Applicative

Intégrez directement dans votre pipeline de CI/CD des outils pour balayer le code, les librairies balayage de secrets. Vous repartirez avec des outils « open source », installés et fonctionnels.

Sécurité des APIs

Un atelier technique approfondi sur la sécurité des APIs, de l’autorisation à la validation des données. L’environnement sera interactif, incluant des exercices de type « Capture The Flag » et des exemples de code en Python et TypeScript.

Développement sécuritaire – Revue de code par un LLM

Cet atelier pratique s’appuie sur les concepts vus dans les modules « Sécurité Applicative et bonnes pratiques » et « OWASP Top 10 Proactive Controls » pour vous montrer comment transformer un LLM en un puissant assistant de revue de sécurité.

Développement sécuritaire – Attaques sur la chaîne d’approvisionnement

En réponse aux attaques récentes sur l’écosystème JavaScript, ce module introduit les menaces et explore des stratégies de défense concrètes pour sécuriser l’environnement npm.

Sécurité Applicative et bonnes pratiques

La définition de la sécurité applicative et ce qu’il faut faire pour améliorer sa posture en entreprise varie souvent d’une personne à l’autre. Certaines startups connaissaient seulement le principe général de « cybersécurité » sans distinguer clairement la sécurité opérationnelle, infonuagique ou applicative.

Contexte / Phases

Pour bien situer le début de la formation durant ce module, une section a été créée sur le contexte des startups, utilisée pour organiser le contenu en général. On parle ici, par exemple, de reconnaître le besoin de vélocité ainsi que les budgets limités, voire inexistants, pour les outils de sécurité et l’aide externe.

Pour bien saisir le niveau de maturité de la startup, dans le but de déterminer jusqu’à quel point il faut prioriser la sécurité applicative, une liste de phases a été créée:

Phase « Idéation »: Idée et Conception
Phase « Validation »: Preuve de Concept et Produit Minimal Viable
Phase « Lancement »: Mise en marché
Phase « Croissance »: Mise à l’échelle
Phase « Maturité »: Optimisation et Expansion
Phase « Transition »: Acquisition, IPO

Une série de cartes aide-mémoires ont été produite. Durant la formation ces phases ont été utilisé lorsque les startups se sont présentées afin de savoir où ils en sont dans leur cheminement. Ceci a permis aux startups, qui ne se connaissent pas, de parler ensemble et d’identifier d’autres en phase similaire ou encore de partager des connaissances d’une phase antérieur si en phase plus avancée.

Principes de sécurité

La formation a obtenu un certain succès à inculquer une mentalité de sécurité applicative aux participants en leur présentant les principes de sécurité. Bien qu’il n’y ait pas de lien direct avec les observations sur le terrain, les nombreuses discussions menées durant la communauté de pratique ont permis d’aborder le sujet différemment.

Bien que les startups soient très orientées vers des résultats concrets et rapides, une ouverture à discuter des concepts fondamentaux était présente. C’est ainsi que l’idée d’introduire et de détailler les principes de sécurité est née.

D’autres parties de la formation ont été conçues en gardant ces principes en tête : les revues par LLM en étaient inspirées, et ils servaient aussi de point de comparaison pour discuter du bien‑fondé de différentes décisions architecturales.

D’autres cartes d’aide-mémoires ont été créées à ce sujet:

Activités de sécurité applicative

Pour cette partie, les activités elles‑mêmes n’ont pas été définies par les interactions avec les startups : si une startup en effectue une, il n’existe pas de processus officiel nommé; il s’agit plutôt d’une personne qui passe à l’action de son propre chef, et l’activité est ainsi complétée.

Cependant, les rencontres de la communauté de pratique ont permis de partager un grand nombre d’outils. Lorsqu’une entreprise est limitée par le temps, la plupart de ses activités reposent sur l’utilisation d’outils automatisés open source, qui donnent d’excellents résultats.

Des cartes d’aide‑mémoire ont été créées, mais en toute transparence, il s’agit des cartes les moins, voire pas du tout, utilisées lors de la formation. Les équipes préféraient se concentrer sur les principes et discuter de leur pile technologique plutôt que des activités de sécurité applicative.

Pour un développeur ayant besoin d’une grande vélocité de livraison, la nomenclature de ce qu’il faut faire est moins importante que de simplement effectuer les activités elles‑mêmes. Ainsi, à part exécuter des tests via des outils et peut‑être commander des tests d’intrusion, on observe un intérêt moindre envers les autres types d’activités.

La liste proposée était:

Revue de Code
Analyse de Risque
Tests d’intrusions
Tests Ciblés
Cas d’Abus
Exigences Sécurité
Opérations de Sécurité
Tests Internes
Scan de Secrets
Scan des Dépendances
Analyse Statique (LLM)
Analyse Infra-as-Code

Choix technologique et architecturaux

Bien caché au milieu de cet article, ce sujet s’est avéré une trouvaille inédite de la formation. Il est le résultat d’une recollection de toutes les étapes de la démarche réalisée durant l’année; du sondage au mentorat, en passant par la revue de l’architecture.

Contrairement aux autres sujets, aucune référence en ligne n’a été consultée pour confirmer son utilité. Mais à force d’interagir et d’observer les startups, il est vite devenu évident que certains choix technologiques influencent directement les risques liés à la sécurité applicative.

Par exemple: le choix du langage. Certains langages sont plus difficiles à maîtriser, ou encore possèdent une base moins sécuritaire que d’autres, ce qui fait en sorte qu’ils demandent plus de temps et d’efforts à sécuriser. Les cadres d’applications découlent également des langages, et donc le choix initial influence jusqu’à ce niveau. Les détails de documentation varient d’un cadre à l’autre et permettent de savoir comment coder une application pour qu’elle soit sécuritaire. Ainsi, jusque dans la ligne de code finale ou les configurations du cadre d’applications, le choix du langage va ultimement guider les bonnes pratiques à suivre, certaines étant plus faciles à sécuriser que d’autres.

Le choix des composantes est un autre bon exemple. Utiliser un API Gateway à la place d’une implémentation plus simple va dicter ce qui se produira dans une phase ultérieure d’une startup. La plupart des développeurs qui n’ont pas l’expérience de systèmes évoluant sur plusieurs années doivent garder en tête qu’un choix peut être le bon au départ, car il est rapide et répond aux besoins immédiats, mais qu’il faudra éventuellement adopter une solution plus robuste. Une startup peut commencer en phase de validation avec une application simple et un seul API, puis devoir ajouter un API Gateway en phase de croissance, voire même au lancement, afin d’obtenir une meilleure sécurité et des contrôles plus efficaces et plus faciles à implémenter.

Le sujet de l’influence des choix technologiques sur la sécurité est peu populaire en ligne, probablement en raison des débats interminables que cela pourrait provoquer sur les forums de discussion. Toutefois, sur le terrain, il s’avère pertinent d’obtenir des recommandations à ce niveau.

Sécurité de la chaîne d’approvisionnement

À la suite des rencontres de la communauté de pratique où nous discutions des failles de npm et des librairies Node.js compromises, nous avons décidé d’ajouter un module supplémentaire à la formation pour offrir des recommandations plus précises à ce sujet.

En plus de guider les participants vers des configurations optimales, nous avons aussi fait référence à des spécifications et à des outils permettant d’évaluer le risque de sécurité des librairies.

Les participants à la formation avaient plusieurs modules supplémentaires à choisir, et la sécurité de la chaîne d’approvisionnement s’est retrouvée au premier rang. Du point de vue des piles technologiques, JavaScript et Node.js/npm étaient présents dans pratiquement toutes les startups; c’est d’ailleurs la seule technologie adoptée unanimement selon le sondage.

Outils de sécurité applicative

Plusieurs discussions ont eu lieu dans les réunions de la communauté de pratique sur ce sujet. L’intérêt pour découvrir de bons outils open source était très grand.

Durant la formation, nous avons décidé de mettre les outils en pratique directement, avec une session où nous les présentions d’abord, puis où les équipes les utilisaient immédiatement sur leur propre code source. Pour certains, l’intégration avait déjà été faite, mais les conseils de configuration des experts ont été utiles.

L’interprétation des résultats, notamment pour valider la légitimité des trouvailles, était cruciale durant la formation. Les développeurs ont fait bon usage de l’expertise disponible pour analyser l’impact et appliquer les mesures correctives.

Revue de code par un LLM

Durant l’année, les discussions sur le choix de LLM comme technologie, leur impact sur le code et divers conseils d’utilisation ont été omniprésentes.

Nous avons fini par comprendre quel LLM était utilisé et comment les startups s’en servaient. Toutefois, personne n’avait constaté qu’ils pouvaient aussi être utilisés pour la sécurité.

Nous avons donc proposé un exercice : est‑il possible d’utiliser un LLM pour la revue de sécurité? Les startups, très ouvertes à l’expérimentation, se sont prêtées au jeu avec enthousiasme.

Les résultats parlent d’eux‑mêmes : en moins de quinze minutes, nous avons trouvé, et parfois corrigé, plusieurs failles dans le code source de différentes équipes.

C’est, de loin, la découverte offrant le meilleur retour sur investissement de toute la formation, rendue possible grâce à l’agilité et à l’ouverture des startups.

Un concept clé ayant permis cette rapidité est que le module proposait déjà des requêtes préfabriquées pour LLM, basées sur les concepts vus dans les modules précédents. Les participants n’avaient qu’à utiliser ces requêtes dans leur outil LLM déjà en place pour obtenir des résultats liés directement aux éléments appris durant la formation.

Sécurité des API

Autre sujet retenu comme universel : pratiquement toutes les startups possédaient une architecture contenant des API. Ce sujet était difficile à approfondir lors des rencontres de la communauté de pratique, puisque les détails importants se situent au niveau de l’implémentation.

De plus, le besoin d’aller plus loin dans certains concepts dépassait le temps prévu pour les revues d’architecture, qui duraient environ une heure.

La formation devait donc inclure une partie plus technique, permettant à chacun de progresser à son propre rythme.

Conclusion

Sélection

Plusieurs parties de la formation, comme les outils de sécurité applicative ou le contenu tiré de références OWASP, ont été produites sans nécessairement se baser sur les apprentissages faits avec les startups. Cependant, la sélection des sujets a tenu compte des réalités, des besoins et de la vélocité des équipes rencontrées.

Pour maintenir la formation sur une période de deux jours, plusieurs sujets pertinents n’ont pas été retenus. Certains étaient répartis entre différentes technologies ou fournisseurs sans qu’une majorité claire se dégage parmi les participants.

Par exemple, les détails techniques liés à la sécurité infonuagique, bien qu’importants, dépendent fortement du fournisseur choisi. Comme les startups utilisaient des plateformes différentes, parfois même locales ou autogérées, une formation pertinente aurait nécessité de couvrir AWS, GCP et Azure en profondeur, ce qui excédait largement le temps disponible.

Ayant une durée très limitée, la formation a donc ignoré des sujets qui ne faisaient pas l’unanimité au niveau des priorités. Ces sujets sont quand même pertinents pour la sécurité applicative et pourraient être choisis en fonction des groupes d’audience ciblés.

Voici une liste des sujets non retenus et raisons:

Sécurité Infonuagique (Cloud Security)

Pour aborder ce sujet de manière pertinente, il serait indispensable de couvrir les spécificités de chaque fournisseur majeur (AWS, GCP, Azure), ce qui excède le temps alloué à la formation. Le programme privilégie des principes de sécurité génériques et portables qui s’appliquent indépendamment de l’infrastructure sous-jacente, une approche qui correspond mieux à la réalité des startups.

Modélisation des Menaces (Threat Modeling)

Bien qu’elle soit une pratique essentielle, la modélisation des menaces est souvent une démarche avancée pour une jeune organisation. Pour les startups, une approche plus directe, axée sur la mise en place de contrôles de sécurité fondamentaux, a été jugée plus appropriée et efficace.

Attaques par Injection et Sécurité Offensive

La compréhension des vecteurs d’attaques est certes utile, mais elle constitue un sujet avancé. Le programme se concentre sur les pratiques de développement proactives (telles que le OWASP Top 10 Proactive Controls) et l’outillage préventif, qui permettent de mitiger rapidement plusieurs de ces risques.

Sécurité de GitHub et GitHub Actions

Une forte majorité des startups sondées utilisent cette plateforme. Cependant, afin de préserver le caractère agnostique de la formation, aucun sujet lié à un fournisseur spécifique n’a été retenu.

WebSocket

Il s’agit d’un protocole de communication spécialisé. Son étude approfondie aurait complexifié le curriculum au détriment de la compréhension des principes fondamentaux de la sécurité des API, qui sont plus universellement applicables.

Sécurité Mobile

La plupart des startups développent des interfaces web, même lorsqu’une application mobile est offerte. Les aspects les plus critiques, comme l’authentification et l’autorisation, sont déjà traités en profondeur dans les modules sur la sécurité des API, qui constituent le socle de la sécurité mobile. Les détails techniques spécifiques aux plateformes mobiles sont trop pointus pour cette formation d’introduction.

Finalement, les sujets suivants n’ont pas été sélectionnés par les participants:

Sécurité des conteneurs (Docker, Kubernetes)
Génération de code sécuritaire avec LLM (React)

Apports indirects

Bien que le cœur de la formation réside dans ses sujets techniques, plusieurs éléments visaient aussi à encourager les compétences comportementales, telles que la collaboration et le partage.

Le temps alloué aux discussions entre les différentes startups a permis de recréer un climat rappelant la communauté de pratique, dans lequel les échanges d’expériences similaires étaient particulièrement enrichissants pour tous.

De plus, la majorité des ateliers étaient conçus pour utiliser le code source réel des participants, ce qui a permis d’obtenir des résultats concrets immédiatement pendant la formation. Cela a créé un apprentissage plus solide tout en générant des corrections qui diminuaient directement les risques de sécurité.

Adaptations

Il va de soi que cette formation, bien que ciblé envers les startups, peut aussi être modifiée ou adaptée à deux niveaux : par technologies similaires, et pour une entreprise qui n’est pas une startup mais qui est ouverte à améliorer la vélocité de ses équipes en sécurité applicative.

Permettre la sélection de modules supplémentaires en complément au cursus de base s’est révélé une bonne solution pour maximiser la pertinence auprès de différents types d’auditoires.

Lors d’une présentation pilote faite auprès de grandes entreprises, celles‑ci ont également obtenu des résultats concrets. Malgré des processus plus complexes, les développeurs conservent une certaine liberté d’action dans leur cycle de développement, ce qui contribue à leur capacité de livrer efficacement.

Cette liberté permet aux développeurs d’initier eux‑mêmes des actions pour améliorer la qualité du code. La sécurité applicative est l’un de ces aspects de qualité lorsqu’on prend le temps d’en expliquer les principes fondamentaux et de présenter les outils permettant d’identifier les problèmes.

Pour la revue de code assistée par LLM, la majorité des entreprises utilisaient déjà des outils intégrés à leurs pratiques. Ce qui constituait une véritable innovation, c’est la manière de relier ces outils aux concepts appris durant la formation.

Les résultats obtenus ont été une révélation pour plusieurs, avec un retour sur investissement exceptionnel : obtenir des résultats en quinze minutes après seulement une heure de formation est peut-être pratique courante pour une startup, mais demeure impressionnant, et bienvenu, dans de grandes entreprises.