FinOps : comment passer à l'étape supérieure dans l'optimisation des coûts via l'automatisation ?

0:14 Bonjour à tous, merci Noémie. Eh bien, écoutez, je suis ravie d'être là aujourd'hui pour animer ce meet-up qui, je pense, va intéresser tout le monde, qui va optimiser aujourd'hui nos coûts via l'automatisation. Je vais commencer par me présenter. Donc, moi, je suis aujourd'hui CCO du groupe OncoDNA, qui est une société de génomique et de théranostique pour la médecine de précision, pour le traitement du cancer et de maladies génétiques. Avant cela, j'ai été pendant 10 ans CTO d'Intégragène, qui a rejoint le groupe OncoDNA maintenant depuis un an et demi. Donc, voilà, ravie d'être avec vous. Et je vais laisser la parole maintenant à François et Kyâne qui vont nous parler de stratégie FinOps. François, je te laisse venir et Kyâne. Kyâne, à toi la parole. On arrive en même temps. Oui, on arrive en même temps. Du coup, je vais démarrer, t'inquiète François. Donc moi, c'est Kyâne Pichou. Je suis lead DevOps chez Phoenix depuis un an et demi maintenant.

1:19 Je passerai un peu plus de temps sur ce qu'est Phoenix un peu plus tard pour vous présenter le contexte. Moi, pour ma part, j'ai une expérience dans la tech qui est plutôt orientée infra, faire de l'architecture résiliente. automatiser des migrations vers le cloud. Dans mon parcours, je suis passé par OVH, que la plupart des gens, je pense, s'y connaissent, où j'ai administré des clusters Kafka internes, donc plutôt des problématiques de grosse volumétrie. J'ai fait de la petite startup en pleine croissance où il y a beaucoup tout à construire et pour accompagner la croissance de l'entreprise. Et j'ai même donné quelques cours en indépendant d'informatique à un moment. Aussi parce que j'aime beaucoup tout ce qui touche à la pédagogie. Et donc désormais, je suis le premier et l'unique actuellement, on en parlera après, DevOps à Phoenix, que je vais bien détailler pourquoi on a ce setup-là après. Et donc dans ce cadre-là, je travaille entre autres sur nos problématiques FinOps, sinon on va parler avec François aujourd'hui. Voilà, donc moi je suis François Pasquet, je suis Technical Card Manager chez DoiT International.

2:24 Auparavant, j'étais TAM aussi chez AWS et puis dans mon parcours, j'ai été aussi Professional Services Engineer dans une petite PME. d'OTT, d'encodage et de streaming vidéo qui s'appelait Anevia et qui a été racheté après par ATEM. Et puis avant ça, j'ai travaillé chez Thadès et j'ai été militaire dans l'armée de l'air pendant 15 ans. Voilà, tout ce qui était système de télécommunication et satellite. Donc là, ce que je fais, Je voudrais vous présenter aujourd'hui, pour un petit peu poser les bases de la session du jour, c'est mettre un peu de contexte FinOps. Très rapidement, je vais un petit peu décrire c'est quoi le FinOps. Pour moi, au départ, c'est une stratégie. À mettre en place dans un seul but, réduire la facture.

3:26 De plus en plus, dans ce que j'observe, c'est que le FinOps tend à devenir une aide à la décision, pour trouver des compromis entre les équipes d'ingénieurs qui ont les mains sous le capot, et les équipes métiers, tout ça dans un contexte, bien sûr, finance. Parce qu'en fait, on se rend compte que contrôler les dépenses, ça représente un vrai challenge. Parce que quand l'organisation s'agrandit, que ce soit en termes de staffing, d'embauche de personnel qui vont être amenés à travailler sur la console, sur le cloud, ou que ce soit en termes d'engagement de ressources aussi sur le cloud par rapport à votre infra. Et avec l'expérience, ce que je peux dire, c'est que sur la route de la migration vers le cloud, il y a un set de responsabilités et de management qui représentent une charge. Et puis ces charges, en fait, elles sont là depuis toujours, en fait, depuis que l'IT est l'IT. Donc, ce n'est pas parce que vous avez choisi de construire votre business sur le cloud que ces charges disparaissent.

4:30 Donc, sans organisation et sans contrôle dès le départ, parce que plus il y a d'utilisateurs, plus il y a de projets, et plus la difficulté est grande, en fait, pour amener une vision d'ensemble, en termes de vision de ce que vous dépensez. Donc, quand je parle de difficulté, après, c'est... C'est par rapport aux efforts à fournir en temps, en technique, et puis après, derrière, tout ce qui est organisationnel. Donc, comme le cloud est dynamique, il y a régulièrement à l'arrière, de nouvelles problématiques. On a remarqué que celles-ci étaient les mêmes, que vous soyez une grosse entreprise comme Netflix ou que vous soyez une startup de 10 personnes, ça tourne toujours autour des mêmes enjeux. C'est trouver le bon réglage avec les bons indicateurs. Avoir conscience de ce qui est en train de se passer, être informé en temps réel des coûts pour mieux les jauger. Être sûr que vous dépensiez ce qu'il faut là où il le faut. Et donc, en fait, c'est ne pas over-commiter ou sous-commiter ou alors tout simplement avoir la surprise parce qu'il y a une personne qui a lancé un test et à la fin, vous allez avoir une dépense à contrôler et puis

5:46 ça finit avec une facture, une grosse facture. Au-delà de ça, en fait, en gros, c'est comment maintenir un contrôle et une gouvernance. Donc, en fait, tout le monde comprend la valeur du cloud. On peut accélérer, être autonome très rapidement. Voilà, ça, c'est de fait. Simplement, avec les équipes d'engineering et de DevOps, il faut aussi perpétuellement se poser les questions. Comme est-ce que j'ai un budget, est-ce que j'ai des limites? Comment je peux m'assurer que mon déploiement de cloud est proportionnel aux attentes de mon business et donc de mon revenu? Parce qu'en fait, on oublie souvent que la multiplication des acteurs sur les projets, ça peut entraîner des disparités de l'information. Donc, ça veut dire quoi? Ça veut dire autoriser plein de personnes. travailler sur la plateforme, ça peut être un risque. Ça peut être un risque de se lever un matin et de voir qu'il y a de la surconso dans tous les sens, qui n'a pas été cadrée, et puis se retrouver en fin de mois avec une facture qui explose. Et donc ensuite, c'est ce que je vois souvent d'ailleurs, c'est que les méthodes d'optimisation financière, elles sont mises en place une fois, que la surconsommation est faite.

6:50 C'est un peu dommage parce qu'on se rend compte que l'écart pour revenir sur une facture qui est modérée, elle nécessite pas mal d'investissement en temps une fois que la conso est actée. Donc ça peut être très très très pénible. Donc une des causes de l'origine de cette surconso, c'est que bien souvent, il y a une incompréhension entre la finance et les équipes d'ingénieurs. Donc, il faut tout de suite voir les avantages de la FinOps, parce que les entreprises qui ont une approche proactive et globale, en fait, elles reçoivent les bénéfices de chaque dollar dépensé. Donc, en fait, avec ça, elles consolident leur pérennité et elles augmentent l'efficience de leurs opérations pour éviter le gaspillage. Donc, depuis la démocratisation du cloud public, on voit que les entreprises sont intriguées et sont attirées par sa facilité de mise en œuvre. Donc, c'est facile, on sélectionne, on clique, on lance les ressources, c'est génial. Mais ensuite, quand on arrive à la fin du mois, la facture qu'on peut avoir, la douloureuse, elle peut donner une surprise. Donc, c'est ce que je fais aussi un peu chez DoiT.

7:51 On engage avec les entreprises une discussion autour des problématiques, soit autour de l'architecture ou des cas d'usage complexe, mais aussi, et bien souvent, C'est dans des discussions autour des sujets d'optimisation des coûts et donc de gouvernance. Donc voilà, une conso, comme je disais, ça peut amener, une conso non contrôlée, ça peut avoir des conséquences graves. Parce que les problèmes liés à l'augmentation d'une facture, ça peut ralentir fortement les futurs projets et donc l'expansion de l'entreprise. Et parfois même, ça peut la mettre en péril. Donc il faut vraiment prendre conscience que les résultats d'une bonne stratégie FinOps, ça peut se concrétiser ultra rapidement. Et ça va permettre à l'entreprise de gagner en agilité, ça va lui permettre d'accélérer, ça va lui permettre de développer même une compétitivité, tout en prenant un avantage. En maîtrisant des nouvelles technologies, donc toujours de manière cadrée pour gagner en efficience. Donc en parlant d'efficience, je me perds juste de faire une petite différence entre efficacité et efficience, parce que l'efficacité c'est la capacité à parvenir à ses fins,

8:58 Et l'efficience, c'est la capacité à obtenir de bonnes performances dans un type de tâche donnée. Donc pour moi, la FinOps, c'est l'alliance des deux. Voilà, c'est ma vision personnelle. Après, on peut discuter. Donc là, ça nous amène à la question, qu'est-ce que le cloud optimization? Donc là, je vais partager juste un petit doc, voilà, rapidos. Voilà, pour vous donner en fait ce que c'est pour moi l'organisation. une organisation FinOps. Voilà, ce qu'il faut vous dire, c'est que tout ce que vous allez mettre en place, tout ça, ça peut marcher uniquement si vous avez aujourd'hui dans votre organisation des personnes qui sont en charge et en responsabilité de la gouvernance du cloud et de la facturation. Donc là, d'un côté, vous avez le cloud management, donc les ingénieurs qui vont travailler directement sur la plateforme. Et puis, vous avez à côté les équipes qui vont apporter de la gouvernance. Voilà. Donc, comment on commence?

10:00 En fait, tout simplement, il faut avoir un moyen de suivre ces coûts. Voilà, avec une granularité qui permet de descendre assez bas dans l'analyse, aussi bien pour avoir une vision globale sur 12 mois, par exemple, ou sur du très court terme. Il y a, par exemple, j'ai regardé avec un client, c'est un conso d'instance sur 24 heures. Et puis, ça nous a permis après de trouver un compromis financier, sans pouvoir en parler après, sur des commits. Il y a plusieurs pricing models chez les cloud providers. Et donc, après, derrière, ça amène à du discount. C'est une console contrôlée. Sur des workloads qui sont réguliers, on peut faire des prédictions et on peut faire du right sizing. Parce qu'en fait, le but c'est d'avoir un coût, avoir une ressource qui correspond à l'utilisation qu'on en fait. Donc en fait, je vois, je terminerai rapidement, je vois en fait dans la FinOps deux approches.

11:08 Moi, je vois une approche pas très compliquée à mettre en œuvre avec l'application, des bonnes pratiques et d'analyses qui permettent d'améliorer facilement. Et rapidement sans gap technologique. Ça permet aussi de percevoir les pièges qui sont liés à la facturation ou les limites de certains services, et puis peut-être après de challenger ces services. auprès du provider que vous utilisez pour avoir de la compétitivité au niveau du coût. Donc, allez voir chez Azure, chez AWS, chez GCP, enfin voilà, selon. Et puis après, ce dont on va parler aussi aujourd'hui, c'est l'approche outillage, tooling. Soit ça permet de dégager des pistes d'optimisation, ou alors ça permet de les mettre en place. Ça peut être en place ces solutions par rapport à, suite à ces observations. Et donc, ça c'est juste un résumé qui rappelle brièvement Comment s'articule une équipe FinOps dans une organisation IT?

12:12 Au milieu, vous avez la FinOps team qui est au centre de tous les échanges entre le provider et les équipes autour. Dans ces équipes, on a à la fois des équipes tech, qui sont des ingés, et des équipes métiers, avec des product owners, des project managers, des chefs de projet, et des personnes qui sont liées à la responsabilité de l'infra. Et parfois, ces personnes-là sont décorrélées des équipes techniques. Donc en fait, tous ces gens, déjà, ils ne dialoguent pas entre eux. Et puis surtout, ils ne dialoguent pas directement avec le provider. Donc c'est à l'équipe FinOps. Au centre qui est censé recueillir tous les besoins avec leurs contraintes. Voilà, tout ça, c'est partagé par les équipes autour, recueilli par les... L'équipe InOps, et puis en fait, l'équipe InOps doit trouver un modèle idéal pour les positionner au meilleur coût, ou alors avec un coût pertinent sur le provider. C'est un peu ça l'idée. Donc aujourd'hui, l'idée, c'est de vous montrer quelques briques via des exemples de Kyâne.

13:17 Parce qu'en fait, dans l'automisation, il y a des parties où le monitoring peut apporter des solutions en termes aussi de déclenchement. Dans le cas où, exemple simple, il y a la création de ressources sans tagging qui amène, puis derrière, ça va amener à ce que ces ressources-là soient détruites. Pas de tag, du coup, détruit. Donc en fait, le FinOps, il ne faut pas voir ça comme une charge. Pour moi, c'est essentiel. Et d'ailleurs, si on revient un petit peu, juste 5 secondes sur les deux années qui viennent de s'écouler, depuis le début de la période Covid, en fait, c'est devenu un enjeu aussi. C'est devenu un enjeu de survie pour certaines entreprises. D'ailleurs, c'est aussi ce qu'on m'a demandé à un moment donné dans mon parcours, c'est est-ce que tu peux nous aider à réduire la facture? Parce que l'économie étant arrêtée, du coup, il n'y avait plus de rentrée par rapport au business, il n'y avait plus de rentrée d'argent. Mais par contre, le coût, il continuait de filer. Donc, il fallait quand même payer les factures chez les providers.

14:19 Donc, il fallait optimiser. Puis, depuis, on va dire, ce que j'observe depuis 2022, il y a un nouvel aspect aussi qui arrive en plus. de la réduction de factures, c'est parce que l'enjeu n'était que financé au départ, et puis maintenant, avec le développement et l'expansion des utilisateurs, il devient aussi écologique. Donc il faut aussi prendre conscience que le Finop s'inscrit dans une démarche RSE. RSE, c'est responsabilité sociétale des entreprises, donc en quelques mots. c'est la contribution des entreprises aux enjeux de développement durable. Et puis, faire de l'optimisation, c'est aussi s'inscrire dans une démarche d'éco-responsabilité qui vise à réduire l'impact. carbone de son infra. Voilà, donc là, je vais laisser la parole à Kyâne, qui nous parle des enjeux FinOps qu'il a rencontrés, et puis quelle a été sa stratégie ensuite pour la mise en place technique, et puis son approche d'anthomatisation, dans le cadre de l'optimisation des coûts en tant que DevOps.

15:20 Voilà. Effectivement, nous, notre côté à Phoenix, c'est des enjeux qui ont été très importants sur l'année, on va dire, l'année scolaire 2021-2022, en tout cas de septembre à la fin de ce trimestre-là. Pour vous donner un peu de contexte, qu'on sache d'où on parle et comment ces problèmes éthiques sont arrivés chez nous, Phoenix, c'est une entreprise qui a 8 ans maintenant et dont l'objectif est de combattre le gaspillage alimentaire sous toutes ces variantes possibles. Puisque très rapidement, le gaspillage est très différent en fonction de s'il est au niveau de l'industriel, du grossiste, de la grande surface ou de la petite épicerie. Il y a différents axes de revalorisation. Et donc, dans ce cadre-là, nous, on propose plusieurs services aux entreprises en fonction de leur taille et de leur métier de base pour réduire le gaspillage alimentaire. Et dans tous nos services, on a des produits tech qui sont là pour rendre le service qu'on propose.

16:26 On en a trois. Et on a... Les trois distincts, il y en a un qui est plutôt orienté B2C, donc ça va être une application mobile pour vendre des paniers aux particuliers à prix réduit. Le leader du marché bien connu est Tougou Tougou, donc c'est quelque chose de relativement similaire dans l'approche. On a côté B2B deux autres produits. On a une plateforme de dons, donc du don d'une grande surface directement à des associations, donc c'est les plus gros volumes pour des grandes et moyennes surfaces. Et on a une autre application mobile qui est là plutôt pour faire du stickage en magasin. Donc, c'est les fameux rayons produits à date courte que vous avez déjà rencontrés dans vos magasins. Et donc, ce sont trois solutions tech très distinctes chez nous avec des squads de dev et des squads de produits différents. Il y a des fonctions transverses au milieu comme la mienne, côté DevOps, mais on a des squads bien distincts. Et dans notre cas aujourd'hui d'exemple, on va plutôt parler de notre application mobile grand public parce que c'est elle qui rencontre les besoins d'infrastructures les plus importants et donc sur lesquels il y a des

17:35 optimisations de coûts beaucoup plus importantes à activer. Et donc, c'est une application mobile avec un backend sur AWS. On va beaucoup parler de ce cas-là aujourd'hui, mais beaucoup des solutions qu'on a mises en place, on va le voir, elles se généralisent, c'est plus dans l'approche, la méthodologie que dans le détail de comment nous, on a optimisé telle ou telle composante. Et donc, les sujets FinOps à Phoenix, malheureusement, comme beaucoup de gens, ils sont arrivés sur la table un peu par la force des choses. Le contexte, c'est qu'au printemps 2021, donc il y a un peu plus d'un an maintenant, Phoenix vous recrute sur son tout premier DevOps, qui du coup est moi, et on a une application mobile qui se paye une toute nouvelle infra sur AWS Kubernetes. Avant, on était vraiment sur du simple serveur dédié. L'idée, c'était vraiment de prendre ce produit et de le faire grandir en lui proposant une infra cloud native. Donc, l'infra toute neuve est en place au printemps dernier sur AWS.

18:39 Et dès l'été 2021, on a commencé, niveau business, à mettre le paquet sur ce produit-là. Donc, il y a eu des campagnes marketing très fortes. On a eu des gros passages télé, des passages sur Capital, par exemple. S'il y a des gens ici qui sont déjà passés sur Capital, vous voyez de quoi je parle en termes d'activité sur l'application. On a eu une reprise d'activité qui était assez forte dans le secteur par ailleurs. Donc, la charge a énormément augmenté sur ce produit-là d'un coup. Et en réalité, un peu avant qu'on soit prêt pour ça, on avait l'infra, mais on n'avait pas la capacité de maîtriser les coûts de cette infrastructure. Et on a pris deux, trois incidents au début de cette grosse montée en charge. Et ensuite, le... La volonté business de Phoenix sur ce produit-là, c'était, OK, quoi qu'il en coûte, on veut que ça tienne. On met le paquet sur ce produit-là. On veut que ça tienne, allez-y sur l'infra, on vous fait confiance. Si ça coûte cher, ça coûtera cher. Pour donner un exemple de à quel point ça coûtait cher, on avait une facture AWS qui oscillait entre 15 et 20 000 euros par mois à peu près, je dirais au début de l'année 2021.

19:50 Et on a eu un passage à plus de 60 000 en septembre, qui s'est fait d'un mois sur l'autre. Donc, on est sur du 3 à 4 fois plus de facturation. Et donc, on a eu un passage à plus de 60 000 euros par mois. Il y a eu vraiment une perte de maîtrise sur le mois de septembre. Et ensuite, jusqu'à la fin de l'année 2021, ça s'est plutôt stabilisé. Mais quand même, on était juste en dessous des 40 000 euros par mois de coût d'infra. Donc, on est quand même sur un fois deux, voire trois par rapport au coût précédent. Donc, autant vous dire que dans ce contexte, le quoi qu'il en coûte, qu'on a vu quelques mois avant, il a vite été nuancé, ce qui est complètement normal. Mais on a complètement perdu la main sur la maîtrise de nos coûts d'infra. C'était un échec important pour nous, pas juste pour les coûts financiers. Alors certes, pour les coûts financiers, mais pas que pour ça. Aussi parce qu'on a eu la sensation d'avoir une infrastructure qui n'était pas scalable. Parce qu'en fait, être scalable, ce n'est pas juste être capable d'absorber plus de trafic, c'est aussi d'être capable de faire plus de trafic et de croître sans perdre complètement la maîtrise de ses coûts. Il ne faut pas que les coûts montent plus vite ou aussi vite que la hausse de trafic.

20:54 Et puis, accessoirement, on est une entreprise qui a un aspect un peu développement durable et pas juste des questions de greenwashing. Vraiment, dans notre approche, on essaye de faire les choses de manière durable et on se rend bien compte que ce n'est pas durable de se dire que si on veut faire x2 de trafic, je dis n'importe quoi, c'est un peu plus que ça quand même, il faut faire x2 de coût d'infra, on se rend compte que ce n'est pas soutenable comme approche. Et donc, on a vite fait ce constat-là, qu'il y avait un gros problème sur nos coûts d'infrastructure, qu'il fallait prendre ça en main, qu'on a fait vite et bien. Et vous connaissez, je pense, le fameux triangle de coûts. qualité, délai. Si on fait vite et bien, on va faire quelque chose de très cher. Et donc, on a fait vite et bien en 2021 et on s'est dit, fin 2021, début 2022, il faut qu'on trouve un moyen de faire toujours bien, mais qu'on prenne le temps, du coup, de faire moins cher. Et pour vous dire actuellement, on a réussi à redescendre en dessous du niveau d'avant de coût d'infrastructure, donc on est en dessous des 15 000 euros par mois de coût d'infra désormais pour ce produit-là, sachant qu'on a une explosion du trafic qui est toujours maintenue.

22:01 Donc, pour moins cher, on fait… plus de clients servis, on a de meilleures performances et on a un meilleur uptime qu'avant. Donc, comme quoi, en prenant le temps, c'était possible. Et on a donc mis en place plein de bonnes pratiques, plein d'outils. On va échanger là-dessus tout de suite avec François, mais c'est pour vous dire à quel point, et je suis tout seul sur ces sujets-là, même si je suis accompagné par les équipes de développement, etc., mais à quel point il y a des leviers, des fois, sur lesquels, quand on prend le temps de les actionner, on peut faire de très, très, très grosses économies. Et pour montrer aussi à quel point quand on perd le contrôle, les coûts peuvent s'envoler très très rapidement. Ce que je propose, je ne sais pas comment tu préfères peut-être François, je peux vous présenter les mesures qu'on a mis en place, peut-être que tu veux rebondir dessus ou des structures ? Oui, par exemple, peut-être voir un peu par rapport à ton… Quelle a été ta première observation, ton approche? Est-ce que tu as attaqué par… Qu'est-ce qui nous coûte le plus cher et comment je peux réduire les coûts?

23:08 Voilà un petit peu la philosophie, la stratégie. Effectivement, je pense qu'il y a plusieurs stratégies qui peuvent se mettre en place. En tout cas, nous, la première chose qui a été faite, c'était pas mal au feeling en fonction de comment les choses avaient évolué à la hausse en termes de coûts chez nous. La première chose, on s'est dit, OK, qu'est-ce qu'on a allumé, entre guillemets, qui n'est pas nécessaire ou qui n'est pas strictement nécessaire ou qu'on pourrait remplacer d'une certaine manière. Par exemple, on avait... Des environnements de développement qui tournaient la nuit et le week-end alors que personne n'avait rien à faire de les utiliser à ce moment-là et que moyennant une petite lambda sur AWS qui se charge d'aller éteindre les bonnes machines et de taguer correctement ses ressources, on a réussi à faire éteindre les deux infratests, parce que du coup on a trois environnements. Deux environnements de test, les éteindre le week-end, la nuit, et surtout de manière très automatisée, c'est-à-dire que si, je ne sais pas, Ce n'est pas pour une raison ou une autre.

24:10 On a besoin de les utiliser quand même la nuit du week-end. Là, actuellement, je vais sur mon interface AWS, sur ma console AWS, et je clique sur un bouton juste pour désactiver le script qui va l'éteindre. Ce n'est pas quelque chose qui se fait à la main, qui est laborieux sur lequel revenir en arrière. Si on veut, quand il y a des changements en dehors, par exemple en France, et qu'on veut décaler un peu les horaires, ça prend littéralement 5 minutes. Et donc, c'est quelque chose de très automatisé. Donc, notre première approche a été d'identifier, Donc ça, c'est un exemple. En tout cas, d'identifier ce qui n'était pas forcément nécessaire sur notre infrastructure. Et pour ça, on a fait une review de... De tout ce qu'on a en fait en termes de ressources cloud. Et pour ça, on a quand même été beaucoup aidé par le fait qu'on utilise, qu'on fait de l'infrastructure à ce code. Et donc, nos ressources, on n'est pas obligé d'aller, les chercher un peu dans tous les coins de la console AWS. Elles sont toutes as code dans du code, donc on utilise Terraform en l'occurrence pour l'infrastructure as code, mais ça fonctionnerait pareil sur AWS si vous utilisez CloudFormation ou d'autres outils sur d'autres cloud providers.

25:14 Le fait d'avoir as code, ça permet de faire des recherches un peu plus poussées et intéressantes sur ce qu'on a comme ressources, des types d'instances qu'on utilise, etc. Et puis d'éviter des erreurs humaines dans l'automédication derrière. Ça fait partie des très nombreux intérêts de l'infrastructure Ascode. Je pense que je ne le vendrai jamais assez, je pense, l'infrastructure Ascode. Mais ça fait partie des multiples avantages. C'est qu'on sait ce qu'on a. Et du coup, quand on cherche à savoir ce qu'on a de déployé sur notre infrastructure, On peut regarder dans notre base d'infrastructures à ce moment-là. En réalité, les grands cloud providers proposent des outils pour pouvoir un peu faire un audit des coûts. On a aussi utilisé, c'est un produit que DoiT nous propose, qui est donc un... Des graphes pour explorer nos coûts de cloud. On aurait pu, alors ça marche très bien l'outil DoiT, après on aurait pu utiliser peut-être la console AWS, le Cost Explorer.

26:17 Il se trouve que nous, on a l'habitude maintenant de travailler avec l'outil DoiT, mais en gros, identifier où étaient les coûts qui ne servaient à rien et à quel moment. C'était la première approche. Et ensuite, on a eu plutôt l'approche de dire, maintenant, il y a... des choses qu'on utilise, peut-être qu'on pourrait optimiser nos performances pour ne plus les utiliser ou revoir notre architecture pour ne plus utiliser, soit utiliser moins de ressources, soit les utiliser mieux ou utiliser des services managés qui coûteraient moins cher au final que de refaire la roue nous-mêmes, ce genre de choses. Mais vraiment, notre première approche, c'était... qu'est-ce qui ne sert à rien et en fait on avait beaucoup de choses mine de rien qui s'étaient entassées avec le temps. Et puis est-ce que vous avez après appliqué par exemple un modèle d'éclatement des comptes par exemple? C'est-à-dire que vous avez sur AWS, c'est vraiment hyper pratique, c'est une des... Des facilités qu'on peut avoir, c'est d'avoir un compte pour la prod, un compte pour le dev, pour la pré-prod, parce qu'après, c'est quand même vachement plus simple pour analyser les coûts, parce qu'on peut tout traquer grâce à ça.

27:21 Complètement. Avec une nomenclature dans les tags, ça c'est aussi ce que vous avez fait. Exactement, c'est ça. Il se trouve qu'on avait déjà des environnements, des comptes par environnement. Donc, on a un compte AWS pour notre prod, pour notre pré-prod, pour notre environnement test, etc. Donc, on a nos comptes AWS pour chacun de nos environnements. Mais effectivement, on est allé au-delà de ça. Et actuellement... Alors, je n'ai pas de chiffres à vous donner, mais à l'instinct, je dirais que 95% de nos ressources AWS sont taguées avec des informations correspondant aux produits, puisqu'on a plusieurs produits, du coup, on a trois produits techniques, donc correspondant aux produits qu'ils utilisent, à l'équipe qui va l'utiliser, plus pour des questions d'accès. en réalité, et avec différentes autres, avec des tags pour des sous-services, etc. Mais effectivement, comme ça, on peut explorer nos coûts en fonction des tags et on peut déclencher des actions, par exemple, éteindre certaines ressources en fonction de nos tags. Et ça, ça a été un gros chantier, effectivement, de taguer toutes nos ressources. Ça, ce n'était pas du tout le cas avant. Autant on avait des comptes, mais taguer toutes nos ressources, c'était un très gros chantier. Et là, encore une fois, on a un très gros intérêt de l'infrastructure Ascode qui émerge, c'est que comme nos ressources sont provisionnées avec du code Terraform, donc de l'infrastructure Ascode,

28:33 on a littéralement un module, une librairie Terraform qui se charge de taguer une ressource AWS, en tout cas de fournir les tags à donner une ressource AWS, Et quand on produit du code Terraform, non seulement il y a des reviews, donc si quelqu'un oublie de taguer, on va le voir. Et en plus, la politique de tagging est uniforme de partout parce que c'est un même module qui va se charger de taguer toutes les ressources, en fonction des données qu'on a sur la ressource. Et ça, vraiment, ça a été un assez gros chantier qu'on a mis rapidement en place parce que je pressentais que ça nous aiderait à avoir un peu plus de visibilité. Et maintenant, on ne regrette pas du tout. C'est extrêmement pratique. On a besoin de faire des évaluations de coûts, même pas juste pour faire la réduction de coûts, mais juste voir l'évolution. Par exemple, on arrête d'utiliser un service à manager pour un autre. On peut voir un peu l'évolution dans le temps de comment les coûts ont évolué. Est-ce que ça a été intéressant, pas intéressant, etc. Donc, le tagging aussi, très, très important dans les sous-services. qu'on a mis en place. Et donc après, ça c'est pour le compute, parce qu'en fait ce qu'on voit maintenant, il y a un autre modèle qui est le serverless, en fait maintenant c'est serverless versus IaaS.

29:47 En fait, souvent, ce qu'on constate, c'est que le serverless est quasi tout le temps moins cher pour des projets qui, en fait, ne nécessitent pas beaucoup de charges. En fait, moi, ce que j'ai vu, c'est que la plupart des projets, qui sont lancés sur des instances EC2 ou des infras type CS, EKS, en fait, ils n'ont pas besoin d'avoir autant de workload. En fait, ils pourraient très bien fonctionner sur du serverless parce que vous paierez moins cher parce que vous allez payer, au lieu de payer à la machine, vous allez juste payer à la quantité de CPU et de RAM. En fait, de ce qu'on dit un peu dans l'industrie, c'est qu'on parle d'un abattement de 75% de réduction comparé à une archi habituelle, une archi serverless et une archi qu'on voyait de manière régulière. C'est pas serverless, il ne faut pas voir que comme un avantage technique, ça peut être aussi un avantage financier. Et donc là, par exemple, est-ce que tu as d'autres workloads serverless ou des choses qui pourraient amener de la matière en exemple?

30:59 Pardon, excuse-moi. Non, vas-y, vas-y. Avant que tu termines. Mais sur ces sujets-là, on manque encore un peu de maturité, je pense. Mais on est en train de migrer certaines choses sur du serverless. On a des... Alors essentiellement nos produits ça reste du web, donc des API web, même si c'est du mobile ça reste des API web etc. Qui pourraient complètement être déportés. L'architecture applicative reste encore un peu compliquée à découper. à découper en petites fonctions qu'on pourrait mettre dans du serverless. Cependant, on a certains gros workloads de traitement. Par exemple, je pense à notre plateforme B2B où il y a des commerçants qui vont importer leurs bas articles. Donc, on est sur des gros CSV sur lesquels il va falloir qu'on fasse du parsing, de la complétion de champs, qu'on aille agréger des données depuis d'autres API. Je pense par exemple à Open Food Fact, ce genre de choses, récupérer des données externes, les traiter sur ce fichier et les mettre dans nos bases de données.

32:00 Et donc, sur ces sujets-là, comme c'est des traitements un peu lourds, un peu longs, on commence à avoir une approche où on dit, OK, on va découper ces traitements-là en petites tâches qu'on va mettre dans une file SQS et qui vont être dépilées par des fonctions Lambda en serverless. Mais les fonctions, disons, de réponse directe de nos API, de nos interfaces web ne sont pas déportées du tout sur du serverless. Je pense que pour le coup, on est un peu loin de ça chez Phoenix encore. Mais effectivement, les gros workloads, on sent qu'ils sont un peu longs à s'exécuter et où typiquement, comme on a beaucoup, on a essentiellement, on a quasiment, on essaye de mettre tout ce qu'on a en termes de compute dans du Kubernetes, essentiellement pour la simplification de gestion d'infram de notre côté. Et tout ce qui ne peut pas vraiment rentrer dans ce cadre-là, typiquement un long workload qui va mal supporter une interruption ou d'être déplacé sur notre machine, on commence à découper, à mettre ça dans du serverless. Mais certes, on économise. sans doute des coûts, mais c'est vrai que ce n'est pas par cette motivation-là qu'on y est arrivé en fin de compte en réalité.

33:06 D'accord. Si je peux me permettre, Kyane, j'ai une petite question parce que je t'entends parler depuis un petit moment et puis tout ce que tu as mis en place, tu es tout seul pour mettre ça en place. Est-ce qu'il y a une intervention assez… Parce qu'effectivement, il y a beaucoup d'adaptations. Pour l'avoir fait il y a maintenant un an et demi au sein d'IntégraGène, on a dû faire intervenir pas mal de partenaires. Comment tu gères cela? Alors, à Phoenix, on a une approche qui est de dire que potentiellement, on va garder une personne, peut-être une deuxième à un moment, sur cette fonction transverse un peu DevOps. Et l'idée est de dire qu'on a des squads de devs produits sur chacun des produits. On a des devs, des équipes produits, des équipes support, etc. Et dans chacune de ces squads, on va créer des relais un peu sur les questions DevOps infrastructure. Et mon rôle va plutôt être un facilitateur des besoins de chacun.

34:08 Je prends un exemple, c'est très bien comme formulation. On a une nouvelle pipeline de CICD qui est nécessaire, par exemple, pour un nouveau produit, pour un nouveau composant, pas d'infra, mais applicatif. L'équipe qui développe va écrire les règles de sa pipeline de CICD. Moi, mon rôle, ça va être de faciliter le fait qu'ils vont pouvoir écrire ça de manière simple, ils vont pouvoir reprendre sur l'étagère un outil de CICD qui fonctionne, des librairies, par exemple, dans leur pipeline de CICD, s'il y a besoin de déployer sur Kubernetes, ils vont juste reprendre une fonction que j'aurais écrite qui serait déployée sur Kubernetes et eux, ils peuvent la reprendre. Donc, l'idée étant que je fabrique un framework petit à petit qui peut être utilisé par les équipes de développement sur les questions de... infrastructure. D'accord, il y a un transfert de compétences envers les équipes, donc un rôle aussi de training envers les équipes qui montent en compétence.

35:09 Exactement, c'est ça, exactement. L'idée étant de leur donner l'autonomie, pas uniquement pour faire des économies et recruter moins de gens sur l'infrastructure. Certes, on pourrait le voir comme ça, ça peut peser dans la balance, mais l'idée aussi étant qu'en donnant plus d'autonomie aux équipes de développement, déjà c'est pour moi ça la vraie philosophie de l'Obs, c'est pas juste une équipe qui fait de l'infra ça dépend des contextes évidemment mais dans notre cas c'est comme ça qu'il faut qu'on fasse dans le cas de Phoenix je pense à la bonne approche c'est de les faire monter en compétence de leur donner de l'autonomie de leur donner des outils qu'ils peuvent utiliser facilement parce qu'en fait Sinon, ils ne vont pas les utiliser. C'est comme les problèmes de sécurité. Si la sécurité, c'est de dire qu'il faut que vous fassiez comme ça, les gens n'aiment pas. Regardez, on a fait un outil pour que vous puissiez faire les bonnes pratiques. C'est super simple à utiliser. Là, les gens veulent le faire. C'est un peu pareil sur les sujets en phrase qu'on essaie de faire à Phoenix. Ok, top. Merci. Et donc, en fait, il y a d'autres segments aussi, parce que là, on a parlé du compute, mais en fait, les gros segments de dépenses, c'est quoi?

36:17 C'est le compute, le network, la data. Et puis maintenant, ce que je vois arriver aussi un petit peu, c'est le ML. Et donc, si on reprend un petit peu, est-ce que tu as, par exemple, travaillé sur des parties network, peut-être avec, je ne sais pas, de la distribution? Parce qu'en fait, tu vois, par exemple, il y a des axes qu'on peut attaquer avec... De la bande passante au niveau des load balancers parce qu'en fait ces coûts en fait ils dépendent du volume de données qui va être ingéré et puis transporté et puis en fait il y a des mécanismes faciles et puis après même qu'on peut même automatiser pour gagner en coût quoi et Qu'est-ce que toi, par exemple, tu as vu sur cette partie network? Est-ce que ça a représenté un coût non négligeable, important sur ton infra?

37:21 Nos coûts network ne sont pas significatifs par rapport au reste de nos coûts. C'est vraiment des sujets qui, pour le coup, vraiment très honnêtes, qu'on n'a pas du tout étudiés. On sait qu'ils sont là, on peut les mesurer. mais c'est quelque chose qui est très peu significatif par rapport à notre manière d'utiliser les infrastructures cloud. Les gros postes de dépense qu'on a sont effectivement de compute. Et dans le compute, le plus important, c'est vraiment les bases de données chez nous. C'est là où on a eu le plus gros levier de réduction de dépenses. Exactement, de la base de données RDS, Aurora en l'occurrence. On a encore des pistes d'amélioration. Je me demande si on ne va pas utiliser Aurora Serverless V2 pour notre application mobile. Ça fait partie des choses futures qu'on va creuser. On n'en est pas encore sûr. L'idée n'étant pas non plus de... De trop se fermer sur des technos propriétaires d'un cloud provider. Je pense que ça reste aussi quand même une contrainte que beaucoup de gens peuvent avoir en tête et qu'on a nous en tête aussi à Phoenix puisqu'on travaille avec des gens qui font du retail et on sait que des fois la marque AWS peut leur poser problème.

38:32 Donc on essaye quand même dans notre approche d'utiliser de manière intelligente les services managés, de ne pas choisir quelque chose qui nous refermerait trop. Donc pour ça, sur certains aspects, machine learning, on n'en a pas vraiment encore, encore, je dis bien encore, à Phoenix, mais sur les questions serverless, on essaye de garder des choses où on pourrait, si on a besoin de bouger pour des clients très spécifiques, on pourrait faire ça sans trop s'enfermer. C'est un jeu d'équilibriste, ça, clairement. Non, mais c'est vrai parce que tu parlais de SageMaker et moi, en fait, ce qui est... qui est top avec SageMaker, c'est que les data scientists, en fait, ils n'ont pas besoin de SRE. En fait, ils n'ont pas besoin de faire appel à ces personnes-là pour construire une infra. Mais par contre, c'est bien pour démarrer, mais par contre, après, on constate que le coût, en fait, il est peu maîtrisable. Parce qu'en fait, les gens qui pilotent, comme les data scientists, en fait, ils n'ont pas une vocation infra. Et puis, du coup, ils ont du mal à identifier dans SageMaker quels seraient les types d'instances idéales.

39:39 Voilà, c'était juste une parenthèse qui sort. J'en profite, François, j'ai une question justement à ce sujet. Quel est ta reco? Si tu en as une, effectivement, on est tous soumis à ça à un moment dans notre développement. Il faut aller vite parce que sinon, on va être à la traîne. Et donc, un développement assez conséquent. Pour ma part, les développements sur lesquels on est, c'est avec des grosses quantités de données, puisque c'est des données génomiques. Donc, on parle d'ADN, on parle de gigas, voire de teras de data. Donc, on est déjà content, effectivement, quand tu parlais d'efficacité, on arrive à notre but, on arrive à analyser. Il faut qu'on aille vite. Donc, on arrive à analyser en un temps à partie puisqu'on fait sur des sujets de santé. Et parfois, on met le coup un petit peu à la traîne et notamment ces aspects de FinOps sur lesquels on s'attarde aujourd'hui. Mais c'est toujours, est-ce qu'on le met dès le départ? C'est l'idéal puisqu'on va pouvoir optimiser au fur et à mesure, mais au détriment de la rapidité dans laquelle on va aller dans le développement. Ou alors, de toute façon, il faut sortir le produit rapidement.

40:41 On verra après pour optimiser un petit peu la démarche, si j'ai bien compris, que Kyâne a suivi. C'est exactement ça. Au départ, oui, c'est sûr, pour accélérer. Et comme on n'a pas forcément tout à disposition, on a des services managés qui peuvent nous mettre le pied à l'étrier rapidement. Mais en fait, le truc, c'est qu'il ne faut pas perdre pied sur les questions qu'on doit se poser. À un moment donné, il faut se dire, quand tu vas regarder ton... Ton dashboard de coût, il faut que tu te poses toujours la question, est-ce que je suis satisfait du coût que j'ai par rapport à mon utilisation? Et en fait, il faut toujours remettre en cause ça, c'est une question perpétuelle. Alors, le truc, c'est que... C'est sûr qu'aller vite, ça ne permet pas forcément de se poser pour faire du design, du bon design. Parce que derrière, comment dire, il ne faut pas se laisser enfermer.

41:48 Et là, notamment, on parlait de SageMaker. Moi, ce que je vois souvent, c'est que les gens se laissent enfermer rapidement parce qu'ils n'ont pas pris le temps. Au milieu de leur développement ou alors à un moment donné de se poser et puis de redéfinir un petit peu voilà on a quelque chose qui tourne maintenant posons-nous regardons si on ne peut pas refaire l'archi pour ne plus être dépendant en fait c'est ça c'est la dépendance qu'il faut détruire et en tout cas éviter pas forcément détruire mais éviter parce que derrière c'est un bloqueur donc ensuite il y a vraiment identifier ce que je disais au début, les bons indicateurs, les bonnes métriques. Donc tu vas lancer ta nouvelle infra, ta nouvelle archi, tout de suite il faut que tu te mettes des outils de BI, de Business Intelligence, qui va te permettre de suivre ton coût au jour le jour.

43:00 Voilà, pour ne pas avoir déjà de surprise. Et puis après, ça va te permettre de poser un budget derrière. En fonction du temps qui passe, et puis de la charge que ça amène, tu pourras prédire, ça va donner des éléments pour prédire ton futur coût. Très bien, je te remercie. Kyâne, j'aurais été intéressée que tu nous parles un peu des performances que tu as obtenues avec les solutions DevOps que tu as déployées chez toi. Oui, bien sûr. Alors, de notre côté, pour dire, nos économies, elles ont fait l'objet d'une règle 80-20 un peu classique, c'est-à-dire qu'il y a quelques mesures qu'on a prises qui nous ont fait faire 80% de nos réductions de coûts. Et puis d'autres qui ont été plus pour grappiller, pour se dire qu'on a optimisé au maximum les coûts. Sur les grosses réductions dont j'ai parlé tout à l'heure, que j'ai évoquées en termes de chiffres, il y en a une où on passe d'une facture qui est à peu près de...

44:08 De un peu moins de 40 000 euros par mois à quelque chose qui ressemble plutôt à 20 000 euros par mois. Ça, c'est quasi exclusivement l'optimisation de notre applicatif qui, en fait, sollicitait énormément notre base de données. Je peux l'expliquer en deux mots techniquement à quoi ça ressemblait, c'est relativement simple. C'est une application où quand on l'ouvre, On a accès aux commerçants qui se trouvent autour de nous. Donc, à l'ouverture d'une application, on a une carte avec les commerçants qui se trouvent autour de nous. Donc, l'une des premières requêtes après l'authentification que fait notre application mobile, ça va être de demander autour de telles coordonnées géographiques quelles sont les personnes qui sont là. Et jusque-là, le back-end faisait des grosses requêtes dans la base de données, assez peu optimisées pour, en gros, lister tous les commerçants. faire des calculs de coordonnées. Et on a juste passé, là l'équipe de développement a fait un super boulot sur un petit outil qui s'appelle les GOH, qui sont, je vais le faire très rapidement, mais en gros c'est une manière d'encoder, de géocoder des coordonnées géographiques.

45:17 Et surtout, ça nous permettait de mettre en cache ces choses-là, ce qui fait que, par exemple, s'il y a 15 personnes qui ouvrent l'appli dans le même arrondissement de Paris, concrètement, les commerçants qui sont autour sont les mêmes. Et donc, cette information-là, on la met en cache. Et ça, on l'a mis en place parce qu'on s'est rendu compte que nos plus gros coûts, c'était nos bases de données et que la charge de nos bases de données, c'était 80% peut-être uniquement une requête qui était donc celle la plus faite de notre applicatif vu que c'est la première qui est faite. Et on s'est dit, OK, il faut qu'on batte à fond sur cette requête-là. Pourquoi? Comment on fait pour l'optimiser? Et donc là, on a divisé par deux notre facture juste en bossant là-dessus et puis en faisant les bonnes solutions techniques. Bon, ça, c'est très spécifique à notre cas de figure. Ça se généralise un peu moins. Par contre, quelque chose qui est un peu plus générique et qui, du coup, nous a fait faire peut-être 80% du reste des économies qu'on a fait, c'est d'optimiser notre utilisation de ressources. Donc, comme je l'ai dit, on fait tourner nos back-end applicatifs dans Kubernetes. Donc, il y a des machines qui sont provisionnées, du compute qui est provisionné dans notre cluster et qui provisionne des ressources de mémoire, de CPU, etc.

46:25 Et en fait, ces applicatifs qui sont dans le cluster, on leur... réserve une quantité de ressources. Et ces valeurs-là, elles étaient mises un peu aux doigts mouillés quand on a commencé, puis on ne les a jamais trop touchées. Et on s'est rendu compte qu'en ayant de la bonne métrologie et en regardant l'utilisation réelle en termes de ressources de nos applications, on s'est rendu compte, par exemple, qu'il y avait des back-end applicatifs, auxquels on octroyait, je dis n'importe quoi, 4 Go de RAM, alors qu'en réalité, dans le pire des cas, dans le plus gros des pics, ils ont consommé 2. Et quand on ajuste ces ressources-là au cas d'usage réel de notre applicatif, on se rend compte qu'en fait, on peut économiser beaucoup de compute qu'on surprovisionnait. Et on ne s'en rendait pas forcément compte parce que ça fonctionnait et puis on n'était pas forcément bien outillé en termes de métrologie au début. Et donc pareil, c'est ça. Là, on a gagné pareil, je pense, sur notre facture restante, 5 000 euros par mois à ce moment-là. Donc c'était plutôt des très bonnes perfs. Et pour moi, c'est vraiment le...

47:27 Le truc le plus important, quand on commence sur ces sujets-là, il faut s'outiller. Il faut s'outiller pour observer ses coûts et il faut s'outiller pour observer son utilisation de ressources applicatives. Quand on a ces deux outils-là, ensuite, les solutions vont venir presque d'elles-mêmes et presque naturellement parce qu'on va voir où est-ce qu'il y a des dépenses et on improvisera dessus. Et d'ailleurs, j'ai une question pour en dire là-dessus, parce que, OK, on observe, après on applique, et en appliquant, on peut automatiser. Donc là, du coup, c'est très bien, mais parfois, en fait, juste... Arriver à un résultat, et en tout cas, ça demande un effort d'automatiser. Et du coup, est-ce que des fois, tu as rencontré des cas où cet effort n'allait pas se révéler payant par rapport au ratio, justement, effort-bénéfice que ça allait apporter? Est-ce que tu as des exemples là-dessus? Oui, on a un petit exemple. Par exemple, le cas d'éteindre nos infrastructures la nuit sur les environnements de dev, on s'est dit, est-ce qu'on ne pourrait pas avoir, du fait de notre activité qui est quand même très...

48:40 Pas juste française, mais qui est très Europe de l'Ouest, Europe du Nord, Est-ce qu'on ne pourrait pas avoir une politique d'autoscanning plus agressive que ce qu'on a maintenant sur l'infra de prod? C'est-à-dire qu'en gros, on diminue beaucoup le nombre de serveurs la nuit. On en garde évidemment, parce qu'on sert quand même des zones internationales ou même les dom-toms, juste qu'il faut bien les servir. Et sur ces sujets-là, le problème, c'est que nous, notre trafic, il est très, très... Il est très focalisé sur des instants très précis, typiquement à 8h du matin, quand il y a tous les commerçants qui publient en même temps leur panier anti-gaspi, ça envoie une notif aux gens qui sont abonnés. Donc là, on a un pic d'un coup d'utilisation. Et en fait, il y a différents moments comme ça dans la journée. Et on s'est dit, bon, on fait un script pour... pour faire de l'autoscaling juste avant que le pic arrive, parce qu'en fait, le pic est tellement rapide qu'en fait, il faut que l'autoscaling réagisse avant et donc il faut qu'on fasse du scripting pour ça. Et on s'est dit qu'on ne trouvait pas ça très intéressant parce que ça nous obligeait à déterminer nous-mêmes à l'avance quels sont les moments de la journée où il va y avoir du trafic et du coup déclencher des trucs à heure fixe.

49:52 Mais si un jour le comportement utilisateur change, je ne sais pas, sur les fêtes de fin d'année ou pendant les vacances, il va changer. En fait, on sentait qu'on allait se mettre dans une situation compliquée qui n'allait pas être rentable. Par contre, on est en train de réfléchir à pouvoir utiliser de la métrique. On pousse beaucoup de métriques dans Datadog. Et Datadog nous propose de la prédiction sur nos métriques quand il y a un certain historique. Et là, on commence à se poser la question de se dire, est-ce qu'on n'utiliserait pas de la métrique prédictive de Datadog pour justement ajuster nos tailles d'infrastructure là-dessus? On ne sait pas encore, on pense que ce serait une bonne idée, mais il faut qu'on fasse un POC avant de le mettre sur la probe. Ok. Pardon, tu voulais prendre la parole, Bérengère. Oui, c'est dans le même état d'esprit. En fait, quelle serait pour toi la répartition entre bonne pratique et automatisation? Dans le sens où, comme tu l'as très bien expliqué, à un moment, il n'est pas forcément utile d'aller vers de l'automatisation. Mais j'entends ça par aussi bien en termes de temps de développement, c'est-à-dire faire de l'automatisation, ça prend du temps.

50:54 Et également, on va dire le fait que tous les utilisateurs aient ces bonnes pratiques parce qu'à tout moment, il faut, nous on avait le cas par exemple, éteindre les machines parce qu'il y a une analyse qui doit durer pendant 5 jours et il ne faut pas la couper. Donc voilà, quel est pour toi le bon équilibre? Je dirais que c'est un peu compliqué à dire parce que je pense que ça dépend beaucoup des situations. À mon avis, ce qui est important, c'est d'être pragmatique. Moi, je vois en tout cas dans notre expérience, c'est vrai que quand les coups d'infras s'envolent, on peut vite être sujet à se dire« Oulala, c'est la panique, comment on fait? » et à essayer d'éteindre des trucs rapidement. Je pense qu'il faut prendre le temps de bien s'outiller. Donc, les deux typologies d'outils dont je parlais avant, bien s'outiller pour avoir une bonne idée claire de où part l'argent, littéralement. Et ensuite, être hyper pragmatique. Moi, j'ai en tête des choses où je sais qu'on n'est pas dans les bonnes pratiques, qu'on pourrait optimiser en automatisant mieux certains de nos process, nos workloads, mais que ça va nous faire économiser

51:55 20, 50, 100 dollars par mois, ce qui peut être significatif dans certains cas, mais qui, au regard de notre facture mensuelle, n'est pas à impact. Et donc, ces sujets-là, OK, on n'est pas à la parfait sur les bonnes pratiques ou ces choses-là. Par exemple, je parlais de 95% de nos ressources à vue de nez qui seraient labellisées. Il y en a où on n'a pas trop de suivi, mais on sait que ce n'est pas grave. Je suis pragmatique, je me dis, tant que notre base de données, nos computes et certains de nos workloads un peu asynchrones sont bien identifiés, que les ressources sont bien taguées, qu'on a un bon suivi dessus, qu'on fait les bonnes pratiques dessus, je sais que sur 80% de notre facture, globalement, on est... On est dans les clous et on fait les bonnes choses. Je pense qu'il faut le prendre avec pragmatisme et faire au long. C'est très classique, des règles de 80-20, réfléchir un peu. Mais ça dépend des cas de figure. Non, mais tu as répondu à ma question, je te remercie.

52:58 François, tu avais une question. Oui, parce qu'en fait, tu parlais de POC tout à l'heure, Kyâne, et justement, il y a peut-être des petites choses que tu es en train de tester, notamment avec Kubernetes. Parce qu'en fait, moi, ce que je vois, c'est qu'avec toutes les initiatives dans le monde Kubernetes, en fait, il y a un réel challenge qui est en train de se positionner. Avec des modèles qui permettent de mutualiser les infras. Est-ce que toi, tu as des choses comme ça qui partent dans cette direction? Est-ce que tu es en train de tester des petites choses dans ce style? Effectivement, ça va avec notre approche à Phoenix de dire qu'il y a une personne transverse sur les sujets d'infra et des relais dans chaque équipe. Là, j'ai quand même beaucoup parlé, sans le dire clairement, mais je parlais beaucoup de ce qu'on fait sur notre application mobile. Mais sur nos autres produits, notre plateforme de dons, typiquement entre les retailers et des associations, on va être sur des infras beaucoup plus classiques, qui ne sont même pas encore tout à fait complètement sur AWS, où c'est un serveur sur lequel on fait tourner le backend.

54:05 Et en réalité, ça fonctionne. On n'a pas de problématique par rapport à ça, à part de la résilience. Mais notre idée, c'est d'aller vers une infra un peu plus commune, un peu plus mutualisée à tous nos produits pour pouvoir déjà mutualiser les bonnes pratiques et s'assurer que les bonnes pratiques FinOps, mais aussi de sécurité ou sur plein d'autres sujets, elles sont suivies de la même manière de partout. Donc ça, c'est quelque chose qu'on est en train de faire et on expérimente de plus ou moins tout mettre dans Kubernetes parce qu'on a globalement des applicatifs qui s'y prêtent bien, c'est du web. Il y a des gens qui disent que c'est incroyable de tout faire, il y a des cas de figure où c'est un outil qui ne se prête pas à certains cas de figure. Mais dans notre cas, ça s'y prête très bien et on essaye de tout pousser dedans pour faciliter nos gestions d'infra et mutualiser nos bonnes pratiques. Et donc, on fait ça petit à petit, on migre nos applicatifs dessus. Kyâne? Super, merci François. On pourrait rester, je pense, encore une heure, deux heures à discuter.

55:06 Bon, il n'y a pas eu de questions, mais tant mieux, j'ai pu poser mes questions au fur et à mesure également. Je vous invite tous à nous rejoindre maintenant sur la plateforme de networking pour poser directement vos questions à François ou à Kyâne. Donc, à tout de suite de l'autre côté. Merci beaucoup. Merci.