L'histoire d'une scale-up : de la startup à la résilience

0:01 Vous savez que ce cher Candide nous a quand même sacrément guidés avec son « il faut cultiver notre jardin », etc. Et c'est justement ce que nous allons découvrir avec l'histoire de Splio, cette start-up qui a su transformer en scale-up tout en cultivant sa résilience humaine et technologique. Et alors, c'est François Pasquet de DoiT et Romain Concaud de Splio qui vont partager avec nous leur parcours, les défis rencontrés lors de la migration vers le cloud, l'optimisation FinOps et comment une équipe de DevOps proactive a été la clé pour une croissance durable. Je vous demande d'accueillir sous un tonnerre d'applaudissements François Pasquet, Technical Account Manager de DoiT, Romain Concaud de Ciseaux Splio, j'espère que j'ai bien dit Ciseaux et pas Ciseaux. C'est Tizot. Et sous vos applaudissements nourris avec notre jingle qu'on adore. L'histoire d'une scale-up, de la start-up à la résistance, à la résilience, pardon.

1:01 Résistance aussi, peut-être, je ne sais pas. Résistance aussi. Vous avez la zapette, vous avez tout ce qu'il faut. Je vous laisse. Comme on dit, floor is yours. Merci. Enjoy. Bonjour tout le monde. On va commencer par se présenter. C'est déjà un premier bon pas. Bon début. Alors, moi je suis François Pasquet, je suis Technical Account Manager chez Duit depuis 3 ans, presque 3 ans. Auparavant, je suis... J'ai travaillé chez AWS, toujours en tant que TAM. Et puis, je suis passé par Thales. Je travaillais sur des équipements embarqués dans les avions. Puisqu'avant, j'étais militaire pendant 15 ans dans l'armée de l'air. Et j'ai fini ma carrière d'ailleurs dans l'Airbus A330 présidentiel, où je m'occupais de toute la partie télécom. Et donc me voilà aujourd'hui devant vous à parler tech et en compagnie de co-présentateur aujourd'hui Romain, que je vais laisser se présenter. Merci beaucoup.

2:02 Moi c'est Romain Concaud, mon CV va être beaucoup plus rapide. Je suis RSI chez Splio depuis maintenant 8 ans et j'ai surtout une expérience de DevOps Manager, ce qui va nous intéresser aujourd'hui. Pour introduire un peu plus Plio, qu'est-ce qu'on est? On est une jeune société qui a été créée en 2001, qui est une société éditrice de logiciels. On vend une plateforme type SaaS, c'est une plateforme CRM à destination du retail et du e-commerce. Et puis on est là aussi pour DoiT. Alors DoiT, c'est un partenaire des cloud providers. Et nous, on aide les digital natives à accélérer, à innover et puis à améliorer le ratio coût-performance. Et donc voilà, ça, ça fait partie aussi de mon job de tous les jours, c'est d'accompagner les clients justement. Dans leur voyage compliqué parfois dans le cloud. Et donc pour l'histoire qu'on va vous raconter aujourd'hui, on va partir du tout début, donc la naissance de Splio.

3:10 Donc au départ, c'est une start-up, une start-up, c'est quand même assez artisanal le fonctionnement au début. Et donc, les gens sont multicasquettes, ils font beaucoup de rôles en même temps. Et après un travail acharné, ils arrivent à lever des fonds. Et donc, à partir de cette levée de fonds, c'est véritablement là que commence l'histoire de Spio. Ah oui, en effet, on ne va pas raconter toute l'histoire de Splio parce que depuis 2001, il s'est passé quand même beaucoup de choses. Mais aujourd'hui, on va vous raconter l'histoire à un début, il y a quand même un petit moment. Le moment un peu fatidique pour n'importe quelle startup, c'est le moment où Splio a enfin réussi à convaincre qu'elle était capable de répondre à un besoin. Et en plus, c'est super cool, il y a beaucoup de gens qui partagent ce besoin. Et c'est à cette étape-là que finalement tout va s'accélérer. C'est le moment où on a eu de la chance, nos deux cofondateurs ont fait appel à une personne qui a structuré ce PIO.

4:11 Donc par structurer, on entend mettre en place des nouveaux services comme un service RH, un service finance, très utile pour faire des levées de fonds. Mais bien évidemment, on a aussi commencé à pas mal grossir des services type commercial. On a aussi bien évidemment fait grossir la tech, ce qui est la partie qui nous intéresse le plus aujourd'hui. Côté tech, il faut se dire qu'à l'origine, comme disait François, on avait des profils assez multicasket. Et à partir de là, on va recruter des profils assez spécialisés. Donc on va recruter de la QA, des produits, des DevOps. On va recruter des SRE. Donc là, on commence déjà finalement, on est au début de l'histoire, mais on va avoir un gros choc de culture. Parce que finalement, il va falloir faire travailler tout le monde ensemble. On n'a pas réinventé la roue, on est passé directement sur une méthodologie agile. Mais mine de rien, Il fallait faire cette transition. La difficulté a été de dire à des gens qui étaient là avant au mode startup qu'effectivement, à l'origine, pour mettre en prod, il suffisait d'aller sur un serveur, d'éditer le fichier en live et puis c'était en production.

5:12 Mais en vrai, c'est peut-être plus efficace de créer un ticket, de le mettre dans un backlog, de faire un poker planning, de le coaster, de faire des merge requests, faire des tests, passer par la QE. Au début, ce n'était pas facile à faire passer comme message. Mais finalement, comme le backlog grossissait aussi vite que la société, Passer par des rituels et des process a permis de rassurer finalement. Et le fait d'avoir recruté des gens qui, eux, connaissaient cette méthodologie, avaient l'habitude de ces process, a permis de rassurer. Et finalement, en très peu de temps, on a réussi à partir sur une méthodologie et des rituels sains et qui nous ont permis de passer cette étape fatidique de start-up to scale-up. Donc là, le produit plaît, il y a des bons feedbacks, mais derrière, les bons feedbacks, ça ne fait pas tout. Parce qu'il y a toute une série de challenges qui s'annoncent, et techniquement, il faut quand même assurer, il y a plus de clients, plus de trafic, et donc il faut répondre à tout ça, et là, on n'est plus trop dans le mode artisanal.

6:14 On passe vraiment, il faut industrialiser, il faut, on va dire, même professionnaliser. Et donc c'est à ce moment-là en fait que Splio est devenu une scale-up. Et donc avec ces... ces points-là dont Romain va parler. Je vais le laisser dérouler par rapport à cette partie entre 10 et 15 ans. Cette étape a duré un moment. C'était une étape assez cool parce qu'on n'a jamais vendu aussi vite, on n'a jamais onboardé aussi vite. Tout était pour le mieux. Petit détail important, à ce moment-là, Splio était sur des infrastructures on-premise. Il y a eu un gros travail fait par des pratiques DevOps, par l'introduction de spécialités. On a fait un gros travail d'industrialisation, d'automatisation pour nous permettre d'aller beaucoup plus vite. On a introduit des technologies comme Kubernetes ou même Kafka. Et quand même, au bout d'un moment, on se disait, bon, on signe vite, mais on se rend compte qu'il y a une partie de notre process qui est difficilement compréhensible.

7:18 C'est quand même le fait d'avoir des infrastructures physiques. Pour la simple et bonne raison, c'est qu'on ne peut pas acheter un serveur comme on achète un plat le soir devant la télé. Il n'est pas livré en quelques heures. Et donc, à cause de ces limites, on s'était dit, on va avoir un mur et on va se retrouver dans une situation un peu paradoxale, de devoir peut-être refuser de signer des contrats parce qu'on n'est pas en capacité d'y répondre. Donc forcément à ce moment-là, la décision a été faite de partir sur du cloud public pour permettre d'avoir ces infrastructures qui permettent de scaler. Et dès cette approche, on a commencé à avoir une vraie scission au sein de la R&D. On va avoir des parties un peu qu'on pourrait appeler des tracteurs, c'est-à-dire qu'ils vont trouver... sur internet des tas d'articles pour dire à quel point il y a plein de sociétés qui regrettent d'être allées dans le cloud, que l'on prime, c'est quand même super génial. Et puis à l'inverse, on va avoir des profils plus promoteurs, qui vont finalement... C'est généralement des profils qu'on a recrutés récemment, qui ont connu un environnement cloud. Et finalement qui était assez frustré du on-premise, par exemple un machin qui demande à avoir un Kafka juste pour faire un test, bon là on va lui dire non, parce qu'en fait il y a quand même du travail derrière, même si on industrialise super bien.

8:28 Donc on a été sur le cloud, après l'autre fait qui était important à prendre en considération, c'est qu'on a quand même recruté des profils qui connaissaient l'on-premise, et donc c'est quand même pas facile. De faire cette montée en compétences sur le cloud, moi y compris. Et donc on a quand même beaucoup réfléchi sur comment on peut faire cette approche, comment on va faire évoluer finalement la culture de la société qui est habituée à gérer des serveurs sur du cloud. Le premier a été, c'est un peu paradoxal, mais on a limité l'usage des technologies. On est resté sur celles qu'on connaissait, c'est-à-dire du Kubernetes et du Kafka. Principalement pas que. Et la seconde approche, c'est ce cadre-là, on va rester dedans, on va blinder notre monitoring, donc on va éviter d'utiliser de technologies à des fins de mieux contrôler l'évolution de notre architecture, parce que le cloud, ça permet de faire quand même beaucoup de choses. Le deuxième point, ça a été aussi un meilleur contrôle des risques associés. Je peux donner un exemple, c'est on voit sur une jolie interface d'un bucket S3 un beau bouton turbo, on se dit que le nom suffit à lui-même, pas besoin de lire la doc, et puis finalement c'est assez déceptif. Mais par contre le lendemain, une belle alerting, 1500 euros plus tard, c'est quand même pas génial.

9:28 Et donc c'est ce genre de situation. qu'on veut éviter, on ne peut pas tout éviter, mais on est dans le cadre de l'apprentissage par l'erreur et donc il faut un bon monitoring, il faut bien s'assurer que tout se fait comme prévu. Grâce à ce cadre, grâce à cet alerting, on nous a permis de passer rapidement sur la partie scale-up. Rapidement, on passe les côtés un peu dans le sens où nos infrastructures étaient faites pour une plateforme et que finalement le cloud c'est des serveurs où on n'a pas trop la main. Il faut quand même changer les cultures du type avant on benchmarkait des disques durs. On clique, on achète un disque dur, on n'a pas trop la main. Mais à part ces petits détails qui ont été un peu longs, on s'en est plutôt bien sortis. Exactement, parce que c'est cette approche méthodique qui permet de prendre des décisions éclairées, d'être capable aussi d'optimiser tout en gardant la performance. C'est comme dans toute navigation, parce qu'en fait, je ne sais pas si vous avez vu, mais avec Romain, on a choisi d'illustrer que si je reviens, on a mis un petit bateau là en haut.

10:33 Donc il y a le petit bateau start-up, et puis après, il y a le bateau qui a poussé. Ce n'est plus la barque, maintenant, c'est vraiment le navire. Avec un équipage, et puis derrière, là, on est en croisière. Maintenant, il faut assurer, il faut gérer tout ce qui est arrivé, tous les challenges. Donc là, pour garder le cap, c'est vraiment ça la difficulté. Parce que dès qu'on diverge du cap, c'est quand même plus longtemps. Si on attend longtemps, c'est quand même difficile de rattraper et de revenir par le cap qu'on s'était fixé au départ. Et donc là, à partir de là, il y a les acquisitions. Après, les acquisitions, c'est aussi... Des opportunités. Moi, j'ai vu ça avec tous mes clients. Les acquisitions, c'est aussi une manière de voir. Comment on peut gérer le même problème, mais avec des visions différentes ?

11:37 Parce que des acquisitions, c'est aussi des gens qui sont dans le même secteur d'activité, dans le même segment. Et donc là, quand on a inclus les gens, peut-être qu'ils avaient une autre vision sur la manière de gérer tel ou tel problème ou tel ou tel topique. Et donc c'est à partir de là qu'il y a une autre histoire aussi qui commence pour Splio, avec son lot de challenges, notamment du legacy. En effet, cette étape est venue assez naturellement, c'est-à-dire que là on est dans le cloud, c'est super bien, on signe des clients, on scale sans souci nos infrastructures. On se rend compte quand même que par rapport à l'idée de départ, il y a certains vecteurs de développement qui peuvent être intéressants, compléter notre produit. Mais il faut forcer de constater que nos concurrents ont mis quand même plusieurs années pour avoir ces fonctionnalités. Nous, on ne peut pas vraiment le faire en quelques semaines, il n'y a pas trop de magie. Donc forcément, on arrive dans une logique d'acquisition, donc essayer de compléter notre produit, enfin d'atteindre cet objectif. Et la phase d'acquisition a introduit quand même deux gros challenges.

12:41 Alors il y a le premier challenge qui est technique, on ne va pas trop rentrer dans les détails, mais on peut se dire que connecter deux plateformes qui n'ont pas été conçues pour travailler entre elles, c'est difficile. Il y a plein de documentation pour approcher ce souci, mais il y a aussi l'aspect humain. L'aspect humain parce que dans ces acquisitions, on va avoir peut-être... des choix philosophiques qui n'ont pas été les nôtres. Je prends des exemples assez simples, plateforme as de service versus infrastructure as de service, deux plateformes complètement opposées. On a eu l'opportunité d'avoir monotone versus multitone, comment on fait communiquer tout ça, comment on fait fonctionner ces gens. Finalement, c'est une vraie culture complètement différente. On a eu la chance d'expérimenter différentes approches, parce qu'on a fait plusieurs acquisitions. La première a été de se dire, potentiellement, on va laisser faire la nature, on va fusionner tous les services, côté R&D, et puis on va voir ce qui va en sortir. Finalement, avec du recul, on a quand même une scission, c'est-à-dire qu'on va avoir les gens qui ont l'habitude de travailler sur le plateforme as-a-service qui vont rester entre eux, et ceux qui sont sur infrastructure as-a-service qui, eux, vont rester de leur côté.

13:43 Finalement, ce n'est pas un très grand succès de mon point de vue. On a eu une autre opportunité finalement par la suite et là on a fait l'approche plutôt de prendre une décision forte dès le début. C'est-à-dire on a dit on maintient tel cap pour des raisons, il y a des raisons techniques mais en vrai dans le fond il fallait surtout prendre une décision parce que chaque solution avait ses avantages et ses inconvénients. Et à ce moment-là, c'est mon point de vue, mais finalement ça a été un moment difficile, mais ça a permis de rassurer une grande partie de la R&D, parce qu'au moins on était cohérent dans sa direction, dans son cap, pour reprendre l'image du bateau. Et c'est ce qui a quand même permis de passer à cette étape, finalement avoir une évolution de la culture chez Splio. Et malgré ces difficultés, ça a été assez bénéfique. Voilà comment on a passé la table acquisition. Et donc, on avait fini par trouver un nouvel équilibre. En fait, finalement, l'équilibre, c'est ce qui, selon moi, se révèle être le challenge le plus difficile à résoudre, à venir à bout.

14:49 Et voilà, donc derrière, on a appelé ça l'âge de raison. En fait, l'âge de raison, ce n'est pas parce que ce n'est pas la fin du voyage, pour rester dans la métaphore de la navigation, de la navigation. C'est juste qu'il y a des points qui ont été identifiés, et dans lesquels je suis sûr qu'il y a beaucoup d'entre vous qui vont se reconnaître dans ces points-là. On voulait en fait avec Romain vraiment axer notre présentation sur la résilience humaine. Parce qu'en fait on parle beaucoup de résilience tech. Quand on pense à Yavility, on pense à MultiEasy, on pense à... PCA, PRA, voilà. C'est ça qui, moi, en tout cas, quand on parle de Zian, c'est ça qui me vient à l'esprit. Mais ce n'est pas que ça, c'est bien d'autres choses. Et là, le fait est que Splio a réussi. Derrière, il y a une équipe qui est soudée, comme un équipage qui est uni.

15:57 Chacun sait ce qu'il doit faire. Les métriques aussi sont définies. Parce que c'est ça le secret aussi, c'est trouver la bonne métrique. Derrière pour dégager aussi une notion de rentabilité. Parce que le but, c'est d'assurer la pérennité. Et donc là, c'est les trois points qu'on a trouvés, qu'on voulait mettre en valeur avec Romain, qui justement révèlent bien ce qui s'est passé aussi chez Splio. Oui, donc ces trois points sont un peu sortis de l'histoire de Splio, pour remettre dans le contexte. On reprend toujours l'histoire. On est dans le cloud, on peut scale, on a une plateforme qui vend du rêve. Et finalement, on se dit, malgré le fait qu'on a mis un cadre, qu'on a mis vraiment quelque chose de très rigoureux, on s'est empêché d'aller sur certains services un peu trop éloignés pour éviter de rajouter de la complexité. Finalement, on s'est quand même retrouvé à quelque chose de complexe. C'était inévitable, un peu l'échec. Mais on n'avait pas le choix, dans le sens où on va avoir du multi-cloud, on va avoir des multi-technologies, et toute cette complexité, elle n'est pas simple.

16:58 Et donc c'est à ce moment-là où on a commencé à travailler avec DoiT, puisque DoiT, avec une simple analyse de la facture, parce que tout le monde a ça, c'est assez facile à trouver, simple analyse de la facture, on va avoir une vraie analyse du comportement, de nos usages du cloud. Ce qui est intéressant avec ces KPI, comme tu disais, c'est que ces KPI sont compréhensibles aussi bien par un engineering manager qu'un responsable d'infrastructure ou même finalement un CFO. L'intérêt d'avoir ces informations, ça va être assez naturel. Côté engineering management, on va se dire, si je viens de faire une mise en production, je vois instantanément le lendemain ou le lendemain les conséquences des coûts. On va améliorer cette compréhension de quand je fais des choses, ça va coûter de l'argent. A partir de là, on rentre dans un cercle assez bénéfique où on va intégrer dans la réflexion quand un produit vient avec une fonctionnalité. On commence à le voir chez Splio, ça commence à venir. Le réflexe de se dire, ok, tu as une fonctionnalité, par défaut j'ai envie d'aller voir tout de suite l'état de l'art, les genres de plateformes qui répondent parfaitement à ce besoin.

17:58 Aujourd'hui, Ils vont introduire des notions d'efficacité, que ce soit en termes de coûts, mais aussi en termes de RSE, puisqu'en grossissant, on a de plus en plus de clients et on est de plus en plus challengé là-dessus. Et donc, en intégrant ces contraintes, finalement, on ne va pas aller vers le choix qu'on aurait pris au début sans prendre ces informations en compte. Et finalement, c'est ce petit changement qui a l'air simple comme ça, mais qui est fondamentalement différent, qui finalement, on a appelé l'âge de raison. L'âge de raison, je pense qu'on est à l'état où le réflexe est là. Maintenant, il faut que, je ne sais plus, on soit capable de le formaliser dans des process pour que quand il y a des nouvelles personnes qui arrivent dès le début, elles arrivent à ce niveau de réflexion. Et ce qui est intéressant, c'est la projection, c'est-à-dire que comme on arrive à anticiper les coûts de combien va coûter à builder, combien ça va coûter à faire le run ou même les migrations quand on est sur des systèmes de double run, ça challenge aussi côté product et en amont de se dire, mais si on est capable d'estimer ce que ça va coûter, est-ce que ça pourrait être intéressant de corréler ça à ce que ça va nous ramener en termes de business? Et là tout de suite ça part au CFO, il se dit en fait avant je faisais des petites règles en trois pour essayer d'estimer les évolutions des coûts de nos infrastructures et du cloud, mais là je peux prendre des décisions beaucoup plus précises, j'anticipe mieux et je prends des meilleures décisions sur ma roadmap pour prendre finalement ce qui est plus percutant et ce qui

19:10 va nous rapporter rapidement plus d'argent. Pas, mais ça c'est un choix. Donc là, on arrive au sommet de la montagne. L'ascension a été compliquée. Maintenant, il faut continuer, il faut survivre au sommet. Et le plus dur, quand même, c'est de rester compétitif, c'est d'avoir une rentabilité qui soit assurée. Et derrière, en fait, il faut quand même tirer des leçons de ce qu'on a vécu, de ce qu'on a vu. Et c'est ça qu'on souhaite mettre en avant avec Romain. Et moi, là, c'est dans la tech, mais ça fait parallèle avec... fait écho à ce que j'ai vécu moi quand j'étais militaire, on se révèle aussi à soi-même et aux autres dans la difficulté. Et c'est à ce moment-là qu'on se rend compte que la force d'un groupe, ça dépasse tout.

20:15 Et c'est ce qui est arrivé chez Spio. C'est des gens qui ont grandi ensemble. Et derrière, ça donne le résultat qui est là aujourd'hui. Et ça, c'est aussi preuve que l'humain, c'est ultra important. Donc ça, c'est la première leçon, la première grande leçon que nous, on voudrait faire passer. Et puis après, je vais laisser Romain développer sur... Tu peux revenir sur l'humain avant tout. Mais voilà, parce que tu as des exemples aussi. C'est les trois exemples qu'on voudrait partager, les trois leçons. Finalement, ça résume un peu l'histoire qu'on vous a racontée aujourd'hui. L'humain vaut tout parce que, mine de rien, pour faire tous ces changements de culture, il était primordial que, en tout cas chez Splio c'était le cas, que les gens comprennent le pourquoi. Quand je prenais l'exemple au début de la personne qui éditait en live le code, il a compris pourquoi c'était intérêt de passer par un tas de rituels pour mettre en prod.

21:17 Ça a été un vecteur qui l'a rassuré. Donc la compréhension était très importante, donc la communication. Le fait qu'on avait mis en place aussi des process dans le cadre agile pour être capable de remettre Monter rapidement des inquiétudes, des points rouges. Et à la fin, finalement, il y a eu un gros aspect cadre, c'est-à-dire que quand on allait dans le cloud, on a mis des cadres plus ou moins larges. Ce cadre a évolué, c'est important d'être à l'écoute et de s'assurer que les décisions qu'on a prises dans le passé soient toujours d'actualité. Ce cadre, il permet de donner une zone où on autorise les gens à faire leur créativité, à mettre en place leur service, etc. Mais voilà, tout est une question de curseur pour définir ce cadre. Donc on a essayé de mettre quelques points, par exemple le fait à l'innovation, stabilité, vitesse ou qualité, ambition versus réalisme. Tous ces points-là, finalement, il faut itérer régulièrement parce que la R&D évolue en fonction des recrutements, en fonction du passé des gens. Et il faut faire évoluer, d'un point de vue DevOps, les services qu'on fournit pour ces raisons.

22:22 Et enfin, le dernier point qui est pour moi le plus important, et c'est pour ça qu'on a mis sous un format de fraise chronologique, c'est tout simplement parce que ce qui a rythmé toutes ces étapes venait à chaque fois de l'organisation. C'est-à-dire, ça ne servait à rien de tout de suite faire quelque chose de hyper scalable quand on a une phase de start-up. Vaut mieux peut-être plus se concentrer sur le produit. Donc finalement, vraiment rester, ne pas essayer de précipiter les choses, être attentif à l'équipe et derrière être capable de donner les bonnes réponses. Un peu pour résumer. Voilà, donc on arrive en fait à la fin de l'histoire. On espère que ça vous a plu. Et si vous avez des questions, on est encore là. Je crois qu'il y a trois minutes. Non? On a encore trois minutes de présentation, mais il y a encore des questions. Exact. Potentiellement 13 minutes de questions-réponses. Il y a du rab. Il y a du rab. C'est ça qui est génial. Donc, c'est la fin. C'est pas un bel écran quand même. Sérieusement, on voit rien, mais c'est génial.

23:24 Clairement, moi je vois du blanc. On voit absolument rien, mais c'est un bel écran. Alors on va démarrer la session de questions-réponses avec nos deux super hôtesses qui vont vous faire passer les micros. Qui a une question? Ah, pardon, à droite. Il faudra qu'on m'explique côté cours, côté jardin. Je sais qu'il y a un truc droite-gauche, côté cours, côté jardin. Je ne sais jamais, en fait. Je ne m'en souviens pas. J'ai une question. Vous avez dit que vous étiez capable, vous essayez d'anticiper le coût du run. Et ça, c'est un gros challenge. J'aimerais bien savoir comment vous faites. Le coût du run? Je ne sais pas, après chez Splio, il y a peut-être un exemple concret. Après, il y a la théorie, mais il y a la pratique. Effectivement, le coût du run. Au début, comment ça s'est fait? Ça s'est fait grâce à DoiT, c'est-à-dire en analysant la facture. On n'est pas 10 000, on sait quand on réalise des choses et donc on est capable de voir à deux jours l'impact et les conséquences de ce qu'on exécute.

24:25 Après, on a fait aussi, je pense que comme beaucoup de sociétés, on a fait un gros travail pour bien mettre les bons labels sur les bonnes ressources. On a aussi automatisé ça dans les pratiques DevOps. Quand on réalise des applicatifs, on labellise bien, ce qui permet d'une remontée très rapide sur les interfaces de DoiT. Et derrière, les engineering managers vont aller sur DoiT et sont capables de voir les évolutions de leurs coûts. Et ce qui est intéressant, c'est à corréler ça finalement à peut-être des business, des KP business, et être capable de se dire, effectivement... Ça c'est normal, ça c'est inattendu. Exactement, est-ce que c'est dans le cas d'un double run, donc je vais avoir un coût qui va augmenter parce que j'ai... J'ai lancé une nouvelle plateforme, mais je suis en train de migrer, donc c'est anticipé, pas de souci. Ou finalement de se dire, j'ai envoyé plein d'emails, donc c'est normal, je n'ai plus... S'il n'y a pas d'explication, là, on lance des investigations plus poussées. Et puis, je dirais même, pour rajouter à ce que tu dis, le... Pardon, je suis terrible. Ça, c'est l'effet Tommy Dessine à chaque fois. On est cueillis. Mais il y a aussi le fait de bien comprendre comment fonctionne ce qu'ils appellent chez les code providers le pricing model.

25:31 C'est-à-dire que chez Adouves, par exemple, ils utilisent le CUR, le Cost and Usage Report, et chaque, ce qu'ils appellent les lignes sur la facturation, c'est des LAN items. Et donc en fait, quand déjà on arrive à déchiffrer ça, et qu'on arrive à les mettre dans des dashboards qui soient compréhensibles par tout le monde, C'est là aussi qu'on peut anticiper, c'est là qu'on peut voir véritablement, ok, là j'ai ma prod, là j'ai mon coup de dev, ça c'est un truc que j'attends parce qu'il y a une release qui va sortir, donc je sais que cette partie-là va augmenter. Mais en fait, le véritable secret, c'est le tag. Il faut tout taguer. Alors il y a des trucs, les cours réseau par exemple, c'est difficile parce qu'on ne peut pas les relier à telle ou telle équipe ou telle ou telle application. Donc c'est là où ça devient difficile. Mais on arrive aussi à corréler... Même sans arriver à taguer, en faisant la bonne analyse et en y mettant les bons SKU qui correspondent, on arrive à avoir une vision.

26:45 Parce que les coûts, quand vous cliquez sur la souris, launch d'une instance, vous poppez une instance C2 sur AWS, les coûts sont répercutés et publiés sur le Cost Engine Report entre 6 et 24 heures après. Donc là vous avez une petite latence, mais ça vous permet de ne pas avoir une trop grande surprise. On va dire que c'est du jour au lendemain. Je ne sais pas si j'ai participé à répondre à la question. Encore une autre question? C'était pour dire que c'était OK? La réponse était bonne, validée, super. Est-ce qu'il y a une autre question dans la salle? Yvan, tu es là ? Il voulait nous faire une blague et nous poser des questions difficiles. Je me permettrais juste de compléter un point, on n'a peut-être pas trop insisté, mais on n'arrivera jamais à avoir le coût exact d'un coût de run, c'est clairement impossible. Mais par contre, on est quand même capable d'avoir la tendance, on est capable, quand ça augmente, d'identifier la zone qui est responsable de l'augmentation de la facture.

27:48 Mais effectivement, c'est impossible de chercher au centime près l'explication du coût. Je pense qu'on peut se quitter sur le coup du Rennes. Oui. C'est OK? Belle conclusion. Impeccable. Rien à rajouter? Parfait. Merci beaucoup à tous les deux. Merci beaucoup. J'espère que vous avez pris autant de plaisir à être sur scène que nous à vous écouter. J'espère que ça a été utile de partager cette expérience. Je vous laisse repartir côté. Merci beaucoup.