Marc Sanselme 00:00:01 – 00:00:30 : Bonjour et bienvenue sur Data Driven 101. Je suis Marc Sansem, l’hôte de ce podcast qui s’intéresse aux applications concrètes et variées de l’intelligence artificielle et de la data. Dans Data Driven 101, je reçois chaque semaine des professionnels pour qu’ils nous parlent de leurs expériences et de leurs visions sans filtre. Aujourd’hui, je reçois Stéphane Estevez, consultant en observabilité de marché EMEA chez Splunk. Splunk est une entreprise américaine spécialisée dans l’analyse de données en temps réel, notamment à partir de données machines. Bonjour Stéphane. 

Stéphane Estevez 00:00:30 – 00:00:32 : Bonjour, merci de me recevoir. 

Marc Sanselme 00:00:33 – 00:00:39 : Avec grand plaisir. Alors, est-ce que tu peux nous redire avec tes mots ce que fait Splunk ? 

Stéphane Estevez 00:00:39 – 00:01:15 : Ça dépend, on a trois heures devant nous ou non ? Non, l’intro était la bonne. Splunk, à la base, c’est une plateforme de données. On récupère des données machines, des données techniques. On ne va pas faire du Word ou de l’Excel en tant que tel, mais c’est des logs, des métriques, des données de base de données, des choses comme ça. Et l’idée, c’est de pouvoir justement récupérer ces données qui existent un peu partout et de les sortir de leur silo, de pouvoir les corréler, de les reporter dessus, de faire de l’alerting, etc. Donc, on est né comme ça. Et après, on a évolué vers d’autres cas d’usage, vers la cybersécurité, l’observabilité et d’autres types de marchés comme ça. 

Marc Sanselme 00:01:15 – 00:01:19 : Le problème que vous résolvez, si on doit en choisir qu’un, c’est quoi ? 

Stéphane Estevez 00:01:19 – 00:02:10 : Parmi les 4 milliards de problèmes qu’on peut résoudre, je vais me concentrer uniquement sur ceux que je connais bien, qui est plutôt l’observabilité. Comme je disais, une plateforme de données, ça fait plein d’autres choses. Je dirais que le premier, c’est tout ce qui tourne autour de l’expérience utilisateur. La qualité de l’expérience utilisateur et tout ce qui tourne autour de la résilience digitale. Savoir quel niveau de performance je donne à mon acheteur si je suis en B2C ou B2B. ou même à un robot dans une usine, savoir si j’ai un ralentissement, une panne, de ce que ça vient, de l’infra, du code, du device de l’utilisateur, etc. Donc c’est un peu ça à la base, cette évolution du monitoring vers l’observabilité. Mais la finalité, je dirais, c’est essentiellement assurer cette résilience digitale, puisqu’aujourd’hui, je pense que toutes les entreprises dépendent de zéro et de un à un moment ou à un autre. 

Marc Sanselme 00:02:12 – 00:02:20 : Et alors, moi, il y a un angle qui m’intéresse particulièrement. Un de vos concurrents, c’est Datadog, on pourrait dire, notamment sur cette partie monétarienne. 

Stéphane Estevez 00:02:20 – 00:02:26 : Confrère, allez, on est sympa avec nos concurrents, nos confrères. 

Marc Sanselme 00:02:26 – 00:02:44 : Votre choix différenciant, c’est de se baser sur de l’open source, notamment open télémétrie, et de contribuer beaucoup sur open télémétrie ? C’est un choix assez original. Est-ce que tu peux nous en parler un peu plus ? 

Stéphane Estevez 00:02:44 – 00:03:11 : Datadog contribue aussi à Open Telemetry, comme nous et d’autres. Il faut bien savoir qu’Open Telemetry, c’est un projet communautaire, donc open source. L’idée, c’est de créer un agent unique. qui puisse collecter tous les types de données dont on a besoin à minima, justement pour comprendre un système et le rendre observable. Et on dit que généralement, les types de données minimum à avoir, c’est des logs, des métriques et des traces. Je ne sais pas si j’ai besoin d’expliquer tout ça à l’audience. 

Marc Sanselme 00:03:12 – 00:03:13 : Pourquoi pas ? 

Stéphane Estevez 00:03:13 – 00:06:14 : Rapidement, en fait, quand je veux troubleshooter ou savoir ce qui se passe, en gros, je vais regarder mes métriques. Mes métriques, c’est ces valeurs numériques qui me disent que ça tourne rouge. Le CPU est trop élevé ou le temps de la transaction est trop long, peu importe. Mais ça ne va pas me dire pourquoi. Ou alors, où est-ce que je dois chercher ? Pour aller savoir où chercher, on va aller collecter un autre type de data qu’on appelle des traces. Et en fait, c’est dans mon parcours dans l’application. J’ai cliqué ici, j’ai été là, je suis sorti de l’appli, viré une API, je suis allé ailleurs, etc. Tracé comme ça pour savoir à peu près où se trouve le problème. Donc, je sais que j’en ai un, je sais à peu près où, mais maintenant, j’ai besoin de comprendre pourquoi. Qu’est-ce qui est arrivé ? Là, c’est les logs. Donc, ces fameux fichiers qui sont générés par l’appli, l’infra, etc. Et qui enregistrent en fait tout ce qui se passe. Et jusqu’à maintenant, avant Open Telemetry, en fait, on avait des agents, soit des agents séparés. Il y en a un pour les logs que j’ai envoyés chez Splunk, par exemple, un pour les métriques que j’ai envoyées chez Datadog, parce qu’on les a nommés. Et puis les traces, on va continuer à nommer des concurrents, Verdina Trace, par exemple, etc. Et la problématique, c’est que déjà, ces agents étaient propriétaires. Donc déjà, je ne sais pas ce qu’ils font vraiment. Il récupère la donnée, il l’envoie, mais entre les deux, ben voilà. En plus, il ne se corrèle pas forcément entre eux. Or, moi, quand je suis en train d’investiguer, j’ai besoin de savoir, de naviguer entre ces logs et métriquer les traces pour prendre une bonne décision. Parce que, OK, me dire le CPU est trop élevé, mais ça veut dire quoi ? Est-ce que j’ai trop d’utilisateurs ? Ça, c’est chouette. Autant mettre la carte bleue et continuer à mettre du CPU. Et si ça venait d’une ligne de code qui était mal formée, qui prenait toutes mes ressources ? Ça, c’est beaucoup moins chouette, mais j’ai besoin de le savoir. Mais ça, c’est dans les traces. Donc, il fallait vraiment décloisonner ces datas-là et avoir un agent unique. Et c’est toute l’histoire d’Open Télémétrie. C’est de se dire, est-ce qu’on ne peut pas créer, la communauté ne va pas créer un agent de télémétrie qui sait tout collecter, qui est open source, donc je vois exactement ce qu’il est en train de faire. Ça, en plus, les équipes sécu, elles adorent, parce que du coup, je peux anonymiser les données avant même de les envoyer vers un Splunk ou vers un de nos confrères, etc. Ce qui a fait, nous, notre particularité, comme je le disais, il y a beaucoup de confrères qui supportent OpenTelemetry, qui savent récupérer des données d’OpenTelemetry. Oui. Lorsqu’on les pousse dans les retranchements, souvent, l’agent propriétaire revient un petit peu tranquillement s’installer en disant oui, mais pour ça, il faut l’agent propriétaire et on redevient, on se renferme dans un environnement propriétaire. Nous, on a fait le choix dès le départ de faire du 100% open télémétrie natif. C’est-à-dire qu’on ne va jamais demander à installer un autre agent. On a fait le pari et on se rend compte qu’avec le temps, le pari était payant parce que c’est en train de devenir le standard de facto du marché. On a même vu en France des grands industriels dans des produits dérivés de l’automobile pour aider à rouler les voitures, je n’ai pas le droit de dire le nom, mais on peut imaginer, qui ont fait le choix stratégique de faire 100% tout sur Open Telemetry. quel que soit vers qui vous allez l’envoyer. Parce que l’intérêt, c’est que si demain, je ne suis pas content de mon outil actuel et je veux renvoyer vers Splunk, j’ai déjà instrumenté tout mon environnement. Juste à rerouter. 

Marc Sanselme 00:06:14 – 00:06:15 : Voilà. 

Stéphane Estevez 00:06:15 – 00:06:22 : C’est une longue réponse, mais c’est un projet qui est tellement structurant et important. Et vraiment, la première étape de l’observabilité, ça mérite qu’on s’y attache. 

Marc Sanselme 00:06:24 – 00:06:59 : OK. Alors, tant qu’on parle d’open télémétrie, je change un peu de sujet immédiatement. Mais on parle pas mal d’IA de machine learning ici. Ce qu’on a besoin de faire dans du machine learning de l’IA, c’est se créer des datasets avec l’input, l’output, etc. Ça se fait à travers de la télémétrie notamment, mais ça ne rentre pas dans les cases log, métrique, trace. Et pourquoi pas ? Alors, comment ça rentre dans les cases ? 

Stéphane Estevez 00:06:59 – 00:09:26 : Pourquoi pas ? Parce qu’en fait, ça dépend. L’IA, ça veut tout et rien dire. Il y a plein de segments, etc. Il y a une partie de l’observabilité. Alors, avant, c’était séparé. Maintenant, les analyses commencent à le mélanger. Bon, après, moi, je trouve que ce n’est pas une bonne idée, mais c’est mon avis perso. c’est le AIOps donc tout ce qui est machine learning appliqué à l’IT en fait pour aider l’IT à être plus efficace. donc c’est tout ce qui va permettre de trouver des anomalies. parce que dans les stacks modernes les environnements modernes type microservices containers tout ça etc… Il y en a partout. Et aujourd’hui, les humains, on ne peut plus absorber ce volume de données. Et donc, trouver une anomalie quand j’ai 10 000 containers quelque part, c’est impossible. Donc, on a besoin de cette capacité à augmenter l’humain avec le machine learning. Donc, trouver des anomalies, détecter la route cause probable dans tout ce millier de datas. Tu sais quoi ? C’est là le problème. C’est directement cette ligne de code. Et donc, tu n’as pas besoin de réveiller à 3 heures du matin et le développeur et le DBA et le gars de l’infra, etc., Moi, je vais te donner la route cause probable et c’est cette personne qu’il va falloir réveiller pour régler le problème qui est en train d’impacter les métiers. Ça permet de faire des choses comme du prédictif. On peut prédire aujourd’hui des pannes avant qu’elles arrivent et avoir le temps. C’est comme si on avait des SLA négatifs. Moi, je vois des SLA où tout le monde dit en combien de temps je peux restaurer le service ? Non, je peux faire des SLA, c’est en combien de temps je peux éviter que ça arrive ? Bon, si tant est que l’incident est déjà passé dans le… On ne lit pas l’avenir, mais on lit le passé et on analyse les signaux faibles. Et en fait, toute la notion d’observabilité, ces logs, métriques, traces, events, tout ça, c’est là où on va aller puiser ces signaux faibles et alimenter aussi les algorithmes d’AI Ops. Après… Ça, nous, on le fournit en standard. Enfin, on consomme le machine learning. L’anomalie detection est déjà là, etc. Je crois que l’audience qui nous écoute, il y a quand même beaucoup de data scientists, par exemple. Il ne faut pas oublier que Splunk, à la base, c’est une plateforme de data. Et on fournit des outils justement pour les data scientists pour simplifier le travail de j’onboard la data, je prépare, je nettoie, etc. On fournit déjà plein d’algos, mais ils peuvent venir avec leurs propres algos. On a eu tout le kit pour le machine learning, pour le deep learning. Et on a des clients comme Porsche, par exemple. Ils ont des data scientists et ils ramènent leurs algos métiers, mais ils les font jouer et les entraînent sur les données générées par Splunk, normalisées par Splunk, simplifiées par Splunk. 

Marc Sanselme 00:09:27 – 00:10:13 : Pour le usage précis de la collecte de données input-output pour un entraînement, un réentraînement futur, je mets en place un use case de machine learning pour la première fois. J’ai des données statiques, j’ai entraîné mes algos dessus. Je log, je mets des traces, j’ai des métriques. Mais comment est-ce que je récupère juste une liste des input-output à travers tous les usages de mon algo, à travers les jours qui passent et les semaines ? Comment est-ce que je peux constituer un dataset sur la base de ce qui s’est passé de la donnée d’usage avec Open Télémétrie ? Est-ce que ça rentre dans ces cases-là ou est-ce que c’est un autre type de télémétrie ? 

Stéphane Estevez 00:10:13 – 00:10:41 : Après, en tout cas, nous, sur la partie qui nous intéresse, qui est vraiment la partie DevOps, DevOps et IT, Open Télémétrie, c’est juste, entre guillemets, c’est juste, mais c’est quand même un projet important, c’est juste la manière de collecter la donnée et l’ingérer dans la plateforme. Et après, c’est dans la plateforme où on va avoir la capacité, justement, à entraîner les algos, ramener ses propres algos, etc. Et les tuner en fonction des besoins, voir les… 

Marc Sanselme 00:10:41 – 00:10:43 : Oui, donc c’est plus qu’est-ce que je vais en faire après. 

Stéphane Estevez 00:10:43 – 00:10:44 : Qu’est-ce que je vais en faire après ? 

Marc Sanselme 00:10:44 – 00:10:54 : On le récupère avec, par exemple, des logs, et après, la responsabilité du back-end, c’est de la sauvegarder dans une database qui va nous créer ce dataset. 

Stéphane Estevez 00:10:54 – 00:12:58 : Après, tout ça, c’est une data platform, donc les données, elles sont dans Splunk. Je peux les exporter si je veux, mais elles sont dans Splunk, parce que l’intérêt après, c’est justement de faire jouer les algos directement dessus, etc. Mais on a, par exemple… pour les clients qui ont envie d’aller un petit peu plus loin. si je prends l’exemple je vais essayer de trouver un exemple un peu intéressant. on a des algos par exemple qui permettent d’analyser sur le passé tous les incidents que j’ai eu et d’analyser les seuils en fait pour comprendre le comportement habituel d’une application. Pour donner un exemple, si je suis une boîte de trading, il est 9h du matin, les marchés ouvrent, on est lundi, c’est normal que mes ressources soient très consommées, par exemple. Dans une optique de monitoring, on va dire, souvent j’ai des seuils statiques et souvent ça passe en rouge. Or, on sait tous que c’est un vaut positif. Que va faire l’admin ? Il va baisser le seuil. Il va baisser le seuil. Je désensibilise. De coup, ce n’est pas la meilleure idée du monde. Moi, ce qui m’intéresse, c’est que l’algo, en fait, détecte que c’est lundi matin, que ce n’est pas le jour de Noël, que les marchés sont ouverts et que tous les lundis matins dans le passé, j’ai déjà eu ce comportement-là et de ne pas générer une alerte. C’est l’algo qui va déterminer si je génère une alerte ou pas. Mais ça marche aussi dans l’autre sens. C’est-à-dire que le lundi suivant, je suis à 5% d’utilisation de mes ressources. Le marché est ouvert. Ce n’est pas normal. Il y a un truc qui ne va pas. Or, pareil, si j’ai un seuil statique, je suis sous les radars, alors clairement, il y a un problème. Là, l’algo, c’est lui qui va déterminer, je génère une alerte quand même. Mais quand on met en place ce genre de choses, on a les possibilités avec Splunk de mettre des garde-fous, de faire des tests et de dire, voilà, si j’active ce seuil-là, ça va donner quoi comme nombre d’alertes ? Est-ce que j’ai la capacité après de les traiter ? Est-ce que j’ai suffisamment dans mes équipes de people pour gérer ça ou pas ? Pour ne pas me tirer une balle dans le pied ? Donc l’idée, c’est d’avoir l’outil, il s’entraîne sur les données, il devient plus pertinent, il crée ses fameux seuils, mais il y a toujours de l’humain quelque part pour s’assurer que ça ne va pas me péter à la figure, pour parler clairement, et de me tirer cette fameuse balle dans le pied. 

Marc Sanselme 00:12:59 – 00:13:20 : Alors là, on est dans des cas un peu concrets. Alors justement, pour bien qu’on comprenne, c’est quoi l’essentiel des données, on va dire les données les plus courantes sur lesquelles vous vous basez, les sources de données sur lesquelles… On peut construire, exploiter, faire du signal. 

Stéphane Estevez 00:13:20 – 00:17:25 : Il y a deux cas de figure. Sur le cas de la figure de la plateforme pure, là, il y a de tout. Il y a évidemment Logmetric Events, comme on l’a déjà dit. Ça peut être des données GPS, du RFID, de l’IoT avec du SCADA, des API. C’est vraiment… Là, on a de la base de données. On peut mettre… de tout dans Splunk, on va dire. À partir du moment, encore une fois, c’est de la donnée machine. Donc, c’est ultra large. Quand on parle d’observabilité pure, souvent, en fait, on s’adresse encore une fois aux personnes du dev, de l’ITOps et de la sécurité. Et là, on reste essentiellement focalisé sur les logs, les métriques et les traces et les events. Mais encore une fois, là, le challenge, c’est surtout de tout mettre sur une seule plateforme plutôt que d’avoir des outils séparés. Parce que, encore une fois, on est là pour s’assurer de la qualité de service à l’utilisateur final. Or, moi je viens du monde de la prod, donc j’ai passé 20 ans dans les data centers, dans les cloud providers et autres, et ça m’est déjà arrivé en tant que product manager et owner d’être appelé, comme les autres, à 4h du mat’. Parce que là, les SLA, il fallait payer des pénalités. Et de me rendre compte qu’autour de la table, chacun regardait son petit écran et puis personne n’avait la solution. Tout le monde se renvoyait la balle. On appelle ça le syndrome de la pastèque. Je ne sais pas si tu l’as déjà entendu. Tout le monde regarde sa pastèque, elle est verte. Et puis jusqu’au moment où on commence à les ouvrir, on se rend compte qu’elle est rouge à l’intérieur. Et c’est un peu ça. Nous, notre rôle, c’est justement de faire en sorte que tout le monde puisse avoir accès à toutes les données dans le bon contexte. Et souvent, ce qui fait sourire un peu les gens avec qui je discute, c’est qu‘on a créé un nouveau KPI. Ce n’est pas une bonne idée de le faire, mais moi, j’appelle ça le « meantime to innocence ». C’est-à-dire que maintenant, je sais en combien de temps je peux prouver que ça ne vient pas de chez moi, que ça vient du copain. Si je suis développeur, c’est de prouver que tu ne m’as pas mal configuré mon infra, ou le gars de l’infra, de dire « je suis désolé, mais c’est ta ligne de code, etc. » ou c’est quelqu’un du réseau, parce que c’est toujours la faute du réseau, de toute façon. mais c’est un peu ça l’idée. donc dans l’observabilité on n’a pas besoin de beaucoup plus. là où le bas blesse et ça souvent les éditeurs de software n’en parlent pas c’est bien de collecter les logimétriques et les traces mais il faut les collecter aussi à la bonne cadence Et puis au bon coût, parce que ça coûte de l’argent de récupérer des données aussi. Donc il faut avoir aussi le bon positionnement en termes de prix pour pas que ça coûte plus cher que ça génère de valeur. Et l’exemple classique, de plus en plus, les nouvelles applis dans les métiers, c’est du microservice sur du container ou du serverless. C’est des infrastructures qui sont ultra éphémères. Elles vivent et elles meurent en quelques millisecondes. Et aujourd’hui, moi, le premier warning que je donnerais aux gens, c’est de jamais faire confiance à la terminologie. Moi inclus, il ne faut pas me faire confiance. C’est-à-dire que quand je parle d’observabilité, j’ai une vision de l’observabilité qui ne sera pas forcément la même que celle de mes clients ou celle de mes confrères. Vous allez sur tous les sites web de tous les acteurs de l’observabilité, tout le monde va vous raconter, on réduit le mean time to repair, on fait du bout en bout, on fait du temps réel. C’est quoi du temps réel ? Le problème, c’est ça, c’est faire du temps réel toutes les minutes, je suis désolé, mais autant faire tous les 4 ans. Parce qu’avec des environnements si éphémères dans le cloud, si vous collectez les données, ne serait-ce que même toutes les 10 secondes, vous êtes déjà trop lent. Parce qu’en 9 secondes de non-observabilité, donc en 9 secondes si je ne récupère pas mes métriques et mes traces, etc., ces technos là il s’est déjà passé plein de trucs. j’ai déjà eu un plantage j’ai perdu des clients j’ai été impacté sur le chiffre d’affaires. le système s’est relancé automatiquement parce qu’il est ultra performant et lors de au bout de 10 secondes quand je repose la question est-ce que tu vas bien? il va me dire bah oui je vais bien. donc moi je suis tranquille je prends mon café Sans savoir que j’ai eu un mémorolique, enfin j’ai eu un problème technique, que j’ai impacté mon business et mes outils sont verts. J’ai une belle pastèque. Et donc aujourd’hui, la problématique, c’est qu’il faut vraiment creuser et pas faire confiance à l’intermédiaire et aller dans le détail. Parce que comme c’est un marché qui est un peu nouveau, il y a beaucoup d’observative washing, comme disent les anglophones. Il y a un peu trop de marketing parfois. 

Marc Sanselme 00:17:26 – 00:17:57 : Ok, hyper intéressant. Alors sur l’aspect très IT, très tech, on voit très bien cet enjeu de service level agreement et compagnie qui ont les traces, les logs, les métriques. Mais est-ce que tu peux nous parler un petit peu des décisions business qu’on peut prendre grâce à ce niveau d’information, des exemples, par exemple, de clients, d’un point de vue vraiment non tech, décision business. 

Stéphane Estevez 00:17:57 – 00:20:48 : Moi, j’en ai un que j’adore, qui est vieux, parce que c’est un client qu’on a depuis pas mal d’années, mais que j’utilise souvent parce que ça part dans tous les sens. C’est ça qui est génial. Très créatif, c’est l’aéroport de Dubaï. qui est un des principaux aéroports en termes de trafic. Il faut savoir que le métier de l’aéroport, c’est l’expérience passager et le duty free au passage et les taxes d’aéroport et ainsi de suite. Donc, tout le métier est là. Et en fait, ils se sont assez rendus compte que pour être dans les très bons classements des meilleurs aéroports, il y a un certain nombre de critères, dont par exemple le Wi-Fi et la propreté. Donc, ils ont commencé à utiliser Splunk pour voir est-ce que le Wi-Fi fonctionne bien parce qu’ils ont à peu près, à l’époque déjà, je parle de ça il y a quelques années, plus de 20 000 connexions simultanées. Donc maintenant, ils en ont certainement beaucoup plus. Et puis, ils se sont dit « Ok, je prends Splunk, comme ça, je récupère toutes mes données et des équipements physiques et du réseau et de ceci, je corrèle et puis je vois si tout va bien. ». du Wi-Fi, je peux peut-être la réutiliser pour d’autres choses. Et ils se sont rendus compte, je ne sais pas si tu le sais, mais ton téléphone, quand il se connecte à un réseau, même si tu n’es pas connecté au Wi-Fi, il dialogue avec le Wi-Fi. Il n’y a pas de données personnelles, mais on a une MAC adresse. Ils se sont rendus compte qu’ils pouvaient aussi créer un heatmap de où se trouvaient physiquement le plus de passagers. Comme ça, en cas d’incendie ou de problème, les équipes de sécurité, mais du genre sécurité, genre pompiers, etc., savaient qu’il fallait aller plutôt au troisième étage avec les mêmes données du Wi-Fi qui servaient à l’équipe réseau. Il n’y a rien d’autre. La donnée a été ingérée une fois. C’est juste qu’on lui pose d’autres questions avec Splunk. On crée un autre dashboard. Et puis finalement, ils se sont dit « Maintenant que je sais où sont les gens, peut-être pouvoir optimiser un petit peu la clim, parce qu’il fait chaud à Dubaï. Je ne peux pas donner le chiffre, mais c’est un niveau d’économie énorme au niveau de consommation électrique, parce qu’ils optimisaient les températures, etc., en fonction de là où se trouvent les gens. On se rend compte qu’une simple donnée, aussi presque basique, je dirais, que le Wi-Fi, peut être déclinée à l’infini. Donc, si on fait ça, pas pour le Wi-Fi, mais pour tous les autres types de data, en fait, le nombre de cas d’usage sur Splunk est absolument illimité. Et pour en venir, parce que je sais que tu aimes bien parler beaucoup d’AI, etc., et de machine learning, par exemple, l’autre cas, ils se sont rendus compte, pour être bien classé, c’est la propreté. Du coup, ils se sont dit, moi, je peux récupérer les données des sensors. On a des capteurs dans les toilettes. Donc, le nombre de fois où j’ouvre la porte, où je me lave les mains, maintenant, c’est automatisé. On passe les mains devant. Tout ça, ça génère des logs, etc. Maintenant, c’est les algorithmes C’est le machine learning qui dit à quel moment l’équipe de nettoyage doit aller nettoyer les toilettes, en prenant en compte les capteurs, etc. Mais aussi en corrélant avec des données d’avions, en disant « Ah, là, c’est un avion qui vient du Japon. 

Marc Sanselme 00:20:48 – 00:20:48 : ». 

Stéphane Estevez 00:20:48 – 00:21:32 : Ils se sont rendus compte que les Japonais étaient les plus exigeants en termes de propreté. Et donc, ils corrélaient un certain nombre de sources comme ça pour s’assurer que quand un avion, par exemple, japonais, arrivait, tout était cliné avant, quoi qu’il arrive. Et c’est comme ça qu’ils ont amélioré vraiment l’expérience utilisateur au maximum, au point que le CEO, donc là c’était pas l’IT, c’est le CEO qui conclut, on a une vidéo en ligne je crois sur YouTube, elle est disponible, sans ajouter aucune piste d’atterrissage, il allait augmenter son business de 30% rien qu’en tapant dans la donnée. dans les données qu’ils avaient sauf qu’ils ne savaient pas qu’ils pouvaient extraire de la valeur du capteur dans les toilettes ils appellent ça les golden bathroom. on peut en parler pendant des heures. c’est limité. 

Marc Sanselme 00:21:32 – 00:21:41 : l’aéroport, les capteurs dans tous les sens et finalement la présence des personnes qui est traduite par les données wifi quoi? 

Stéphane Estevez 00:21:42 – 00:22:01 : Aujourd’hui, tout génère de la data. Et le problème, c’est que ces données, justement, elles sont partout. Elles ont des formats différents. Elles sont difficiles à collecter. Elles sont difficiles à corréler. C’est difficile de dashboarder. Mais c’est l’intérêt d’une plateforme de data. C’est tout l’intérêt, justement, d’avoir une solution comme Slug. C’est de pouvoir en tirer quelque chose et de générer de la valeur. Mais quand je dis de la valeur, c’est que ça va jusqu’à plus de 30% de chiffre d’affaires. 

Marc Sanselme 00:22:01 – 00:22:10 : Alors, du coup, la donnée de Wi-Fi, on comprend bien la puissance que ça a. Peut-être d’autres exemples de sources de données aussi puissantes comme ça. 

Stéphane Estevez 00:22:12 – 00:23:16 : On a des fabricants automobiles, par exemple, qui récupèrent des données pour savoir où est-ce qu’ils mettent les… Alors là, on sort de mon environnement naturel qui est l’observabilité pure, qui est disponible applicative et infra et tout ça. Mais on a des constructeurs automobiles qui, par exemple, travaillent sur où est-ce que je vais mettre les bandes de chargement de mon véhicule. Et ça, c’est des corrélations de données qui viennent de où sont les clients, où est-ce que ça a été vendu, où est-ce que les gens habitent, s’ils ont voulu accepter de partager les datas, etc. Et de faire plein de corrélations différentes pour optimiser. Et là, c’est leur data scientist, pour le coup, qui utilise la plateforme et qui a travaillé les algos. Donc, on a des algos standards, mais ils ramènent aussi leurs propres algos. Et c’est la plateforme qui leur dit, voilà, ça, c’est à tel endroit, dans telle rue. Donc là, c’est corrélé de l’info GPS, avec des infos de vente qui peuvent peut-être venir de Salesforce. C’est vraiment des sources ultra hétérogènes. Sur tous les secteurs d’activité aujourd’hui, la data, c’est générique. On est présent dans tous les secteurs d’activité. 

Marc Sanselme 00:23:19 – 00:23:24 : L’IA générative a changé beaucoup de choses pour beaucoup de gens. Pour vous, ça a changé quoi ? 

Stéphane Estevez 00:23:24 – 00:24:46 : Pas grand-chose. Moi, personnellement, oui, parce que j’utilise pas mal. Non, non, plus sérieusement, enfin, oui et non, parce qu’on fait de l’AI génératif, donc on a des AI assistants. Donc, aujourd’hui, on peut parler en langage naturel avec la suite observatrice Splunk. Ils disent, raconte-moi ce qui se passe. Dis-moi, voilà. Donc, au lieu de chercher entre les log métriques et les log métriques, il va dire, ben voilà, j’ai repéré que tel problème dans le cloud a fait que tel, dans tel container a fait que tel machin, etc. a impacté tel utilisateur. En langage naturel. Donc ça, on fait ? Parce que de toute façon, on se doit de le faire, entre guillemets, mais on s’adresse quand même à des experts. Mais c’est très pratique, par exemple, quand on a des gens qui sont moins familiers avec les outils pour pouvoir juste dialoguer sans forcément comprendre, même si on a fait en sorte quand même que les outils soient assez intuitifs pour faire du troubleshooting. Après, on aide aussi les clients qui, eux, ont fait le choix d’utiliser des LLM, par exemple, pour rendre ces LLM observables. Est-ce qu’ils sont sécurisés ? Est-ce qu’ils sont disponibles ? Est-ce qu’ils ont le niveau de performance nécessaire ? Est-ce qu’ils font des choses qu’ils ne devraient pas faire ? Et là, on fait de l’observabilité pour les LLM de nos clients. Donc, on en a, nous, les nôtres, qu’on fournit à nos clients pour qu’ils puissent dialoguer avec Splunk, mais on aide aussi à appliquer ce qu’on sait faire en sécurité et en observabilité pour les LLM de nos clients qu’ils utilisent pour leurs propres besoins. 

Marc Sanselme 00:24:47 – 00:25:00 : Ok. Et la suite Splunk, est-ce qu’elle envisage, ou ce que c’est fait, de créer, on va dire, un volet observabilité pour LLM ? 

Stéphane Estevez 00:25:00 – 00:25:07 : C’est le cas, en fait. Alors, j’ai peut-être mal expliqué. Effectivement, c’est le deuxième cas de figure. Enfin, si j’ai bien compris la question, c’est le deuxième cas de figure. 

Marc Sanselme 00:25:07 – 00:25:11 : Avec des traces spécifiques au LLM où on peut observer… 

Stéphane Estevez 00:25:12 – 00:27:25 : Le LLM, c’est plus dans le dialogue. C’est-à-dire, si je reprends le premier exemple, c’est de dire, voilà, moi, j’ai un outil d’observativité comme Splunk, par exemple, où je récupère toutes mes données et je veux savoir qu’est-ce qui ne va pas ? Pourquoi j’ai une dégradation ? Pourquoi j’ai une perte de revenu ? Pourquoi j’ai une dégradation de performance ? Et à quel endroit je dois regarder ? Est-ce que c’est mon cloud ? Est-ce que c’est l’appli ? On peut aller jusqu’au… C’est le laptop de l’utilisateur. On a des cas, j’ai quelques anecdotes assez étonnantes là-dessus. Et donc, on a une interface graphique où tu vas pouvoir consommer ces données. Et voilà, cliquer en disant, tiens, là, j’ai une trace d’un utilisateur qui a un problème. Je clique. Ah, ça ne vient pas du code. Je regarde. Ça vient du code. Pardon, ça ne vient pas du code. Je clique. Hop, ça vient de l’infra. Et ça vient de telle machine ou de tel endroit dans l’Internet, dans le réseau, peu importe. Voilà. Mais si je n’ai pas envie de faire tout ce schéma-là en quelques clics, je peux aussi lui dire, OK, j’ai une alerte. dégradation sur tel utilisateur. Manque de bol, c’était mon PDG, par exemple. Donc là, tout le monde est en train de s’exciter. Eh bien, je vais lui poser la question. Donc, on a un autre élème derrière. Il va lui dire, Splunk, observabilité, raconte-moi ce qui s’est passé pour tel incident. Et Splunk va aller à la place et dire, ben voilà, j’ai regardé telle trace et il semblerait… En fait, il va faire tout ce travail-là. que va faire l’humain pour l’aider à aller plus vite à la réponse. Comme beaucoup, on consomme et on fournit entre guillemets de l’LLM, mais c’est plus l’interface entre Splunk et l’utilisateur final. Après, on a des clients qui utilisent l’LLM pour d’autres besoins chez eux, pour leurs propres besoins. Et là, on considère l’LLM comme un environnement informatique, on va dire. Donc, c’est les agos qui tournent sur des machines avec du code, du Python, du je ne sais pas quoi dessus. on va le rendre observable. C’est-à-dire qu’on va le monitorer, si on utilise l’ancien terme, on va dire, pour faire en sorte que ce chat GPT que tu utilises, qu’est-ce qu’il fait ? Est-ce qu’il tourne bien ? Est-ce qu’il se connecte là où il devrait ou il ne se connecte pas ? C’est un autre cas d’usage un peu différent. Après, on fait les deux. Je ne sais pas si j’ai bien compris ou répondu à ta question. 

Marc Sanselme 00:27:25 – 00:27:28 : Tout à fait. Tu avais une anecdote en tête ? 

Stéphane Estevez 00:27:28 – 00:28:31 : Ah oui, l’anecdote, c’est qu’en fait, quand je dis qu’il y a quand même des gens un peu particuliers, on a un client qui est dans le voyage et qui ne comprenait pas pourquoi quelqu’un n’arrêtait pas de se plaindre sur les réseaux sociaux, etc. Donc là, on est en train de parler à l’époque de Twitter. Donc quand je disais que Splunk peut récupérer des données de partout, c’est qu’on peut récupérer aussi des données de Twitter, par exemple, et dire pourquoi ça ne marchait pas. Et après, quand on a aidé le client à investiguer, c’est parce que la personne se plaignait de la lenteur du site web, parce qu’il était en train d’acheter des billets d’avion à partir de son interface de la PlayStation 5. Je ne sais pas qui a l’idée de prendre la manette de la PlayStation pour taper une URL et acheter un billet d’avion, honnêtement, sur un navigateur avec une PlayStation. Mais du coup, on le sait. Donc, on peut aller répondre à cette personne. Je suis vraiment désolé que ça n’aille pas si vite, mais c’est comme si tu te connectais avec ton BlackBerry de nos jours. On a optimisé notre site pour iOS, Android, un ordinateur. Donc, c’est vrai qu’on n’a pas pensé à la PlayStation pour acheter des billets d’avion. 

Marc Sanselme 00:28:31 – 00:28:47 : Donc, c’est vraiment ce que tu disais tout à l’heure le time to innocence. combien de temps est-ce que je mets à te montrer que le responsable c’est toi parce que tu te connectes avec une playstation mais pour trouver cette info déjà pour savoir qu’il y a eu ce problème? 

Stéphane Estevez 00:28:48 – 00:29:23 : parce que c’est une trace parmi des centaines de milliers par jour, peut-être. Donc, c’est un utilisateur. Mais il faut déjà la détecter. On l’a détecté parce qu’il monitorait aussi son Twitter en fonction de certains mots-clés, où les gens se plaignent, etc. Et de pouvoir ensuite corréler plein, plein, plein d’éléments pour arriver à trouver, c’est ce qui s’est passé, c’est à cause de ça. Et de pouvoir répondre, parce que ça reste quand même un client… pouvoir lui répondre et lui apporter une solution. parce que le business, moi, de ce client, c’est de vendre des billets d’avion et il a envie que ce client revienne, qu’il rachète des billets d’avion. Mais peut-être pas avec l’APS. 

Marc Sanselme 00:29:23 – 00:29:43 : Mais ça doit être un… Tu dis ça presque comme une blague, mais ça doit être un vecteur de vente colossal, ce time to innocence, quoi. De montrer que c’est pas de chez nous que vient le problème, ça veut dire mettre moins de ressources sur des questions qui viennent du client et qui nous font… 

Stéphane Estevez 00:29:44 – 00:32:55 : alors ça marche tout le temps ça c’est clair parce que tout le monde sourit tout le monde fait comme ça de la tête oui un petit signe de oui en disant bah oui ça nous arrive tout le temps. honnêtement j’ai peut-être démarré dans la prod il y a maintenant plus de 20 ans en comptant toutes les expériences et j’ai l’impression que ça n’a pas changé encore. On est toujours dans la même situation, on a toujours des cycles de crise, on se fait toujours rappeler la nuit et puis on se pointe toujours du doigt. Mais aujourd’hui, ce qui motive les gens à passer à de l’observabilité, c’est déjà qu’ils ont pris conscience que le monde a changé. C’est-à-dire qu’on change la manière de coder les applis. Donc avant, on faisait des gros monolithes, on faisait une version par an. Maintenant, on fait des microservices et on fait une mise à jour toutes les cinq minutes. On a changé la manière de fournir de la capacité de calcul. On n’a plus les bons vieux serveurs rackés. Maintenant, on a des containers, des trucs dans le cloud, on-prem, machin, etc. Et puis, on en balance dans le cloud. Donc, en fait, on n’est plus propriétaire du matériel dans le cloud. Donc, on perd vachement de visibilité sur les données. Donc, il faut trouver un autre moyen d’avoir cette information-là. Parce qu’on reste propriétaire du contrat. Donc, le client final, lui, il s’en fout de savoir si vous êtes chez tel ou tel cloud. Ce n’est pas son problème. Donc, je dirais, le besoin, il est là. Le besoin, je dirais, de… de résilience digitale est là. Nous, on a même fait une étude l’année dernière qui est encore super valide, qui s’appelle le cost of downtime. Combien ça vous coûte d’argent de ne pas être disponible ou d’être lent ? Je suis désolé, j’utilise beaucoup de mots anglais, mais ils disent « slow is the new down ». C’est-à-dire qu’aujourd’hui, Être lent, c’est comme une interruption de service. En fait, c’est à peu près le même impact sur le business, tellement les gens ont une attente en termes de performance, etc. On voit que dans cette étude, par exemple, les différents centres de coûts, ce n’était pas juste la perte de chiffre d’affaires. Mais ça va être aussi le marketing, par exemple, qui ont un gros budget, qui s’allouent pour aller chercher des nouveaux clients. Quand on a un grand plantage, parce qu’on dépend d’un site web, si on est dans le B2C, qu’on a un gros site web… etc. Ce budget-là, je vais devoir le réallouer pour réétablir la confiance, recréer la confiance sur la marque, etc. Donc, ça va m’impacter mon business aussi. Après, s’il y a eu un problème en même temps qui est lié à la sécurité, je vais payer des amendes pour certains cas ou je vais payer des premiums sur mes assurances digitales auprès des assurances. En fait, on se rend compte qu’il y a des coûts cachés partout, dans tous les sens. Donc, aujourd’hui, on dépend trop, entre guillemets, mais c’est bien. Mais ça demande une certaine responsabilité du digital. Et si on n’est pas capable de rendre ces systèmes observables et de les sécuriser, c’est tout notre business qui est à risque. Après, c’est toujours compliqué parce qu’on s’adresse quand même à des ingénieurs, souvent. Et on aide de plus en plus à aller vers le CTO, le CIO, voire le CEO, comme l’exemple de l’aéroport de Dubaï. Donc, on les aide de plus en plus à se reconnecter au métier. Et montrer qu’un plantage technique, c’est directement lié au business. finalement. Et comme toujours, quand on touche au portefeuille, on a un peu plus d’écoute. 

Marc Sanselme 00:32:57 – 00:33:01 : Quels sont les obstacles humains à l’utilisation de votre travail ? 

Stéphane Estevez 00:33:01 – 00:33:35 : Alors moi, je suis fan d’un peu de psycho de comptoirs. Et pour moi, c’est souvent les biais cognitifs. C’est-à-dire, je prends des exemples. En fait, les gens ne se rendent pas compte… qu’ils ont besoin des données, parce qu’ils disent « ça y est, moi j’ai l’habitude, j’ai toujours fait comme ça, le biais d’ancrage par exemple. ». Ou un autre que j’utilise souvent pour expliquer l’observabilité, c’est le biais du survivant. Je ne sais pas s’il te parle, le biais du survivant ? Oui, oui. 

Marc Sanselme 00:33:35 – 00:33:37 : C’est rare, bravo ! 

Stéphane Estevez 00:33:37 – 00:36:38 : Il y a peu de gens… En fait, c’est typiquement… Pour l’expliquer, je prends souvent l’analogie… En ce moment, ce n’est peut-être pas la meilleure idée, mais pendant une guerre, dans le passé, les ingénieurs essayaient d’améliorer les avions. Ils regardaient les avions qui rentraient de campagne, ils regardaient où étaient les impacts, ils disaient « Là, je vais renforcer le blindage. ». Ça a l’air logique. En plus, c’est des ingénieurs, des gens qui ont fait des études. Sauf que c’est faux. C’est une erreur. Là, on est en train de faire un vieil du survivant. Et c’est un statisticien qui l’aura expliqué. Il s’appelait Abraham Wall, d’ailleurs. Il leur a dit, mais là, vous regardez uniquement les avions qui sont rentrés de campagne. Moi, ce qui m’intéresse, c’est ceux qui, malheureusement, ne sont pas rentrés. Et à mon avis, s’ils ne sont pas rentrés, c’est qu’ils ont été impactés là où il y a le moins d’impact. Et c’est les fameux inconnus, inconnus, qui est beaucoup utilisé dans le monde militaire, etc. Mais pas que. Et ça, c’est un biais classique. En fait, on est constamment en train de changer de technologie. Mais en fait, on aborde l’observabilité et le monitoring de l’ancienne manière. Donc, si maintenant j’utilise des containers, je ne les moniteur pas comme une machine virtuelle. Si maintenant je fais un microservice, je ne fais pas du tracing pour comprendre le parcours utilisateur comme je le faisais sur un monolithe, etc. Sauf que comme c’est des inconnus et inconnus, je ne sais pas ce dont j’ai besoin. Et ça, pour moi, c’est plus cette démarche intellectuelle à avoir, d’arriver à… On ne peut pas les enlever, les biais cognitifs. On vit avec tous les jours. Mais déjà, de les réduire un petit peu en se disant, mais en quoi la donnée va me permettre de sortir de ça et de sortir du lot, finalement ? Parce qu’il y a une étude, je crois que c’était BCG qui avait fait ça, que je trouve très intéressante. C’est, en fait, en période de crise… ils ont regardé sur une très longue période la performance des entreprises pendant une situation de crise et pendant quand tout allait bien, le ciel est bleu. Et ils se sont rendus compte, et j’avais en tête notamment Berkshire Hathaway, qui est la boîte de Warren Buffett, qui est beaucoup dans les assurances, et ils ont regardé sur 25 ans. Et en fait, Berkshire Hathaway, en période de crise, il surperformait par rapport à ses concurrents. Et quand tout allait bien, ils sous-performaient. Sauf qu’il y a moins de crises que de jours de ciel bleu. Mine de rien, sur 25 ans, quand ils faisaient la moyenne, le fait d’être très bons en période de crise, c’est-à-dire de revenir à un état normal plus rapidement, de restaurer le service plus rapidement, etc. En fait, ils surperformaient de deux points tous leurs concurrents. Sur la durée. Et c’est ça qu’on essaie aussi d’expliquer aux gens, c’est qu’être très bon dans la gestion des problèmes, sur le long terme, c’est pas juste revenir à un état zéro. C’est qu’on va gagner des parts de marché, qu’on va devenir meilleur que ses concurrents. Mais ça, c’est sur le long terme. Après, le problème, c’est que les gens souvent réagissent un peu à court terme. Mais je trouvais cette approche un peu stimulante de dire parce que les crises, personne n’a envie de les gérer. Sauf que si vous êtes vraiment bon à les gérer, sur le long terme, en plus, ça vous permet de vous différencier des autres. Et c’est l’air de la guerre. 

Marc Sanselme 00:36:38 – 00:36:43 : C’est là-dessus qu’on est jugé le plus souvent. On est jugé sur la gestion des crises et moins la gestion du quotidien. 

Stéphane Estevez 00:36:44 – 00:36:49 : Mais surtout, c’est que ça rapporte. C’est pas juste. je reviens à la normale, c’est que j’ai du plus. 

Marc Sanselme 00:36:52 – 00:37:06 : Et qu’est-ce que tu dis le plus souvent dans le cadre de ton travail qui pourrait s’apparenter à de l’évangélisation, que tu as besoin de dire aux gens pour les embarquer avec toi dans tes objectifs ? 

Stéphane Estevez 00:37:06 – 00:40:22 : De poser tout ça sur une feuille blanche avec un stylo ? C’est-à-dire que souvent, on se jette sur une techno, on se jette sur le petit problème qui est à droite et à gauche et on en oublie justement, on fait un peu un biais du survivant quelque part. Aujourd’hui, il y a un certain nombre d’étapes à suivre parce qu’il n’y a rien de pire, encore une fois, si je reprends mon expérience personnelle, il n’y a rien de pire que le changement. Quand on change d’outil, quand on change de manière de collecter les données, parce qu’il y avait des process, des formations, des trucs, il y a tout un historique. Donc, à partir du moment où on décide de faire ce changement, c’est de le faire plutôt bien parce qu’on va le payer pendant longtemps. La technique, on la traîne. Donc, moi, je conseille aux gens de démarrer. Comment je collecte la data ? Moi, première étape, open télémétrie. Ça tombe bien, c’est open source. Je n’ai pas d’action dedans, personne n’en a. Nous, on a fait le plein de Paris, mais encore une fois, c’est un effort communautaire. Première étape. Au moins, j’ai une manière de collecter la télémétrie qui est standardisée, qui est gratuite, dont l’équipe sécurité va aussi adorer, qui me permet en plus de taguer, de mettre plein de choses, d’anonymiser, de faire plein de choses avant d’envoyer des données vers une plateforme d’observabilité ou une plateforme de data. Et qui, en plus, si demain, je n’aime pas la plateforme à qui je l’ai envoyée, j’ai juste à rerouter les flux et je n’ai pas besoin de tout réinstrumenter. Parce que ça, c’est ce qui est le plus embêtant. Surtout si j’ai la SLS sur chacun des éléments, etc. Donc ça, c’est la première étape. Je m’intéresse à comment je collecte la data. Ensuite, à qui je l’envoie. Et de plus en plus, c’est vraiment d’avoir cette vraie approche plateforme. Oui, on a des équipes séparées. On a beau vendre du DevOps, maintenant on parle de DevSecOps, de BizDevSecOps, on en rajoute autant qu’on veut derrière. La réalité, c’est qu’on voit quand même souvent encore des silos, etc. Donc, c’est déjà d’obliger les gens à travailler ensemble sur la même plateforme et de casser ces silos entre les sources de données pour avoir ce meantime to innocence, mais plutôt dans l’aspect positif. Faire du blameless troubleshooting. On s’en fout de savoir si c’est la faute à qui il est. On est tous là pour trouver la solution, pour parler clairement, pour être un peu… Et ça, si je ne sais pas avec quelles sources de données commencer, je commence peut-être par les logs, tout simplement. Pourquoi ? Parce que c’est la source de données que tout le monde comprend. Un développeur sait ce que c’est qu’un log. Une équipe IT Hub sait ce que c’est qu’un log. La sécurité sait ce que c’est qu’un log, etc. Et après, je rajoute les autres, par exemple. Je commence à casser les silos, mais il faut les casser. Il faut avoir le contexte. Ça ne sert à rien d’avoir log, metric, trace, event. Si je ne les ai pas en contexte, c’est juste de la data. Donc ça, c’est l’étape 2. Et après, je peux m’amuser à aller vers tout ce qui permet d’améliorer tout ça, donc toute la partie AI, etc. Mais il faut vraiment penser comme si je construisais une maison. « Ouais, l’AI, c’est super sympa, mais c’est le panneau solaire. ». Mais si mon palo solaire, pardon, ma maison, elle n’a pas de fondation, moi, ce qui alimente l’AI, ce qui alimente les algorithmes, c’est la data. Et si j’ai la data, comment je la collecte ? Voilà. Donc, il faut vraiment… C’est structurant, mais ça paye. C’est ça qui est sympa, c’est que ça paye. C’est-à-dire qu’on passe moins de temps à troubleshooter, plus de temps à créer des nouvelles applications. Et je pense que c’est ce que tout le monde veut, pas avoir à gérer les problèmes. Je préfère le ciel bleu. Enfin, moi, perso, je préfère le ciel bleu. 

Marc Sanselme 00:40:23 – 00:40:34 : Est-ce que tu as une opinion que tu n’as pas déjà partagée? parce que tu nous en as déjà partagé ? Est-ce que tu as une opinion que tu voudrais nous partager ? 

Stéphane Estevez 00:40:34 – 00:41:29 : Non, c’est ça, c’est juste prendre le temps. Pas brûler les étapes. Je sais que ça peut sembler contre-productif lorsque justement tout le monde parle de temps réel. Mais c’est des choses qui se préparent bien. Et il ne faut pas hésiter à demander de l’aide. Que ce soit Splunk, mes confrères, j’imagine que c’est pareil. On voit plein de clients tous les jours dans des situations assez similaires. Donc on peut partager des cas d’usage ou des méthodologies ou comment faire pour accompagner les gens justement pour y aller et pas brûler les étapes. Souvent aussi on essaie de, ma dernière opinion c’est toujours de trouver un quick win aussi parce qu’on a toujours des boss, toujours un patron à convaincre. Et on a une roadmap, mais il faut toujours démarrer avec le premier quick win pour juste créer la confiance. Et après, il faut chercher le budget, il faut chercher les équipes qui ont envie de travailler et créer un peu cette dynamique. 

Marc Sanselme 00:41:30 – 00:41:38 : Ok. Alors, l’épisode touche à sa fin, mais quelle personne tu aimerais entendre dans un prochain épisode ? 

Stéphane Estevez 00:41:38 – 00:42:02 : moi j’aimerais bien. justement on a beaucoup parlé d’open télémétrie. moi j’aimerais bien écouter. peut-être une société justement. nous on en connait quelques unes. je vais peut-être te donner des noms mais ouais ouais des retours d’expérience sur l’open télémétrie ou sur l’observabilité également parce que c’est des sujets qui m’intéressent. donc ouais j’aimerais bien écouter. 

Marc Sanselme 00:42:02 – 00:42:03 : c’est une super idée. merci Stéphane. 

Stéphane Estevez 00:42:03 – 00:42:04 : bah merci à toi. 

Marc Sanselme 00:42:06 – 00:42:36 : juste faire la petite outro. pour terminer j’ai besoin d’enregistrer deux phrases. vous venez d’entendre Stéphane Estevez consultant en observabilité de marché EMEA chez Splunk. dans le prochain épisode je recevrai Stéphane Estevez consultant en observabilité de marché EMEA chez Splunk. ok.