Imaginez une entreprise où l'équipe DevOps croule sous les tickets, où les développeurs attendent des jours pour un environnement de test, et où chaque déploiement ressemble à une opération à cœur ouvert. Ce scénario, malheureusement courant, illustre ce qui arrive quand la structure des équipes ne suit pas la croissance de l'organisation. Cette page applique le modèle Team Topologies au DevOps : ses 4 types d'équipes, ses 3 modes d'interaction, et des repères concrets pour dimensionner votre organisation selon sa taille, de la startup à l'entreprise de plusieurs centaines de développeurs.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Comprendre les 4 types d'équipes Team Topologies et leur proportion cible
- Appliquer les 3 modes d'interaction selon le contexte (collaboration, self-service, coaching)
- Dimensionner votre organisation selon sa taille : startup, scale-up, entreprise
- Repérer les anti-patterns organisationnels les plus fréquents
- Piloter une transformation progressive sans tout casser d'un coup
Pourquoi la structure des équipes est-elle si importante ?
Section intitulée « Pourquoi la structure des équipes est-elle si importante ? »Avant de parler d'outils, de pipelines CI/CD ou de conteneurs, il faut comprendre une vérité fondamentale : la structure de vos équipes détermine la qualité de vos logiciels. C'est ce qu'on appelle la loi de Conway, formulée en 1967 par Melvin Conway :
« Toute organisation qui conçoit un système produira inévitablement un design qui copie la structure de communication de cette organisation. »
Concrètement, si vos équipes travaillent en silos, votre architecture sera fragmentée. Si la communication entre équipes est difficile, les interfaces entre composants le seront aussi. Cette loi n'est pas une fatalité, c'est un levier : en structurant intelligemment vos équipes, vous façonnez votre architecture plutôt que de la subir.
C'est précisément ce que propose Team Topologies, un modèle créé par Matthew Skelton et Manuel Pais. Plutôt que de subir la loi de Conway, ce framework permet de l'utiliser à son avantage en définissant des types d'équipes et des modes d'interaction clairs.
Les concepts fondamentaux
Section intitulée « Les concepts fondamentaux »Avant de plonger dans les détails, clarifions trois concepts essentiels qui guideront toute notre réflexion sur la structure des équipes.
La charge cognitive
Section intitulée « La charge cognitive »La charge cognitive désigne l'effort mental nécessaire pour accomplir une tâche. Dans le contexte des équipes DevOps, c'est la quantité d'informations qu'un membre doit garder en tête pour être productif : l'architecture du système, les outils, les processus, les dépendances avec d'autres équipes.
Quand la charge cognitive dépasse les capacités d'une équipe, plusieurs symptômes apparaissent :
- Les délais de livraison s'allongent
- La qualité du code se dégrade
- Le turnover augmente
- L'innovation disparaît
L'objectif principal de Team Topologies est de réduire et répartir équitablement la charge cognitive entre les équipes. La 2e édition du livre (2025) en fait explicitement le critère de conception numéro un : avant toute autre considération, on se demande si une équipe a la bande passante mentale pour absorber son périmètre.
Le flux de valeur (flow)
Section intitulée « Le flux de valeur (flow) »Le flux représente la capacité à livrer de la valeur de bout en bout, de l'idée jusqu'à l'utilisateur final. Une bonne structure d'équipe maximise ce flux en minimisant les handoffs (passages de relais), les attentes et les dépendances bloquantes.
Pensez-y comme un cours d'eau : chaque silo organisationnel est un barrage qui ralentit l'écoulement. L'objectif est de créer des équipes capables de délivrer de la valeur avec le minimum de dépendances externes. Le guide dédié au flux de valeur et au flow détaille les outils de cartographie pour visualiser où se situent vos propres barrages.
L'autonomie des équipes
Section intitulée « L'autonomie des équipes »Une équipe autonome peut prendre des décisions, expérimenter et livrer sans avoir besoin de permissions externes constantes. Cette autonomie n'est pas un luxe, c'est une nécessité pour maintenir la vélocité quand l'organisation grandit.
Mais attention : autonomie ne signifie pas isolement. Les équipes doivent rester alignées sur les objectifs de l'entreprise et coordonnées avec les autres équipes. C'est tout l'art de Team Topologies : définir les bons niveaux d'autonomie et les bons mécanismes de coordination.
Les 4 types d'équipes Team Topologies
Section intitulée « Les 4 types d'équipes Team Topologies »Team Topologies définit exactement quatre types d'équipes, ni plus, ni moins. Cette simplicité est volontaire : elle force à clarifier le rôle de chaque équipe et à éviter les zones grises où personne n'est vraiment responsable.
Stream-aligned Teams (60-80 % des équipes)
Section intitulée « Stream-aligned Teams (60-80 % des équipes) »Les équipes stream-aligned sont le cœur de votre organisation. Elles sont alignées sur un flux de valeur métier : un produit, une fonctionnalité majeure, un segment de clients, ou un parcours utilisateur.
Caractéristiques clés :
- Responsabilité end-to-end : du code à la production
- Autonomie maximale : peuvent livrer sans dépendances bloquantes
- Focus métier : comprennent le domaine fonctionnel qu'elles servent
- Taille optimale : 5 à 9 personnes (règle des « two-pizza teams » d'Amazon)
Pourquoi viser 60 à 80 % ? Parce que ce sont ces équipes qui créent directement de la valeur pour les utilisateurs. Les autres types d'équipes existent pour les soutenir, pas l'inverse. Si vous avez plus d'équipes de support que d'équipes stream-aligned, quelque chose ne va pas dans votre organisation.
Exemple concret : chez un e-commerçant, vous pourriez avoir une équipe stream-aligned « Checkout » responsable de tout le parcours de paiement, une équipe « Catalogue produits », une équipe « Livraison », etc.
Platform Teams (10-20 % des équipes)
Section intitulée « Platform Teams (10-20 % des équipes) »Les équipes plateforme fournissent des services internes qui accélèrent le travail des équipes stream-aligned. Leur mission est de réduire la charge cognitive des développeurs en leur offrant des capacités en self-service.
Caractéristiques clés :
- Mode self-service : les équipes stream-aligned consomment sans intervention humaine
- Documentation exemplaire : guides, tutoriels, exemples fonctionnels ; la doc est un produit, pas une corvée
- Fiabilité : les services doivent être plus stables que si chaque équipe les gérait
- Adoption volontaire : la plateforme doit être attractive, pas imposée
Ce que fournit typiquement une équipe plateforme :
- Pipelines CI/CD pré-configurés
- Environnements de développement standardisés (voir les DevContainers)
- Observabilité (logs, métriques, traces) as-a-service
- Provisionnement d'infrastructure automatisé (Terraform, Ansible)
- Gestion des secrets et des accès
Le concept de Thinnest Viable Platform (TVP, la plateforme minimale viable) reste central : ne construisez pas une plateforme monumentale. Commencez par le strict nécessaire et enrichissez-la en fonction des besoins réels des équipes. Une plateforme trop ambitieuse devient un fardeau au lieu d'un accélérateur.
Enabling Teams (5-15 % des équipes)
Section intitulée « Enabling Teams (5-15 % des équipes) »Les équipes enabling sont des catalyseurs de compétences. Leur rôle est d'aider les équipes stream-aligned à adopter de nouvelles pratiques, technologies ou méthodes de travail.
Caractéristiques clés :
- Mission temporaire : elles n'interviennent que le temps nécessaire
- Pas de livraison directe : elles ne codent pas à la place des autres
- Transfert de compétences : leur succès se mesure à l'autonomie acquise par les autres équipes
- Expertise transverse : sécurité, performance, architecture, pratiques DevOps
Exemples d'interventions enabling :
- Former une équipe à Kubernetes pendant 2 à 3 sprints
- Accompagner l'adoption de pratiques de test automatisé
- Aider à mettre en place une stratégie de feature flags
- Coacher sur les pratiques de trunk-based development
Durée typique d'engagement : une équipe enabling ne devrait pas travailler avec la même équipe stream-aligned plus de quelques semaines à quelques mois. Si l'engagement dure plus longtemps, il y a un problème : soit la compétence est trop complexe (besoin d'une équipe complicated-subsystem), soit le transfert ne se fait pas.
Complicated-Subsystem Teams (0-10 % des équipes)
Section intitulée « Complicated-Subsystem Teams (0-10 % des équipes) »Les équipes complicated-subsystem gèrent des composants qui nécessitent une expertise tellement pointue qu'il serait déraisonnable de l'attendre des équipes stream-aligned.
Caractéristiques clés :
- Expertise rare : domaines comme le machine learning, les codecs vidéo, la cryptographie
- Composant réutilisable : le sous-système est consommé par plusieurs équipes stream-aligned
- Maintenance spécialisée : nécessite des compétences difficiles à acquérir et maintenir
Attention au piège : la tentation est grande de créer des équipes complicated-subsystem pour tout ce qui est « technique ». Résistez-y. Si vous pouvez former les équipes stream-aligned à gérer un composant (via une équipe enabling), c'est préférable. Réservez ce type d'équipe aux vrais cas de complexité irréductible.
Exemples légitimes : équipe spécialisée en traitement vidéo temps réel, équipe de data scientists pour les modèles ML de production, équipe sécurité cryptographique pour les systèmes de paiement.
Les 3 modes d'interaction
Section intitulée « Les 3 modes d'interaction »Définir les types d'équipes ne suffit pas. Il faut aussi clarifier comment ces équipes interagissent. Team Topologies propose trois modes d'interaction, chacun adapté à des situations spécifiques.
Collaboration
Section intitulée « Collaboration »Le mode collaboration implique un travail conjoint entre deux équipes. Les frontières s'estompent temporairement, les équipes partagent des objectifs communs et découvrent ensemble des solutions.
Quand l'utiliser :
- Exploration d'un nouveau domaine
- Innovation nécessitant des compétences croisées
- Définition d'une nouvelle API ou interface
- Début d'un projet sans spécifications claires
Caractéristiques :
- Haute bande passante de communication (réunions fréquentes, pair programming)
- Durée limitée dans le temps (quelques semaines à quelques mois)
- Objectif commun clairement défini
- Les deux équipes apprennent l'une de l'autre
Exemple : une équipe stream-aligned et une équipe plateforme collaborent pendant 6 semaines pour définir les primitives d'une nouvelle API de déploiement. Une fois l'API stabilisée, elles passent en mode X-as-a-Service.
X-as-a-Service
Section intitulée « X-as-a-Service »Le mode X-as-a-Service est l'inverse de la collaboration : une équipe consomme les services d'une autre avec un minimum d'interaction. L'interface (API, documentation, SLA) est suffisamment claire pour que la communication directe soit rarement nécessaire.
Quand l'utiliser :
- Services matures et bien documentés
- Opérations courantes et répétitives
- L'équipe consommatrice n'a pas besoin de comprendre les détails d'implémentation
Caractéristiques :
- API claire et stable
- Documentation complète et à jour
- Support via tickets ou canaux standards (pas de sollicitations directes)
- SLA définis et respectés
C'est le mode cible pour la plupart des interactions entre équipes stream-aligned et équipes plateforme. Une plateforme réussie, c'est une plateforme qu'on peut utiliser sans avoir besoin de parler à quelqu'un.
Facilitating
Section intitulée « Facilitating »Le mode facilitating est utilisé quand une équipe (généralement enabling) aide une autre à acquérir de nouvelles compétences sans faire le travail à sa place.
Quand l'utiliser :
- Adoption de nouvelles technologies
- Montée en compétences sur des pratiques spécifiques
- Amélioration des processus existants
Caractéristiques :
- L'équipe facilitante ne livre pas de code en production
- Elle enseigne, coache, accompagne
- L'objectif est l'autonomie de l'équipe accompagnée
- Durée limitée par définition
Différence avec la collaboration : en mode collaboration, les deux équipes travaillent ensemble sur un livrable. En mode facilitating, une équipe apprend à l'autre comment faire, sans produire le livrable elle-même.
Dimensionner ses équipes selon la taille de l'organisation
Section intitulée « Dimensionner ses équipes selon la taille de l'organisation »La structure idéale dépend fortement de la taille de votre organisation. Ce qui fonctionne pour une startup de 15 personnes ne convient pas à une entreprise de 500 développeurs, et inversement : imposer une gouvernance lourde à une petite équipe la paralyse.
Startup (moins de 20 développeurs)
Section intitulée « Startup (moins de 20 développeurs) »À ce stade, parler d'équipe DevOps dédiée est souvent prématuré. L'enjeu est de diffuser la culture DevOps dans toute l'équipe technique plutôt que de la confier à un rôle isolé.
Configuration recommandée :
- 1 à 2 profils DevOps/SRE généralistes intégrés aux équipes de développement
- Pas d'équipe plateforme dédiée
- Focus sur l'automatisation de base (CI/CD, IaC)
Priorités :
-
Mettre en place une CI/CD fonctionnelle
Un pipeline qui builde, teste et déploie automatiquement. Rien de sophistiqué, mais fonctionnel. Vous pouvez commencer avec GitLab CI ou GitHub Actions.
-
Adopter l'Infrastructure as Code dès le départ
Terraform, Pulumi ou équivalent. Même simple, cette pratique évite une dette technique énorme.
-
Implémenter une observabilité de base
Logs centralisés, métriques applicatives, alertes sur les erreurs critiques.
-
Documenter les runbooks essentiels
Comment déployer, comment revenir en arrière (rollback), comment diagnostiquer les pannes courantes. Une bonne approche Docs-as-Code garantit que la documentation reste à jour avec le code.
Piège à éviter : vouloir reproduire l'organisation de Google ou Netflix. À ce stade, la simplicité est votre meilleure alliée. Un développeur qui comprend l'ensemble du système vaut mieux qu'une organisation complexe.
Scale-up (20 à 100 développeurs)
Section intitulée « Scale-up (20 à 100 développeurs) »C'est la phase critique où la complexité explose. Les pratiques informelles ne suffisent plus, mais une organisation trop rigide tue l'agilité qui a fait le succès de l'entreprise jusque-là.
Configuration recommandée :
- 2 à 6 Platform Engineers formant une équipe plateforme naissante
- Un ratio d'1 Platform Engineer pour 10 à 15 développeurs
- Plusieurs équipes stream-aligned autonomes
Structure type :
├── Équipe Plateforme (3-5 personnes)│ ├── CI/CD & Tooling│ ├── Infrastructure│ └── Observabilité│├── Équipe Stream-aligned Produit A (5-8 personnes)├── Équipe Stream-aligned Produit B (5-8 personnes)└── Équipe Stream-aligned Produit C (5-8 personnes)Cette structure type reste un point de départ, pas un moule figé : elle se réajuste dès que les frontières entre produits changent ou qu'un domaine prend trop de place cognitive pour une seule équipe.
Priorités :
-
Construire une plateforme interne minimaliste
Templates de projets, pipelines CI/CD standards, documentation des bonnes pratiques.
-
Définir les domaines des équipes stream-aligned
Utiliser le Domain-Driven Design (DDD, une méthode de conception qui aligne le découpage logiciel sur les frontières métier) pour identifier les bounded contexts (les frontières fonctionnelles cohérentes).
-
Mettre en place des SLO/SLI partagés
Chaque équipe stream-aligned doit être responsable de la fiabilité de son domaine. Les indicateurs DORA complètent cette approche : le rapport DORA 2025 a remplacé l'ancien classement à quatre paliers (Elite/High/Medium/Low) par sept profils d'équipe qui croisent performance de livraison et signaux culturels, et y ajoute un modèle de capacités IA pour distinguer les équipes où l'IA accélère réellement la livraison de celles où elle amplifie surtout l'instabilité.
-
Créer un guild DevOps transversal
Un espace d'échange pour partager les pratiques entre équipes.
Enterprise (plus de 100 développeurs)
Section intitulée « Enterprise (plus de 100 développeurs) »À cette échelle, la spécialisation devient nécessaire. Les équipes généralistes ne peuvent plus couvrir tous les domaines avec l'expertise requise, et le nombre de dépendances croît plus vite que le nombre d'équipes.
Configuration recommandée :
- Équipes plateforme spécialisées (infra, CI/CD, observabilité, sécurité)
- Équipes enabling pour l'accompagnement des pratiques
- Potentiellement des équipes complicated-subsystem
- Centre d'excellence DevOps pour l'alignement stratégique
Structure type :
├── Département Plateforme│ ├── Équipe Infrastructure Cloud (4-6)│ ├── Équipe CI/CD & Developer Experience (4-6)│ ├── Équipe Observabilité (3-5)│ └── Équipe Sécurité Plateforme (3-5)│├── Équipe Enabling DevSecOps (3-4)│ └── Accompagnement sécurité des équipes produit│├── Équipe Enabling SRE Practices (3-4)│ └── Coaching reliability engineering│├── Tribus Produit (plusieurs équipes stream-aligned chacune)│ ├── Tribu Paiement│ ├── Tribu Catalogue│ └── Tribu Logistique│└── Centre d'Excellence DevOps └── Standards, gouvernance, roadmap plateformeCe schéma illustre une organisation type, mais le point important n'est pas le nombre de boîtes : c'est que chaque équipe reste dans une fourchette de charge cognitive gérable, quitte à multiplier les équipes plateforme spécialisées plutôt que d'en avoir une seule surchargée.
Priorités :
-
Développer une Internal Developer Platform (IDP) complète
Self-service pour l'ensemble du cycle de vie : création de projet, déploiement, monitoring. Voir le guide dédié au Platform Engineering pour la démarche complète.
-
Mettre en place des équipes enabling par domaine
Sécurité, performance, reliability : chaque domaine critique a ses champions.
-
Définir une gouvernance claire
Standards techniques, processus d'adoption, mesure de l'adoption des pratiques.
-
Mesurer l'efficacité de la plateforme, pas seulement son existence
Developer Experience surveys, temps de mise en production, lead time for changes. C'est un point sensible : plusieurs études sectorielles 2026 sur le Platform Engineering signalent que la majorité des organisations auront mis en place une équipe plateforme, mais qu'une minorité seulement mesure un gain de productivité réel, faute d'indicateurs suivis dans la durée. Une plateforme sans boucle de mesure ne peut pas prouver sa valeur, même si elle en apporte.
Les anti-patterns à éviter
Section intitulée « Les anti-patterns à éviter »Reconnaître les mauvais patterns est aussi important que connaître les bons. Voici les erreurs les plus courantes, observées dans des organisations de toutes tailles.
L'équipe DevOps silo
Section intitulée « L'équipe DevOps silo »Symptômes :
- Une équipe « DevOps » fait les déploiements à la place des développeurs
- Les développeurs créent des tickets pour chaque action opérationnelle
- Distinction nette « Dev » vs « Ops »
Cet anti-pattern est problématique car il recrée exactement le silo que DevOps était censé éliminer. Les développeurs ne sont pas responsables de leur code en production, et les « DevOps » n'ont pas le contexte fonctionnel nécessaire pour bien décider. La solution consiste à intégrer les compétences DevOps dans les équipes stream-aligned et à transformer l'équipe DevOps en équipe plateforme qui fournit des services en self-service.
La plateforme ticket-driven
Section intitulée « La plateforme ticket-driven »Symptômes :
- L'équipe plateforme traite des tickets au lieu de construire des services
- Les développeurs attendent des jours pour des actions simples
- Aucune amélioration des outils malgré des demandes répétées
Ce piège transforme l'équipe plateforme en goulot d'étranglement au lieu d'un accélérateur : elle passe son temps en support au lieu de construire. La parade est systématique : pour chaque demande récurrente, automatiser et exposer en self-service, puis mesurer le temps d'attente moyen et viser sa réduction continue.
L'over-engineering prématuré
Section intitulée « L'over-engineering prématuré »Symptômes :
- Plateforme Kubernetes complexe pour 3 services
- Micro-services pour une équipe de 10 personnes
- Outils sophistiqués utilisés à 5 % de leurs capacités
La complexité technique génère une charge cognitive qui ralentit tout le monde : l'équipe passe plus de temps à gérer les outils qu'à livrer de la valeur. La question à se poser systématiquement est simple : cette complexité est-elle justifiée par les besoins actuels ou anticipés dans les 12 prochains mois ?
Les équipes trop petites ou trop grandes
Section intitulée « Les équipes trop petites ou trop grandes »Symptômes :
- Équipes de 2-3 personnes sans couverture en cas d'absence
- Équipes de 15+ personnes avec des réunions interminables
- Bus factor de 1 (un seul départ suffirait à bloquer la maintenance) sur des composants critiques
Les petites équipes manquent de résilience ; les grandes équipes perdent en communication et en vélocité. La cible reste la fourchette de 5 à 9 personnes par équipe : en dessous, regrouper ; au-dessus, diviser en identifiant des flux de valeur distincts.
Évolution progressive : comment transformer votre organisation
Section intitulée « Évolution progressive : comment transformer votre organisation »La transformation vers Team Topologies ne se fait pas du jour au lendemain. Voici une approche progressive adaptée à la plupart des contextes, découpée en quatre phases successives.
Phase 1 : cartographie et diagnostic (2-4 semaines)
Section intitulée « Phase 1 : cartographie et diagnostic (2-4 semaines) »-
Identifier les flux de valeur actuels
Quels sont les produits ou services que vous livrez ? Qui sont les utilisateurs ?
-
Cartographier les équipes existantes
Qui fait quoi ? Quelles sont les dépendances ? Où sont les goulots d'étranglement ?
-
Mesurer la charge cognitive
Combien de domaines ou de technologies chaque équipe doit-elle maîtriser ?
-
Identifier les interactions dysfonctionnelles
Où y a-t-il des attentes récurrentes ? Des frustrations ?
Cette phase de diagnostic gagne à s'appuyer sur un cadre structuré plutôt que sur des impressions : le guide pour évaluer sa maturité DevSecOps propose une grille utilisable telle quelle pour objectiver l'état de départ.
Phase 2 : quick wins (1-3 mois)
Section intitulée « Phase 2 : quick wins (1-3 mois) »Avant de toucher à l'organigramme, cette phase vise des victoires rapides qui construisent la confiance dans la démarche. L'erreur classique consiste à vouloir tout restructurer d'un coup au nom de Team Topologies : mieux vaut prouver la valeur du modèle sur des irritants concrets et mesurables, avant de proposer un changement de structure plus profond.
-
Clarifier les responsabilités existantes
Sans changer la structure, expliciter qui est responsable de quoi.
-
Réduire les dépendances évidentes
Automatiser les demandes récurrentes les plus frustrantes.
-
Améliorer la documentation
Rendre les services existants plus accessibles sans intervention humaine.
-
Former les équipes aux concepts Team Topologies
Créer un vocabulaire commun avant de restructurer quoi que ce soit.
Phase 3 : restructuration progressive (3-12 mois)
Section intitulée « Phase 3 : restructuration progressive (3-12 mois) »Une fois la confiance installée par les quick wins, cette phase touche enfin à la structure des équipes elle-même. L'objectif n'est pas de tout transformer simultanément : on pilote avec une ou deux équipes volontaires, on observe ce qui fonctionne réellement sur le terrain, puis on étend la démarche progressivement au reste de l'organisation.
-
Piloter avec une ou deux équipes
Transformer une équipe existante en équipe stream-aligned avec responsabilité end-to-end.
-
Construire les premières briques de plateforme
Commencer par le service le plus demandé et le fournir en self-service.
-
Définir les modes d'interaction
Expliciter comment les équipes pilotes interagissent avec le reste de l'organisation.
-
Itérer et étendre
Appliquer les leçons apprises aux autres équipes progressivement.
Phase 4 : optimisation continue (permanent)
Section intitulée « Phase 4 : optimisation continue (permanent) »-
Mesurer régulièrement
Temps de déploiement, satisfaction développeur, incidents, temps de résolution.
-
Ajuster les frontières
Les domaines évoluent, les équipes doivent s'adapter.
-
Évaluer la charge cognitive
Si une équipe est débordée, questionner son périmètre plutôt que de lui ajouter des outils.
-
Faire évoluer les modes d'interaction
Une collaboration peut devenir X-as-a-Service une fois le service stabilisé.
Cette phase n'a pas de fin : la 2e édition de Team Topologies insiste justement sur ce point en présentant le modèle comme un processus continu plutôt qu'un état stable à atteindre une fois pour toutes.
Les rôles clés dans une organisation DevOps mature
Section intitulée « Les rôles clés dans une organisation DevOps mature »Au-delà de la structure des équipes, certains rôles sont essentiels au bon fonctionnement de l'organisation. Cette section les positionne brièvement ; le guide dédié détaille comment les placer précisément dans le modèle.
Site Reliability Engineer (SRE)
Section intitulée « Site Reliability Engineer (SRE) »Le SRE combine compétences de développement et d'exploitation pour garantir la fiabilité des services. Son focus : SLO, error budgets, automatisation des opérations.
Positionnement typique : intégré aux équipes stream-aligned ou dans une équipe enabling SRE.
Platform Engineer
Section intitulée « Platform Engineer »Le Platform Engineer construit les services de la plateforme interne. Son focus : developer experience, self-service, automatisation.
Positionnement typique : équipe plateforme.
DevSecOps Engineer
Section intitulée « DevSecOps Engineer »Le DevSecOps Engineer intègre la sécurité dans le cycle de développement. Son focus : shift-left security, automatisation des contrôles, sécurité de la supply chain.
Positionnement typique : équipe enabling ou équipe plateforme sécurité.
À retenir
Section intitulée « À retenir »4 types d'équipes
Stream-aligned (60-80 %) créent la valeur. Platform (10-20 %) fournissent des services. Enabling (5-15 %) transfèrent des compétences. Complicated-subsystem (0-10 %) gèrent la complexité irréductible.
3 modes d'interaction
Collaboration pour l'exploration (temporaire). X-as-a-Service pour la consommation autonome (cible). Facilitating pour l'apprentissage (temporaire).
Charge cognitive d'abord
La structure doit minimiser la charge cognitive. C'est le critère de conception numéro un depuis la 2e édition du livre (2025). Aucun outil ne sauve une équipe cognitivement débordée.
Groupement plateforme
Depuis 2025, on parle de platform grouping plutôt que d'équipe plateforme unique : plusieurs équipes coopèrent pour livrer une plateforme cohérente.
Mesurer, pas seulement construire
Selon les études sectorielles 2026 sur le Platform Engineering, la majorité des organisations auront une équipe plateforme, mais peu mesurent un vrai gain de productivité faute d'indicateurs suivis.
Évolution progressive
Ne restructurez pas tout d'un coup. Cartographiez, pilotez, itérez. La transformation prend des mois, pas des semaines.
FAQ : questions fréquentes
Section intitulée « FAQ : questions fréquentes »Pour aller plus loin
Section intitulée « Pour aller plus loin »Ressources externes :