Quels profils recruter pour l'observabilité ?

Mode de lecture

IngénieurDécideur

Scénario illustratif. Une entreprise publie une offre d’« ingénieur observabilité ». La fiche liste quinze outils, de Prometheus à Kubernetes en passant par trois éditeurs. Trois mois plus tard, la personne recrutée maîtrise ces outils mais passe ses journées à répondre aux incidents, parce que c’est le vrai problème de l’équipe : personne ne répond de la fiabilité du service de paiement. L’entreprise cherchait un SRE et l’ignorait.

Cette page décrit cinq profils, ce qui les distingue et ce qu’on attend d’eux à chaque niveau. Elle ouvre une série sur le recrutement : écrire la fiche de poste, conduire l’entretien et réussir les 90 premiers jours. Le générateur de fiche de poste assemble le tout pour un contexte donné.

Commencer par le problème

Avant de choisir un intitulé, écrivez en une phrase le problème que la personne recrutée doit résoudre. Quelques exemples :

• « Nos équipes ne savent pas pourquoi une requête est lente : il manque des traces et personne ne sait les lire. »
• « Nos incidents durent trop longtemps et personne ne répond de la fiabilité du paiement. »
• « Nos équipes produit montent chacune leur propre supervision ; on paie trois outils et aucun n’est bien tenu. »
• « Nos assistants d’IA répondent mal certains jours et nous ne savons pas le mesurer. »
• « La facture de télémétrie a doublé en un an sans que personne sache pourquoi. »

Chacune de ces phrases appelle un profil différent. Le tableau qui suit fait la correspondance.

Cinq profils

Profil	Le problème qu’il résout	Ce qu’il livre	Ce qu’il n’est pas
Ingénieur observabilité	les équipes ne voient pas ce qui se passe dans leurs services	l’instrumentation, la chaîne de collecte, les tableaux de bord et les alertes de référence, la formation des équipes	la personne qui répond à tous les incidents
SRE (ingénieur de fiabilité)	personne ne répond de la fiabilité d’un service	des objectifs de fiabilité (SLO), une astreinte qui tient, des post-mortems qui produisent des actions, l’automatisation des tâches répétitives	un administrateur système renommé
Ingénieur plateforme	chaque équipe réinvente son outillage	une plateforme interne en libre-service (déploiement, observabilité, sécurité) traitée comme un produit	une équipe qui fait le travail des autres à leur place
Ingénieur observabilité de l’IA	la qualité des réponses d’un modèle n’est pas mesurée	le traçage des appels aux modèles, les évaluations de qualité, le suivi du coût par requête	un data scientist qui entraîne des modèles
Référent FinOps de la télémétrie	le coût de l’observabilité dérive sans explication	un suivi du coût par équipe et par signal, des règles de rétention et d’échantillonnage, un rapport mensuel	un contrôleur de gestion

Le SRE vient du livre de Google Site Reliability Engineering, qui le définit comme ce qui arrive quand on confie l’exploitation à des ingénieurs logiciels. L’ingénierie de plateforme a sa propre définition dans le livre blanc de la CNCF sur les plateformes. Les trois autres intitulés n’ont pas de référence officielle : ils décrivent des besoins qu’on voit apparaître dans les offres d’emploi, avec des contours qui varient d’une entreprise à l’autre.

Ingénieur observabilité

Il rend les services lisibles. Il choisit et maintient la chaîne de collecte, souvent autour d’OpenTelemetry : les SDK dans les applications, le Collector au milieu, le stockage au bout. Il écrit les conventions de nommage, les tableaux de bord de référence et les alertes de base que chaque équipe reprend. Une grande partie de son travail est pédagogique : apprendre aux équipes à instrumenter leur code et à lire une trace.

Le signe qu’il réussit : les équipes produit diagnostiquent seules leurs incidents, sans l’appeler.

SRE

Il répond de la fiabilité d’un ou de plusieurs services. Il négocie avec le produit un objectif de fiabilité (un SLO, par exemple « 99,5 % des paiements aboutissent en moins de deux secondes ») et le budget d’erreur qui en découle, la marge d’échec qu’on s’autorise. Il tient ou organise l’astreinte, anime les post-mortems et réduit le travail répétitif. L’observabilité est son outil principal, pas son livrable.

Le signe qu’il réussit : les incidents se raréfient, durent moins longtemps et ceux qui restent apprennent quelque chose à l’équipe. Voir une astreinte soutenable et le post-mortem sans blâme.

Ingénieur plateforme

Il construit le chemin que les équipes produit empruntent pour déployer et exploiter leurs services : modèles de projet, pipelines, environnements, observabilité intégrée par défaut. Il traite cette plateforme comme un produit, avec des utilisateurs (les développeurs), une feuille de route et une mesure de l’adoption.

Le signe qu’il réussit : un nouveau service arrive en production instrumenté, sans que personne ait eu à y penser.

Ingénieur observabilité de l’IA

Il mesure ce que les métriques classiques ne voient pas : une réponse fausse renvoyée en 200 millisecondes avec un code de succès. Il trace les appels aux modèles (les conventions GenAI d’OpenTelemetry y servent, voir observer un LLM, un RAG et MCP), met en place des évaluations de qualité et suit le coût par requête. Il travaille avec les équipes qui conçoivent les assistants et avec celles qui les exploitent.

Le signe qu’il réussit : une baisse de qualité est détectée avant que les utilisateurs ne s’en plaignent. Le guide de l’observabilité de l’IA détaille le métier.

Référent FinOps de la télémétrie

Il rend le coût de l’observabilité lisible et pilotable. Il relie la facture aux équipes et aux signaux, repère les métriques qui explosent (voir qui fait grossir la facture), fixe des règles de rétention et d’échantillonnage. C’est rarement un poste à temps plein : souvent une mission confiée à un ingénieur observabilité ou à un SRE, en lien avec l’équipe FinOps de l’entreprise.

Le signe qu’il réussit : la finance et les ingénieurs lisent le même rapport mensuel et décident ensemble.

Les compétences par niveau

Les intitulés « junior », « confirmé » et « senior » recouvrent des réalités très différentes d’une entreprise à l’autre. Je recommande de les définir par le périmètre de décision plutôt que par les années d’expérience.

Domaine	Junior : applique	Confirmé : conçoit pour son équipe	Senior : fixe les règles pour plusieurs équipes
Instrumentation	ajoute des métriques et des spans en suivant les conventions	choisit quoi instrumenter dans un service et écrit les conventions de l’équipe	définit les conventions communes et les fait adopter
Collecte et stockage	déploie un Collector à partir d’un modèle	dimensionne la chaîne, règle l’échantillonnage et la cardinalité	arbitre entre architectures, éditeurs et coûts sur plusieurs années
Alertes et SLO	répond à une alerte en suivant la procédure	écrit des alertes sur les symptômes et des SLO avec le produit	fixe la politique d’alerte et de budget d’erreur de l’entreprise
Incidents	participe à la réponse, rédige la chronologie	coordonne un incident, anime le post-mortem	améliore le processus d’incident et forme les coordinateurs
Diagnostic	lit une trace, un tableau de bord, des logs	relie les trois signaux pour trouver une cause	diagnostique des problèmes qui traversent plusieurs systèmes
Communication	explique ce qu’il a fait	forme son équipe, écrit une documentation que d’autres suivent	convainc des équipes qui ne dépendent pas de lui, parle à la direction et à la finance

La dernière ligne compte autant que les autres. Un ingénieur observabilité qui ne sait pas faire adopter ses conventions produit des tableaux de bord que personne n’ouvre.

Un poste ou plusieurs ?

Le nombre de postes dépend de la taille de l’organisation et de son modèle d’équipe. Les repères ci-dessous sont indicatifs, à ajuster selon la criticité des services.

Taille de l’organisation technique	Ce qui fonctionne souvent
moins de 50 ingénieurs	un poste qui couvre l’outillage et la fiabilité, avec une astreinte partagée par les développeurs
50 à 200 ingénieurs	une petite équipe plateforme qui porte l’observabilité, des SRE rattachés aux services les plus critiques
plus de 200 ingénieurs	une équipe observabilité distincte, des SRE par domaine, un référent FinOps de la télémétrie, un profil observabilité de l’IA si des assistants sont en production

Le piège le plus fréquent est le poste unique qui cumule tout : construire l’outillage, tenir l’astreinte de tous les services et répondre aux questions de la finance. L’urgence gagne toujours ; l’outillage n’avance plus.

Recruter ou faire évoluer ?

Le marché de ces profils reste tendu. Avant d’ouvrir un poste, regardez qui pourrait l’occuper en interne. Un administrateur système qui connaît vingt ans d’historique du système d’information, formé à OpenTelemetry et aux SLO, devient souvent un SRE plus utile qu’un recrutement externe. Un développeur qui a instrumenté son propre service est souvent le meilleur ingénieur observabilité possible : il connaît la douleur de l’autre côté.

La leçon 5 du parcours DSI décrit les profils types d’une équipe d’exploitation et les trajectoires qui fonctionnent pour chacun.

Pour aller plus loin

• Comment écrire une fiche de poste d’observabilité ? : la structure, les erreurs fréquentes et deux modèles.
• Comment conduire un entretien ? : questions, exercice pratique et grille d’évaluation.
• Comment réussir les 90 premiers jours ? : l’intégration de la personne recrutée.
• Le générateur de fiche de poste : une fiche et une trame d’entretien adaptées à votre contexte.

PasserellesCe que cette page change au-delà de l'équipe technique.

BusinessValeur, coût, risque

Un recrutement raté coûte des mois de poste vide puis des mois d'intégration. Un problème écrit avant la fiche de poste réduit ce risque pour un effort de quelques heures.

OrganisationQui décide, qui possède

Le profil dépend du modèle d'équipe : une équipe plateforme centrale, des référents dans chaque équipe produit ou un mélange. Voir les modèles d'équipe.

HumainÉquipes, astreinte, compétences

Une grille de compétences écrite sert aussi aux personnes déjà en poste : elle dit ce qu'on attend pour passer au niveau suivant.

MétiersProduit, finance, risque, relation client

Pour les RH : la grille de cette page donne un vocabulaire commun avec les managers techniques, pour les fiches de poste comme pour les entretiens annuels.

Pourquoi des passerelles →