Entretien Giovanni Clément, CTO du groupe Adeo : « L'observabilité est l'affaire de tous »

Pourriez-vous présenter dans les grandes lignes le groupe Adeo et son projet de transformation numérique Common Digital Platform ?

Giovanni Clément : Adeo réunit 130 000 collaborateurs à travers le monde. Il est leader sur le do-it-yourself avec une orientation forte sur l’éthique écoresponsable, ce que nous appelons le make-it-positive et qui se ressent à travers toutes les filiales du groupe dont Leroy Merlin, Zôdio, Weldom. Le retail se transforme. C’est bien sûr exacerbé par la crise mais, depuis quelques années, les leaders réinventent la façon de consommer ou, si l’on parle de l’habitat, de se projeter dans la réalité virtuelle en montrant, par exemple, comment une cuisine va rendre chez soi. Le but d’Adeo, c’est donc de créer une expérience complète. Si vous voulez construire une maison, faire des plans, du câblage électrique, de la décoration, monter une cuisine ou un salon, cela consiste à offrir la capacité de gérer l’entièreté de votre projet avec différentes filiales. Leroy Merlin est axé sur le bricolage, Zôdio sur la décoration, etc. Dans cette réinvention du retail, il y a bien sûr le digital. A travers nos magasins, nous faisions du physique first et nous souhaitons homogénéiser un parcours qui démarre sur le web et trouve sa continuité dans les lieux de vente avec l’expérience physique. C’est extrêmement important de ne pas perdre un client entre les deux. La principale vertu de notre projet de digitalisation Common Digital Platform, c’est donc d’influencer de nouvelles méthodes de consommation dans le do-it-yourself et d’accélérer la façon dont on utilise le digital dans le retail. 

Dans ce contexte de migration vers le cloud d’une partie des applications, vous avez mis en place un projet d’observabilité du système d’information reposant sur la solution de Datadog.

L’observabilité, c’est très important pour nous. C’est ce qui nous permet de réagir très rapidement, ou de réduire notre temps de réaction face à un événement qui peut être critique, de type technique : une application qui tombe, un problème de réseau, etc. C’est donc avoir la capacité d’identifier très vite ce problème et disposer des bonnes informations pour le résoudre dans un temps très court, ou qui minimise l’impact pour le client. Il y a également une intention très forte de lier tout ce qu’on peut observer techniquement et de l’apporter aux métiers, de le vulgariser pour les métiers. Non pas pour avoir d’un côté, le métier qui utilise les métriques métiers et de l’autre, la technologie qui utilise les métriques technologiques, mais pour avoir un groupe qui corrèle tout cet écosystème de métriques pour le client. Que signifie un problème technique pour les métiers ? Principalement, un impact pour le client qui sera mécontent. Dès lors, comment passe-t-on d’un modèle réactif à un modèle anticipatif ? La mise en place de cette stratégie n’est pas uniquement l’affaire de la technologie, mais celle de tout le monde. Comment le métier va influencer l’utilisation de la technologie pour pouvoir anticiper et faire de la technologie pour le client? C’est l’amorçage des préceptes que l’on peut voir dans le product management. Sur l’observabilité, cela concerne la manière d’apporter les chiffres aux métiers pour que l’on ait un groupe qui fonctionne de façon centrale, comme une équipe. 

Quel est le périmètre applicatif concerné par les outils mis en place ?

Nous observons tout ce qui peut être observé. Les incidents le sont à partir de métriques brutes qui ont besoin d’être exploitées pour apporter de la valeur. Par exemple, le MTTR, mean time to recover, c’est-à-dire le temps moyen de réaction à partir d’un événement jusqu’à sa résolution. Typiquement, une métrique MTTR, cela parle uniquement à un technicien. Par contre, l’amener aux métiers, c’est ce qui fait sa réelle valeur. Nous monitorons tout ce qui peut l’être. C’est l’émergence du site reliability engineering, mouvement du SRE initié au départ par Google mais qui est l’évolution de la façon de faire des opérations, en lien avec les métiers. Globalement, nous monitorons les applications, les infrastructures, la qualité du réseau. On peut même parler de métriques business puisque, via le mouvement SRE, on va agréger des métriques qui expliquent ou décrivent quand une application est fonctionnelle, c’est-à-dire quand ses métriques technologiques, de performance ou d’impact client sont bonnes. Donc, nous ne mesurons pas uniquement un indice de santé applicatif mais également des indices de performances métiers au sein de Datadog et l’agrégation des deux fera que nous aurons vraiment un état de santé de la qualité de services proposée aux clients. C’est extrêmement important pour nous de suivre l’ensemble de la chaîne avec, au bout, la satisfaction client qui nécessite de réagir immédiatement s’il y a des temps d’attente, si une application est tombée, etc. 

Vous aviez déjà des outils d’observabilité avant d’adopter Datadog. Sur quels critères votre choix s’est-il opéré ?

Il y a plusieurs parties dans l’observabilité. Cela va de la collecte à la présentation, c’est-à-dire la façon d’exploiter ces données de façon visuelle. Nous avons déjà un partenariat stratégique avec Google sur le cloud qui nous permet de facilement récupérer des logs sur la partie stockage, avant exploitation. Nous stockons sur Big Query, du chaud et du froid. Le chaud, ce sont des logs avec une rétention particulière qui ont vocation à être exploités très rapidement et le froid, c’est ce que nous archivons, ce sont des logs qui ont perdu leur valeur intrinsèque instantanée, mais sur lesquels nous souhaitons une historisation. Sur ces deux façons d’exploiter les logs, on utilise différentes technologies. Et globalement ces logs sont transmis directement à Datadog pour une exploitation sur une semaine. Nous avons choisi cet outil pour exploiter facilement ce qu’on récupère de différentes sources et vulgariser. Datadog permet vraiment de travailler la datavisualisation. Nous avions besoin d’un outil extrêmement puissant pour sortir toute la valeur de nos logs et les apporter de façon différente. Nous en récupérons énormément. Les logs peuvent s’exploiter de différentes façons selon les personnes qui les utilisent. 

Les métiers vont souhaiter des métriques un peu orientées performances, des pourcentages qui agrègent d’autres métriques, des indices qui peuvent être exploités au premier coup d’œil. Les équipes opérationnelles vont utiliser ces informations pour faire évoluer la plateforme. Elles ont besoin de métriques plus précises, par exemple, un pourcentage de disponibilité ne va pas leur servir, elles vont plutôt parler de « budget d’erreur » qui est aussi une notion de SRE, travailler 

la marge d’erreur pour, soit prendre des risques ou tout simplement veiller à ce que la plateforme respecte notre promesse et le niveau de services. Datadog le permet. Ce qui est très appréciable, c’est qu’avec les mêmes métriques, on peut facilement agréger et déterminer des scénarios. Et on arrive facilement à corréler différents personas d’utilisation de l’outil.

Quelles sont les fonctionnalités Datadog que vous utilisez ?

Principalement, le Live Tail. Nous voyons passer les lignes de logs brutes en réalisant, au-dessus, une analyse multidimensionnelle où l’on choisit des filtres, par applicatif, par rapport à une zone - EMEA ou mondiale - ou un type d’environnement, que ce soit en préproduction ou en production. Il y a aussi des fonctionnalités sur la génération d’incidents, autour des Health Check, des tests synthétiques qui répondent à des seuils, qui vont solliciter les API d’état de santé des applicatifs. Nous utilisons aussi la capacité de s’intégrer à différentes sources de données, un point très important. Et nous prenons du temps pour tester les nouvelles fonctionnalités qui sortent régulièrement, voir comment on peut faire évoluer nos façons de faire, ce qui ne veut pas dire que nous allons tout utiliser. Ce qui est aussi appréciable chez Datadog, c’est qu’ils présentent de nouveaux usages.

Avez-vous déployé tout ce que vous aviez prévu dans le projet ?

Le scope initial portait sur notre chemin critique e-commerce qui est maintenant quasiment couvert. Nous avons des projets d’expansion. Je fais partie d’un groupe qui écoute énormément le collectif. Le choix de Datadog a été impulsé par mes équipes, mais son adoption est propre aux équipes qui vont l’utiliser. Et ça, c’est extrêmement important. Pour le pousser plus loin, j’apporte énormément d’attention à ce que ce produit soit utile pour les équipes, donc petit à petit, nous le testons auprès d’autres équipes. 

Pour que l’outil soit adopté largement ?

Oui. Nous ne sommes pas sur du top down, mais sur le respect du choix des technologies et des outils. Nous avons un plan d’expansion bien plus large qu’une seule plateforme e-commerce, sur d’autres plateformes, d’autres filiales et d’autres plaques mondiales. Aujourd’hui, le projet est opérationnel en France et testé dans d’autres pays. Nous venons tout juste de finir une migration très structurante et de passer notre site LeroyMerlin.fr entièrement dans le cloud. Bravo aux équipes. Cela nous a énormément aidé à préparer cette migration pour qu’elle soit sécurisée, pour avoir la vision nécessaire pour maîtriser entièrement le périmètre. Nous l’avons réussie avec quasiment aucun impact pour le client durant toute cette migration.

Quelles sont les difficultés que vous avez pu rencontrer dans la mise en place de l’outil ?

Parmi les points délicats, il y a l’aspect FinOps, c’est-à-dire la capacité à gérer la croissance financière de services qui sont sur étagère. C’est très facile de dépasser des projections de consommation, surtout dans les logs. Dans notre transformation cloud, la maîtrise de cette nouvelle discipline qu’est le FinOps est donc un enjeu majeur. Il s’agit de contrôler la consommation des ressources cloud.

Un contrôle financier ?

Ce n’est pas uniquement une question de finance, il s’agit aussi d’éco-responsabilité. Même si le serveur n’est pas à côté de nous - nous avons des datacenters en propre - et qu’il est ultra facile de consommer une ressource d’infrastructure chez notre cloud provider, on doit être sensible à l’impact écologique derrière. Ce n’est pas parce que c’est chez Google ou chez d’autres que le serveur n’a pas d’empreinte carbone, d’empreinte résiduelle. Il faut être sensibilisé sur l’impact de consommation d’une infrastructure. Le FinOps, c’est un peu la corrélation entre les deux. C’est la maîtrise de notre croissance d’un point de vue financier, avec une résultante écoresponsable. Dès que nous avons utilisé Datadog, nous avons pulvérisé nos seuils de consommation en envoyant tous les logs et puis nous avons compris. Nous sommes passés d’une solution historique propriétaire, gérée avec les stacks ELK (Elasticsearch, Logstash et Kibana) que nous maîtrisions et stockions chez nous, avec des coûts d’infrastructure noyés dans la masse. Alors qu’avec le business model de Datadog, nous payons à l’unité de consommation. Il y a différentes unités de consommation et l’on voit vite les coûts grimper. Nous avons bien été accompagnés sur ces aspects. Mais, au début, lorsque nous avons envoyé vers Datadog le même flux que nous recevions en interne sur nos technologies propriétaires, nous nous sommes rendu compte que ce n’était plus possible. Et c’est très bien, parce que cela nous a sensibilisés : est-ce nécessaire de tout logger, le niveau d’information envoyé est-il le bon, comment l’ajuster ?

Pouvez-vous donner un exemple ?

Par exemple, la rétention qui est le sujet majeur de tous les clouds providers qui fournissent une solution de logs, la rétention à chaud, donc le temps de stockage d’un log à chaud qui doit être exploité très rapidement, c’est ce qui coûte le plus cher en fait dans ces solutions-là. Nous avons regardé ce que ce que cela changerait de passer d’un palier à un autre, disons de 14 jours à 7 : quel impact sur les équipes et sur le coût. Et on s’est aperçu que pour nos réactions à chaud, notre travail, notre maturité actuelle, nous n’avions besoin par exemple que de 3 à 5 jours de logs. Parce que c’était la fenêtre qui nous permettait d’exploiter facilement et avec rétro-action des logs ou des événements qui nous parvenaient. Il n’y avait donc aucune utilité de le faire à 14. Donc en soi, c’est bien, parce que cela nous présensibilise à faire attention et à consommer uniquement ce qui est nécessaire. Je pense que quasiment toutes les entreprises qui se transforment dans le cloud doivent considérer cet aspect financier qui, forcément, a déraillé à un moment et qui redemande un peu de structure.

L’utilisation de ce type d’outils permet d’ajuster ses coûts ?

Oui, c’est justement l’une des nouvelles fonctionnalités qui apporte une vision un peu plus centrée sur la consommation, par exemple selon le provider. Cela permet de savoir si l’on a trop consommé ou pas. En fonction de l’utilisation du CPU, de la RAM, des indices de consommation d’un serveur, de savoir si on sursollicite ou pas. Si on le sous-sollicite, peut-être qu’on surconsomme. Donc, réduire soit la taille, la puissance si c’est une VM, peut-être réduire la résilience, le nombre d’instances déployées, ce genre de choses. Et c’est très utile. D’ailleurs, Datadog automesure lui-même sa consommation.

Quels sont les bénéfices constatés après la mise en place de ces outils ?

Il y en a beaucoup. L’un des plus importants, c’est de faire travailler des équipes ensemble. En fait, initialement, la façon dont on faisait de l’observabilité silotait la visibilité que l’on avait de notre patrimoine applicatif. Chaque équipe produit avait sa propre façon de faire. La valeur que l’on a, qui résulte aussi de l’ADN d’Adeo, c’est que l’on travaille ensemble. Donc, les informations d’une équipe intéressent les autres. Surtout si un produit est interdépendant. C’est extrêmement important de prôner cette transparence. Si un produit a des problèmes de qualité de service, on ne va pas partir dans le blâme. C’est au contraire extrêmement intéressant d’avoir cette information pour influencer l’engineering et travailler le côté fault tolerant du produit. Se dire que si cette dépendance travaille sa qualité de service, on peut avoir potentiellement des impacts sur notre promesse et qu’il faut donc renforcer cette partie. Ça a vraiment une implication intrinsèque sur la manière dont on utilise la technologie au sein des produits. Donc, vraiment, la vertu que l’on a trouvée porte sur la manière de faire de l’observabilité. Toutes les données atterrissent sur le même outil, chacun peut faire son propre dashboard et écouter les métriques de l’autre. Et pour nous, qui supervisons l’ensemble des plateformes, cela nous permet de faire des dashboards avec différentes granularités de vues, très simplement. Par exemple une vue high level de la plateforme, de sa disponibilité, une vue par domaines, une vue par produits, et tout le monde dispose d’une vue à 360 degrés de ce qui se passe et pas uniquement silotée par produits. 

Compte tenu de l’expérience acquise, quelles recommandations faire à des équipes souhaitant mettre en place une solution d’observabilité ?

L’observabilité, ce n’est pas uniquement une notion technologique, même si elle sert principalement la technologie. Il doit y avoir une vraie prise en compte de l’organisation globale, de tous les types de métiers, de leur rôle. Nous sommes en plein milieu d’une transformation digitale. Je pense que beaucoup d’entreprises le sont et cela demande une certaine maîtrise. Premièrement parce que ce qui peut se passer demain - on l’a appris avec la crise - peut être nouveau, et très disruptif. Il faut bien observer ce qu’on fait, bien se connaître et bien connaître notre capacité à faire. Quand on parle des métriques, ce n’est pas uniquement un état de santé, ça peut être le rythme de delivery, des métriques orientées agile, ce peut être n’importe quoi, mais il faut avoir, avec des chiffres, une vision très claire de ce qui se passe. Il faut aussi connaître l’impact de nos actions. C’est très important dans une période où les nouvelles générations travaillent principalement par le sens. S’il n’y a pas de sens, on perçoit vraiment un frein majeur, une démotivation, une perte de passion. Et l’observabilité, cela permet aussi d’apporter du sens. Nous sommes dans une phase de transformation digitale où l’on doit embarquer une équipe. La stratégie d’observabilité concerne donc tout le monde : le top management, le middle management, les développeurs, les products owners, le product management. Cela va aussi participer à la performance des personnes en magasin puisqu’on leur fournit également des outils. Il doit y avoir une sensibilisation, une prise en compte et surtout un pilotage. La deuxième chose, en parallèle, c’est de bien veiller à maîtriser la façon dont on observe. Encore une fois, il y a beaucoup de façons d’observer. On peut être très précis, très granulaire, et on peut être aussi très global. Il faut veiller à la consommation, ne pas trop logguer par rapport au niveau d’informations que l’on veut en retirer. Il est très facile de pulvériser un budget avec ce genre d’outils, comme avec tout outil dans le cloud.