La donnée, grande oubliée du multicloud

Bruno:
Changer d'infra, c'est facile a priori, il suffit de reconstruire le code ailleurs, de cliquer sur quelques boutons et hop, tout fonctionne. Enfin, tant qu'on ne parle pas des données, parce que la donnée elle, elle n'est jamais aussi docile que le code d'un cloud à l'autre. Elle traîne les pieds, elle résiste un peu au voyage et à l'époque on avait même des DBA qui pouvaient se pencher sur les sauvegardes. Mais aujourd'hui, tout le monde s'enorgueillit de faire du clone native, mais qui pense vraiment à construire sa sauvegarde et à restaurer ses données partout, et soit vraiment partout. Mais alors, pourquoi la donnée est-elle toujours la grande oubliée du multicloud ? Peut-on rendre une base de données 100% agnostique, snapshotable et portable où qu'on veuille ? Et surtout, la restauration universelle, est-ce un doux rêve ou un cauchemar kafkaïen version DevOps ? Pour répondre à ces questions de portabilité mondiale, je ne reçois pas Dora, l'exploratrice, mais il s'y connaît en migration sans sac à dos. Christophe, bonjour.

Christophe:
Bonjour.

Bruno:
Alors Christophe, est-ce que tu pourrais te présenter pour les quelques personnes qui ne te connaîtraient peut-être pas ?

Christophe:
D'accord. Je suis directeur des ventes Europe du Sud au sein du groupe Vim, et plus précisément pour notre offre de sauvegarde Casten. Maintenant, ça va faire à peu près 25 ans que je travaille dans l'IT. J'ai commencé traditionnellement chez Digital, pour ceux qui ont connu. J'ai suivi chez Sun, j'ai fait de l'OMC... J'ai fait de la cybersécurité avec Zscaler, j'ai fait du datadoc pour le monitoring. Donc j'ai une culture assez large, en fait, de vision assez large des différentes technologies. Et durant ces 25 ans, effectivement, j'ai pu suivre l'évolution technologique.

Bruno:
Alors justement, sur cette notion de sauvegarde de données, qu'est-ce qui a changé par rapport à ce qu'on faisait avant ? C'est-à-dire qu'est-ce qu'on est juste sur un... Comme on faisait avant, on se fait un backup d'une base de données et puis après on peut le recoller ailleurs et tout fonctionne bien. ou est-ce que nos environnements ont changé drastiquement ?

Christophe:
Alors, effectivement, l'IT est venu par des briques technologiques et à la base, on avait l'habitude de sauvegarder de l'infrastructure. Là, tu le parles, sauvegarder ma base de données, sauvegarder mon réseau, sauvegarder... On parle de différents, mais c'est encore siloté. Et c'est là où tout est disruptif, c'est-à-dire que tous les éditeurs ont élaboré leurs produits sur des environnements physiques et statiques. D'accord ? C'est pour ça que quand déjà le premier mouvement qu'il y a eu, c'est au moment de l'avènement des VM, de la virtualisation, où là, ah, c'est des événements virtuels. Donc il y a eu un changement sur la façon de sauvegarder. Et c'est là où il y a eu l'avènement de Veeam dans les années 2000, avec l'avènement de VMware d'ailleurs, en partie. Et ensuite, là, Patak S, et maintenant, il y a Kubernetes. Et là, on ne parle plus d'environnement virtuel, on parle d'environnement éphémère. Donc, ça remet tout en cause. Ça remet en cause le stockage, parce qu'il faut provisionner en live, etc. Il faut avoir quelque chose qui puisse bouger automatiquement. Donc, ça impose de ce fait de changer l'approche. Et là où avant, on va occuper une infrastructure, maintenant, on va occuper une application. Et là, on arrive sur le fameux why, en fait. C'est-à-dire, on arrive vraiment au bout. C'est-à-dire l'IT, le cloud native sur ce sur quoi je pose mon infrastructure, mon application. Je m'en moque. Moi, ce que je veux, c'est que ça me délivre. Et c'est là où ça devient intéressant. Et aujourd'hui, c'est pour ça qu'il y a des nouveaux acteurs qui sont arrivés, comme Casten, où on a décidé, on a pris le parti pris de nos fondateurs, de dire, il faut qu'on change complètement. Aujourd'hui, je ne vais plus back-upper mon infrastructure. Donc, je ne vais pas back-upper mon OpenShift. Je ne vais pas back-upper mon SUS. Je vais back-upper le namespace, l'application tant que telle, et pouvoir la restaurer.

Bruno:
Oui, parce qu'en fait, le changement que tu évoques, c'est qu'avant, on faisait de la sauvegarde pour pouvoir restaurer le système si un jour on a un crash. Là où aujourd'hui, il faut qu'on ait notre donnée et tout notre service qui soit réplicable en temps réel en fonction des différents pods qui vont se lancer, et qui peuvent se réduire aussi si besoin à différents moments.

Christophe:
Oui. En fait, pour être plus précis, c'est qu'on sait restaurer les blocs aujourd'hui. J'ai ma base de données, je la restaure super. Est-ce que mon service est toujours d'Appen Raling ? Non. Et c'est là où maintenant, aujourd'hui, en fait, il faut s'assurer que on restaure tous les blocs en même temps pour pouvoir restituer le service. Donc, je dirais que nous, chez Castan, le parti prix qu'on a, c'est de dire, je vais restaurer le service. Je ne vais pas restaurer que la donnée, je vais restaurer le service. Mais pour restaurer le service, il faut que je restaure la donnée. Donc, en fait, c'est la façon, on arrive toujours au même point, en fait. C'est le comment j'y arrive, en fait, et le plus rapidement possible. Et c'est là où ça devient intéressant et c'est pour ça que l'approche est différente.

Bruno:
Et du coup, c'est une restauration qui n'est pas uniquement en cas de crash. Quand on a évoqué le multicloud, c'est que parfois la restauration, c'est juste que tu veux déménager ou c'est juste que tu as une partie de ton service qui part ailleurs. Ce n'est pas que parce qu'il y a eu un crash.

Christophe:
Voilà. J'ai un exemple concret où il y a un client qui a vraiment pris la philosophie du cloud. Je ne vais pas citer le nom du client. C'est en Europe du Sud. Mais en fait, ce qu'il a fait, c'est qu'aujourd'hui, il s'est aperçu que mettre des features de type on-surprise dans le cloud, ça coûte plus cher que de l'avoir on-premise. Sauf que le problème de tout mettre on-premise, il faut que je construise une architecture qui soit sur la target, au maximum de consommation. Donc lui, il travaille dans le retail, donc on sait qu'au moment du Black Friday, il y a une consommation énorme. En fait, lui, ce qu'il fait avec Casten, c'est qu'il met sa production on-premise avec des fixtures de type Enterprise. Donc, il a tout. Ça ne lui rend pas cher. Son DR, il le fait dans Microsoft. Et au moment où il décide de faire le Black Friday, de lancer la campagne, en fait, il bouge l'application en quelques minutes. Il la bouge sur le cloud. Il utilise la scalabilité du cloud de Microsoft. Et au moment où ça retombe à un pic d'activité normale, là, il peut rapatrier son application on-premise. Donc, effectivement, comme tu le dis, aujourd'hui, notre solution, ce n'est pas qu'une solution de sauvegarde, mais aussi, il faut l'utiliser. Et là, c'est une éducation à faire comme un outil de mobilité et vraiment cloud natif. C'est-à-dire, je peux bouger. Là, je le mets dans Microsoft. Pourquoi pas demain dans Google ? Pourquoi pas demain sur un autre site ? Mais effectivement, on peut le citer pour un déménagement, par exemple.

Bruno:
Mais du coup ça amène plusieurs questions parce que ce simple phénomène de déménagement ça paraît simple quand tu le présentes comme ça on se dit que c'est quelques clics, mais forcément ta donnée, même si les cloud providers ils sont grosso modo relativement uniformes sur beaucoup de choses ta donnée elle est pas forcément, on va dire que le format de ta donnée la disponibilité de ta donnée elle est pas forcément compatible avec la destination il y a peut-être un.

Christophe:
Nous on est en mode bloc donc en fait on n'a pas de snapshots etc donc il n'y a pas de souci on est sur un format basique de s3 après effectivement il ya des targets à avoir effectivement après la magie pour redémarrer une application, des fois ça fait pas comme ça des fois il ya des applications ça peut redémarrer mais il faut savoir comment redémarrer l'application, Et c'est là où on va plus loin que de la sauvegarde, c'est-à-dire que nous, on discute avec les développeurs, effectivement, pour dire, attention, ton application, pour la redémarrer, qu'est-ce que je dois démarrer en premier ? Et c'est un peu comme, j'explique des fois, quand je vulgarise ça, c'est comme quand on déménage chez moi, par exemple, j'ai des cartons. OK, je suis arrivé dans ma nouvelle maison, mais est-ce que les cartons sont dans les bonnes pièces ? Quel carton je vais ouvrir en premier ? Parce que si je veux faire la cuisine, avant de sortir les assiettes, il faut peut-être que je sorte des casseroles. Donc il y a la façon de redémarrer l'application et c'est pour ça que je te rejoins sur le fait que ce n'est pas magique et derrière par contre là où nous on va s'intégrer c'est qu'on a vraiment cette philosophie cloud native où on va, utiliser vulgairement ce qu'on appelle des blueprints pour le moment du redémarrage, de dire attention voilà toutes les steps à faire et là il y a besoin d'un travail, de la si on peut dire de la programmation ou des gens qui soient là pour vérifier que l'application va redémarrer Ok.

Bruno:
Alors du coup quelle va être la différence avec un système type cube qui lui aussi a cette capacité en fait à savoir quoi démarrer commande en calandre.

Christophe:
Bonne question très bonne question en fait souvent là on va arriver dans un discours c'était clair cette foule donc souvent en fait ce qui s'est passé c'est comme je dis tout le monde en avait marre d'attendre, d'attendre dans les départements de d'avoir les ouvertures de flux etc maintenant le, le fait que maintenant on gère l'application les gens sont dit super maintenant à git ok c'est génial git git effectivement c'est très bien c'est à dire que ça va gérer un instant et ça va mettre je dirais, je dirais un périmètre de comment bien déployer comment bien structurer l'application, par contre en revanche il va lui manquer des fois certains modules en fait c'est à dire que d'ailleurs pour ça pour le déploiement elle va utiliser argoced et par exemple d'accord maintenant la question se pose c'est quand j'ai des données spécifiques des secrets, des persistants de volume etc ben ça mon guide il n'a pas en fait Et c'est là où il y a un problème souvent, c'est que les gens vont dire, non, non, moi avec mon guide je peux redémarrer l'application. Oui, mais est-ce que tu peux redémarrer l'application avec toutes les données ? Donc c'est un peu comme si je disais pour vraiment vulgariser... Guide va faire la recette, il va dire voilà, pour faire la recette, il faut ça, ça, ça. Par contre, il a oublié de savoir ce qu'il avait dans le frigidaire. Qui va aller acheter les bons éléments dans le frigidaire ? Et c'est ça en fait qui pose problème aujourd'hui. C'est qu'aujourd'hui, il y a des outils, guide est très important, argoseguer est très important, mais la sauvegarde est aussi importante pour avoir justement une visibilité à l'instant T.

Bruno:
Mais quand tu parles de cette notion de redémarrage, ton cube, ton Kubernetes aussi, en fait, lui, il a toute sa procédure. Il sait que pour démarrer un service, démarrer un serveur, il y a tout un ensemble de choses à faire dans un certain ordre de donner des accès à ceci, cela et compagnie. Donc ma question en fait, c'est quoi la différence entre un cube et ce que proposait chez Vim ?

Christophe:
Cube, nous on ne redémarre pas le Kubernetes en fait, puisqu'on est une application à l'intérieur d'une MSPACE. On a un MSPACE à part entière, on a une application à part entière. Donc en fait, on va utiliser les outils des différents fournisseurs donc Red Hat Alcien, SUS Alcien, etc. Donc ils vont redémarrer. Nous, on n'est pas en charge de redémarrer. Nous, on est en charge de redémarrer le namespace. Donc, pour redémarrer une namespace, j'ai besoin que le cube soit actif. C'est pour ça que souvent, effectivement, et c'est une bonne question, des clients nous disent « Ah ok, vous redémarrez le cube. » Non, non, on ne redémarre pas le cube. Ça, il y a des outils pour ça, pour le faire. Ils sont très bien, c'est leurs outils. Donc, Red Hat va avoir le sien, Rancher va avoir le sien, tout le monde va avoir le sien. Ils vont redémarrer. Et une fois que c'est redémarré, on va installer Casten et c'est là que Casten va aller récupérer toutes les dépendances applicatives pour pouvoir redémarrer l'application.

Bruno:
— OK. Mais alors du coup, est-ce que tu peux me donner un exemple d'éléments que vous allez pouvoir apporter qu'un cube de manière native... Enfin, tu vois, si je reprends toute ma CI et que je la déplace de mon on-premise vers mon Azure...

Christophe:
Par exemple, si tu es dans le cadre d'une application stateless, tu vas avoir les PV, tu vas avoir les secrets, tu vas avoir pas mal de choses comme ça, en fait, donc à un moment donné, j'ai oublié le terme, je le retrouverai plus tard, c'est pas grave, mais en fait, il y a des spécificités dans l'application qui ne sont que dans la partie Kubernetes et qui ne sont pas dans le Git. C'est pour ça que c'est important d'avoir cette partie sauvegarde, le git il faut comprendre que le git il est là pour effectivement on dit que c'est la source de vérité oui la source de vérité du code en tant que tel mais pas de la vision est-ce qu'il y a de la donnée, est-ce qu'on a modifié des choses est-ce qu'il y a des choses qui ont été faites, ça s'arrête là en fait et c'est pour ça que c'est complémentaire c'est pas concurrent d'ailleurs, git, argocédé et castane ou les outils de sauvegarde en règle générale je pourrais dire c'est complémentaire.

Bruno:
Et donc le fait d'être comme ça un namespace et d'être au cœur de l'application, ça vous permet en fait d'être complètement agnostique de tout ce qu'il peut y avoir autour, de pouvoir embarquer absolument ?

Christophe:
Tout à fait. C'est-à-dire qu'en fait, on va être à l'intérieur. En fait, ce qui va se passer, c'est qu'on va s'installer. À l'intérieur, on va faire le discovery automatique des applications, des différents namespaces. Et en fonction des namespaces, on va faire l'analyse des connexions de tout ce qu'ils ont, etc. Et on va pouvoir être capable de sauvegarder le namespace et toute son arborescence. Donc en fait, une application, vous allez avoir des config maps à l'intérieur, vous allez avoir des secrets, vous allez avoir potentiellement des PV, etc. Mais nous, on va sauvegarder les blocs, mais aussi l'arborescence. L'image que j'aime faire, c'est qu'à un moment donné, si on continue dans l'ancien monde où on prend le bloc, c'est comme si... Moi, j'ai eu des enfants, le fameux bateau en Lego. On construit, ça tombe par terre. OK, il se brise. OK, donc sans outils comme entre parenthèses Castel, je prends tous les Legos, je les pose sur la table, je dis, ben voilà, c'est... Ah oui, mais mon bateau, il n'est pas reconstruit. Donc, il faut que je reprenne le mode d'emploi. Nous, en fait, ce qu'on va faire, c'est que le bateau va être cassé et on va reconstruire le bateau, d'accord, pour redonner le bateau, déjà construit, en fait, et pas simplement tous les blocs.

Bruno:
Sur la notion de... Quand on parle de sauvegarde, en fait, de manière un peu plus large, surtout aujourd'hui, je pense qu'on parle aussi, en fait, d'une notion de sécurisation de manière un peu plus globale. C'est-à-dire qu'au final, c'est pas que... On l'a déjà un peu évoqué, mais c'est pas que restaurer ton système le jour où il se fait effacer, c'est aussi le protéger d'une certaine typologie d'attaque. Dans quelle mesure est-ce que vous apportez justement aussi cette protection, ou c'est juste de la restauration en cas de problème ?

Christophe:
En fait, nous, ce qu'on va faire, c'est qu'on va s'appuyer sur des notions d'immuabilité, de chiffrement. Par exemple, avant de faire nos sauvegardes, effectivement, on va les dédupliquer, les compresser, etc., les chiffrer. Et on va faire ça à une granulaté assez fine, puisqu'on va la faire en namespace. Pas que sur le cluster, mais sur cette partie-là. Ensuite, on est capable de, effectivement, comme on est 100% API, on va être capable de s'intégrer au système du client. Donc, par exemple, les clés, s'il veut les mettre dans son vault, il les mettra dans son vault. Le stockage, on va faire des muabilités mais si le stockage cible n'a pas la future des muabilités, il n'y en aura pas, nous on ne va pas inventer des muabilités par contre on va être capable de l'activer et c'est ça qui fait qu'aujourd'hui on est capable de s'intégrer dans la majorité des systèmes de type cloud native parce qu'on est 100% API donc on va activer toutes ces notions de base.

Bruno:
Mais donc du coup il y a aussi cette notion de chiffrement apporte forcément, une couche de sécurité si jamais il y a une exfiltration de choses qui est faite, mais est-ce que du coup il y a aussi une, Une vérification, je ne sais pas, d'accès, des informations ?

Christophe:
Il y a la notion d'airbac aussi, effectivement. Donc on a un airbac assez fin là-dessus, parce qu'effectivement, on va pouvoir délimiter qui a le droit d'accéder à l'application. Donc on va avoir une granularité, non pas qu'au niveau du cluster, mais au niveau du même space. Dire par exemple, toi, tu es développeur de l'application A, tu as accès à l'application A, mais comme tu es développeur, tu n'as accès qu'à la pré-prod et pas à la prod. Ou tu as le droit, OK, de bouger ton application, mais pas sur la prod, ou inversement. Donc on va pouvoir effectivement donner une granularité de droits qui permettent de, je dirais, de contrôler qui a accès à l'information et quand. Par contre, après, d'aller diagnostiquer à l'intérieur, c'est ce que je dis souvent à un client, s'il y a eu une attaque sur l'application, nous, si l'application a été chiffrée, on va la sauvegarder, mais chiffrée. C'est pas notre job. Je travaillais dans l'informatique et dans la cybersécurité avant. Il y a à peu près, à l'époque, on disait 4000 fournisseurs de sécurité. Donc dire que BIM va remplacer 4000 personnes de la sécurité, c'est pas possible. Par contre, ce qu'on dit, c'est qu'on va s'intégrer. Avec ces outils-là et qu'on peut s'intégrer pour compléter l'offre et avoir une couverture globale et complète.

Bruno:
Et du coup, restaurer aussi toute cette couverture si jamais il y a besoin, au moment de la réplication.

Christophe:
Tout à fait. On est capable de dire qu'elle, à un moment donné, si l'outil dit « Ok, l'attaque a eu lieu hier à telle heure », on est capable après de dire « Ok, on va faire la restauration, la dernière restauration qui n'a pas été impactée, c'est celle-là, donc on va pouvoir restaurer ce système-là.

Bruno:
» Oui, je vois. Quand on a préparé l'épisode, il y a un élément qui m'a étonné. Sur ce que vous proposez chez Vim, c'est cette... Je ne sais pas si le terme protection est juste, mais c'est cette gestion du data drift. C'est quelque chose qui peut arriver de manière assez courante dans un contexte. Ce que j'ai compris quand on discutait en préparation, c'est que vous avez un ensemble d'outils qui permettent de vérifier, de voir dans quelle mesure est-ce qu'on peut avoir de la donnée qui, petit à petit, commence un peu à trop changer de format, ou à diverger ou à changer. J'ai mal compris un truc.

Christophe:
Non, ce n'était pas ça, parce que ça, nous, on ne va pas le faire. Nous, ce qu'on va faire, c'est qu'on va sauvegarder la donnée. Après, il y a des outils qui sont là pour le donner. Je pense que c'est quand on parlait de l'IA, où à un moment donné, un système détecte qu'il y a eu un drift, en fait, sur la donnée, et il faut revenir à un instant T. L'outil va le détecter, Castelan va être capable de dire ok donc je vais restaurer cette donnée et d'assurer que la donnée que je restaure elle est bien immuable, elle n'a pas été corrompue donc on revient à une unité basique après derrière pour des, quand on va commencer à faire de la dérive notamment de prompt etc parce que le code n'a pas été bien fait là il va y avoir des acteurs comme Red Hat qui ont leurs propres outils qui vont permettre de voir cette dérive nous en fait on va, chez Vim on va assurer qu'un seul drift c'est le drift de la donnée et de dire de pouvoir restaurer, Et quoi restaurer, en fait ? C'est surtout ça l'important, c'est à quel moment je dois restaurer et où je dois restaurer, en fait.

Bruno:
Et est-ce que sur le... Quand justement tu réalises qu'il faut restaurer ta donnée plus ou moins loin dans le temps, est-ce que du coup, de manière automatique, on peut aussi se dire, voir que si je restaure mon snapshot de data d'il y a 48 heures, par exemple, en fait, c'est une version de l'application différente qu'il faut pouvoir restaurer avant, parce que il y a... C'est peut-être un cas rare, mais tu peux avoir des changements dans ton code, ou dans ton format de données. Tu vois ce que je veux dire ?

Christophe:
Oui, c'est-à-dire qu'à un moment donné, nous, on va restaurer un instant T et on va restaurer. Par contre, on peut restaurer sur n'importe quelle version. Je m'explique. Aujourd'hui, le namespace va être restauré à l'instant T et comment il était à l'instant T. Après, ça recommuniquera avec le guide s'il faut le remettre à jour ou pas. Ça, c'est un autre débat. Par contre, en revanche, si ton cluster cube a changé et qu'il est passé de la version 4 à la version 4.18, on sera restauré sur le 4.18. Parce qu'on est agnostique à l'infrastructure donc pour répondre à ta question, si la couche infrastructures a changé c'est pas un problème si le stockage a changé c'est pas un problème on sera restauré etc, par contre le namespace en tant que tel on va restaurer à l'instant t et après c'est le guide qui fera son job pour dire ok c'est quoi ma source de vérité ma source de confiance.

Bruno:
Mais donc, cette capacité de rollback, elle se fait dans un délai, c'est proportionnel à la tête de la base de données quand même, j'imagine ?

Christophe:
Après, il y a la base de données qui va se restaurer de son côté.

Bruno:
Etc.

Christophe:
Après, restaurer le service, ça peut être plus ou moins rapide. Ça peut être plus ou moins long aussi en fonction de si l'application est complexe, s'il y a beaucoup de paramétrage, ça dépend. C'est difficile à dire. On sait restaurer rapidement. En fait, ce qui fait qu'on va restaurer rapidement, encore une fois, c'est qu'on a la cartographie globale de l'application. Donc, on sait ce qui a restauré, comment et pourquoi. Donc, on va avoir en général un RTO assez, rapide. Le plus optimisé possible. Il y a des applications. Là, on a vu, il y a eu un crash où le client, avec son GitOps, s'il mettait 8h pour redémarrer, avec Astin il ne remettait que 2h, Voilà. Alors, pourquoi lui spécifiquement ? Je ne sais pas. Mais là, c'était possible. Dans d'autres cas, ça peut être peut-être plus long. Ça dépend vraiment comment a été configurée l'application, comment elle est, etc. Donc, dans des cas, on va être beaucoup plus rapide. Dans des cas, pareil.

Bruno:
De toute façon, j'imagine que c'est avec le... Ce n'est pas forcément quelque chose que tu peux anticiper. C'est-à-dire que je pense que c'est en mesure d'estimer le temps de...

Christophe:
Oui, c'est-à-dire que nous, ce qu'on va faire, c'est que l'avantage, c'est qu'Astene s'installe rapidement. Je dirais, même pas 10 minutes si tous les flux sont ouverts on sait faire la première la première comment s'appelle la première restauration donc ça c'est assez rapide pourquoi encore une fois c'est parce qu'on est intégré dans qu'il est un test mais tu verras les tests natifs donc c'est ça c'est l'avantage de la solution, mais après dire comment on va dire ok on va faire un test on va regarder on va faire et après on va optimiser la restauration en rajoutant ce qu'on appelle nous des blueprints qui vont être une sorte de ligne de les lignes de commandes pour dire bah attends quand tu redémarres ton application faut d'abord faire ça ça ça ça il ya un ordre à respecter, et ça ça va nous permettent encore plus d'optimiser, mais tout en travaillant, je dirais, conjointement avec les outils cloronatifs, avec, le Git, avec l'Argos et Guédé, etc.

Bruno:
Qu'est-ce qu'il y a... Parce que du coup, Castel, ce n'est pas quelque chose que vous faites depuis le début de l'histoire de Vim.

Christophe:
Oui.

Bruno:
Qu'est-ce qui a généré, en fait, tu vois, comment vous en êtes arrivé à faire ça sous forme de cette solution complète ?

Christophe:
C'est pour une solution complète.

Bruno:
C'est-à-dire ? De Castel, en fait. C'était quoi le cheminement ou le déclencheur marché ou technique ?

Christophe:
Donc Veeam ait racheté Castel ?

Bruno:
Ah, je pensais que Castel, ça avait été créé par...

Christophe:
Ah non, justement. En fait, Veeam est arrivé, en fait, pour faire un petit peu la genèse. Veeam et Castel, c'est un peu la même histoire. C'est-à-dire que Veeam a été créé au moment où il y a l'avènement de VMware. C'est pour ça que c'était très lié à VMware et c'est pour ça que Veeam a été le leader et est toujours le leader sur la partie protection de VM. Parce qu'ils avaient vu qu'à ce moment-là, la virtualisation demandait de changer l'approche. Là où on sauvegardait les environnements physiques, là on doit sauvegarder les environnements virtuels. Donc du coup, c'est comme ça que Vim a été créé. Ensuite, ils ont étoffé leur portfolio. Et ensuite est arrivé Kubernetes. Et Patakès, ça change. Maintenant, on ne parle plus d'environnement virtuel, on parle d'environnement éphémère. D'accord ? Et c'est là où, par exemple, Portworx est arrivé aussi et que Pure Storage a décidé de racheter Portworx. Tout ça parce que la philosophie, l'approche de provisionner du stockage ou la façon de sauvegarder a changé. Et donc, c'est là que Vim s'est dit, attends, est-ce que j'adapte mon système, Vim qui a été fait pour faire de la sauvegarde d'environnement virtuel ? Est-ce que j'essaye de bidouiller et de faire un patchwork ? Ou est-ce que je prends une solution from scratch ? Et là, ça tombait bien. Il y avait Casten qui avait été créé, parce que Casten a été créé en 2017. Le Cube s'est sorti en 2014 ou 2015 de mémoire par par google donc tout de suite ça a été vu en amont donc en fait on est société jeune castane en fait vieux dans le monde kubernetes ce qu'on est de pratiquement depuis le début et donc c'est là que les, le management de vim a décidé ok ben non on va pas faire la même bêtise nous on apprenait qu'il fallait une nouvelle solution pour approcher comme vim vmware et donc ils ont décidé de racheter castane qui était vraiment adapté et 100% adapté. Aujourd'hui castane fait que de la sauvegarde kubernetes.

Bruno:
Tu évoquais aussi tout à l'heure que, Dans cette mise en place du système, il y a beaucoup d'échanges avec l'ensemble des développeurs, pour notamment comment sont faits les différents accès aux différents services de l'application divers et variés. Mais est-ce que ça veut dire aussi que dans le quotidien du métier de développeur, le fait d'avoir Vim dans son écosystème change aussi certaines manières de produire du code, de produire du projet ? Est-ce que ça impose un ensemble de restrictions ou de règles ? Ou au final, c'est juste un sujet de DevOps ? Et du coup, c'est complètement transparent pour eux ?

Christophe:
C'est complètement transparent pour eux. Parce que nous, on a été faits dans Cube pour Cube. Donc on a la même philosophie. Et c'est d'ailleurs pour ça que les clients nous apprécient. Et surtout les DevOps, quand on discute avec eux, c'est ceux qu'on veut rencontrer plutôt qu'en premier. Parce qu'ils comprennent la philosophie et ils ne sont pas intéressés par la sauvegarde. mais sont aussi, comme tu le dis, intéressés par tout ce qui est mobilité et autres, pour pouvoir, je dirais, débugger, etc. Donc, je dirais qu'à ce niveau-là, on n'est vraiment pas en conflit. Au contraire, on est en phase avec eux, en fait, sur cette partie-là. Après, le fait, je dirais, la question, c'est plus le fait de mettre du Kubernetes en place. D'accord ? Ça change les approches que doivent avoir les gens de l'archi. Et souvent, c'est là où on va avoir des fois des problèmes, où les gens du stockage vont dire, non, non, non, moi, je reste sur cette techno. Par exemple, aujourd'hui, quand on parle de VM, souvent, ce qui est poussé en général, c'est de faire du file system derrière. Sauf que nous, on préfère le bloc. Dans le monde Kubernetes, on préfère le bloc parce que c'est déjà beaucoup plus rapide à restaurer. Donc, de dire maintenant, OK, tout ce que tu as fait et tous les procédures que tu as écrites pour tes VM, que tu vas migrer maintenant sur la VM, maintenant sur du cube vert, par exemple, ben non, non, non, maintenant, ton stockage, il faut que tout tu réécrives, il faut que tu mettes du bloc. Donc ça demande des changements et on va arriver sur une guerre de silos avec des gens où ils voient l'intérêt qu'Ubernet est pour eux, il y en a d'autres ça va leur apporter des contraintes, Dans un premier temps, et pourtant ça tourne aujourd'hui, pourquoi les gens. Décident de changer de VMware, c'est parce que ça ne marche pas, c'est pour des raisons financières. Et donc ça n'a aucune valeur en tant que telle, je dirais, d'un point de vue technique à la base. Donc c'est pour ça que la question est assez difficile. C'est nous, en tout cas, on va être beaucoup plus enclin à avoir la même philosophie que les gens du cloud natif, pour résumer ça, que les gens traditionnels ou de l'IT traditionnel. Mais comme je le dis, les mainframes, depuis 2000, on m'a dit qu'ils étaient morts, il y en a toujours. Donc DVM, il y en aura toujours. Il va falloir apprendre à vivre ensemble, en fait, simplement.

Bruno:
C'est tout. — Donc en fait, dans une équipe qui est déjà suffisamment mature sur Cube, ça va rien changer à personne. En revanche, s'il faut pouvoir... Si c'est des gens qui sont encore sur des systèmes peut-être un peu plus, on va dire simplistes ou monos-thread ou ce genre de choses, ça va nécessiter quelques changements, de toute façon, parce que le passage sur Cube va leur demander de changer.

Christophe:
Typiquement, oui. Un exemple concret, c'est qu'aujourd'hui, pour pouvoir utiliser Casten, il faut savoir utiliser Kubernetes. Donc souvent, nous, ce qu'on va avoir, c'est que souvent, quand les clients nous appellent, ils me disent « Ah, Christophe, il y a un bug sur Casten ». Et en fait, souvent, ce n'est pas un bug sur Casten, c'est un problème de compréhension de comment fonctionne Kubernetes. Donc souvent, on va avoir discuté avec les personnes qui sont en charge de maintenir Kubernetes, parce que les gens de la sauvegarde n'ont pas le droit de toucher, à la partie infrastructure Kubernetes. Et c'est là où des fois il va y avoir des discussions et là où on va devoir des fois effectivement dire attendez ça serait bien de mettre tout le monde autour de la table les gars en charge du cube les développeurs et la sauvegarde là où avant tout le monde pouvait travailler dans son, dans son coin parce que c'était siloté mais maintenant c'est plus siloté et donc je dirais aujourd'hui le challenge c'est que, pour moi pour les DSI aujourd'hui le challenge ça va être de dé-siloter tout ça c'est à dire ça impousse de revoir toutes les organisations au niveau RH.

Bruno:
Alors du coup, ça veut dire que là, on parle beaucoup de Cube, mais il n'y a pas que Cube dans le paysage. Mais est-ce que ça veut dire que quand justement je vais déménager le cloud et que je m'en trouve dans un nouveau écosystème où je n'ai pas forcément accès à Cube, en fait, avec l'aide de Vim, je peux du coup reproduire mon écosystème et toute mon infra de manière un peu plus simple ou comme de toute façon, vous, vous êtes hébergé dedans. C'est-à-dire que j'ai toujours le même travail de migration à faire entre...

Christophe:
Il y a un travail sur la... Si l'application était sur Cube, d'accord, et qu'elle tourne, qu'elle était native, qu'elle était native, il n'y a pas de soucis, on peut leur démarrer n'importe où. Ça, il n'y aura pas de soucis. Par contre, s'il y a des applications qu'il faut passer de la VM et mettre sur du container, là, il y a un travail de replatformisation. Il va y avoir des outils qui vont simplifier ça, mais ça ne se fait pas comme ça, ce n'est pas aussi magique. Donc, il y a un travail. C'est pour ça qu'aujourd'hui, d'ailleurs, le dilemme et est-ce que je dois réécrire mes applications ou pas ? La question, c'est que s'il n'y a pas vraiment d'ajout à faire, etc., bah... Quelle est la nécessité de la replateformer ? Ça ne sert à rien. Par contre, en revanche, si je dois rajouter sans cesse des nouveaux services, là, oui. Là, le bénéfice du cloud native, c'est justement d'éviter d'attendre que ma prochaine version sortira dans deux mois. Et donc, c'est la capacité de pouvoir rajouter. Donc, c'est assez difficile de répondre à cette question parce qu'en fait, aujourd'hui, vous voyez un DSI, vous lui demandez de refaire son datacenter, il ne le fera pas comme il est aujourd'hui. Mais sauf qu'aujourd'hui c'est une façon d'argent mais en fait on le sait pertinemment sauf qu'il est obligé de, ce que j'appelle toujours le boulet il a un boulet, ce qu'on appelle le passif il est obligé de jouer avec, donc il va avoir des infrastructures qui vont tourner, sur tel et tel techno il va avoir des nouvelles techno, il va falloir toujours qu'il joue, qu'il bouge entre ces différents mondes c'est ça qui n'est pas facile.

Bruno:
Comme du coup vous êtes dans cet écosystème de ces grands orchestrateurs type Cube et autres. Est-ce que ça veut dire que c'est quand même une solution qui est réservée à une certaine catégorie d'acteurs ? On peut avoir parfois l'image que Cube, qui est quand même un outil complexe, on ne va pas se mentir, qui permet de faire des choses formidables, mais qui ne sont pas nécessaires pour tant de gens que ça, au final.

Christophe:
Ça dépend de l'application, ça dépend de ce qu'ils veulent faire avec l'application.

Bruno:
Parce que tu vois, on a parfois l'impression que Cube, c'est un truc qui est réservé à une certaine taille d'entreprise. C'est-à-dire que du coup, ce n'est pas n'importe quel site e-commerce qui va y avoir accès, ce n'est pas n'importe de quelle...

Christophe:
C'est une bonne question et c'est pour ça qu'aujourd'hui, on voit une montée en puissance de ce qu'on appelle, nous, au fur et à mesure, les VCSP chez Vim, c'est-à-dire on a des partenaires qui fournissent du Kubernetes à ce service. Parce qu'effectivement, t'as raison, ça demande d'avoir une population précise. Nous, on travaille avec un gros client bancaire, je ne sais pas le nom, où la personne qui était en charge de la sauvegarde a dû comprendre et savoir se cultiver autour de Kubernetes qui n'est pas si simple. Donc, c'est une technologie difficile à appréhender. Elle va permettre d'accélérer et de simplifier la mise en production des services, mais par contre, effectivement, c'est pas fait. Comme je l'ai dit à Indéacis, Kubernetes n'est pas venu pour te simplifier la vie. Ça va simplifier la vie du business. Mais par contre, toi, ça va te la complexifier. Parce qu'il va falloir effectivement la mise en œuvre. Il y a des process différents à mettre en place. Par contre, à terme, le héros, il va être là et ça va vraiment lui simplifier sa vie.

Bruno:
Je ne sais pas si je suis en phase avec cette... Je suis d'accord que ça facilite la vie du business parce qu'effectivement, ça te permet de gagner en vélocité, de t'adapter à tout un tas de sujets. Tu peux plus facilement optimiser ta facture parce que du coup tu peux gérer des pics de charge il y a des tas d'exemples qu'on peut donner mais c'est ce qu'on évoquait un peu en off quand les micros étaient coupés, certes Cube est compliqué mais je trouve que ça te permet quand même de faire extrêmement simplement, des choses qui étaient d'un niveau de complexité totale avant que ça existe. C'est-à-dire qu'avant Cube, si tu voulais faire la même chose que ce que Cube te permet de faire aujourd'hui, il te fallait une équipe de 60 personnes, full-time, dédiée à ça, juste au run, pour ça, alors qu'aujourd'hui, au final, avec peut-être une personne et demie, et un truc bien configuré, ça te permet de faire des choses.

Christophe:
Une chose bien configurée, c'est toujours la mise en place. En fait, le maintien en condition opérationnelle, 200% d'un une fois que ça tourne aux petits oignons alors là, c'est c'est il n'y a pas besoin d'avoir dix mille personnes je suis tout à fait d'accord avec toi, là on est dans une phase où on est au creux de la vague en fait où c'est un moment donné où on doit changer car les gens qui vont accepter de changer il y en a qui sont proches de leur retraite qui vont pas vouloir changer qu'ils disent moi je continue à tourner comme ça parce que je maîtrise ça il y en a d'autres qui vont vouloir et cetera changer et se dire ok c'est l'avenir parce que comme tu dis à la base c'est fait pour simplifier la vie, et à la base on en revient à est ce que c'est le but du jeu c'est de générer des lignes de code, ou est-ce que c'est vraiment de générer une valeur business on est toujours on pourra tourner le problème dans tous les sens c'est qu'une question business et qu'est ce que ça va me rapporter et aujourd'hui voilà avant moi je me rappelle les développeurs monnaient regarde je t'ai fait une application j'ai 2000 lignes de code, maintenant on entend plus parler ça c'est au contraire c'est à dire comment tu vas faire une application et en évitant de développer 2000 lignes de code et c'est là où ça devient intéressant et c'est là où je te rejoins c'est que à la base google pourquoi ils ont créé ça c'est tout simplement pour pouvoir délivrer beaucoup plus rapidement, encaisser les pics de charge. Mais après, il y a eu plein de choses qui sont arrivées où on a vu, ah ouais, c'est intéressant pour ça, c'est intéressant pour ça. Donc, la valeur va être là, il va y avoir des avantages, ça c'est clair. Aujourd'hui, mais par contre, la VM a encore de l'avenir, parce qu'à un moment donné, pour des notions de sécurisation et vraiment silotées, il n'y a pas mieux qu'une VM aujourd'hui.

Bruno:
Ouais, clairement.

Christophe:
Voilà.

Bruno:
Tu as évoqué, effectivement, un changement de métier, où tu disais qu'on ne fait plus de lignes de code, enfin, on compte plus de lignes de code, on s'intéresse à d'autres sujets ce qui a toujours été un peu vrai mais c'est encore plus vrai aujourd'hui, mais du coup dans le contexte justement de ce que vous apportez, Est-ce que cette nouvelle tendance où on pond 100 000 lignes de code par jour, on met 22 fois en prod par jour, est-ce que vous apportez cette culture justement de snapshot, de capacité de revenir en arrière si jamais on fait des erreurs ? Tu vois, j'ai envie de dire, peut-être qu'on est dans un monde où on fait beaucoup plus facilement des erreurs, parce qu'en fait, on peut en faire beaucoup plus par jour, et donc il faut pouvoir peut-être restaurer tout le temps. Est-ce que vous voyez aussi une tendance, un impact de ces nouvelles pratiques, de déploiement et de création de services dans la manière dont le service aujourd'hui est utilisé ?

Christophe:
En fait, effectivement, plus c'est industrialisé, plus c'est automatisé, plus ça va te permettre de faire des erreurs, éventuellement d'avoir une tolérance à l'erreur, on va dire, parce qu'on va pouvoir revenir. Avant, ce n'était pas le cas. Dès qu'on envoyait quelque chose en prod et que ça partait en vrille, là, c'était la cata. Aujourd'hui en fait on peut revenir rapidement en fait et c'est je pense que là pour répondre à ta question. Ça va tolérer plus les erreurs parce qu'on va être capable de faire le retour arrière et c'est des outils comme castan etc, mais aussi du guide etc qui va permettre de revenir en arrière et pouvoir tester en fait c'est un peu l'approche d'élan musk en d'ailleurs et le musk avec ses fusées qu'est ce qu'il fait en fait il a dit on a progressé plus vite parce qu'on toléra les erreurs c'est à dire j'acceptais que les fusées explosent par contre on apprenait beaucoup voilà ça va être un peu la même chose effectivement dans le monde dans mon cube où tu as tout à faire raison. Dans le sens où je vais pouvoir lancer des trucs, ça marche, ça marche pas, je reviens en arrière. Il n'y a plus cette notion de comment je fais mon retour arrière, en fait. Une première discussion que j'avais eue longtemps avec un CIEXO, c'était qu'on parlait de l'outsourcing. Il me dit, Christophe, moi, ce que je négocie avec toi, c'est pas mon ticket d'entrée, parce que ça, vous savez être super compétitif, les Américains, là-dessus. C'est mon ticket de sortie. C'est comment je reviens en arrière. Et là, t'arrêtes dans cette notion-là, où justement, grâce à des outils bien étoffés, et si on a bien tous les building blocks nécessaires, comme le guide l'argo cd et le cas stène pour la donnée parce que le guide c'est je vais dire le guide ça permet de reconstruire squelette mais que le squelette, après il ya toute la donnée et là si vous avez l'intégralité là ça va vous permettre de pouvoir redémarrer moi je suis capable de redémarrer et d'être audité pour dire que, Qu'est-ce que j'ai redémarré ? Quand et à telle date ? C'est ça aussi qui est important, c'est d'avoir cette traçabilité. Et c'est pour ça qu'on a racheté aussi, nous, un Security AI, en fait, au niveau de VIM, justement, pour cette partie-là. Parce qu'aujourd'hui, ce qui est important, c'est de contrôler la notion de la donnée aussi en tant que telle et de pouvoir être capable d'argumenter et d'auditer le fait que j'ai bien restauré la bonne donnée.

Bruno:
Est-ce que ça veut dire aussi que parce que je me dis si tu fais autant de déploiements il y a quand même un intérêt à te dire ok j'ai peut-être essayé de faire un snapshot avant chaque déploiement comme ça si jamais mon déploiement plante je reviens avant, mais si j'ai 800 Tera de données à faire un snapshot et que j'ai fait 22 par jour il y a un moment peut-être que Castel va commencer un peu à tout sauter un peu.

Christophe:
C'est après, effectivement, en fonction de la bonne passante. Il y a toujours de la bonne passante, etc. Mais oui, c'est une règle que font nos clients aujourd'hui. C'est qu'ils s'assurent. Donc nous, on a une grande priorité des backups toutes les 5 minutes. D'accord ? Donc on va pouvoir effectivement backuper et s'assurer qu'on a une visibilité de l'application à un instant T et d'être capable de revenir en arrière au bon instant si jamais on a lancé quelque chose et qu'on doit faire un retour arrière. On sait le faire sur les containers mais aussi intéressant par exemple des clients aujourd'hui qui sont en train de voir pour se désengager de VMware pour la notion, purement financière parce que c'est pas une notion technique aujourd'hui on est capable nous d'assurer le rollback arrière c'est à dire les clients aujourd'hui il y en a qui me disent j'aimerais bien tester, du SUS virtualization du OpenShift virtualization mais je suis pas sûr que mon application si elle tourne pas comment je fais etc, alors aujourd'hui je me dis mais en fait avec la mobilité qu'on a la capacité de te fournir en fait je dirais met toutes tes applications, sur ton kubirt, ok, on teste, on regarde on voit, ça marche pas, on revient en arrière on te la redémarre sur tes, VMWare et je dis pour moi je suis sûr qu'il y a des applications comme les mainframes encore on en revient mais qu'il y a des applications qui resteront sur du VMWare donc ça sera un plus petit scope parce que les clients devront réduire l'ardoise mais, c'est possible et c'est cette mobilité qui va permettre aux clients on en revient en fait, de pouvoir tester des nouveautés tester, voir si ça marche, si ça marche pas.

Bruno:
Il y a aussi quand même, parce que vous avez quand même un focus très fort, j'entends évidemment que le but c'est de redémarrer toute une application et tout un service, avec tous les services qui vont avec, mais avec un focus quand même très fort sur la donnée, qui est quand même aujourd'hui considérée comme ce qui a le plus de valeur, c'est-à-dire que le code est devenu quelque chose qui n'a plus de valeur, la donnée elle en a très fortement, mais elle est aussi extrêmement utilisée par tous ces systèmes d'IA. Comment est-ce que tous ces nouveaux services de LLM qu'on ajoute dans nos applications aujourd'hui, ça va impacter aussi, justement, de la manière dont cette donnée, est consommée, peut-être back-upée, peut-être vérifiée, peut-être relancée ? À quel point est-ce que ça joue aussi chez vous, en fait ?

Christophe:
Alors, ça joue dans le sens où, à un moment donné, nous, on va, comme je dis, si on restaure, on restaure la donnée qu'on a sauvegardée et qui était en amont, d'accord ? Par contre, qui a fait quoi sur la donnée au moment où on a sauvegardé ? Ça, on n'avait pas la visibilité. C'est pour ça qu'on a racheté Security AI, qui permet de voir la cartographie des accès de la donnée, etc., et de pouvoir voir qui a fait quoi. Parce que dans le domaine de l'IA, c'est ça qui va être important. Aujourd'hui, c'est de savoir la véracité de la donnée, est-ce qu'elle est bonne, est-ce qu'elle n'est pas bonne. Parce qu'à un moment donné, s'il y a une dérive, voilà, par exemple, si je prends, alors ça va peut-être être polémique, mais si je prends une IA chinoise versus une IA américaine, vous allez vous apercevoir que vous vous demandez c'est quoi. Sur une IA chinoise, quelqu'un avait fait un test une fois, j'avais vu ça dans la presse, quel est le meilleur pays du monde ? Ils disent que c'est la Chine. Ça dépend ce qu'on lui donne à manger.

Bruno:
En fait.

Christophe:
Et c'est là où, effectivement, pour l'IA, ce qui me fait peur, c'est pas les modèles en tant que tels, c'est qu'est-ce qu'on lui donne à manger, qu'est-ce qu'il va dire. Là, tout à l'heure, dans la voiture, j'étais en train d'effectivement... Il y a une polémique qui sort sur Google, sur Gemini, je crois. Parce qu'à un moment donné, en fait, il disait, si vous êtes marié avec un Pakistanais, à quoi il doit faire attendre la... Tu vois, de quoi je parle ? En fait, c'est hallucinant. C'est qu'on se dit, OK, il est déjà parti pris, mais en gros, par qui il a été éduqué ? C'est toujours la même chose. C'est comme un enfant. En fonction de par qui il a été éduqué, il va avoir des partis pris. Et c'est là où il faut faire attention avec l'IA de savoir c'est quoi la vraie donnée et qu'est-ce qu'on peut dire que c'est une donnée qui est vraiment véridique. Et c'est pour ça, nous, qu'on a racheté Security AI, en fait. C'est ni plus ni moins pour avoir cette cartographie des données, d'accord ? Pouvoir la cartographier, savoir qui a accès à quoi, quand, comment, qui a touché, qui a pas touché, etc. Et c'est ça qui va nous permettre ensuite, après, de pouvoir alimenter notre système. Et le Security AI, par exemple, va nous dire, attention, il faut que tu redémarre ta sauvegarde d'il y a deux mois, parce qu'en fait, depuis deux mois, en fait, t'es pollué. D'accord ? Donc, en fait, tu vas restaurer quelque chose, ok, super. je te certifie que c'est bien la donnée qui avait à l'instant t mais sauf que là à l'instant t est ce que la donnée était pure ou pas c'est ça qui est intéressant et c'est pour ça qu'il ya il faut faire attention c'est encore une fois c'est qu'est-ce qu'on lui donne à manger, et donc on en arrive sur le fait aujourd'hui, il n'y a pas seulement sauvegarder la donnée mais savoir, et d'assurer que la donnée est bien pure ou fiable on va dire.

Bruno:
Une certaine forme d'intégrité de la donnée.

Christophe:
À l'été la donnée c'est ça.

Bruno:
Dans ce que tu as évoqué parce que, tu nous as dit tout à l'heure que vous avez une granularité de snapshot qui peut aller jusqu'à 5 minutes. Donc faire un snapshot toutes les 5 minutes. Là, tu nous prends un exemple de... Certes, il est fictif, mais quand même l'exemple de... Il faut que tu restores ta donnée d'il y a 2 mois. Et en fait, la question qui s'est construite avec ces différents éléments, c'est que, quand tu fais ton snapshot toutes les 5 minutes, est-ce que c'est-à-dire que tu vas back-up l'intégralité de la donnée, toutes les 5 minutes, auquel cas ça va te prendre du stockage, tu fais les changements mais du coup est-ce que ça veut dire que vous êtes capable de dire ok je te restaure la donnée d'il y a deux mois, et en fait je vais réussir à réappliquer tous les changements qui ont été apportés en deux mois sur ta donnée en excluant après.

Christophe:
C'est de la réconciliation à.

Bruno:
Faire là ça.

Christophe:
Va être un problème parce qu'à un moment donné, si la donnée elle a été impactée après ma sauvegarde il va avoir une réconciliation à faire et là il y a tout un boulot c'est pas magique, par contre en revanche Security Eye va pouvoir aider là dessus et dire qu'est-ce qui a été bougé, qu'est-ce qui n'a pas été bougé. Et donc, c'est là où ça va permettre de reconstruire. Parce que, nous, effectivement...

Bruno:
Parce qu'en fait, tu vois, je peux me dire que tu parlais tout à l'heure de Security AI qui va vous permettre, en fait, de cartographier, en fait, toute la donnée qui a accès, quand, comment, qui a fait quoi. En fait, c'est-à-dire qu'on peut identifier une espèce de pattern qui a pollué la donnée et de se dire, en fait, on exclut tout ce... Tout ce qui correspond à ce pattern-là, mais on rejoue tout le reste.

Christophe:
Ça peut être ça, oui, effectivement. Mais après, encore une fois, Pourquoi ça c'est ? On va s'intégrer à des outils de sécurité, donc c'est une partie, mais il n'y a pas qu'eux en fait, c'est là où il va y avoir tout un travail. Mais là, ce n'est pas magique, effectivement. Nous, ce qu'on peut dire, c'est que si on est sûr qu'à l'instant T de tout ça, la seule chose qu'on pourra dire et qui va être plus facile à faire, c'est qu'avant, quand il y a une attaque, ce qui se passe, un ciseau, il bloque tout, il ferme tout. D'accord ? Et après, est-ce qu'il va être capable d'order ? Et donc, tu as les gens du business. Ah, il faut remettre le service. Ben oui, mais est-ce que tu peux me valider que ça, ça n'a pas été corrompu ? Donc, à un moment donné, là, ce qu'on va pouvoir faire, c'est dire, moi, je peux te valider qu'avec les outils séries qu'on a vus, que la donnée, elle a été, je dirais, qu'engrenée ou attaquée qu'à partir de telle date. Donc, si on fait cette restauration-là, je peux te garantir que le service va tourner, peut-être pas avec toutes les données à jour, parce que là, il y aura un boulot à faire. Par contre, ton service, je vais pouvoir redonner le service. Là, c'est un garant pour le ciseau qui va pouvoir dire, OK, j'ai la garantie qu'en redémarrant ce système-là, je ne vais pas regangréner, remettre du virus partout. Donc là, du coup, il va être plus rassuré. Et le problème aujourd'hui, c'est ça, c'est comment je rassure un ciseau pour lui dire, ce système que j'ai sauvegardé hier, il est bon, ne t'inquiète pas, ça redémarre. Et c'est là où il faut effectivement avoir cette confiance et d'être sûr que la donnée n'a pas été corrompue, Pour terminer.

Bruno:
Est-ce que vous voyez on évoquait tout à l'heure le fait qu'on met beaucoup plus en prod, qu'avant parce qu'on peut faire beaucoup plus de choses beaucoup plus rapidement qu'avant est-ce que vous voyez dans les usages une tendance qui montre qu'on fait beaucoup plus de rollback qu'avant, parce qu'en fait on fait beaucoup plus de merde qu'avant, ou au final, on arrive à produire beaucoup plus vite, mais de manière toujours aussi qualitative ?

Christophe:
On arrive à produire plus vite de manière qualitative. Après, ça va être en fonction des sociétés et, je dirais, de la... De l'expérience qu'a le client autour de Kubernetes, en fait. Souvent, des fois, ça va être plutôt un manque de connaissances du système Kubernetes qui va amener des erreurs, en fait. C'est comme je le disais en amont, des fois, souvent, le problème, ce n'est pas la sauvegarde, c'est la façon dont c'est configuré au niveau Kubernetes. Et ça, ça va demander un temps d'éducation. Parce que je cherchais le terme, c'est une éducation, en fait, à avoir. Donc, il y a des sociétés qui vont être super rapides, des très gros clients qu'on a ou là c'est ce que j'appelle c'est vraiment des tueurs au niveau Kubernetes. Par contre nous ce que ça nous apporte c'est que nous par contre avec eux on est obligé de plus parler Kubernetes donc on parle pas que sauvegarde et c'est ça qui fait la force aujourd'hui de mes équipes en tout cas techniques c'est qu'elles parlent pas que sauvegarde elles parlent Kubernetes aussi, encore une fois le problème c'est l'application c'est comment je redémarre mon service donc ça c'est le premier point. Deuxième point par rapport à ce que tu disais est-ce que le client va pouvoir va commencer à accélérer et faire des rollback ouais, on voit parce que ils ont ils commencent à avoir confiance donc il dit bah tiens je vais lancer service là je vais voir si ça marche ça marche pas je reviens en arrière etc donc ils vont avoir cette flexibilité que va apporter justement qu'ils permettent est ce que j'avais pas avant, quand je j'avais une version c'est un moment donné quand on se plantait dans un développement bah il fallait attendre 12 mois pour en ressortir ou alors falloir venir à la version précédente là aujourd'hui c'est plus cas on peut grâce aux microservices justement on peut on peut adapter rapidement donc oui bien sûr des rollbacks, sont nécessaires après là où ça va jouer, où là où on va avoir la pression, c'est le rollback et en combien de temps je suis capable de le faire parce que des fois, une interruption de 10 minutes on peut dire, c'est pas beaucoup, on va dans le monde bancaire 20 000 microsecondes si pour passer un échange c'est mort donc voilà, c'est pour ça que des rollbacks il va y en avoir de plus en plus en tout cas, il commence à y en avoir, est-ce que c'est déjà maintenant, je dirais standardisé, je dirais pas non je dirais pas oui, par contre ça commence à arriver ok.

Bruno:
J'en ai Dernière question en plus, auquel je pense aussi, c'est que... Alors je sais pas si tu pourras peut-être nous détailler aussi comment ça se passe chez vous. Mais comme vous êtes quand même sur des systèmes relativement critiques, vous avez quand même un devoir, tu le disais, c'est-à-dire que le but, c'est de rassurer notamment un ciseau. Ce n'est pas les trucs que tu fais comme ça, par dessous la jambe. Dans les pratiques de dev en interne chez Vim, sur toutes les solutions que vous avez, est-ce que vous aussi, vous êtes passé en mode, en fait, vous produisez du code de manière disproportionnée par rapport à avant ? Ou est-ce que de par cette spécificité que vous avez, c'est-à-dire qu'il faut quand même garantir une certaine fiabilité du système, en fait, vous avez encore du code qui est énormément écrit à la main, très relu par des humains. Tu vois, c'est quoi vos pratiques là-dessus ?

Christophe:
Alors, est-ce qu'on utilise l'IA ? Oui, on l'utilise. Il y a de la relecture, évidemment. On fait, on teste beaucoup plus de nouvelles features, effectivement. Mais par contre, après, ça n'empêche pas la relecture parce que nous, par contre, en revanche, on se doit d'assurer de fournir un produit stable au client. Donc il est retesté, retesté, retesté donc ça prend du temps quand même de valider et c'est pour ça, sinon je dirais si on ne sait pas faire ça autant prendre de l'open source dans ce cas là, voilà, c'est ce qui va faire la garantie donc nous aussi, nous bien entendu je ne dirais pas que c'est faux de dire qu'on n'utilise pas l'IA même moi à mon niveau d'un point de vue commercial je l'utilise, on voit l'avantage ça permet de faire un tri mais ça n'empêche pas qu'à un moment donné il y a de.

Bruno:
La revue que tu vas avoir Est-ce que toi du coup depuis que tu es chez Vim sur les 12 derniers mois tu vois un changement de rythme de release de nouvelles fonctionnalités, de correction ce genre de choses, Ou au final, c'est un peu mieux qu'avant, mais sans être non plus...

Christophe:
Alors, sur la partie Castel, je dirais que nous, on est Kubernetes natif depuis de bout à bout. En fait, on les voit rêver, les nouvelles features. Après, on va arriver plutôt sur des... Maintenant, on arrive quand le produit est assez mature. On va arriver plutôt sur des limites techniques liées à Kubernetes ou liées à l'infrastructure Kubernetes, ce qui fait que certaines features, on va avoir du mal à les développer. Il faut qu'on repense différemment, en fait. C'est plutôt là que je les vois. Mais sinon, je dirais même, on va avoir, des nouvelles features, mais un peu moins moins qu'avant parce que le produit c'est vraiment, je dirais est de plus en plus robuste et que maintenant on arrive sur plus des contraintes liées à cubert est tout système à une contrainte en fait à un moment donné donc donc de dire que tout ou, quand on va résoudre tous les problèmes de la terre et cube c'est pas vrai on déplace des fois un petit peu le problème on va améliorer des choses voilà la question c'est qu'est ce qu'on doit améliorer en projet aujourd'hui le maître mot c'est go to market donc c'est de pouvoir déployer les services rapidement, après par contre maintenant ce qu'il faut faire et pour rassurer les ciseaux ce que tu dis etc, c'est justement de créer cette couche de confiance derrière l'ia notamment de créer cette infrastructure de confiance l'infrastructure pour sauver l'année je sais la sauvegarde et je suis capable de dire qu'elle va pas bouger etc ok super et maintenant, la confiance qui fait que mon système en lui-même va me permettre va être bien restauré au bon moment qui va être auditable etc et c'est là le challenge aujourd'hui c'est ce challenge de l'ia d'ailleurs.

Bruno:
— Top. Merci beaucoup, Christophe, pour tes discussions. J'aurais une dernière question pour toi, qui est une des questions rituelles du podcast. Est-ce qu'il y a un contenu que tu souhaiterais partager avec l'ensemble des auditeuristes ?

Christophe:
— Alors en fait, moi, ma Bible, et je dirais que c'est valable aussi bien dans le monde sales que dans le monde technique ou business, c'est Simon Sinek, en fait, qui a créé le Golden Circle. Et en fait qui dit tout simplement il faut se focaliser sur le why parce que souvent l'IT on s'est focalisé sur le what et le how et en fait lui ce qu'il dit d'abord focalisons nous sur le why et pour moi ça c'est ma bible, aussi bien d'un point de vue commercial que d'un point de vue technique quand je suis avec un client c'est ok attends, ok tu veux ça mais pourquoi tu le veux en fait parce que souvent on nous demande une feature mais on ne nous demande pas le pourquoi ok pourquoi, qu'est-ce que tu veux sécuriser ah ok mais pour sécuriser ça tu peux le faire comme ça donc je pense que ça c'est pour moi c'est ma bible, et je pense que c'est aussi de la, De mon sens paysan, en fait, tout simplement. Et je reprends l'exemple de l'iPhone, quand c'était une guerre entre, comment ça s'appelle, entre Wozniak et Steve Jobs à la base, où, en fait, Steve Jobs disait, non, non, moi, je veux pas que le client, il regarde à l'intérieur du système. Il est pas fait, il est pas éduqué pour. Lui, ce que je veux, c'est qu'il veut accéder à son service, il veut faire son téléphone. alors que Wozniak qui était plutôt un geek dans l'âme ouais mais regarde s'il fait ça, il pourra customiser ouais mais plus il customise, moins il maîtrise et donc plus il y a de problèmes et je pense que ça résume un peu ça de où on met la barre, où on place la.

Bruno:
Barre et puis là où je te rejoins c'est que cette recherche du way je pense que c'est aussi indispensable dans notre métier de développeur et de développeuse, de pas aller juste écrire une feature ce que l'on nous a demandé mais de comprendre effectivement ce que les gens y veulent on en parlait dans le compilé qu'on a fait juste avant, notre métier c'est pas d'écrire du code c'est d'apporter une solution et pour apporter une bonne solution il faut comprendre le bon problème. Tout à fait merci beaucoup Christophe merci à tous d'avoir suivi cet épisode j'espère que ça vous aura donné envie d'aller checker un peu tout ce que Vim va vous proposer. Si vous n'êtes pas encore dans un environnement cube je pense que cette discussion de Christophe vous a peut-être donné aussi envie de passer sur cube et donc potentiellement aller checker ce que Vim propose là dessus en tout cas moi je vous remercie comme toujours de partager ce podcast autour de vous. N'hésitez pas à aller checker en description de cet épisode pour voir le lien pour aller essayer le MCP FTD et avoir toute cette base de savoir directement dans votre agent de génération de code, ça peut toujours être utile, je vous remercie je vous souhaite une très bonne fin de semaine, je vous dis à la semaine prochaine et d'ici là, codez bien.