De la sélection d’une plateforme à l’observabilité des applications critiques

LE PROJET EN BREF

Un programme complet, de la sélection à l’adoption

ARCHITECTURE D’OBSERVABILITÉ

Relier l’usage, les transactions et les composants

Schéma conceptuel : aucun système, écran ou donnée client n’est représenté.

ÉTAPE 01 / 08

Partir d’un problème de visibilité, pas d’un outil

Dans une grande organisation disposant d’un système d’information étendu, plusieurs applications essentielles reposaient sur des composants techniques interdépendants. Lorsqu’une dégradation apparaissait, il fallait mobiliser plusieurs spécialistes pour rapprocher les symptômes, confronter leurs observations et remonter progressivement vers la cause. Le besoin exprimé n’était donc pas simplement d’ajouter des sondes : il s’agissait d’obtenir une vue cohérente des parcours applicatifs, des dépendances et de leur impact sur l’expérience réelle des utilisateurs.

Nous avons commencé par traduire les attentes des équipes informatiques en objectifs de diagnostic : quels parcours observer, quels composants relier, comment qualifier un incident et à quel moment la plateforme doit alerter. Cette expression de besoin était nécessaire pour comparer des offres qui, sur le papier, proposaient toutes de collecter des métriques et de produire des tableaux de bord.

ÉTAPE 02 / 08

Un benchmark Gartner, puis trois acteurs en soutenance

Le programme a pris appui sur les analyses du Gartner disponibles au moment de la consultation. Elles ont servi de point de départ pour constituer une présélection de trois éditeurs majeurs, et non de verdict automatique. Une position favorable dans une étude de marché ne garantit ni la compatibilité avec un patrimoine applicatif, ni l’adoption par les équipes.

Une expression de besoin structurée a été soumise aux acteurs retenus. Les soutenances permettaient de comparer les démarches d’implémentation, l’APM, la cartographie des dépendances, la restitution des données, l’expérience utilisateur, la gouvernance et les conditions d’exploitation. Nous avons cherché à départager les réponses sur les situations que rencontreraient réellement les équipes : une transaction lente, un dysfonctionnement intermittent, une dégradation liée à un service tiers ou un incident dont la cause n’apparaît pas dans la couche infrastructure.

ÉTAPE 03 / 08

Un POC sur plusieurs briques majeures du SI

Après les soutenances, un POC a été organisé autour de la proposition considérée comme la mieux adaptée au besoin. L’enjeu était de la confronter à plusieurs briques fondamentales du système d’information, et non à une démonstration idéale sur un environnement isolé.

Nous avons évalué la capacité à suivre des transactions, relier les services et éclairer les causes possibles d’une dégradation. Pour un tel dispositif, l’instrumentation APM doit être rapprochée des métriques d’infrastructure, des événements et, lorsque les applications le permettent, des traces distribuées. Le nommage des services, la cohérence des environnements et les attributs associés aux transactions sont décisifs : sans conventions communes, une plateforme peut découvrir énormément de composants sans fournir une lecture exploitable. Les scénarios de test ont donc été envisagés du point de vue de l’investigation, pas uniquement de la collecte.

ÉTAPE 04 / 08

Pourquoi Dynatrace a été retenu

À l’issue de cette démarche, Dynatrace a été retenu pour le programme d’observabilité. Le choix résultait des soutenances et de l’évaluation menée sur le périmètre pilote, avec une priorité : rendre les dépendances et les comportements applicatifs suffisamment lisibles pour accélérer les investigations.

La sélection d’un outil ne réglait toutefois pas la question de son appropriation. Il restait à construire une méthode commune : définir les services à observer, organiser les droits d’accès, clarifier les responsabilités sur les alertes et expliquer ce que chaque direction pourrait attendre de la nouvelle plateforme. Dynatrace devait devenir une capacité opérationnelle partagée, et non un nouveau tableau de bord réservé à une équipe d’experts.

ÉTAPE 05 / 08

Déployer une première brique, puis étendre par étapes

Nous avons débuté par le déploiement sur une première brique importante du SI. Cette étape a permis d’associer mise en place technique, appropriation par les équipes et retour sur l’utilité des informations disponibles. Le déploiement n’était pas conçu comme une activation simultanée sur l’ensemble du patrimoine.

Une extension progressive a ensuite concerné d’autres composants majeurs. Chaque nouvelle application soulevait des questions proches, mais rarement identiques : conditions d’instrumentation, versions des technologies, flux entre services, fenêtre de changement, règles de nommage et niveau de détail de la télémétrie. Le principe directeur était de conserver une lecture cohérente d’une brique à l’autre. L’accompagnement au changement auprès des différentes directions, ainsi que la formation, ont compté autant que le paramétrage technique dans cette montée en charge.

ÉTAPE 06 / 08

Le RUM pour reconnecter la technique à l’expérience utilisateur

Un volet du travail a porté sur le Real User Monitoring, ou RUM. L’idée était de ne pas déduire l’expérience utilisateur de la seule disponibilité des serveurs. Une application peut répondre aux contrôles techniques tout en présentant, côté navigateur, un chargement lent, des erreurs JavaScript ou un parcours pénible.

Avec le RUM, l’analyse s’intéresse à des sessions et à des parcours réels : temps de chargement, erreurs côté client, interactions et variations selon le contexte d’utilisation. Ces données nécessitent des précautions de confidentialité et une définition claire de ce qui doit être collecté. Associées à l’APM, elles permettent de rapprocher un symptôme vécu par l’utilisateur d’une transaction et des services sollicités. Ce rapprochement est particulièrement utile lorsqu’un incident ne provoque pas de panne franche, mais une dégradation perceptible.

ÉTAPE 07 / 08

Une squad pour rechercher directement la root cause

L’un des changements les plus concrets concernait la manière de traiter les incidents. Plutôt que de convoquer immédiatement tous les spécialistes d’une chaîne applicative, nous avons constitué une squad capable d’intervenir rapidement à partir des informations disponibles dans Dynatrace. Elle pouvait engager une investigation ciblée, identifier les composants à examiner et solliciter ensuite les bons experts.

L’approche suivait un chemin simple : partir du symptôme, identifier le parcours affecté, observer les traces et les dépendances, comparer les signaux de latence ou d’erreur et formuler une hypothèse sur la root cause. Cette hypothèse restait à confirmer techniquement avant toute remédiation. Le changement était avant tout organisationnel : réduire les recherches dispersées et donner aux intervenants une base commune pour décider. La plateforme n’était pas censée résoudre automatiquement chaque incident ; elle rendait le dialogue entre équipes plus précis.

ÉTAPE 08 / 08

Faire de l’observabilité une capacité durable

Ce programme a mêlé plusieurs dimensions : benchmark et consultation du marché, soutenances, POC, choix d’architecture d’observabilité, instrumentation applicative, RUM, accompagnement au changement, formation, déploiements progressifs et organisation des investigations. Cédric est intervenu sur cette transformation, de la construction du besoin à l’adoption d’une méthode plus efficace de diagnostic.

L’enseignement principal est qu’une plateforme d’observabilité ne délivre sa valeur que lorsqu’elle rencontre les usages quotidiens de l’organisation. Les données doivent être suffisamment fiables pour orienter une investigation ; les équipes doivent comprendre ce qu’elles regardent ; les nouveaux composants doivent être intégrés avec des conventions reproductibles. Le résultat recherché n’est pas d’avoir davantage de courbes, mais de mieux comprendre ce qui se passe lorsqu’un parcours essentiel se dégrade.

QUESTIONS FRÉQUENTES

Ce qu’il faut retenir

Pourquoi comparer plusieurs plateformes avant un POC ?

Parce que la pertinence d’un éditeur dépend des usages attendus, des technologies déjà en place et de la capacité des équipes à exploiter les informations. Une étude de marché est un point de départ, pas une décision à elle seule.

Quel est le rôle du RUM dans l’observabilité ?

Le Real User Monitoring mesure l’expérience réellement rencontrée dans le navigateur. Il peut être rapproché des traces applicatives pour rechercher la cause technique d’une dégradation visible par les utilisateurs.

Qu’apporte une squad d’investigation ?

Elle fournit un premier niveau de diagnostic transverse, capable de mobiliser les spécialistes concernés à partir d’éléments de télémétrie partagés, plutôt que de réunir systématiquement tout le monde.