Améliorer la résilience de votre organisation grâce à la sécurité

0:00 Bonjour à toutes et tous. Je suis Nathalie Lamy. J'ai le plaisir aujourd'hui de présenter cette masterclass qu'on vous propose en amont de la conférence des 2 et 3 décembre de Tech.Rocks, qui sera sur le sujet de la résilience et des écosystèmes en mouvement. J'ai le plaisir aujourd'hui d'accueillir Olivier Dupré, qui est Solution Architect chez GitLab, et qui va nous parler de comment chez GitLab on peut améliorer la résilience des systèmes et des organisations à travers la sécurité. Avant de laisser la parole à Olivier, je précise qu'il est encore temps de prendre votre place pour la conférence des 2 et 3 décembre, où on pourra explorer d'autres manières d'améliorer notre résilience. Olivier Dupré, à toi. Merci beaucoup, Nathalie. Elle m'a déjà tout présenté. Je suis un des solutions architectes chez GitLab.

1:03 Et donc, d'ici quelques minutes, je vous partagerai notre vision et comment on peut améliorer la résilience de vos systèmes. Après la sécurité, on va voir en quoi la sécurité est une des briques nécessaires. Pour achever la résilience et pour atteindre la résilience plus que l'achever. On va se laisser encore quelques minutes. On se disait qu'on commencerait d'ici midi 5, le temps à ce que chacune et chacun ait le temps de se connecter. Le système peut parfois faire quelques validations techniques avant de vous laisser rentrer. On va laisser à chacun et chacune le temps d'aller se chercher un verre d'eau, un café. Donc, je referai mon lancement à 10h. Je me suis précipitée. J'ai vu 4, 3, 2, 1, parce qu'il y a le timing qui s'affiche au début, 4, 3, 2, 1. J'ai dit, allez, on y va. C'est ça. Non, c'est très bien ça. Ça ne laisse pas un espace blanc.

2:06 C'était très bien. Et je vois qu'Alexandre nous fait la vélo-tipi finalement. Merci beaucoup, Alex. On a quelques premiers participants qui... Qui parle dans le chat. Vous verrez, on a plusieurs moyens de discuter. Il y a un chat. On va passer sur la définition du chat. Et il y en a également une section questions pour être plus ciblé sur les questions et permettre, nous, de les tracer de notre côté aussi. Voir ce qui a été posé comme question et comment on y a répondu, si on y a répondu aussi. Effectivement, quand j'ai parlé, il n'y avait a priori encore personne. C'était un entraînement. Alors, ceux qui rejoignent, n'ayez pas peur si je ne parle pas encore.

3:14 On attend qu'il y ait un peu plus de monde qui se connecte. Si vous voulez. Dans la tchat. Oui, j'ai dit 10h05, bravo. Non, mais je suis un peu… C'est le décalage horaire, ça? C'est comme si je venais de me lever. Vous savez même pas le mot. Je promets que je suis levée depuis longtemps. Je ne suis pas levée. C'est peut-être pour ça justement que tu es décadente. Tu te levais trop tôt. Allez, on se laisse encore une petite minute et puis on démarre.

5:00 Du coup, je vais commencer. Donc, je recommence ce que j'ai dit au début. Donc, bonjour à toutes et tous. Je m'appelle Nathalie Lamy. J'ai été pendant 26 ans VP Engineering dans l'industrie électronique et informatique et notamment dans les objets connectés chez Netatmo. Et cette année, je suis également coprésidente du comité de contenu de la conférence qui aura lieu les 2 et 3 décembre, la conférence Tech.Rocks. Donc, j'ai travaillé avec le comité de contenu pour vous proposer toutes les conférences qui auront lieu ces deux jours-là. Et c'est en amont, justement, de cette conférence qu'on vous propose aujourd'hui la première masterclass. Donc, on ouvre officiellement le programme aujourd'hui avec Olivier Dupré, qui est Solution Architect chez GitLab. Et avant de lui donner la parole, je tiens à rappeler qu'il est toujours temps de prendre vos places pour les 2 et 3 décembre. Aujourd'hui, vous allez déjà avoir un aperçu avec Olivier pour vous donner envie d'en connaître plus sur différentes solutions pour

6:06 aborder la résilience, que ce soit la résilience ici de nos systèmes et de nos organisations, mais pendant la conférence aussi la résilience individuelle. Il y a plein d'aspects et d'angles d'attaque qu'on a voulu vous proposer dans cette conférence. Je vais laisser la main à Olivier, qui, comme vous le voyez ici sur l'écran, à vous parler de la résilience et de la sécurité, des liens qu'il fait entre les deux. Voilà, je vais te laisser la parole, Olivier. Je te laisse te présenter peut-être un peu plus et lancer la masterclass. Merci. Et merci beaucoup Nathalie. Donc, on a été chez Olivier Dupré, donc Solution Architect chez GitLab. Je sais que certains sur cet événement me connaissent, pour avoir été d'anciens collègues. Vous pouvez aussi me connaître peut-être parce que j'organise deux conférences sur Toulouse, qui sont le DevFest et Cloud Toulouse.

7:08 Ce sont des événements où vous m'avez déjà vu, où vous me verrez aussi au DevSecOps for the Tour qu'organise GitLab dans deux jours. À Paris 14ème et c'est pareil, je serai sur place dans deux jours s'il y en a qui sont là-bas. Et aujourd'hui, je vais en effet vous parler résilience et surtout je vais essayer de vous montrer comment la sécurité est un des axes qui participent à la résilience et à quel point c'est important d'avoir un système sécurisé pour être sûr d'assurer sa résilience. Et merci, Alexandre, d'avoir détaillé mes années d'expérience dans la plate. Alors, qui suis-je? On l'a déjà un peu introduit tout à l'heure. Donc, co-organisateur du DevFest Toulouse et de Cloud Toulouse. Vous pouvez me retrouver sur LinkedIn avec le pseudo, vous voyez, le pseudo, l'IBL, je ne sais pas comment on dit, le Handel peut-être, qu'on voit apparaître à l'écran.

8:10 Et avant ça, j'ai travaillé en tant que Cloud Solution Architect, en tant que Solution Architect, en tant qu'Architect et Formateur Sécurité. Et puis, j'ai encore d'autres expériences les années précédentes. Du coup, j'ai quelques bases solides, on va dire, pour parler sécurité et DevOps. C'est un des domaines dans lesquels je gravite depuis largement plus de 10 ans. Notre agenda du jour, on va parler, je vais faire en cinq temps. On va commencer par rappeler quelques faits brutaux, j'ai envie de dire, sur la sécurité et son coût. On va ensuite essayer de déterminer un petit peu quel lien on peut faire entre ces faits qu'on vient de voir et la résilience. Et une fois qu'on aura vu ces liens, OK, il y a des liens, mais qu'est-ce qu'on en fait? Qu'est-ce qu'on fait dans tout ça?

9:12 Et comment on améliore finalement la résilience à travers la sécurité? Et avant de passer sur la démo qui permettra de conclure la partie théorique et passer sur la partie un peu plus pratique pour vous montrer rapidement une des choses qu'on peut faire à travers GitLab. Je vous parlais d'IA, c'est le sujet chaud du moment, on ne peut pas l'éviter évidemment. Et on a évidemment l'IA de forts impacts aussi bien sur la résilience que sur la sécurité. Et on verra quels peuvent être ses impacts et puis qu'est-ce qu'on en fait chez GitLab. Et quels sont les angles d'attaque qu'on prend sur l'IA et comment on manipule tout ça. Alors, l'effet sur... la sécurité en cinq chiffres. J'ai décidé de m'axer sur ces cinq-là. Le coût moyen d'une suite de données, aujourd'hui, 4 millions d'euros. Un peu plus de 4 millions d'euros quand il y a une suite de données. On en a tous entendu parler.

10:14 SFR et Free, très récemment, pour ne citer que deux, mais je ne fais pas de... De shaming parce que j'ai envie de dire que toutes les entreprises y passent, en tout cas toutes les entreprises sont la cible des attaques à minima. Donc voilà, il y en a qui sont plus célèbres que d'autres et qui font plus de bruit, mais c'est un coût et c'est un coût qui est très important de se faire pirater. Et quand je dis toutes les entreprises y passent, rien que sur le troisième trimestre de cette année, On a eu 17 millions de comptes qui ont été piratés. Et typiquement, il y en a eu 4 millions avec Free. Ce n'est pas le troisième trimestre, c'est le quatrième. Donc, ces 4 millions-là ne sont même pas inclus dans ce chiffre-là. Et c'est un chiffre qui a une croissance de 30% depuis le trimestre précédent. Donc, on a une trajectoire qui est... Toujours croissante si on regarde un petit peu l'historique, mis à part quelques petits sursauts par chance, on va dire, dans le temps. Mais globalement, le piratage, ça se porte plutôt bien et on est de plus en plus victime.

11:19 J'ai évoqué l'IA tout à l'heure, et quand on parle d'IA, aujourd'hui on génère de plus en plus de col. Il y a une étude qui est sortie il y a peut-être deux mois, je ne suis plus très sûr. sur du temps exact, c'était environ il y a deux mois, 41% de bugs en plus depuis qu'on utilise massivement la Gen AI en termes de code. Qui dit plus de bugs, dit moins de résilience. Le lien semble assez évident et donc on reviendra dessus, mais on verra quels peuvent être les impacts et du coup, comment mitiger ça. Parmi les différentes attaques, il y en a une qui est en croissance dramatique, si je peux le dire comme ça. Ce sont les attaques DDoS, les dénis de service. On a une augmentation de 117% en 2023. Donc, on a plus que doublé par rapport à l'année précédente. Je vous disais tout à l'heure qu'on a une courbe d'augmentation des attaques. DDoS fait partie de celles qui ont une très forte augmentation.

12:24 Et qu'est-ce que c'est le DDoS? Dénis de service, c'est-à-dire qu'on fait tomber vos services, on fait tomber votre applicatif, on fait tomber votre récit. Et donc, ça veut dire qu'on n'a plus de résilience. On n'a pas atteint l'objectif de notre résilience. Ce n'est pas parce qu'un serveur a brûlé, ce n'est pas parce qu'un data server n'est plus visible, c'est vraiment parce qu'il est attaqué. Et donc, mon service n'est plus rendu. Et c'est ce qu'on cherche à avoir quand on cherche à atteindre la résilience et l'excellence opérationnelle. Et dans la même veine, parmi les autres attaques qui vont croissant, ce sont tous les ransomware. On va dire que 55% de... 2023. Tout le chiffre que je donne, là, ils sont issus d'un rapport IBM qui est sorti l'an dernier. Pour ça, c'est que le chiffre de 2023. Ils n'ont pas encore sorti sur 2024, évidemment. Et là encore, quand on parle ransomware, si on a un ransomware qui arrive et qui chiffre toutes les données qu'on a sur notre SI, qui chiffre les assets de nos clients, etc., peu importe, et qui demande donc une rançon pour être déchiffré,

13:27 C'est-à-dire que notre service n'est plus rendu. Tout le temps où les données sont chiffrées, etc., on a dégradé notre résilience. Et donc, à travers ces cinq chiffres, on voit déjà qu'il y a un intérêt certain à venir se protéger de tout ça pour permettre d'atteindre la résilience et de continuer à rendre le service à nos clients. Donc du coup, le lien avec la résilience, j'ai commencé à le teaser un petit peu et vous commencez à le voir. Imaginons dans votre système, et je suis sûr que ça parle à beaucoup d'entre vous, ce ne sont pas des choses qui sont trop étrangères. Vous avez mis en place du backup et du restore, vous avez établi éventuellement un disaster de poverty plan. Donc, comment je rétablis mon service une fois qu'il est tombé? Donc ça, vous êtes parfaitement à jour, et c'est tant mieux. Vous êtes capable de relancer tous vos services. Mettons que vous avez votre production, qui est notre schéma de gauche, avec tous les services qui sont dedans, de la donnée des services, du load balancing, peu importe la couche de services que vous avez.

14:29 C'est votre produit. vous êtes capable automatiquement de retomber sur un autre serveur, éventuellement sur d'autres data centers, pour faire face à tout type de problème. On a vu par exemple récemment des inondations à Valence en Espagne. Tout data center présent là-bas, fatalement, ne marche plus. Donc, être capable d'automatiquement balancer sur d'autres data centers situés ailleurs, ça permet d'assurer le service. Mais multiplier toute votre infrastructure, Comme ça, ça a des coûts. Vous allez multiplier les coûts fatalement si vous allez multiplier l'infrastructure. Et malheureusement, si vous avez été capable d'automatiser la balance d'un côté à l'autre, les hackers, les pirates, peu importe leur nom, sont aussi capables d'automatiser leurs attaques. Et s'ils ont attaqué votre data center qui était à, peu importe l'emplacement, ils seront tout autant capables d'attaquer le même data center, répliquer, enfin, un autre data center avec les mêmes services, la même chose ailleurs. Et donc, s'ils ont été capables de faire une des doses, le Distributed Denial of Service, la perte de service sur un de vos data centers, ils vont être capables de le faire sur le suivant dès que vous allez le remonter.

15:39 Donc, tous vos efforts et votre multiplication des coûts va s'en retrouver finalement une perte, une perte pure, parce que vous n'êtes pas prêt à résister à une attaque. Vous n'avez pas été prêt la première fois, vous n'êtes pas prêt non plus la deuxième fois. Et donc, je vais me permettre de vous poser une première question avant qu'on avance. Aujourd'hui, parmi vous, on a déjà une première question qui est arrivée. Merci pour la question qui est dans la partie interactivité. Et je vais vous en poser une deuxième. Parmi vous, qui est aujourd'hui dans un mode plutôt réactif et qui est aujourd'hui dans un mode plutôt proactif? Alors, je reformule un petit peu pour clarifier la question, mais qui aujourd'hui, quand vous subissez une attaque, finalement, c'est dans le mode panique, et se dit, bon, je suis attaqué, comment je fais? pour me protéger. J'ouvre mon page de RUT, je joue machin, etc., mes différents moyens d'alerting. Et j'espère que mes équipes vont trouver rapidement une solution pour parer le problème ou qui s'est mis dans une méthode et dans un modèle prêt à...

16:44 Prendre les attaques parce que vous avez mis en place l'organisation qui vous permet d'anticiper ces attaques et d'être finalement résilient justement d'un point de vue sécurité. Alors on verra cette question, on va laisser tourner un petit peu le DRP en attendant et on reviendra sur cette question tout à l'heure. Dans ce cas-là, j'enchaîne sur cette question qui fait suite un petit peu à la question que je viens de vous poser. Vous avez subi une attaque, vous avez subi, peu importe, une injection d'SQL, une falsification, une usurpation d'identité, il y en a des milliers d'attaques différentes, ou si on se focalise rien que sur le top 10 listé par le WASP, on a déjà de quoi faire tomber des systèmes. Si vous le redéployez, vous aurez les mêmes effets si vous subissez les mêmes causes. D'accord? Donc, on peut rentrer dans une boucle infinie et se dire, je suis capable de redéployer mon service à tout va, mais je subirai toujours les mêmes pertes de service tant que mes

17:54 attaquants seront capables de m'attaquer de la même manière si je ne suis pas capable, moi, de m'adapter. Donc, qu'est-ce qu'on fait quand on est face à ce constat-là? La première, ça va être se mettre en capacité de déployer continuellement une solution. Parce que l'idée, c'est de ne pas redéployer la même chose, mais de trouver une solution, de la développer très rapidement sans impacter et sans être impacté non plus par ce qu'on est en train de faire. Vous avez forcément en cours des développements, de nouvelles features, etc. L'idée, ce n'est pas de déployer des choses qui sont... En cours de développement, etc. Il faut être capable de déployer rapidement, de livrer un fixe, un autre fixe de production, mais en le testant et en le testant de manière, sur tous les aspects, surtout en étant capable de valider que les attaques qu'on vient de subir vont être couvertes, vont être protégées. D'accord? Donc, on se donne la capacité de redévelopper en retestant et donc redéployer rapidement en production.

18:56 Ça, ça va être l'enjeu pour ne pas redéployer la même chose et donc ne pas recevoir les mêmes attaques. Et je le dis, il faut pour ça opérer un cycle de sécurité, c'est-à-dire ramener la sécurité au plus proche du développeur, parce que mes développeurs et développeurs qui vont devoir créer le fixe de sécurité vont devoir valider ce qu'ils ont fait, vont devoir anticiper également les prochaines attaques, vont donc être sûrs que... Ils ont bien corrigé un problème, mais ils n'ont pas ouvert X brèches supplémentaires. Ils ne viennent pas dégrader le système sur d'autres aspects. Il faut qu'ils soient en capacité d'analyser, d'analyser tout ce qui livre. Alors, il y a un cas très célèbre qui a éclos il y a quoi, deux ans. Log4J qui a fait beaucoup de bruit. Je déploie du Log4J. Si je ne suis pas capable d'analyser aujourd'hui que Log4J est un problème pour mes assets, je vais le déployer et je serai victime d'attaque de la même manière. Donc, je n'aurai finalement toujours pas de résilience. Il faut également que je sois capable de gouverner parce que tous et toutes, je parle aujourd'hui à beaucoup de six levels et de gens qui prennent des décisions.

20:05 Si on n'est pas capable d'appliquer vos décisions à toutes les couches du développement, à toutes les couches du cycle de vie logiciel, comment on peut s'assurer qu'elles sont respectées finalement? Ce n'est pas juste des procès, c'est aussi de la confiance, d'accord, mais ça n'exclut pas le contrôle. Donc mettre en place une gouvernance et s'assurer qu'elle est appliquée de manière systématique dans vos processus, c'est aussi vous assurer que les outils et les choix que vous avez faits pour assurer la résilience et la sécurité de vos systèmes, sont mis en œuvre à tout instant et donc vos assets sont protégés, les assets de vos clients sont protégés. On a ce témoignage d'un de nos clients aujourd'hui, et j'ai écrit volontairement un client qui n'est pas une multinationale au sens 440, qui sont pourtant évidemment nos plus gros clients. Mais là, on est sur une entreprise même à taille réduite.

21:08 C'est une entreprise, une assurance, Zebra, que vous connaissez peut-être. C'est 350 employés aujourd'hui, Zebra, dans le monde. Et ils nous expliquent que depuis qu'ils ont mis en place GitLab, ils ont doublé leur vitesse de déploiement et ils ont divisé par trois leur... Le nombre d'outils qu'ils utilisaient. Donc, on voit bien qu'il y a une échelle d'économie aussi qui va avec. Mais le plus important pour moi, et c'est ce que j'ai souligné dans le texte, dans la citation qu'il nous donne, c'est qu'ils sont devenus confortables avec leur système de test et de vérification. Donc aujourd'hui, ils font des déploiements en ayant vérifié ce qu'ils font, en étant confortables et en sachant que ce qu'ils vont déployer n'est pas un risque pour leurs clients, pour leurs utilisateurs. Et vous vous doutez bien, quand on parle d'assurance, on parle de versement, d'argent, etc. Donc, il y a derrière des IBAN, il y a tout un tas de choses et des montants qui sont liés au domaine de l'assurance, des transactions financières. On ne peut pas trop se permettre de prendre des risques non plus d'un point de vue sécurité.

22:10 Et de la même manière, nos clients ont besoin de pouvoir faire des déclarations rapidement, ont besoin de voir. souscrire à nos offres. Donc, être confortable avec notre offre et savoir qu'elle va tenir, qu'elle va être résistante, résiliente dans le temps et qu'elle va pouvoir livrer le service, finalement, c'est quand même un maître mot pour cette entreprise comme pour beaucoup d'autres. Et je suis sûr que vous vous reconnaissez dans cet exemple-là. Alors, l'IA dans tout ça. On vient de parler résilience, on a parlé sécurité, et l'important c'est d'avoir ramené la sécurité pour s'assurer qu'on n'allait pas pousser des solutions qui vont tomber aussi sec juste après avoir été déployées. Et l'IA dans tout ça. L'IA nous permet d'aller plus vite. Mais aller plus vite où? Aller plus vite dans le mur? Aller plus vite vers l'échec? Ce n'est pas forcément l'objectif. Elle nous permet de délivrer plus, mais délivrer plus quoi? Délivrer plus de bugs, plus de failles? Là aussi, est-ce que c'est vraiment l'objectif qu'on cherche à atteindre? Est-ce qu'on veut à tout prix intégrer l'IA, quitte à échouer plus vite?

23:10 Ou est-ce qu'on veut au contraire utiliser l'IA? Dans le côté le plus vertueux, j'ai envie de dire, pour trouver plus rapidement des fixes de sécurité, pour automatiser nos fixes de sécurité. On l'a dit tout à l'heure, être capable de livrer en continu, mais est-ce que si finalement on a pu créer directement nos tests, nos correctifs de sécurité et les valider plus rapidement, on n'aurait pas là aussi gagné en résilience? Est-ce qu'utiliser l'IA pour comprendre les failles de sécurité et donc anticiper leur exploitation par d'éventuels pirates, ce ne serait pas aussi une façon vertueuse d'utiliser l'IA? De la même manière, les bugs, alors que j'ai un de mes clients qui parle rapidement, je dis au DevSecOps World Tour de GitLab, qui parle de bugs de sécurité. Donc, il prend l'image dans sa largeur la plus grande. On attend d'un développeur qui réalise quelque chose, qui réalise une user story, qui respecte des spécifications et ne pas mettre en danger notre récit, ne pas mettre en danger les assets de nos clients, ça fait partie de ce qu'on attend d'un développeur.

24:15 Et donc, être capable d'identifier ça au plus vite, c'est aussi un des enjeux qu'on peut acheter grâce à l'IA. Et de la même manière, je vous dis, on va être amené à redéployer, à déployer, à redéployer. Si on déploie un système qui échoue, finalement, on n'est pas tellement résilient. L'IA peut aussi nous aider ici dans l'explication des échecs et trouver des solutions. Et c'est justement ce que fait GitLab et on va le voir à travers un exemple que je vais vous montrer maintenant. Donc ça c'est notre workflow habituel, tout ce que vous voyez en vert c'est ce qu'on a amené avec l'IA. Et donc aujourd'hui je vais faire un focus plus particulier sur la partie sécurité puisque c'est le thème du jour. Mais donc on voit qu'on a amené de l'IA sur la partie sécurité, au même titre on en a amené sur la partie sécurité. la partie génération de code, résolution de problèmes qui se trouve ici, etc. Assistance au développement pour être sûr qu'on livre quelque chose de valide et qui n'est pas en jeu mon SI. Alors, normalement, vous êtes censé continuer à voir mon écran si je passe ici.

25:21 Je vois qu'il finit à jour. Ok, donc là, on va quand même vous présenter mon use case. Pardon. Ici, mon use case, juste pour vous présenter le rôle que je vais prendre là. Je vais prendre le rôle d'Anna, qui est project manager et dont son métier, enfin, pas seulement, mais un des enjeux de son métier, c'est justement de s'assurer que dans le développement, dans le cycle de vie du logiciel, on respecte la compliance, celle qui a été définie par les différents six levels, et qu'on assure la résilience de notre système. Et c'est ça que je vais vous montrer, que je vais mettre en œuvre. Et ensuite, on verra comment le développeur fait face à cette compliance qu'on lui a imposée sur son projet. Donc en tant qu'ANA, ici, j'ai devant moi un centre de compliance. Donc là, je suis dans GitLab. Et je vois que j'ai un ensemble de projets. Ici, j'ai pré-filtré les projets sur lesquels je voulais travailler. Et j'ai appliqué différents frameworks. Donc, j'ai des frameworks qui sont définis. On va voir comment ils sont définis.

26:22 On va voir quels enjeux ils ont. Mais mes frameworks ici, j'ai un framework de démo et un framework de test. J'ai décidé d'appliquer les deux sur mon projet. projet Node.js, on va juste se focaliser sur celui-ci aujourd'hui. Donc, en tant que responsable de projet, je peux simplement venir voir ici mon projet et choisir les différents frameworks qui ont du sens dans mon cas et les appliquer ici. Donc, on voit qu'en deux clics, j'ai appliqué mes règles. Que je veux de manière très spécifique pour assurer la résilience de mon système. Alors ces règles, quelles sont-elles? On va aller les voir ici. On va les voir ici, pardon. Ici, j'ai défini un ensemble de polices, qui est donc ma gouvernance, que je veux appliquer à mes projets pour m'assurer de leur sécurité et donc de leur résilience. Et j'en ai quatre que j'ai appliquées à mon framework de démo, on le voit ici. D'accord? Donc, le premier, c'est que je vais... Imposer des scans de sécurité statique, ce qu'on appelle les SAST.

27:26 Donc là, je reçois mes scans de sécurité statique sur mon code et sur mon infrastructure as code, donc mon code Terraform, Antible. Je vais scanner tous ces codes-là de manière systématique. Je vais également venir faire des scans de sécurité sur le... Mes secrets, mes dépendances, mes containers. Les containers, vous faites le lien avec Docker, Kubernetes, évidemment. Les dépendances, c'est le log4j dont je parlais tout à l'heure. Et les secrets, typiquement, votre clé d'accès à votre cloud, que ce soit GCP ou AWS, par exemple, vous avez une clé d'accès. Un développeur, une développeuse peut faire une erreur, c'est humain, et livrer cette clé-là avec son code source dans GitLab. On est capable de venir le détecter, de venir même l'empêcher de pousser cette clé-là et donc s'assurer que cette clé ne va pas fuiter quelque part, ne va pas être accessible à des tiers et donc ils ne vont pas pouvoir venir. Tout simplement détruire votre système de l'intérieur en ayant toutes les clés d'accès. C'est un cas d'usage très fréquent justement dans les dénis de service et venir faire de l'usurpation d'identité en prenant la clé de quelqu'un pour aller détruire son système de l'intérieur en utilisant ses droits, en son nom donc.

28:37 C'est un cas excessivement classique. Et nous avons la capacité de venir identifier ça, ou plutôt d'empêcher que ça arrive en amont, finalement. La clé ne fuira jamais. Un autre, donc maintenant que j'ai enforcé, que j'ai imposé ces deux types de scanners, enfin quatre types de scanners finalement, à travers deux polices, il y a deux autres choses que je vais vouloir faire dans ma police. Je vais vouloir m'assurer que je ne fais pas fuiter de failles de sécurité de niveau haute ou supérieur, donc haute ou critique. Et donc, c'est ce que je fais à travers cette police-là, en m'assurant que si jamais il y a une faille de sécurité majeure ou autre, je vais demander l'approbation de quelqu'un. Je vous l'ai dit tout à l'heure, il faut se mettre en capacité de livrer vite. Si j'ai ma prod qui tombe, j'ai... besoin de la remonter, j'ai besoin de la redéployer. Et j'ai besoin de la redéployer, pas forcément à l'identique, j'ai besoin de la redéployer dans une version qui sera plus sujette aux attaques.

29:40 Sauf que, pendant que j'ai développé mon fix, je peux me rendre compte qu'il y a une autre faille de sécurité, mais pour laquelle il n'y a pas de solution. D'accord? Et dans ce cas-là, je vais demander de l'approbation ou alors pour laquelle une faille de sécurité qui ne peut pas être exploitée dans mon cas parce que j'ai d'autres éléments de sécurité périmétriques qui me protègent de cette faille de sécurité-là. Dans ce cas-là, Je lui ai demandé l'approbation. Et là, en l'occurrence, j'ai demandé l'approbation de mon équipe sécurité, du honneur du projet, de moi-même et d'une autre personne. En l'occurrence, ça n'ira pas. Donc, j'ai demandé si ces personnes-là approuvent que ma faille de sécurité connue et donc mitigée puisse partir en prod. Ils me donnent leur approbation et je serai en capacité de déployer. Donc là, j'ai ensuite une autre police qui concerne les licences. Je ne vais pas rentrer dans le détail. Ce n'est pas le sujet du jour. Et après, j'ai également un deuxième framework de test. Tout à l'heure, j'en ai parlé. C'était plus pour souligner la capacité d'avoir plusieurs frameworks de test. Et donc, vous pouvez avoir un framework de sécurité qui est propre à votre entreprise, puis un framework qui est spécifique à votre B2B, un autre qui est spécifique à votre B2C, un autre qui est military grade, parce que vous avez des projets qui sont

30:50 d'une importance capitale et que vous voulez protéger plus que d'autres. Et donc, vous allez pouvoir définir vos différents frameworks et les appliquer de manière concurrente ou individualisée sur chacun de vos projets. D'accord? Donc là, j'ai défini l'ensemble de mes policies. Et qu'est-ce que ça donne si justement, maintenant que j'ai défini, j'étais le chef de projet, j'ai défini toutes ces policies. D'accord? Qu'est-ce que ça donne si je change de casquette et que je passe développeur? Eh bien, moi, en tant que développeur, qu'est-ce que je vais voir dans mon code et dans le code que je pousse? Donc ça, c'est du code que j'ai poussé, que j'ai manipulé, et donc je viens de faire un commit, d'accord? Je voudrais faire une livraison. Sauf qu'ici, j'ai un pipeline qui correspond donc au police qu'on vient de... qu'on vient de définir. Je vais regarder dans le détail ici. On ne va pas rentrer dans le détail de chaque élément. Mais je vois que ici, j'ai mon build qui est à la construction de mon projet. OK, pas de problème. J'ai une test militaire, pas de problème. Et tout le reste a été défini automatiquement, justement par mes policies. Donc, mes policies sont bienvenues faire une détection de secret, sont bienvenues analyser mon code IAC, m'ont fait le Hello World dont on parlait tout à l'heure.

31:56 Alors là, j'en ai un qui est défini en local et celui qui est enforcé par ma policy. Et j'ai bien des analyses SAFT, de containers, de dépendance. Donc tout ça, sans que moi en tant que développeur, j'ai eu le moindre besoin de le déclarer, ça m'est imposé automatiquement sur mes projets. Et il en résulte, si je reviens sur ma merge request, revenir une case avant. Ici, je vais avoir en effet des résultats qui sont affichés. Bon, mes licences, on a dit, elles sont comparatives. Je vois les résultats de mes tests. OK, pas de problème. J'aurais pu avoir des tests de performance et des choses comme ça qui peuvent me servir. Mais surtout, ici, ce qu'on a dit, c'est que j'ai vu qu'il y avait une faille de sécurité. On ne rentrera pas dans le détail de la faille de sécurité, ce n'est pas l'objectif aujourd'hui. Mais j'ai une nouvelle faille de sécurité critique ici qui est arrivée. Et ce qu'on s'était dit tout à l'heure au niveau des policies, c'est que j'ai voulu m'assurer qu'il n'y avait pas de faille de sécurité haute ou critique qui partait en production. Ici, j'ai eu huit failles de sécurité haute et une faille de sécurité critique.

32:57 J'ai donc besoin d'une approbation. Je suis donc dans l'un. capacité ici d'émerger. Je suis ici dans la capacité d'émerger. Je vois bien que j'ai tous les approbations qui ne m'ont pas été données. Donc, mon merge est bloqué. Je peux lui dire, dès que tu auras toutes les approbations, tu émergeras automatiquement. Ou j'attends d'avoir les approbations. Et les approbations, ici, je vais avoir un moyen d'alerter les personnes qui sont concernées pour venir leur dire attention. Ici, il y a besoin d'une approbation sur cette règle-là. Donc, j'ai bien mis en place une gouvernance qui me permet de garantir que je ne vais pas mettre à risque mes aspects, je ne vais pas mettre à risque ma production en déployant quelque chose qui n'est pas sécurisé. Donc ici, j'ai ramené au plus proche de mon développeur tout ce dont il a besoin. Maintenant, soit il analyse chaque faille de sécurité, il va les résoudre, soit il y en a certaines qu'il n'est pas en capacité de résoudre, et dans ce cas-là, il viendra demander l'approbation. Je suis approbateur ici. Si j'ai mis mon approbation, je serai dans ce cas-là en capacité de merger. Dès qu'il va se rafraîchir, j'aurai la capacité de venir merger.

34:00 Normalement, un peu. Après, justement, voilà. Je suis en capacité d'aller vers la prod et d'avoir tout mon système qui pousse sur les différents environnements aval. Je vais m'arrêter là sur cette démo. L'idée, ce n'est pas non plus de rentrer dans un détail profond sur du GitLab. Je me tiens évidemment à votre disposition pour le faire. Si vous avez besoin d'aller plus loin, j'aurai aussi mes collègues qui seront disponibles le 2 et 3 décembre à Paris. Mais je voulais plutôt ouvrir un petit peu le sujet maintenant sur vos questions. L'idée, c'était aussi de vous laisser la main, de venir. Je crois qu'Alexandre, vous avez partagé une demande de venir avec vos questions, justement pour qu'on puisse en parler. Donc, on va se donner un petit peu de temps maintenant pour rentrer dans cette partie-là et ce qui vous concerne finalement. Merci Olivier, c'était vraiment super intéressant. Je ne sais pas si tu as vu dans l'interactivité, il y a des gens qui ont répondu à ta question. Alexandre a mis le modèle proactif versus réactif.

35:07 Donc, en gros, il y a un tiers de réactifs pour deux tiers de proactifs. Et sur les discovery plans, c'est à peu près pareil, d'ailleurs. Pour l'instant, il y a... Je ne crois qu'il n'y a pas encore de questions. Du coup, je vais moi poser mes questions. Super, vas-y. Est-ce que tu dirais, parce que c'est super intéressant de voir effectivement qu'il ne s'agit pas juste de remonter une... Son système s'il s'est écroulé pour une raison X ou Y, que ce soit suite à une attaque des DOS ou suite à... Si c'est lié à une intempérie, évidemment, ce n'est pas exactement le même problème. On peut supposer que le système est peut-être bien sécurisé pour le remonter tel quel. Mais c'est important de comprendre d'où vient la panne avant de... Avant de remonter le système. Et du coup, est-ce que... J'imagine qu'en amont, finalement, de... En amont de la définition de quelles solutions techniques on utilise pour bien sécuriser son système, que ce soit GitLab ou autre, il y a toute une réflexion à avoir sur quels sont finalement les risques.

36:18 Qui peuvent attaquer notre système, qui peuvent détruire notre système. des différentes pannes. Et cette analyse-là, comment tu conseilles de la faire? Parce que c'est plus une analyse de risque, etc. Est-ce que vous, GitLab, vous accompagnez les clients là-dessus ou pas trop? Alors, ça fait partie des sujets, en effet, que nous, en tant que solution architecte, on peut adresser avec nos clients. Pour leur aider à vous aider à déterminer qu'est-ce qui peut impacter votre value stream, finalement. Votre value stream, c'est comment je délivre de la valeur à mes clients, et dans ce cas, déterminer tout, mes clients, mes usagers, mes utilisateurs, selon vous êtes en secteur public ou pas, quels sont tous les éléments qui peuvent venir m'impacter et comment je peux, quelles sont les solutions que je peux apporter et comment je peux m'en protéger. Donc oui, en effet, ça fait partie des sujets qu'on peut adresser ensemble.

37:22 On peut conduire ce qu'on appelle des Value Stream Workshop. Et je suis d'ailleurs certifié là-dessus, on a tout un modèle de certification sur les Value Stream Workshop. Dont l'objectif est justement de travailler avec nos clients sur la manière dont ils délivrent de la valeur à leurs clients, et où c'est qu'il y a des problèmes, où c'est qu'il y a des bottlenecks, où c'est qu'il y a des failles de sécurité, etc. Et donc, quels sont les différents leviers dont on dispose pour venir améliorer la situation? Ok, très bien. Oui, complètement. Merci. Donc là, il y a une première... Question, est-ce que les policiers doivent utiliser des outils GitLab ou peut-on y intégrer nos propres outils ? Bonjour Eric, on partage le même nom, ravi. Du coup, oui, c'est une des forces de GitLab, vous le savez très certainement, on est un outil open core, c'est-à-dire qu'on a une immense majorité de notre source qui est open source, et une petite sous-partie qui est privée.

38:33 Mais donc, on a un modèle open core et une de nos forces, c'est justement d'être capable de s'intégrer, j'ai envie de dire virtuellement, avec tout et n'importe quoi. Il y a évidemment quelques limites, mais du moment qu'un système peut être appelé via une API, via un appel shell ou des choses comme ça, on est capable de s'intégrer avec eux. Et si le système en question sort des résultats au format texte et qu'on peut transformer dans un JSON, qui est notre format pivot, alors on est en plus capable de les intégrer dans l'interface que je vous ai montré tout à l'heure quand je vous ai montré là il y avait une faille de sécurité critique puis faille de sécurité majeure si votre outil l'outil que vous avez développé vous en interne pour une raison x ou y est capable de sortir un résultat texte et qu'on peut le transformer dans un JSON on sera capable d'afficher et donc il nous a défecté 8 fois des sécurités critiques supplémentaires elles seront affichées là elles seront directement disponibles pour vos équipes de dev donc on est capable de s'intégrer en effet et c'est Une de nos forces, j'ai envie de dire par rapport à d'autres, c'est vraiment notre interopérabilité.

39:37 Je peux citer deux clients actuellement qui sont précisément dans ce cas-là. Il y a une petite PME toulousaine et un grand acteur 440, une grande société de service 440, qui sont dans le même... Dans ce cas-là, ils ont leurs propres outillages, leurs propres outils de dev et leurs propres outils de... test, pardon, donc là on n'est plus tout à fait sur la sécurité, mais ils ont leur propre outil de test et on est capable de s'intégrer avec eux parce qu'on est capable de les déclencher, on est capable, c'est nos runners dans nos pipelines qui font ce travail-là, mais on s'intègre sans problème. Ok, merci. Je ne sais pas si tu veux réagir justement aux réponses qu'il y a eu sur le modèle proactif versus modèle réactif. C'est-à-dire qu'en gros, on voit quand même qu'un tiers encore des tech leaders, enfin un tiers, c'est une stat sur six réponses, on ne peut pas vraiment faire de stat, mais en tout cas, que finalement, il y a encore des...

40:37 Personnes qui sont plutôt sur le mode réactif, c'est-à-dire que quand il y a un bug ou quand il y a le système qui plante, vont chercher d'où vient la panne, etc. Est-ce que tu as un peu de réaction, enfin, tu as envie de réagir là-dessus? Alors, c'est... Pas de panique déjà, j'ai envie de dire. C'est très courant, même quelle que soit la taille de votre entreprise. Même des très gros acteurs CAC 40 ou Fortune 500, se trouvent dans ces cas-là. Donc, il n'y a aucune honte, j'ai envie de dire, à avoir. Et il n'y a rien d'anormal. Mais justement, on est capable avec GitLab d'amener d'accompagner au changement, d'amener progressivement une évolution dans ce domaine-là et de se placer sans faire une perturbation. majeur, sans venir casser tous les systèmes existants, etc. On n'est pas, et ça rejoint aussi la réponse que je viens de donner juste avant, on n'est pas un outil et une plateforme, en fait, qui vient en remplacement de tout l'existant et donc qui vient en mode

41:44 Big Bang, j'écrase tout et vous m'utilisez exclusivement moi et donc c'est obligé de reformer tous vos utilisateurs instantanément, etc. Et donc d'avoir des gros investissements. On est capable d'y aller de manière progressive et donc intégrer un modèle réactif. Vous l'avez vu tout à l'heure, je vous ai montré les policies. Alors, si je rentre dans le détail, ça se définit en quelques clics. Alors, on peut le faire en mode code, puisqu'on fait du everything as code chez GitLab. Mais vous avez des interfaces graphiques qui vous permettent en quelques clics d'appliquer un framework, mais également de définir vos policies. Ça se fait très, très rapidement, très simplement. Et donc, on peut justement amener progressivement du changement, amener progressivement de la sécurité auprès de vos développeurs et passer dans un modèle réactif qui sera plus pérenne pour votre avenir, sans pour autant demander des investissements massifs, sans pour autant demander de tout remplacer, tout changer. Alors, on y va aussi step by step. Donc, il n'y a rien d'alarmant. C'est un sujet qu'il y a à connaître.

42:46 On sait qu'il y a un problème. On sait qu'on a une capacité d'amélioration sur ce sujet-là. Très bien, on y va et on y va ensemble. Pas de souci. D'ailleurs, est-ce que... Parce que quand même, les gens qui s'adressent à toi, Ça veut dire qu'ils ont déjà fait une démarche quelque part de se poser la question. Comment vous allez chercher ceux qui ne se sont pas encore bien posés l'action? Parce qu'ils pensent que finalement, il n'y a pas de problème, parce qu'ils sont trop petits, ils ne risquent pas d'être attaqués par des DOS ou je ne sais quoi. Alors qu'en fait, on voit par exemple l'opforgie, ça me rappelle des souvenirs, malheureusement. On n'a pas eu de problème, mais en tout cas, on a utilisé. Enfin bref, on était impacté sans être impacté, mais en tout cas, on a dû se poser la question de comment corriger ce truc-là. Mais donc, les gens, parfois, ils ne sont pas encore au courant qu'ils peuvent être impactés finalement, mais comment vous allez les chercher pour finalement les sensibiliser alors qu'ils y sont peut-être pas sensibles, justement?

43:49 Alors, grâce à des événements comme Tech.Rocks, on a besoin de faire un peu de marketing aussi et de se faire connaître. Donc évidemment, on rentre chez beaucoup de clients, on est très connu pour ça, on est un gestionnaire de code source. C'était notre métier premier, j'ai envie de dire, il y a 10 ans quand on a commencé. Puis on est rapidement arrivé sur le domaine du CI, essentiellement du CI, puis après du CI fini. Mais donc, être en capacité d'automatiser les choses, ça a été affecté parmi nos premiers métiers. Et donc, venir expliquer à nos clients, venir leur montrer avec quelle facilité on est capable de... d'intégrer de la sécurité, avec laquelle on est capable d'automatiser leur processus et donc de venir améliorer leur résilience. C'est du démarchage, une partie de démarchage commercial aussi, de marketing, comme je viens de le dire. On est présent sur beaucoup de salons, les événements qu'on fait ce jeudi à Paris, etc.

44:49 Donc, c'est des événements qui nous permettent de... d'expliquer à nos clients, de leur montrer et donc de se faire connaître aussi sur ce domaine-là. On n'est pas juste du CICI. On n'est pas juste gestionnaire de code source, on est capable d'être une plateforme et on est d'ailleurs reconnu. Pour ça, on a la chance d'avoir Gartner qui a créé il y a deux ans un Magic Quadrant pour les plateformes d'FC Ops et une place leader depuis deux ans dans ce domaine-là, loin devant tous nos concurrents. Parce que oui, notre vision, elle est aujourd'hui reconnue par un acteur comme Gartner, qui n'est pas n'importe qui, sur ce platforming. Et on fait également des surveys en interne, auprès de nos clients, de manière très, très large, sur la volonté de nos clients. Et on drive notre produit aussi en fonction de la volonté de nos clients. Et aujourd'hui, la volonté de nos clients, elle est claire, elle est réduire le nombre d'outils qu'ils ont. On a 94% de nos clients qui demandent à réduire leur nombre d'outils, qu'ils en ont trop d'outils, très souvent plus de 10 outils dans leur écosystème.

45:55 C'est trop, ça coûte une fortune de maintenir tout ça, de les intégrer, etc. Éventuellement, une fortune en licence aussi, si c'est des outils payants. Et rationaliser, avoir une seule plateforme qui nous permet justement de piloter et de faire communiquer tout le monde, de faire travailler tout le monde ensemble. C'est un défaut qu'on voit très souvent quand on a une démarche DevOps. On ne fait pas travailler des gens ensemble, on ne les fait pas travailler sur les mêmes outils, donc ils ne se parlent pas vraiment. Là, avoir réuni le dev, le set, les ops sur le même outil, la même plateforme, donc tout le monde est capable de se parler, de collaborer efficacement. C'est un gain de coût, quel que soit votre... La taille de votre société. Oui, je pense que simplifier les outils, c'est quand même un vrai sujet. Et je pense... Après, les gens ne sont pas forcément conscients. Ce qu'ils regardent parfois, c'est le tarif, la page tarif, sans se rendre compte du gain. Comme tu disais au début de la présentation, c'est-à-dire qu'avoir une faille, une faille exploitée, évidemment, si la faille n'est pas exploitée, le coût ne se voit pas directement.

46:56 Mais il y a une faille, il y a un... Un coût potentiel des failles exploitées qui est énorme. Et donc, avoir des outils qui empêchent... Évidemment, le coût n'est pas encore réel tant qu'on n'a pas eu une faille exploitée, mais il vaut mieux éviter de tomber là-dedans. C'est tout le problème de la gestion du risque, tu as raison. Alors, c'est une question que j'aurais voulu poser également. Combien d'entre vous ont fait ce lien, alors que ce soit un lien formel ou pas, entre la résilience et la sécurité, entre vos budgets, votre gestion du risque, votre budget de gestion du risque, et votre budget, les budgets liés à cette gestion du risque, donc à la gestion de la sécurité? Puisqu'on le sait, une faillite de sécurité, ça peut coûter 4 millions. Alors, ça ne coûte pas 4 millions à toutes les entreprises. Il y a des entreprises qui sont plus petites, heureusement. Et c'est vrai que le lien, le coût de la faille n'est pas toujours si évident, puisque c'est difficile d'évaluer, par exemple,

48:01 le coût en perte de clients, enfin en clients qui ne viendront jamais chez nous parce qu'il y a eu cette faille, ou des gens qui quittent, tu citais l'exemple de Free, mais de vraiment mesurer quel est l'impact de perte de clients ou de personnes qui ne viendront jamais, ce n'est pas toujours évident. Mais nous, on a eu le cas, par exemple, chez Netatmo, de notre logisticien, la plateforme qui envoie les colis aux clients qui a eu une faille de sécurité exploitée, donc une attaque cyber. Et ça, on a su mesurer justement le perte en nombre de commandes qu'on n'a pas pu livrer parce que du coup, ils ont dû arrêter leur système d'information le temps de comprendre ce qui s'était passé, etc. Donc, ils ont du coup arrêté aussi d'envoyer les colis, tout simplement. Et donc, on a arrêté de prendre des commandes parce qu'on ne pouvait plus livrer. Et donc, ça, par exemple, c'est une faille.

49:02 Alors, la faille, elle n'était pas chez nous. Mais n'empêche que c'est assez facile de chiffrer la perte en chiffre d'affaires. Dans ces cas-là. Et tu dis, donc, l'Ocforgy, nous, on n'a pas, la faille n'a pas été exploitée chez nous parce qu'on a pu vérifier qu'elle n'avait pas été exploitée, donc on n'a pas eu de perte directement. Mais par contre, du coup, nous, on avait, enfin, il se trouve que chez Netatmo, on avait une équipe qui s'occupait de la cybersécurité et on est utilisateur. Donc, Mais du coup, c'est... Le temps qu'on passe à analyser ces failles, quand on a des outils pour nous aider, on a passé beaucoup de temps à essayer de comprendre si la faille avait été exploitée ou pas. Évidemment, tout un plan pour mettre à jour tout ça, c'est normal, mais comme toutes les personnes qui utilisaient ça. Mais tout ça, quand on a des outils pour nous aider à le faire plus rapidement, c'est un gain de temps et donc d'argent aussi à ce niveau-là. Donc, quand tu parles de simplification des outils, moi, ça me parle carrément.

50:03 Donc là, il y a des gens, attends, il y a quelqu'un chez Manomano. La sécurité était dans le budget Platform et Security. Ok. Voilà, donc il n'y a pas eu d'autres réactions sur ce sujet-là, je crois. Par contre, on a une autre question qui est arrivée depuis toujours de Eric. Est-ce qu'on peut voir la partie Vulnerability Explanation? J'ai l'impression que le plus compliqué est de faire comprendre les problèmes de sécurité aux non-experts de la sécurité. Alors, c'est une très bonne question, très bon sujet. Allez, je repartage mon écran. Il est plus partagé. Partager mon écran puisqu'on a un peu de temps je me permets de le faire en effet live démo donc là ici je suis toujours sur mon projet vous voyez l'écran peut-être il faut que je change la mise en page parce que sinon merci

51:06 Alors, ici, je suis sur le Vulnerability Report. Alors, je vais le faire à l'échelle de mon projet. On peut remonter à n'importe quel niveau et donc avoir une vision beaucoup plus large. Si le chef de projet a envie de le voir au niveau du projet, le directeur d'équipe aura peut-être envie de le voir sur l'ensemble de tous les projets de son équipe, etc. Et les six levels que vous êtes auront probablement envie de le voir de manière très transverse sur l'ensemble de votre parc. Donc, à tout niveau, moi, je peux remonter là et voir ce même rapport. Et donc, dans ce rapport-là, alors, on va essayer d'aller voir. On va faire un peu de ménage. Je vais aller cibler directement mes outils SAST. Qui vont permettre de faire de l'explication de vulnérabilité. Typiquement ici, si je prends cette faille-là, Express Open Redirect, Donc ça, c'est une faille qui a été identifiée. Là, en l'occurrence, mon dernier report qui concerne ma prod. Donc je sais que j'ai cette faille-là en prod. Et si je viens regarder la définition, alors ça, c'est une définition officielle, elles ne viennent pas forcément toutes de nous.

52:11 On a une base de vulnérabilité qu'on alimente avec différentes sources, dont le NVD, pour ceux qui connaissent, c'est le National Vulnerability Database qui est établi par les États-Unis. Ils ont un organisme exprès qui s'appelle le NIST qui s'occupe de ça. Et on est nous-mêmes aussi... Identifieur de sources de CDE. Donc, on est capable d'identifier des failles et de les remonter, de les flaguer. Mais celle-là, elle vient d'une liste. Donc, elle a un identifiant, tout ça. Une description qui est... limite, tout le monde ne la comprend pas forcément. Et ici, ce qu'on a amené avec l'IA, justement, c'est l'explication de vulnérabilité. On est capable de venir demander automatiquement à notre IA de venir qualifier cette vulnérabilité, de l'expliquer. Et alors, il y a trois éléments, il y a trois sections, pardon. Une première qui est l'explication pure et dure. Donc voilà ce qu'on fait, etc. On peut renvoyer un utilisateur vers une autre URL sans validation propre, machin, et c'est lié à ce bout de code-là, etc.

53:12 OK. On voit le code là ici, c'est-à-dire un extrait de mon code précis. Je sais précisément dans quel fichier est impacté par la généralité. Je vais plus loin. Ici, je vois comment je pourrais former l'attaque. Alors ça, quand j'étais formateur sécurité, c'est quelque chose qui marchait très bien avec mes élèves, mes étudiants. Je ne sais pas quel est le terme le plus approprié. Mais donc, mes élèves, quand je leur expliquais à quel point c'est facile d'exploiter une faille de sécurité, à quel point finalement le code qu'ils ont livré, il met réellement en danger l'entreprise. C'est particulièrement visible sur les files sécurité SQL aussi. On voit que c'est très, très simple à mettre en œuvre. Finalement, c'est percutant pour un développeur ou une développeuse. Il faut peut-être que j'y fasse attention à celle-là parce que je peux en effet faire tomber la boîte. De manière assez simple. Et derrière, avec l'IA, on vient fournir une solution sur comment on peut résoudre le problème. Donc là, voilà les domaines qu'on veut autoriser. Et donc, je fais un filtre là-dessus.

54:14 Je m'assure que je fais forcément toutes les réactions se font vers des domaines que j'ai autorisés. Donc, ici, le développeur, il copie le code, il vient le coller dans son IDE, fin d'histoire, il a réglé le problème. Il pousse, on fait repasser les scanners de vulnérabilité. Ça serait qu'il n'y ait pas une nouvelle faille de sécurité sur ça, typiquement. Normalement, non, mais on n'est pas à l'abri. Donc, on va toujours refaire passer tous nos scanners de sécurité. Mais ici, on a une explication complète. Et donc, en tant qu'utilisateur de la plateforme, j'ai compris, je suis sensibilisé à la simplicité d'exploitation. Donc, je ne vais pas la reproduire. Il y a aussi ça. Et j'apprends au fil de l'eau. C'est aussi quelque chose qu'on notait quand j'étais formateur. Si vous prenez une équipe de dev, vous les envoyez trois jours en formation. Vous allez leur bourrer le crâne avec plein de choses sur la sécurité, c'est génial, mais c'est connu, les stats sont formelles là-dessus, ils auront oublié entre 60 et 80% de ce qu'ils auront appris en une semaine. Donc, si vous envoyez trois jours, vous en avez perdu deux sur les trois, au bout d'une semaine déjà.

55:18 Apprendre au fil de l'eau, déjà, vous n'avez pas à mobiliser des équipes pendant trois jours ou plus, à aller apprendre de la sécurité. Et ils vont retenir parce qu'ils le voient ici, dans un contexte où ça a du sens pour eux. Je ne suis pas en train de leur parler d'une phase de sécurité SQL. Ils ne font pas de SQL sur ce projet. Très bien. Par contre, ils font de l'express avec nos JS. Et là, ils voient très précisément comment on fait et comment on exploite cette phase de sécurité. Donc, on retient mieux quand on est dans le contexte et ça évite de le reproduire. Donc, c'est aussi l'idée. J'espère que ça répond à ta question. Super, merci beaucoup Olivier. En tout cas, ça donne plein de pistes pour s'améliorer dans le futur. On va mettre bientôt fin à la masterclass. Le temps est passé super vite. Et c'était vraiment chouette d'avoir tes conseils pour améliorer la manière dont on gère nos systèmes et nos organisations. Et on voit qu'il y a aussi beaucoup de liens avec la culture de développement et la culture d'entreprise de manière plus générale.

56:21 Parce qu'effectivement, comme disait Eric, il faut sensibiliser l'équipe tech. Moi, je pense qu'il y a aussi l'équipe tech parfois qui n'est pas suffisamment sensible. Et aussi, effectivement, ça peut... peut être plus dur. Une fois que l'équipe tech est sensibilisée et qu'il comprend bien qu'il faut investir dans des outils qui permettent de faire mieux, il faut aussi effectivement réussir à convaincre le financier, celui qui tient le budget, et le patron pour... Qui n'est pas forcément quelqu'un de tech, pour qu'ils comprennent qu'il a tout à y gagner et que ce sont des investissements pour éviter des failles qui coûtent beaucoup plus d'argent. Si vous êtes... Je me permets de revenir là-dessus. Si vous êtes intéressé, justement, enfin, si vous êtes soucieux de votre budget, on est aussi capable de calculer avec vous des ROI et de voir. On a des entreprises, j'ai un très grand acteur, Touzin, qui nous a fait part qu'il avait un cashback en six mois sur la plateforme. Donc, on retrouve ces investissements de manière très concrète.

57:24 On peut vous mettre en relation. Alors, on peut nous calculer les ROI avec vous. On peut vous montrer les témoignages de nos clients et même vous mettre en relation avec des clients qui expliquent, OK, voilà combien j'ai gagné finalement. Oui, c'est un investissement initial, mais je rentre rapidement dans mes coûts. Très bien, merci. Donc, avant de se quitter, j'ai trois choses à vous dire. Premièrement, comme on disait, c'était la première masterclass d'une série de quatre. Et donc, la semaine prochaine, je pense que la prochaine, c'est le 19 novembre. Enfin, vous allez donc sur le lien Camille Alexandre dans la discussion pour vous inscrire. Il y a encore des places. Le 19 novembre, ce sera avec Figma, si je ne me trompe pas. Ensuite, quand vous quitterez cette masterclass, Vous allez avoir un satisfaction survey qui va vous être envoyé. Et donc, merci d'avance de passer quelques minutes à répondre pour nous permettre de nous améliorer. Parce que c'est important pour nous.

58:25 Et enfin, je terminerai en disant que, Il y a le Tech.Rocks Summit le 2 et le 3 décembre, auquel vous n'auriez pas compris. Et donc, on vous attend nombreux parce que ça va être vraiment un moment incroyable. Au Théâtre de Paris, en plus, dans un lieu juste magnifique. Et comme Olivier disait au début, il y aura des collègues d'Olivier, de GitLab, qui seront présents. Au Tech.Rocks Summit les 2 et 3 décembre. Et donc, si vous avez des questions à leur poser sur la solution, vous pouvez aussi le faire là-bas. Voilà, merci beaucoup et très bonne journée. Merci à toi, Nathalie. Merci beaucoup. Merci tout le monde.