Organisation
Modèles d'équipe pour l'observabilité
Pour : architectes · managers d’équipe · direction et DSIPrérequis : Notions de base sur l'observabilité et sur l'organisation des équipes informatiques.
À mon avis, une plateforme d’observabilité échoue rarement pour des raisons purement techniques. Elle dure quand trois questions ont une réponse écrite : qui construit la plateforme, qui possède ce qui y entre et qui paie. Le modèle d’équipe est la façon dont une organisation répond à ces trois questions en même temps.
Cet article compare trois modèles, propose une frontière de propriété et une matrice RACI, puis traite du financement et des signaux qui indiquent qu’il faut changer de modèle.
Un vocabulaire commun : Team Topologies
Section intitulée « Un vocabulaire commun : Team Topologies »Le livre Team Topologies de Matthew Skelton et Manuel Pais (IT Revolution, 2019) fournit un vocabulaire utile pour ce sujet. Il décrit quatre types d’équipes et trois modes d’interaction :
| Type d’équipe | Rôle dans l’observabilité |
|---|---|
| Équipe alignée sur un flux (stream-aligned) | une équipe produit qui livre un service et l’exploite |
| Équipe plateforme (platform) | fournit la collecte, le stockage, les tableaux de bord types et l’alerting en libre-service |
| Équipe facilitatrice (enabling) | aide temporairement les équipes produit à monter en compétence, par exemple sur l’instrumentation OpenTelemetry |
| Équipe sous-système complexe (complicated-subsystem) | rarement nécessaire pour l’observabilité, sauf composant très spécialisé |
Les modes d’interaction sont la collaboration, le service (X-as-a-Service) et la facilitation. La correspondance avec l’observabilité est ma lecture du livre, pas une définition des auteurs ; je la recommande parce qu’elle oblige à dire comment les équipes travaillent ensemble et pas seulement qui fait quoi.
Trois modèles
Section intitulée « Trois modèles »L’équipe plateforme. Une équipe dédiée construit et exploite la plateforme comme un produit : pipelines de collecte, stockage, visualisation, alerting, modèles d’instrumentation. Les équipes produit la consomment en libre-service. Le livre blanc de la CNCF sur les plateformes (CNCF Platforms White Paper) insiste sur cette approche produit : des utilisateurs internes, des besoins recueillis, une expérience soignée.
Le centre d’excellence. Un petit groupe transverse définit les standards (conventions de nommage, conventions sémantiques, règles d’alerte, gabarits de post-mortem), forme et conseille. Il n’exploite pas forcément la plateforme, qui peut être un service acheté ou gérée par l’exploitation. Son pouvoir repose sur l’expertise et le soutien de la direction.
Le modèle fédéré. Un noyau central exploite le socle commun et chaque équipe produit désigne un référent observabilité, qui consacre une part explicite de son temps à l’instrumentation, aux SLO et aux tableaux de bord de son équipe. Les référents forment une communauté animée par le noyau.
| Équipe plateforme | Centre d’excellence | Fédéré | |
|---|---|---|---|
| Ce qui est centralisé | l’outil et son exploitation | les standards et l’expertise | le socle et l’animation |
| Point fort | cohérence, économies d’échelle, libre-service | démarrage léger, diffusion des bonnes pratiques | proximité du métier, adoption par les pairs |
| Risque principal | devenir un goulet d’étranglement ou un guichet de tickets | produire des standards que personne n’applique | hétérogénéité, référents sans temps réel |
| Quand le choisir, à mon avis | plusieurs dizaines d’équipes, besoin de maîtrise des coûts | démarrage, outil acheté, peu d’équipes | organisation déjà décentralisée, équipes produit autonomes |
| Condition de réussite | un responsable produit de la plateforme et des indicateurs d’usage | un mandat de la direction et des standards vérifiés automatiquement | du temps de référent écrit dans les objectifs |
Ces modèles ne s’excluent pas. Une trajectoire fréquente consiste à démarrer en centre d’excellence, à constituer une équipe plateforme quand le volume le justifie, puis à fédérer via des référents. Je recommande de nommer le modèle actuel et le modèle visé, même s’ils sont hybrides : une organisation qui ne sait pas dans quel modèle elle est ne sait pas qui décide.
La frontière de propriété
Section intitulée « La frontière de propriété »Quel que soit le modèle, je recommande d’écrire une frontière simple entre ce que possède la plateforme et ce que possèdent les équipes produit. Le principe « vous le construisez, vous l’exploitez », formulé par Werner Vogels dans un entretien à ACM Queue en 2006, s’applique aussi à l’observabilité : l’équipe qui livre un service possède ses signaux.
| Possédé par la plateforme | Possédé par l’équipe produit |
|---|---|
| Collecteurs, pipelines, stockage, rétention par défaut | instrumentation de son code et de ses dépendances |
| Disponibilité et performance de la plateforme elle-même | SLI et SLO de ses services, avec le métier |
| Modèles d’instrumentation, bibliothèques, tableaux de bord types | tableaux de bord spécifiques à son service |
| Règles d’alerte génériques (plateforme, infrastructure partagée) | alertes sur ses symptômes et procédures associées |
| Contrats de données et budgets de cardinalité par défaut | respect de son contrat de données et demandes de dérogation |
| Mesure et affichage des coûts par équipe | arbitrages de coût sur ses propres signaux |
La plateforme a elle-même des SLO : disponibilité de l’ingestion, délai d’apparition d’un signal, latence des requêtes. Une plateforme d’observabilité qui ne s’observe pas perd la confiance des équipes au premier trou de données.
Une matrice RACI opérationnelle
Section intitulée « Une matrice RACI opérationnelle »La leçon 3 du parcours DSI propose un RACI de direction. Celui-ci descend d’un niveau, vers les activités quotidiennes, pour un modèle à équipe plateforme avec référents (exemple illustratif, à adapter en atelier).
| Activité | Équipe plateforme | Équipe produit | Référent observabilité | Sécurité | Métier |
|---|---|---|---|---|---|
| Exploiter la plateforme et ses SLO | A, R | I | I | C | I |
| Instrumenter un nouveau service | C | A | R | I | I |
| Définir le SLO d’un parcours client | C | R | C | I | A |
| Créer une alerte d’appel | C | A | R | I | I |
| Ajouter un attribut à forte cardinalité | A | R | C | I | I |
| Collecter une donnée potentiellement personnelle | C | R | C | A | I |
| Arbitrer un dépassement de budget de télémétrie | R | C | C | I | A |
| Faire évoluer les standards d’instrumentation | A, R | C | C | C | I |
Rappel des deux règles qui comptent : un seul A par ligne et une revue au moins annuelle. La matrice RACI interactive vérifie la première et montre la charge de chaque rôle.
Financer
Section intitulée « Financer »Trois modes de financement coexistent, qui recoupent la progression FinOps décrite dans la leçon 4 du parcours DSI :
| Mode | Principe | Ce qu’il suppose |
|---|---|---|
| Budget central | la DSI porte toute la dépense | rien de plus qu’un budget ; mais aucune équipe n’est incitée à réduire ses signaux |
| Affichage des coûts (showback) | chaque équipe voit ce qu’elle consomme | des étiquettes d’équipe imposées à l’ingestion et une revue mensuelle |
| Refacturation (chargeback) | chaque équipe paie sa consommation | une mesure fiable, acceptée et un mécanisme budgétaire interne |
Je recommande de commencer par l’affichage des coûts dès que la plateforme est partagée, même si la refacturation n’est jamais mise en place. Voir sa consommation suffit souvent à changer les comportements. Je recommande aussi de financer le socle (exploitation, standards, formation) en central : le refacturer pousse les équipes à le contourner.
Les signaux qu’il faut changer de modèle
Section intitulée « Les signaux qu’il faut changer de modèle »| Signal observé | Ce qu’il suggère |
|---|---|
| Le délai pour obtenir un premier tableau de bord sur un nouveau service s’allonge | la plateforme est devenue un guichet ; investir dans le libre-service |
| Plusieurs équipes ont monté leur propre pile | les besoins ne sont pas couverts ou pas entendus ; recueillir les besoins comme un produit |
| Les standards existent mais les revues de code ne les vérifient pas | le centre d’excellence n’a pas de levier ; automatiser la vérification en intégration continue |
| Les référents n’ont plus de temps pour ce rôle | le modèle fédéré n’est pas financé ; écrire leur temps dans les objectifs |
| Personne ne sait répondre à « qui possède ce signal ? » | la frontière de propriété n’est pas écrite |
Les indicateurs de pilotage d’une plateforme traitée comme un produit (délai avant le premier tableau de bord, satisfaction des développeurs, taux de libre-service, coût par service instrumenté) sont détaillés dans la leçon 5 du parcours DSI.
Liste de contrôle
Section intitulée « Liste de contrôle »- Le modèle actuel et le modèle visé sont nommés
- La frontière de propriété plateforme et équipes produit est écrite
- La plateforme a ses propres SLO et les publie
- Le RACI opérationnel a été construit en atelier et compte un seul A par ligne
- Chaque équipe voit ce qu’elle consomme
- Le socle commun est financé en central
- Les rôles (ingénieur plateforme, responsable produit, référent) ont une fiche de poste
- Les signaux de changement de modèle sont revus au moins une fois par an
Pour aller plus loin
Section intitulée « Pour aller plus loin »- Ce que la plateforme autorise à collecter se décide dans la gouvernance de la télémétrie.
- L’auto-diagnostic de maturité met en évidence les écarts entre plans, par exemple une pile avancée que personne ne possède.
- L’architecture cliquable propose un calque « qui possède quoi ».
- Matthew Skelton et Manuel Pais, Team Topologies: Organizing Business and Technology Teams for Fast Flow, IT Revolution, 2019 ; présentation des concepts sur teamtopologies.com.
- CNCF TAG App Delivery, Platforms White Paper.
- Jim Gray, A Conversation with Werner Vogels, ACM Queue, 2006.