Observabilité : prenez des décisions éclairées pour un numérique responsable.

Bonjour à tous et merci d'être venus assister à ce talk où on va vous parler d'observabilité et de la prise de décision éclairée pour un numérique responsable. En introduction, pour imaginer un peu le propos, imaginez-vous que vous montiez dans un avion, quelle que soit sa taille, dont le ou les pilotes ont construit eux-mêmes leur avion pour le piloter, et tout en sachant que potentiellement vous n'avez pas de tour de contrôle pour gérer les plans de vol. Vous aurez une vue assez parlante de ce qu'on trouve dans les divers systèmes d'information au travers des outils qui sont mis en place et de leur implémentation.

-Alors, je suis Guillaume Velder, je suis Practice Leader chez Open, nommé gourou observabilité, et donc je travaille depuis 23 ans dans l'accompagnement des DESS dans leur transformation perpétuelle, puisque c'est véritablement le cas, et ça fait une douzaine d'années. Donc, je suis spécialisé dans le domaine de la supervision et ce qu'on appelle aujourd'hui de manière plus large l'observabilité, et donc tous les process associés et les outils qui gravitent autour de l'observabilité de manière générale.

-Donc moi, Jacques Bchillot, je suis architecte applicatif, ça fait 20 ans que je fais de l'informatique, ça fait plus, ça fait 16 ans à peu près que je fais du web. Je suis certifié numérique responsable, et je m'intéresse surtout en ce moment à intégrer justement cette composante numérique responsable au sein de nos applications.

- Et encore un autre quinquagénaire, Luc Lefèvre. Je fais du web depuis 99, du e-commerce depuis 2006. J'ai fait un peu de dev. Aujourd'hui, je suis chef de projet Technical Program Manager chez un client. Le numérique responsable, ça a toujours été mon dada. Parler d'accessibilité, on parlait de faire en sorte que tous les sites web soient utilisables par nos clients. Finalement, tout ça, c'est du numérique responsable. Et bah, aujourd'hui, je suis certifié numérique responsable. Open, on a inst stand là-bas qui est aussi certifié numérique responsable, et je suis hyper content. On est très content tous les trois C d'être là pour avoir cet échange. Let's go, Guillaume, c'est ton tour, merci.

Donc, un rapide retour sur ce qui constitue aujourd'hui le besoin et la naissance, enfin, du besoin de l'observabilité dans les systèmes d'information. Sur 40 ans d'histoire globale de l'informatique, on est passé de systèmes hypercentralisés à des choses qui se sont finalement déployées au niveau des si, rien qu'au travers des matériels donnés aux utilisateurs, mais également finalement maintenant tout ce qui est socle technique et socle applicatif, avec la mobilité qui s'est invitée depuis des jeunes dizaines d'années, le Cloud qui est le sujet d'aujourd'hui, et l'intelligence artificielle qui va aussi venir s'inviter dans toutes les thématiques techniques, et également finalement au niveau de l'observabilité.

La dématérialisation du socle technique, toute la structuration des applications, ça a fait aussi changer les méthodologies de travail. Hein, le DFC Cops est bien implémenté partout, en fait, il y a eu une transformation de silos purement techniques pour basculer vers des silos maintenant organisationnels qui sont construits finalement par des équipes PO, PM, les équipes DevOps opérationnelles qui les constituent et qui sont en responsabilité d'un ou d'un pool d'application, la supervision finalement.

C'est l'éclatement de toutes les données qui sont récupérées sur des socles applicatifs, des socles techniques, et c'est, la première étape en termes de récolte de métrique, de log, de trace et autres, mais qui sont finalement éclatées. Et bien souvent, c'est difficile pour une entité de driver la récupération de ces informations et de la centraliser, la constitution des dashboards pour qu'ils soient pertinents. C’est une question qui est très compliquée à mettre en œuvre au sein des DSI, et c'est d'autant plus compliqué qu'aujourd'hui toutes les infrastructures et applications sont de moins en moins tangibles. On utilise des méthodes langage du déclaratif pour créer, poper des infrastructures, les détruire. On l'a vu tout à l'heure avec des vies de Pod de quelques secondes au besoin. Et donc, pour en arriver à l'observabilité, où finalement où le véritable travail ce sera d'agréger toutes ces données et de pouvoir en créer des dashboards qui auront un véritable sens pour les DSI.

Concentration de données, vue globale et métaobjet. Donc, métaobjet au sens application, je regroupe toutes mes métriques, représente l'application que je veux voir dans un état de taux de disponibilité de 97%, 98%, 99%, et qui fait véritablement la différence, c'est d'en arriver à intégrer également des données métiers pour apporter du contexte finalement à ce que l'on a récupéré dans des métriques qui sont vraiment technico-techniques.

On aborde la partie numérique responsable, observabilité et numérique responsable. Déjà, l'idée c'est derrière numérique responsable, l'idée c'est qu'on se mette d'accord sur une définition. Moi, j'ai repris la définition de l'Académie du numérique responsable qui font un super MOOC, je vous conseille. C'est réduire finalement le numérique responsable, c'est réduire l'empreinte écologique sociale du numérique. Je pense qu'on a tous entendu parler aujourd'hui, 40 ans de transition numérique, on n'est pas fini, on avance, et on a enfin compris que potentiellement il y avait un problème climatique derrière tout ça. Finalement, on a l'urgence climatique. Je pense que tout le monde est un peu au courant de ce qu'on entend par urgence climatique. Ça fait longtemps qu'on est en urgence climatique. Rapport du chef de projet de 2018 qui dit que le numérique représente 4% des gaz à effet de serre avec une augmentation de 9% par an de la consommation d'énergie. Je pense que tout le monde est au courant de ça, et on se dit bon, ok, j'essaie d'agir, mais l'intérêt, je trouve, que dans le numérique responsable, c'est qu'il y a quelque chose vraiment sympa. C'est qu'au lieu de se dire, d'un côté il y a la transition numérique, de l'autre, il y a l'urgence climatique, c'est de se dire je prends les deux et je fais avancer les deux en même temps et c'est finalement concilier les deux sujets.

On va se dire finalement avec le numérique responsable, c'est je peux créer de la valeur économique, je peux créer de la valeur sociale, je peux créer de la valeur environnementale. Donc, on crée la valeur. On peut aussi avoir l'envie, et je pense que c'est nécessaire, de vouloir réduire l'empreinte sociale et environnementale du numérique. Et troisième point, on peut se dire aussi, tiens, bah avec le numérique, je peux avoir des actions positives. Je peux utiliser le numérique pour réduire cette empreinte sociale et environnementale. Donc, c'est ça le numérique responsable.

On est à Cloud Nord aujourd'hui, le Cloud est effectivement une peut-être une solution plutôt que d'avoir des datas VO plutôt qu'avoir ses serveurs en propre chez soi qui ne sont pas utilisés à 100%. Le Cloud, finalement, on va payer un service, le service on va le confier au High Scaler, à OVH, à GCP, à AWS, à Microsoft Cloud. Eux, leur intérêt, finalement, c'est économique. C'est déjà de faire en sorte que leur infra, quoi tout ce qui défoie, ça réduit finalement la consommation d'énergie. En fait, eux, ils sont hyper bons là-dedans et effectivement, ça c'est une vraie opportunité.

Donc, voilà, là où ils peuvent être moins clairs, c'est peut-être sur la rotation de leur machine, la rotation de leur matériel. On sait qu'en gros 60 PE là. Ouais, c'est cette slide là, voilà alors ce sont les chiffres de là, ça date de 2022. 78% de l'impact environnemental est lié à la construction des machines, aussi bien les serveurs aussi bien que les devices client. 21% concerne la phase d'usage. Bon, il y a 1%, j'ai essayé de chercher où ça venait. Je ne sais pas s'il y a quelqu'un de la dame ici qui pourrait me l'expliquer.

Globalement, le sujet quand même du numérique responsable, c'est peut-être s'attaquer à ces 78% tout le temps. En tout cas, il faut s'attaquer au 78%. Il faut aussi s'attaquer au 21%. Et finalement, le numérique responsable, donc comme je le disais, c'est les deux sujets, hein, euh, transition numérique et urgence écologique. Voilà, et finalement, il faut aller concilier les enjeux sociaux, environnementaux et économiques. Et finalement, si on parle d'observabilité aujourd'hui, c'est un processus qui a le net avantage de poser le sujet au sein de l'entreprise. On va pouvoir finalement se dire, bah chacun fait des efforts. On va pouvoir mesurer les efforts réalisés par chacun avec une data centralisée. Mais je te laisse la parole maintenant.

La technicité, Guillaume. Alors, l'observabilité en tant que telle, en tant qu'outillage pour une DSI, euh, le but c'est de partir de la technicité pour arriver à une prise de décision. Alors, j'ai pris un chiffre qui a été fourni par New Relic, euh, et qui expose que 72% des DSI ou des services informatiques de manière générale utilisent plus de deux outils d'observabilité. Donc, qui peuvent être un peu ce qu'on connaît aujourd'hui sur le marché, une série, une suite ELK, du Datadog, du Sentry, enfin, du Dynatrace et de nouveaux acteurs qui arrivent sur le marché.

Le véritable sujet, finalement, là-dedans, ce n'est pas tant l'outillage en tant que tel que ce que l'organisation que ça demande. Ce qu'il faut bien voir, c'est véritablement que pour arriver à avoir une prise de décision, il faut avoir une donnée concentrée. Et donc, il faut que dans une DSI, on ait un choix de produit qui soit le plus centralisé possible, qui n'empêche pas tout un chacun en tant que développeur, en tant que HS, de créer ses propres dashboards pour ses propres besoins, d'utiliser potentiellement même dans son coin plutôt le CloudWatch directement ou un PgWatch 2 quand on fait du PostgreSQL parce que c'est plus pertinent techniquement. Mais derrière ce qui est important, c'est que même si ces outils-là sont très pertinents pour les personnes qui utilisent au quotidien une techno particulière, il faut arriver véritablement à cultiver tout le monde pour que l'injection des données, des datas, soit centralisée sur un outil qui a été, euh, choisi et qui va faire foi pour le reste de la DSI.

L'important également, ce sera de travailler sur tout, tout ce qui est normalisation et référentielle puisque finalement, pour pouvoir faire de l'agrégation dans tous ces outils-là, il faut que les équipes agiles puissent se mettre d'accord sur des terminologies, du tagging, des choses comme ça qui doivent être structurées sinon au risque d'avoir un éclatement de la donnée dans les outils et d'être en incapacité de d'assurer qu'on supervise et qu'on observe finalement tout le périmètre technique de la DSI et finalement qu'on a compréhension à tous les niveaux de cette data et que en plus de ça par la suite on puisse agréger des datas qui au premier abord ne paraissent pas être liées mais qui finalement mis bout à bout ou mélangé mixé au travers des différents dashboards possibles les formules mathématiques qu'on a à disposition dans les outils permettent de dégager des informations intéressantes en terme de conduite de produit par exemple plutôt que un état, un état, un instantané d'une application.

Pour illustrer le propos, ce que je vous montre contre là c'est un dashboard qu'on voit euh de manière assez assez courante, euh, qui est très beau comme ça avec bon on a plein de métriques, on a plein de pourcentages, on a du vert, du rouge, du orange, on voit bien qu'il y a des choses qui a priori ont dépassé certains seuils, ça parle tout de suite, mais finalement en fait sur un dashboard comme celui-là, moi il y a quelque chose qui me dérange beaucoup euh, c'est pas de l'observabilité, on est sur de la supervision, ni plus ni moins. L'observabilité elle va venir à partir du moment où par exemple quand on fait du e-commerce, c'est un exemple qui est assez simple à traiter, ce qui aurait été intéressant pour pouvoir déjà corréler l'activité qu'il y a là euh par rapport aux métriques techniques qu'on y a agrégées, c'est tout simplement avoir le nombre d'utilisateurs unique, le nombre de connexions qui sont réalisées sur le site, le nombre de paniers ouverts, le nombre de Canaux de paiement qui ont véritablement été euh aboutis, qui ont été jusqu'au bout parce que dans ce cas-là ça permettra de voir des activités qui ne sont pas des activités techniques, on peut avoir un site qui fonctionne très bien et pourtant avoir des articles mal encodés, avoir des prix mal appliqués, et puis tout à coup ça s'affole, on sait pas pourquoi parce que techniquement tout est ouvert, tout fonctionne, mais en fait c'est pas à ce niveau-là qu'il faut regarder, c'est un niveau plus haut, un niveau global, à un niveau beaucoup plus proche du corps business et l'intérêt de mettre un peu de business dans nos dashboards c'est tout l'intérêt c'est de travailler le mix technique et le mix métier.

Alors comment faire vivre cette observabilité sur le long terme, c'est un sujet qui est compliqué également parce que finalement de la même manière qu'il faut rester pertinent techniquement, apprendre en continu, euh, ça fait partie des éléments du DevOps. Il de se former en continu, bah finalement, suivre l'observabilité de ce qu'on met en œuvre, ça fait partie des éléments qu'il faut absolument avoir en tête. C'est-à-dire pas uniquement son sprint et puis terminer le sprint avec toutes les features qu'on a pu engager, et ainsi de suite, mais que on se soit dit à chaque fois j'ai telle chose qui arrive, comment je vais faire pour m'assurer que cette brique que j'ai mise en place soit remontée correctement dans les outils. En fait, pour que ce ne soit pas quelque chose qui soit un pain point pour tout le monde et que ce ne soit pas une surcharge complémentaire de travail, il faut donc cette acculturation à tous les niveaux.

Mais il faut également donc le rendre le plus dynamique possible, l'automatiser plus, que tous les workflows qui permettent de déployer n'importe quel élément dans votre infrastructure soient automatisés et atterrissent directement dans les outils. Il faut que ce soit surtout connu de tous et utilisé par tous parce qu'en fait l'observabilité meurt à partir du moment où on n'a pas de consommateur de l'observabilité. On se finit par avoir des dashboards qui dépérissent dans un coin qui sont représentants d'une infrastructure ou d'une architecture qui est datée, et finalement, ben, on a des outils qui ne tournent pour rien et des processus certainement derrière aussi qui ne sont plus suivis. Donc, en tirer une qualité de données pour tout ça, on connaît tous, euh, ce cycle-là donc de devsops qui est déployé partout. En fait, ce qu'il faut voir, c'est que l'observabilité, il faut vraiment qu'elle vienne se greffer en en 4e élément, comme quelque chose qui soutient tout ça. Parce que votre avancée dans les futures, elle arrive bien, les besoins arrivent bien parce que vous devez avoir plus de consommateurs, vous devez avoir plus d'utilisateurs sur votre plateforme, vous devez avoir moins d'incidents et ainsi de suite. Donc, chaque personne qui a un profil dev, profil plus sécurité, plus système doit avoir cette culture de l'observabilité pour travailler ensemble et avoir finalement un langage commun.

Dans plusieurs ESI où j'ai travaillé, on avait des champions qualité, champion sécurité, he des personnes qui, comme un moustique, viennent sans arrêt. Vous vous rappelez qu'ils sont là et qu'il y a des choses à respecter pour sécuriser le SII. En fait, c'est véritablement quelque chose qu'il faudrait aussi voir naître dans les SII, c'est champion d'observabilité, c'est-à-dire une équipe HS qui fait qui qui soutient tout l'outillage, he les zbler à mettre en place. Mais par contre, dans les équipes, dans toutes les équipes agiles finalement, avoir des personnes qui, je suis dev, mais je sais ce que c'est que l'observabilité et je suis le meilleur placé pour savoir comment superviser ce que je suis en train de mettre en œuvre, je suis HS. C'est pareil pour le système. Ouais, il y a un sujet d'évangélisation derrière tout ça, c'est beaucoup de d'acculturation et...

L'iceberg de l'observabilité, d'embarquement finalement dans une thématique qui va prendre de plus en plus de place. On va traiter après un peu plus profondément la partie numérique responsable, mais si on veut pouvoir être capable de montrer de d'avoir des tendances même sur le travail qu'on produit tout un chacun au quotidien, et ben avoir ces métriques-là autant que nos métriques CPU RAM ben, c'est ce sera intéressant pour l'évolution du SII et l'affichage en tout cas de données embarquées. Donc, un sujet plus profond tel que le changement climatique, voilà comment ça se enfin l'iceberg qu'on a aujourd'hui à construire qui est quand même assez imposant parce que la première frontière qu'on voit ici à ce niveau-là c'est bien souvent celle à laquelle la plupart des environnements informatiques s'arrête. On prend des métriques techniques, on les fait apparaître, on met de l'alerting, on fait de la notification, on vient adosser à ça un service de pilotage et de résolution, et puis finalement ça tourne en boucle à ce à ce niveau-là euh là où un outil quel qu'il soit aujourd'hui est capable de beaucoup plus à partir du moment où on va commencer à traiter avec les autres acteurs, donc du métier, euh, et également donc euh faire que les personnes qui sont dans la technique sont aussi en compréhension des sujets et des enjeux corps business de le l'environnement dans lequel il travaille. À partir de là, on peut conceptualiser les fameux dashboard métier et qui vont venir agréger finalement les leurs métriques dans des dashboards comme je montrais tout à l'heure par exemple par rapport au e-commerce.

Et seulement à partir de là on pourra faire d'autres calculs d'autres représentations qui seront beaucoup ou plus tournés sur le green et le social, euh, mais ça je te laisserai développer cette partie-là, yes, et ça donne aussi de la visibilité à ceux qui prennent qui font des choix dans nos systèmes d'information. La direction d'avoir cette visibilité au même niveau, chacun des produits, la même observabilité le produit A le produit B ben, on parle de la même chose. C'est important pour le pour ceux qui prennent des décisions d'avoir une vision éclairée de de la plus agrégée possible ou alors une image de l'observabilité comme on parle de numérique responsable. Je prends un graphe de du GC, tout simplement pour dire que là derrière finalement si on prend ce graphe-là, on peut le comprendre tous très vite malgré certainement derrière une quantité phénoménale de d'indicateurs qu'il a fallu agréger pour pouvoir obtenir cette vision là et faire des projections.

Pour moi, ça c'est une représentation de ce qu'on devrait pouvoir obtenir sur un dashboard qui sera typé métier qui sera typé anticipation de comment mon SI va va évoluer, comment ma consommation d'un service cloud de manière globale va évoluer. Alors du coup, oui, on parle de Comment intégrer l'observabilité dans une application ?

Comment est-ce qu'on intègre cette notion de développement durable dans une application ? Comment on doit faire ? Bah, il faut l'intégrer de la même manière que la sécurité ou que la qualité, c'est ce que l'on fait déjà dans toutes les applications. Ben, elle doit être exactement au même niveau. On a déjà des personnes qui sont sensibilisées, qui sont formées à la qualité, qui sont formées à la sécurité. Il en faudrait de même, il en faut de même pour le numérique responsable.

Pour mesurer cet impact environnemental, où est-ce qu'on va le faire ? Ben, on va le faire tout au long de la vie du projet, dès la conception, pour pouvoir faire les bons choix. Il faut intégrer les bonnes technologies, il faut intégrer les bons designs dans la réalisation, parce qu'il va nous falloir nos indicateurs de suivi, comme pour la sécurité, comme pour la qualité. Exactement pareil, on va devoir mettre en place nos indicateurs, les suivre, et prendre des décisions par rapport à ça, et aussi sur les maintenances. Parce que les maintenances, c'est quoi ? Ce sont aussi des remontées d'indicateurs. On va devoir suivre la qualité, la sécurité, corriger les problèmes, et pareil pour le développement durable, pour l'impact de l'application sur l'environnement.

Si on ne respecte pas les exigences, on a besoin d'avoir à ce moment-là, et pour faire tout ça correctement, parce qu'on fait déjà en fait ça, on a déjà, comme tu disais juste avant, on a déjà des indicateurs techniques qui remontent dans des petits dashboards qui sont un peu éparpillés, qui sont mesurés surtout pour les développeurs, un peu pour les pilotes de projet. Pour le faire bien, il faut le faire avec l'observabilité qui doit intervenir du coup partout et qui doit être mise en place justement par ce profil Obs et pas HS. Attention, ne pas confondre le profil HS. On va l'intégrer dès le début autour de la table avec tous les autres acteurs, comme on avait fait à un moment donné. On avait mis un peu de côté les UX/UI qu'on a ramenés depuis peu autour de la table dès la conception.

L'Obs dès le début, il doit être là pour discuter, pour donner son avis, plus que ça, pour nous guider. Si on revient à la conception, c'est lui, à base de référentiels existants qu'on peut avoir sur les clouds providers. Ils donnent tous un impact de l'utilisation de leur plateforme, mais aussi à base de référentiels qui seront construits. Là, on reviendra un peu après sur tout ce qui est référentiel numérique responsable. Il va nous aider du coup à faire ces fameux choix techniques, ces fameux choix de design d'architecture. Et même mieux que ça, il va travailler aussi avec le CFO, parce que le CFO lui, ce qu'il veut, c'est dépenser le moins de ressources possible, ce qui est génial, c'est ce qu'on veut faire avec du numérique responsable. On veut dépenser le moins de ressources possible. Du coup, le CFO il va en plus challenger ce que va proposer l'Obs, donc lui aussi sera autour de la table au niveau des ressources.

L'Obs il sera là aussi. Quand je dis "il," ce n'est pas une seule personne, comme on disait tout à l'heure, c'est une équipe qui peut intervenir sur les différentes strates en fait de l'entreprise. Sur la réalisation, c'est lui qui va nous aider à créer les indicateurs. Parce que, on dit qu'on veut des indicateurs, mais il faut savoir quoi remonter comme information. Comment on les construit et surtout après comment on les crée ? Comment on va faire les configurations techniques des applications, l'intégration d'ingénieurs ou autres, qui vont nous permettre de remonter vraiment ces indicateurs et qui soient cohérents aussi entre tous les produits dans l'entreprise. Encore une fois, cohérente. Et comme tu le disais tout à l'heure aussi, les métriques, il faut les monter, mais pour les différentes strates. Pour la technique, pour le métier aussi, pour des pilotes qui ont besoin de vérifier que financièrement tout se passe bien, mais aussi pour la stratégie de l'entreprise. Pour vérifier que les applications répondent bien aux besoins de la stratégie. Tout ça, ce sont des applications différentes sur aussi bien les exigences que d'impact environnemental que de la CQ que de la qualité.

Et sur la maintenance, c'est la même chose aussi. On a besoin aussi d'avoir ces indicateurs qui vont remonter encore une fois pour les suivis et pour les correctifs qui pourraient y avoir à faire. Parce que dans une architecture cloud hybride multicloud avec de l'infrastructure as a service, des VPN, tout ce que vous voulez, vous avez besoin de contexte. L'équipe elle a besoin de contexte, elle a besoin de trace et ça faut que ça se remonte proprement et sur toutes les exigences qui concernent l'application. Donc, je parlais de référentiel. Ces référentiels sont assez importants et je vais laisser Luc enchaîner là-dessus.

Oui, merci. Donc, Jacques nous donne une vision dev finalement. Dev-run aujourd'hui, build-run, build-run. Excuse-moi. Oui, tout à fait. Et moi, j'ai plus eu la casquette un peu gestion de programme, gestion de projet. En fait, l'observabilité ça va nous permettre d'avoir un référentiel commun, d'avoir tout le même langage avec l'ensemble des parties prenantes : décideur, chef de projet, product owner, product manager, développeur, testeur, métier. J'en oublie peut-être aussi, excusez-moi, mais l'idée c'est vraiment ce langage commun.

Sur ce graphique, en fait, on voit deux choses : la partie consommation des ressources et le côté humain. Sur la partie consommation des ressources, finalement pour simplifier, quand on parle de ressources informatiques, finalement on va parler de stockage, classique d'échange de données, échange de données entre API, échange de données entre serveur et client. On va aussi parler de charge de calcul, charge de calcul côté serveur, côté client, aussi. Il y a des outils qui nous permettent d'aller capturer de l'information sur les devices de nos clients pour voir quel est l'état de leur CPU, quel est l'état de leur mémoire, et etc. Donc, autant en profiter. Donc, ouais, c'est ça en fait.

Avec le cloud, on peut avoir plusieurs fournisseurs. On est de plus en plus en app, je pense que on en a pas mal parlé autour des conférences aujourd'hui. L'idée finalement, c'est d'agréger toutes ces données avec un référentiel des tags communs et de se dire bah, j'ai cette donnée. Alors, peut-être pas en temps réel, mais de manière suffisamment récurrente pour pouvoir se dire bah, oui, j'avance dans la bonne direction.

Quels sont les exemples concrets ? Aujourd'hui, les killers focus pas mal sur la partie empreinte carbone de leur outil. C'est intéressant, ça permet de faire des calculs, c'est très bien, c'est un premier pas, mais on oublie aussi toutes les ressources en eau, en énergie, en ressources abiotiques pour construire les Dev VI et ainsi de suite. Donc, c'est une vue qui n'est pas complète. L'idée, c'est d'être agnostique de ces dashboards que nous fournissent les fournisseurs Cloud et de se dire, bah je construis mon propre référentiel qui va me permettre d'avancer. Donc, ça, c'est la partie ressources. Ensuite, il y a la partie humaine. On va pouvoir mettre, par exemple, un système d'information bien conçu, un système d'information qu'on pourrait qualifier de numérique responsable, c'est-à-dire un SI utilisable, utile, développé, utilisé. C'est de se dire, bah, je vais comparer l'évolution du nombre d'utilisateurs par rapport aux ressources, un nombre de ressources de d'utilisateur constant. Est-ce que je consomme de plus en plus de ressources ? Ensuite, utile, donc ça, c'est une vue un peu macro. Utile, c'est peut-être au niveau du produit, nos marketeux ou l'équipe marketing, excusez-moi, a dit, "Ah, il faut à tout prix développer ça, c'est hyper important, ça va nous faire plein de business," et cetera. Donc, on va mesurer peut-être les performances économiques, et aussi, on peut aussi, au niveau de l'application, c'est de se dire, bah, cette nouvelle fonctionnalité est-ce qu'elle est vraiment utile ? Si elle ne l'est pas, pourquoi la garder ? C'est s'encombrer, dans son quoi, il va falloir la maintenir, va falloir lui appliquer des correctifs.

Mon beau-père, il travaille dans l'avionique et en fait, il m'expliquait que pour être certifié, un code ne doit pas contenir de code mort, il doit contenir aussi que des fonctions utiles. Moi, j'aime bien ce point de vue là parce qu'aujourd'hui, dans le Nord, on fait pas mal de retail et je pense, alors je ne suis pas d'accord, je pense malgré tout qu'on pourrait largement optimiser nos codes pour qu'ils soient plus performants, qu'ils consomment aussi moins de ressources. De la même manière, toujours sur cette image de l'avion, aujourd'hui on a une tolérance au bug sur un site e-commerce qui est quelquefois assez dingue. Si on avait cette même tolérance sur les avions, on aurait peut-être plus de crash. Donc, l'idée, donc, dans l'utilisable, c'est de se dire, bah, je vais mesurer les anomalies et je vais m'assurer que tous mes clients puissent profiter de mon développement. J'entendais récemment dans la boîte où je suis en prestation aujourd'hui quelqu'un qui me disait, "Ouais, bah c'est bien beau les États-Unis, on va peut-être pouvoir y aller, mais par contre, notre France n'est pas du tout accessible. Si on mettait ça en prod B, on se prendrait des class actions et on serait carrément dans la merde." En fait, il y a quand même un intérêt dans tout ça, donc c'est toujours numérique responsable, c'est lié à l'économique, le social et l'environnemental.

L'exemple de Frédéric Bordage, oui, Frédéric Bordage, le leader du numérique durable. Je pense qu'il y en a plusieurs qui le connaissent, ouais bon, euh, lui dit en fait, si on veut s'attaquer à l'empreinte du numérique responsable, à l'empreinte du numérique, excusez-moi, le LET motive, c'est moins d'équipement plus longtemps, et en appliquant cela, on s'attaque à 75 % du problème. En effet, en fait, en ayant cette démarche numérique responsable, en ayant les bons dashboards aussi avec l'observabilité pour le mesurer, on va s'attaquer aux ressources directes de la planète. On va pouvoir maîtriser notre empreinte carbone. Est-ce que je vais dans le bon sens ? Est-ce que toutes les actions que je mène permettent de réduire cela ? Quand on parle de ressources, on parle aussi de ressources indirectes. Est-ce que finalement mon SI est utilisable sur des anciens devices ? On peut aussi le mesurer ça. En parlant des ressources, on sait qu'il y a beaucoup de tension au niveau des ressources. On sait qu'il y a des problèmes d'extraction, d'exploitation des hommes par les hommes. L'idée, c'est de se dire, bah moi, à mon niveau, si je me fixe des objectifs là-dedans, si j'ai cette démarche-là, ben je vais aussi agir sur l'humain. Donc, voilà, ressource directe de la planète, on en a parlé, ressources indirectes de la planète, on a parlé, l'humain lié à la consommation des ressources, on a parlé, et humain lié à l'usage, c'est ce que je vous disais, se dire, "Tiens, c'est super, je vais avoir une fiche produit avec des vidéos qui s'animent et cetera dès l'ouverture de la fiche produit, ça va être classe, ça va être beau," et cetera. Sauf que peut-être ça va marcher à Lille, euh, par contre, en pleine campagne, si on arrive plus à regarder la fiche produit, on arrive plus à commander parce que finalement, euh, la fiche produit est trop longue à charger. Bah là, on a un problème. Donc, voilà, l'idée, c'est vraiment de concilier tout.

Les dashboards, ça, j'espère que je ne suis pas trop long. Ah oui, très beau dashboard que nous a fait Sébastien, Sébastien qui est ici présent, on le remercie pour toutes ces belles slides. L'idée, un peu, ça, c'est une image, c'est de se dire, bah, au niveau des dashboards, on peut avoir des dashboards. L'idée, c'est d'avoir des dashboards qui parlent à chacun, dashboard décideur, peut-être très macro, dashboard produit, dashboard métier, un peu de transparence, c'est l'agilité, on est d'accord, ça fait une partie d'un des principes, et c'est de se dire, bah, tiens, voilà, aujourd'hui, je suis, j'étais là, euh, l'objectif des accords de Paris c'est d'être là sur l'objectif carbone, par exemple. Alors, ce n'est pas les accords de Paris, excusez-moi, je corrigerai plus tard. L'idée, c'est d'avoir du visuel qui parle à tout le monde, basé sur de la data réelle et de se dire, bah, au niveau de mon produit, par exemple, bah, moi, j'ai ce plan d'action. J'en enlève les selectol, je peux suivre des actions donc des actions macro au niveau du SII et des actions au niveau des produits. Se dire, bah, voilà, chacun avance et l'idée, c'est de mesurer aussi régulièrement notre avancée. C'est de se dire, bah, on est dans un processus de continuous delivery, bah, c'est de se dire, bah, ok, j'ai livré et maintenant, ok, j'ai livré, maintenant, c'est de le faire de manière beaucoup plus euh, récurrente, itérative, exactement. Donc, ouais, j'ai parlé de vision décideur sur les dashboards, vision produit, ha, vision métier. En fait, effectivement, euh, je peut être passé la slide suivante.

Les accords de Paris, on a entendu parler aujourd'hui, on n'a pas de chance, il pleut dans le Nord, mais on sait que la température sur l'année 2023 et euh, et limite les accords de Paris, c'est de se dire que on ne doit pas, sur une période de 10 ans, augmenter la moyenne des températures de plus de 1.5 sur 2023. Juste sur l'année, je crois qu'on a un degré 4, j'ai cru lire ça dans les informations récemment, je n'ai pas la source, mais je crois que c'était dans le monde aussi. Le Grenel 2 nous impose aux sociétés, aux entreprises d'une certaine taille de faire un bilan carbone tous les 3, 4 ans. On ne va pas attendre 3, 4 ans, se dire, e j'étais là et maintenant je suis là, ah, bah merde, je me suis gouré. Je me suis gourje n'ai paspas pris la bonne direction. L'idée de l'observabilité, c'est de se dire, bah, comme je le disais, he continuous delivery, c'est de se dire je mesure à chaque fois ma marge de progrès. Euh, on a aussi, euh, une vision très émission, euh, émission carbone sur euh, sur ce que nous impose la loi demain. Euh, si ça se trouve, la loi va nous demander d'autres matrices sur notre consommation en eau, je n'en sais rien et cetera. C'est quelque chose qui, de toute façon, est amené à arriver parce qu'au niveau européen, il y a des propositions de de de loi qui sont en en cours de rédaction et même d'un point de vue euh, franco-français, de toute façon, il y aura à TER des obligations pour les entreprises de présenter des éléments factuels par rapport justement à leur engagement sur le numérique responsable, sur leur consommation. Alors, il n'y a pas que le numérique là-dedans, bien sûr, dans une société qui fait du transport, il y a les camions ainsi de suite, ça couvre tous les secteurs, mais nous, on va aussi finalement être acteur là-dedans. Il y aura de la même manière qu'on présente des bilans consolidés, qu'on a la comptabilité publique qui doit être qui doit être présentée de manière annuelle, il y aura exactement la même chose finalement qui va se mettre en œuvre plus ou moins à marche forcée, mais en tout cas, l'observabilité sera un des un des éléments techniques en tout cas puisque nous, on est fortement technicien, finalement, dans dans toute cette histoire avec juste cette capacité de se dire, ah, je peux moi-même, à mon niveau, même si bah je fais partie des petits moustiques comme expliqué tout à l'heure, ben influer comme je peux sur sur ce ce coût global de l'informatique et du et du numérique. C'est ça en fait euh, avec l'observabilité, on va pouvoir positionner des KPI, des KPI commerce, mais aussi des KPI sur des sur des mesures où on peut influer et l'observabilité finalement va va nous permettre d'avoir cette vision éclairée de la situation, toujours dans ce dans ce processus de d'amélioration continue. Voilà, je vais te laisser conclure du coup, Guillaume.

Ouais, voilà donc ce qu'on voulait présenter dans ce talk, que c'était finalement pas tellement de de la technique pure et dure, mais la capacité qu'on a qu'au travers de d'outils qui finalement sont là pour dans un premier temps surveiller l'état de de de nos plateformes et de ce qu'on délivre en terme de service à nos clients, bah que on est en capacité aussi tout simplement de de de se poser la question d'une autre manière, moins technique, plus orienté sur quelque chose qui est au niveau qui est à la fois bénéfique pour l'activité des entreprises pour lesquelles on travaille et qui ont un corps business bien spécifique mais également en se disant que on peut tout à fait adresser des thématiques beaucoup plus fondamentales enfin en tout cas qui nous ont qui nous sont adressé aujourd'hui au travers de des différents items qu'on a présenté durant tout cette tout ce talk. Donc, si jamais vous avez des questions sur l'accompagnement qu'on est à même de de de faire, si vous avez des questions sur la supervision de manière générale sur les les euh les process qui sont associés, tout ce qui vient s'agréger autour de des outils d'observabilité et qui permettent de la rendre plus facile, plus aisé, plus pertinente, euh, on est à votre disposition au stand open, donc n'hésitez pas à venir nous nous poser des questions, on sera un plaisir de de vous répondre. On a peut-être encore un peu de temps pour des questions-là en direct, question elles arrivent, voilà. Non, est-ce qu'il y a des questions déjà ? On verra s'il y a du temps, et sinon, ben, on se retrouvera sur le sur le stand. On a été extrêmement clair, j'ai l'impression.

Oui, question, l'observabilité, c'est bien, ça coûte aussi en terme numérique responsable ? Alors tout à fait euh, il suffit de revoir le le le slide qui était présenté tout à l'heure sur l'utiliser, utilisable et utile. Finalement, la question en tant que telle, elle se pose elle-même à l'outil observabilité parce que c'est ni plus ni moins qu'un outil technique, comme je vous disais, on est technicien, moi je suis dans la technique aussi autour de de de ce produit-là plus spécifiquement et il y a ces questions euh c'est le travail avec les développeurs pour voir comment on filtre les logs qu'on pousse dans l'outil pour diminuer la quantité de de log stocké parce que ben on a vu que le stockage c'est un des items qu'il faut travailler euh donc oui c'est un c'est un c'est un outil qui qui vient se poser c'est un outil chapeau finalement, mais une thématique chapeau . Du coup, ma question c'était comment on fait un peu la balance entre ce que ça coûte et ce que ça va rapporter derrière ? Effectivement, je pense que quand je parlais un moment donné, je disais, en temps réel ou pas un moment donné, effectivement faut avoir cette proche de d'écoconception autour de de de ce processus d'observabilité. Mais si on n'est pas si on n'est pas dans ce processus, j'ai du mal à voir comment on va pouvoir mesurer notre marge de progression. Mais oui, il faut avoir cette démarche d'écoconception autour du processus d'observabilité, je pense que c'est là où tu V venir. Oui, ou c'est comment on arrive à mesurer justement parce que des fois justement l'observabilité coûte en même plus cher que les services, souvent même je pense pour certaines solutions effectivement qui sont, et c'est encore plus gênant finalement quand on sait que la solution a un coût très conséquent sur le budget du SI et que on se rend compte que finalement bah c'est un outil, comme je disais tout à l'heure dans une des slides, le faire perdurer il faut qu'on le rende utile et pour ça il y a qu'un seul moyen c'est que véritablement c'est pas l'affaire juste d'une équipe Obs qui va amener faire tenir la solution et la mettre à disposition tous il y a tout ce côté acculturation alors là c'est le micro qui se balade il y a tout ce côté acculturation finalement qu'il faut vraiment travailler aussi pour arriver à avoir une observabilité qui est utile et qui effectivement n'est pas un centre de coût. Je crois qu'on nous invite à couper, mais on est on est tous les trois disponibles pour qu'on puisse en discuter peut-être juste là ou à côté de notre stand euh voilà si vous voulez en discuter on est près de nous, entendre et à tout de suite, merci beaucoup en tout cas.