FinOps

0:15 Bonjour à tous, vous m'entendez bien ? Je suis Marie-Caroline Bénézet, je suis aujourd'hui directrice des opérations de la transformation du groupe SMCP. Le groupe SMCP, c'est un groupe de mode qui fait du retail et bien sûr du e-commerce aussi. Et je suis très heureuse aujourd'hui d'accueillir d'abord Cyril, Cyril Deblois, puis Emmanuel Cordente, qui vont nous parler de cloud et de stratégie de migration, et puis aussi de comment on gère le run, comment on vérifie. s'assure qu'on atteint les objectifs qu'on s'est fixés. Donc, ce sera à la fois assez… Enfin, on va essayer d'être assez… au niveau de regarder un peu de loin le sujet, mais aussi d'être assez concret et de parler un peu des écueils, des risques ou des conseils qu'on peut avoir en matière de migration. Bonjour Cyril, merci de m'avoir rejoint. On va commencer avec toi. Donc Cyril, tu travailles chez AWS et tu vas nous en dire un peu plus.

1:18 Travail et puis un peu plus sur toi. Je te laisse commencer. Ok, merci Marie-Caroline. Bonjour à tous, je m'appelle Cyril Leblois, je m'occupe de Cloud Financial Management chez AWS, ça correspond à la fonction FinOps et j'accompagne nos clients dans la mise en place des bonnes pratiques sur ce sujet et on va en parler un petit peu aujourd'hui. Si je comprends bien, toi tu travailles plutôt une fois que les clients ont migré dans le cloud, une fois qu'ils sont déployés dans le cloud pour les aider à... Mieux utiliser le cloud et surtout mieux y être plus clair dans la stratégie économique? Est-ce que tu peux nous expliquer un peu? C'est ça. Donc, j'appartiens à une équipe qui s'appelle Cloud Economics, qui a pour but de quantifier les bénéfices d'une migration, que ce soit sur une dimension de TCO, mais aussi sur les autres dimensions. Donc, il y a une partie de l'équipe qui aide les clients à construire des business cases de migration, donc en général, un environnement on-premise vers AWS. Et ensuite, effectivement, mon équipe intervient, puisque une fois qu'on a fait la migration, on va constater une partie de ses gains.

2:24 En fait, ça ne s'arrête pas là. Finalement, le cloud, c'est un des bénéfices de la migration, c'est qu'au fil du temps, avec la connaissance plus fine de ce qui se passe sur la plateforme, on va pouvoir continuer à optimiser. Mais ça demande à la fois d'un savoir-faire spécifique et puis s'habituer aux outils, des choses comme ça. Ça n'arrive pas par défaut, il y a des choses à faire. Et donc, mon métier, c'est d'aider les clients à faire ces choses, justement. Et justement, en parlant de clients, c'est quel type de client, quelle taille de client et quel type de personne à l'intérieur des clients? Pour qu'on figure un peu mieux avec qui tu travailles. D'accord, donc je fais partie d'une équipe de 11 personnes en Europe. Moi, je m'occupe de la France et d'Israël. Je m'occupe principalement des clients les plus importants à titre personnel avec des relations suivies dans le temps, donc des récurrents. Après, selon les tailles de clients ou les types de projets, je vais intervenir plus en... On va dire en qualification du besoin et derrière je vais articuler différentes équipes AWS ou même des partenaires qui vont pouvoir accompagner les clients.

3:30 Et je travaille aussi sur construire du contenu qui soit accessible en self-service aussi pour que des clients pour lesquels, comme je suis tout seul pour la France et l'Israël, je ne peux pas adresser tous les clients, mais nous voulons, je disais, de quoi évidemment pouvoir travailler sur ces sujets, qu'il y ait quelqu'un comme moi qui soit disponible ou pas. Et donc, je construis aussi du contenu. Donc, le framework de bonne pratique, j'y contribue. On a chacun une spécialité, des choses comme ça. Ok. Alors, tu viens d'aborder la question du framework de bonne pratique. Est-ce que tu peux nous en dire plus? Ce que tu me racontais en préparant, c'est que ça s'articule autour de quelques grands piliers. Est-ce que tu peux nous expliquer justement quelle est votre méthodologie ou votre vision sur cette question? Ok, donc il faut comprendre, et bon c'est assez connu mais je vais le rappeler, c'est que la plupart de ce que l'on crée chez AWS, ça vient des clients, on va dire entre 90 et 95. à la fois des nouveaux services ou des features via des clients.

4:35 Et c'est pareil pour ces frameworks. C'est-à-dire qu'évidemment, nous, on essaie d'être force de proposition, mais on va beaucoup apprendre de nos clients, les aider face aux difficultés qu'ils peuvent rencontrer, par exemple, et à créer des choses pour ça. Ce qui veut dire que sur ce framework, à l'origine, on travaillait principalement sur l'optimisation des coûts. Qui est la demande principale, c'est un des drivers dans l'immigration. Donc nos clients nous demandaient, est-ce que vous pouvez nous aider? Comment est-ce qu'on peut faire ? Et donc moi, initialement, ça fait trois ans que je fais ce rôle, mon métier, il était finalement d'auditer une facture AWS et d'aider le client à réduire cette facture. Alors moi, j'aime bien ce côté-là, c'est quand même assez significatif sur comment AWS voit la relation à long terme avec ses clients. Et puis en fait, on s'est aperçu qu'à partir de ce besoin initial, la réduction des coûts, en fait, il y avait d'autres choses à faire pour être efficace sur ce sujet-là. Donc, c'est comme ça que les autres piliers se sont créés. Donc, le premier, c'est celui sur la visibilité. Donc, c'est quelles sont les bonnes pratiques pour comprendre de manière très fine comment je suis facturé par AWS.

5:39 Donc, ça veut dire la granularité par type de service. Qui sont les utilisateurs chez moi qui génèrent quel coût? Ensuite, une fois qu'on a cette visibilité, on va pouvoir faire de la responsabilisation. Donc, ça veut dire petit à petit amener les gens à se rendre compte que certains choix techniques impliquent une génération de coûts particuliers. Alors que historiquement, dans l'environnement on-premise, c'est évidemment le développeur à moins cette question à se poser. Là, c'est important qu'il puisse y répondre au moins en partie. Ensuite, il y a le côté KPI, donc les facteurs clés de succès, les définir, mettre en place des logiques pour les tracer, qui va être responsable, des choses comme ça. C'est le premier pilier dans la visibilité. Le deuxième, c'est sur la partie optimisation des coûts. C'est des choses qui sont assez établies depuis que le cloud existe, le cloud public et le cloud privé. partie qui est commune. On sait à peu près ce qu'il faut faire. Ce qui est difficile, en fait, c'est de l'implémenter de manière programmatique, c'est-à-dire à la fois de manière automatique.

6:40 Il y a un côté change management, finalement, qui n'est pas qu'une histoire d'outils, des choses comme ça. Donc là, il y a toute partie de la pratique sur ce sujet. Le troisième, ça concerne tout ce qui est forecast, budget, donc là, plus la projection. Dans le futur que j'imagine d'utiliser AWS pour un besoin particulier, comment je m'y prends pour comprendre quels seront les coûts, quelle est la marge d'erreur. Et donc on a Emmanuel qui va nous apporter un témoignage juste après plus précis sur ce sujet, parce que lui, il a conduit et il conduit encore des gros projets sur ce sujet-là. Le dernier pilier, il est plus un petit peu opérationnel, donc c'est qu'est-ce qui change finalement dans la façon d'opérer un système informatique lié au cloud. Donc il y a des choses à changer, évidemment, pas tout. C'est heureusement pas une façon complètement de travailler différente. Donc on va retrouver dans ce pilier des parties qui sont plus spécifiques au change management. Donc ça veut dire qu'il y a certaines bonnes pratiques qui ne sont même pas spécifiques au cloud. Finalement, n'importe quel changement...

7:40 d'envergure en entreprise va demander les mêmes besoins. Donc, si je résume et si c'est bien compris tout ce que tu nous racontes, tu dis quatre piliers, quatre angles que l'on regarde, que l'on devrait regarder pour améliorer, optimiser ou… ou tout simplement bien gérer son cloud, c'est un, la visibilité, alors tu appelles ça visibilité, moi je comprends, bien comprendre qu'est-ce qu'on paye, pourquoi, qui est responsable de quoi dans l'équipe et quels sont les projets qui ont quel impact en termes de facturation cloud, ça c'est le sujet. Premier pilier que tu appelles visibilité. Le deuxième, optimisation. Donc, c'est une fois qu'on a bien compris comment on les fait réduire, comment est-ce qu'on les met sous contrôle, comment est-ce qu'on les surveille. Le troisième, c'est comment est-ce qu'on anticipe, donc c'est le forecasting. Ça, c'est un, je trouve, auquel on pense assez bien, notamment quand on prépare sa migration.

8:41 Mais ce que tu indiques, c'est qu'il faut sans arrêt le remettre sur l'ouvrage, regarder vers quoi les choix qu'on est en train de faire. En fait… Ce qu'on s'aperçoit, c'est que le bon fonctionnement de ce pilier-là, il n'est pas tant lié à la méthode de forecast finalement, parce qu'on peut faire des choses extrêmement complexes. Il y a bien sûr une nature variable du cloud par essence, mais même au niveau des projets, au niveau de notre environnement métier, il va évoluer. Donc, il y aura des changements. Le vrai savoir-faire des clients qui se sentent à l'aise, c'est sur la partie remédiation. C'est-à-dire qu'il va y avoir des dérives sur certaines parties du budget, dans un sens ou dans un autre. C'est comment on adresse ces dérives. Donc en amont, qu'est-ce qu'on met en place comme processus, idéalement automatisé. Si ce n'est pas automatisé, comment on va prendre la décision? d'aller dans un sens ou dans un autre, c'est cette partie qui va être assez structurante dans le fait qu'on est toujours pile poil sur les budgets prévus, ou si ce n'est pas le cas, il y a une explication qui est très claire, on s'est mis d'accord à l'avance dans quel cas on allait décider qu'un budget pouvait être dépassé par exemple,

9:45 Ça, c'est vraiment ce qu'on voit de manière consistante. J'imagine que dépasser son budget, si ça correspond à plus d'activités, plus de ventes et plus d'e-commerce par exemple, c'est moins choquant que si ça correspond juste à un changement de version. Changement de façon de faire qui n'est pas corrélat du business. C'est ça. La particularité, c'est que chaque entreprise va avoir un degré d'acceptation de ces changements qu'il faut qu'elle définisse. Certains clients vont dire, écoutez, s'il y a 20% d'utilisateurs en plus sur ma plateforme, je comprends que mon coût varie dans les mêmes proportions. Il y en a d'autres qui vont dire, non, moi, mon seuil, ce n'est pas celui-là. Je veux rester dans le budget, quoi qu'il soit. Après, si mon activité est double, là, OK, je veux… Donc, il y a un côté comprendre, en fait, quelles sont les sensibilités à ces drivers business en interne pour adapter. Et donc, derrière, il y a les façons de gérer ça. Dans quel cas on va bloquer le budget quelque part? Donc il y a des possibilités par exemple de restreindre de nouvelles ressources qui pourraient être lancées.

10:46 Dans quel cas effectivement on considère que ça accompagne le business et c'est normal et là on va le laisser dépasser ce qui était prévu au départ. J'imagine qu'on pourrait même arriver à un stade où on sépare les coûts de cloud et il y en a qui sont des vrais coûts d'infra et il y en a qui sont des coûts de grosse margin ou de run directement lié à l'activité. On pourrait même arriver jusque là. Ça m'amène à un sujet qui est pour moi prépondérant dans ma fonction, c'est la mise en relation entre la dépense sur le cloud et les avantages métiers, la transaction business qui est servie par le cloud. Pourquoi? Parce que si tout se passe, Ça se passe bien et l'intérêt du cloud, donc de la AWS dans mon cas, et du client, ça va être que vos coûts cloud augmentent. Parce que finalement, ça veut dire que vous avez plus de transactions métier. Et moi, mon engagement vis-à-vis de mon client, ce n'est pas tant de lui faire baisser la facture, c'est de lui faire baisser son coût à la transaction individuelle. Si vous avez un assureur qui a un coût à l'UWS par sinistre de temps, mon métier, ça va être de l'aider à faire baisser ce coût de traitement par sinistre au fil de l'eau.

11:58 Après, si ça s'est rempli, ça va naturellement l'inciter à investir peut-être plus sur AWS, peu importe, mais c'est normal finalement que sa facture vienne à croître à partir du moment où il a bien la réduction de cette unité. Donc c'est effectivement, pour répondre à ta question, c'est assez crucial. De distinguer les coûts qui sont finalement des coûts fixes, un peu shared services, mais sans variabilité, et ceux qui sont effectivement directement liés à une fonction business, et dans quel cas c'est bien à partir du moment où on n'est pas sur du linéaire, puisque là ça devient... C'est toujours intéressant, mais c'est évidemment, ils n'avaient pas besoin de moi finalement. Le client, s'il fait deux fois plus d'activités, il paye deux fois plus. Bon, je n'ai pas de grande intervention. Mon métier, c'est bien que le deux fois plus, il coûte moins cher que la première partie. Oui, ok. Et on voit bien que ce dont tu parles là, qui est de traduire en unité d'œuvre, le coût du cloud, ça entraîne

13:00 Une nécessité qui est d'embarquer beaucoup plus de monde que seules les équipes IT autour de cette question, qu'elle soit la question du cloud ou la question du coût du cloud. Est-ce que tu peux nous parler un peu de ça, de la manière dont les clients, les meilleurs clients s'y prennent pour faire ça? Et quel est l'enjeu pour eux réellement? Évidemment, pour nous, il n'y a pas de meilleur client. Après, on essaie de nous identifier dans l'ensemble de ce que l'on voit, les facteurs qui font qu'un client va avoir plus de succès qu'un autre et faire en sorte que ces pratiques se diffusent à tout le monde. Après, il n'y a pas de notion de valeur spécifique là-dedans. En fait, c'est une notion de transformation digitale. C'est un petit peu... Un marronnier quelque part, mais c'est assez important dans le sens où soit on fait de l'externalisation d'IT, donc AWS va être un fournisseur comme un autre, on va mettre de l'IT ailleurs, on fait l'IT exactement de la même façon et effectivement on va pouvoir avoir une économie en TCO.

14:01 Mais si on s'arrête là, finalement, on n'a pas vraiment transformé grand-chose. Et on ne va pas, par rapport à un concurrent, par exemple, dans votre métier, qui va faire la même chose, et qui, lui, va vraiment tirer parti des particularités du cloud, vous allez vous retrouver dépositionné. Et donc, cette conversation en utilisant des métriques qui sont spécifiques au métier, ça permet aussi aux donneurs d'ordre interne qui ne sont pas de l'IT de comprendre ce que vous faites. Si vous allez, reprenons l'idée de l'assureur. Je n'ai rien de particulier avec les assureurs, c'est pour qu'on parle toujours sur le même sujet. C'est le meilleur client en fait, dis-le nous. Je ne peux pas en parler. Je n'ai pas de vertical particulier, c'est assez varié en fait. Et donc voilà, le coût de la transaction au contrat traité, soit vous exprimez, quelqu'un de l'IT peut dire, je ne sais pas, un CFO ou quelqu'un qui est en R&D, voilà, quand on traite un dossier, il me faut 40 calls API, j'ai tant de données stockées, il y a tant de données qui transitent, ça ne va pas lui parler.

15:07 Par contre, si vous lui dites, hier, quand je traitais un sinistre, ça me coûtait 67 centimes de dollars sur AWS, et puis en travaillant, on est arrivé à 52, c'est des notions qui parlent à tout le monde. Donc après, on peut travailler, là on parle de dimension dollar, mais il y a des dimensions, ça peut être des dimensions de célérité, à quelle vitesse on traite un dossier, quel est le taux d'erreur, l'indisponibilité du système, des choses comme ça. Et en fait, ça va permettre, tout le monde va comprendre en quoi l'usage du cloud est transformationnel, en quoi chaque partie du métier, donc quelqu'un qui n'a rien à voir avec l'IT, qui process au niveau opération dans le métier, lui va comprendre en quoi demain il peut traiter 4 fois plus de sinistres par exemple, ou bien quelqu'un qui crée des nouveaux contrats en marketing, au lieu de faire des opérations où il va tester 3-4 nouveaux produits en même temps, il peut en tester 100, peut-être 200, avec à la fois une capacité technique de mesurer les retours de ses produits, et aussi une capacité à éliminer ceux qui ne sont pas

16:08 efficaces très rapidement, donc avec une gestion finalement du coût qui est la même quand il avait juste 2-3 projets, mais il est capable d'identifier beaucoup plus vite. Évidemment, les ressources AWS, vous les utilisez à un moment donné, vous faites vos essais, ça ne fonctionne pas, vous arrêtez les ressources, il n'y a plus de coût. Ce qui est relativement différent quand on est dans un environnement où les assets sont là, il faut les utiliser pour quelque chose. Le parallèle que je me dis, que je fais là comme ça rapidement en t'écoutant, c'est que finalement, avant cette histoire de variabilité des coûts du cloud, la seule conversation d'intéressante technique qu'on pouvait avoir sur des enjeux business, c'était par exemple, moins il y a d'appels API, moins il y a de risques de plantage, moins il y a de temps de délai de réponse ou des choses comme ça, qui étaient finalement difficiles à percevoir parce que le risque de planter ou le risque de complexifier la tâche, Ce n'est pas évident à mesurer. Là, l'avantage, c'est qu'on a des métriques qui sont quand même très objectives, qui sont en euros, en dollars, ce qui permet d'avoir des conversations assez intéressantes finalement sur l'architecture même du service qu'on déploie, avec des gens du métier et des gens de l'IT qui font la traduction.

17:18 Super intéressant. Donc, c'est ça que tu… Finalement, ce que tu nous dis là, c'est l'intérêt majeur de traduire en unité d'œuvre métier le coût du cloud, c'est de permettre une conversation beaucoup plus large que seulement l'équipe IT autour de la question de l'infrastructure, du cloud en particulier, et de… de« unlock», comme diraient les Américains, de« débloquer» de la capacité d'innovation. Et finalement, du coup, et c'est ce que tu disais tout à l'heure, la capacité d'aller prendre des parts de marché ou d'aller gagner en maturité et en innovation par rapport à ses propres concurrents. Ok, super intéressant. Est-ce que, pour conclure cette première partie-là, de l'intervention. Est-ce que je peux te poser juste une question plus de l'ordre de quels sont les conseils que tu donnerais justement à des... Donc là, nos participants aujourd'hui à la masterclass sont plutôt des techs, des tech leaders. Quels conseils tu pourrais donner par rapport à cet enjeu justement d'ouverture interne?

18:24 C'est les clients qui m'ont donné ces conseils. Il y en a un que je ne peux pas citer ici, mais il est assez connu parmi les CTO français, qui disait, avant, je suis CTO, j'ai un gros service informatique, on m'appelait la maison du no. C'est-à-dire qu'on venait me voir avec des projets, moi j'avais une capacité à les déployer qui était liée à mes ressources, je devais en sélectionner et finalement, même si ce n'était pas la façon dont je le faisais, les gens avaient l'impression que mon boulot c'était de trouver une raison de ne pas faire. Maintenant on m'appelle la maison du oui, c'est-à-dire que c'est moi qui vais voir les métiers et je vais leur proposer finalement, j'ai créé une espèce d'infrastructure, ils ne voient plus la partie technique, ils ne voient qu'une espèce d'usine à fabrique de tests sur les métiers par exemple. Et donc c'est un changement de position vis-à-vis de la fonction IT par rapport au reste des métiers. Alors on ne va pas faire le tour de l'histoire de l'IT comme étant un centre de service interne, il s'est passé plein de choses.

19:29 En fait, ça a... rapproche l'IT des métiers. Il y a une notion de création de valeur commune finalement, alors que c'est pas tout noir, je grossirais pour le message, mais ça permet vraiment de positionner l'IT comme un créateur de valeur au centre de l'entreprise, et donc qui va se rapprocher des autres fonctions, développer des choses ensemble, et ça pour moi c'est fondamental, et c'est pour le CTO une opportunité. aussi de peser assez différemment dans les discussions, dans un board, des choses comme ça par exemple. Ok, merci beaucoup Cyril. Il y a des questions qui sont déjà arrivées, mais je propose qu'on les garde pour juste après. Du coup, tu reviendras pour qu'on puisse te poser les questions. Bienvenue Emmanuel. Je vous présente Emmanuel Cordente qui travaille chez Oui SNCF et qui va peut-être nous proposer un point de vue encore plus concret. Emmanuel, je te laisse te présenter pour commencer.

20:33 Bonjour, je suis Emmanuel Cordente, je travaille chez OuiSNCF. J'ai été longtemps dans la cyber chez Oui, j'ai fait ça pendant une dizaine d'années. Et puis depuis deux ans, je pilote un gros programme de migration dans le cloud. Qui est en train d'arriver sur la fin. Donc, je peux commencer à vous en parler. Super. Voilà. Alors peut-être pour commencer, la première question que je voulais te poser, puisqu'aujourd'hui on parle de la relation finalement entre l'équipe IT, la direction générale, les équipes métiers, peux-tu déjà nous raconter comment vous avez pris la décision de migrer dans le cloud? Oui, alors du coup, la décision de migrer, elle est arrivée. Elle a mûri petit à petit quand même, parce que ça faisait quelques années qu'on... qu'on faisait des projets dans le cloud, donc on avait commencé à faire des pilotes et à avoir du coup un avis sur la question.

21:38 Et effectivement, petit à petit, on a commencé à se dire, peut-être que ça vaudrait le coup de faire une grosse migration dans le cloud, sachant qu'aujourd'hui, on a deux data centers en propre qui nous servent d'hébergement pour l'ensemble de notre SI. Et en fait, on a eu un fait externe, c'est-à-dire qu'on doit rendre un de nos data centers, on doit le rendre au propriétaire du bâtiment. Et donc, on avait un projet de migration de data center qui était dans les tuyaux. Donc, c'est des projets, je ne sais pas si vous en avez déjà fait, mais c'est des projets qui sont souvent compliqués, assez lourds. Nous, on en avait déjà fait quelques années auparavant. Donc, on en gardait quand même un souvenir un peu douloureux. Et on savait que ça allait nous prendre beaucoup de temps, beaucoup d'énergie pour finalement... Pas grand chose en fait, c'est à dire qu'on ne fait que déplacer quelque chose, donc on ne le transforme pas pendant qu'on fait ça. Et donc on a eu ce sujet là qui est arrivé un petit peu en parallèle de cette réflexion cloud, et à un moment donné on s'est dit, est-ce que

22:45 dans le délai que l'on a, c'est à dire entre le moment où on était et le moment où on devait rendre le data center, est-ce qu'on est capable de glisser à l'intérieur une migration complète dans le cloud? Ce qui nous laissait à peu près 18 mois. Donc ça a été ça un peu le driver. Donc une fois qu'on s'est dit, techniquement, on pense que c'est jouable, effectivement, il a fallu provoquer la décision. Et là, c'est une autre paire de manches, en fait, parce que là, on rentre effectivement, notamment sur ces sujets économiques, qui sont quand même le cœur du sujet pour prendre ce type de décision. Et donc là, effectivement, il faut arriver à simuler, à projeter un petit peu les coûts, combien est-ce que ça va coûter une fois qu'on aura migré, combien ça va coûter l'opération de migration, parce que du coup, pendant toute cette phase de migration, c'est finalement un investissement qu'il faut faire, pendant toute cette durée de migration, on appelle ça la double bubble, donc on a des coûts qui vont venir se rajouter à nos coûts existants, c'est-à-dire que nos data centers, on continue de les payer, on continue de maintenir

23:52 ces environnements-là. Et en parallèle, on va aller investir du jour homme, mais aussi de l'infrastructure chez le cloud, petit à petit, qui va aller crescendo. Et donc, cette bulle-là, il faut arriver à la modéliser. Et ça, clairement, ce n'est vraiment pas évident pour le coup. Et puis, il faut arriver aussi à se projeter, une fois que j'aurai terminé ma migration, combien me coûte mon SI pour le projeter sur les années suivantes, parce que finalement, ce sont des plans qui vont, comme je vous le disais, il y a une partie d'investissement et puis il y a une partie de rentabilisation de ces investissements. Donc, c'est des plans qu'on va monter sur plusieurs années pour essayer de trouver un équilibre. économique. Même si, comme on l'a dit tout à l'heure, effectivement, le driver économique n'est pas le seul, mais pour prendre la décision, il faut quand même rester très lucide, ça reste un des drivers hyper importants. On reviendra sur la question du ROI un peu après. Peut-être déjà commencer par creuser la question de, justement, la transformation des autres drivers que tu évoques là.

24:55 Comment, on a abordé le sujet avec Cyril tout à l'heure, c'est une transformation. qui est un peu plus large qu'une seule transformation technique, c'est une transformation qui est un peu plus motivée qu'un seul gain de ROI. Est-ce que tu peux nous décrire justement toute la partie immergée de l'iceberg en matière de transformation? Alors effectivement, la transformation, la manière dont on la présente, Moi, j'ai tendance à penser que dans un premier temps, ça reste quand même du marketing, c'est-à-dire qu'on vend quand même quelque chose et en face de nous, les gens attendent de voir quand même. Donc, on va vendre de plus d'innovation, donc des accès à des services un peu plus innovants. L'exemple que j'utilise souvent, c'est l'intelligence artificielle, par exemple, qu'on a pu mettre en place, expérimenter sur le cloud, alors qu'on n'était pas capable de faire ça sur nos data centers. Ça va être d'avoir un meilleur TTM, donc une accélération un petit peu de notre capacité à produire des fonctionnalités pour nos clients.

26:02 Ça va être bien entendu une partie économique, donc ça on va en parler, mais ça peut être aussi des sujets autour de la résilience ou des sujets autour du focus des équipes sur la valeur client justement, etc. Donc on a tout un écosystème d'arguments qui viennent un peu appuyer cette transition vers le cloud, mais qui sont dans un premier temps, qui sont beaucoup de promesses en fait. Et en plus, la migration en tant que telle ne permet pas d'atteindre toutes ces promesses. C'est-à-dire que c'est bien une démarche entière. Donc, la migration est une étape, en fait, dans cette transformation. Et donc, ça ne s'arrête pas là. Après, il faut effectivement continuer pour aller chercher ses avantages. Oui, dans le jargon, le lift and shift ne suffit pas pour rendre ses promesses. Exactement. Et j'en profite pour glisser une petite question, puisque tu as dit que tu faisais de la cybersécurité avant. Est-ce que, justement, en matière de résilience et de cybersécurité en particulier, il y a des promesses particulières qui sont faites?

27:07 Alors effectivement, moi c'est vraiment comme ça que je suis rentré sur le sujet, c'est avec la casquette sécurité. Et l'intérêt qu'on y voit, alors il y a forcément des risques supplémentaires, parce qu'on est sur des environnements qui sont naturellement ouverts, mais on a en contrepartie des environnements qui sont fortement industrialisés, et ça d'un point de vue sécurité, on aime beaucoup, on va aimer d'avoir des choses qui sont fortement normées, fortement auditable, répétable, etc. Et donc, c'est sur ces aspects-là, en fait, où finalement la transition cloud a porté aussi effectivement des choses sur la partie sécurité et aussi sur la partie résilience. En gros, si je résume ce que j'ai compris, c'est le fait que l'atterrissage que l'on vise quand on passe dans le cloud, soit dans un environnement plus industriel, plus normé, qui soit facilement auditable parce qu'il ressemble à plein d'autres environnements par ailleurs.

28:11 C'est ça qui rassure d'un point de vue normes de sécurité. Oui, effectivement, ça nous rassure. Ça ne suffit pas, mais ça nous rassure. Ça nous permet d'avoir quand même des SI qui sont mieux maîtrisés, même s'ils sont plus exposés. Oui, parce que moi, c'est souvent ce qu'on m'oppose. Intuitivement, on se dit qu'on est plus exposé dans le cloud. D'ailleurs, je disais, les recommandations de l'ANSI sont assez sévères sur cette partie-là. On est plus exposé, mais on compense par le fait qu'on est dans un environnement plus industriel. Donc, en fait, on se protège de soi-même, quelque part. C'est ça. Et donc, on profite nous aussi, sur les aspects sécurité, on va profiter des avantages du cloud. Donc, ces services qui nous servent à produire de la valeur client, on s'en sert aussi pour mettre en place des services de sécurité pour protéger ces infrastructures. Donc, du coup, sur cet aspect-là, ça reste quelque chose qui est, de mon point de vue, assez positif. Alors, si on revient justement un peu plus sur les questions de ROI, la question là, ce n'est pas tellement de te demander quel est ton héroïsme, etc.

29:15 Parce que je pense que ça n'est pas trop compliqué et en même temps trop casse-gueule de te poser cette question-là. Mais moi, j'ai plutôt envie de te poser la question de comment est-ce que tu... Travaille pour faire en sorte que la promesse que tu as faite, justement, dont tu viens de parler, advienne. Et le plus de chances possibles de se réaliser. Comment est-ce que tu mets ça sous contrôle? Oui, alors ça c'est vrai que c'est vraiment la partie compliquée. C'est pour ça que je trouvais que c'est intéressant le point de ce soir. Donc il y a déjà arrivé à projeter un petit peu, à faire la première projection. Donc là, en tout cas en ce qui me concerne, il faut que je remonte un peu dans le temps. Et au moment où on décide de faire cette migration, là c'est quand même... Compliqué et le plus de chances possibles de se réaliser. Dans le sens où on a, dans mon cas, on est à peu près sur 350 applications, 7000 serveurs, on est sur des SI qui ne sont pas... Pas analysable à l'échelle humaine, c'est-à-dire que personne dans l'entreprise ne connaît l'intégralité du SI, on a vraiment une multitude d'équipes qui travaillent là-dessus.

30:18 Et donc du coup, arriver à se dire à un moment donné, on va se projeter dans le cloud, sachant que les équipes qui maîtrisent le SI ne connaissent pas le cloud, c'est toute la difficulté. C'est que tu fais une migration et que des gens qui n'y connaissent a priori rien, puisqu'ils sont en charge de ce qui n'est pas dans le cloud. Exactement, donc on les embarque dedans, mais ceci étant, dès le début, il faut qu'on arrive à se projeter. Donc c'est là où effectivement le clouder joue un rôle important, c'est-à-dire qu'il arrive lui avec une expérience, il arrive, comme l'expliquait Cyril, avec des frameworks, avec des outils qui nous permettent d'essayer de simuler un petit peu les choses. Ça reste de la simulation. On voit bien, quand je l'explique en interne, on essaie de faire la météo à six mois, un an. C'est ça qu'on essaie de faire. On voit bien qu'à la fin, le prix ou le coût final du projet dépend de tellement de petites choses. C'est un peu les effets papillons qui sont à droite, à gauche. Tout influence un petit peu. C'est la somme de toutes ces influences qui fait qu'on va tenir ou pas le projet.

31:21 Donc du coup, ces outils-là sont importants parce que sans ça, on ne saurait pas se projeter. Nous, on n'y serait pas arrivé. Donc on s'est appuyé sur le... expertise. Après, il y a un peu de feeling qui vient aussi par-dessus des équipes qui regardent un peu les chiffres qui sortent et se disent, ça peut le faire là, ça me paraît bizarre et tout ça. Donc, on a itéré, mais finalement, dans notre cas, on a fait ça relativement rapidement. Ça a pris moins de deux mois, en fait. Donc, ça a été très rapide, finalement. Mais je vous expliquais le contexte, c'est que tout le temps qu'on passait à étudier, c'était du temps en moins qu'on avait à migrer. Donc, on s'était dit, si c'est jouable, il faut qu'on le fasse très, très vite. Donc, c'est pour ça qu'on est allé assez vite. Si je comprends bien ces outils-là, c'est à la fois de la méthode, c'est ce que tu appelles les frameworks, mais aussi l'outillage au sens mapping. Il me semble, en tout cas, ça, c'est de mon expérience que je parle, on installe des outils qui vont aller scanner toutes les machines que tu utilises et qui les dimensionnent sur un certain nombre d'indicateurs pertinents. Tu laisses tourner ça un certain temps.

32:21 Effectivement, il y a l'inventaire, c'est ce dont tu es en train de parler, avec des outils qui vont nous aider à compléter les inventaires qu'on peut déjà avoir en interne. Donc, ça nous permet de bien collecter l'ensemble des métriques qui nous intéressent. Donc, ça va être sur des serveurs, ça va être la mémoire, la CPU, le disque dur, etc. Donc, tous ces éléments-là sont bien entendu primordiaux. Et après, ce qui est important aussi, derrière, c'est la méthode de migration. Parce qu'au-delà d'infrastructures dont on est en train de parler là, il y a aussi l'effort de migration, puisque c'est finalement la plus grosse partie dans la phase de migration. la plus grosse partie des coûts, c'est l'effort humain que l'on va faire, que l'on va déployer finalement pour reconstruire nos infrastructures dans le cloud. Et cette partie-là, du coup, elle est très influencée par la méthode de migration. Et donc ça, c'est quelque chose, pareil, qu'on construit avec le cloudeur. Et à un moment donné, il faut rééchanger avec les équipes pour qu'elles-mêmes puissent commencer à donner un premier feeling sur des estimations qu'on est en train de poser sur leur travail à eux.

33:28 Donc, c'est vraiment une phase qui est un peu délicate. J'ai vu que c'était une des questions qui était déjà posée, du coup j'en profite, je te la pose maintenant. Dans les méthodes de migration, ce que j'en connais, mais tu vas compléter parce que tu es plus pointu, tu as migré tel quel, donc le lift and shift, puis après tu as de la transfo, tu as peut-être aussi d'ailleurs des machines que tu décides d'abandonner, d'éteindre, d'arrêter, de ne même pas migrer. Comment est-ce que vous vous arbitrez entre ces différents choix et à quoi ça ressemblait votre matrice de choix à la fin? Oui. Alors, déjà, je vais commencer par le dernier point parce qu'il est vraiment important et c'est vraiment quelque chose qu'on avait intégré dans le modèle. Et pareil, basé sur l'expérience d'AWS sur le coup. Il nous avait dit, vous allez voir, quand vous allez migrer, il y a toute une partie de votre récit qui va partir à la poubelle. Nous, les équipes chez nous, ça leur paraissait curieux parce qu'on venait justement de faire des déménagements. Donc, normalement, on avait déjà quand même pas mal nettoyé notre quinquennat.

34:31 Et donc, du coup, on a quand même positionné dans le modèle le fait qu'on supprimait, je ne sais plus si c'était 20 ou 25% de notre SIS, ce qui est quand même, en termes de milliers de serveurs, c'est quand même énorme. Vous avez combien de machines? On avait entre 7 et 8 000, ça dépend comment on compte. Donc du coup, c'est quand même des gros volumes. Et en fait, dans la réalité, c'est réellement ce qui se passe. C'est qu'on voit, je vous ai parlé au début de 350 applications, au final, on en migre 250. Donc, il y en a quand même une centaine qui ont disparu pendant le processus de migration. C'est là ton ROI. Alors en fait, ça y participe clairement, parce que c'est quand même une des parties qui est intégrée dans le modèle, donc ça joue pour une part. Donc ça, c'était la troisième. Pour la dernière catégorie, la plus facile, celle que vous n'avez pas. Et les autres, c'est est-ce que tu migres à l'identique ou est-ce que tu transformes? Alors oui, là-dessus, AWS a été très dur avec nous.

35:32 Ils nous ont dit, les gars, c'est super ce que vous voulez faire. Par contre, 18 mois, c'est quand même tendu, votre affaire. Et si vous transformez, vous n'y arriverez jamais. Donc ça, ils ont été très, très clairs. On a bien compris le message. Donc en fait, on s'est autorisé à faire un tout petit peu de refactoring sur certaines applications qui avaient déjà commencé à se transformer, notamment sur de la containerisation, des choses comme ça. Chez nous, en tout cas, c'était ces équipes-là. Qu'on a pu basculer sur des services managés type EKS, ce genre de choses. Mais ça reste un petit pourcentage. Et sur le reste, on essaye de faire ce que nous, on appelle du re-build. Donc, on reconstruit à l'identique nos infrastructures. Mais même en faisant ça, on injecte forcément du changement. Et on voit que, et là, on le voit vraiment dans toutes les actions de migration, parce qu'on migre énormément d'applications toutes les semaines en ce moment. On voit partout où on a fait un petit peu trop de changements. Du coup c'est plein de problèmes complémentaires qui arrivent lors des... lors des bascules, etc. Donc aujourd'hui, on va y arriver en fait.

36:34 Le projet, on est en train d'arriver au bout et on va arriver à le faire en 14 mois, ce qui est très bien. Nous, on est très contents. Mais il faut effectivement tout le temps beaucoup de rigueur pour se freiner là-dessus. Donc c'est vrai que des fois, on a envie de faire mieux, de simplifier tout ça. Et on se dit, on va le faire, mais juste après en fait. Donc là, on migre en l'état. Après, tu appelles Cyril et tu travailles après. Donc, si je résume ce que je comprends, en termes de surprise par rapport à ce à quoi tu t'attendais, mais si c'est assez… subjectif, c'est beaucoup plus d'abandon finalement ou d'arrêt, de décommissionnement comme on dit dans le jargon que prévu, qu'imaginé et à l'opposé moins de refactoring que souhaité pour des questions de time to market. De délai. De délai. Et pour le coup, le délai me semble hyper important, parce que ça a un lien avec les finances.

37:41 Au début, dans nos premiers plans, on partait sur une migration sur 4 ans. C'était ça notre plan. Comme je vous l'avais dit, on n'avait pas cette histoire de déménagement. Donc, on se disait, on va migrer en 4 ans, tranquillou. On refactorise un peu. Et puis, en fait, on a écouté pas mal d'entreprises. On est allé voir des gens qui avaient fait ces migrations. Et c'est vrai qu'on... On s'est rendu compte que personne ne faisait ça. Tout le monde allait beaucoup plus vite, faisait ça un an, un an et demi. Du coup, on a creusé un peu le sujet. Effectivement, on nous a dit qu'il faut faire gaffe si vous faites des migrations longues. Il y a quand même un risque important que vous restiez coincé au milieu. C'est-à-dire qu'au bout de deux ans d'effort, parce que c'est quand même... Les migrations, c'est quand même dur, c'est quand même lourd. Là, on en a marre, vraiment, on est content d'arriver au bout. Si on en avait encore pour deux ans, objectivement, surtout que dans les entreprises, on sait qu'il peut y avoir des changements de management, des changements d'équipe, etc. Et on peut facilement se retrouver dans une configuration où on est coincé au milieu. On ne sait plus trop pourquoi on le fait, on n'a plus trop envie d'y aller, etc. Et puis, en fait, on reste un peu à cheval. Et donc, là où je voulais en venir, par rapport au sujet du budget et de la partie FinOps, ce qu'il faut aussi comprendre, c'est que pendant cette phase de migration, le pilotage budgétaire, il est un peu particulier.

38:55 C'est-à-dire que dans le programme de migration, tout le budget d'infrastructure pendant la migration, il est porté par le programme de migration. Donc ce que je vous expliquais, la bulle, la bubble bubble. Donc sur la partie infrastructure, sur l'année 2021, les projets, on ne leur a pas demandé un budget supplémentaire d'infrastructure. Donc ils ont le leur qui paye normalement la partie qui est un premise. Et nous, en fait, par de l'investissement, on vient payer tout ce qu'ils sont en train de construire sur Amazon dans l'année, en fonction de, et ça coûte plus ou moins cher, en fonction de s'ils ont mis... migrer en janvier ou s'il migre en décembre, ce n'est pas pareil. Donc, il y a toute cette trajectoire qu'il y a à construire. Mais du coup, ce pilotage économique de l'infrastructure, il est… Il n'est pas partagé encore. Oui, et surtout, il ne faut pas qu'il dure longtemps, parce qu'en fait, à partir du moment où je me retrouve dans la situation où j'ai des applications qui ont migré en février, en mars, donc elles, c'est bon, elles ont migré, mais du coup, elles consomment maintenant de l'infrastructure sur AWS, mais c'est moi qui la finance.

39:57 Et donc, du coup, on sent que la structure de pilotage, de ce truc-là, ça ne marche pas. Elle n'est pas vertueuse. Oui, mais non, du coup, il faut rapidement qu'on arrive à la fin du projet, donc là, c'est ce qu'on est en train de faire, pour sortir de ce projet-là et basculer dans un nouveau mode où là, effectivement, on va être sur le... On coupe le unprimed et on est pur... On va sur le pilotage FinOps avec des fonctions FinOps qui vont être reventilées jusque dans les projets, en fait, pour qu'on ait un vrai pilotage de l'infrastructure AWS et de ses coûts. Donc, les projets longs, il faut faire attention parce que ce pilotage économique, il devient très compliqué, en fait. Donc ça, ce serait ton conseil en termes de recommandations, c'est plutôt de venir sur un projet resserré, quitte à ne pas faire tout ce qu'on veut faire en termes de refactoring, pour rapidement se débarrasser du on-premise, être pur coût variable au cloud, Je résume comme ça. Et ensuite, pouvoir s'attaquer, cette fois-ci, aux transformations qui vont tirer parti pleinement de la puissance en modèle économique et en capacité d'innovation du cloud. Et le retour d'expérience, c'est qu'on voit que les projets, je vous ai dit qu'il y a une partie des projets qu'on a mis en refactoring, ce que nous on appelle le refactoring, et d'autres qu'on a mis en rebuild et qui derrière ont fait le refactoring, et on voit qu'à l'arrivée,

41:11 ceux qui sont partis en refactoring n'arrivent pas avant les autres. Donc en fait, ça leur a pris plus de temps parce qu'il y a plus de transformations, alors que ceux qui ont migré, qui étaient sur quelque chose de très maîtrisé, ils ont migré très très vite, et finalement maintenant ils se transforment. Donc je ne suis pas sûr qu'on y gagne. Tu as une question de disponibilité, tu as aussi une question de focus des équipes, c'est-à-dire que quand elle est... L'équipe, elle est focus sur le projet de migration. Elle est peut-être moins pertinente et elle va faire plus d'erreurs sur des questions de transfo. Et surtout, ce n'est pas les mêmes personnes. C'est ça. Alors qu'une fois qu'ils y sont, on revient sur la vie normale d'une application qui se modifie pour performer mieux. OK. C'est ça. OK. Ce n'était pas intuitif, cette partie-là, pour moi. Oui. Et du coup, le corollaire de ça, c'est que… En TIPS aussi, c'est tout ce pilotage pendant la phase de migration, tout le pilotage économique de l'infrastructure, donc la projection des coûts mois par mois en fonction de qui migre, qui ne migre pas, etc. C'est quelque chose qui prend beaucoup de temps. Et nous, c'est clairement quelque chose qu'on a sous-estimé au début.

42:12 Et donc, ça veut dire qu'il faut qu'on ait dans les équipes de pilotage de la migration, il faut avoir pas mal de ressources type PMO, des gens qui sont capables de construire des dashboards, de travailler sur des référentiels, etc. Au début, on n'était pas assez. Et clairement, on a été un peu dans le brouillard à une période du projet. C'est-à-dire qu'on n'était plus en pilotage. Et donc, c'est quelque chose sur lequel on a remis l'accent. Et là, on a vraiment vu la différence. Là, on est vraiment en maîtrise. Alors, peut-être pour conclure ta partie, est-ce que tu peux nous dire quelles sont les étapes devant toi, les choses auxquelles vous vous attelez? Tu viens de parler de cette partie. Remise sur contrôle des coûts et re-responsabilisation des... équipe projet, est-ce qu'il y a d'autres choses que tu veux mentionner sur ce qui reste devant vous ? Nous, comme je le disais, la migration, c'est une étape dans le processus. Donc effectivement, il y a une étape à très court terme, on est en train de travailler dessus, sur le passé d'un FinOps un peu central, qui était

43:20 le garant des coûts, qui surveillait, qui ventilait, tout ça, mais qui était très central, passer à une organisation beaucoup plus décentralisée, où on va déléguer beaucoup plus, éclater plutôt le contrôle et la gestion des budgets d'infrastructure de chaque projet ou de chaque factory chez nous. On va l'éclater dans toute l'entreprise. Donc là, on est en train de travailler là-dessus. Et puis, on est en train aussi de travailler sur le refactoring. Donc, le refactoring à l'échelle chez nous, étant donné qu'on a beaucoup d'applications qui ont des patterns similaires, on veut du coup essayer de dégrossir, de préparer ces refactoring pour que les équipes ne réinventent pas la roue à chaque fois. Donc, de mutualiser entre les équipes la meilleure adhérence au cloud. La meilleure manière de se transformer. L'utilisation du cloud. Et puis, faire en sorte que les transformations, ils ne soient pas tous en train de les découvrir. qu'on puisse réutiliser finalement au moins les leçons apprises d'un projet sur l'autre.

44:26 Merci beaucoup Emmanuel pour ce témoignage. Il y a des questions? Et notamment une première question que je vais laisser le soin à Dimitri de poser. Mais avant ça, je voudrais faire venir Cyril. Reviens avec nous, Cyril. Et puis du coup, Dimitri, profites-en pour revenir aussi et venir poser ta question. Bonjour. On l'entend, mais on ne le voit pas. C'est bon. Voilà, c'est pour inciter les autres aussi à poser des questions et à venir. Oui, une des questions derrière, c'est est-ce qu'il y a des... Surprise, là, un peu dans les freins chez les clients hors tech, hors migration. Est-ce qu'il y a des surprises qui peuvent venir de la finance ou d'autres qui sont des freins pour la migration cloud? Moi, ça me surprend toujours, mais finalement, quand on y pense, ça fait un certain sens. Le cas le plus classique, c'est les gens qui ont une opinion très forte et qui, voilà, ils sont soit... En France, à fond. Ah oui, oui.

45:28 Ils sont soit à fond pour le cloud, soit, ah non, mais le cloud, on m'a dit que c'était nul. Et en fait, finalement, nos fonctions, elles sont vraiment là. C'est-à-dire qu'on fournit de quoi objectiver tout ça. Qui est une opinion, c'est important, il faut des opinions, sinon on est des machines. Après, c'est bien si on peut s'appuyer sur des éléments tangibles. Et aussi, Emmanuel l'expliquait un petit peu, c'est-à-dire que, Que les hypothèses de départ ne soient pas à 100% fiables, parce qu'il y a des choses qu'on ne peut pas s'imaginer, ce n'est pas très grave, mais on se met d'accord sur ce qui fait qu'on a pris cette décision. Quels sont les éléments tangibles que l'on a construits, avec les marges d'erreur dont on a parlé, mais qui font que demain, quand on va se retourner et se dire est-ce qu'on a bien fait de faire ça, on pourra répondre à cette question. Alors que dans l'autre cas, des fois j'ai des clients qui m'appellent, je suis étonné, le cloud c'est cher ou c'est pas cher, peu importe la position, mais je leur dis bon d'accord, et quand vous avez décidé de migrer, vous l'avez fait sur quelle base?

46:29 Ah ben non, non, on a... On n'a pas fait ce travail, on s'est dit qu'il fallait y aller, on y est allé. Bon, ok, on va le faire, mais c'est plus efficace de le faire. Ça, c'est mon premier... Surprise récurrente, le côté, voilà, c'est des opinions. C'est bien ou c'est pas bien, mais on ne sait pas comprendre pourquoi. Pas trop. L'autre, elle est plus naturelle et c'est bien normal. C'est des gens qui ont peur de perdre une partie du contrôle sur leur infrastructure. On va dire CTO pour simplifier la conversation, mais ce n'est pas que ça. Alors qu'en fait, ils peuvent voir AWS ou un clouder comme potentiellement une fuite pour eux du domaine qu'ils maîtrisent, alors qu'en fait, c'est une autre façon de travailler, au sens où la plupart de leur activité va rester identique, leur fonction dans l'entreprise ne va pas évoluer, après ils vont s'appuyer sur des outils, des leviers qui sont légèrement différents. C'est une peur quelque part un peu humaine pour lequel je dis AWS, mais n'importe quel acteur, et même on a des partenaires qui sont là pour accompagner aussi.

47:35 Nous, on s'est aperçu aussi historiquement que les transformations réussies, elles sont souvent basées sur l'existant des gens dans l'entreprise. C'est rare qu'une transformation se passe bien si on n'amène que des forces vives, entre guillemets, de l'extérieur, des spécialistes, et hop, ils vont tout nous faire ça, ça ne marche pas. L'entreprise a son histoire, le SI, c'est une... Un empilement d'historique, ça dépend des tailles d'entreprise et de l'histoire, mais ce côté-là, cette connaissance fine, elle est prépondérante. On ne peut pas coller une couche de cloud et se dire, ça y est, tout va aller mieux. C'est un mélange des deux. Emmanuel l'a aussi expliqué, finalement, il a accompagné les gens qui opéraient les infrastructures on-premise. Vers la version dans le cloud. Ce n'est pas deux mondes qui s'opposent, c'est un monde qui évolue avec... On essaie de tirer parti des bénéfices du cloud. Il y a certains éléments, et Emmanuel les a évoqués, sur lesquels il faut être vigilant.

48:40 Et notre boulot, c'est de faire en sorte que c'est comme ça que ça se passe. Emmanuel, il y a des freins que tu veux? Des freins surprenants, non? J'en ai pas beaucoup. L'adjectif est peut-être un peu gênant. Oui, c'est nécessaire. La plupart sont, moi, me semblent légitimes, en fait, et normaux. Mais oui, il y en a plein en fait. Sur la maîtrise des données par exemple? Oui, par exemple. Donc après, nous c'est des choses qu'on a eu beaucoup tout au début. Et comme le disait Cyril, après il faut objectiver un petit peu les choses. Et puis en expliquant, et surtout dès que les gens commencent à... Les équipes sont quand même très tech, donc dès que les gens commencent à... à toucher un peu, à comprendre un peu comment tout ça, ça marche. Rapidement, tout ça se dissipe et aujourd'hui, on n'a plus aucun frein. Et du point de vue de la direction générale, parce que là, tu parles du coup de freins, du point de vue de la direction générale, il y en a d'autres?

49:49 Ce qu'a expliqué Cyril, il y a les ultra convaincus, il y a ceux qui sont ultra sceptiques au début. Effectivement, tout le monde a un avis très éclairé sur la question, sans vraiment savoir ce qu'est le cloud à la base. On part souvent d'assez loin. Mais voilà, en éclairant un petit peu les choses, pareil, ça prend un peu de temps. En tout cas, il n'y a rien qui me paraît anormal. Je trouve que c'est plutôt sain de se poser ces questions-là. Et effectivement, si on avait tous été hyper convaincus au début, ça aurait été plutôt inquiétant. Donc moi, ça m'a plutôt rassuré d'avoir des gens qui avaient besoin d'être convaincus et de voir que finalement, les arguments arrivaient à les convaincre. Ok. Dimitri, tu veux compléter ta question? Il y avait une petite orientation là, si on est sur la partie finance, parce que là l'interlocuteur reste le CTO, c'est des discussions auxquelles on s'attend et qui sont un peu là effectivement. Mais la surprise, moi c'était un peu les surprises plus côté finance ou…

50:50 ou d'autres qu'on ne peut pas voir venir, qui est un peu l'idée de la masterclass. Là, c'est des choses qu'on ne sait pas et qu'on ne peut pas découvrir. Déjà fait le sujet. Moi, je fais partie de ceux qui, pour l'instant, disent que si je n'ai pas besoin d'une grosse scalabilité chez moi, le cloud, je sais que ça va coûter plus cher. Ça ne veut pas dire qu'il ne faut pas le faire, mais je fais partie de sa vie là. Mais est-ce qu'il y a des côtés finances ou autres, des blocages surprenants qui arrivent? On va dire qu'il y a un côté perception du risque, pas tant financier, plutôt… risque pour l'entreprise en général, prise de risque opérationnelle, parce que on peut se dire que la migration peut mal se passer, on parlait tout à l'heure avec Emmanuel de se retrouver au milieu du guet, au bout de deux ans d'efforts, effectivement personne n'a envie de se retrouver dans cette situation-là. En fait, ce qui se passe, c'est que quand on explique à un CFO que finalement, sa notion du risque, elle va évoluer sensiblement entre des investissements dans deux tranches, dans des data centers, je ne sais pas, on va simplifier, trimestriels à quelques millions pour un gros client,

52:06 avec une instruction lourde de ses projets parce que c'est un investissement significatif, des projections à un usage 3 à 5 ans qui sont aléatoires parce que l'usage évolue et on va se projeter tant qu'on veut. Finalement le cloud c'est un peu l'inverse c'est à dire qu'il y a des risques d'investissement beaucoup plus fréquents, pourquoi? Parce qu'un développeur qui lance une machine dans son coin potentiellement il peut aller impacter le bilan financier de l'entreprise on va dire au sens large mais c'est un risque individuel très faible et donc il y a une réversibilité c'est surtout ce point là qui est important, c'est à dire que si vous faites des choix techniques qui s'avèrent non fonctionnels au niveau applicatif le lendemain vous arrêtez les machines et donc le risque financier il est vraiment appréhendé différemment et du coup la problématique pour un un acteur financier, ça va être plus la notion de visibilité dans le temps, puisqu'ils sont habitués à... un cycle d'investissement, d'amortissement sur l'IT dans un data center, c'est facile, c'est normé. Donc, ils savent, les projections d'amortissement par rapport aux tranches d'investissement, elles sont claires.

53:12 Le cloud, par nature, il peut être plus variable et il va être plus variable. Donc, c'est plus ça qui peut les effrayer. Et donc, il y a tout un ensemble de bonnes pratiques. Il faut que les fonctions de finance se rapprochent, entre guillemets, des fonctions techniques. Pourquoi? Parce que ce côté... Ce côté prise de décision de l'investissement, il va être beaucoup plus fréquent, mais pour un montant individuel beaucoup plus faible. C'est ce qui va évoluer dans la relation. Et le CapEx, OpEx, là, vous n'avez pas trop… C'était un autre axe pour moi où le data center était CapEx et AWS passe en OpEx. Et pour certaines startups et tout ça, ça peut être un énorme changement financier. potentiellement, non? C'est un sujet. Après, déjà, par essence, nous ne fournissons pas de conseils fiscaux. Ce qu'on va se dire là, ça reste une discussion entre adultes. Oui, oui, oui. Ce qui se passe, c'est que la notion de CAPEX, elle est un peu...

54:13 Si on ne regarde que par cet angle, oui, c'est un changement important. Dans la réalité, il n'existe pas de système de SI qui ne sont que CAPEX. Les modèles Gartner, Forrester, ils tendent vers du 30% en tant que CAPEX et le reste, c'est de l'OPEX. Les gens, ils sont... Ils vont toujours être là. D'autres parties du SI vont toujours être là. Et en fait, on considère qu'en moyenne, la réduction du TCO, quand on bascule dans le quart, est de l'ordre de 30%. Donc en fait, vous allez transformer 100... Constitué de 70 d'OPEX, 30 d'OPEX, vers 70, qui va effectivement que l'OPEX, il n'y a pas l'impact que l'on s'imagine. Pour moi, c'est un débat, c'est un prisme particulier. Oui, mais c'est pour quelques startups qui fonctionnent à l'EBITDA, dans lequel le CAPEX n'est pas compté, et tout est gratuit, et là, l'impact, il est colossal. Mais si c'est vraiment important pour toi, tu as d'autres manières de rebasculer d'autres parties en CAPEX?

55:16 Le développement, oui, c'est vraiment le coût de l'infra, c'est surtout ça. Il y a aussi beaucoup de... Si ce sujet est si important pour la startup, tout ce que tu achètes aujourd'hui en IT qui s'optexise, de toute façon, le changement est beaucoup plus large que seule l'infrastructure. Seul l'infrat tech. Je ne dis pas que ce n'est pas un sujet, bien sûr, mais ce n'est pas aussi impactant qu'on se l'imagine. Après, on peut kidnapper pour d'autres questions. Pardon, pardon, vas-y. Je voulais rebondir sur ce que tu disais. Il y a un autre sujet qui peut hériter un petit peu les départements financiers. c'est qu'avant, quand on est dans un monde de primaires, on est dans un monde financièrement qui est très contrôlé, très validé. C'est-à-dire que pour acheter une machine, il y a des arbitrages, on fait un bon de commande, c'est validé par Pierre-Paul ou Jacques, et après on passe la commande, on reçoit une facture. À partir du moment où on est dans le cloud, la DAF se rend compte que ça ne marche plus comme ça, c'est-à-dire qu'on ne fait plus vraiment de bande-commande.

56:22 C'est-à-dire que l'acte de commande devient un micro-acte de commande d'ailleurs. C'est-à-dire que beaucoup de gens font des micro-commandes toute la journée. Et tout ça se transforme en une facture qui arrive à la fin de l'année, à la fin du mois, et qui n'est pas de la même nature que quand on achète un serveur sous forme de CAPEX. Comme on le disait juste avant. Donc ça, ça peut faire peur aussi au début de se dire, mince, mais est-ce que je ne suis pas en train de perdre la maîtrise? Et la DAF a un peu l'impression au début de subir les factures, c'est-à-dire qu'elle voit les factures tomber en fait, mais finalement, elle ne les a pas vraiment anticipées. Un hold-up de process. Oui, au début, ça fait un peu peur. Et donc voilà, après, c'est tout le dispositif qu'il faut mettre en place pour revenir en maîtrise là-dessus, mais ça ne se fait pas tout seul. Pour rester sur la question des changements de process et peut-être élargir aux personnes, Cyril, tu as rapidement évoqué le fait que recruter des spécialistes pour qu'ils viennent

57:24 gérer le cloud chez soi, ce n'était pas une bonne façon de faire parce que ça mettait sur la touche les gens qui connaissent les applications. Ce n'était pas suffisant. Du coup, j'aimerais bien poser une question sur la formation des personnes. On en parlait un tout petit peu avant de commencer la conférence sur tous les modules, tout ce qui existait en termes de formation. Est-ce qu'Emmanuel, d'abord, et peut-être Cyril pour compléter, tu peux nous raconter comment vous y êtes pris en matière de… awareness peut-être, mais surtout formation pour les personnes en charge. Donc, c'est vrai que le parti pris qu'on a pris dès le début, Le but, c'était que les migrations allaient être faites par nos people. On sait qu'il y a d'autres modèles où on fait faire l'acte de migration. On a voulu le faire nous-mêmes en l'intégrant finalement dans le dispositif de formation et de transformation de ces people. C'est-à-dire qu'on s'est dit qu'elles allaient apprendre aussi le cloud au travers de cette migration.

58:25 Donc effectivement, dans tout le programme de migration, il y avait tout un chantier important autour de la formation des employés, avec par métier des cursus qui étaient identifiés, qui étaient posés avec des formations, que ce soit des formations d'AWS, mais aussi des formations internes, des bootcamps, des choses comme ça. Ou des game day. Et donc, du coup, on est allé proposer finalement aux collaborateurs, en fonction de son métier, des parcours de formation répartis dans l'année en fonction de son actualité. Mais c'est vraiment un truc qui est important à bien intégrer parce que déjà, ça prend du temps. Et donc, c'est du temps au moins qu'on a pour faire les actions de migration. Et en même temps, il ne faut pas le laisser pour la fin parce que du coup, ça crée du risque et puis ça crée du bruit pendant les actes de migration où les gens ne sont pas à l'aise. C'est quelque chose qui est long, la migration des personnes et la transformation des personnes.

59:26 Au début, on se dit qu'ils vont apprendre le cloud, mais on est comme ça. En fait, dans la réalité, ça prend vraiment du temps. Ce n'est pas quelque chose, ce n'est pas parce qu'on a fait une formation ou deux, en fait, que du coup, les personnes sont à l'aise. Il faut ces formations, mais il faut aussi du temps entre ces formations pour qu'elles manipulent et tout ça. Et on se rend compte que c'est vraiment panique déjà. Cyril, tu voulais compléter cette partie-là, parce que je sais que ça te tenait pas mal à cœur. Oui, ça reste beaucoup au modèle organisationnel de transformation. Pour ça, quand je disais qu'on s'appuie essentiellement sur l'interne, je confirme ce que... Après, ça n'empêche pas que d'avoir des ressources externes pour apporter un savoir-faire pointu et initier quelque chose, c'est aussi un mouvement qu'on voit assez facilitant. Donc après, sur les modèles, on suit ça de très près, parce qu'évidemment, nous, on essaie de trouver les façons de faire qui sont les plus utiles pour les diffuser à nos clients, comme le framework dont j'ai parlé tout à l'heure. Et il y a quelque chose qui est assez récurrent, c'est cette notion de construire un centre de compétences qu'on va appeler CCOI, qu'on va appeler Cloud Business Office, peu importe.

1:00:37 Donc avec des gens qui vont se spécialiser, donc principalement des gens en interne qu'on va faire monter en compétences. Mais il y a des effets de bord, c'est-à-dire que déjà on va identifier des gens qui sont déjà soit formés un peu, soit qui sont sensibles au cloud, ça les intéresse. Donc on va finalement appauvrir le reste de l'entreprise pour faire monter ce centre de compétences qui va lui un petit peu finalement évoluer plus vite que le reste de l'entreprise, qui va devenir bon et tout ça. Et passer cette étape-là, le risque c'est que ces savoir-faire, ils ne reviennent pas dans le reste de l'entreprise. Nous on voit que c'est une étape assez critique. Une fois que cet organe entre guillemets central qui va définir la stratégie, qui va définir les normes, les bonnes pratiques, des choses comme ça, il faut qu'après... Il y a un SMH, et il y a des modèles, après, qui sont organisationnels, pas de WVS. On parle de boîte de pétri, donc le côté aller créer des colonies quelque part. Donc, il faut que ces gens qui ont maturé, ensuite reviennent dans des parties plus périphériques. Tout à l'heure, Emmanuel expliquait aussi qu'ils allaient rentrer maintenant dans cette phase où il y a une décentralisation ou un éclatement, entre guillemets.

1:01:41 Ça fait partie de ça. C'est-à-dire qu'il faut aussi après aller accompagner ceux qui n'ont pas fait partie du bateau initial. Qui n'ont pas autant appris ou autant profité. C'est un des défauts classiques. Il y a une espèce de structure où des fois c'est une entité dans l'entreprise, ça peut être une filiale spécialisée qui devient un peu l'espèce de superstar. Ça y est, l'entreprise peut se dire, on est dans le cloud, on fait des trucs incroyables. Et puis en fait, il y a 95% des gens qui se sentent insultés quand on dit ça, parce que leur boulot n'a pas changé. Finalement, on ne leur a pas proposé les formations qu'ont vues les autres. Il y a ce côté après de passer à une deuxième étape. Ce que tu dis, c'est qu'il y a le moment du projet qui centralise un certain nombre de fonctions, on l'a bien vu dans ce qu'Emmanuel décrit, et qu'il ne faut pas rater l'étape d'après, qui est la redécentralisation. Le fait qu'on rende les compétences, les personnes, aux projets, aux équipes, pour qu'elles aillent continuer de nourrir avec ce qu'elles ont appris, les évolutions et les refactoring dont on a parlé tout à l'heure sur les projets, c'est ça?

1:02:46 Exactement. Ok. Super intéressant. Donc un mouvement de balancier, on centralise, on redécentralise quand on a fait le gros du projet ou quand on a fini le projet de migration. Après, j'abonde aussi dans le sens des... manuel où il faut quand même ce côté un peu détaché entre guillemets parce que c'est compliqué de faire maturer toute l'entreprise en même temps après ça dépend des tailles d'entreprise mais si on y a un côté il faut un effet d'entraînement c'est pareil aussi pour les projets entre quatre ans et un an C'est quand même un changement culturel qui n'est pas dément, mais c'est quand même différent. Et pour qu'une entreprise change, il faut qu'il y ait un enjeu quelque part. Si on traite deux, trois applications où les utilisateurs ne verront pas la différence, qui va changer ses façons de travailler pour quelque chose où personne ne voit l'impact. Il faut que ce soit un peu visible, qu'il y ait un petit enjeu, soit de temps, soit de taille du projet, pour qu'il y ait un côté d'entraînement à la transformation, je parle au sens.

1:03:47 Donc c'est pareil pour cette entité un peu spécialisée, c'est normal qu'elle se détache, qu'elle n'ait pas la même vitesse que les autres, parce que sinon on mettrait trop de temps, on n'arriverait pas à emmener tout le monde à la même vitesse. Mais voilà, il y a un moment, il faut qu'elle s'arrête là où elle est et qu'elle attire quelque part tout le reste de l'entreprise jusqu'à elle. Ok. Merci beaucoup Cyril, Emmanuel. Merci à tous les participants. Est-ce que, peut-être pour conclure, est-ce que je peux vous demander de dire un petit mot de conclusion? Emmanuel, tu peux commencer? Si tu veux, si tu ne veux pas, tu passes ton tour, je vais voir. Non, mais voilà, je pense que... Je ne sais pas quoi vous dire. Non, franchement, je pense qu'on a dit l'essentiel. Je ne veux pas redire de choses complémentaires. Non, écoute, ne sois pas embêté par ma question. C'était un truc que tu n'as pas dit, que tu as envie de dire.

1:04:49 C'est ça, je cherchais, mais je n'en trouvais pas. Je suis très contente de moi, c'est qu'on t'a fait tout dire. Cyril, est-ce que tu veux nous dire un petit mot de conclusion? Un petit. Alors, merci à Tech.Rocks, bien sûr, pour l'organisation. Une chose que je pense, j'espère que vous avez compris dans l'intervention d'Emmanuel, c'est que pour que ça se passe bien, ça n'arrive pas par hasard. Il faut mettre en place des choses. Dans son cas, ça a été de staffer plus de PMO qu'envisagé. De manière générale, dans la fonction FinOps que j'adresse, il y a ce côté-là. Tout est assez clair, les frameworks sont tournés d'accord, même entre Clouders, avec des tiers. Mais la vraie question, c'est qu'il faut faire quelque chose, ça n'arrive pas tout seul. Les outils ne vont pas prendre les décisions à votre place, ils vont juste vous aider à les implémenter de manière programmatique, par exemple. Il faut quand même se poser des questions, il faut définir une stratégie. Donc, il y a quand même un minimum à investir. Donc là, on parlait de pieds et mots tout à l'heure, mais c'est la même chose finalement pour le FinOps. Le cloud, la migration vers le cloud, pour que ça se passe bien, il faut faire ce qu'il faut pour que ça se passe bien.

1:05:54 Ce n'est pas par défaut. Le fait de migrer dans le cloud ne garantit pas que les choses vont se passer bien. Il y a un processus, il y a des choses à mettre en place. Super. Merci, Cyril. Donc, moi, je retiens que finalement, on a parlé de cloud, de migration dans le cloud comme de quelque chose de transformant de plein de dimensions. Évidemment, le sujet qu'on voulait aborder aujourd'hui, c'était la partie économique, c'est-à-dire comment est-ce qu'on… tire parti de cette transformation pour dépenser moins. et ou pour, à dépense égale, être plus performant, plus innovant, plus rapide, puisque c'est un des enjeux dont vous avez parlé beaucoup. Et comme tout projet transformant, il s'appuie sur des personnes et sur de la technologie, mais surtout sur des personnes. Et la question, c'est de mettre les gens dans les meilleures conditions pour qu'elles… elle fasse arriver le projet, atterrir le projet sur la cible qu'on vise.

1:06:56 Ok, merci à tous. C'était super de discuter avec vous, y compris pendant la phase de préparation. Je vous remercie pour votre temps et pour votre partage d'expérience. J'espère que ça a intéressé nos participants. Je crois qu'on peut conclure. Si je ne me trompe pas, Noémie, lorsqu'on va conclure, on va se retrouver dans l'étape de networking. Voilà, elle est confirmée dans le chat. Merci à tous. A tout de suite sur l'étape pour ceux qui veulent.