Organisation
3. Gouvernance et roadmap
Pour : architectes · managers d’équipe · direction et DSIPrérequis : Avoir lu la leçon 1 du parcours.
Une stratégie d’observabilité sans gouvernance devient vite une collection de projets isolés qui dérivent. Cette leçon donne trois outils : une roadmap par phases, un RACI et une méthode de choix.
La roadmap en quatre phases
Section intitulée « La roadmap en quatre phases »Chaque phase construit sur la précédente. Les durées sont indicatives et se calibrent sur votre périmètre ; l’ordre, lui, se respecte.
flowchart LR P1["Phase 1<br/>Fondations<br/>0 à 3 mois"] --> P2["Phase 2<br/>Structuration<br/>3 à 6 mois"] --> P3["Phase 3<br/>Optimisation<br/>6 à 12 mois"] --> P4["Phase 4<br/>Maturité<br/>12 mois et plus"]
Phase 1, fondations. Inventaire des outils, des sources et des équipes. Choix de l’architecture cible, à partir du business case de la leçon 1. Indicateurs de service (SLI) des services critiques. Deux ou trois gains rapides réalisables en moins de six semaines, pour créer la confiance.
Phase 2, structuration. Instrumentation des services prioritaires avec OpenTelemetry. Objectifs de service (SLO) formalisés. Alertes fondées sur les SLO et le burn rate. RACI signé et organisation de l’astreinte.
Phase 3, optimisation. Traces distribuées sur les parcours critiques. Corrélation entre métriques, logs et traces. Post-mortems sans blâme systématiques sur les incidents majeurs. Pilotage du coût de la télémétrie (voir la leçon 4).
Phase 4, maturité. Configurations, tableaux de bord, alertes et SLO gérés comme du code, versionnés. Automatisation ciblée des réponses aux incidents récurrents. AIOps sur des cas d’usage précis, si les données le permettent (voir la leçon 6). Observabilité des systèmes d’IA s’il y en a (voir la méthode GenAI).
Le RACI de l’observabilité
Section intitulée « Le RACI de l’observabilité »| Activité | DSI | RSSI | Plateforme, SRE | Développement | Métier |
|---|---|---|---|---|---|
| Définir la stratégie d’observabilité | A | C | R | I | C |
| Arbitrer le budget annuel | A | I | R | I | C |
| Instrumenter les services | C | I | R | A | I |
| Définir les SLO d’un service | C | I | C | R | A |
| Conduire la réponse à un incident majeur | I | C | A | R | I |
| Notifier un incident à l’autorité | C | A | R | I | I |
| Produire le reporting de direction | A | C | R | I | C |
| Piloter la roadmap | A | C | R | C | I |
R : réalise. A : rend compte, valide, un seul par ligne. C : consulté avant décision. I : informé après décision.
Deux règles suffisent à éviter la plupart des dérives : un seul A par ligne, sinon personne n’assume et une revue trimestrielle, parce que l’organisation change. La matrice RACI interactive vérifie ces règles et montre la charge de chaque rôle.
Autogéré, SaaS ou mixte : décider avec les mêmes critères
Section intitulée « Autogéré, SaaS ou mixte : décider avec les mêmes critères »Aucune option n’est meilleure dans l’absolu. Ce qui les départage, c’est votre volume, vos compétences, vos contraintes de souveraineté et la façon dont vous instrumentez.
| Critère | Open source autogéré | SaaS | Mixte |
|---|---|---|---|
| Coût au démarrage | infrastructure et temps d’équipe | abonnement, peu d’effort de mise en place | les deux, sur des périmètres séparés |
| Évolution du coût | surtout liée aux personnes et au stockage | surtout liée au volume facturé | à suivre sur les deux lignes |
| Compétences nécessaires | exploitation de la plateforme, astreinte | administration, gouvernance de l’usage | les deux, en plus petit |
| Délai avant les premiers résultats | plus long | souvent plus court | intermédiaire |
| Souveraineté | maîtrisée si l’hébergement l’est | dépend de l’hébergement, du droit applicable et des sous-traitants | à qualifier par flux |
| Dépendance | aux compétences internes | à l’éditeur et à sa grille tarifaire | partagée |
| Coût de sortie | faible si l’instrumentation est standard ; tableaux de bord et alertes à reprendre | faible si l’instrumentation est en OpenTelemetry ; élevé avec des agents et un langage de requête propriétaires | idem, par périmètre |
Le facteur qui pèse le plus sur la réversibilité n’est pas le modèle commercial : c’est l’instrumentation. Une collecte en OpenTelemetry permet de changer de backend sans réinstrumenter ; des agents propriétaires, qu’ils viennent d’un éditeur ou d’un projet open source, lient l’organisation à ce backend.
La grille d’évaluation des solutions : six critères
Section intitulée « La grille d’évaluation des solutions : six critères »Pour comparer deux ou trois options sur une base commune, notez chacune de 1 (faible) à 4 (excellent) sur six critères, pondérés selon votre contexte. La grille interactive fait le calcul et signale les notes éliminatoires.
| Critère | Question à poser | Signal d’alerte |
|---|---|---|
| Portabilité | la solution reçoit-elle et exporte-t-elle les données en OpenTelemetry, dans des formats ouverts ? | format exclusif, export limité |
| Coût de sortie | combien coûte une migration : historique, tableaux de bord, alertes, intégrations ? Est-ce écrit au contrat ? | pas de clause de sortie |
| Souveraineté des données | où sont stockées les données, sous quel droit, avec quels sous-traitants ? | localisation ou sous-traitants opaques |
| Prévisibilité du coût | les simulations à 12 et 36 mois tiennent-elles sur vos volumes réalistes ? | facturation à l’usage sans plafond |
| Support et niveaux de service | délais garantis, langue, interlocuteur dédié, communauté active pour l’open source ? | aucun engagement écrit |
| Écosystème | intégrations avec la chaîne CI/CD, l’ITSM, la sécurité ; API ouverte et documentée ? | intégrations limitées aux produits du même éditeur |
eBPF : instrumenter sans toucher au code
Section intitulée « eBPF : instrumenter sans toucher au code »eBPF est une technologie du noyau Linux qui exécute des programmes vérifiés sur des points d’accroche (appels système, réseau, fonctions). En observabilité, elle permet de capturer le trafic HTTP, gRPC, TCP ou DNS sans modifier les applications. Parmi les projets connus : Cilium et Tetragon pour le réseau et la sécurité, Pixie pour Kubernetes et Beyla, dont Grafana Labs a donné le code à OpenTelemetry en 2025.
Pour le DSI, eBPF réduit le coût d’instrumentation et le délai avant les premières données, surtout sur des applications qu’on ne peut pas modifier. Il demande un noyau Linux récent et des compétences spécifiques, à vérifier outil par outil avant une preuve de concept.
La plateforme comme produit et la sobriété
Section intitulée « La plateforme comme produit et la sobriété »Dans une plateforme interne de développement, l’observabilité devient un service en libre-service : les équipes instrumentent elles-mêmes leurs services avec des modèles prêts à l’emploi, sans attendre l’équipe d’exploitation. Deux conditions : des standards OpenTelemetry partagés et des configurations versionnées comme du code, ce qui apporte au passage l’auditabilité et la réversibilité.
L’observabilité sert aussi la sobriété : elle repère les services surdimensionnés, les requêtes inefficaces, les traitements redondants. Elle a elle-même une empreinte, d’où une règle simple : chaque métrique collectée doit avoir un usage identifié (une alerte, un tableau de bord, une décision). Si votre entreprise publie un rapport de durabilité, les métriques d’infrastructure peuvent alimenter son volet énergie. Le périmètre et le calendrier de la CSRD ont été revus par l’Union en 2025 et 2026 : vérifiez-les pour votre cas.
Six anti-patterns du DSI
Section intitulée « Six anti-patterns du DSI »- Le tableau de bord vide : des outils sans SLO ni indicateurs métier. Remède : partir des cinq indicateurs attendus par la direction, puis les relier à des mesures techniques.
- Le projet invisible : pas de business case, donc un coût sans contrepartie visible, coupé au premier arbitrage. Remède : la leçon 1.
- Le big bang : tout instrumenter d’un coup. Remède : la roadmap par phases et des gains rapides.
- Le RACI fantôme : chacun pense que c’est l’autre. Remède : un RACI signé au plus tard en phase 2, revu chaque trimestre.
- La conformité en mode pompier : découvrir ses obligations au premier contrôle. Remède : intégrer la capacité de preuve à la roadmap (voir la leçon 2).
- L’outil avant la stratégie : choisir une solution avant d’avoir défini les besoins. Remède : stratégie, besoins, liste restreinte, preuve de concept, décision, dans cet ordre.
Atelier : votre roadmap
Section intitulée « Atelier : votre roadmap »Durée : 45 minutes, à deux ou en petit groupe.
- Situez votre organisation sur la grille ci-dessous, puis sur l’auto-diagnostic de maturité du site.
- Identifiez deux ou trois gains rapides réalisables en moins de six semaines.
- Construisez les phases 1 et 2 : objectifs, livrable principal, équipes, budget, dépendances, indicateur de réussite chiffré.
- Remplissez la matrice RACI avec vos rôles réels et repérez les lignes qui font débat.
- Comparez deux options dans la grille d’évaluation.
| Dimension | Niveau 1 | Niveau 2 | Niveau 3 | Niveau 4 |
|---|---|---|---|---|
| Vision | aucune | implicite | documentée et partagée | alignée sur la stratégie du groupe |
| Budget | diffus | identifié | structuré | pluriannuel |
| Gouvernance | pas de RACI | rôles informels | RACI signé | RACI revu chaque trimestre |
| Conformité | rien | en mode pompier | intégrée à la roadmap | preuves produites en continu |
| Communication | pas de reporting | ponctuel | tableau de bord mensuel | revue régulière en comité de direction |
| Outillage | outils disjoints | partiellement intégrés | collecte unifiée OpenTelemetry | configuration gérée comme du code |
Les dimensions les plus basses désignent les priorités. Une organisation au niveau 3 en outillage et au niveau 1 en gouvernance a investi dans la technique sans structurer les responsabilités : c’est le RACI qui passe en premier.
Ma prochaine action : quelle action, pour quelle date, avec qui ?
Pour aller plus loin
Section intitulée « Pour aller plus loin »- Le plan organisation et l’architecture cliquable, avec son calque « qui possède quoi ».
- Le simulateur de coût au Collector.