Read in English

Où placer les rôles DevOps dans Team Topologies ?

30 min
Quiz · 6 questions

Par Stéphane Robert mis à jour le 13 octobre 2026

Améliorer cette page

Que voulez-vous signaler ?

L’issue s’ouvre déjà remplie avec le titre et l’adresse de cette page.

SRE, Platform Engineer, DevSecOps, FinOps : les rôles DevOps se multiplient, et une question revient dès qu'on connaît les 4 types d'équipes Team Topologies : "OK, mais mon SRE, je le mets où ?"

Ce guide commence par distinguer les huit rôles, leur socle commun et ce qui oriente vers chacun, puis répond à la 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

Distinguer les huit rôles DevOps, leur socle commun et ce qui oriente vers chacun
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

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.

Qu'est-ce qui distingue les rôles DevOps ?

Huit rôles reviennent dans les organisations qui pratiquent le DevOps : SRE, Platform Engineer, Cloud Engineer, DevSecOps, ingénieur CI/CD, FinOps, Release Manager et Architecte DevOps. Ils partagent un même socle technique et se distinguent par ce qu'ils protègent : la fiabilité, l'expérience des développeurs, l'infrastructure, la sécurité, le flux de livraison, les coûts, la coordination ou la trajectoire d'ensemble. Avant de les placer dans des équipes, il faut savoir ce que chacun apporte.

Le titre « DevOps Engineer », omniprésent dans les offres d'emploi, n'en fait pas partie : c'est un fourre-tout qui désigne selon l'entreprise un SRE, un Platform Engineer, un Cloud Engineer ou un administrateur système outillé. DevOps est une culture, pas un poste ; les rôles ci-dessous en sont les spécialisations.

Quel socle tous ces rôles partagent-ils ?

Quel que soit le rôle visé, le même socle revient dans les offres d'emploi et les parcours de formation. Chaque rôle y ajoute ensuite sa spécialité : le tableau dit ce qui est attendu de tous, la matrice plus bas dit où chacun se place.

Domaine	Ce qui est attendu de tous
Systèmes	Administration Linux, scripts shell, réseau TCP/IP et DNS
Versionnement	Git, branches, revue de code par demande de fusion
Conteneurs	Images OCI, registres, construction en plusieurs étapes
Infrastructure as Code	Terraform ou un équivalent, sur au moins un fournisseur cloud
CI/CD	Au moins une plateforme : GitLab CI, GitHub Actions ou Jenkins
Orchestration	Kubernetes : pods, déploiements, services, entrées
Observabilité	Métriques, alertes, journaux centralisés
Assistants IA	Un copilote de code pour accélérer, sans lui déléguer la revue

Le premier pilier, l'administration Linux, est aussi un métier à part entière et la porte d'entrée la plus fréquente : le parcours administrateur Linux le détaille. Le dernier mérite une nuance. Le rapport DORA 2025 (State of AI-assisted Software Development, Google Cloud) décrit l'IA comme un amplificateur : elle renforce les équipes qui ont déjà de bonnes fondations (tests, CI/CD, observabilité) et n'améliore rien chez celles qui en manquent.

Quel rôle choisir selon ce qui vous motive ?

Face à des frontières aussi poreuses, la question utile n'est pas « quel titre vise le marché » mais « qu'est-ce qui me motive au quotidien ». Le tableau part de vos affinités plutôt que d'une liste d'outils, et la dernière colonne dit si le site propose un parcours pour s'y former.

Vous aimez…	Orientez-vous vers…	Parcours sur ce site
Diagnostiquer et résoudre des incidents	SRE	Ingénieur fiabilité
Construire des outils pour les autres équipes	Platform Engineer	Ingénieur plateforme
L'infrastructure et l'architecture cloud	Cloud Engineer	Ingénieur cloud
Automatiser le chemin du code à la production	Ingénieur CI/CD	Ingénieur CI/CD
La sécurité et la conformité	DevSecOps	Ingénieur DevSecOps
Les chiffres et l'optimisation	FinOps	aucun
Coordonner des équipes	Release Manager	aucun
La stratégie et la transformation	Architecte DevOps	aucun

Trois rôles n'ont pas de parcours, pour trois raisons différentes. Le FinOps n'a pas de formation dédiée ici, mais la leçon Maîtriser la facture cloud en enseigne le cœur. Le Release Manager est un rôle de coordination plus que de technique. L'Architecte DevOps est la somme des autres rôles après des années de pratique. Les trois sont décrits plus bas, dans le détail par rôle.

Comment passe-t-on d'un rôle à l'autre ?

Il n'existe pas de diplôme unique qui mène à ces rôles. La plupart des professionnels viennent d'un poste voisin : l'administrateur système qui passe au cloud et à l'IaC évolue vers Cloud Engineer ou SRE, le développeur qui commence par la CI/CD de son équipe glisse vers le Platform Engineering. Les trajectoires les plus fréquentes suivent une spécialisation, puis montent en séniorité :

Spécialisation	Trajectoire typique
Infrastructure	Administrateur → Cloud Engineer → Platform Engineer → Staff Engineer
Fiabilité	DevOps → SRE → Senior SRE → Staff SRE
Sécurité	DevOps ou SRE → DevSecOps → Security Architect
Stratégie	Staff SRE ou Platform → Architecte DevOps → direction technique
Finance	Cloud Engineer ou DevOps → FinOps → responsable FinOps

Le niveau Staff désigne un ingénieur expert qui élargit son influence à plusieurs équipes sans devenir manager. Ces lignes sont des repères, pas des règles : beaucoup combinent deux affinités, SRE et Platform Engineering par exemple, avant de se spécialiser. Le catalogue des métiers traduit les cinq rôles qui ont un parcours en formations du site.

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

Voici où chaque rôle DevOps s'intègre le plus naturellement dans Team Topologies :

Source · SVG

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

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)

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.

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. En 2022, le cabinet Gartner prévoyait que 80 % des grandes organisations d'ingénierie logicielle auraient une équipe de platform engineering en 2026, contre 45 % alors : ce rôle est devenu une fonction standard.

Cloud Engineer

Le Cloud Engineer se place généralement dans une équipe Platform, parfois dans une équipe Complicated-subsystem.

Équipe Platform (typique)
Équipe Complicated-subsystem (rare)

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.

DevSecOps Engineer

Le DevSecOps Engineer se place principalement en équipe Enabling, parfois en équipe Platform.

Équipe Enabling (recommandé)
É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.

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.

Ce que le FinOps enseigne aux équipes, le framework de la FinOps Foundation, l'ordre des leviers d'économie, la différence entre montrer la dépense et la refacturer, se lit dans la leçon Maîtriser la facture cloud, avec les certifications du domaine.

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.

Équipe Platform (typique)
Embedded 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.

Release Manager

Le Release Manager se place en équipe Enabling ou directement dans une équipe stream-aligned.

Équipe Enabling
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

La réunion go/no-go est le rituel qui définit le rôle. Avant une release majeure, chaque partie prenante confirme sa préparation, puis la décision tombe, binaire : go, on déploie, ou no-go, on reporte. Elle transforme une décision individuelle en décision collective assumée, à condition que les critères soient écrits avant la réunion et non improvisés pendant.

Participant	Ce qu'il confirme
Responsables de développement	Le code livré est prêt et fusionné
QA	Les tests prévus sont passés
Exploitation ou SRE	Le service tiendra la charge, le retour arrière est prêt
Produit	Le contenu livré a la valeur attendue
Support	Les équipes au contact des clients sont prévenues

Dans les organisations régies par ITIL 4, le cadre de gestion des services informatiques, le Release Manager pilote une pratique précise. ITIL 4 en sépare trois : le change enablement évalue le risque d'un changement et l'autorise, la release management prépare et contrôle la version à rendre disponible, et le deployment management la déplace techniquement vers la production. Le Release Manager tient la deuxième et s'articule avec les deux autres. La certification ITIL 4 Foundation en donne le vocabulaire ; SAFe Release Train Engineer n'a de sens que dans une entreprise organisée en trains de release SAFe.

Les feature flags, interrupteurs qui activent une fonctionnalité sans redéployer, et le déploiement canary déplacent une partie de ces arbitrages. Le code part en production désactivé, l'activation progressive revient aux équipes produit, et le Release Manager garde la responsabilité du cadre : les critères d'arrêt et le retour arrière.

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.

Sa roadmap de transformation part toujours d'un état des lieux : sans diagnostic honnête, elle devient une liste de vœux déconnectée des vrais blocages. Quatre temps la structurent.

Temps	Ce qui s'y fait
Audit	Évaluer les pratiques existantes et repérer les écarts
Vision	Définir l'état cible et les étapes intermédiaires
Victoires rapides	Choisir les premiers gains visibles qui créent l'élan
Feuille de route	Planifier sur 12 à 24 mois, avec des jalons mesurables

Ses standards réduisent la charge cognitive de chaque équipe plutôt que de viser l'uniformité pour elle-même : architectures de référence, anti-patterns expliqués, conventions de nommage, et un tech radar qui classe les technologies adoptées, à l'essai ou abandonnées. Un standard imposé sans justification finit contourné. Il traduit aussi les objectifs du métier en choix techniques : « lancer dans six pays » devient une architecture multi-région, « le délai de mise sur le marché est la priorité » devient une CI/CD rapide et des feature flags. Il mesure le résultat avec les métriques DORA, qui parlent aux dirigeants.

Ce qui le distingue tient autant à ce qu'il ne fait pas. Il ne code pas au quotidien, sauf un prototype ponctuel, ne gère pas les incidents de production, ne décide pas seul et n'impose aucune technologie sans la justifier. Son succès se mesure à l'autonomie des équipes : si elles ont besoin de lui pour chaque décision, c'est un échec. Le rôle demande en général huit à dix ans de pratique technique, souvent comme SRE ou Platform Engineer, avant de pouvoir porter cette influence sans autorité.

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)

À 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 :

Source · SVG

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)

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é : des pipelines similaires mais incompatibles, des configurations Kubernetes divergentes, pratiques de monitoring hétérogènes.

Source · SVG

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)

À 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.

Source · SVG

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

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

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"

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

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

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

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

Huit rôles partagent un même socle (Linux, Git, conteneurs, IaC, CI/CD, Kubernetes, observabilité) et se distinguent par ce qu'ils protègent ; le titre « DevOps Engineer » est un fourre-tout, pas un rôle.
SRE, Platform Engineer et DevSecOps sont des compétences ; Stream-aligned, Platform et Enabling sont des types d'équipes. Un même rôle se place différemment selon le contexte.
Il n'y a pas de placement universel : taille, maturité et besoins métier décident.
Une équipe Enabling réussie se rend obsolète : un Enabling permanent signale un problème.
Une plateforme se consomme en self-service : si les développeurs ouvrent des tickets pour l'utiliser, c'est un échec.
La 2ᵉ édition de Team Topologies (2025) parle parfois de platform grouping ; le principe reste de servir les équipes stream-aligned.
Gartner prévoyait en 2022 que 80 % des grandes organisations d'ingénierie logicielle auraient une équipe de platform engineering en 2026.

Contrôle de connaissances

Vérifiez que l'essentiel de cette leçon est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

Le chronomètre démarre au clic sur Démarrer
Questions à choix multiples, vrai/faux et réponses courtes
Vous pouvez naviguer entre les questions
Les résultats détaillés sont affichés à la fin

FAQ : questions fréquentes

Où placer le SRE dans Team Topologies ?

Quelle est la différence entre une équipe Platform et une équipe Enabling ?

Le DevSecOps doit-il être dans une équipe Platform ou Enabling ?

Pourquoi éviter une équipe DevOps fourre-tout ?

Comment évoluent les placements des rôles DevOps quand l'organisation grandit ?

Qu'est-ce que l'anti-pattern du SRE pompier de service ?

Ressources externes

Ces lectures prolongent la leçon depuis les sources : le livre Team Topologies, ses pages consacrées au platform engineering, et deux retours d'expérience sur le placement du SRE et la transformation d'une équipe DevOps en équipe Platform.