Le FinOps vu d'un.e SRE

0:14 Bonjour à toutes et à tous. Je vais commencer par passer la parole à Arthur et à François pour nous présenter avant de rentrer dans le vif du sujet. Donc Arthur. Oui, bonjour. Du coup, ça ne tombera pas plus bas. Du coup, moi, c'est Arthur. Je suis SRE chez Pigment. Pour ceux qui ne savent pas ce que ça veut dire, SRE, c'est Site Reliability Engineer, ce qui veut grosso modo dire que je suis un dev qui s'occupe beaucoup de l'infrastructure et que mon principal focus, ce n'est pas forcément de livrer des nouvelles fonctionnalités, mais plutôt que de m'assurer que la plateforme dans son ensemble marche bien tout le temps. Après, tout le temps avec une astérisque, si vous savez ce que c'est le SRU, vous savez ce que je veux dire. Et du coup, moi je suis là pour vous parler de mon expérience quand j'ai fait du FinOps, notamment chez Pigment. J'en avais fait un peu dans mon ancienne boîte, mais chez Pigment c'était différent. Je trouve qu'on a pris une approche qui marche bien. Et du coup, je suis là pour faire ce retour d'expérience. C'est à moi, bonsoir, je m'appelle François Pasquet, je suis Technical Account Manager chez DeWitt.

1:18 DeWitt, c'est un partenaire AWS et GCP. Moi, j'ai commencé ma carrière, j'étais dans l'armée de l'air, j'ai fait 15 ans d'armée. Je travaillais dans les systèmes embarqués dans les avions. Ensuite, je me suis reconverti. J'ai travaillé chez Thales et puis je suis arrivé à un moment chez AWS. Et c'est là où j'ai découvert le rôle de Technical Account Manager. Donc j'ai fait ça pendant deux ans. Et ensuite, je suis allé chez Dewey. Voilà. Et donc, ce soir, c'est aussi mon point de vue que je vais apporter sur la FinOps au travers de mes expériences et de mon regard de technique account manager et de mes interactions que j'ai eues avec mes clients et des expériences que j'ai eues avec eux aussi. Voilà. Alors moi c'est Katia, je suis CTO et cofondatrice de Cockpit.io. Nous sommes une entreprise spécialisée dans l'accompagnement autour des sujets cloud et DevOps. Nous avons du build, du conseil et des formations.

2:21 Sinon moi j'ai commencé en tant que développeuse qui a toujours fait de l'infra. AWS ça fait une dizaine d'années que je pratique, ça fait 7 ans aussi que je fais du consulting et j'ai eu l'occasion durant ces années de consulting de voir des organisations et des entreprises de différents types et de différentes tailles. Et c'est aussi cette expérience-là que j'ai voulu aussi partager avec Arthur et François. Alors, première question, on va tous y répondre. Quels sont les avantages et les opportunités du FinOps? Je te passe la main en premier, François, pour nous donner aussi la définition du FinOps. Oui, parce qu'on s'était mis d'accord. Quand on s'était vu la semaine dernière, on s'est mis d'accord sur une définition. Parce qu'en fait, on n'avait pas les mêmes points de vue. Et donc, on a trouvé une définition tous les trois, que je vais vous partager tout de suite, parce que comme ça, ça pose les bases aussi des questions et en tout cas de ce dont on va parler après. C'est une pratique qui vise à instaurer une responsabilité financière au coût variable du cloud.

3:24 Elle repose notamment sur la collaboration et l'utilisation d'un langage commun entre les équipes, permettant de trouver un équilibre entre le coût, la performance et la qualité. Ça, c'est notre définition. Maintenant, les avantages. Alors, de mon point de vue, les avantages, et notamment par rapport aux échanges que j'ai avec mes clients, c'est de pouvoir trouver une gouvernance, de trouver un modèle de rentabilité. Tout dépend bien sûr de la maturité de l'entreprise à laquelle je suis confronté. Maintenant, quand on parle de FinOps, tout de suite, on voit, on pense réduction des coûts. Mais ce n'est pas que ça, en fait. Ce n'est pas« je vais faire des économies». Ça en fait partie, mais c'est aussi une méthodologie, c'est aussi une pratique. Qui permet justement de trouver les leviers et de faire travailler les personnes entre elles.

4:26 Et surtout, comme on le dit dans la définition, d'avoir un langage commun. Parce que les gens des OPS et les gens des finances qui discutent ensemble, parfois ils ne se comprennent pas. Et donc, avoir une personne qui puisse faciliter les échanges et qui puisse faire en sorte que tout le monde se comprenne, c'est aussi un avantage du FinOps, c'est de pouvoir introduire ce genre de profil dans les entreprises qui permettent, sur une longue durée, en tout cas, moi, c'est ce que j'essaye de faire, d'aider aussi à la stratégie, à implémenter une stratégie, et à pouvoir... Je me suis perdu là, pardon. C'est vraiment aider à mettre en place les outils, à trouver des automatisations, à trouver des moyens pour pouvoir dépenser correctement.

5:27 C'est pour moi, en tout cas, les avantages que je vois dans la FinOps. Et toi Arthur ? En moi, les avantages que je vois dans le FinOps, c'est que ça permet d'améliorer son application. Moi, je dis ça en tant que personne qui construit une application. Et ce que j'entends par améliorer, c'est s'assurer que l'application répond aux objectifs de son entreprise. Parce que sinon, ça ne sert à rien. Je pense qu'on sait tous que le DevOps, le principe, c'est de permettre une meilleure collaboration entre les équipes de développement et les équipes opérationnelles. La manière dont je vois le FinOps, c'est qu'en fait, c'est à peu près la même chose. Pour moi, il y a vraiment une parallèle. En fait, ça sert à rapprocher et à faire collaborer les équipes financières avec les équipes techniques. Alors malheureusement le mot FinTech était déjà pris, donc on est parti sur FinOps, mais je pense que pour moi on l'a appelé ça FinOps parce que clairement c'est un clin d'œil au DevOps.

6:28 On va y arriver avec ce cahier. Et en fait pourquoi le FinOps c'est important? Parce qu'en fait avec le cloud, le coût il a changé comparé au bare metal. C'est pas du tout la même chose. En fait on utilise ce qu'on veut et on paye à la fin du mois. Et en fait, pour les ingénieurs, c'est beaucoup plus pratique, c'est sûr. Mais pour les équipes financières, en fait, c'est très déroutant. Avant, un CFO, il allait signer un devis. Maintenant, il signe une facture. Et c'est quand même pas la même chose. Ce qu'il faut comprendre surtout, c'est que cette facture-là, elle est complètement inscrutable. Elle arrive sur le bureau du CFO. Il ne comprend rien. Donc il demande au CTO, qui la regarde, qui ne comprend rien non plus, qui se tourne vers un CRE qui ne comprend rien non plus. Et en fait, le FinOps, pour moi, pour bien faire du FinOps, et c'est surtout là l'avantage de la méthodologie, c'est qu'en fait, il faut passer outre la facture, il faut aller regarder les données de facturation brutes. Il faut aller se dire, c'est quoi la base de données qu'utilise le cloud provider quand il me dit qu'il m'a facturé telle machine tant de minutes? C'est ça qu'il faut aller regarder.

7:29 Et en fait, en corrélant ces données-là d'utilisation du cloud avec notre utilisation, du cloud. En fait, on prend une approche data-driven qui nous permet de mieux comprendre les coûts de notre application et du coup de faire évoluer notre architecture intelligemment. Parce qu'en fait, si votre architecture, elle pousse votre boîte à la ruine, vous n'avez pas construit une bonne application. C'est éclairer la décision. Exactement, c'est ça. Au quotidien, on continue. Et en fait, l'amélioration continue. Aujourd'hui, toutes les organisations d'ingénierie, c'est ce qui les fait fonctionner. Moi, je pense que je vous rejoins. Pour moi, le FinOps, ça donne vraiment un cadre pour établir une transparence parce que pendant de très nombreuses années, le sujet des coûts des infrastructures était tabou. Donc il n'y avait qu'une petite poignée de personnes qui savaient combien coûte une infra. Là, on parle d'infrastructure. Par contre, en tant qu'ancienne dev ou quand on est dans l'équipe technique, on a été nombreux à avoir entendu« ça nous coûte cher, ça nous coûte cher», mais sans spécialement avoir le contexte entier pour savoir qu'est-ce qui coûte cher réellement, pourquoi ça coûte cher et ça coûte cher par rapport à quoi.

8:37 Donc il y a ça, ce premier sujet-là. Le deuxième point, c'est que la promesse du cloud, c'est de réduire les coûts par rapport à une infra on-prem. Donc ça, c'est une des promesses qui est faite par le cloud. Mais la réalité, c'est que comme on a le clic facile, donc on a les ressources qui sont à disposition, Parfois, on se rend compte que pas du tout. Quand on va sur le cloud, cette facilité-là d'avoir des accès, de changer de type de ressources, d'avoir des choses en plus, on perd un peu la maîtrise. Donc le FinOps, ça permet d'avoir un cadre pour pouvoir bénéficier de cette promesse-là. Et puis, ça permet aussi d'avoir des données, d'extraire des données, de nouvelles données pour prendre des décisions business ou techniques, savoir est-ce que quelque chose est rentable ou pas, est-ce que ça vaut le coup d'investir dans ces choses-là. Ce n'est pas spécialement, ça ne va pas à l'encontre de l'innovation, l'idée ce n'est pas là, c'est vraiment d'avoir la maîtrise de... de ses coûts. Et puis ça permet aussi à des entreprises qui se lancent de gagner en compétitivité.

9:39 Je rejoins un peu ce que dit Arthur. Si on a une infrastructure qui coûte extrêmement cher et qu'on n'est pas rentable et qu'on ne sait pas optimiser ses coûts, ça peut aussi devenir problématique pour la viabilité des entreprises. Donc ça, c'est pour moi la... Trouver les métriques. Exactement. Dégager un modèle de rentabilité derrière. Voilà. Donc ça, c'est pour les avantages et les inconvénients. J'ai une question pour toi, Arthur. D'après ton expérience en tant qu'assero, tu as parlé notamment de ce que tu fais chez Pigment. Quel conseil donnerais-tu à une entreprise qui souhaite mettre en place cette approche? Collaborer. Collaborer et encore une fois collaborer. En fait, comme pour le DevOps, l'objectif c'est de casser les silos. Enfin, c'est pas l'objectif. L'objectif, c'est de ne pas ruiner la boîte. Le moyen, c'est de casser les silos. Je vais essayer d'expliquer mon raisonnement, comment j'en suis arrivé à cette conclusion-là. Là, en gros, on parle du coût d'une application.

10:42 Et en fait, le coût d'une application, il se divise en trois morceaux. Il y a le coût d'implémentation, ce que vous payez les ingénieurs pour le faire. Il y a le coût de maintenance, donc ça c'est ce que vous payez les ingénieurs pour maintenir votre application. Et il y a le coût d'exploitation, ce que coûte votre application à tourner. Le FinOps, en fait, ça se concentre beaucoup sur les coûts d'exploitation. Ça ne veut pas dire que, même si on veut réduire ces coûts-là, ça ne veut pas dire qu'il faut qu'on économise 10 000 euros sur les coûts d'exploitation, mais que ça nous coûte 30 000 euros en coûts de maintenance. Parce que sinon, vous allez avoir un problème, vous n'avez rien gagné. Donc on ne peut pas ignorer les autres coûts pour autant. Mais du coup, si on se concentre sur les coûts d'exploitation, il y a un exemple hyper intéressant, je trouve, c'est Amazon Prime Vidéo. Vous avez peut-être vu passer ça dans les journaux il y a quelques mois. En gros, ils ont complètement refondu un de... dans leur service. Je ne sais plus ce qu'ils faisaient, je crois qu'ils faisaient l'encoding vidéo ou un truc comme ça. Pour ceux qui ne savent pas, Prime Vidéo, c'est un concurrent de Netflix. Et en fait, ce qu'ils ont fait, c'est qu'ils sont partis d'une architecture de microservices qu'ils avaient avant, et ils ont tout refait, et ils sont partis sur une architecture monolithique.

11:46 Et le résultat, ils ont fait un retour d'expérience là-dessus, le résultat c'est que le service maintenant il est plus scalable, il est plus résilient et il est moins cher. En fait ils sont revenus même parce qu'ils étaient partis sur du serverless et au final ils ont fait le chemin inverse de beaucoup. Oui, c'est ça. Exactement. Genre là où beaucoup de gens commencent avec une application qui tourne sur un seul serveur, puis après se disent, attends, il me faut plein de serveurs et je pars sur Lambda. Eux, ils ont commencé avec Lambda et les step functions, et ils sont revenus sur une architecture monolithique. Et en fait, ce qu'il faut comprendre, du coup, c'est que cette implémentation-là, ce refactoring, en fait, il aura coûté du temps, du temps d'ingénieur, donc de l'argent. Mais maintenant, ils ont moins de maintenance et les coûts opérationnels sont moindres. L'application compte littéralement moins cher à la minute, ce qui est quand même cool. Et là-dessus, il y a beaucoup de gens qui ont parlé de cet article-là et il y en a beaucoup qui s'en servaient pour se dire« Ah, je vous avais bien dit, les microservices, c'est nul». Et en fait, non, ce n'est pas ça la morale. Ce n'est pas ça la morale pour moi.

12:48 Est-ce que c'était une erreur pour Amazon Prime, l'équipe Amazon Prime de vidéo, de faire une architecture microservice? Non, en fait, parce que ça leur a permis de développer leur application beaucoup plus vite. Ça a permis à leurs ingénieurs... d'être beaucoup plus efficace, d'ajouter un maximum de fonctionnalités et de faire concurrence à quand même un géant de la tech. Et du coup, ils ont pu prendre une plus grosse part de marché. Maintenant que le marché s'est un peu stabilisé au niveau du streaming, et qu'il y a plus de concurrence, et qu'il n'y a pas une croissance à deux chiffres tous les ans, les besoins d'ajouter des nouvelles fonctionnalités en continu sont moindres. Et maintenant, il faut réduire les coûts. Et du coup, c'est pour ça que les objectifs de l'organisation ont changé, et du coup, l'architecture de l'application a changé en réponse. Du coup, souvent, maintenant que j'ai fait ce petit aparté, souvent quand une entreprise se dit « je veux faire du FinOps », ce qu'ils se disent, ils prennent un raccourci, en fait, et qui n'est pas bon. Du coup, le raccourci, c'est, on se dit, mon objectif, c'est de réduire mes coûts d'infra.

13:50 Le SRE connaît bien l'infra. Donc le SRE va s'occuper du FinOps. Super. Et en vrai, on peut voir la logique, mais il y a un problème. En fait, le souci, c'est que, et je me suis retrouvé dans cette situation, c'est qu'en fait, quand son CTO vient voir un SRE et lui dit, tu vas t'occuper du FinOps, tu vas faire du FinOps maintenant, voici la facture AWS, on se revoit dans deux semaines. Le CRO est face à un problème qu'il ne sait pas analyser et qu'il ne sait pas résoudre. Et pourquoi? Parce qu'en fait, le FinOps, ce n'est pas un sujet d'infra. C'est un sujet d'architecture. Et c'est ça qui est très différent. C'est une nuance qui est quand même importante. Si on se concentre seulement sur l'infra, on applique des solutions génériques. Donc par exemple, on va supprimer une VM qui traînait depuis longtemps, et ça a de la valeur. Ou alors on va utiliser des solutions comme FlexSave, qui sont super, mais qui sont génériques en fait. Il n'y a rien de spécifique à notre application dans ces solutions-là. Donc je prends un exemple. Si par exemple je découvre en étudiant ma facture qu'il y a mes buckets qui représentent 30% de ma facture cloud.

14:56 Bon, en tant que SRE, je fais quoi? Je supprime le bucket? Ben non. Donc, en fait, en tant que SRE Sol, moi je ne peux pas savoir pourquoi nos buckets représentent 30% de la facture, et je ne peux surtout pas savoir si c'est trop, si c'est trop peu, ou si ça se trouve, nos devs ont hyper bien optimisé, et ça aurait pu être 80%, je ne peux pas savoir. Et en fait, il faut comprendre l'utilisation que l'application... Fait des services cloud, et du coup, quels aspects de cette utilisation sont plus chers qu'ils ne devraient l'être. Donc du coup, bien faire du FinOps, c'est corréler les données de facturation brute avec l'utilisation qu'on fait de ces services. Et du coup, ça veut dire qu'en fait, si vous voulez faire du FinOps, il vous faut quelqu'un qui comprend les services cloud, c'est pour ça qu'on se tombe vers la SEO en général, qui comprend le fonctionnement de votre application, Si votre application est simple et que le SRE est là depuis le premier jour, peut-être qu'il comprend bien votre application, mais si votre application a la mûrie, votre organisation a la grossie, le SRE, il y a plein d'aspects de l'application qu'il ne comprend pas.

15:58 Et il faut quelqu'un qui est capable d'analyser les données brutes, mine de rien c'est un skill, et c'est un skill qu'un SRE n'a pas forcément. Et il faut aussi quelqu'un qui a une vision d'ensemble sur l'organisation, qui a des contacts avec les équipes financières, qui savent quels sont les enjeux, etc. Qui savent que la facture cloud représente X% du chiffre d'affaires, donc du coup c'est bien, pas bien, voici comment les courbes évoluent. Qui parle le langage des cloud providers aussi, qui comprend les pricing models. C'est ça, exactement. Du coup, si vous êtes dans une petite organisation, une petite boîte, une petite start-up, Peut-être que vous avez quelqu'un qui coche toutes ces cases. Vous avez quelqu'un de polyvalent qui est capable de faire tout ça tout seul. Mais le fait est qu'en fait, si vous êtes dans une organisation un peu plus grosse, plus mature, où en fait les rôles sont bien plus spécialisés, en fait vous n'allez jamais trouver une seule personne qui sait faire tout ça. Et donc du coup vous avez besoin de mettre en place une équipe transverse. Et c'est pour ça qu'il faut casser les silos, c'est pour ça qu'il faut collaborer. Parce qu'en fait un SRE seul ne peut pas y arriver, un dev seul ne peut pas y arriver, un data analyst seul ne peut pas y arriver, et l'équipe financière seule ne peut pas y arriver.

16:59 Donc du coup il faut que tout le monde collabore. Je donne un exemple comme ça d'équipe transverse. Vous pouvez prendre par exemple un SRE qui connaît bien les services cloud que vous utilisez, il connaît bien l'infrastructure. Vous prenez un dev qui connaît très bien le fonctionnement de l'application et l'utilisation des services cloud, parce que c'est lui qui tape sur les API. Vous prenez un data analyst, par exemple, si vous en avez, qui est capable de prendre de la donnée brute, de la transformer, d'en extraire des insights comme personne, parce que c'est son métier. Et vous prenez un engineering manager, par exemple, qui a une vision d'ensemble de votre organisation technique, mais aussi du reste de votre entreprise. Parce que ce n'est pas qu'un problème technique. Et je conclue en disant, quand vous formez cette équipe, c'est important qu'elle ait un objectif clair. Alors du coup, je l'ai noté. L'objectif de cette équipe, c'est de permettre à toute l'organisation de mieux comprendre les coûts d'exploitation de l'architecture actuelle. Une fois que vous les comprenez, ces coûts, et surtout que tout le monde les comprend.

18:02 Ce n'est pas juste l'équipe infra qui les comprend, ce n'est pas juste les devs qui les comprennent, tout le monde les comprend, y compris l'équipe financière. À ce moment-là, vous allez pouvoir collaborer avec un vocabulaire commun, avec une approche data-driven, pour améliorer votre architecture, pour qu'elle aille dans la bonne direction. Autre question pour toi, François. Quels sont les types d'entreprises qui viennent te voir pour mettre en place l'approche FinOps et quels conseils donnerais-tu aux autres? Le profil des entreprises est assez varié. Ça peut aller de la start-up à la scale-up, en passant par des structures plus importantes. Maintenant, ça ne veut pas dire que les structures les plus importantes ne sont pas forcément celles qui sont les plus avancées, qui sont les plus matures, en tout cas dans la méthode FinOps. Souvent, le premier déclencheur, c'est« Ok, on dépense trop, il faut qu'on réduise là». Là, la facture est trop grande, il faut qu'on trouve des leviers.

19:07 Il faut que dès le mois prochain, on ait du résultat, il y a une pression du CFO. Et donc là, on va aider tout de suite. En fait, c'est un accompagnement à la carte. Donc on va faire des ateliers d'optimisation de coûts, où on va avec eux regarder un petit peu leurs usages. De manière proactive, on va aller analyser leur dashboard et leur donner des insights sur... Peut-être que tu parlais des buckets, mais il y a beaucoup de boîtes qui ne mettent pas de lifecycle policy. Ou s'ils ne connaissent pas les patterns d'utilisation de leurs données sur les buckets, ils ne connaissent pas, par exemple, sur WordVest, il y a Intelligent Tearing. Ils ne vont pas utiliser ce genre de service. qui certes ont un coût, mais ça peut donner quand même des pistes après derrière pour faire plus d'optimisation. Et donc, on a ce genre d'accompagnement.

20:10 On a aussi des entreprises qui viennent nous voir et qui déjà ont une bonne vision de leurs dépenses. C'est-à-dire qu'ils ont déjà construit des dashboards, ils ont leur tooling d'analytics, ils ont déjà tout ça. Maintenant, c'est plus dans l'évangélisation, j'allais dire, entre guillemets, des équipes, à savoir, OK, comment faire en sorte que tout le monde aille dans le même sens, comment faire en sorte que tout le monde participe en fait à cet effort. Et bien souvent, le challenge, il est là, en fait. Trouver la porte d'entrée parce que le challenge du synopsis c'est qu'il faut qu'il soit crédible auprès des deux côtés donc il faut qu'il soit un peu tech donc quand ils vont parler au tech il faut pas que les techs le renvoient balader en disant tu comprends rien et puis en même temps quand ils parlent aux finances il faut aussi qu'il ait les bons mots, les bons éléments de langage

21:11 Donc la difficulté, en fait, elle est là. C'est de trouver cet équilibre et de pouvoir mettre tout le monde autour de la table et d'adopter justement ce langage commun. Alors en fait, ce langage, il faut le décorréler aussi du langage trop tech ou trop finance. Tout le monde sait ce que c'est que le right sizing, tout le monde sait ce que c'est qu'un coverage, tout le monde sait ce que c'est qu'un commit. Donc à partir de là, on peut commencer à trouver la bonne manière de travailler, de collaborer. La deuxième partie de la question, c'était... Quel conseil tu donnerais à celles qui n'adoptent pas encore cette approche? Parce que dans ce que je vois, il y en a beaucoup qui sont réfractaires, qui n'aiment pas beaucoup cette méthode. Et quand à la fin des workshops qu'on fait, on leur dit« mais en fait, vous avez fait de la fin-up sans vous en rendre compte, parce que les phases, il y a les cycles inform, operate, optimize.

22:17 Tout ça, ça paraît un peu abstrait. Et dans le niveau de maturité où il faut commencer, parce que dans la méthode d'eau, si vous allez sur finos.org, vous allez voir crawl, walk, run. Enfin voilà, c'est des étapes en fait. Par lesquels il faut, je pense, passer pour pouvoir avoir une bonne pratique de la FinOps. Quand on leur dit qu'ils ont déjà des roucans, juste en travaillant, en regardant comme ça, en faisant ces workshops, ils ont déjà déroulé un cycle de... Ils sont convaincus après, de se dire, ok, c'est comme ça qu'il faut qu'on continue, c'est comme ça qu'il faut qu'on fasse, parce qu'on se rend compte qu'on se rend compte On se rend compte que c'est efficace, on se rend compte qu'à la fin, effectivement, on voit le résultat. Là, on a regardé parce que finalement, l'équation, le coût du cloud, il est porté par l'usage multiplié par le taux.

23:18 C'est juste ça, en fait. Mais qui va porter les optimisations sur l'usage? C'est plus le CRO parce qu'il faut décentraliser cette partie-là. Qui va porter le coup sur le taux? Là, c'est plus le FinOps. Donc là, oui, c'est bien d'avoir une équipe centralisée. Parce que ça prend quand même du temps. Parce que quand... Quand AWS a sorti le Cost Usage Report, c'était quoi, en 2017, je crois? C'était pareil. Eux, ils ont fait crawl, walk, run. Au départ, la facture, c'était juste une facture comme ça. Il n'y avait rien dedans. Et puis, petit à petit, ils ont itéré et c'est devenu... C'est devenu un inventaire avec 200 000 lignes. Voilà. Après, c'est l'épreuve de l'orientation pour trouver des infos. Exactement. Et plus on va dans la granularité, et plus c'est difficile. Et c'est pour ça qu'il faut avoir des gens qui savent lire, qui savent interpréter ce genre de données, et qui puissent aller expliquer derrière aux équipes tech, OK, là,

24:24 tu as dépensé, tu as fait ça, ça a eu comme conséquence sur la facture. ce mois-ci, parce que c'est bien de le faire aussi tous les jours. Il faut aussi monitorer tous les jours. Quand on a des cost-anomalies, quand on a des... Justement, la réactivité que procure la FinOps, c'est de ne pas laisser courir un... Je ne sais pas moi, un mauvais usage, quelqu'un comme tu disais, quelqu'un clique, c'est facile, tu pop une instance. Mais si tu la laisses courir pendant un mois, à la fin, le cloud, c'est plein de petites choses qui s'accumulent et qui, à la fin, font un montant. important. Le fait de pouvoir avoir un outil de détection qui peut regarder, analyser les patterns d'utilisation, qui va dire« Ah, là, on sort du pattern, c'est peut-être un truc de pas normal. » Là, j'ai eu le cas hier sur un client qui s'est fait hacker C'est fréquent. C'est fréquent. Donc, ils avaient hard-codé leurs clés.

25:29 Ils ont eu 1000 dollars de ces deux en peu de temps. Ça a déclenché l'alerte. Et en fait, c'était... Alors, ce n'était pas pour faire de la crypto. Non, pour une fois, c'était pour faire du spam. Donc, c'est la FinOps. Et en tout cas, moi, ce que je conseille de faire, c'est au départ, le premier truc, la base, c'est le tagging. Ça, c'est une des premières choses. Alors, ça ne va pas forcément... Il y a des gens qui ne s'intéressent pas. Il y a des boîtes dans les FinOps. Nous, non. De toute façon, on gagne beaucoup d'argent. On n'a pas forcément envie maintenant de passer du temps à comprendre les modèles de prix. On n'a pas forcément le budget aussi non plus. Pour engager un FinOps, on embauche des développeurs, on embauche des CRU, on embauche des DevOps. Donc la FinOps, on va la laisser.

26:30 de côté, et puis on y reviendra plus tard. Ça, je ne pense pas que ce soit le... Après, je ne dis pas la vérité, mais je ne pense pas que ce soit la bonne manière. Parce que si partir à faire du tagging au bout d'un certain temps, on accumule une des techniques, c'est de plus en plus difficile. Donc autant faire les choses faciles dès le début, même si on ne veut pas aller dans cette direction tout de suite. Au moins, on se donne la possibilité, on ne se ferme pas la porte, on se donne la possibilité de pouvoir l'utiliser après. Une des premières pratiques à faire, c'est ça, c'est le tagging, c'est commencer un petit peu à comprendre le coût, ce qui induise les changements, etc. Comprendre la donnée. Merci. Moi, j'aimerais juste compléter par rapport à mon expérience. J'ai eu l'occasion de travailler avec plusieurs entreprises qui n'avaient pas de profil ACRO, ni de profil spécialement OPS.

27:32 Donc, c'était des entreprises qui avaient des projets, des produits. Des équipes tech qui étaient exclusivement constituées de profils dev. Donc effectivement, le modèle cloud, ça donne cette facilité-là d'amener son produit rapidement, son MVP, son POC, très rapidement, d'avoir une infrastructure qui fonctionne et qui permet de montrer qu'on a quelque chose et d'itérer après. Donc dans ce cas-là, Le FinOps s'adresse aussi à ce type d'entreprise. Et c'est pour ça aussi, quand je dis que ce n'est pas uniquement une question de SRE, parce qu'on a aussi un grand nombre d'organisations tech qui sont un peu plus réduites, qu'il faut aussi amener vers cette approche-là. Elle commence à partir d'un certain moment, comme le modèle d'Amazon Prime Vidéo. Une fois qu'on a lancé le produit, qu'on est sur le marché, qu'on s'est fait connaître, qu'on commence à gagner des parts de marché, on commence à avoir du trafic. Et c'est là où la facture commence à devenir douloureuse. Surtout le trafic réseau. Exactement.

28:33 Justement, ces frais-là sont cachés en général, parce que dans les modèles de pricing, on va voir le temps. On parle de la WS, on va voir le coût d'une instance OC2 de ce type-là, coût de temps. Mais les frais réseau, ceux-là, sont généralement... Interzone. Exactement. Très souvent oubliés. Donc c'est là où c'est important aussi d'avoir des personnes qui sont expérimentées, qui maîtrisent le sujet, qui peuvent aussi nous aiguiller à comprendre les factures et à savoir s'il y a des axes d'amélioration. Donc moi, ce type d'entreprise, je les ai déjà vues de nombreuses fois. Effectivement, ce n'est pas qu'une question d'infrastructure. Ça, je vous rejoins, c'est une question d'architecture, d'architecture infra, d'architecture logicielle. C'est aussi des arbitrages à faire, à faire en connaissance de cause. Parfois, ça me coûterait beaucoup plus cher à optimiser que de laisser ça comme ça. Ça, ça dépend du contexte des entreprises, du budget qui peut être alloué. Il y a aussi un autre sujet, c'est qu'on vit dans un monde où il y a une tension sur les matériaux qui permettent de construire le matériel informatique.

29:38 Donc ça, c'est un élément qui fait que le coût, même sur le cloud, commence à devenir très cher. Il y a aussi l'énergie qui coûte de plus en plus cher. Donc même quand on est sur des cloud providers souverains ou S, très souvent on voit sur les réseaux les personnes qui découvrent les mails qui annoncent les augmentations de tarifs. qui commence à râler. Donc là aussi, ça amène les gens à réfléchir comment je peux réduire mes coûts. Donc ça, c'est un vrai sujet aussi. Et l'approche FINOP, ça permet aussi de pouvoir faire face à ces modifications-là, à ces changements-là. Donc même si mon trafic n'évolue pas spécialement beaucoup, peut-être que ces coûts-là vont avoir un impact très important sur ma facture finale, sur mon coût final. Ce n'est pas qu'une question de facture. Ensuite, il y a aussi le sujet d'usage responsable des ressources. C'est un non-sujet pour beaucoup, mais c'est un vrai sujet aussi.

30:39 On parle de Green IT, l'idée ce n'est pas de faire du greenwashing, mais d'avoir un usage responsable des ressources. L'approche FinOps aussi, c'est un des leviers qui permet de comprendre, en ayant vraiment toutes les datas qui arrivent, tous les dashboards, les beaux tableaux qu'on a, ça peut aussi être un vrai levier pour dire, on a la maîtrise, on comprend ce qui est bien utilisé ou pas. Tu parlais de right sizing, tout le monde sait que c'est une bonne pratique, mais est-ce que vraiment tout le monde est outillé pour voir si les ressources sont utilisées de manière efficace, optimale, etc. Donc ça, c'est un vrai sujet. Donc, c'est des sujets qui peuvent se rejoindre. Donc, l'un peut servir l'autre. Et puis... Il y a aussi, moi, ce que j'aime bien, c'est vraiment cette notion-là de transparence. Donc que l'idée du coup ne devienne pas un sujet tabou. parce qu'il y a des organisations qui n'aiment pas trop parler de factures, et qu'il y ait cette responsabilité-là qui vient très en amont de la chaîne de production d'une application.

31:41 Donc on implique aussi les développeuses et les développeurs, mais aussi les personnes qui réfléchissent aux produits, par exemple. Est-ce que c'est vraiment important, cette fonctionnalité-là, qui va devoir nécessiter tant? Est-ce que c'est important ou pas? Est-ce que c'est prioritaire par rapport à l'autre? Comme j'aime bien préciser, ce n'est pas au détriment de l'innovation. L'idée, ce n'est pas de se brider à tout prix, mais l'idée, c'est vraiment d'avoir tous les éléments, toutes les données en tête pour bien prendre les décisions, des décisions techniques, mais aussi parce que moi, j'aime bien aussi rappeler que les décisions techniques, elles sont là dans un intérêt business. Exactement. À part si on travaille dans une fondation ou un projet open source pour le fun, tout ce qu'on fait dans le cadre d'une entreprise, on le fait dans un intérêt business parce que notre intérêt aussi, c'est que l'entreprise soit viable. Elle soit rentable. Exactement. Donc il y a ça. Et puis, c'est pour ça qu'il faut impliquer vraiment tout le monde, que tout le monde ait le même niveau d'information. Et pour moi, l'approche FinOps aussi, c'est un vrai levier qui peut être différenciant pour gagner en compétitivité.

32:43 Quand on maîtrise ce qu'on dépense, on maîtrise surtout, on comprend. Il y a la notion de contexte et de compréhension. Pourquoi on dépense tant? Pourquoi ça nous coûte tant? Est-ce que ça vaut le coup? Est-ce qu'il y a des choses à faire ou pas? Tout ça, c'est vraiment amené par le FinOps. Et tu parlais de tags, tu parles aussi d'accès à l'information, donc de bien savoir monitorer, rajouter du tracing, faire des choses comme ça. Peut-être... Cost allocation, en fait. Exactement, les cost allocation. Réfléchir à... Parfois, on dit que c'est des mesures, mais éteindre les ressources dont on n'a pas besoin sur les endroits de reprod, par exemple. Exactement, c'est pour ça qu'il faut regarder l'utilisation horaire sur une journée. Ça permet justement de défier des patterns comme ça. Avoir la notion aussi d'environnement éphémère qui peuvent apporter un tout. C'est vraiment un tout, mais ce n'est pas un sujet uniquement infra. Donc ça, on est tous les trois d'accord là-dessus. Ce n'est pas uniquement un sujet tech.

33:44 Et même quand on est tech, c'est super important d'avoir cette approche-là d'usage responsable. L'idée, ce n'est pas de se brider, mais c'est vraiment d'avoir un usage responsable, maîtrisé et de comprendre aussi dans quel contexte on évolue. De responsabiliser tout le monde et d'avoir vraiment ces discussions-là en ayant cette approche-là, qui est en plus dans les discussions, dans les choix d'architecture. Voilà. Je ne sais pas si vous avez d'autres choses à dire avant la conclusion. Donc chacun, on a réfléchi à une conclusion avant de clôturer, de vous passer le micro. Je ne sais pas qui veut commencer par la conclusion. Arthur? Je peux commencer. Ça va être très court, on a déjà tout dit. Mais oui, c'est ça, en fait. On en a tous les trois parlé à des moments différents, mais c'est la collaboration, l'analyse aussi de l'état présent, en fait, présent en continu. Tu parlais des consommations horaires, typiquement, oui, c'est ça qui permet de regarder, de comprendre ce que fait notre application et quand.

34:51 En tant que SRE, l'observabilité, c'est ça, en fait, et c'est quand même important. Mais derrière, une fois qu'on a... On a mesuré, il faut analyser, communiquer, partager avec le reste de l'organisation, améliorer ce qu'on a et itérer en fait, il faut recommencer. Et moi, ma conclusion, ce serait n'ayez pas peur des mots comme« amortized cost»,« unblended cost»,« blended cost». Tout ça, ça a une signification qui est utile. Et le FinOps, en tout cas la personne FinOps, est là pour vous aiguiller, pour vous aider. Et pour mettre en place des outils, mettre en place des bonnes pratiques. Voilà, donc il ne faut pas hésiter, il ne faut pas avoir peur de la FinOps. Moi, pour ma part, c'est... Ce que je voudrais dire, c'est vraiment que l'approche FinOps, elle est accessible à tout le monde.

35:56 Il ne faut pas nécessairement attendre d'avoir un CFO, parce que tout le monde n'a pas de CFO, tout le monde n'a pas de profil ou d'équipe dédiée à la finance. Ensuite, oui, collaborer, parce que de toute façon... C'est le minimum syndical aujourd'hui. On parle beaucoup de collaboration dans le cadre de DevOps. FinOps, c'est aussi collaborer, collaborer. Définissez vos objectifs. L'idée, ce n'est pas d'y aller comme ça. On va réduire les coûts, on va faire baisser la facture. Quels sont les objectifs? Les objectifs techniques, mais aussi business. C'est super. C'est important aussi à faire communiquer les deux et itérer. Parce qu'il faut toujours s'inscrire dans une démarche d'amélioration continue. Ce qui est valable aujourd'hui ne l'est pas forcément le lendemain. Donc, il ne faut pas avoir peur d'itérer, itérer, itérer. De se remettre en question. Exactement. Merci Arthur et François. Merci à vous toutes et tous. C'était vraiment un plaisir d'échanger avec vous. Merci d'être venu.

36:56 Voilà. Et je laisse la parole. Je ne laisse pas la parole à Noémie, mais je la laisse passer le micro à la personne qui souhaite prendre la parole. Merci à toi aussi, Katia. Merci. Bonjour. Merci beaucoup pour la présentation très claire. Moi, je découvre un peu la FinOps, donc c'était hyper intéressant. Vous avez parlé pas mal du côté réactif. Moi, je m'intéresse beaucoup aussi au côté proactif. J'imagine qu'à un moment donné, il faut former des équipes, vous parlez beaucoup de langage commun. Mais comment vous faites pour que ça ne soit pas pris comme une contrainte? À quel moment du projet vous vous entrez pour ne pas qu'on refasse les mêmes erreurs, etc. Comment faire en sorte que les erreurs que vous avez déjà détectées ne se reproduisent pas, etc. Comment être plus proactif au niveau de la FinOps? Il faut trouver des éléments motivateurs. On en discutait avec Arthur tout à l'heure. c'est que quand on vient voir un OPS, on lui dit, ok, là, ça a coûté 10 000 balles, bon, il faut faire des efforts.

37:59 Bon, c'est pas non plus très motivant. Si, maintenant, on va le voir, on dit, ok, 10 000 multiplié par 12, ok, on peut embaucher peut-être quelqu'un d'autre. Dans l'équipe. Donc là, tout de suite, ça permet de se projeter, de... Voilà. C'est fixer comme ça des éléments pour chaque équipe de... Ok, qu'est-ce qui va les... Quelle métrique va les motiver, en fait? Et de la traduire pour que ce soit pour eux... Il faut qu'ils aient une image. Au niveau proactif, mon idée, c'était quand tu commences un nouveau projet, À quel moment vous... Il y a un moment détecté où on peut détecter que ça, ça va coûter trop cher, cette architecture-là, et du coup, vous conseillez dès le début. Je ne sais pas si tu vois ce que je veux dire. Dire prévoir un coût, c'est-à-dire par rapport à une archi donnée sur le papier et de se dire, OK, ça va coûter tant. Oui, voilà, pas exactement, mais oui. À peu près? Alors, conseiller en fait, en amont, il faut donner les bonnes pratiques.

39:03 Alors, il y a de... Oui, en fait, comme le modèle de prix, par exemple, si on prend du compute, que ce soit sur AWS ou sur GCP, je connais beaucoup moins Azure, mais j'imagine que c'est la même chose. Il y a des coûts qui diffèrent par région. Donc dès l'instant où par exemple vous allez faire votre archi, vous allez vous dire ok, je vais choisir la région Singapour, c'est peut-être pas le mieux pour commencer, pour faire du compute parce que c'est la plus chère. Donc voilà, il y a un aspect comme ça de dire, ok, comment trouver la ressource qu'il me faut avec les performances que je veux et qui ne me coûtent pas trop cher. Donc là, c'est un peu de la proactivité. Maintenant, derrière, la proactivité vient aussi avec le monitoring, l'observabilité. Dire que si par exemple vous êtes un retailer et que tous les mois de décembre, votre infra,

40:15 elle est comment dire, elle est... Solliciter plus qu'à d'habitude parce que vous avez plus d'activités sur votre site de retail, la preuve d'activité c'est ok, on va peut-être faire du... On va peut-être scaler correctement, est-ce qu'on peut utiliser peut-être des spots, est-ce qu'on peut... Il y a aussi cette partie par rapport à ce que vous avez déjà observé et peut-être qu'il y a des phénomènes qui vont se répéter et pour lesquels vous allez pouvoir anticiper. Sur certains cloud providers, on a la notion de calculette. Alors, ce n'est pas une science exacte. Donc, voilà, on ne peut pas anticiper le trafic, tous les flux réseaux, ça, on ne peut pas l'anticiper. On a quand même une calculette qui permet à peu près d'avoir une idée globale de... Une estimation d'un coût d'infrastructure. Donc ça, c'est déjà un premier point quand on définit une architecture sur le cloud, d'avoir un ordre idée. Alors la réalité, c'est qu'il faut toujours compter plus que ce qui est affiché dans la calculette.

41:17 Ça, c'est un point. Après, le deuxième point, c'est vraiment de former aux bonnes pratiques parce qu'au final, quand on parlait de tagging, de mécanisme d'autoscaling, etc., quand on définit une architecture, c'est à ce moment-là aussi être... Sûr qu'on est accompagné par les bons profils qui maîtrisent le sujet, parce que très souvent, quand on ne sait pas, on découvre, on apprend sur le tas. On se dit que le cloud, c'est facile, on va vers ce qui nous semble facile. Il y a des mécanismes sur le cloud qui permettent l'autoscaling, le fait d'avoir des spot instances. Mais tout ça, c'est des arbitrages qu'on peut faire très en amont de la mise en prod. Déjà du développement, rien que dans le stade, on définit une architecture. Et puis sinon, former aux bonnes pratiques tout de suite tout le monde. Donc voilà, expliquer c'est quoi le modèle de coût, qu'est-ce qui coûte le plus cher, pourquoi il faut mettre du tagging, le right sizing, anticiper le monitoring aussi, effectivement, pour savoir, pas uniquement le monitoring aussi, on peut avoir les traces pour savoir s'il y a des choses qui prennent du temps, etc.

42:20 Tout ça, c'est des choses qu'on peut anticiper, mettre en place très en amont. Anticiper les coûts d'igrès, par exemple. Il y a plein de choses qui peuvent permettre d'anticiper des coûts. Et de ne pas tomber trop loin. Mais oui, je n'ai pas parlé des calculettes, mais oui, il y a des calculettes données par les cloud providers, enfin, proposées. J'ai essayé de donner mon point de vue de tech plus plus, parce qu'on est tous les trois techs, mais voilà. Pour moi, c'est une question de sizing, en fait. Quand on discute d'ajouter une fonctionnalité à un service ou de créer un nouveau service. Les questions qu'il faut qu'on se pose, c'est... On se pose différentes questions, mais on se dit, ok, c'est quoi le volume de données, le nombre d'utilisateurs, l'activité des utilisateurs, quand un utilisateur fait telle action, je vais écrire tant de données en base, pour chaque élément de données que j'écris, je vais la lire dix fois, par exemple, etc. Toutes ces questions-là, toutes ces variables dans l'équation, sont complètement 100% spécifiques à votre application.

43:26 Et le truc, en fait, c'est qu'on peut se dire, il y a une solution générique, machin, où on se dit, on va mutualiser les ressources. Ah bah, tu sais quoi, du coup, on va faire un cluster Kubernetes, et comme ça, chaque instance aura son propre sizing et tout, et on va faire du beanpacking, et ça va être trop bien. Et je suis déjà arrivé, dans mon taf d'avant, j'étais dans le conseil, chez un client, où justement, c'était ça l'architecture qui lui avait été vendue. Et puis après, j'ai commencé à discuter avec le client du trafic qu'ils attendaient, du nombre d'utilisateurs qu'ils avaient et de l'activité qu'il y aurait sur ce nouveau service qu'ils étaient en train de développer. Et au final, je leur ai proposé de ne pas du tout partir sur du Kubernetes, mais plutôt partir sur du serverless, à la fois pour les services backend et pour la base de données. Et on est passé d'une architecture, donc un cluster Kubernetes déjà c'est 1000 euros par an si vous n'avez pas de machine. Et après derrière, il faut compter au moins une machine par data center minimum. Et là, vous avez un petit cluster et vous avez les coûts de réseau entre trous, etc. Et quand il n'y a pas d'activité, la nuit, vous payez quand même. Voilà, donc on était sur une architecture qui allait coûter aux alentours de 5-6 000 euros par an. On est passé sur une architecture serverless qui coûte 15 euros par mois.

44:30 Donc 180 euros par an à peu près. Et en fait, on a instantanément fait de la facture cloud un non-sujet pour les équipes financières. Et ça, en fait, ça passe en passant par le sizing, en fait, quand ils nous disent, ah, ben, en fait, on a, OK, 10 000 utilisateurs qui vont être hyperactifs 5 minutes par semaine, parce qu'en fait, c'est un système d'enchaire. On leur dit, on peut faire tourner H24, ça ne sert à rien. Et en fait, ce genre de truc, c'est des discussions qu'il faut avoir. On peut avoir une calculatrice et c'est bien. Et c'est avec la calculatrice qu'on calcule, ok sur un an, Kubernetes ça coûte tant, le serverless ça coûte tant, avec tel trafic, etc. On estime, mais ça commence par le sizing en fait, et la discussion de que fait notre application. Et quand tu posais ta question à la base, tu disais comment est-ce qu'on fait pour pas que ce soit trop contraignant? Et comment est-ce qu'on fait pour être proactif, pour que la collaboration soit agréable et efficace? Donc tu parlais de la motivation, ça c'est super. Quand quelqu'un pousse quelque chose en prod et qu'il y a un graphe qui fait juste moins 20%, Ça, c'est un énorme kiff.

45:35 Mais en revanche, pour la collaboration, quelque chose qui aide vachement, c'est le domain-driven design. C'est un concept en développement logiciel qui est, on apprend le vocabulaire métier, et c'est ça qu'on utilise dans le développement de notre application. C'est-à-dire qu'en fait, les développeurs apprennent le métier des utilisateurs. C'est ça qui est important. Et ici, on veut que les développeurs apprennent le métier des équipes de finance, et on veut que les équipes de finance apprennent le métier des développeurs. Et ça, ça passe par le fait d'établir un vocabulaire commun, un vocabulaire omniprésent, comme on dit dans le DDD. Le DDD c'est aussi un ensemble de méthodologies pour mettre en place cette collaboration là. Donc il y a plein de techniques, je ne vais pas les lister maintenant parce qu'il y a 12 livres épais comme ça sur le DDD, mais plein de bonnes ressources qu'on peut trouver, mais il y a plein de techniques pour justement mettre ça en place dans une organisation où initialement, On essaie de faire collaborer des gens qui n'ont pas du tout le même métier. Moi, j'ai juste un petit warning par rapport au serverless, parce que j'en avais parlé avec vous, j'ai rencontré un exemple d'un client qui était parti sur full serverless, parce que j'ai que des devs, je n'ai pas de compétences poussées en infra ni en ops.

46:48 On se retrouve avec plusieurs centaines de lambdas. Et après... On perd un temps fou à déployer. Les gens ne comprennent pas parce qu'il y a des choses qui ne fonctionnent pas. Parfois, quand on déploie, on déploie sur les paperlines de CICD. Et après, les coûts qu'on a économisés dans Serverless, on va les payer dans Datadog pour essayer d'avoir un tracing et un monitoring pour comprendre pourquoi du comment. Parfois, ça ne fonctionne pas et pourquoi parfois c'est lent. Sur tous les sujets techniques, effectivement, je suis totalement d'accord. Il n'y a pas de recette miracle. C'est des arbitrages à faire, c'est des choix à faire dès le début. Et savoir, en fait, anticiper l'évolution de son application. Est-ce que le trafic va être multiplié par 10? Est-ce qu'on envisage de développer de nouvelles fonctionnalités? Et après, il faut itérer. Donc, ce qui est très bien au début, il ne faut pas avoir peur de remettre en question constamment ce qu'on fait. C'est comme ça qu'on s'améliore et qu'on améliore, on continue. Merci beaucoup. Bonsoir, merci, bravo de votre intervention.

47:52 Bastien de Cloud FinOps. Donc moi, j'ai une question, c'est que déjà, bravo pour tout ce que vous faites opérationnellement, c'est hyper clair. Et souvent, on se rend compte... avoir le complexe du camp flex par rapport aux américains mais j'ai un chiffre en tête dans la finops foundation il communique sur le fait que morgan stanley ils ont envoyé 200 personnes forbes certifié finops practitioner le point il est est ce que vous voyez vous culturellement aussi france et on va dire pays limitrophes ou pays certains pays francophones Le fait qu'on puisse se limiter aussi, vous parliez beaucoup de s'approprier des termes financiers, de parler le langage et le vocabulaire, et où ce serait peut-être un peu plus naturel dans d'autres pays, notamment des pays anglo-saxons, mais pas que. Est-ce que vous pensez qu'il y a plus de challenges, en France en particulier, ou d'autres pays latins, à insuffler cette culture-là? À cause d'un tabou? C'est ça? Oui, peut-être. Est-ce que le dialogue, parce que c'est vraiment ça, c'est casser les silos et communication et vocabulaire commun, est-ce que c'est plus challengeant, c'est plus difficile ici? Pareil aussi, le fait de voir des finops sur des profils peut-être moins valorisés ou moins valorisables que dans des pays où...

48:58 Tu as raison, le côté business est moins tabou. Et le fait de dire qu'on sert une cause commune pour le business et pour des clients, c'est moins tabou. Donc voilà, question ouverte et je n'ai pas la réponse. Moi, je vais juste commencer, je pense. Culturellement, il y a un tabou avec l'argent. Déjà, rien qu'avoir les salaires, on ne communique pas de manière naturelle sur nos salaires quand on est dans la tech en France. Je pense que déjà, il y a un petit... Effectivement, au début, je parlais de ce changement culturel, de ce tabou-là qui commence à cesser. On commence à... par les argents et c'est pas grave si on dit qu'on a on paye une infra de 10 000 euros 100 000 euros mensuels etc après comparer à d'autres pays je ne sais pas mais je pense que voilà quand on si on compare à la question salariale on dit toujours qu'en france il ya ce petit tabou là avec avec il ya toujours ouais parce qu'il ya beaucoup de C-level qui considèrent que c'est une donnée confidentielle. Donc, qu'elle ne devrait pas être communiquée, même en interne, au sein des équipes.

50:00 Et donc, elle est réduite à être connue que d'un petit groupe de personnes qui n'ont pas forcément les compétences pour agir, mais qui ont la connaissance et qui décident de qui doit savoir ou pas. Donc, effectivement, il y a une petite barrière encore. Moi, je n'ai jamais travaillé sur des jeux FinOps avec des boîtes étrangères. Donc, je ne sais pas. Bonjour, Benoît de Malte. En fait, je voulais peut-être aussi partager un petit peu ce qu'on a autour de l'expérience. Sans le savoir, on a fait un peu ce que vous avez dit cette année. On est parti du constat 2023. On voulait rentrer dans une croissance un peu raisonnée en termes de coût cloud, c'est-à-dire commencer à comprendre un peu nos factures et à mieux les maîtriser et à rentrer pourquoi pas dans une phase où on anticipe un peu plus.

51:04 On a fait un peu ce que vous avez recommandé, c'est-à-dire on a mis des engineering managers, des SRE surtout et des devs autour de la table. On a commencé à réfléchir à comment est-ce qu'on pouvait optimiser. On s'était fixé une première guideline qui était de se dire on va essayer de finir l'année avec un forecast de budget 2024 égal à celui 2023. Tout en continuant à croître au niveau de l'entreprise et en continuant à accompagner le business. On a réussi, c'est cool, on était contents. Maintenant, la prochaine étape, et ça c'est une question que je voulais vous poser, ce qu'on se dit, c'est qu'en fait, ce petit groupe de personnes ne peuvent pas rester les gardiens du temple. Et on s'en est rendu compte au cours de l'année qu'en fait, on avait des équipes de dev qui continuaient à développer, à rajouter de nouvelles fonctionnalités, etc. Et qui étaient moyennement au courant. Alors même si on est assez transparent sur les coûts, sur les budgets, etc., les équipes sont au courant de combien ça coûte. C'est quelque chose qu'on communique. On avait communiqué dès le départ quel était l'objectif de cette équipe-là. Donc tout le monde est... étaient au courant qu'on voulait optimiser, mais malgré tout, en fait, ils ne font pas forcément attention au quotidien à tout ça.

52:08 Et donc, en fait, est-ce que vous avez des retours d'expérience sur, par exemple, le fait de créer des budgets par équipe, de leur faire réfléchir à ça, qu'ils puissent justement anticiper? Faire du chargeback, en fait, c'est ça? Oui, il y a des endroits où ça fonctionne. Maintenant, ça dépend du niveau d'engagement des gens derrière. Est-ce que ça va déclencher? Parce qu'il y a du chargeback et le contraire, comment ça s'appelle? Du showback? Donc le showback, c'est partager toutes les données avec tout le monde. Et centraliser le coût, c'est un budget global. Alors que le chargeback, c'est vraiment, on a budgétisé pour cette équipe. J'ai vu dans des grosses boîtes, où ça, ça marchait, ouais. Le chargeback? Le chargeback. D'accord. On serait plutôt showback, là, pour commencer. Showback, c'est l'étape d'après, en fait.

53:09 Ah bon? Ouais. Donc là, t'es déjà dans la partie... Je parlais, tu sais, crawl, walk, run. Là, tu runs, là. Dans la méthode d'eau, en théorie. Mais c'est bien. On va essayer. Je pense qu'avant de fixer des limites aussi, tant que dev, on... On peut comprendre les choses. En parlant, en expliquant, il ne faut pas qu'il y ait une seule partie de l'organisation qui soit au courant des décisions, qui prenne des décisions. Même si on prend des décisions, il faut vraiment... Tu parlais d'évangélisation. C'est super important parce que beaucoup de personnes sont curieuses, veulent juste apprendre. On partage les bonnes pratiques et on montre, en respectant ces bonnes pratiques-là, voilà le résultat. Comme tu disais, tout le monde aime bien voir que l'impact est positif. C'est aussi ce côté-là challengeant. Il y a même des compétitions entre équipes, parfois. Sans aller à la compétition. Sans être une compétition bienveillante.

54:12 Exactement, mais rien que d'expliquer, d'évangéliser et de responsabiliser les gens, tout le monde, pas uniquement les devs, même les personnes accueillies, de produits, etc. Ça aussi, ça peut être un vrai levier pour bien réduire ses coûts et surtout d'avoir cette consommation-là raisonnée. En fait, je vais rebondir sur ton expérience, que je trouve hyper intéressante. Et en fait, justement, j'essaie de me projeter sur ce que tu disais, de fixer un budget par équipe. Et en fait, ce que je me disais, c'est que chez Pigments, ça ne marcherait pas du tout. Parce qu'en fait, si on regarde d'où viennent nos coûts d'infra, et quelle équipe travaille sur les fonctionnalités qui peuvent potentiellement améliorer cette situation, une équipe qui travaille sur 90% de la facture. Parce qu'en fait, la nature de notre application fait que ce qui coûte cher, c'est le stockage et le traitement de la donnée, et on a une équipe qui est en charge d'essayer d'optimiser et de faire scale notre moteur de calcul.

55:17 Mais les autres équipes sont toujours, elles aussi, en train d'implémenter des fonctionnalités qui sont très importantes, qui sont importantes pour nos utilisateurs, mais qui fondamentalement ne coûtent pas cher. Typiquement, est-ce qu'un dev front, ça coûte en FinOps? Ça rajoute... Je ne sais pas, ça passe... Non mais c'est vrai, un dev front qui passe des semaines à améliorer, des mois même, ou son année, à améliorer le front, il y a zéro impact sur la facture cloud. Et pourtant, on ne va pas virer les devs front en se disant« tout le monde fait du backend, maintenant il faut réduire la facture». Donc je ne suis pas forcément convaincu par le côté budget équipe. Si Paul, une API toutes les 3 secondes pour avoir une mise à jour de statut, ça peut commencer à coûter cher. Complètement. Et du coup, à ce moment-là, tu as la question de comment est-ce que tu répercutes. Le front a appelé le backend, le backend a appelé un autre backend, les deux ont appelé une DB, etc. Retracer, qu'est-ce qui coûte? Tu parlais de ça, du coup, de tracking, mais en fait, retracer l'ownership de... Alors, telle fonctionnalité dans le front a utilisé 2% du CPU de la DB ce mois-ci.

56:21 Alors ça dépend, si ton front c'est du Node.js et que dans tes builds, tes runners tournent sur le cloud et que tu payes les nodes de mon module que tu télécharges toute la planète. Donc ça dépose ça aussi, ça peut être... Faites du caching. Ça, ça fait mal, ça. On parle des modules, donc bon. Est-ce qu'il y a une autre question? Question ou partage d'expérience, du coup? Oui, tout à fait. Question ou partage? Le micro est à vous. Question un peu, si vous aviez chacun un exemple concret d'un peu de réussite perso dans le cadre de... Oui, moi j'en ai un.

57:23 C'était une optimisation des volumes de storage sur AWS. Et donc, ce client-là, il utilisait des volumes très chers, des I.O. Et donc, par rapport à la performance qui était demandée, c'était tout match. Et donc, à l'échelle d'une boîte, c'était des centaines de milliers de volumes. Donc à la fin, par an, ça représentait 200 000 euros. Donc ça, c'est... Vraiment une recherche. Il y avait aussi les coûts induits EC2 aussi derrière, qui ne sont pas cachés, mais qu'on ne voit pas tout de suite, et notamment lorsqu'on crée une instance. On attache un volume. Et quand on termine une instance, parfois le volume peut rester tout seul, mais il continue à côté de l'argent.

58:31 Il y a plein de choses comme ça. Ils appellent ça du logging fruit. C'est hyper simple à gérer. Ou alors, il y avait un autre truc aussi, c'était... Tous les environnements de dev qui restaient allumés le week-end et la nuit. C'est hyper facile. Derrière, c'est des milliers d'euros d'économiser. Moi, j'ai un exemple. Il y a mon associé qui le connaît. C'est un client qui fait une plateforme SaaS de vidéo streaming, des Netflix, Like, etc. Et c'était une facture mensuelle de plusieurs dizaines de milliers d'euros par mois. L'Infra a été monté par des devs, donc ils sont allés très vite en prod, ils ont gagné des clients, donc très bien. Sauf qu'ils sont partis sur un modèle instance EC2, etc. Donc en passant sur un modèle de containerisation, avec l'auto-scaling, les mécanismes d'auto-scaling, qui permettent vraiment d'absorber la charge au moment où on a un trafic très important, donc en général c'est la nuit ou le week-end,

59:43 Donc on a réussi à réduire la facture de 40%. Pour une boîte qui commence, qui a quand même son marché, qui commence à avoir du trafic qui arrive, réduire sa facture cloud qui est déjà de plusieurs dizaines de milliers d'euros de 40%, c'est quand même très impactant. et très important aussi pour la suite. J'ai déjà donné l'exemple tout à l'heure de le gros cluster cube versus les deux lambdas qui font un fois 100, enfin divisé par 100 sur la facture. Je vais peut-être donner un autre exemple que j'ai fait très récemment. Je t'en parlais tout à l'heure, François. Il y a trois semaines, j'ai pris un jour et demi, deux jours, on va dire, deux jours en comptant les code reviews, etc., pour accélérer chaque job de CI et de non-CI de une minute. J'ai accéléré le clone du repo. Et du coup, tous nos jobs de CI ont gagné une minute.

1:00:45 C'est une minute de moins qui est facturée. En fait, ça a l'air qu'il y a 2000 jobs par jour, à peu près, qui tournent, sur tous nos PR, tous nos releases, etc. Et en fait, c'est 2000 minutes par jour de gagné, ce qui revient à peu près à un jour et demi par jour. Et en fait, c'est tout bête. Et en fait, l'impact sur la... Enfin, une minute, ça peut paraître d'être peu, mais en fait, c'est-à-dire que si c'est optimisé au bon endroit, passer deux jours à gagner une minute, ça vaut le coup, en fait. Et les devs sont plus efficaces maintenant, parce que les PR mergent plus vite. Bonjour, Clémence. Du coup, moi, je n'ai plus de questions. Enfin, je n'ai pas de questions, mais c'est plutôt un retour d'expérience. Parce que du coup, apparemment, la liste des questions est épuisée. Du coup, par expérience, ce qui est super important, c'est la visibilité. Parce que ce dont je me suis aperçu assez rapidement, j'ai aussi eu l'occasion de travailler dans une équipe centrale où finalement on avait plein de projets, plein de clients internes. Et assez vite, on veut réfléchir, puis on veut traiter les sujets, mais on se rend vite compte qu'en fait, on a l'impression de maîtriser, mais on ne maîtrise pas grand-chose de ce qui se passe.

1:01:53 Et je pense qu'il faut faire le deuil de la compréhension globale de tout ce qui se passe très précisément. Et juste se dire qu'en fait, le développeur qui développe sa feature, qui a son container, qui a son serverless, ou qui a même son application monolithique, il l'a fait pour une raison. Et qu'en fait, c'est la personne la mieux placée pour corriger le problème ou pour améliorer la situation. Et ce qui marche super bien, c'est juste la visibilité. C'est juste un super dashboard qui permet de dire, en fait, le coût de ton application, c'est tant. Mais encore, le coût de l'application, ça ne sert à pas grand-chose. Parce que si c'est une application qui fait 100 000 personnes, si c'est une application qui en fait 1 000, tu as trop de l'application qui fait 1 000, les clients, ils payent 100 fois plus. Et peut-être que la valeur business est 100 fois plus importante aussi. Donc finalement, peut-être que ça n'a pas d'intérêt d'optimiser, ou peut-être que si. Et donc l'intérêt finalement, c'est d'aller un petit peu plus loin. Et c'est là où on voit la qualité de la donnée, c'est faire le coût par utilisateur, ou le coût par, ce qu'on appelle le coût par siège. Ou bien le coût par usage, ça dépend comment vous facturez après à vos utilisateurs.

1:02:58 Souvent, c'est à l'externe. Parce qu'à l'interne, le chargeback, par expérience, il y a des coûts cachés extrêmement importants. Les coûts cachés qui sont que, quand on a 200 000 lignes de facturation par jour d'Amazon, qu'on doit agréger sur le mois, sur le semestre ou sur l'année, qu'on doit dédupliquer, embaucher des gens pour ça, un système complet. Utiliser Pigment, je dis ça. C'est littéralement notre outil. Ça sert à ça. On s'en sert en interne d'ailleurs pour ça. Ça marche bien. Elle est Microsoft. Et du coup, ce qui est vachement important pour moi, pour finir, c'est la visibilité. Et l'idée de dire, par exemple, le coût par siège, il est de, par exemple, 20 centimes. Et de dire, là, on a fait une mise en prose, on a fait la V1, on a fait telle feature. Et sur l'ashboard, on met un flag, on met par exemple un bâton. Sur Graphenasse, c'est vachement simple. Sur ce graphe-là, on met un bâton, on met un flag et on le norme. Et en fait, ce flag-là, c'est la V1. Et le V1, le coût par siège, c'est 1,20$.

1:04:01 Et la V2, c'est« Ah merde, on est passé à 2$, est-ce que ça a de l'impact ou pas? » Du coup, on peut en discuter. Et proactivement ou réactivement, l'équipe de développeurs va se poser la question. C'est comme les monitoring. Si on voit une latence ou potentiellement une métrique de qualité du VIX, 40 000, les gens aiment leur travail. Donc ils vont faire en sorte que les gens soient contents. Rien que ça, en fait, par expérience, ça résolvait proactivement 50% des problèmes. C'est un élément motivateur. Avoir la bonne métrique pour pouvoir trouver ou comprendre le coût derrière. Parce que c'est vrai que quand on voit des chiffres énormes, ça ne parle pas. J'avais un autre client, son but c'était de passer en dessous du dollar pour le million de requêtes.

1:05:06 C'était sa métrique. Et quand on a la bonne métrique, effectivement, après, on avance beaucoup plus vite. Merci pour votre présentation. On a commencé à aborder le sujet, on n'a pas trop parlé des outils. Vous avez mentionné un nom d'outil, je n'ai pas compris le nom que vous avez mentionné, et je ne le connais pas. Mais du coup, j'avais cette question sur que ce soit peut-être faire la différence entre des entreprises monocloud et des entreprises multicloud. Est-ce qu'il y a des outils autres que ce qui sont proposés par les cloud providers qui ont des utilités fortes, surtout au départ pour la partie quick win comme on a parlé? Et est-ce que vous avez des retours d'expérience là-dessus? Petit aparté, tout à l'heure je parlais de Pigment, en fait c'est ma boîte, c'est pour ça que j'en parlais. Nous on utilise Pigment pour le FinOps, mais c'est fait pour la planification financière à la base, on le vend aux équipes financières.

1:06:09 Il s'avère que nous on s'en sert en interne pour différents usages, parce qu'on n'a pas besoin de payer les licences. Mais sinon, pour répondre à ta question, do it. C'est l'outil qui sert à ça. Il sert à agréger les données venant de différents club providers, de les visualiser, de les transformer, d'avoir des restournes dessus sans trop d'efforts. Nous, on est passé par Do It, et c'est une très bonne première étape. Ce n'est pas la finalité du truc, parce que derrière, il faut faire tout ce qui est spécifique à son application. Mais mine de rien, c'est Do It qui nous a montré du doigt que les communications entre les régions, ce n'était pas rien du tout. Et du coup, c'était à prendre en compte. Est-ce que tu veux rebondir, François? C'est comme ton produit. Merci. C'est, oui, Cloud Diagnostic, en fait. Après, c'est sûr que les... Les cloud providers proposent leurs propres outils de monitoring. Je parle toujours d'AWS, Google, tous les gros cloud providers, Microsoft, j'imagine aussi.

1:07:17 Effectivement, quand on est monocloud, ça peut paraître pratique, mais maintenant, Le challenge aussi, quand on fait du multi-cloud, c'est d'avoir une plateforme unique ou avoir une visualisation centrale. Après, il y a des sortes de parties. Datadog, c'est top. C'est vraiment... Mais Datadog... Ça coûte un. Je rebondis un truc, juste en combinant vos deux retours d'expérience. Je suis d'accord avec toi. À partir du moment où tu mets des dashboards devant les équipes, ils sont motivés. Il y a une certaine rivalité saine qui peut se mettre en place, qui peut être très motivante. Et pour répondre à ta question sur les outils, j'ai déjà vu des développeurs développer des outils sur mesure, parce que c'est des développeurs, ils savent faire, justement pour raffiner la donnée. Ils se disent, j'ai telle donnée brute qui me vient du cloud provider, j'ai besoin de la corréler avec l'utilisation de mon application. L'application n'expose pas la donnée nécessaire, tu sais quoi, je vais rajouter un endpoint interne et maintenant on a la donnée et je vais pouvoir la corréler avec l'utilisation de mes buckets par exemple ou de mes bases de données.

1:08:28 Et en fait tout d'un coup ils peuvent se dire, ah ok en fait c'est cette fonctionnalité là ou même ce bloc de code là qui coûte cher. Et en fait derrière, il commence à raffiner l'analyse et à converger sur des améliorations utiles. Il ne faut pas sous-estimer la capacité d'un développeur motivé à trouver des solutions à un problème. Il y a aussi un outil dont un client m'a parlé et qu'il utilise, qui s'appelle Cloud Custodian. C'est open source. Et ça permet vraiment d'agréger aussi des données, de construire des dashboards. Il dit que c'était bien, je n'ai pas testé. Merci, là on va pouvoir passer au buffet. On me fait signe en arrière-plan. Merci vraiment à toutes et à tous. C'était vraiment un plaisir d'échanger déjà tous les trois et ensuite avec vous. Et puis place au buffet.

1:09:28 Voilà. Merci.