- Speaker #0
Aujourd'hui, on va parler d'un métier qui a récemment évolué dans le monde de la cyber, un métier qui apporte sa couche d'abstraction à la résilience des entreprises et que très peu maîtrisent, même au sein des DSI. Ce métier, c'est celui d'architecte, mais pas n'importe lequel, un architecte virtualisation. On va donc passer en accéléré du rack au cloud et 20 ans de transformation dans les infras. Mon invité du jour, il a tout vu des data centers bien réels aux infrastructures hyper convergées, des VM à la mode aux stratégies FinOps d'aujourd'hui. il a co-écrit des livres sur VMware, il a été formateur Citrix, VMware et il est encore formateur AWS. Et maintenant, il enseigne comment éviter les plantages, entre autres. Il fait en sorte que ça tienne dans le budget et que ça marche. Son côté FinOps n'y est peut-être pas pour rien et son côté Agilopathe non plus. Mon invité d'aujourd'hui, c'est Eric Fourn. Il a formé plus d'ingé que le rectorat, mais aujourd'hui, c'est lui qui est sur le grill avec moi. On va parler virtualisation, bien sûr, mais aussi formation. transmission et audit, et surtout ce qui fait de lui une pointure dans ce monde en perpétuelle mutation. Bonjour Eric, je me rappelle de notre rencontre à Nice, c'était en 2016 je crois, pour un event d'une semaine sur la cybersécurité. Tu m'avais alors été présenté par l'un des organisateurs comme étant une des références dans le monde de la Virtu, mais tu as quand même écrit des livres, non ?
- Speaker #1
Bonjour Fabrice. Merci pour l'invitation. Et effectivement, moi aussi, je me rappelle de l'Event A Nice. C'était une formation sur la cybersécurité, effectivement, une norme en particulier. Et effectivement, je travaille depuis très longtemps dans le milieu de la virtualisation. Il se trouve que j'ai co-écrit deux livres sur le produit Vsphere de VMware.
- Speaker #0
Cool. Moi, en fait, tu vois, je n'ai pas trop connu ce monde-là, le monde de la virtu. J'ai quitté, en fait, ma position d'administrateur système au moment où ça commençait, en fait. Donc, je suis encore à l'ancienne mode, mais ça remonte à plus de 15 ans maintenant. Donc, j'ai connu du Xen sur Linux. j'ai connu les micro-p de Sun Microsystems avant qu'ils se fassent racheter par Oracle. Quand ils ont commencé à faire tourner du x86 dessus, c'est là vraiment où on a commencé à faire des dual-boots sur Solaris, à commencer à jouer sur du Linux avec des environnements desktop, mais virtualisés. Mais moi, je me suis arrêté là. Donc là, les amis, je vous parle d'un temps où mes procédures DR tournaient encore sur les serveurs physiques. Toi, peux-tu nous dire ? que pour toi cela a amené en termes de cybersécurité ? C'est-à-dire résilience, disaster recovery, éventuellement puissance ? Tu es devenu architecte cloud en fait maintenant.
- Speaker #1
Oui, effectivement. Alors moi aussi j'ai connu le monde un peu physique, 100% physique avec les serveurs, avec les data centers. Et effectivement, petite dédicace à un ami, Stéphane, avec qui j'ai travaillé beaucoup sur du... Disaster Recovery dans le milieu Solaris, c'est un expert Solaris. On a fait énormément de choses, on a appris énormément avec cette personne et on a fait des échanges, on a travaillé sur de la virtualisation. En fait, la virtualisation, c'est un petit peu le produit magique qui permettait de recréer un environnement pour créer une situation qu'avait un client. Par exemple, j'ai mon outil d'antivirus qui ne fonctionne pas, il y a quelque chose de bizarre dans la console. et qui nous pouvaient, grâce à des produits faciles d'utilisation comme les produits VMware, Workstation, il y a très très longtemps, même la version 1, on pouvait très rapidement installer notre environnement, réinstaller un système, mettre en place le produit et voir comment ça réagissait. Et des fois, même assez souvent, on arrivait à reproduire la situation du client et on était capable de lui dire, monsieur, madame, mettez en place ce petit patch. ou changer ce paramètre et puis ça va fonctionner.
- Speaker #0
Donc, c'est comme ça. Donc, accélération pour le client, tu pouvais tester plein de choses du coup, sans devoir acheter le serveur.
- Speaker #1
Ah oui, ça, c'était vraiment super. C'est là que ça a commencé. Et puis après, effectivement, quand c'est arrivé dans les entreprises, et puis après, c'était beaucoup plus simple. Une machine virtuelle, c'est un ensemble de fichiers. Donc, si on repose des fichiers au bon endroit, qui sont dans le bon état, les snapshots, c'est-à-dire quand on prend un instantané de l'état du serveur Là, on arrive à faire des choses très intéressantes. Et on peut tester des choses. Donc, dans tout ce qui est sécurité, et en particulier la partie A, c'est la partie disponibilité, availability, là, on arrive à faire des choses très intéressantes et surtout faciles. On pouvait donner la procédure à n'importe qui. Donc, ça nous a facilité la vie. Et puis, il y a même des produits aujourd'hui qui sont basés dessus. créent des environnements à la volée et qui permettent de tester un script en environnement cloisonné et nous sortir des résultats. Donc en cybersécurité,
- Speaker #0
c'est génial. Comme Veaam. Veeam fait ça aussi, je pense. Ça, j'ai eu l'occasion de tester. Pas de déployer perso, mais de gérer des DR où ils utilisaient Veeam avec des réplications. Ils ont testé du coup de l'autre côté avec les tests fonctionnels. C'était magique. Moi, quand je me rends compte que je devais installer tout ça sur des serveurs, préparer du patching, c'était sur les vrais serveurs. Et quand on était encore chez Sun, mais ça remonte maintenant 25 ans, on faisait des stress tests sur les machines clients. Donc le client avait sa machine qui faisait un hang. On ne savait pas reproduire le problème chez le client. On la mettait en lab chez nous, mais je te parle même de gros serveurs, des bêtes qui pèsent 100, 200 kilos. Et on réinstallait l'OS, on testait tout à fond, mais tu voyais, ça nous prenait une semaine. Et... Ce n'était pas toujours reproductible non plus. Et donc, ça frustrait nous et le client parfois. Tandis qu'avec une VM, on peut décupler tout ça. Moi, je trouve ça génial. Je suis un peu frustré parce que je n'ai pas connu ce monde-là. Je le comprends, mais c'est toi l'expert. De ce côté-là, ce n'est pas moi. Mais bon, j'ai aussi fait mon deuil. Ok, tu as d'autres choses par rapport à ça, sur l'évolution de ces VM ? Tu as fait d'autres choses suite à ça ou pas ?
- Speaker #1
Oui, on a fait plein de choses. En fait, tu vois, tu me dis que je suis l'expert, mais en fait, surtout en virtualisation et dans ce monde-là, je suis un éternel débutant, on en apprend tous les jours. Je me suis retrouvé avec des cas inimaginables, avec des orchestrations de plans de reprise grâce à des machines virtuelles et des sites, des reprises d'un site à l'autre. avec une synchronisation avec des baies de stockage.
- Speaker #0
Le site complet ? Donc, complet failover d'un DC, par exemple ?
- Speaker #1
Ah oui, oui, complet. Alors, des fois, ce n'était pas complet. On disait qu'on avait des machines d'importance qu'on devait récupérer. Et donc, il fallait configurer l'environnement pour que certaines machines ne redémarrent pas. D'autres redémarrent quand il y avait assez de puissance. Oui, oui, oui. Et puis, certaines devaient absolument démarrer dans un ordre précis.
- Speaker #0
Oui, je vois. J'ai eu ça sur des salles machines que nous, on a dû arrêter. C'était le côté physique aussi, du coup. Mais il y avait cette fameuse orchestration avec des gens qui n'avaient jamais préparé ça. Donc, des sysaadmins qui ne réfléchissaient pas et qui disaient... Nous, on avait déjà coupé le réseau, par exemple, et eux disaient... Oui, mais maintenant, je vais me connecter au terminal serveur pour arrêter mes machines. Je dis, mais non, tu n'as plus le réseau. Donc, tu dois aller dans le DC. Le DC, tu as 20 kilomètres. pour te connecter au terminal server qui est dans le DC, tu vas faire comment ? Toutes des choses comme ça. Après, quand c'était bien préparé, d'année en année, pour le même DC, on avait cette fameuse procédure et on en profitait quand on devait arrêter le DC pour documenter ça forcément, mettre à jour et faire notre plan DR en fonction parce qu'on ne peut pas arrêter un datacenter comme ça. Mais oui, orchestration, du coup, je vois très bien les... pas dire les ennuis, mais les contraintes. Et si tu as tes plans derrière qui ne sont pas bien à jour, ton plan d'orchestration qui est théorique au moment de le lancer et qui est super bien validé, il suffit qu'il y en ait un qui ait planté quelque chose, c'est une machine qui ne démarre plus. Oui, donc, même avec de la Virtu, en fait, là, tu gardes la contrainte de l'orchestration. Donc, ça t'aide, mais même avec la Virtu, ça, c'est la même contrainte, je pense. D'accord avec ça ?
- Speaker #1
Tout à fait. Et puis... La virtualisation a apporté énormément de choses, de la souplesse et tout ça, mais en réalité, à partir du moment où on oublie les règles fondamentales, en fait, virtu ou pas virtu, ça ne fonctionne pas. Quand je donnais des formations sur VMware, ce que je disais souvent, qui faisait sourire mes stagiaires, c'était, tu sais, la machine est peut-être virtuelle, mais les problèmes sont réels. Et donc, je disais, si ça ne fonctionne pas, l'argent que tu perds, il n'est pas virtuel.
- Speaker #0
Oui, ou le manque à gagner, ou le temps perdu, il est perdu.
- Speaker #1
Voilà. On avait aussi des cas où on se retrouvait avec un avis. On m'appelait et on me disait « Éric, là, on revient en arrière. Comment ça ? On retourne au physique. » « Bon, expliquez-moi. » J'ai eu des cas où la rigueur n'était pas respectée. On testait des versions différentes et on me disait « En virtu, ça ne fonctionne pas. Oui, mais tu testes une version qui est buggée, qui est encore en preview. » Donc non. Ça ne va pas fonctionner, ça va boucler. Et puis, ça fonctionne moins bien.
- Speaker #0
Et ils auraient eu le même problème. Peut-être pas ce même problème-là, puisqu'ils n'auraient pas utilisé la même VM, mais ils auraient eu d'autres problèmes. Manque de rigueur. Oui, c'est facile, ça va plus vite. Mais si tu n'as pas de rigueur, de toute façon, ça ne marche pas. Et aujourd'hui, au fil des ans, tu es devenu architecte cloud. Pour l'instant, principalement AWS. Mais tu restes à l'écoute des autres technologies également. Est-ce que c'est ta compréhension de la vertu qui t'a aidé, voire décidé, à embarquer dans le cloud ?
- Speaker #1
Oui. Alors effectivement, aujourd'hui, je fais de l'AWS et beaucoup d'Azure aussi, puisque c'est arrivé par une prestation chez un client. Un peu de Google aussi, même. J'aime bien regarder ce qui se fait un peu partout. Est-ce que la virtualisation m'a aidé ? Oui, pour la simple et unique raison qu'en fait, le cloud s'est présenté comme un ensemble technologique. Non, le cloud, c'est un modèle. C'est un modèle d'utilisation de la ressource. Et ce sont des technologies sous-jacentes qui soutiennent ce modèle. À partir du moment où on estime qu'on doit se servir soi-même, aller chercher l'information sur une interface, demander de la ressource, et d'ici quelques minutes, c'est disponible que ce soit du serveur de la base de données. du stockage, il faut quelque chose en dessous qui automatise et qui fait qu'il y a un peu moins de personnes aux commandes. Parce que quand je vais demander un serveur, idéalement j'ai quelque chose d'automatisé qui va me donner le serveur que je demande. Alors je ne vais pas avoir une configuration exotique, mais je vais avoir quelque chose qui s'en rapproche. C'est la ressource sur étagère, on va aller chercher ce qu'il y a de disponible. Et en fin de compte... La base de tout ça, c'est la virtualisation. Comme je disais tout à l'heure, une VM, c'est un ensemble de fichiers. Alors, si je demande finalement un ensemble de fichiers, qu'on sait me coller des fichiers quelque part, bon, ça va fonctionner. Après, si j'ai les droits d'exécution, on me les donne à la volée et puis je lance le tout. Donc, la virtualisation, c'est quand même la base du cloud. Ça m'a aidé, évidemment.
- Speaker #0
Moi, je l'ai ressenti comme ça aussi dans le CICSP au fil des ans. C'est la fameuse certif, la Bible de 1200 pages, où quand tu sors de là, tu as l'impression de tout connaître, mais finalement, tu ne connais rien, parce que c'est une table de matière qui ne fait que grossir au fil des années. Justement, au fil des années, dans un des chapitres, on a vu qu'on venait du mainframe. Il y a encore des mainframes qui existent, je reconnais. On a évolué vers l'architecture N-tier, puis tout doucement vers la Virtu. On voit vraiment l'historique arriver, la Virtu, et puis le Cloud. Sauf que dans le CICSP, Ils ne donnent pas trop d'infos sur le cloud parce qu'ils ont un autre certif, qui s'appelle le CCSP, qui est un agnostique aussi de tout vendeur. Et donc, ils ne voulaient pas tuer leur bébé. Mais on voit vraiment ce scaling et comment ce chapitre-là est construit sur les bases théoriques avec du réseau, forcément, qui est transversal, avec de l'IAM. Et eux aussi, dans la façon dont ils ont fait évoluer leur chapitre, on voit que c'est en scale, c'est avec différentes couches. Et je trouve que oui, c'est là où je me dis, la VM finalement, enfin la virtu, est une des bases du cloud, parce que tu vois directement que dans le chapitre, alors je le fais un peu de manière pragmatique, mais dans le chapitre, ce qui suit, c'est le cloud. Et voilà, ce que j'ai aussi entendu, c'est que pour un hôpital notamment, avec lequel je travaille, eux, ils ne veulent pas du tout aller dans le cloud, et ils ont expliqué des problèmes de latence. Ils disent, voilà, on doit faire des IRM. il y a des examens en cancérologie, que sais-je, c'est des... On ne connaît même pas la taille du volume. Ils disent, on ne peut pas se permettre de mettre ça dans le cloud parce qu'on en a besoin de ça à l'instant T. Et donc là, on est trop tributaires du réseau, donc ils ont leur propre réseau, leur propre data center avec où ils sont en machine, mais eux, c'est stratégique. Je ne dis pas que tous les hôpitaux font ça, mais celui avec lequel j'ai eu l'occasion de travailler, ils le font. Et après, le reste, ils restent maîtres. Et alors, ils ne cachent pas le fait qu'ils ont des VM. Donc, ils ont des VM, forcément, mais ça reste chez eux. Donc, tu vois, moi, j'ai été assez étonné avec eux parce que c'est les premiers qui disent, on ne va pas dans le cloud. Alors après, oui, ils ont des petites applications SaaS. comme tout le monde, mais qui sont plutôt pour les non opérationnels, c'est-à-dire en dehors de l'hôpital. Donc je pense qu'on va encore avoir des vagues qui vont revenir. Aujourd'hui, tout entrepreneur dans l'IT, tout analyste ou même tout développeur qui ne ne maîtrise pas la virtualisation, honnêtement, je pense qu'il est mort. Tu es d'accord avec moi ? S'il ne maîtrise pas ça...
- Speaker #1
Oui, il a un minimum à connaître. C'est effectivement... Je suis d'accord avec toi. Ne serait-ce que savoir ce que c'est et savoir ce que ça implique. Par exemple, un développeur qui n'a aucune idée de ce que c'est qu'une machine virtuelle, il se peut qu'un jour il ait un problème dans son code, il se peut qu'un jour il se dise, bon, on va le faire tourner soit dans des VM, soit dans des containers, mais il faut qu'il ait une petite idée de la technologie sous-jacente qui va permettre de, des fois, faire des adaptations et comprendre pourquoi ça ne marche pas. Parce que, des fois, ça ne fonctionne pas. à cause de ce qu'il y a en dessous.
- Speaker #0
Moi, j'avais 1ca à en assembleur à l'école, mais ça remonte. Je me rappelle, j'avais un 486 à la maison. Je codais chez moi. C'était nickel. Je suis arrivé à l'école, je me mettais sur un autre 386, ça ne marchait pas, ce n'était pas le même micro-P. Et j'avais pris des codes qui étaient trop précis par rapport à mon propre micro-P. Donc, j'avais déjà optimisé mon code. Et c'est là où tu te rends compte que ça ne marchait pas. Donc, ça, ça m'a appris à coder différemment. Bien sûr, on était loin de la virtu. Mais en fait, ce que tu expliques là, oui, si le développeur travaille uniquement dans son sandbox et pense que ça va marcher même en test, il se met le doigt dans l'œil. Et ça, je l'entends encore souvent avec les clients chez qui je travaille. C'est parfois même le DevOps qui doit venir tripatouiller le code du développeur alors qu'il tourne sa propre machine sur sa propre VM en local. Il dit, ouais, mais chez moi, ça marche. Ça, c'est aussi réfléchi au développeur. Chez moi, ça marche, ou sur ma bécane, ça marche. Je ne comprends pas pourquoi ça ne marche pas dans l'environnement de test. Rigueur. Rigueur, rigueur, rigueur, rigueur.
- Speaker #1
Attends, je vais peut-être réagir à ce que tu dis. Oui, tu m'as parlé de l'hôpital. Aujourd'hui, j'estime qu'il y a un seul modèle de cloud. C'est le cloud hybride. C'est-à-dire un peu chez nous, un peu à l'extérieur. Ce qui assume le fait de dire... « Non, moi, je n'y vais pas. » C'est qu'ils ont étudié la chose. Et donc, c'est bénéfique. Aujourd'hui, avec les problèmes de sécurité qu'on voit apparaître de plus en plus aujourd'hui, c'est juste un modèle. Donc, c'est OK. C'est OK d'utiliser une partie des services dont on a besoin et de ne pas tout mettre là-dedans.
- Speaker #0
Oui, je suis assez d'accord aussi avec toi parce que je pense plus loin en termes de continuité d'activité. et ce n'est pas l'entreprise qui doit s'adapter au cloud. Pour moi, l'entreprise, comme tu dis, doit faire son marché, optimiser là où elle s'est optimisée, mais ne pas tout mettre dans le cloud. Tout comme je dirais, ne pas tout mettre dans un data center non plus, parce que je pense résilience, je pense continuité d'activité. Les clouds qu'on connaît aujourd'hui, ils sont quand même de l'autre côté de l'Atlantique. Il y a une partie géopolitique qui rentre en ligne de compte. Il y a eu récemment un blackout total au Portugal sur une panne de courant qui finalement a été induite apparemment à cause de l'Espagne. C'est super, si on a tout dans le cloud, c'est génial, mais je n'ai pas de courant, je fais comment ? Donc c'est cet état d'esprit-là, c'est dire le cloud pour moi fait partie de la résilience et doit faire partie d'une stratégie. qui va au-delà de la sécurité de l'information, mais qui va vraiment sur la continuité d'activité. Et après, je sais que les sociétés sont limitées également par l'argent, les investissements. Et je n'ai pas encore vu, en tout cas aujourd'hui, une société qui est, par exemple, chez AWS, qui est à la fois chez Google, en tout cas pour les mêmes applis, et qui est à la fois chez Microsoft. Ça coûterait tellement cher, et le coût en maintenance de ça, je ne le vois pas. Par contre, je ne sens pas un recul. par rapport au cloud, mais les gens commencent à penser un peu plus hybride, comme tu dis, et pensent un peu plus résilience que dire, ah, ok, j'ai fait du lift and shift, comme certains font. Ils pensent que tout est dans le cloud quand ils ont migré, sauf que non, il y a la gouvernance, il faut continuer à mettre à jour. Ça ne s'arrête pas, la migration ne s'arrête pas une fois que c'est dans le cloud. Et ça, je ne vais pas dire beaucoup de mes clients, mais... Quelques-uns de mes clients n'ont pas cette maturité-là au niveau du cloud et ils font la plupart du temps du lift and shift. Ça y est, on a migré la salle machine. C'est dans le cloud, c'est nickel, le projet est terminé. Non, non, c'est non-stop. C'est un peu comme l'ISO, c'est non-stop. Mais ils n'ont pas la maturité ou ils ne sont pas bien accompagnés avec des architectes comme toi ou autre. Donc, comme tu dis, l'entreprise doit faire son marché. Et il y a du positif dans le cloud, il y a du négatif. Il faut vraiment partir des risques. Et ce que je vois aussi maintenant avec l'IA, L'IA révolutionne notre monde, mais l'IA va aussi révolutionner, pour moi, le monde du business continuity, parce que ça peut nous aider à développer certaines choses et à penser différemment. Et le cloud, du coup, pour moi, est aussi vu comme une stratégie de repli, de résilience. Mais évidemment, si je mets tout dans le cloud et que je ne sais plus accéder à mes données, même si on fait confiance à AWS, même si on fait confiance... confiance à la géopolitique. Ce n'est pas ça que je mets en cause. Si demain, je n'ai plus Internet, qu'est-ce que je fais ? Starlink ? Voilà.
- Speaker #1
Imagine que tout fonctionne bien. Imagine que tout fonctionne bien. Une des premières choses que dit le directeur technique d'AWS, le docteur Vogels, « Don't trust us » . Il dit « Everything fails all the time » . En gros, il dit qu'il y a tout qui va. Ce n'est pas une question de si, c'est une question de quand.
- Speaker #0
C'est chez nous.
- Speaker #1
ça va se casser la figure. Et pour ceux qui ont une stratégie, c'est même pas une stratégie, mais pour ceux qui disent je vais migrer dans le cloud et qui s'arrêtent au lift and shift, ou entre architectes, ce qu'on dit c'est ok, si ta stratégie s'arrête là, c'est du lift and shit. Parce qu'en fait, à la fin, tu ne sais plus quoi faire avec. ok, c'est dans le cloud, et dans trois ans, tu pleures parce que tu regardes la facture. Et il ne s'est rien passé de mieux.
- Speaker #0
J'ai eu un client qui a fait ça. Et ils ont migré une ancienne salle serveur. Ils ont tout migré, mais sans réelle analyse, BCP, BIA, Business Impact Assessment, etc. Ils ont dit, on va tout migrer. Et après, ils ont reçu la première facture. Et pourtant, ils ont pris un intégrateur. Ils ont reçu la première facture. Et là, le business a dit, c'est trop cher. Mais là, l'intégrateur leur a posé les questions, mais ils se sont dit, on verra bien. Et l'intégrateur... Ce n'est pas business. Donc, eux, ils exécutent ce qu'on leur dit. Donc là, ils ont manqué, ils ont appris. Et maintenant, ils ont coupé toute une série de services. Et voilà. Mais je parle quand même d'une petite société. Enfin, ils sont 60. C'est une société qui a quand même plus de 30 ans d'existence. Donc, tu vois, assez, on va dire, exilien ou alors qui est passé au travers des choses. Mais ils ne sont pas prêts. Ils ne sont pas prêts. Et bon, pour eux, ce n'est pas la question de revenir en arrière non plus. La salle était vétuste, ils devaient la migrer. Et ça correspondait à un risque. Donc, on a clôturé un risque chez eux, la vétusté de la salle. Et je leur ai dit, faites gaffe, vous allez vous choper des nouveaux risques avec le cloud. Moi, je suis très bien avec ça. Ce n'est pas négatif de dire, vous allez avoir des nouveaux risques. C'est juste de leur montrer qu'il y a un nouvel actif, ou il y a un nouveau projet. Chaque projet a ses risques. Est-ce que vous avez bien pensé à ça avant d'y aller ? Voilà. et puis maintenant, entre guillemets, c'est trop tard. pour eux, ils ne vont pas revenir en arrière, ce n'est pas le but. Mais ce n'était pas préparé comme cela devrait. Et en plus, ce dont on vient de parler là, c'est une belle intro pour la question suivante, tu fais de la FinOps. Peux-tu nous expliquer ce que c'est et en quoi cela consiste ? J'ai notamment quelques clients qui ont migré vers du cloud sans cette couche d'orientation et je pense que cela aurait pu leur servir avant de migrer, en termes de coûts notamment. C'est quoi ton avis ?
- Speaker #1
FinOps, déjà, c'est des mots à la mode. On a tous entendu DevOps, SecOps et tout ça. FinOps, c'est Financial Operations. En gros, c'est un suivi financier qu'on met en place. Parce que dans le cloud, on nous a vendu que c'était ça. Et ceux qui font du business savent que notre métier... c'est finalement cacher cette complexité au client et la gérer. Lui dire, bon, elle existe, mais je vais la gérer pour toi par rapport à ce que tu m'as demandé. Et ça, c'est le boulot d'architecte en général. Le FinOps, en fait, il y en a beaucoup qui pensent que, bon, le but, c'est de diminuer les factures. C'est un des effets. Mais le FinOps, c'est simplement de comprendre qu'on doit travailler pratiquement au jour le jour. pour comprendre les modèles de tarifs, les modèles de facturation, et faire au mieux, et comprendre comment on dépense. Moi, pour ça, j'aime bien le hip-hop, donc j'utilise un petit peu le titre du premier album de 50 Cent qui n'était pas connu, qui s'appelle « Power of the Dollar » . Vous devez travailler là-dessus. La puissance du dollar que vous dépensez, qu'est-ce qu'il gère ? Qu'est-ce qu'il génère à la fin ? Vous suivez chaque dollar que vous dépensez, chaque euro que vous dépensez, suivez-le. Et à un moment donné, il arrive dans un trou noir. c'est que cet euro que vous avez dépensé, il ne sert à rien. Donc ne le dépensez pas. Le finop, c'est de connaître l'environnement, savoir ce qu'on veut faire et s'adapter pour utiliser les meilleurs modes de fonctionnement, les meilleurs modes de facturation. Acheter en gros ou pas ? Acheter à l'avance ou pas ? S'abonner sur un an, trois ans, parce que ça va nous coûter moins cher ou pas ? Et c'est aussi le fait d'éviter de tomber dans le piège de l'illimité. Tout le monde connaît le forfait illimité avec le téléphone. L'exemple que j'utilise souvent quand je donne des formations FinOps ou quand je fais du conseil FinOps, c'est « Ok, vous avez un forfait téléphonique à 2 heures et il vous coûte 10 euros par mois. Mais à côté de ça, on vous vend un forfait illimité à 20 euros par mois. » Illimité, vous. Vous pouvez utiliser 10 heures, 30 heures, ça va vous coûter 20 euros par mois. Et il y en a qui vont se dire « Ah, mais en fait… » je vais utiliser le forfait illimité parce qu'il me coûte 20 euros. Tu te rends compte ? La bonne façon de voir les choses, c'est plutôt de se dire, est-ce que j'en ai besoin ? Si j'utilise moins de deux heures, l'illimité à 20 euros ne me sert à rien. Donc, je dépense 10 euros par mois pour rien. Et c'est ça l'important. En fait, pour continuer et répondre à la deuxième question que tu m'as posée, c'est quel est ton avis là-dessus ? En fait, pour moi, aller dans le cloud sans la démarche FinOps, c'est organiser un anniversaire sans gâteau. Ça ne marche pas. Tu vois ? Ça ne marche pas. La personne qui est concernée par son anniversaire n'a pas de bougie, elle n'a pas de gâteau, il manque quelque chose. Et même si c'est super la fête, on ne se sent pas bien.
- Speaker #0
Tu as le gâteau, mais pas les invités. Tu vois ?
- Speaker #1
Il manque un truc. Il manque un truc. fondamental. En gros, moi, j'estime, je trouve technologiquement c'est génial, mais je trouve que l'argent, il est mieux dans la poche de l'entreprise, du client que dans la poche d'Amazon ou de Microsoft ou ainsi de suite. Mais Bezos, il est assez riche. Ça suffit, en fait. On va lui donner l'argent qu'on doit lui donner et pas plus.
- Speaker #0
C'est le patron d'Oracle maintenant qui est premier.
- Speaker #1
Mais Oracle aussi a son hyperscaler maintenant, et qui est bien fait, ils ont racheté plein de technologies, et aujourd'hui ils ont quelque chose de correct. Tout le monde a compris, tous ceux qui ont de l'argent ont compris qu'en fait il fallait proposer l'hyperscaler parce que tout le monde aura besoin de ces ressources. Et donc ce qu'on fait, pour moi le FinOps c'est, où est-ce que tu mets l'argent ? Si tu n'as pas besoin de le dépenser, ne le dépense pas. Si tu as besoin de le dépenser par contre, dépense-le, justifie-le. Travaille en architecte, récupère un besoin et apporte une solution.
- Speaker #0
Ça demande une compréhension du métier. Et à mon avis, côté architecte, vous êtes peut-être considérés comme étant trop technique par rapport au métier. Et donc le métier ne vous écoute pas. Alors que vous avez des tonnes de bons conseils à leur dire. Je pense que la FinOps peut être la synapse qui fait vraiment l'interface entre les couches basses. d'architecture et les couches hautes dans le management, mais il faut aussi que le métier sorte de son bureau, se mouille, s'intéresse au cloud, on n'en prend pas des experts, ce n'est pas le but, mais s'intéresse et comprendre où est votre valeur ajoutée en étant architecte dans le FinOps. Ce n'est pas faire que tout se passe bien, c'est faire au mieux pour des besoins qui doivent être alignés sur ce que le client interne veut. Après, il y a beaucoup de clients qui ne savent pas ce qu'ils veulent.
- Speaker #1
même en interne effectivement des fois c'est pas réaliste mais on les guide pour ça j'ai un client chez qui je suis depuis longtemps qui me fait confiance là dessus et je les remercie pour ça
- Speaker #0
je travaille avec le métier, je fais partie d'une équipe et on travaille avec les métiers, on va les voir, on discute avec ces personnes et à un moment donné, ça m'est arrivé souvent, elle leur dit, tu sais, je ne comprends pas ta business logique, est-ce que tu peux faire un schéma que je comprenne un petit peu ce qui se passe ? Oui, je veux faire ci. Non, non, ne parle pas de technique, on va en parler après. Dis-moi comment ça fonctionne, donne-moi la cinématique. Et à force, il y en a qui ont pris l'habitude et ont fait des choses beaucoup plus intéressantes dans le sens où on se dit, ok, on est parti du besoin, on veut faire ci. ou ça. Et tu vois, là, ton besoin est... Je sais faire quelque chose avec. Et je sais te proposer les services sous-jacents. Et à partir de maintenant, t'as un besoin qui est réaliste. Et on arrive à mettre en face les bons services. Et donc, la facture, on sait la justifier. C'est ça, le FinOps.
- Speaker #1
Oui. Super. Je vois pas beaucoup de formations FinOps. J'en vois pas beaucoup. alors qu'il y a vraiment besoin. Donc, on va scruter ça dans les mois qui viennent, voir si les gens comprennent. Maintenant, oui, si on ne vend pas, le but n'est pas de vendre la formation Finops, ce n'est pas ça, ce n'est pas le but du podcast, mais ça peut les aider. Ça peut être un accompagnement pour comprendre justement les difficultés qu'ils auraient à aller seul ou aller avec un intégrateur. n'a pas du tout le mindset FinOps et qui est là pour, tiens, je fais de la prestation, super, j'ai vendu 20 jours, on a gagné, le projet est terminé, appelez quelqu'un d'autre. Du coup, moi, je vois la position FinOps aussi comme n'étant pas... Ça peut être de l'accompagnement, mais je la vois surtout en interne. Il doit y avoir un besoin en interne qui est créé, donc avec un architecte, un ou une, parce qu'il y a... Il y a aussi des femmes dans l'IT, trop peu. Et on a besoin de tout le monde. Mais si la position a été internalisée sur le long terme, c'est intéressant. Et je vois un peu ça aussi avec l'agilité.
- Speaker #0
C'est ce que je voulais te dire. En fait, les formations finops dont tu parles, elles existent. Mais il n'y en a pas beaucoup. Effectivement, on n'est pas... on ne leur donne pas exactement ce dont ils ont besoin parce qu'ils ont besoin de faire le lien avec ce qu'ils doivent faire et ce qu'on peut faire. C'est finalement, ce qui m'arrive régulièrement, c'est que c'est du coaching parce que c'est personnalisé aux besoins et à la situation du client. Je fais beaucoup de coaching comme ça. J'ai même partenaire avec un éditeur de produits FinOps. Et je travaille avec eux pour leur donner cette vision métier qu'ils ont. qu'ils ont, mais qu'ils ont besoin de voir évoluer parce qu'ils développent dans leur coin. Et ils ont besoin d'avoir ce lien avec quelqu'un du terrain. C'est bien ce qu'ils font. Tout le monde ne le fait pas. Mais vraiment, ce qui marche aujourd'hui, quelques formations ne sont pas à mettre de côté, mais c'est du coaching. Parce que vraiment, on se retrouve avec des personnes qu'on doit écouter, qu'ils ne me défendent d'oléance, qu'ils ne comprennent pas ce qui se passe, et on doit leur dire, attends, calme-toi, je t'écoute, je suis à ta disposition, et on va discuter ensemble des solutions qu'on a ouvertes. Et on va voir si on en garde certaines, si on en a juste d'autres. Donc je t'écoute, on travaille ensemble pour trouver quelque chose qui va convenir et que tu pourras justifier.
- Speaker #1
C'est ça. Et finalement, tu vois, j'ai lâché le mot agile. Il fait une transition sans le vouloir. Tu es aussi agilopathe. Donc, qu'est-ce qui ne marche pas avec les méthodes agiles dans les entreprises et pourquoi, à ton avis ? Et c'est quoi un agilopathe ?
- Speaker #0
Déjà, effectivement, je suis aussi agilopathe parce que je dors. pas bien la nuit, donc il faut bien apprendre des choses. Encore un peu. Oui, mais plus sérieusement, en fait, ça m'a beaucoup aidé dans toutes mes missions. Parce qu'à l'origine, l'agilité, c'est basé sur un principe simple, c'est du bon sens. C'est d'être capable de changer de direction si on s'est planté, c'est d'accepter de se planter rapidement, le fait qu'il fasse ce genre de choses-là. Et après, il y a différentes organisations et des cadres de travail. En fait, ce que je vois, c'est que les cadres de travail, les fameux frameworks sont intéressants et sont... Souvent, bien fait, bien pensé, mais c'est assez difficile finalement de faire correspondre une entreprise avec les personnes, avec sa culture et tout ça, et de les faire rentrer un petit peu au forceps dans un cadre. C'est ça qui se passe. En fait, ce que je vois, sans critiquer gratuitement, c'est qu'il y a certains frameworks. Moi, je pense qu'on devrait utiliser une partie. Il y a des choses qui sont très bien faites et qu'on devrait lâcher le reste très simplement. Il y a des grosses entreprises qui vont utiliser certains frameworks et qui vont absolument mettre en place le vocabulaire et les instances et une sorte de gouvernance. Mais en réalité, l'agilité, quand on va vraiment au bout de l'agilité, on voit qu'il y a des niveaux de management qui ne sont pas nécessaires. L'agilité va prôner les gens avant tout le reste. Et finalement, normalement... on va vers l'autonomie et la responsabilisation des personnes et quand on a des managers qui ne veulent pas lâcher qui disent c'est moi qui décide tu fais ça malheureusement c'est ça donc en fait l'agilopathe dédicace à mise c'est une maladie c'est pas une maladie non Non, non, ce n'est pas une maladie. C'est justement une idée qu'on va aider les entreprises à se soigner grâce à leurs propres ressources. Donc, on va aller interroger, travailler avec les personnes, pour qu'ils restent ce qu'ils ont en eux, d'accord ? Et aider à, entre guillemets, soigner l'organisation en étudiant les tendances des personnes et l'organisation elle-même. Parce que des fois, le cadre fait qu'on ne se sent pas bien, fait qu'il y a des choses qu'on garde à l'intérieur. Voilà, et ça, en fait, ça permet d'avoir, ça va chercher ailleurs aussi avec la communication violente, ce genre de choses-là. Et en fait, l'idée, c'est vraiment d'être à l'écoute, d'avoir une posture qui permet d'avancer sans jugement. Sans jugement, l'idée, c'est vraiment que si on en a au début, on a encore ce réflexe, de le garder pour soi, faire la poker face. se dire bon bah ok non mais ça commence comme ça et puis après au bout d'un moment le jugement on l'a plus puisqu'en fait on se met à la place de l'autre et on essaie de comprendre ces difficultés et c'est associé à des principes qui sont très très vieux on applique aux enfants Montessori le docteur qui a travaillé sur tout ça en fait toute la pédagogie en fait qu'il y a derrière L'agilopathe va utiliser un petit peu ce qui a été proposé par le docteur Maria Montessori. D'ailleurs, aujourd'hui, quand vous allez voir sur le site de l'agilopathe, on propose Montessori Extended, ça veut dire étendu aux entreprises, aux adultes. Et vraiment ça, en fait, ça me permet, moi, en tant qu'architecte, d'éviter de rentrer dans une case et de me mettre dans la posture où j'écoute. vraiment beaucoup les autres, et j'aime beaucoup écouter, bon là je parle, mais j'écoute beaucoup, pour proposer des solutions et de me mettre aussi en doute, parce que moi aussi je peux me planter quand je propose quelque chose. Oui, oui, oui.
- Speaker #1
Moi c'est ce que je dis à mes clients, je n'ai pas la vérité. Eh oui. Au fil des ans, quand j'étais plutôt tech, je disais, c'est moi l'expert, enfin je ne le disais pas comme ça, mais c'est moi l'expert, j'ai la vérité. et donc je te dis de faire ça parce que je sais que l'application de telle commande fait ça, tel résultat mais je pensais pas business, donc oui je continue à dire que j'avais la vérité la différence c'est qu'aujourd'hui en ayant fait différentes analyses de risques au fil des ans je propose plusieurs vérités et c'est le business qui choisit la meilleure vérité et la vérité peut être vue à intervalles réguliers, donc ça je te parle des risques mais la vérité peut être vue parce que Ça ne correspond plus au business. Et tout ça peut évoluer. Donc, je suis plus prudent en disant, finalement, moi, je suis là pour apporter des solutions, pour les aider, pour être facilitateur. Et ils pourraient très bien venir avec autre chose. Je l'ai encouru cette semaine avec un client qui voulait... Je parle un peu RGPD ici. Il voulait absolument mettre les photos des personnes avec nom et prénom. ou même ne pas les photos des personnes, mais uniquement nom, prénom, fonction sur le site web. Et directement, j'ai réagi. Attention, est-ce que les personnes sont au courant ? Oui, non. Après, ce n'est pas avec moi qu'il va y avoir des soucis. et puis on en a discuté avec le DPO, le délégué à la protection des données, où cette personne-là voyait d'autres risques. Moi, je dis que je m'en fiche, je ne suis pas là pour bloquer. Par contre, si tu me mets des gens, et admettons qu'ils soient d'accord, qu'ils ont donné leur consentement positif et éclairé, et tu mets des gens sur le site, moi, je dois mettre à jour mon joiner mover lever parce que je peux te mettre un bot sur ton site, je sais que telle personne est arrivée, je sais que son adresse mail, c'est comme ça. Bam ! Premier jour, je lui envoie un phishing. Donc je pensais comme ça. Et la personne pensait dans son coin en silo. Ah, je n'ai pas vu ça comme ça. Je dis non, c'est pour ça qu'on a un comité de direction. Pour prendre les projets dans le comité de direction et que chacun, chaque expert autour de la table dans son métier vient dire moi je pense à ça, je pense à ça, vous êtes d'accord. On gère le risque entre adultes derrière. Et puis derrière, je lui ai expliqué, je dis tu vas comme ça, je vais considérer que c'est bon et que ça va être accepté. Je tune 4-5 documents. et voici le risque, et voici la mitigation qu'on met. Et moi, ça me va, c'est son business, c'est lui qui a décidé. Et au début, cette personne-là me prenait en grippe parce qu'elle me dit, tu bloques. Je ne bloque rien du tout.
- Speaker #0
Pas du tout.
- Speaker #1
Je t'explique les risques que moi, je vois. Et peut-être que ce ne sont pas des risques qui vont être acceptés au Codire. Il y a des fois, je présente des risques au Codire, ils me disent, avec quoi tu viennes ? Je dis, OK, voilà. Mais je continue à dire, même quand je ne suis pas d'accord, on peut très bien ne pas être d'accord et s'apprécier et c'est à eux de me dire oui mais ça ça n'arrivera jamais OK. Parce que si je suis là et qu'ils me prennent comme consultant et que je ne dis plus rien, je sers à quoi ?
- Speaker #0
Voilà. Oui, il est là le souci. C'est vrai que notre boulot, c'est de parler. C'est de dire quand il y a quelque chose qui nous semble un peu bizarre et d'expliquer. Après, si on dit non et qu'on a pris en compte, c'est bon. Mais si on se dit finalement, on ne dit rien, là, ça pose un problème. Effectivement, je pense que on a besoin juste... justement, d'assainir cette communication et assainir la communication, et ça c'est intéressant pour la communication non-violente aussi, c'est de dire ce qui doit être dit. C'est-à-dire que ça peut être perçu comme violent, mais on le dit pour l'autre.
- Speaker #1
Il faut que l'autre... Il faut le faire. Ne le prenne pas de manière personnelle parce que ça peut blesser certaines personnes, ça peut blesser leur égo. Donc il y a des choses que je sais que je vais dire avec la personne, parce qu'au fil des ans, on devient psy aussi. Je ne suis pas psy, loin de là,
- Speaker #0
mais tout ce qui est CNV,
- Speaker #1
donc communication non-violente, PNL, tout ça aide beaucoup à justement faciliter. Alors les méchants, les détracteurs diraient qu'on est des manipulateurs, mais ce n'est pas de la manipulation, mais il faut quand même bien comprendre comment les personnes fonctionnent pour réussir à les faire aller dans la direction. et envie, par rapport à laquelle il y aura moins de heurts, on ne va pas les blesser. Ceux qui prennent tout systématiquement au pied de la lettre, j'ai appris à travailler avec eux. Je sais que je ne vais pas leur écrire un mail. Je vais d'abord aller leur en discuter et leur expliquer pourquoi ils vont recevoir le mail. Pourquoi tu m'as envoyé un mail ? Parce que j'ai besoin d'une preuve d'audit. J'ai fait ça. J'ai fait ça avec un... Je lui ai dit, écoute, j'ai besoin de revoir tel process avec toi, je dis ne t'inquiète pas. pas, on le revoit, tu me dis quand tu veux. Je dis, je t'envoie une invitation avec ça et ça et ça. J'ai ma preuve d'audit, on a revu le process. On a d'abord revu le process ensemble. Et donc, je lui ai expliqué, avec une autre personne, je vais faire autrement. Donc, je m'adapte. Je suis un caméléon. Et... C'est un peu ça. On est dans un métier qui, globalement, on ne fait pas que de la technique. Merci Eric pour ta participation et j'espère que cet épisode pourra susciter des vocations et des reconversions.
- Speaker #0
Merci Fabrice pour l'invitation, ça me fait plaisir parce que je suis le podcast depuis le début, on travaille ensemble depuis longtemps.
- Speaker #1
Un fan !
- Speaker #0
Je suis fan, avant même le podcast j'étais fan, donc c'est un honneur pour moi.
- Speaker #1
Et donc à toi qui nous écoute, si tu pensais que les architectes ne pensaient que technique, maintenant tu sais. Tu sais qu'il faut une bonne dose de jugeote, de psycho, de pragmatisme et de réalisme pour maintenir une infra, je veux dire, digne de ce nom, qui soit cyber-résiliente. On se retrouve très vite pour d'autres épisodes, d'autres invités. En attendant, à vendredi prochain.
- Speaker #0
Salut ! Salut, merci.
