Ressources

Platform engineering pour une scale-up : par où commencer sans sur-ingénierie

Platform engineering pour une scale-up : quand s'y mettre, la plateforme minimale, construire ou acheter, les anti-modèles, la mesure et un plan de démarrage.

Par Corentin Mas, publié le 29 septembre 2026 · 20 min de lecture

Base d'expérience : Méthode et documentation officielle (CNCF, DORA, Team Topologies, Microsoft Learn, Kubernetes, Amazon EKS, Backstage) : démarrage d'une plateforme interne minimale, sans référence client ni retour de mission.

Relecture factuelle : Claude Code (revue indépendante déléguée par Corentin Mas, 28/09/2026), le 29 septembre 2026

Quand une scale-up passe de quelques équipes produit à plusieurs, des symptômes peuvent apparaître : chaque nouveau service est copié d'un autre, défauts compris ; un déploiement dépend d'une ou deux personnes ; l'équipe infrastructure crée à la demande bases, secrets et accès. Le « platform engineering » arrive alors avec ses images de conférence : portail développeur, abstraction de Kubernetes, équipe dédiée. Une direction technique peut attendre l'inverse : éviter la sur-ingénierie, rester autonome avec un filet de sécurité, ne plus dépendre d'une personne clé.

Faits datés

Ce guide aide un CTO à trancher : quoi construire d'abord, quoi attendre, comment mesurer, et comment démarrer en trois étapes. Il s'appuie sur le livre blanc Platforms de la CNCF (Cloud Native Computing Foundation), dont la version 1 date de mars 2023 et dont l'édition courante est publiée en ligne, sur son modèle de maturité en version 1, sur le rapport DORA 2024 et sur les documentations de Backstage, Kubernetes et Amazon EKS. Les calendriers de version, les chiffres et les comportements de produit cités ont été vérifiés le 29 septembre 2026 sur les sources listées en fin d'article.

Vérifié le 29 septembre 2026

En bref

Une plateforme interne est un ensemble intégré de capacités présenté selon les besoins de ses utilisateurs : déployer, obtenir une base, lire ses journaux, sans ticket. Ce n'est ni un portail, ni Kubernetes, ni une équipe d'exploitation renommée.
Le besoin se lit dans des signaux (demandes répétitives, services copiés, déploiements suspendus à une personne), pas dans l'effectif seul.
On commence par la plateforme la plus fine possible : dépôt modèle, déploiement GitOps et services managés pour les tâches les plus fréquentes, avec une sortie de secours documentée.
Le rapport DORA 2024 associe les plateformes internes à une productivité plus élevée, mais aussi à un débit et à une stabilité des changements plus faibles : le gain passe par un libre-service réel.
On mesure l'usage et les délais, pas les fonctionnalités livrées.

Ce que le platform engineering résout, et ce qu'il n'est pas

Le livre blanc Platforms de la CNCF définit une plateforme comme « un ensemble intégré de capacités, défini et présenté selon les besoins de ses utilisateurs » (traduction). Ses treize domaines de capacités vont des portails et des API de provisionnement à l'observabilité, aux services de données, à l'identité et aux secrets. Il appelle chemin balisé (golden path) un modèle de projet et sa documentation qui déroulent un parcours complet : construire, analyser, tester, déployer, observer.

DORA, le programme de recherche DevOps Research and Assessment (sans rapport avec le règlement européen du même sigle), y voit une discipline sociotechnique : interactions entre équipes d'un côté, automatisation, libre-service et répétabilité de l'autre. Team Topologies, de Matthew Skelton et Manuel Pais, fournit le vocabulaire : l'équipe plateforme est l'un des quatre types d'équipe et fournit aux équipes alignées sur un flux de valeur une plateforme interne qui réduit leur charge cognitive. Le fil commun est cette charge cognitive : une équipe produit ne peut pas maîtriser à la fois son domaine, Kubernetes, le réseau cloud et les secrets.

Ce qu'il n'est pas

Un portail. C'est une interface parmi d'autres, à côté des API et des lignes de commande. Le livre blanc admet qu'une plateforme très simple peut être « une page de wiki » renvoyant vers des procédures standard.
Kubernetes. Sa propre documentation précise qu'il n'est pas un PaaS (Platform as a Service) « traditionnel et tout compris » : il ne construit pas l'application, ne fournit ni base de données ni middleware, n'impose aucune solution de journalisation, de surveillance ou d'alerte. C'est une brique possible, pas la plateforme.
Une équipe d'exploitation renommée. Une équipe qui traite des tickets comme un distributeur tombe dans le piège que DORA nomme « ticket-ops ».
Une obligation. Parmi les sept attributs du livre blanc figure « optionnelle et composable » : une équipe doit pouvoir n'en utiliser qu'une partie, et gérer ses propres capacités en dehors si nécessaire.

Ce que dit la recherche DORA

Dans le rapport Accelerate State of DevOps 2024, 89 % des répondants déclarent utiliser une plateforme interne de développement. Les utilisateurs de ces plateformes affichent une productivité individuelle supérieure de 8 % et une performance d'équipe supérieure de 10 %, et la performance de livraison et d'exploitation de l'organisation augmente de 6 %. En contrepartie, le débit baisse de 8 % et la stabilité des changements de 14 %. Hypothèses des auteurs : plus d'étapes et de passages de relais avant la production, une plateforme imposée alors qu'elle ne convient pas, ou des changements poussés plus volontiers parce qu'ils se corrigent vite. Selon l'âge de la plateforme, le rapport observe pour la productivité des gains au démarrage, puis une baisse, puis une reprise.

Deux résultats intéressent une scale-up. Quand les utilisateurs accomplissent leurs tâches sans solliciter une équipe d'appui, la productivité progresse de 5 %, au niveau individuel comme au niveau de l'équipe. Une équipe plateforme dédiée a un effet négligeable sur la productivité individuelle et s'accompagne d'un gain de 6 % au niveau de l'équipe. Ces corrélations désignent le libre-service comme levier ; une plateforme qui ajoute des étapes peut ralentir.

Le modèle de maturité : un repère, pas un objectif

Le modèle de maturité de la CNCF décrit quatre niveaux (Provisional, Operational, Scalable, Optimizing) sur cinq aspects : investissement, adoption, interfaces, exploitation, mesure. Chaque niveau demande davantage de financement et de temps, et atteindre le plus haut « ne devrait pas être un objectif en soi ». Pour une scale-up, l'enjeu tient en deux déplacements : de processus propres à chaque demande (« custom processes ») à un outillage standard (« standard tooling »), et d'une adoption imposée (« extrinsic push ») à une adoption choisie (« intrinsic pull »).

Signaux : quand investir, quand attendre

Pour chaque signal, la réponse minimale à construire et ce qu'il vaut mieux ne pas encore construire
Signal	Réponse minimale	Ce qu'il ne faut pas encore faire
Chaque nouveau service est copié d'un autre, avec ses erreurs	Dépôt modèle versionné : Dockerfile, CI, manifests, tableau de bord	Portail de création de services
Un déploiement dépend d'une ou deux personnes	Image construite par la CI, déploiement par demande de fusion, contrôleur GitOps	Orchestrateur de déploiement maison
Les mêmes demandes reviennent : base, stockage, DNS, secret	Module Terraform versionné, sollicité par demande de fusion	API de provisionnement, catalogue de services
Préproduction et production divergent	Environnements entièrement dans le code, détection de dérive planifiée	Environnements éphémères pour chaque demande de fusion
Les alertes font du bruit, un incident se diagnostique dans plusieurs outils	Journaux, métriques et quelques alertes créés avec chaque service	Pile d'observabilité maison
Des secrets circulent par messagerie	Coffre managé synchronisé vers les charges	Abstraction de secrets multi-fournisseurs
Un nouvel arrivant attend longtemps son premier déploiement	Parcours documenté, testé par le dernier arrivé	Catalogue logiciel exhaustif
Une seule personne sait opérer la plateforme	Infrastructure as code, runbooks, binôme	Recruter une équipe plateforme avant le premier chemin balisé

À l'inverse, avec une seule équipe produit, un PaaS qui suffit et des déploiements sans douleur, mieux vaut écrire les procédures et garder l'existant.

La plateforme la plus fine possible : des chemins balisés pour les tâches fréquentes

La CNCF recommande la couche de plateforme la plus fine possible au-dessus des services des fournisseurs managés (« thinnest viable platform layer ») et cite pipelines, bases de données et observabilité comme de bons points de départ. DORA conseille d'identifier le chemin balisé du parcours le plus courant et d'en construire juste assez pour l'améliorer de façon démontrable. Microsoft Learn rappelle que la solution de moindre effort tend à être la bonne pour commencer, mais que la maintenance décide souvent du succès de l'investissement.

Le socle minimal

Pour chaque tâche fréquente, le chemin balisé minimal et la sortie de secours documentée
Tâche	Chemin balisé minimal	Sortie de secours documentée
Créer un service	Dépôt modèle versionné : Dockerfile, CI, manifests, tableau de bord, runbook à compléter	Service créé à la main, soumis à la liste de contrôle du chapitre 5
Déployer	Image référencée par digest ; demande de fusion dans le dépôt de déploiement ; contrôleur GitOps ; retour arrière par revert	Déploiement manuel tracé, régularisé dans Git
Obtenir une base de données	Module Terraform versionné sur le service managé du fournisseur, sauvegardes actives par défaut	Base propre à l'équipe, restauration jouée
Voir journaux et métriques	Étiquettes standard, collecte, tableau de bord et quelques alertes créés avec le service	Instrumentation propre, alertes vers un destinataire nommé
Obtenir un secret	Coffre managé synchronisé vers le cluster, rien dans Git	Lecture directe du coffre par l'application
Accéder aux environnements	Authentification unique, groupes reliés à des rôles, clients OIDC déclarés dans Git	Accès d'urgence documenté et testé

Le déploiement suit les principes OpenGitOps : état désiré déclaratif, versionné et immuable, tiré automatiquement par des agents logiciels qui l'observent et le réconcilient en continu. Pour les secrets, External Secrets Operator lit un gestionnaire externe (AWS Secrets Manager, HashiCorp Vault, Google Secret Manager, Azure Key Vault, entre autres) et injecte les valeurs dans des Secrets Kubernetes via les ressources ExternalSecret et SecretStore. Les clients OIDC (OpenID Connect) déclarés dans Git posent des questions de propriété de champ, traitées dans l'article Piloter la configuration Keycloak en GitOps : adoption, dérive et suppression de champs.

Le modèle de service, et comment il vieillit

Un dépôt créé depuis un modèle GitHub démarre avec un seul commit, sans l'historique du modèle : corriger le modèle ne corrige pas les services déjà créés. La propagation se décide donc dès le départ. Copier traite ce cas : copier update met le projet à jour vers la dernière version étiquetée du modèle en reprenant les réponses enregistrées lors de la dernière génération ou mise à jour, à condition que le projet contienne un fichier .copier-answers.yml valide et que modèle et projet soient versionnés dans Git, le modèle avec des tags. Les conflits se résolvent à la main avant le commit.

# Exemple fictif : dépôt modèle d'un service web
modele-service/
  copier.yml                  # nom, équipe propriétaire, base de données oui ou non
  Dockerfile
  .github/workflows/ci.yaml   # construire, tester, analyser, pousser par digest
  deploy/base/                # Deployment, Service, sondes, ressources, PodDisruptionBudget
  deploy/overlays/preproduction/
  deploy/overlays/production/
  observabilite/              # tableau de bord, alertes sur symptômes
  docs/runbook.md             # symptôme, diagnostic, action, retour arrière

Le premier chemin balisé à construire : créer un service et le déployer jusqu'en production.

Le premier chemin balisé, de la création du service à la production

Le schéma suit un nouveau service depuis le modèle versionné jusqu'à la production, avec la sortie de secours et le retour arrière par revert.

Schéma défilable horizontalement ; sa version textuelle complète suit.

Lire le schéma sous forme textuelle

Un développeur a besoin d'un nouveau service et vérifie si le modèle couvre son besoin.
Si oui, il crée le dépôt depuis le modèle versionné. Sinon, il emprunte la sortie de secours : service créé à la main et soumis à la liste de contrôle, qui mène à la même situation finale.
Sur le chemin balisé, il ouvre une demande de fusion.
La CI construit l'image, la teste, l'analyse et la pousse vers le registre.
Le dépôt de déploiement est mis à jour pour la préproduction.
Le contrôleur GitOps synchronise l'environnement.
Si le service n'est pas sain, ou si ses métriques et journaux ne sont pas visibles, la modification est annulée par un revert et une nouvelle demande de fusion relance le cycle à l'étape 3.
Si tout est vérifié, la promotion en production passe par une demande de fusion approuvée.
Le service arrive en production avec un propriétaire et un runbook renseignés.

Modèle explicatif, sans donnée client, d'après le livre blanc Platforms de la CNCF et les principes OpenGitOps cités en fin d'article.

Kubernetes ou non, construire ou acheter

Kubernetes : une brique, pas un prérequis

La crainte « pas de Kubernetes » est légitime : un chemin balisé se construit de la même façon sur un service de conteneurs managé, comme Amazon ECS avec Fargate, ou sur un PaaS. La question : les charges et l'équipe justifient-elles un orchestrateur ?

Critères de décision entre un service de conteneurs managé ou un PaaS et Kubernetes managé
Critère	Service de conteneurs managé ou PaaS	Kubernetes managé
Charges	Services web et tâches planifiées homogènes	Charges hétérogènes : traitements de données, services à état, contrôleurs spécialisés
Écosystème	Services du fournisseur suffisants	Extensions de l'API nécessaires : GitOps, secrets, politiques d'admission
Portabilité	Pas d'exigence de sortie à court terme	Exigence réelle, à vérifier couche par couche
Exploitation	Personne pour absorber montées de version et diagnostics	Plusieurs personnes capables de le faire, pas une seule

Choisir Kubernetes, c'est accepter un calendrier : le projet maintient les branches des trois dernières versions mineures, chacune avec environ un an de correctifs. Sur Amazon EKS, une version reçoit 14 mois de support standard puis 12 mois de support étendu facturé en supplément (si le support étendu n'est pas désactivé) ; au terme du cycle, EKS met à niveau d'office le plan de contrôle, mais pas les nœuds autogérés ni les groupes de nœuds managés. Les montées de version deviennent une activité récurrente de la plateforme ; le coût d'un retard se chiffre avec la méthode de l'article Support étendu EKS et RDS : calendrier de fin 2026, tarifs et calcul de l'exposition.

Rester sur un service de conteneurs managé est donc une décision de plateforme à part entière. Une migration ultérieure vers Kubernetes peut se conduire service par service, et une exigence de portabilité se vérifie couche par couche. Si Kubernetes est retenu, l'exposition des services se choisit dès le départ, avec le reste du modèle.

Construire ou acheter l'interface

Ce que chaque option d'interface apporte, ce qu'elle demande d'entretenir et quand elle est pertinente
Option	Ce qu'on obtient	Ce qu'il faut entretenir	Pertinent quand
Modèles et GitOps, sans portail	Dépôt modèle, CI, dépôt de déploiement ; l'interface est la forge	Modèles et leur propagation, modules Terraform, contrôleur GitOps	Par défaut, tant que retrouver un service et son propriétaire reste simple
Backstage auto-hébergé	Cadre open source de portail : catalogue, modèles logiciels, TechDocs, extensions	Une application : versions, extensions, hébergement, authentification, données du catalogue	Quand la découverte des services devient le problème et qu'une personne en fait son produit
Portail géré	Backstage proposé en service par un éditeur, ou portail propriétaire	Modèle de données, intégrations, contrat, réversibilité	Quand un catalogue est nécessaire mais que personne ne peut entretenir Backstage

Le coût de Backstage est surtout un coût de maintenance. Projet en incubation à la CNCF, c'est un « cadre open source pour construire des portails développeurs » : l'adoptant construit et héberge sa propre application. La ligne principale sort chaque mois ; la mise à jour passe par yarn backstage-cli versions:bump, et les paquets app et backend créés par create-app ne reçoivent pas automatiquement les évolutions du gabarit : elles se reportent depuis le changelog du paquet @backstage/create-app, ou à l'aide de l'outil Upgrade Helper. Extensions et données du catalogue se dégradent sans responsable : Backstage devient un produit interne à part entière.

Microsoft Learn observe que les développeurs adoptent plus volontiers une capacité exposée dans un outil qu'ils utilisent déjà (éditeur, forge, ligne de commande, portail interne existant) que dans une interface entièrement nouvelle. Le portail vient donc après les chemins balisés : il les expose, il ne les remplace pas.

Piloter la plateforme comme un produit : équipe, anti-modèles, mesure

Des utilisateurs, une feuille de route, une adoption choisie

Pour la CNCF, une plateforme se conçoit et évolue selon les besoins de ses utilisateurs, comme tout produit logiciel. L'équipe plateforme étudie ces besoins, tient la feuille de route, fait connaître la valeur proposée et gère les interfaces ; elle peut commencer avec un nombre limité d'équipes applicatives engagées. Les modes d'interaction de Team Topologies donnent la forme de la relation : collaboration temporaire avec une équipe pilote, avec des critères de sortie explicites, pour découvrir le besoin, puis « X-as-a-Service » une fois le chemin stabilisé. Une note produit d'une page cadre le tout : utilisateurs, problèmes traités, non-objectifs, sorties de secours, mesures suivies.

Qui l'exploite

Trois organisations sont possibles : une ou deux personnes à temps partiel, une petite équipe dédiée, ou une équipe interne appuyée par un tiers sur un périmètre écrit. Vu les résultats DORA cités plus haut, une équipe dédiée n'est pas un préalable au premier chemin balisé ; la CNCF demande de la doter selon son domaine et le nombre d'équipes servies.

Deux règles valent partout. Les composants de la plateforme (CI, contrôleur GitOps, registre, cluster, coffre) sont eux-mêmes en production : chacun a un propriétaire nommé, une règle explicite de prise en charge des incidents (plage horaire, destinataire, escalade) et un runbook. Et le « bus factor », nombre de personnes dont l'absence simultanée rendrait la plateforme impossible à opérer, doit dépasser un. Plusieurs mesures le relèvent : infrastructure as code dans les dépôts de l'entreprise, accès d'urgence détenus en interne, runbooks exécutables par un tiers, restaurations jouées par l'équipe interne. Un filet de sécurité extérieur ne vaut que s'il laisse l'équipe autonome.

Les anti-modèles

Le portail d'abord. C'est le piège « Build it and they will come » décrit par DORA : une plateforme bâtie sur des hypothèses, sans recherche auprès des utilisateurs.
Abstraire Kubernetes trop tôt. Déplacer la complexité vers la plateforme (« shift down », dit DORA) est le bon objectif, mais une abstraction maison qui masque tout devient un produit à documenter, versionner et déboguer ; quand elle fuit, l'équipe doit comprendre deux couches. Mieux vaut des conventions lisibles dans le modèle (une base Kustomize ou un chart Helm commun), et n'abstraire que ce qui se répète.
Une plateforme obligatoire sans sortie de secours. DORA parle de « cage dorée » ; son rapport 2024 relève une baisse de débit de 6 % chez les répondants tenus d'utiliser exclusivement la plateforme. La sortie de secours reste permise, sous la liste de contrôle et avec un propriétaire nommé ; les sorties fréquentes désignent le prochain chemin à construire.
Une équipe plateforme d'une personne. La plateforme risque de devenir la nouvelle dépendance à une personne clé qu'elle devait supprimer.
Tout livrer d'un coup. Le piège « Big bang » de DORA : construire une plateforme complète avant de livrer quoi que ce soit.

Mesurer l'usage, pas les fonctionnalités

La CNCF range les mesures en trois familles : satisfaction et productivité des utilisateurs, efficacité de l'organisation, livraison. DORA mesure la livraison avec cinq métriques qui prolongent les « four keys » historiques : délai de changement, fréquence de déploiement, temps de rétablissement après un déploiement en échec, taux d'échec des changements, taux de reprise des déploiements. Elles s'appliquent service par service.

Pour chaque mesure, ce qu'elle révèle, comment la collecter et le piège à éviter
Mesure	Ce qu'elle révèle	Collecte	Piège
Métriques DORA, par service	Effet sur le débit et la stabilité	Forge, CI, contrôleur GitOps, outil d'incidents	En faire un objectif, comparer des équipes
Délai entre la création d'un service et son premier déploiement en production	Efficacité du chemin balisé	Dates de création du dépôt et du premier déploiement	Mesurer sur un service jouet
Délai entre l'arrivée d'une personne et sa première modification livrée	Qualité de l'intégration	Date d'arrivée, première demande de fusion déployée	Confondre avec la formation au métier
Demandes à l'équipe plateforme : nombre, nature, délai	Ce qui n'est pas encore en libre-service	Étiquettes de l'outil de tickets	Décourager les demandes pour faire baisser le nombre
Adoption : services sur le chemin, sorties de secours	Utilité réelle	Inventaire des dépôts, fichiers de réponses du modèle	Compter les créations, pas l'usage durable
Satisfaction	Irritants	Enquête courte et régulière	Enquête sans suite visible

La référence est la mesure de départ, relevée avant le premier chemin balisé.

Un plan de démarrage en trois étapes et une liste de contrôle de mise en production

Ce plan est une proposition de méthode, pas un engagement de délai : chaque étape se termine par un critère de passage, et chaque organisation en fixe la durée selon sa taille et son existant. Il suit Microsoft Learn : piloter une nouvelle capacité sur de nouvelles applications plutôt que par une migration, dont les besoins particuliers n'apparaissent qu'en cours de route.

Livrables et critère de passage de chacune des trois étapes du plan de démarrage
Étape	Livrables	Critère de passage
1. Observer	Inventaire des demandes répétitives, mesure de départ, entretiens avec des développeurs de plusieurs équipes, note produit, équipe pilote choisie	Les deux ou trois tâches les plus fréquentes sont nommées, avec leur délai actuel
2. Premier chemin balisé	Dépôt modèle, CI, dépôt de déploiement GitOps, tableau de bord et alertes par défaut, documentation, sortie de secours écrite	L'équipe pilote crée et déploie un nouveau service sans solliciter l'équipe plateforme
3. Élargir et décider	Base de données par module Terraform, synchronisation des secrets, liste de contrôle, ouverture à d'autres équipes, revue des mesures	Décisions écrites pour la période suivante : portail ou non, Kubernetes ou non, organisation de l'équipe

Liste de contrôle de mise en production

Elle vaut pour tout service qui entre en production, chemin balisé ou sortie de secours ; le modèle la satisfait par construction.

Image construite par la CI depuis un commit identifié, déployée par digest ou tag immuable.
Déploiement par demande de fusion ; retour arrière par revert joué au moins une fois.
Sondes distinctes : readinessProbe retire le pod du trafic sans le redémarrer, livenessProbe redémarre le conteneur, startupProbe protège un démarrage lent.
Requêtes CPU et mémoire déclarées.
Au moins deux réplicas et un PodDisruptionBudget (minAvailable ou maxUnavailable) contre les interruptions volontaires, comme le drainage d'un nœud ; il n'empêche pas les interruptions involontaires, comme une panne matérielle.
Base managée, sauvegardes actives, restauration jouée et datée.
Aucun secret dans Git ni dans des variables de CI recopiées.
Journaux structurés, métriques et tableau de bord reliés au service.
Alertes sur des symptômes visibles des utilisateurs, vers un destinataire nommé ; arrivée vérifiée.
Équipe propriétaire nommée dans le dépôt ; runbook court (symptôme, diagnostic, action, retour arrière).
Accès de production nominatifs via l'authentification unique, aucun compte partagé.
Dépendances externes, quotas et limites du fournisseur identifiés.

Le cadrage d'un premier socle, du choix de l'orchestrateur à la chaîne GitOps, est décrit sur la page Plateforme Kubernetes : livrer sans perdre le contrôle ; la préparation du passage en production, sur la page Mise en production Kubernetes : ouvrir par étapes.

Sources officielles et limites de lecture

Les faits cités sont arrêtés au 29 septembre 2026 et datés dans les sources ci-dessous.

Limites. Les chiffres DORA sont des corrélations tirées d'une enquête : ils décrivent une population, pas une organisation donnée, et ne prouvent aucune causalité. Le livre blanc et le modèle de maturité sont des documents communautaires, pas des normes. Aucun ordre de grandeur de délai, de volume de tickets ou de taille d'équipe n'est proposé, faute de source primaire. Le plan en trois étapes est une proposition de méthode, pas un calendrier. Le coût de Backstage est décrit qualitativement, et aucun éditeur de portail n'est comparé. Les outils cités sont des exemples, pas des recommandations. Les calendriers de support changent à chaque version : la page officielle prime.

Sources

Platforms White Paper, CNCF TAG App Delivery, https://tag-app-delivery.cncf.io/whitepapers/platforms/, consulté le 29/09/2026.
Platforms white paper, README (historique des versions), dépôt GitHub cncf/tag-app-delivery, https://github.com/cncf/tag-app-delivery/blob/main/platforms-whitepaper/README.md, consulté le 29/09/2026.
Platform Engineering Maturity Model, CNCF TAG App Delivery, https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/, consulté le 29/09/2026.
Accelerate State of DevOps Report 2024, chapitre « Platform engineering », DORA, https://dora.dev/research/2024/dora-report/2024-dora-accelerate-state-of-devops-report.pdf, consulté le 29/09/2026.
Capabilities: Platform engineering, DORA, https://dora.dev/capabilities/platform-engineering/, consulté le 29/09/2026.
DORA's software delivery performance metrics, DORA, https://dora.dev/guides/dora-metrics/, consulté le 29/09/2026.
Key concepts, Team Topologies, https://teamtopologies.com/key-concepts, consulté le 29/09/2026.
Team Topologies Interaction Modes: Breaking Through Common Misconceptions, Team Topologies, https://teamtopologies.com/news-blogs-newsletters/2025/2/21/team-topologies-interaction-modes-breaking-through-common-misconceptions, consulté le 29/09/2026.
Plan and prioritize, guide Platform engineering, Microsoft Learn, https://learn.microsoft.com/en-us/platform-engineering/plan, consulté le 29/09/2026.
Overview, documentation Kubernetes, https://kubernetes.io/docs/concepts/overview/, consulté le 29/09/2026.
Releases, Kubernetes, https://kubernetes.io/releases/, consulté le 29/09/2026.
Understand the Kubernetes version lifecycle on EKS, Amazon EKS User Guide, https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html, consulté le 29/09/2026.
Pod Lifecycle, documentation Kubernetes, https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/, consulté le 29/09/2026.
Disruptions, documentation Kubernetes, https://kubernetes.io/docs/concepts/workloads/pods/disruptions/, consulté le 29/09/2026.
Specifying a Disruption Budget for your Application, documentation Kubernetes, https://kubernetes.io/docs/tasks/run-application/configure-pdb/, consulté le 29/09/2026.
What is Backstage?, Backstage, https://backstage.io/docs/overview/what-is-backstage, consulté le 29/09/2026.
Keeping Backstage Updated, Backstage, https://backstage.io/docs/getting-started/keeping-backstage-updated, consulté le 29/09/2026.
Creating a repository from a template, GitHub Docs, https://docs.github.com/en/repositories/creating-and-managing-repositories/creating-a-repository-from-a-template, consulté le 29/09/2026.
Updating a project, documentation Copier, https://copier.readthedocs.io/en/stable/updating/, consulté le 29/09/2026.
GitOps Principles v1.0.0, OpenGitOps, https://opengitops.dev/, consulté le 29/09/2026.
External Secrets Operator, documentation, https://external-secrets.io/latest/, consulté le 29/09/2026.

Navigation