Guillaume Lannebère, Betclic : « Nous sortons complètement du on-premise d'ici fin 2024 »

CIO : Vous dirigez le Centre d'excellence cloud de Betclic. De quoi s'agit-il exactement ?

Guillaume Lannebère : Nous avons pris la décision de passer dans le cloud en 2018 et nous avons commencé à basculer en 2020. Nous avons entamé la migration avec AWS pendant le premier confinement et la mise en place a duré 2 ans. A l'époque, nous n'avions qu'un seul provider, mais aujourd'hui nous exploitons aussi Azure de Microsoft. Et le Cloud center of excellence (CCoE) a été mis en place il y a deux ans, pour accompagner l'ensemble des équipes IT dans le move to cloud. Nous sommes une équipe de 5 au sein d'une DSI qui compte environ 400 personnes. Au total, Betclic emploie environ 1200 personnes, internes et externes pour un CA supérieur à 1 md€. La majorité de la masse salariale, c'est de l'IT.

Vous avez donc aujourd'hui quasiment terminé la migration dans le cloud ?

Nous nous sommes effectivement engagés à sortir complétement du on-premise d'ici à fin 2024 et nous terminons la migration de nos projets entre AWS et Azure. Auparavant, nous avions 3 datacenters et AWS que nous traitions comme un 4e datacenter en quelque sorte. Pour passer dans le cloud, nous avons « réarchitecturé » notre plate-forme afin de répondre aux besoins de notre activité, qui évoluent. Nous avons donc pris une approche microservices avec beaucoup d'asynchrone, pour tenir les pics de charge. Il s'agit vraiment de « scaler » et d'aller beaucoup plus vite pour nous adapter à l'activité sur notre plate-forme. Je parle de la façon dont on gère le trafic lors d'un événement exceptionnel tel qu'une Coupe du monde ou l'Euro de football, comme en ce moment.

Pour quelles raisons avez-vous choisi deux providers ?

Bien sûr, pour ne pas mettre tous nos oeufs dans le même panier. Mais cela va aussi nous permettre de bénéficier du meilleur des deux mondes. Nous pouvons ainsi utiliser les services managés d'AWS et ceux d'Azure. Et qui plus est, nous avons commencé sur AWS, mais il se trouve que nous avons un important existant Microsoft : une grosse base SQL Server et beaucoup de .Net. Comme nous avons un programme de migration dans le cloud très ambitieux, Azure va nous permettre de ne pas réarchitecturer toutes les applications. Microsoft gère bien mieux SQL Server qu'AWS, par exemple. Notre idée c'est aussi d'opter pour le bon cloud provider pour le bon usage.

La plate-forme Betclic en ligne.

Avec Azure, nous allons faire du rehosting, voire du lift and shift. Nous allons utiliser cette dernière option pour le paiement, par exemple, dont l'architecture est déjà adaptée. Le module est déjà développé avec des outils Microsoft, il est plus simple de le rendre compatible avec Azure.

Qu'en est-il de votre coeur d'activité, le pari sportif ?

Le trafic sur la partie directement liée au sport est à la fois prédictible et non prédictible. Par exemple, je sais que l'équipe de France va jouer ce soir. Je connais l'horaire de début du match et à peu près l'heure à laquelle il va se terminer, avec ou sans prolongations. En revanche, le résultat et la physionomie du match ne sont pas prédictibles. Si nos joueurs gagnent, tout le monde va se connecter à la fin du match et tout le monde va gagner de l'argent, mais à l'inverse, malheureusement, si le résultat est défavorable, nos clients vont moins se connecter parce qu'ils savent qu'ils ont perdu. Et c'est cette partie-là qui n'est pas du tout prédictible. Cette partie « sports » est sur AWS, parce qu'elle a justement besoin de cette adaptabilité, du scaling.

Pour les jeux de casino, nous avons aussi besoin de scaling, mais de façon un peu moins linéaire. Les comportements s'apparentent davantage à ceux observés sur les sites de e-commerce. Les utilisateurs vont jouer en rentrant du travail le soir jusqu'à l'heure d'aller se coucher. Beaucoup moins dans la journée ou le week-end, par exemple. C'est une activité plus prédictible, et nous l'hébergeons donc sur Azure. C'est aussi le cas du login, également sur Azure. Quand un de nos clients gagne, la première chose qu'il fait c'est de se connecter pour être payé.

Est-ce aussi parce que vous n'avez que très peu d'activités prédictibles que vous avez développé votre propre calendrier de scaling ?

Nous avons adopté ce calendrier de couleurs spécifique à notre activité, sur le même principe que ce soit sur AWS ou Azure, parce que notre trafic n'est pas complètement prédictible et que nos pics de charge arrivent en quelques secondes à peine. Nous ne pouvons donc pas travailler avec les changements automatiques d'un provider pour ça. Nous nous basons sur des couleurs. C'est inspiré de notre marketing chez Betclic qui parle toujours en semaines vertes, rouges ou noires. Nous avons fait la même chose côté IT et nous parlons de passage à l'échelle vert, rouge ou noir. Par exemple, dans la journée entre 8h et 18h, on sait qu'aucun match de foot ne se joue, donc nous sommes en vert. Notre quantité d'instances sera au plus bas niveau parce qu'il n'y a pas beaucoup d'activité.

En revanche, encore une fois si durant la coupe du Monde, un match de la France est programmé le soir, nous passerons en noir à 19h00, c'est-à-dire un passage de 3 à 50 machines. Nous prenons toujours un peu de marge. En fin de match, l'arbitre siffle et tout le monde prend son application pour vérifier s'il a gagné ou perdu. On ne sait pas quand l'arbitre va siffler exactement, même si on a une idée du créneau durant lequel cela va se passer. On connaît en gros la durée du match, mais à l'intérieur de cette durée, rien n'est prédictible. Nous savons que, par exemple, de 20h00 à 23h30, il va falloir être réactif, mais qu'à partir de 23h30 tout à coup, le trafic va chuter parce que les utilisateurs vont dormir. Nous changeons de couleur à partir d'une demi-heure à une heure avant le match et jusqu'à une demi-heure à une heure après, pour tenir compte de buts ou de prolongations éventuels.

A quoi correspondent ces couleurs ?

Justement, nous avons opté pour des couleurs et non directement des chiffres, justement pour tester les valeurs limites dont nous avons besoin. Si un service se met à appeler beaucoup d'autres services à son tour, il va en fait faire écrouler ces services connexes. Les couleurs nous permettent de garder un point de vue global, de tester la couleur associée à une valeur pour être sûr de l'impact global sur Betclic.

Les couleurs correspondent à des nombres d'instances maximum. Cela va dépendre du service utilisé, mais généralement c'est 3 instances pour le vert. Le noir sera dans une fourchette autour de 50, voire davantage, et le rouge se situe entre les deux. Mais c'est davantage un pourcentage. Pour certains services, le noir pourra correspondre à 10 instances. Nous faisons aussi des passages à l'échelle sur les bases de données. En vert, nous n'avons besoin que d'une base avec peu de puissance. Pour traiter de gros volumes, nous aurons par contre quelque chose de beaucoup plus puissant.

Avez-vous déjà mesuré certains indicateurs depuis votre passage dans le cloud, comme l'augmentation de la productivité, de l'efficacité par rapport aux clients, la réduction des coûts... ?

Il est trop tôt, en particulier parce que nous sommes passés directement du on-premise au cloud, et que nous ne connaissons pas le coût on-premise. En revanche, nous faisons du finops, de la gestion des coûts et de la maîtrise des coûts. Nous nous en sommes préoccupés dès le démarrage. Cela fait partie à part entière de la gestion de notre démarche de scaling. Nous regardons, par exemple, si nous prenons trop de marge ou pas. Parce que bien sûr, au début, les équipes choisissent la plupart du temps une configuration en noir alors que le rouge suffirait. Ce sont des éléments que nous suivons, mais sans métrique comparative, parce que nous arrivons dans le cloud avec des habitudes venant du on-premise.

Justement, collaborez-vous sur la maîtrise des coûts avec votre DAF ?

Oui, nous avons fait un gros travail dès que nous sommes passés dans le cloud il y a 4 ans. Nous avons directement formé les équipes DAF et contrôle de gestion. Nous sommes passés par Gekko (aujourd'hui Accenture), un partenaire d'AWS. Les équipes de la finance ont accès à nos plates-formes AWS et Azure. Elles mettent en forme leur propre tableau de bord et j'échange avec elles au moins une fois par mois pour étudier les coûts. Mais aussi pour qu'elles comprennent techniquement pourquoi parfois, on assiste à des débords. Le cloud ne pardonne pas quand on fait une erreur, mais l'important, c'est de réagir à temps. Et d'expliquer ce qui s'est passé. Ce que l'on qualifie d'erreur dans ce cas, ce sera par exemple un développeur qui active un service, mais oublie de le désactiver. Ce qui peut vite coûter cher dans le cloud. Nous avons mis en place des mécanismes d'alertes.

Avez-vous développé une méthode spécifique de mesure des coûts ?

Nous avons défini un canevas pour l'ensemble des nouveaux projets que l'on nous présente au CCoE, pour passer dans le cloud. Nous demandons à l'équipe concernée quelle architecture, quels services elle va utiliser, comment elle a pensé la sécurité, la résilience, les mises à l'échelle, le backup, donc, en fait tout ce qui est aujourd'hui compris dans les piliers des Well Architectured Framework de Microsoft et d'Amazon. Le tout avec une calculatrice de coûts.

À partir de ces éléments, j'étiquette leur service, et je fais un point de suivi avec l'ensemble des équipes toutes les deux semaines. Il arrive qu'une équipe ait un peu peur, et démarre son projet avec une quantité de ressources réservées trop importante. S'ils sont trop hauts au niveau des coûts, nous analysons avec eux et nous essayons de comprendre les raisons de leur chiffrage.

Est-ce que cela signifie que vous avez des compétences purement finops dans vos équipes ?

Au sein du CCoE, nous n'avons que des compétences IT, mais qui maîtrisent parfaitement le cloud sous tous ses aspects et connaissent très bien les providers. Nous avons des développeurs, des personnes qui viennent de l'infrastructure, des architectes IT, etc. Le CCoE, ce sont des compétences cloud, finops, greenops, etc. Et notre rôle est de définir les bonnes pratiques en matière d'usage du cloud.