DevSecOps à l'échelle : retour d'expérience de Tiime Software

0:05 Sans plus tarder, nous allons replonger dans cet univers de l'intelligence artificielle. Alors figurez-vous que dans la version sécurité de Matrix, Grégory et Sébastien sont un peu nos Morpheus et Néo du DevSecOps. Ils ont vu la faille, ils ont trouvé le patch. Je vous trouve encore bien dissipée par rapport à ces belles intros que j'ai préparées à chaque fois. Alors donc, ils ont trouvé le patch et ils viennent nous expliquer pourquoi la pilule rouge, c'est souvent un scan Snyk. Je vous demande d'accueillir Grégory Domagala, Staff Solution Engineer de Snyk, et Sébastien Barre de CISO Tiime. Messieurs. Je vous demande de prendre place. Alors, j'ai une petite indication à vous formuler juste avant. Si vous entendez une petite musique qui fait comme un petit tic-tac, c'est que nous approchons très très sérieusement de la fin de votre talk, si tant est que vous ayez complètement bouffé votre temps préparé.

1:09 Donc ne vous inquiétez pas et je viendrai délicatement faire une petite danse derrière vous pour spécifier que le temps des questions-réponses approche. Ok, ça va pour vous? Super, merci. Vous avez la zapette? Si vous avez des slides, je ne sais pas si vous avez des slides ou pas, donc zapette pour vous. N'hésitez pas à vous en servir. Et puis, je vous laisse, ils sont hyper sympas, vous allez voir. C'est vrai. A plus. Merci. Bonjour et merci d'être présent à ce talk qui va être dédié à la sécurité applicative. Je m'appelle Grégory Domagala et effectivement je suis staff solution engineer chez Snyk, maintenant depuis un an, pas demain, ça fera un an. Qui connaît Snyk? Juste lever la main s'il y a... D'accord, ok. Snyk c'est une entreprise qui édite une plateforme de sécurité applicative, justement pour s'intégrer dans les chaînes CI, dans les SCM, afin de... Dès que j'ai un truc, il faut que je l'exploite. afin de regarder un petit peu ce qui se passe dans le code, dans les librairies, mais on va également plus loin, j'en parlerai un petit peu, sur la partie IA, qui devient une grande préoccupation maintenant.

2:16 Je suis accompagné de Sébastien, que je vais laisser se présenter. Bonjour Grégory, bonjour à tous, bonjour à toutes. Je suis Sébastien Barre, RSSI chez Tiime. Tiime, c'est 250 collaborateurs, dont 110 personnes dans les équipes tech qui développent nos produits. Et nous avons 5 produits majeurs. Un logiciel d'aide à la comptabilité pour les TPE, PME et les experts comptables. On a une solution de compte pro. Et on développe en ce moment une plateforme de paiement dématérialisé, une PDP. Et donc, dans ce contexte, nous avons des enjeux de sécurité sur nos produits assez forts, sur la sécurité de la donnée de nos clients également, et des enjeux de conformité. C'est dans ce contexte-là que j'ai rencontré Grégory il y a quelques mois pour évaluer des solutions de sécurité des applications. Et ce que je ne savais pas à ce moment-là, c'est que Grégory allait dresser la trame du talk de ce jour. Mais évidemment, moi, je vais vous présenter comment Tiime a développé son programme de sécurité applicative.

3:17 Merci Sébastien. Effectivement, le but c'est vraiment d'avoir un retour d'expérience de Sébastien sur comment il a monté à l'échelle son programme de sécurité applicative. Alors ce talk qui sera divisé en trois parties. D'abord le contexte initial, pourquoi il y a un besoin de sécurité applicative chez Tiime. Ensuite la phase de test. Qu'est-ce qui s'est passé durant le test ? Comment ont été évaluées les solutions? Et puis enfin, le futur, comment on va encore améliorer le programme de sécurité applicative chez Tiime? Et également la conclusion à la fin. Du coup, ça va être un peu une sorte d'interview. On va essayer de comprendre un petit peu le pourquoi, Sébastien, c'était quoi le contexte initial, pourquoi à un moment donné, Tiime a eu besoin de s'équiper en outils de sécurité applicative, si tu peux nous en dire un peu plus. Oui, bien sûr. Chez Tiime, on avait une approche où on avait une solution existante de contrôle de sécurité de nos codes, mais plutôt centralisée, gérée par les équipes cyber, avec très peu d'usage direct par les équipes tech.

4:24 Tout ça pour des problèmes d'intégration et d'adaptation à l'usage qu'ont les techs de ces outils et d'intégration dans leurs méthodes. Ce qu'on a voulu faire, c'est changer les usages autour de ces solutions et mettre la solution au plus près de nos équipes techniques. En termes de besoin, justement, ce besoin d'avoir un outil de sécurité applicative, c'était quelque chose qui est venu d'audit ou de ce genre de choses? Ça a été imposé? C'est quelque chose qui a été demandé par les équipes de dev aussi ? Alors, on n'avait pas d'enjeu d'audit, de conformité. On a évidemment les besoins d'assurer la sécurité de nos produits. Déjà, c'est plutôt un besoin interne. On a des enjeux, comme je disais, autour de sujets de conformité, de démontrer les pratiques de sécurité de notre code. Après, c'est plutôt une approche pragmatique et de méthode actuelle où les équipes de dev produisent du code assez fréquemment.

5:33 Et donc, on ne peut plus se permettre d'avoir un outil centralisé avec une latence et un silotage entre les équipes cyber et les équipes tech qui rendent un peu... La mécanique lente et inappropriée. Merci Sébastien. En termes d'ambition, c'était quoi justement ces objectifs que tu cherchais à atteindre avec un outil de sécurité applicative? Qu'est-ce que tu recherchais dans l'outil? Oui, donc ce qu'on a rapidement identifié, c'est les causes de la non-adoption. Et donc, on a cherché à les transformer en critères d'adoption. C'est simplement la facilité d'usage de l'outil. Donc, à travers la facilité de l'usage, nous, on y voyait plusieurs enjeux. On a évidemment le besoin de produire un indicateur pertinent aux personnes qui vont utiliser l'outil. Donc ne pas être noyé dans une multitude. d'informations et de couvrir un périmètre trop large.

6:33 Au contraire, on a voulu organiser notre mécanique de contrôle en représentant notre organisation de produits, nos organisations d'équipe, et donc distribuer l'information directement au sein de nos tribus. Ça, c'était un premier enjeu. Ensuite, on avait l'enjeu de l'usage. L'usage, c'est plutôt comment on fournit l'outil aux équipes de développement pour qu'elle en ait un usage le plus natif possible par rapport à leur pratique. Donc là, avec les solutions retenues, ou en tout cas dans le cadre de l'étude qu'on a menée, on identifiait une problématique qui est le scan désynchronisé. Donc typiquement, on se dit qu'on scanne toutes les deux semaines, tous les mois, et puis produire des résultats à une cadence qui n'est pas celle des équipes qui produisent le logiciel. Et inversement, les points d'intérêt, c'est de produire le contrôle dans l'IDE, lorsque le développeur produit son code, ou alors au sein de la forge logicielle dans les mécaniques de pipeline.

7:44 Et on avait un autre jeu. Le troisième, l'efficacité des scans, évidemment. Les équipes sont intéressées sur un indicateur de qualité et donc éviter les faux positifs et couvrir des enjeux de sécurité. qui intéresse les équipes, que ce soit technique ou au sein de l'équipe cyber et de la direction. Merci Sébastien. C'est important, dans les ambitions, on parle souvent d'un programme de sécurité applicative, qui va utiliser à la fin ces outils? Ce sera le développeur. Donc il faut vraiment que ce soit bien intégré dans les outils du développeur, dans l'IDE, dans le SCM, pour ne pas qu'il ait à sortir de ces outils dont il a l'habitude. On essaie vraiment de les aider à s'acculturer, on y reviendra après sur la sécurité applicative, notamment en leur proposant des facilités, notamment avec de l'IA, pour fixer les vulnérabilités directement dans l'IDE à base d'une IA qui s'appelle Snyk Agent Fix, et qui permet de corriger assez facilement avec le contexte du code, ce qui est hyper important.

8:49 Du coup, on a bien compris la partie contexte. On va passer dans la partie processus de choix. Comment s'est passé ce processus, l'évaluation de Snyk? Qu'est-ce que tu as regardé le plus dans la solution? Et un petit retour d'expérience sur cette partie évaluation de Snyk. Oui, donc ce que moi j'ai regardé le plus, ça va être l'intérêt pour un ciseau, une équipe cyber. Et évidemment, on n'a pas fait l'évaluation seul, on a intégré nos ops, nos devs, pour justement s'assurer qu'on a aussi des critères qui soient représentatifs de tous les enjeux qu'on aurait dans la société. et sur la sécurité de nos applications. La première, elle est un peu évidente, c'est la capacité à couvrir les technologies utilisées par les équipes de développement. Lors de nos études, on a vu que des produits pouvaient ne pas tout couvrir, ne pas couvrir aussi bien une techno qu'une autre. Et sans avoir énormément de technologies différentes, on a quand même au sein des équipes des différences.

9:53 Et donc, on voulait s'assurer de la capacité à tout couvrir. Le deuxième, j'en ai parlé... précédemment, c'était la capacité à segmenter la façon dont est organisé l'outil et la façon dont il va distribuer les informations aux équipes techniques, aux équipes de dev. Donc là, c'est l'idée d'apporter une information utile sur les résultats des évaluations. La qualité du produit, plus sur les enjeux qu'on peut connaître, de faux positifs, de pertinence de résultats, facilité d'accès, facilité des remédiations aussi, tout ce qui va permettre un usage facile et efficace des équipes. Présentation des résultats, j'en parlais, on a aussi l'enjeu d'éviter le silo et surtout de mettre en capacité d'action les équipes qui malheureusement peuvent parfois créer ces bugs.

10:54 Donc leur apporter un résultat, en tout cas une explication, un premier volet d'information sur l'explication. C'est quoi le problème rencontré par Snyk et comment le corriger? Donc ça c'était sur la partie qualité et présentation. Et le dernier point, évidemment, la facturation, parce qu'il y a toujours aussi des enjeux. Donc facturation, parce qu'on a différents modes au final, et ça va sûrement dépendre de l'organisation de la société qui va intégrer. Est-ce que c'est de la facture par siège, par projet? Et donc voilà, nous on avait un intérêt. aussi dans la solution Snyk. Je suis étonné, en tant que RSSI, tu n'as pas parlé de dashboard, de KPI, c'est ce qui est demandé aussi par les ciseaux, clairement. Et du coup, le point de bascule, quel a été le point de bascule? Parce que j'étais présent lors de l'évaluation, je représentais Snyk, mais il y a eu plein de solutions testées, qu'est-ce qui a fait basculer?

11:57 Voilà, sur Snyk. Avant tout, la qualité des personnes qu'on a eues en avant-vente. Non, non, non, je plaisante. C'est surtout la qualité des résultats, comme on l'a dit, on avait cerné nos besoins par rapport à des problèmes existants, ou en tout cas à des axes d'amélioration existants. Et le fait de faire ces évaluations de plusieurs produits et de définir nos critères, donc qu'est-ce qu'on souhaitait, quels étaient nos indicateurs de succès, et puis à la fin, une évaluation la plus neutre possible pour retenir une solution. Tu peux nous en donner un peu plus d'informations aussi sur la partie intégration parce qu'elle est importante. Encore une fois, tous ces outils, il faut qu'ils s'intègrent parfaitement dans tout un écosystème. Ça peut être du ticketing avec du JIRA par exemple, ça peut être de la CI-CD, de la vieille CI-CD mais avec du J-Kins. On ne parle pas d'FCM.

12:58 On essaye aussi d'avoir un... un produit qui s'intègre assez facilement. Est-ce que tu as un retour là-dessus, sur cette partie intégration de la solution? Comment tes équipes, comment les développeurs ont perçu cette solution? Oui, donc deux étapes dans l'intégration, l'intégration technique dans un premier temps qu'on a opéré. En structurant le produit, en y définissant les différents niveaux d'organisation et en introduisant les différents comptes utilisateurs sur ces structures, donc donner la capacité aux personnes d'accéder à l'outil. Et ensuite, une deuxième étape, enfin... Deuxième étape dans cette partie intégration technique, qui était d'introduire le code et les répertoires directement depuis Git dans les équipes qu'on avait construites dans l'outil. Une fois que cette étape préparatoire était en place, on a formé et assisté les équipes produits dans leur usage, en leur présentant l'outil, en assurant les repos qu'ils souhaitaient intégrer.

14:04 Auprès de leurs équipes et enfin en suivant pendant 3-4 semaines la vie de l'usage des équipes techniques pour ensuite consolider l'usage et le sanctuariser à travers des reportings. Les fameux dashboards un peu plus assurés. Merci Sébastien. Justement, on est dans la phase où tu as pu choisir l'outil, le plus il reste à faire, maintenant c'est la montée à l'échelle d'un programme de sécurité applicative. Et du coup, tes premiers résultats, quels ont été tes premiers résultats justement quand tu as commencé à déployer? On parlera un petit peu aussi de process parce que c'est important tout à l'heure, mais déjà tes premiers résultats quand tu as commencé à scanner fort. Oui, donc on a eu des résultats attendus et des résultats... produit par opportunité lié à l'usage de l'outil. Les résultats attendus assez classiques, des métriques et des écarts sur le code, sur les usages qu'on peut faire de l'intégration du code.

15:17 Et ce qu'on a eu comme opportunité à travers Snyk, c'est de voir plus la partie déploiement, donc avoir des contrôles sur les conteneurs, avoir des contrôles sur nos scripts de déploiement. Donc ça, c'était un premier gain lié à l'usage de l'outil. Ce qu'on a aussi apporté avec l'outil, c'est la production des métriques. On y vient. Donc, de mesurer des tendances, c'est-à-dire, typiquement, ce qui nous intéresse, nous, un des cas piéclés, c'est de voir l'évolution des écarts par rapport au sprint. Est-ce qu'on a plutôt une tendance haussière? Il y a un manque de qualité de formation, d'action, ou est-ce qu'on a plutôt une tendance à la baisse, où là, effectivement, on peut présenter l'apport de l'outil et la bonne implication de l'ensemble des acteurs. Donc ça, c'était quelque chose qui était natif dans les indicateurs et auxquels on peut accéder rapidement et qui intéresse tout le monde.

16:25 Donc oui, j'en parle, structurer les métriques. Donc ça c'est les... les indicateurs plutôt de base natif et ensuite l'usage qu'on en fait donc là c'est aller identifier ce qui va intéresser plutôt les équipes tech, la direction ou un indicateur de niveau organisation. Tout ça c'est l'ajustement dans l'usage. Merci Sébastien. On va parler de blocage d'EPR. Je ne sais pas si dans la salle il y a beaucoup de développeurs qui participent à du développement. Est-ce que vous aimez bien qu'on vous bloque vos PR? Je ne pense pas. Généralement, quand je parle à un RSSI, la première chose qu'il demande, c'est est-ce que Snyk est capable de bloquer les pipelines, le code, avec par exemple un seuil de criticité sur des vulnérabilités. Et justement, je voulais un peu avoir ton avis là-dessus, parce que je trouve que ce n'est pas une bonne méthode tout de suite. Il y a d'abord un peu d'acculturation des développeurs à avoir, en tout cas que toutes les équipes soient bien au fait de l'outil, comment il fonctionne, avant de commencer à bloquer les développeurs, parce qu'ils ne vont pas aimer du tout.

17:30 Et le but, c'est de faire encore une fois travailler les équipes sécu avec justement ces équipes de développement. Je ne sais pas si tu as un peu de feedback là-dessus sur comment tu as mis en place cette partie-là et comment ça a été reçu. Oui, en tout cas ce que je peux dire c'est que c'est souvent une des premières questions qu'on se pose. Ce n'est pas la première fois que je fais l'exercice et ce n'est pas la première fois que j'ai la question. Je ne pense pas qu'il y ait forcément une façon de faire, un objectif. à définir sur est-ce qu'on bloque, est-ce qu'on ne bloque pas. Moi, en tout cas, c'est ce qu'on a fait chez Tiime, c'est plutôt un enjeu de méthode et de se dire comment on va arriver à réduire, avoir un produit qui répond aux enjeux de sécurité, à l'appétit au risque. À notre envie de sécuriser le produit. Et pour ça, je pense que toutes les organisations ont des niveaux différents en fonction de la criticité. Et pour répondre un peu plus directement à la question, chez Tiime, on a les deux approches.

18:36 On a des équipes qui bloquent les PR. Et on a des équipes qui vont plutôt utiliser l'outil pour produire des PR, aller les contrôler au cycle du développement et mesurer un résultat en fin de sprint. C'est hyper important. Quand on monte un programme de sécurité applicative, on en parlait un petit peu tout à l'heure, il y a trois piliers essentiels. Il y a le produit. Il y a le process et également le people, on appelle ça les 3P, les gens. Parce que vous allez vous mettre un outil, alors l'outil il faut qu'il soit clairement intégrable, facile d'utilisation, que les développeurs aiment, mais également derrière un process, par exemple sur de l'application Legacy, vous allez récupérer un certain nombre de résultats, qu'est-ce que vous faites de ces résultats, qui va les corriger également? C'est la partie process, donc il y a un peu d'acculturation aussi. Quand on utilise ce genre de produit. Je ne sais pas si dans vos entreprises, vous êtes confronté justement à des programmes de sécurité applicatif. Intégrés dans vos pipelines, mais c'est important que tout le monde soit acculturé à ça.

19:45 Du coup, la suite c'est quoi? On va peut-être parler un petit peu aussi d'IA et ces choses-là. Comment tu vois la suite? Comment tu vas encore améliorer ton programme de sécurité applicative chez Tiime? Oui, effectivement. J'ai eu la chance déjà de participer au call avant et j'ai vu qu'il y avait un gros enjeu il y a... Dans ce summit et on l'a évidemment chez Tiime. Ça fait partie des axes d'évolution, des usages, des développements, des usages qu'on peut avoir du produit. Déjà des choses un peu plus globales sur Snyk, c'est qu'il y a un panel de possibilités et d'usages qui sont assez vastes. Donc là, depuis les quelques mois où on a utilisé l'outil, on a déjà mis en place des améliorations dans... l'organisation, la sensibilisation, donc assurer que l'usage soit bien stabilisé, comme j'ai pu le dire auparavant.

20:49 Et là, on rentre effectivement dans la phase d'amélioration. On voit de l'amélioration sur le périmètre qu'on couvre. Aller chercher d'autres produits qui étaient peut-être moins visibles, d'autres équipes. Et ensuite améliorer l'usage de l'outil. Donc là typiquement il y a les PR check que moi je trouve très intéressantes plutôt que... Voilà en tout cas de se dire qu'on vérifie aussi la correction qu'on a apporté et aller chercher un indicateur un peu plus qualitatif sur la correction des écarts. On a aussi effectivement des usages liés à l'IA. Donc je crois que c'est toi qui en parle le mieux pour le moment. l'intégration dans l'IDE. Et sinon, chez Tiime, sur l'IA, effectivement, on est en plein dans la phase de prospection, d'études, et on regarde attentivement tout ce que peuvent apporter les outils de sécurité applicative sur le scan des moteurs et le scan des intégrations, en tout cas le contrôle des intégrations qu'ont fait des modèles d'IA.

21:54 Effectivement, il y a plusieurs. On voit qu'il y a un paradigme qui est en train de changer sur la partie IA. Il y a deux pans. En tout cas, côté SNIC, on va avoir de l'IA dans les scans qui vont permettre de corriger les vulnérabilités. Mais je suppose que beaucoup maintenant utilisent de l'agentique AI avec du copilot, ce genre de choses, qui vont générer du code. Ce code, parfois, il peut arriver qu'il se trompe quand même, est vulnérable. Il va falloir adresser également ce problème. On a sorti récemment SNIC Studio, qui est un serveur MCP qui va pouvoir s'intégrer directement dans les outils de développement pour pouvoir checker ce qui a été généré par GitHub, ce qu'on appelle Secure at Inception chez SNIC. Qui va permettre de tout vérifier ce que va générer une IA générative de code. Et on a aussi une deuxième partie, peut-être chez vous, vous utilisez des LLM qui sont intégrés dans vos applications, ces LLM vont amener d'autres vulnérabilités. On va parler de prompt injection par exemple, c'est complètement différent des outils classiques d'analyse de sécurité.

23:00 On va devoir un peu dialoguer, on va avoir un agent qui va attaquer un autre agent. Je ne vais pas rentrer dans le détail durant ce talk, si vous voulez des infos, on a un stand de toute façon. Mais sachez qu'il y a toute une partie sécurité adressée aussi avec l'utilisation de ces LLM. Sébastien, je te laisse peut-être le mot de la fin. Si tu veux donner quelques takeaways aux personnes qui sont intéressées pour monter un programme de sécurité explicative, je te laisse. Oui, si je peux donner quelques conseils ou retours d'expérience sur... Les choses qui font qu'on peut faciliter l'adoption d'une solution de contrôle de la sécurité des applications, le premier, ce serait de bien identifier le périmètre à couvrir. On en parlait sur les technologies. Connaître les modes d'intégration, savoir la solution qui va être la plus adaptée aux équipes qui auront l'usage du produit.

24:10 Les équipes cyber, évidemment, peut-être un peu plus rodées et à la recherche d'informations plus basées sur des métriques, des indicateurs. Je pense plus aux équipes de développement, et c'est ce qu'on a vu chez nous, d'être en capacité de leur apporter la solution. qui va faciliter leur travail, accélérer leur travail et produire de la qualité. Définir le périmètre, pour moi c'est un enjeu aussi lié à l'adoption. On peut voir des fois des choses qui ne sont pas bien conçues en termes d'audience et de production. Donc là, si on veut mettre les gens en capacité d'agir, il faut leur donner de l'information utile. Et le dernier point, c'est de qualifier les résultats attendus par chaque partie. qu'on peut avoir des avis différents sur la façon d'intégrer, la qualité d'un indicateur, et donc de faire participer toutes les personnes impliquées

25:12 dans l'intérêt de la solution, ça va permettre de gagner en qualité sur l'évaluation. C'est d'ailleurs le premier des vecteurs de succès, d'assurer le fait que l'ensemble des personnes qui auront la capacité d'utiliser l'outil ont la conviction que c'est le bon. Tester l'outil et partager l'information, c'est plutôt durant la phase d'évaluation. Nous, on a vu des sensibilités différentes, ça crée de la conversation, du challenge, et au final, on s'aperçoit qu'on peut être passé à côté de quelque chose. Donc toujours le collectif qui est important dans ce type d'usage d'outils. L'enjeu de former les équipes sur l'outil et sur l'intérêt de l'outil. Pourquoi on met en place cet outil? Pourquoi pour nous la cybersécurité c'est important? Et le dernier point c'est un peu de maintenir la dynamique. Moi, ce que je trouve utile, c'est de mettre en place des revues, des échanges pour aller assurer qu'on a un bon usage de l'outil.

26:19 C'est comme ça qu'on identifie aussi des perspectives d'évolution sans vouloir faire du contrôle. On peut aussi identifier... Des intérêts d'évolution parce que les techs sont très demandés. sur les nouveaux usages. Juste, zéro. Merveilleux, mais c'est merveilleux, pile poil sur le gong. Bravo. Bravo Grégory et Sébastien, merci beaucoup à tous les deux. On rentre dans la phase de Q&A, si vous êtes d'accord tous les deux. Est-ce qu'il y a des questions dans la salle? Levez la main et surtout levez-vous, histoire que les micros puissent arriver jusqu'à vous. Ah, une question sur la gauche, en l'occurrence votre droite. Et votre prénom, s'il vous plaît? Aurore, si tu veux. Oui, Aurore, bien sûr, Aurore. Coucou, Aurore. Hello. Moi, j'ai une petite question sur la partie, justement, implication des équipes. Déjà, merci beaucoup pour le talk, je recommence.

27:21 Sur la partie implication des équipes, est-ce qu'il y a eu besoin de faire passer ça dans des objectifs un peu plus terre-à-terre, des tribus, voire même des développeurs? Toute la première partie qu'on construit, je l'ai bien, jusqu'au moment où ce n'est plus la prio, la correction. Et donc voilà, comment vous avez adressé ça? Merci. Oui, donc effectivement, construction, adoption et stabilisation. On n'a pas de gate, on peut avoir des gates. Nous, c'est plus une approche par les risques. Et donc, c'est ces revues, c'est cette mécanique de... de dynamique dans l'usage et la revue qui font que selon l'indicateur et selon l'état du sprint du produit, on va aller escalader un risque, prioriser une remédiation et potentiellement bloquer une mise en prod. Ça ne m'est jamais arrivé.

28:23 Et encore que je dis ça, mais ça peut arriver. Et voilà, c'est des enjeux effectivement qui sont extrêmes. Après, ça c'est des approches, on va dire, plutôt passantes sur le flot. On a aussi des approches bloquantes. Et donc là, c'est assez trivial. Ces rouges, ça ne passe pas et puis on corrige. Merci beaucoup. Une autre question, j'avais vu une autre main se lever, ou peut-être en haut. Est-ce que c'est OK pour tout le monde? Pas de frustration? Pas de burning question, comme on dit? OK, super. Merci infiniment à tous les deux. Merci. Je voudrais qu'on vous applaudisse quand même, parce que je ne l'ai pas suffisamment dit. Honnêtement, vous voir comme ça, c'est super impressionnant, même si vous êtes un peu dans le noir. Donc moi, je tiens vraiment à féliciter tous nos speakers depuis le début, parce que vraiment, c'est une performance. Merci à tous les deux. Et j'aime beaucoup vos baskets.