Vous avez lu les fiches de postes DevOps. Vous avez compris les 4 types d'équipes Team Topologies. Mais une question reste : "OK, mais mon SRE, je le mets où ?"
Ce guide répond à cette question avec une matrice claire et des exemples concrets, mise à jour après la sortie de la 2ᵉ édition du livre Team Topologies (2025). L'objectif : vous permettre de placer chaque rôle au bon endroit selon votre contexte, pas selon un dogme théorique.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Positionner chaque rôle DevOps (SRE, Platform Engineer, DevSecOps, FinOps, etc.) dans les 4 types d'équipes Team Topologies
- Identifier les placements alternatifs selon la taille et la maturité de votre organisation
- Repérer les anti-patterns organisationnels les plus fréquents (équipe fourre-tout, SRE pompier)
- Anticiper l'évolution des placements à mesure que l'organisation mûrit
Pourquoi ce guide existe
Section intitulée « Pourquoi ce guide existe »Team Topologies définit 4 types d'équipes, pas des titres de postes. Les rôles DevOps (SRE, Platform Engineer, etc.) sont des compétences qui peuvent s'exercer dans différents types d'équipes selon le contexte.
Le problème : la littérature Team Topologies parle rarement des rôles individuels. Et les fiches de postes DevOps mentionnent rarement leur place dans l'organisation.
Résultat : beaucoup d'organisations créent une "équipe DevOps" fourre-tout qui devient un goulot d'étranglement, exactement ce que Team Topologies cherche à éviter.
Ce guide comble ce vide avec une approche pragmatique et actualisée.
Rappel : les 4 types d'équipes Team Topologies
Section intitulée « Rappel : les 4 types d'équipes Team Topologies »Avant la matrice, un rappel des concepts Team Topologies. Si vous maîtrisez déjà le sujet, passez directement à la section suivante.
La 2ᵉ édition du livre (Skelton et Pais, 2025) affine légèrement le vocabulaire : le terme "équipe Platform" devient parfois "platform grouping" pour souligner que la plateforme peut elle-même être composée de plusieurs équipes fractales. Ce guide continue d'utiliser "équipe Platform" pour rester cohérent avec le reste du site, mais gardez cette nuance en tête si vous lisez la littérature récente.
| Type | Rôle | % typique | Exemple concret |
|---|---|---|---|
| Stream-aligned | Livrer de la valeur métier end-to-end | 60-80% | Équipe "Checkout", équipe "Mobile App" |
| Platform | Fournir des services en self-service | 10-20% | Équipe qui maintient le Kubernetes interne |
| Enabling | Transférer des compétences (temporaire) | 5-15% | Équipe SRE qui forme les devs à l'observabilité |
| Complicated-subsystem | Gérer une complexité technique irréductible | 0-10% | Équipe moteur de recommandation ML |
Principe clé : les équipes Platform, Enabling et Complicated-subsystem existent pour servir les équipes Stream-aligned, pas l'inverse. Si une équipe Platform génère plus de travail qu'elle n'en absorbe, elle rate sa mission.
La matrice de placement des rôles
Section intitulée « La matrice de placement des rôles »Voici où chaque rôle DevOps s'intègre le plus naturellement dans Team Topologies :
| Rôle | Placement principal | Placement alternatif | Mode d'interaction typique |
|---|---|---|---|
| SRE | Enabling | Platform, Embedded stream-aligned | Facilitating, X-as-a-Service |
| Platform Engineer | Platform | Aucun | X-as-a-Service |
| Cloud Engineer | Platform | Complicated-subsystem | X-as-a-Service |
| DevSecOps | Enabling | Platform | Facilitating, X-as-a-Service |
| FinOps | Enabling | Aucun | Facilitating |
| Ingénieur CI/CD | Platform | Embedded stream-aligned | X-as-a-Service |
| Release Manager | Enabling | Stream-aligned | Facilitating, Collaboration |
| Architecte DevOps | Enabling | Aucun | Facilitating |
Détail par rôle : où et pourquoi
Section intitulée « Détail par rôle : où et pourquoi »La matrice ci-dessus donne le placement principal, mais chaque rôle mérite une explication : pourquoi cet endroit précis, et à partir de quel signal envisager un placement alternatif. Les sous-sections suivantes détaillent, rôle par rôle, ce qui change concrètement selon le type d'équipe choisi.
Site Reliability Engineer (SRE)
Section intitulée « Site Reliability Engineer (SRE) »Le SRE est le rôle le plus polymorphe de l'écosystème DevOps. Son placement dépend fortement de la maturité de l'organisation en matière de fiabilité.
Quand : Organisation en transformation, équipes produit peu matures sur la fiabilité.
Ce que fait le SRE :
- Accompagne les équipes stream-aligned à définir leurs SLO
- Forme aux pratiques d'incident management et de post-mortems
- Aide à mettre en place l'observabilité
- Transfère les compétences on-call aux équipes produit
Mode d'interaction : Facilitating (temporaire, quelques semaines à quelques mois par équipe)
Objectif : Rendre les équipes stream-aligned autonomes sur la fiabilité. Le SRE ne fait pas le travail à leur place, il les rend capables.
Quand : Grande organisation avec beaucoup d'équipes stream-aligned à servir.
Ce que fait le SRE :
- Construit et maintient l'infrastructure d'observabilité (Prometheus, Grafana, alerting)
- Fournit des templates de SLO et dashboards standardisés
- Gère les outils d'incident management (PagerDuty, OpsGenie)
- Maintient les runbooks partagés
Mode d'interaction : X-as-a-Service (les équipes consomment sans intervention humaine)
Attention : Le SRE dans une équipe Platform ne doit pas devenir le "pompier de service" qui éteint les feux des autres. Il construit des outils qui permettent aux équipes de gérer leur propre fiabilité.
Quand : Équipe sur un système critique (paiement, santé, finance) nécessitant une expertise fiabilité dédiée.
Ce que fait le SRE :
- Fait partie intégrante de l'équipe produit
- Participe aux sprints et aux décisions d'architecture
- Gère les astreintes avec l'équipe
- Pilote les post-mortems
Mode d'interaction : Membre à part entière de l'équipe (pas d'interaction externe)
Risque : Créer une dépendance où l'équipe n'apprend jamais à gérer sa propre fiabilité. À utiliser avec parcimonie.
Platform Engineer
Section intitulée « Platform Engineer »Le Platform Engineer a un placement évident : équipe Platform. C'est littéralement son domaine.
Ce que fait le Platform Engineer :
- Construit l'Internal Developer Platform (IDP)
- Définit les Golden Paths (chemins standardisés vers la production)
- Maintient le portail développeur (Backstage, Port)
- Crée les templates de projets et les CLI internes
Mode d'interaction : X-as-a-Service (toujours)
Principe fondamental : Si les développeurs doivent créer un ticket pour utiliser la plateforme, le Platform Engineer a échoué. L'objectif est le self-service total. Le cabinet Gartner estimait que 80% des grandes organisations logicielles disposeraient d'une équipe de platform engineering en 2026, contre 45% en 2022 : ce rôle n'est plus un pari, c'est devenu une fonction standard.
Cloud Engineer
Section intitulée « Cloud Engineer »Le Cloud Engineer se place généralement dans une équipe Platform, parfois dans une équipe Complicated-subsystem.
Ce que fait le Cloud Engineer :
- Gère l'infrastructure cloud partagée (VPC, networking, IAM)
- Maintient les modules Terraform réutilisables
- Fournit des environnements pré-configurés
- Optimise les coûts et la sécurité au niveau infrastructure
Mode d'interaction : X-as-a-Service
Les équipes stream-aligned consomment l'infrastructure via des modules Terraform ou des APIs sans avoir besoin de comprendre les détails.
Quand : Infrastructure très complexe nécessitant une expertise pointue (multi-cloud, edge computing, réseaux hybrides).
Ce que fait le Cloud Engineer :
- Gère un sous-système d'infrastructure spécialisé
- Expose des APIs simplifiées pour les autres équipes
- Absorbe la complexité que les autres équipes ne peuvent pas gérer
Mode d'interaction : X-as-a-Service
Ce placement est rare et réservé aux très grandes organisations avec des besoins infrastructure hors du commun.
DevSecOps Engineer
Section intitulée « DevSecOps Engineer »Le DevSecOps Engineer se place principalement en équipe Enabling, parfois en équipe Platform.
Ce que fait le DevSecOps :
- Forme les équipes stream-aligned aux pratiques de sécurité
- Accompagne l'adoption des scanners SAST, DAST, SCA
- Aide à remédier les vulnérabilités critiques
- Transfère les compétences de threat modeling
Mode d'interaction : Facilitating
Objectif : Chaque équipe stream-aligned devient capable de gérer sa propre sécurité. Le DevSecOps intervient ponctuellement, pas en permanence.
Ce que fait le DevSecOps :
- Intègre les scanners de sécurité dans les pipelines CI/CD
- Maintient les policies OPA/Gatekeeper
- Gère les secrets management (Vault)
- Fournit des templates sécurisés par défaut
Mode d'interaction : X-as-a-Service
La sécurité est automatisée et transparente : les développeurs n'ont pas besoin de penser à la sécurité, elle est intégrée par défaut.
FinOps Practitioner
Section intitulée « FinOps Practitioner »Le FinOps Practitioner se place presque toujours en équipe Enabling.
Pourquoi pas Platform ? Parce que le FinOps n'est pas un service technique à consommer. C'est un changement de comportement qui nécessite un accompagnement humain, au moins tant que les pratiques de tagging et d'allocation ne sont pas ancrées dans les habitudes des équipes.
Ce que fait le FinOps :
- Forme les équipes à comprendre leurs coûts
- Accompagne la mise en place du tagging et de l'allocation
- Anime les revues de coûts avec les équipes
- Aide à définir des budgets et des alertes
Mode d'interaction : Facilitating
Objectif : Chaque équipe stream-aligned devient responsable de ses coûts cloud. Le FinOps fournit la visibilité et l'accompagnement, pas le contrôle.
Ingénieur CI/CD
Section intitulée « Ingénieur CI/CD »L'Ingénieur CI/CD se place généralement dans une équipe Platform, parfois embedded dans une équipe stream-aligned.
Ce que fait l'Ingénieur CI/CD :
- Construit et maintient les pipelines partagés
- Crée des templates de pipeline réutilisables
- Gère les runners et l'infrastructure CI/CD
- Optimise les temps de build
Mode d'interaction : X-as-a-Service
Les équipes stream-aligned utilisent des pipelines standardisés sans avoir à les maintenir.
Quand : Équipe avec des besoins CI/CD très spécifiques (monorepo complexe, release particulière).
Ce que fait l'Ingénieur CI/CD :
- Construit des pipelines sur-mesure pour l'équipe
- Optimise les workflows spécifiques au projet
- Participe aux sprints de l'équipe
Ce placement est rare et généralement temporaire.
Release Manager
Section intitulée « Release Manager »Le Release Manager se place en équipe Enabling ou directement dans une équipe stream-aligned.
Quand : Organisation avec plusieurs équipes stream-aligned qui doivent se coordonner pour les releases.
Ce que fait le Release Manager :
- Coordonne les fenêtres de release entre équipes
- Organise les go/no-go meetings
- Gère les dépendances de release
- Communique avec les parties prenantes
Mode d'interaction : Facilitating ou Collaboration
Quand : Équipe autonome avec un flux de release complexe (produit B2B, logiciel on-premise).
Ce que fait le Release Manager :
- Membre à part entière de l'équipe
- Gère le cycle de release du produit
- Interface avec le support et les clients
Le Release Manager est alors spécialisé sur un seul produit.
Architecte DevOps
Section intitulée « Architecte DevOps »L'Architecte DevOps se place en équipe Enabling, toujours.
Ce que fait l'Architecte DevOps :
- Définit la vision et la roadmap de transformation
- Établit les standards et les patterns
- Coache les équipes sur les bonnes pratiques
- Débloque les situations complexes
- Communique le ROI aux dirigeants
Mode d'interaction : Facilitating
Particularité : L'Architecte DevOps n'est pas dans une équipe Enabling dédiée. Il est l'équipe Enabling, souvent seul ou avec 1-2 personnes.
Patterns d'organisation par taille
Section intitulée « Patterns d'organisation par taille »Le bon placement d'un rôle dépend autant de la taille de l'organisation que de sa maturité. Une pratique pertinente pour 15 développeurs devient un frein à 150, et inversement, structurer trop tôt crée de la bureaucratie inutile. Voici comment les rôles DevOps se répartissent à chaque palier, avec les signaux qui indiquent qu'il est temps de passer au palier suivant.
Startup (moins de 20 développeurs)
Section intitulée « Startup (moins de 20 développeurs) »À cette taille, Team Topologies est souvent overkill. L'enjeu n'est pas la structure organisationnelle, c'est la survie du produit. Mais voici comment les rôles DevOps se répartissent naturellement :
Pas d'équipe Platform dédiée. Un ou deux développeurs "DevOps-minded" gèrent l'infrastructure et les pipelines à temps partiel, souvent 20-30% de leur temps. C'est acceptable tant que cette dette organisationnelle ne ralentit pas l'équipe.
Signaux qu'il est temps de structurer :
- Les développeurs passent plus d'une demi-journée par semaine sur des problèmes d'infra
- Chaque nouvelle recrue met plus d'une journée à avoir un environnement fonctionnel
- Les déploiements échouent régulièrement par manque de standardisation
Scale-up (20-100 développeurs)
Section intitulée « Scale-up (20-100 développeurs) »C'est la phase critique où la structure informelle ne suffit plus. Les équipes stream-aligned commencent à réinventer la roue chacune de leur côté : pipelines similaires mais incompatibles, configurations Kubernetes divergentes, pratiques de monitoring hétérogènes.
L'équipe Platform (3-6 personnes) centralise ce qui était dispersé : Platform Engineers, Cloud Engineers et Ingénieurs CI/CD travaillent ensemble pour fournir une expérience développeur cohérente.
L'équipe Enabling (2-4 personnes) comble les lacunes de compétences : SRE, DevSecOps et Architecte DevOps accompagnent les équipes stream-aligned pour qu'elles deviennent autonomes sur la fiabilité, la sécurité et les bonnes pratiques.
Les interactions sont claires :
- Platform vers Stream : X-as-a-Service (self-service, pas de tickets)
- Enabling vers Stream : Facilitating (accompagnement temporaire, transfert de compétences)
Enterprise (100+ développeurs)
Section intitulée « Enterprise (100+ développeurs) »À cette échelle, une seule équipe Platform ne suffit plus. On parle de département Platform avec des équipes spécialisées : Core Platform (infrastructure), Developer Experience (CI/CD, tooling), Observability, Data Platform, Release Management.
Les équipes stream-aligned sont regroupées par domaine métier : Payments, Catalog, Logistics, Mobile... Chaque domaine peut avoir 3-5 équipes stream-aligned qui partagent un contexte métier.
Les équipes Enabling se spécialisent :
- SRE Guild : diffuse les pratiques de fiabilité à travers l'organisation
- Security Champions : anime le réseau de champions sécurité dans chaque équipe
- Architecture Office : maintient la cohérence technique globale
- CoE DevOps : définit les standards et accompagne les transformations
Attention à la bureaucratie : à cette taille, le risque est de créer des silos et des processus qui ralentissent au lieu d'accélérer. La règle d'or reste : si une équipe stream-aligned doit attendre une autre équipe pour délivrer de la valeur, quelque chose ne va pas.
Anti-patterns à éviter
Section intitulée « Anti-patterns à éviter »Un mauvais placement ne se voit pas immédiatement : il se traduit d'abord par des frictions diffuses (tickets qui s'accumulent, astreintes qui épuisent, releases qui ralentissent) avant de devenir un vrai problème organisationnel. Voici les quatre anti-patterns les plus fréquents, avec le symptôme qui doit alerter et la correction à apporter.
1. L'équipe "DevOps" fourre-tout
Section intitulée « 1. L'équipe "DevOps" fourre-tout »Symptôme : Une équipe appelée "DevOps" qui fait CI/CD, infra, sécurité, monitoring, et répond aux tickets des développeurs.
Problème : C'est un goulot d'étranglement, pas une équipe Platform. Les développeurs attendent au lieu de faire.
Solution : Séparer les responsabilités selon Team Topologies :
- Ce qui peut être en self-service vers l'équipe Platform
- Ce qui nécessite un accompagnement vers l'équipe Enabling
- Le reste s'intègre dans les équipes stream-aligned
2. Le SRE "pompier de service"
Section intitulée « 2. Le SRE "pompier de service" »Symptôme : Les SRE passent leur temps à éteindre les feux des équipes produit au lieu de construire de l'automatisation. Ils sont appelés à chaque incident, participent à tous les post-mortems, et leur backlog de projets d'amélioration ne diminue jamais.
Problème : Les équipes stream-aligned n'apprennent jamais à gérer leur fiabilité. Pire, elles développent une dépendance : "on peut shipper ce code fragile, les SRE gèreront en prod".
Solution : Positionner les SRE en Enabling avec une mission claire : transférer les compétences, pas faire le travail à la place. Concrètement :
- Le SRE accompagne l'équipe pendant 2-3 sprints maximum
- L'équipe stream-aligned prend ensuite l'astreinte de son propre service
- Le SRE peut revenir si les SLO se dégradent significativement
3. Le Platform Engineer qui fait du support
Section intitulée « 3. Le Platform Engineer qui fait du support »Symptôme : L'équipe Platform passe 80% de son temps à répondre à des tickets.
Problème : La plateforme ne s'améliore pas, les développeurs restent dépendants.
Solution : Chaque ticket récurrent doit devenir une automatisation. Mesurer le ratio build/run et viser 70% build minimum.
4. Le DevSecOps qui bloque les releases
Section intitulée « 4. Le DevSecOps qui bloque les releases »Symptôme : La sécurité est un checkpoint humain qui ralentit le flux. Chaque release attend une "validation sécu" qui prend 2-5 jours. Les développeurs contournent le processus pour les "urgences".
Problème : La sécurité est perçue comme un obstacle, pas un facilitateur. Les développeurs et la sécurité sont en opposition au lieu de collaborer.
Solution : Intégrer la sécurité dans la plateforme (scans automatiques, policies as code). Le DevSecOps devient Enabling (formation) au lieu de gatekeeper. Concrètement :
- Les scans SAST/DAST/SCA s'exécutent automatiquement dans le pipeline
- Les vulnérabilités critiques bloquent le pipeline, pas un humain
- Le DevSecOps forme les développeurs à corriger eux-mêmes
- La validation humaine reste nécessaire uniquement pour les cas complexes (nouveau service exposé publiquement, données sensibles)
Évolution des placements
Section intitulée « Évolution des placements »Les rôles ne restent pas figés. Voici des évolutions typiques :
-
Phase initiale : tout embedded
Dans une startup, tous les rôles sont intégrés aux équipes de développement. Pas de distinction formelle.
-
Création de l'équipe Platform
Quand les développeurs passent trop de temps sur l'infra/CI/CD, on extrait ces compétences dans une équipe dédiée. Les Platform Engineers et Cloud Engineers émergent.
-
Ajout des Enabling
Quand les équipes stream-aligned manquent de compétences (fiabilité, sécurité, coûts), on crée des équipes Enabling temporaires avec SRE, DevSecOps, FinOps.
-
Maturation : du Enabling au Platform
Ce qui était accompagnement humain devient automatisation. Le SRE Enabling devient SRE Platform (observabilité as-a-service). Le DevSecOps Enabling devient security policies dans la plateforme.
-
État cible : équipes stream-aligned autonomes
Les équipes stream-aligned gèrent elles-mêmes leur fiabilité, sécurité et coûts. Platform fournit les outils. Enabling intervient ponctuellement pour les nouveaux sujets.
À retenir
Section intitulée « À retenir »Rôles différents des types d'équipes
SRE, Platform Engineer, DevSecOps sont des compétences. Stream-aligned, Platform, Enabling sont des types d'équipes. Un même rôle peut se placer différemment selon le contexte.
Le contexte décide
Il n'y a pas de placement universel. La taille de l'organisation, la maturité des équipes et les besoins métier déterminent où placer chaque rôle.
Enabling = temporaire
Une équipe Enabling réussie se rend obsolète. Si vos SRE ou DevSecOps sont en mode Enabling permanent, quelque chose ne va pas.
Platform = self-service
Si les développeurs doivent créer des tickets pour utiliser la plateforme, c'est un échec. L'objectif est l'autonomie totale.
Le vocabulaire évolue
La 2ᵉ édition du livre Team Topologies (2025) parle parfois de "platform grouping" plutôt que d'équipe Platform unique. Le principe reste le même : servir les équipes stream-aligned en self-service.
L'adoption s'est généralisée
Selon Gartner, 80% des grandes organisations logicielles disposent aujourd'hui d'une équipe de platform engineering, contre 45% quatre ans plus tôt. Ce n'est plus une option, c'est un standard.
FAQ : questions fréquentes
Section intitulée « FAQ : questions fréquentes »Pour aller plus loin
Section intitulée « Pour aller plus loin »Ressources externes :