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. L’objectif : vous permettre de placer chaque rôle au bon endroit selon votre contexte.
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.
Rappel : les 4 types d’équipes
Section intitulée « Rappel : les 4 types d’équipes »Avant la matrice, un rappel des concepts Team Topologies. Si vous maîtrisez déjà le sujet, passez directement à la section suivante.
| 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 | — | X-as-a-Service |
| Cloud Engineer | Platform | Complicated-subsystem | X-as-a-Service |
| DevSecOps | Enabling | Platform | Facilitating, X-as-a-Service |
| FinOps | Enabling | — | Facilitating |
| Ingénieur CI/CD | Platform | Embedded stream-aligned | X-as-a-Service |
| Release Manager | Enabling | Stream-aligned | Facilitating, Collaboration |
| Architecte DevOps | Enabling | — | Facilitating |
Détail par rôle : où et pourquoi
Section intitulée « Détail par rôle : où et pourquoi »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.
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 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.
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 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 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.
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 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 »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 → Stream : X-as-a-Service (self-service, pas de tickets)
- Enabling → 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 »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 → équipe Platform
- Ce qui nécessite un accompagnement → équipe Enabling
- Le reste → intégrer 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 ≠ 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.
Pour aller plus loin
Section intitulée « Pour aller plus loin »Ressources externes :