REDPIXEL - stock.adobe.com

Chez iad, l’observabilité est le ciment des bonnes relations entre Devs et Ops

Faire coopérer les développeurs et les Ops, mission impossible ? Pas pour les équipes cloud d’iad. Le réseau immobilier a profité de sa migration vers le cloud et de l’adoption d’une plateforme d’observabilité pour rapprocher les deux populations et améliorer la qualité du code en production.

Iad est un réseau de mandataires immobiliers. Il rassemble près de 18 000 conseillers indépendants et est géré par environ 495 employés dans huit pays. Ce groupe qui a réalisé un chiffre d’affaires de 453 millions d’euros en 2024 est le leader de la vente immobilière en France. Il est également présent en Allemagne, au Portugal, en Espagne, en Italie, au Mexique, au Royaume-Uni et aux États-Unis (plus particulièrement en Floride).

« Nous offrons un CRM à nos agents immobiliers avec une large palette d’outils : gestion de prospects, mandats, diffusions des annonces, gestion des visites, transactions, etc. », résume Armand Saghri, Responsable Cloud & Operations chez iad. « Cela leur permet de réaliser toutes leurs tâches du quotidien ».

Armand Saghri a rejoint iad en 2022 après avoir quitté Altice Media où il s’occupait de l’architecture cloud des sites Web médias, dont BFM TV. Avant cela, le responsable cloud avait travaillé pour Canal +.

« Pour moi qui viens de l’univers des médias, les systèmes IT [d’iad] sont plus complexes », affirme-t-il. « Il y a beaucoup de plus de domaines fonctionnels à gérer, en particulier autour de nombreux flux financiers. Ces éléments sont pour la plupart critiques ».

Cela réclame, selon Armand Saghri, de déployer un système hautement disponible. « Si les systèmes sont “off” pendant une journée, il y a un impact majeur pour notre réseau de conseillers qui perdent ainsi leur outil de travail », illustre-t-il.

Dès son arrivée, Armand Saghri a participé à la migration des systèmes d’iad d’un cloud privé vers AWS. Une opération qu’il avait déjà expérimentée chez Altice Media.

« Nous avions des VM et des instances physiques sur ce cloud privé. Le système était assez figé et un peu vieillissant », explique le responsable.

Aussi, iad avait besoin d’une supervision plus simple pour son SI. « Quand il y avait un incident, les développeurs devaient s’appuyer sur les Ops pour analyser les logs et l’état de santé des machines », note Armand Saghri.

Dans cet effort, le responsable Cloud & Operations a été missionné pour mettre en place un outil de supervision le plus complet possible. « Nous voulions trouver un outil cloud native qui nous permettrait de nous orienter vers l’observabilité », déclare Armand Saghri. « Nous voulions donner à une large population, pas uniquement aux Ops, un état de santé en temps réel de nos applications et de nos features ».

L’idée n’était pas seulement de surveiller de potentiels problèmes IT, mais aussi les opérations de l’entreprise.

Autre enjeu, la simplification de la remontée des incidents. Lorsque les conseillers immobiliers rencontrent un problème sur la plateforme, ils peuvent solliciter le back-office d’iad, impliquant « un parcours classique de résolution d’incidents (qualification par un chef de projet, prise en charge par l’équipe technique et déploiement d’un correctif si nécessaire) ».

Les responsables IT souhaitaient mettre en place un système plus proactif afin de détecter les incidents avant que les utilisateurs de la plateforme ne les constatent.

Armand Saghri avait déjà une plateforme en tête, mais a également testé les solutions de Coralogic et de Dynatrace. « Le panel d’outils offert par Datadog est beaucoup plus complet », estime le responsable. « Nous voulions utiliser le Real User Monitoring et les fonctions de sécurité qui ne sont pas aussi mûres dans les solutions des concurrents ».

Surtout, Armand Saghri et certains membres de son équipe étaient déjà des habitués de Datadog. « Je maîtrise cette solution », considère le responsable.

Dans ses expériences précédentes, le déploiement de Datadog avait favorisé la coopération entre les « devs et les ops », selon lui.

Convaincre les développeurs

Il y avait tout de même un enjeu de taille à relever. Pendant la migration vers le cloud d’AWS, les Ops ont mis en place Datadog, ses agents et effectuer les configurations nécessaires.

« Nous nous sommes dit : “si nous voulons pratiquer l’observabilité, il va falloir le faire en coopération avec les développeurs” », indique Armand Saghri.

Pour déployer les fonctionnalités APM, il fallait instrumenter le code, configurer correctement les logs au format JSON et y inclure du contexte. « Tout ce que les développeurs loggent nous sert à mettre en place des métriques que l’état de santé des applications et des features ».

Si cela ressemble à une formalité technique supplémentaire, c’était loin d’être le cas. Elle impliquait une conduite du changement dans les habitudes de travail et donc de convaincre du bien-fondé de l’opération. Armand Saghri s’est dit que le meilleur moyen pour ce faire était d’apporter une preuve par l’exemple.

« Nous avions un projet à mener en parallèle », déclare le responsable. « Nous l’avons fait dans une stack “full serverless” avec un développeur habitué de Datadog en respectant tous les éléments d’observabilité que nous avions dans notre cahier des charges ».

Ce travail a été présenté aux développeurs, en sus des métriques affichées dans les tableaux de bord de Datadog.

« Nous avons montré comment obtenir une visibilité des performances à chaque étape du code, comment suivre précisément les requêtes envoyées à la base de données, et les performances associées », raconte-t-il. « Nous avons configuré les messages d’erreur pour qu’ils soient directement envoyés vers le canal de discussion de la squad de développeurs concernés et vers le Pagerduty des Ops ».

Une présentation qui a fait mouche. Les développeurs n’avaient pas l’habitude d’aborder les déploiements sous cet angle et d’aller si loin dans l’observabilité. « Eux s’assuraient avant tout que leur code passe les tests QA. Nous avons essayé d’aller plus loin en évaluant les performances, en identifiant ce qui peut être optimisé. iad est en pleine croissance, beaucoup de features sont lancées. Si nous ne nous sommes pas vigilant sur ces points, notre dette technique va s’alourdir ».

Les développeurs ont mis la main à la patte pour la mise en place des tableaux de bord et ont fait « beaucoup d’efforts » sur l’implémentation des logs. « “Logger” proprement est sans doute le plus gros enjeu pour les développeurs. Cela demande de réfléchir à des métriques spécifiques aux métiers et trouver comment les exposer à travers les logs et les événements ».

Ce « chantier » a eu l’effet escompté : rapprocher les développeurs des opérateurs. « Aujourd’hui, cela influe beaucoup sur les nouvelles features : il y a toujours un Ops et un Dev qui travaillent ensemble sur les sujets liés à l’observabilité, aux performances », assure Armand Saghri. « Du fait de cette démarche, lorsqu’une fonctionnalité est déployée, elle rencontre beaucoup moins de problèmes ».

Cela implique également de penser à la supervision dès la conception du code. « Je dis régulièrement que l’observabilité, c’est l’affaire de tous : que ce soient les développeurs, les ops ou les responsables produit. Cela porte grandement ses fruits », estime le responsable Cloud & Operations.

Une culture que les responsables souhaitent continuer à diffuser dans les équipes. 

Des routines pour rapprocher les développeurs et les Ops

Les Ops, de leur côté, ont mis en place les moyens pour faire la « chasse » aux faux positifs et obtenir les bonnes alertes. « Là aussi, cela fonctionne bien : dès qu’il y a un problème, nous sommes alertés. Nous utilisons également la fonction “error tracking” de Datadog qui remonte des informations sur les erreurs inédites ».

Les développeurs se sont presque « pris au jeu ». « Dès qu’une erreur est liée à leur périmètre, ça les pique un peu et ils se penchent rapidement sur le problème. C’est très plaisant de voir cela ».

Selon Armand Saghri, l’observabilité n’est atteignable que si les relations entre les développeurs et les opérateurs sont bonnes. « Sinon, ça ne fonctionne pas », lance-t-il.

Il n’y a pas de recette miracle. « Ce n’est pas évident, ce sont des populations qui n’ont pas forcément l’habitude de travailler ensemble ».

 En revanche, quelques pratiques peuvent aider à améliorer la qualité du code. « Nous, nous avons une routine. Nous organisons des points à plusieurs stades : principalement au lancement du développement et au moment de préparer le déploiement », explique Armand Saghri. « Si les critères d’observabilité ne sont pas là, nous pouvons refuser la sortie d’un projet. Ces rituels sont portés par les responsables produit ».

Une routine imposée par le directeur technique.

Ainsi, le gros de l’infrastructure cloud d’iad est supervisé à l’aide de Datadog. Au début du mois de janvier, 50 agents Datadog servaient à collecter les données des hôtes EC2. Le groupe oscille entre 120 et 300 conteneurs ECS (principalement PHP), ainsi que 700 fonctions lambda (principalement en Node.js) tous environnements confondus. L’APM permet de surveiller le comportement du CRM utilisé par les 18 000 conseillers.

Le tout représente un volume d’environ 100 millions de logs par semaine. 

Datadog sert aussi aux métiers

Outre la bonne santé de l’infrastructure et des applications métiers, Datadog est par exemple utilisé pour s’assurer de la bonne gestion des mandats immobiliers.

Ce document est nécessaire pour qu’un agent puisse vendre un bien au nom d’un propriétaire. Il existe différents mandats, par exemple suivant si le vendeur passe par une ou plusieurs agences. Il existe aussi des mandats de recherche : là, un acheteur réclame à un agent de trouver un bien répondant à ses critères.

« Dans Datadog, nous avons des tableaux de bord avec les mandats signés par conseiller, les types de mandats – exclusifs, simples, etc. —, les mandats expirés, annulés ou encore les demandes d’avenants », relate Armand Saghri. « Nous avons des alertes concernant le volume de mandats obtenus par jour. Si le volume est bas, cela peut être le signe d’un problème logiciel chez nous ou nos partenaires ».

FinOps : gérer les dépenses du cloud et… de l’observabilité

Un usage aussi important de la plateforme d’observabilité demande une certaine prudence économique.

« D’abord, nous gérons le FinOps de la facture de Datadog », indique le responsable. « Nous avons mis des alertes pour identifier les taux anormaux d’ingestion de logs. Sur les sessions de RUM, il faut également surveiller la volumétrie tout comme les logs en provenance de nos centaines de conteneurs ».

Sachant que les équipes d’iad gèrent une trentaine de comptes AWS séparés tous liés à Datadog, cela réclame une certaine « hygiène FinOps ».

Armand Saghri n’utilise pas le module dédié au FinOps de la plateforme. « J’ai déjà mes outils », note-t-il. En revanche, Datadog est utilisé pour le bon dimensionnement de l’infrastructure cloud. « Nous faisons cohabiter deux systèmes : un legacy et un nouveau. Nous en déshabillons un pour rhabiller l’autre ».

Datadog permet d’identifier les conteneurs inutilisés. Par exemple, un service d’une quinzaine de conteneurs Docker a été migré vers AWS, mais une fois en production, la plateforme d’observabilité a permis de se rendre compte qu’il n’était pas utilisé depuis environ un an et demi. Elle est également utilisée pour alerter les équipes quand des environnements de développement et de tests sont encore en fonctionnement alors qu’ils devraient être éteints.

À l’avenir, les équipes d’iad espèrent renforcer la gestion des vulnérabilités et leur remédiation à travers Datadog.

Article modifié.  

Pour approfondir sur DevOps et Agilité