Fiabiliser et sécuriser les chaînes d'approvisionnement DevOps

0:03 Premier point, c'est vraiment de venir simplifier la vie de ces personnes qui mettent en place les softwares sous Flexion. c'est de venir rassurer nos directions, donc les DSI, les RSSI, les directions techniques, sur la conformité et le niveau de sécurité de l'ensemble de leur chaîne d'approvisionnement logiciel. Moi, ce que je veux pour ce deuxième objectif, c'est que les directions aient instantanément des réponses sans déployer des efforts énormes pour être rassurés sur est-ce que mon délivrerie est conforme à ce que j'ai envie d'avoir dans mon entreprise. Bonjour à tous, je suis Philippe Ensarguet, VP Software Engineering chez Orange, mais aujourd'hui, c'est en tant que membre de l'équipe contenu de Tech.Rocks que je suis avec vous. Je suis ravi pour ce podcast de recevoir Aurélien Coget. Bonjour Philippe, merci pour l'invitation. Avec la place que joue le software aujourd'hui dans notre économie et ce tout secteur d'activité confondu, sécuriser, pérenniser ou encore répondre à des exigences réglementaires ou légales sur les outils qui permettent de gérer son cycle de vie, de l'idée jusqu'au produit entre les mains d'un utilisateur, revêt un caractère absolument vital.

1:12 On s'intéresse de plus en plus à la sécurité, la performance ou encore la réutilisation du code. Mais qu'en est-il pour le pipeline et les différentes étapes et outils que l'on orchestre pour le produire? C'est ce que nous allons découvrir avec Aurélien dans ce podcast en explorant les défis et les enjeux de la sécurisation d'une supply chain software et comment une démarche d'inner source peut être un catalyseur d'une démarche d'industrialisation. Tout d'abord, je suis persuadé Aurélien que notre public serait ravi de comprendre qui tu es. Je me présente, je suis Aurélien Coget, je suis de formation ingénieur informatique généraliste, mais j'ai un intérêt plus particulier pour les systèmes, le réseau et surtout l'automatisation des tâches. Sorti d'école, j'ai rejoint une super première expérience au ministère de la Défense. J'ai débuté dans un environnement où la sécurité était primordiale. J'ai même démarré mon expérience en devant coder des applis sans avoir Internet sur mon poste. Donc, c'est assez formateur. J'ai ensuite continué dans ce ministère en prenant des notions de pilotage projet.

2:17 Ça m'a beaucoup plu. J'ai poursuivi mon parcours en rejoignant une ESN côté Nantais, qui est Soprasteria, en tant que chef de projet, toujours dans l'IT et toujours dans la défense. Et ensuite, j'ai déménagé plus dans le sud, où là, j'ai rejoint une autre aventure, une aventure startup, startup dans la blockchain. Une startup qui avait levé des fonds en pleine croissance, peut-être même une croissance trop rapide. Et là, j'occupais un rôle de responsable du département informatique. Et dans cette startup, j'ai rencontré mon associé d'aujourd'hui qui s'appelle Thomas Bonny. Et on a super bien matché sur les valeurs qu'on voulait apporter aux entreprises et aux équipes de développement, notamment pour accélérer leur délivré. Du coup, la première question qui me vient après ta présentation, c'est quels ont été les déclencheurs de la création de R2Devops? C'est une suite logique. Avec Thomas, on a monté tout d'abord, avant de parler de R2Devops, une société de service en 2020, où on travaillait pour des clients, où on les aidait à se transformer numériquement. C'était à base d'agilité et de méthodologie DevOps.

3:18 Et on a mis notamment beaucoup en place, beaucoup de chaînes d'approvisionnement logiciels dont on va parler un peu aujourd'hui. Donc c'est du code qui sert à automatiser des tâches de votre delivery. Et on s'est rendu compte qu'en faisant ça, à chaque fois qu'on intervenait dans des équipes, les équipes réinventaient systématiquement. la roue, faisant perdre du temps à tout le monde, rendant compliqué la maintenance des systèmes qui devenaient hétérogènes et amenant aussi une perte de connaissance à chaque fois qu'il y avait un mouvement ou un départ d'un développeur. Nous aussi d'ailleurs, dans nos prestations avec Thomas, on avait ce réflexe malheureux de réinventer la roue. Et un jour, Thomas m'a donné un coup de main et il m'a fait gagner deux heures, peut-être trois, sur un projet. Et c'est à partir de là qu'on a appris que si on travaillait plus ensemble sur une façon commune de faire certaines choses, on pourrait réutiliser les travaux de chacun qu'on applique dans certains projets. Et cette manière collaborative permettrait de tendre vers des systèmes qui seraient plus homogènes, plus facilement maintenables, parce qu'on sait exactement ce qu'on va utiliser pour créer nos prochaines supply chains. Et donc, notre première mission, ça a été de construire un référentiel qui est aujourd'hui open source, référentiel d'outils, de composants, on peut les appeler comme ça, qui permet aux développeurs d'aller construire un pipeline CI-CD sur la plateforme GitLab.

4:31 Donc tout ça, c'est open source, c'est collaboratif. Et c'est de là que tout a commencé en termes d'action, j'ai envie de dire. Et aujourd'hui, R2Devops, c'est une solution, il y a une partie open source qui existe toujours, mais c'est surtout une solution qui aide les entreprises IT à pousser la standardisation comme clé pour la conformité et la sécurisation de leur délivre. Super, toujours très intéressant de comprendre l'inception et la genèse d'une société. Avant de rentrer dans le vif du sujet de la sécurité de la software et de l'inner source, Il y a toujours deux questions que j'aime poser dans les podcasts. La première, c'est finalement, quelles sont tes motivations? Qu'est-ce qui fait que tu te lèves tous les matins? Où sont tes inspirations, en fait? C'est très intéressant comme question. Alors, je me lève tous les matins pour deux choses professionnellement que je vais te partager. La troisième, c'est le petit déjeuner, mais je pense que ça ne vous intéresse pas là. La première, c'est de venir simplifier la vie des développeurs qui créent et qui maintiennent ce code de la supply chain. On est passé par là, on a énormément souffert quand on regarde ce qu'on a fait. On a perdu énormément de temps et également énormément de connaissances.

5:33 Et également, ces personnes-là, qui sont trop peu nombreuses dans les entreprises, elles ont des responsabilités très fortes. Elles peuvent représenter des SPOF à certains moments, donc des points de défaillance uniques. Et moralement, ça peut être compliqué puisqu'elles ont cette responsabilité de tenir la prod à bout de bras. Donc, premier point, c'est vraiment de venir simplifier la vie de ces personnes qui mettent en place les softwares supply chain. Et le deuxième point qui me stimule, auquel j'ai envie d'apporter une réponse, c'est de venir rassurer nos directions, donc les DSI, les RSI, les directions techniques, sur la conformité et le niveau de sécurité de l'ensemble de leur chaîne d'approvisionnement logiciel. Aujourd'hui, c'est assez compliqué de connaître tout le code qui vient automatiser nos tâches, qui vient accélérer notre délivrerie, de savoir ce qu'il y a dedans, est-ce qu'il est conforme, est-ce qu'il est sécurisé. Quand je parle à des boîtes avec peu de projets, c'est assez facile, on peut se permettre de regarder manuellement dedans, mais rapidement, quand on a une cinquantaine, une centaine, des milliers de projets dans notre gestionnaire de code source, peut-être que GitLab ou GitHub, Ça devient un enfer pour tout le monde de venir regarder et s'assurer que le code est conforme.

6:35 C'est chronophage, ça n'a pas de valeur pour le développeur qui doit faire ce travail, ce n'est pas répétable. Moi, ce que je veux pour ce deuxième objectif, c'est que les directions aient instantanément des réponses sans déployer des efforts énormes pour être rassurés sur est-ce que mon délivrerie est conforme à ce que j'ai envie d'avoir dans mon entreprise. La deuxième question, c'est peut-être au travers des différentes expériences que vous avez rencontrées, est-ce qu'il y a une anecdote qui finalement te tient à cœur et qui est représentative du contexte de l'échange que l'on va avoir juste derrière? Oui, alors c'est une anecdote qui est plus axée sur le côté sécurité que sur le côté in-source. Mais j'aime bien en parler parce que malheureusement, ce n'est plus une anecdote, mais ça arrive trop souvent. Aujourd'hui, ce qu'on fait, c'est qu'on propose d'observer ce qu'il y a dans les papilles de CSID, dans le code de la software supply chain. Et généralement, quand on parle à des clients, ils ont beaucoup de projets. Et un de nos clients, il voulait regarder uniquement 500 projets alors qu'il en avait 2000. Moi, je lui ai dit qu'on pouvait regarder l'ensemble parce que je voulais qu'il ait une vision exhaustive de tout son code.

7:38 Et il m'a dit non, non, j'ai que 500 projets qui sont importants dans mon entreprise. Donc, à comprendre, j'ai que 500 repositories actifs importants dans mon GitLab ou mon GitHub, mais en tout, il en avait 2000. Donc, on a fait cette analyse, on lui a donné des réponses. Il n'y avait pas de réponse critique, juste de la dette technique, des ressources obsolètes. Il n'y a pas de carton rouge, en fait, sur ce qu'on a vu. Mais j'ai quand même poussé pour qu'on lui donne cette réponse. Réponse exhaustive. Et quand on a analysé le reste des projets, c'est là où on est tombé sur des pépites, sur des projets qui étaient peu actifs, où on a découvert des secrets qui donnaient accès à... Au cloud provider, qui donnait accès également, les CITREAT ce sont des mots de passe, à des privilèges sur le kit lab pour pouvoir supprimer des projets. Et donc cette anecdote où nous on était content de trouver des choses, c'est notre but, on était aussi content de l'aider à désamorcer au plus tôt avant que ce soit exploité, mais cette anecdote, elle se répète trop souvent, où on me dit, Aurélien, moi j'ai que... 500 projets, mais 5000 qui sont importants, on ne va regarder que ça. Le problème, c'est que ça se cache souvent dans les détails, ce qu'on n'a pas envie de voir. Il y a un legacy, il y a un historique, il y a des projets qui sont moins visibles que d'autres, mais qui sont quand même présents.

8:42 Et la sécurité, ce n'est pas juste sur des projets qui sont actifs, en tout cas sur la supply chain. Moi, j'inviterais de vraiment s'interroger sur tout le code qui est dans notre repo, dans nos repos, parce qu'on peut trouver des choses dedans qui peuvent permettre d'exploiter et de remonter petit à petit sur d'autres projets qui sont plus actifs. Très bien. Effectivement, je pense que c'est une anecdote qui est extrêmement représentative du reste de la discussion que nous allons avoir. Donc, rentrons maintenant dans le vif du sujet. Parlons sécurisation de supply chain et en quoi l'inner source peut venir y contribuer. Tu as évoqué le terme de supply chain, de chaîne logicielle. C'est peut-être évident, mais peut-être pas. Donc, la première question que j'ai envie de te poser, c'est quoi une supply chain logicielle? C'est vrai que ça paraît évident parce qu'on… On connaît le terme dans l'industrie de la supply chain et on a raison, ça vient de là. On a encore volé des choses dans l'industrie côté IT. On peut faire le parallèle, j'aime bien faire cette explication qui permet, j'espère, de comprendre ce que ça veut dire cette software supply chain.

9:47 Dans l'industrie, pour y avoir travaillé, dans une industrie alimentaire qui fabriquait des pâtes, On a des ateliers de fabrication qui vont fabriquer des spaghettis, par exemple. Et cette spaghetti, à la sortie du four, elle n'est pas exploitable en production directement. Elle va devoir passer par des étapes de conditionnement, de contrôle qualité, du séchage, du pesage, de l'emballage, de la livraison, jusqu'à être livrée dans notre magasin favori pour être consommée par les utilisateurs. Dans le software, moi je parle de software supply chain, on peut avoir cette même image du code qui est produit par nos développeurs, mais qui n'est en soi pas exploitable tout de suite en production, il va devoir passer par un certain nombre d'étapes qui sont propres au projet ou à l'organisation. Donc ça peut être des étapes de test, de buil, de delivery. Mais le but, c'est de le livrer de manière conforme et rapide à un client final. Donc moi, quand on parle de software supply chain, on peut le résumer par l'ensemble des étapes qui va permettre à votre code ou au code de vos équipes de développeurs d'être livré de manière conforme et sécurisée pour un usage par vos clients. Le deuxième mot très structurant pour cadrer notre échange, c'est la notion de dinner source.

10:52 C'est peut-être intéressant de faire un travail similaire rapidement pour amener des clés de lecture? Oui, bien sûr. C'est vrai qu'on est assez familier avec l'open source, qu'on entend parler depuis assez longtemps. L'open source, un peu moins. Très simplement, ce qu'on peut dire, c'est que l'open source, c'est de l'open source adapté au monde de l'entreprise. On prend le meilleur des valeurs de l'open source, le partage, l'amélioration continue, la collaboration, la transparence. Et on lui enlève ce qui peut gêner parfois les entreprises, c'est-à-dire cet accès sans vraiment de restriction au code source. Donc l'inner source, on peut dire que c'est un open source de l'entreprise avec des accès restreints pour votre organisation. Mais qui va permettre au BIP de rester propriétaire de tout le code qui est produit. Ce qui est important, c'est les valeurs, surtout, qu'il y a dedans. Qui sont repris de l'open source et qu'on peut appliquer en interne. Donc, rentrons dans le vif du sujet. Pour toi, aujourd'hui, quels sont les enjeux actuels en termes de sécurisation d'une supply chain logicielle? Tu as bien fait de poser la question avant, qu'est-ce que c'est que cette software supply chain? Je veux juste dire qu'il ne faut pas qu'on oublie que c'est aussi et surtout du code.

11:55 Bien que ce soit des étapes où on a cette image d'automatisation, mais ça reste du code qui est produit par les équipes de développement. Aujourd'hui, ce code, il n'y a pas vraiment de standard. C'est-à-dire que les équipes font un peu ce qu'elles veulent. Alors, ça va marcher. Tout ce qu'on voit, ça fonctionne. Mais on ne sait plus trop ce qu'il y a dedans. Quand on regarde un peu plus près, on peut retrouver trop facilement des choses qui sont dramatiques, la présence de mots de passe, des variables qui ne sont pas assez protégées, des ressources qui viennent d'origine que l'entreprise ne connaît pas et qui pourtant font bien tourner tout le système. Tout ça, ça fonctionne, mais les enjeux là-dedans, c'est qu'on oublie trop souvent que ce code-là de la supply chain, il va accéder à beaucoup de choses. Il va accéder au code de vos projets, parce qu'il va devoir les tester, les builder, les déployer. Il va également accéder à vos environnements cloud, si vous en utilisez, parce qu'il va devoir déployer dessus, donc il va utiliser des credentials, ce genre de choses. Et tout ce code-là accède à énormément d'informations qui sont critiques. Et aujourd'hui, on ne sait pas forcément bien identifier à quoi ce code a accès, comment guérir s'il y a des problèmes dans ce code-là.

12:58 Il y a des exemples. assez connus, je n'invente pas, qui sont sur des... Si vous cherchez des supply chain attacks, vous allez tomber sur SolarWinds, par exemple, où des attaquants ont injecté des portes dérobées dans un processus de distribution de mise à jour. Le but, c'était de toucher des clients finaux. La problématique était dans une mise à jour, donc n'était pas en attaquant la cible directement, mais par une dépendance. Autre faille qu'on peut voir, qui est peut-être un peu plus technique, qui concerne Java, un peu plus récente également, la faille log4j. Cette faille-là permettait d'exécuter du code à travers une bibliothèque de log. Cette bibliothèque de log a été utilisée dans plein d'applications, mais elle est également distribuée dans plein d'applications qu'on intègre dans des frameworks ou qu'on utilise dans nos entreprises. Tout ça, c'est assez dramatique parce qu'on ne maîtrise pas trop ce qui se passe. Pour moi, ce qui me paraît être très compliqué, c'est qu'on ne maîtrise pas le nombre de chocs, qui est énorme. La première étape qui est de détecter et d'identifier le patrimoine qui est impacté, c'est beaucoup trop long et ce n'est pas sûr du tout. Pour avoir discuté avec des entreprises qui ont subi cette attaque, quand ça arrive, c'est un peu la panique dans l'entreprise parce que tout le monde veut des réponses immédiatement, mais personne ne sait vraiment identifier le périmètre, qui est cette première étape.

14:12 Qu'est-ce qui est impacté? Qu'est-ce qui est touché? Et donc, ce sont des situations qui laissent des traces physiques sur les systèmes, mais également sur les personnes qui doivent s'engager à donner des réponses critiques sans avoir les moyens de venir mesurer sereinement l'impact que ça a amené dans les entreprises. Pour revenir et résumer, d'apporter une réponse en peut-être une phrase sur la question. Pour moi, l'enjeu, c'est d'éviter cette situation. Il ne faut pas qu'elle arrive. Et pour éviter, il faut pouvoir anticiper, il faut pouvoir observer, mais surtout maîtriser les ressources qu'on utilise pour construire nos software supply chain. C'est pour moi vraiment la clé. Du coup, la question suivante que j'ai envie de te poser, qu'est-ce que tu observes finalement sur le terrain? Bon, on se dit tout, Philippe. Là, je vais être… Oui, on se dit tout. Je vais être un peu cynique, je ne cite pas de nom, mais ce que je vois aujourd'hui, c'est que dans nos entreprises qui mettent en place un certain nombre de pas plein de CICD, d'automatisation dans leur delivery via des softwares supply chain, elles sont en train de construire des bombes à retardement, si je peux dire comme ça.

15:16 C'est mon quotidien aujourd'hui de parler avec des entreprises qui font ça. C'est aussi mon quotidien de les aider et de parler de ce code. Et je commence à arriver à expliquer, c'est mon but, ce n'est pas juste de dire que ce n'est pas bien, mais d'essayer de comprendre pourquoi on en arrive là. Ce serait trop facile de dire que c'est que les créateurs, les développeurs qui sont à l'origine de ça. Je ne m'arrête pas là, j'ai été développeur, j'ai été aussi manager, donc j'ai l'avantage de ne pas trop prendre parti. Mais ce que je vois sur le terrain, c'est que dans le domaine IT, il y a quelque chose qu'on n'a pas encore, je pense, compris par rapport à ce qu'a compris l'industrie sur le sujet de la supply chain. Dans l'industrie, la supply chain, c'est quelque chose dans laquelle on va investir beaucoup d'argent, beaucoup de temps, beaucoup de ressources, parce que c'est quelque chose en lequel on croit, qui va nous faire gagner du temps, qui va augmenter la cadence, qui va rendre le travail moins pénible. Et dans le software, malheureusement, je ne ressens pas ça. Je ressens plutôt que toute cette automatisation, c'est vu comme un centre de coût plutôt qu'un centre de profit. Et le problème, c'est que je creuse toujours, et je me rends compte que dans les appels d'offres auxquels on va répondre, on va rarement, ou trop peu souvent, trop rarement, mettre une ligne budgétaire sur la supply chain,

16:26 On va mettre de l'industrialisation, mais c'est encore trop faible. Le fait de ne pas... avoir cette ligne budgétaire qui vient dire on va investir sur ce projet, sur la software supply chain, parce que dans tous les cas, il va y en avoir. Vous allez demander à vos équipes d'automatiser des tâches avant de mettre ça en place. Mais le fait de ne pas mettre de ligne écrite, ça ne valorise pas la démarche. Ça, pour moi, c'est la première étape de se dire on va en faire, donc on l'écrit. Et le problème qui vient en cascade de ne pas le budgéter dès le départ, c'est que demain, quand j'ai un développeur qui vient me voir et qui me dit Aurélien, j'ai besoin de 4 heures pour mettre à jour le code de la supply chain parce qu'il y a un problème, là, je ne suis pas en mesure de venir imputer sur quoi que ce soit. Donc, en fait, on ne va pas le faire. Et pour moi, il y a un problème comme ça qui s'enchaîne dès le départ. Si on ne met pas dès le départ qu'on va investir du temps, de l'argent sur l'automatisation, on retrouve derrière des systèmes qui ne vont pas être maintenus, qui ne vont pas être sécurisés, et ça devient la catastrophe. Je suis persuadé que ce n'est pas que technique, ce que je vois sur le terrain.

17:27 J'ai envie de comprendre la cause et je le vois comme un tout. Pour moi, si on valorise mieux cette partie-là, ça nous permettrait d'éviter le chaos que je suis en train de voir qui se dessine et de remettre vraiment une place un peu plus belle pour cette software supply chain qui redeviendrait un centre de profit plutôt qu'un centre de coût aujourd'hui. Donc en fait, industrialiser son code, c'est bien, mais industrialiser sa supply chain, ça paraît complètement nécessaire quand on t'écoute. Et a priori, ce n'est pas vraiment ce que tu observes dans ton quotidien. Du coup, si on veut essayer de... Regardez comment apporter des éléments de réponse. Quelles sont pour toi les meilleures pratiques ou les conseils que tu pourrais partager pour pouvoir surveiller les menaces et les vulnérabilités de cette supply chain? Alors, moi, je conseillerais de commencer simple. D'abord, il faudrait avoir des choses qu'on arrive facilement à observer. Que ce soit rapide, que ce soit simple à faire, qu'on puisse obtenir des réponses quand on en a besoin, Je ne parle pas encore d'alerting. Pour moi, l'alerting dans ce domaine-là, c'est l'étape d'après.

18:27 Il y a déjà des choses à faire, de venir regarder et de comprendre ce qui se passe avant de parler d'alerting, mais c'est une bonne prochaine étape. Le but pour moi aujourd'hui, c'est de pouvoir avoir des informations fiables et sûres dès qu'on en a besoin. Par exemple, si à chaque fois, je vais prendre un exemple de la vie quotidienne, Si à chaque fois que tu voulais être assuré sur ton niveau d'huile dans ta voiture, à chaque fois que tu voulais avoir cette information, tu devais t'arrêter, descendre de ta voiture, ouvrir le capot, couper le contact. Prendre les mesures et remonter, c'est un peu long. Et il y a un moment, tu ne vas plus le faire et à un moment, tu vas tomber en panne. Donc, il faut qu'on puisse observer tel qu'un tableau de bord te donne l'info dès que tu en as besoin. On regarde trop souvent, mais au moins, ça te rassure. Et c'est pour moi la première étape aujourd'hui, c'est de pouvoir voir. Pour que ce soit simple à observer, parce que c'est bien beau de dire qu'il faut observer, il faut pouvoir se mettre d'accord sur une façon de travailler en entreprise. Aujourd'hui, le code dans la supply chain, on fait un peu ce qu'on veut, il n'y a pas de normes. Et c'est peut-être ça le problème. Donc, il ne suffit pas d'avoir une norme internationale.

19:30 Ce que je demande, même si peut-être un jour ça arrivera, mais déjà en interne d'entreprise, ce serait beau de se dire, on travaille toujours de cette façon-là pour rendre beaucoup plus facilement la maintenance et aussi l'observation. Et c'est là où l'innovation prend du sens, et là où on peut raccrocher le discours de ce podcast. Il y a de la sécurité, mais il y a aussi l'innovation qui peut permettre vraiment d'enclencher cette étape-là. Pour moi, ça prend énormément de sens par rapport à ce que je vis tous les jours, de pouvoir créer et partager un patrimoine commun en entreprise sur lequel les équipes se sont mis d'accord. Il n'y a pas besoin de suivre une norme. On peut aussi inventer sa propre norme. C'est déjà une bonne première étape en interne d'entreprise. Ce qui va permettre à moyen terme de gagner énormément de temps dans les opérations de maintenance, d'observation, de compréhension de ces systèmes et aussi de donner un cadre beaucoup moins dangereux aux équipes de développement qui vont devoir intervenir sur des systèmes qu'on commence à connaître. Le point qui peut-être est intéressant maintenant de regarder, c'est qu'évidemment, il y a tous les contextes de sécurité que tu viens de nous partager depuis déjà quelques minutes, mais on est peut-être à un moment aussi

20:37 un peu différent parce qu'on a des évolutions, notamment réglementaires, et je pense par exemple à une directive comme NIS2. Et en fait, finalement, ces évolutions réglementaires, elles peuvent avoir des impacts extrêmement structurants sur le sujet de la sécurisation de la supply chain logicielle. Et donc, du coup, finalement, ça devrait clairement amener nos auditeurs à se questionner sur le sujet. Qu'est-ce que ça t'évoque, finalement, ce contexte d'évolution réglementaire? Ça va dans le bon sens. Bien sûr, il y a du travail parce que ça va demander beaucoup de changements. Donc, tu parles de Nice 2, c'est vrai que c'est celle qu'on entend de plus en plus aujourd'hui. À première vue, il y a une évolution par rapport à Nice 1 sur les secteurs des entreprises qui vont être concernés, tels que la santé, l'énergie, mais on a aussi les fournisseurs de services. service numérique. Il n'y a pas de liste finalisée aujourd'hui, je crois que ça va se décider pour en 2024, mais il y a quand même aujourd'hui un critère qui ressort.

21:38 Nice 2, ça va toucher des entreprises qui ont un certain nombre de personnes, il me semble que c'est 50 employés, 50 personnes, et un chiffre d'affaires supérieur à 1 million d'euros. Ce n'est pas non plus tout le monde. Mais ce qui est important de comprendre, c'est pourquoi cette directive à l'arrivée, le contexte, et ça c'est l'ANSI qui nous le dit, c'est qu'aujourd'hui, il y a 60% des attaques qui sont signalées à l'ANSI qui viennent de ces structures-là. Et de plus en plus, le type d'attaque provient d'attaques type supply chain, venant d'un sous-traitant ou d'une dépendance. Donc, ça fait du sens vraiment parce que je pense qu'il voit aussi des choses. Ce n'est pas juste pour dire on va sortir une norme. Il est encore trop tôt, je fais des recherches, mais encore trop tôt pour avoir un document qui liste exactement ce qu'on doit suivre. Il y a quand même des grandes catégories qui sont du classique, mais qui ne sont pas encore assez précises à mon goût, de pouvoir, par exemple, déclarer dans les 24 heures un accident, un incident, d'utiliser du chiffrement fort, garantir la continuité opérationnelle.

22:40 En cas d'incident, et on commence aussi à voir des choses sur garantir la sécurité des supply chain. Donc, c'est là où je pense que ça va demander à toutes nos entreprises qui sont concernées de venir commencer à regarder ce qu'on utilise pour construire nos supply chain, s'intéresser de plus près aussi à ce code. Parce que c'est du code qui, pour l'avoir vécu quand vos supply chains s'arrêtent, vous ne livrez plus en production. Donc, ça peut avoir des impacts énormes, pas que sur la production, mais aussi sur le produit, puisque, comme je vous l'ai dit, c'est du code qui touche à beaucoup de choses, et notamment à votre code applicatif. Donc, c'est bien qu'on s'intéresse à ce sujet-là. Je suis curieux de voir ce qu'on va nous demander. Mais en tout cas, pour moi, il faut commencer à en avoir conscience. Je pense que ce que tu viens de dire là est vraiment très structurant parce qu'en plus du contexte qui est peut-être un peu plus évident quand on parle de sécurité, pour moi la dimension réglementaire finalement amène une deuxième lame qui peut être extrêmement impactante vis-à-vis de la façon dont les entreprises peuvent être amenées

23:45 à gérer leur business, d'autant plus quand on est basé sur un business qui est très software-centrique, avec du digital, et qu'on produit ce code-là. La maîtrise finalement de cette supply chain, oui, on le fait pour des raisons de sécurité, mais on va se rendre compte qu'on va être de toute façon amené à le faire, tout simplement pour être en situation de pouvoir répondre à des trajectoires réglementaires. Et là, on a parlé de Nice 2, mais il y a d'autres trajectoires qui se jouent au niveau européen qu'il va falloir intégrer. La question suivante qui me vient à l'esprit, Aurélien, c'est que finalement, quels conseils tu pourrais donner, évidemment à part déployer R2Devops, qui est forcément la... réponse naturelle à laquelle tu vas penser, mais concrètement, une organisation qui envisage d'adopter l'InnerSource pour améliorer la sécurité de sa supply chain, qu'est-ce que tu apporterais comme conseil à ces organisations ? Le premier conseil que je te donne, évidemment, c'est notre approche, c'est une façon de répondre aux problèmes, il y en a certainement plein d'autres, c'est ce qu'on pousse.

24:53 Ce qui est important de comprendre derrière, c'est que c'est quand même alimenté par de l'InnerSource, pour que ça marche. Il y a plusieurs choses dans R2Devops, mais là, si on veut parler d'InnerSource, qui est vraiment pour moi la première étape pour la standardisation et maîtriser ce qu'on met dans nos supply chains, c'est ça dont j'ai envie de parler quand tu me poses cette question. L'InnerSource, c'est une belle idée, c'est bien, mais ce n'est pas magique. Ça ne marche pas tout le temps. Il y a une formule, il y a quand même des conditions qui vont faire que ça va marcher. Notamment, ça nécessite un investissement certain. Mais aujourd'hui, je sais que cet investissement, il vaut la peine. Il faut être en mesure de l'identifier, de se dire, OK, on est prêt à faire cet investissement. Mais aujourd'hui, quand je parle à des équipes de développement, je vois qu'elles réinventent systématiquement la roue, comme nous on a pu le faire, qu'elles emportent la connaissance à chaque fois qu'il y a du mouvement, du turnover ou autre, je suis convaincu que l'InnerSource serait une bonne solution. Et c'est ça le message que je porte. Maintenant, avant de se lancer dans l'InnerSource, c'est un investissement, ça doit se discuter.

25:53 Et un conseil que je peux donner qui marche bien, c'est premièrement de s'assurer que ça va vous aider et que ça va aider tout le monde, parce que l'InnerSource tout seul, ça ne marche pas. Et pour ça, je vous encouragerais à interroger vos équipes, vos plateformes d'ingénierie, vos équipes DevOps, enfin tous ceux qui touchent de près ou de loin les supply chains, et de leur demander est-ce qu'elles ont le sentiment de réinventer la roue. Vous pouvez leur poser la question comme ça, à chaque fois qu'elles vont coder leur pipeline CIC. Donc les pipelines CIC, ça va leur parler, c'est dans leur jargon, c'est le code qui va servir à créer vos supply chains. Posez-leur la question et si vous remarquez une tendance affirmative, c'est peut-être qu'il y a de la duplication de code, ou il y a une perte de connaissance, ou il y a des choses que l'innocence pourrait vous aider à résoudre. Une deuxième question, adaptée plus à une typologie d'entreprise qui a un certain nombre d'équipes, ou plusieurs équipes tech en interne, est-ce que, ça je la pose parce que j'ai découvert, bizarrement que c'était le cas, mais en posant la question, on peut le savoir bien plus tôt, c'est de leur demander, est-ce que vous savez comment vos collègues mettent en place leur PAPN-CSI?

26:57 Est-ce que vous connaissez la façon dont, dans tel département, ils font pour déployer tel type d'application? Et encore une fois, si vous voyez une réponse qui a une tendance au non, c'est que potentiellement, vous avez plusieurs équipes qui font plusieurs fois la même chose, qui va diverger, qui va falloir maintenir dans le temps, et que là encore, l'InnerSource pourrait être une solution envisageable pour harmoniser le tout. Encore une fois, si vous n'avez pas beaucoup de projets dans votre environnement, cette approche va rester valable, mais là où on sent vraiment la valeur, c'est quand vous avez un certain nombre de projets, un certain nombre de pipelines, avec plusieurs équipes techniques potentiellement, qui sont en train de réinventer la roue sans le savoir. Donc vraiment, le premier conseil, pour résumer, ce serait d'aller chercher des infos auprès de vos équipes, savoir si elles ont les problèmes, par des questions, je vous en ai donné deux, et est-ce qu'elles pensent que l'InnerSource pourrait être une solution? Parce que si vous décidez de partir dans cette démarche d'innovation, ce seront eux les moteurs de la contribution, ce n'est pas quelque chose qu'on va faire non plus tout seul. Est-ce que tu as une forme de potion magique sur comment s'assurer de l'adhésion des équipes de développement et de la direction?

28:00 finalement, dans le modèle d'InnerSource que tu viens de présenter. Oui, c'est vrai que c'est la première étape quand on dit, OK, on a validé que l'innersource pouvait être une option, mais maintenant, comment on le met en place et comment on s'assure que ça va être un succès? Ce n'est pas suffisant d'avoir juste une bonne idée et de mettre en commun de la connaissance. J'ai vu beaucoup d'initiatives comme ça où on démarre, mais c'est un feu de paille, ça s'arrête parce qu'il y a d'autres choses, il faut l'alimenter en fait ce mouvement-là. Et pour moi, il s'alimente, il faut du soutien de la direction. Pourquoi? Pas juste pour dire, allez-y les gars, c'est bien, c'est parce que ça va demander du temps aussi à ces équipes qui initient le mouvement de pousser la bonne parole, d'aller accompagner les équipes, de leur montrer, maintenant on travaille de telle façon, d'aller harmoniser les procédés. Et tout ça, c'est du temps, je l'entends, c'est du temps où on ne va pas produire peut-être son cœur de métier, mais c'est du temps où on va évangéliser, on va pousser la bonne parole en interne pour que le système prenne à l'échelle. Ça, il faut que ce soit accepté aussi par la direction, que ces équipes-là vont devoir passer du temps à en parler. Et le deuxième point super important, c'est de pouvoir rendre la contribution facile.

29:04 Si moi, j'ai envie de participer au mouvement, il faut que je puisse le faire de manière simple. Il ne faut pas que ça me demande énormément de travail, sinon je vais me décourager, je ne vais pas le faire. Donc, si on a ces deux éléments-là, du soutien, je dirais trois, des personnes qui sont convaincues, qui sont motrices, un soutien de la direction qui invite des personnes à en parler lors de talks, à passer du temps dans les équipes, et également un moyen simple de venir contribuer pour que d'autres personnes s'embarquent dans le mouvement, parce que le but, ce n'est pas non plus qu'il n'y ait que les originaux de départ qui contribuent et qui maintiennent ça. Si on a ces trois choses-là, ça permet d'avoir vraiment une belle mécanique et de sentir la magie de l'inersource qui prend. Merci beaucoup Aurélien, je pense que tu as apporté des éléments de réponse particulièrement pertinents, à la fois dans la dimension sécurité de la supply chain, et je pense que tu as bien illustré en quoi finalement l'inner source est un moyen de pouvoir y répondre. On est en train tranquillement de se dire... Riger vers la fin de notre échange. Mais avant ça, peut-être une question que j'ai envie de te poser.

30:07 Est-ce que tu as un agenda particulier? Si les personnes qui sont en train de nous écouter ont envie de venir à ta rencontre ou écouter des talks à venir, est-ce que tu as un agenda à nous partager? Oui, je vais essayer de le faire dans l'ordre, parce que là, j'ai une vision jusqu'à l'été, je pense que ça suffit, mais on va se rendre au FIC, le Forum international de cybersécurité à Lille, du 26 au 28 mars, où on va exposer notre innovation avec la délégation au Citanique. Si vous voulez aller voir un peu les entreprises du Sud, on sera là. Donc nous, notre but, c'est vraiment de montrer qu'on est là pour vous aider à désamorcer des bombes, à éviter le chaos dans vos softwares supply chain. Donc on sera présent. On sera aussi présent à un événement qui voit le jour à Paris le 11 avril, qui s'appelle le CICD Day. C'est la première édition. On est très content d'être sponsor. C'est très spécifique CICD. Donc si vous avez l'appétence sur ce sujet-là, il y aura des acteurs de la CICD et nous, on y sera aussi. On va également exposer au Devox Paris 17-19 avril.

31:11 On sera à Vivatech Paris aussi, donc c'est beaucoup Paris, avec la délégation au CITANI encore une fois. Et personnellement, je vais donner un talk au DevOps Day à Genève le 13 ou le 14 mai. C'est par là. Et c'est vraiment un talk qui est aligné avec ce qu'on se dit, puisque le titre, c'est« Leader Source comme rempart». contre le chaos dans vos softwares supply chain. Donc, c'est clairement une autre illustration de ce qu'on est en train de se dire là. Et clairement aligné. Très bien. Du coup, finalement, on a pas mal d'occasions pour pouvoir aller à ta rencontre et pouvoir aller creuser et rentrer un peu plus dans le détail. Donc, on arrive à la fin de notre podcast. Une dernière question que j'aimerais finalement te poser. Puisque tu sais, la population Tech.Rocks, on s'adresse vraiment à des profils de CTO, de VP, de Head of Engineering. Finalement, quelles sont pour cette population-là les tendances à surveiller dans les années à venir en termes de sécurité de ce playchain logiciel?

32:14 Qu'est-ce qu'il faut que les leaders de la tech intègrent dans leur playbook? Malheureusement, je ne vais pas vous donner une solution miracle ou un outil à tester. Ce que je peux vous dire, c'est que je pense qu'on a une quinzaine d'années de retard en ce qui concerne le code de nos chaînes d'approvisionnement. Je n'ai pas de problème à le dire maintenant que je suis au quotidien. J'aimerais plutôt qu'une tendance ou qu'un outil, c'est qu'on commence à avoir conscience que c'est vrai et que c'est aussi du code. Et que c'est surtout du code qui est aussi crucial que notre code applicatif. Quand je parle du code applicatif, ça peut être votre code Java, votre code PHP, peu importe. Pour moi, c'est cette prise de conscience qui va être vraiment le game changer qui va venir ensuite. Actuellement, on porte beaucoup d'attention sur ce code applicatif. On est tous familiers avec des outils comme Sonar, où on va regarder vraiment ce qui se passe dans ce code-là. On examine aussi beaucoup les applications une fois qu'elles sont construites, qu'elles sont livrées, on va les tester, on va faire des montées de charges, des tests de sécurité.

33:15 Mais pour ma part, moi ce que j'aimerais, c'est qu'on commence à regarder ce qui rentre d'eux. Le tuyau, ce n'est pas plein de CICD, ce code-là, Donc, on regarde dedans qu'est-ce qu'on met, est-ce que c'est critique, est-ce que c'est maintenable. Et c'est ça pour moi la nouvelle tendance, c'est plutôt ce changement de mindset. Il faut continuer à regarder le code applicatif, il faut continuer à tester nos applications, mais aussi regarder et qu'on admette qu'il y a du code entre deux, ce code de la supply chain, et qu'il est tout aussi important, parce que c'est cette colonne vertébrale de notre délivré, et qu'il est temps qu'on y mette autant d'attention et de rigueur que sur notre code applicatif. Merci Aurélien, encore un épisode qui est passé bien vite. Merci pour la passion et l'énergie que tu as apporté. Je pense que ça a permis à notre audience de comprendre, si ce n'était pas déjà le cas, l'importance de cette prise de conscience des enjeux de sécurité liés à la supply chain software. Et certainement, finalement, le bien le plus précieux de toute entreprise qui met le logiciel au cœur de sa stratégie et qui en produit.

34:19 Donc, pour toutes ces raisons-là, merci beaucoup pour tes partages. Et je propose peut-être de terminer notre podcast. Sur un dernier mot de ta part? Oui, écoute, moi, je… Je te remercie à mon tour de m'avoir invité et je serais ravi d'avoir allumé quelques lumières pour vous aider à éviter le chaos dans vos secteurs sur Playchette.