Platform Engineering : l'évolution du DevOps

Le Platform Engineering représente une évolution naturelle des pratiques DevOps. Face à la complexité croissante de l’écosystème (Kubernetes, Terraform, CI/CD, observabilité, sécurité), une nouvelle approche émerge pour réduire la charge cognitive des développeurs.

Qu’est-ce que le Platform Engineering ?

Le Platform Engineering a été formalisé en 2018 par Evan Bottcher (ThoughtWorks) dans son article fondateur. C’est une réponse à un problème émergent dans les organisations DevOps matures.

Le problème

Kubernetes, Terraform, CI/CD, observabilité, sécurité, compliance… Les développeurs doivent maîtriser de plus en plus d’outils pour déployer leur code.

Résultat : ils passent moins de temps à développer et plus de temps à configurer de l’infrastructure.

La solution : l’Internal Developer Platform (IDP)

Une équipe dédiée (Platform Team) construit une Internal Developer Platform (IDP) — une plateforme qui abstrait la complexité et offre des interfaces simples aux développeurs.

Les caractéristiques d’une IDP :

Self-service : Les développeurs peuvent provisionner ce dont ils ont besoin sans ouvrir de ticket
Abstraction : La complexité sous-jacente est cachée derrière des interfaces simples
Golden Paths : Des chemins balisés qui intègrent les bonnes pratiques par défaut
Produit, pas projet : La plateforme est traitée comme un produit avec ses utilisateurs (les développeurs)

Platform Engineering vs DevOps

Aspect	DevOps traditionnel	Platform Engineering
Modèle	Chaque équipe gère son infra	Une plateforme mutualisée
Charge cognitive	Élevée (chaque dev doit tout savoir)	Réduite (la plateforme abstrait)
Golden paths	Chacun fait comme il veut	Chemins balisés, bonnes pratiques intégrées
Self-service	Variable	Objectif central
Équipes	Intégration Dev/Ops dans chaque équipe	Équipe plateforme + équipes produit
Scaling	Difficile (expertise dupliquée)	Économies d’échelle

Golden Paths : chemins balisés pour les développeurs sur une plateforme interne

Les Golden Paths

Les Golden Paths (ou “paved roads”) sont des chemins pré-configurés qui permettent aux développeurs de livrer rapidement tout en respectant les standards de l’organisation.

Exemple concret

Sans Golden Path (DevOps classique) :

Pour déployer un nouveau microservice, le développeur doit :
1. Créer un repo Git
2. Configurer la CI/CD (50+ lignes de YAML)
3. Écrire le Dockerfile
4. Créer les manifests Kubernetes (Deployment, Service, Ingress, ConfigMap, Secret...)
5. Configurer le monitoring (ServiceMonitor, alertes Prometheus)
6. Mettre en place les dashboards Grafana
7. Configurer les logs (Fluentd/Loki)
8. Définir les Network Policies
9. Configurer les scans de sécurité
10. ...et 20 autres étapes

Avec Golden Path (Platform Engineering) :

Pour déployer un nouveau microservice, le développeur :
1. Remplit un formulaire : nom, langage, type de service
2. La plateforme génère automatiquement tout le reste
3. En 5 minutes, il peut commencer à coder

Ce que ça change

Pour les développeurs :

“Je veux déployer mon service” → Un formulaire, pas 50 fichiers YAML
Les bonnes pratiques (sécurité, observabilité) sont intégrées par défaut
Moins de temps à configurer, plus de temps à coder
Courbe d’apprentissage réduite pour les nouveaux

Pour les Ops/SRE :

Standardisation : moins de configurations “artisanales” à maintenir
Économies d’échelle : une plateforme pour N équipes
Focus sur la plateforme, pas sur le support ad-hoc
Réduction du “toil” (travail répétitif sans valeur)

Pour l’organisation :

Temps de mise sur le marché réduit
Compliance et sécurité intégrées par défaut
Onboarding accéléré des nouveaux développeurs

La Platform Team

Rôle et positionnement

La Platform Team :

Traite la plateforme comme un produit interne
Les développeurs sont ses utilisateurs/clients
A un Product Owner et fait du discovery utilisateur
Mesure la satisfaction développeur (Developer Experience - DevEx)
Itère sur les fonctionnalités selon le feedback

Compétences typiques

Domaine	Expertise
Infrastructure	Kubernetes, cloud providers, networking
Automatisation	Terraform, Crossplane, Backstage
CI/CD	GitLab CI, GitHub Actions, ArgoCD
Observabilité	Prometheus, Grafana, tracing
Sécurité	Policy as Code, secrets management
Developer Experience	Portails développeurs, documentation

Outils de Platform Engineering

Backstage (Spotify)

Backstage est un framework open-source pour construire des portails développeurs. Il offre :

Catalogue de services : Inventaire de tous les services de l’organisation
Templates : Création de nouveaux services via des formulaires
Plugins : Intégration avec CI/CD, monitoring, documentation
TechDocs : Documentation centralisée (Docs-as-Code)

Crossplane

Crossplane permet de définir l’infrastructure via des Custom Resources Kubernetes :

Provisionnement de ressources cloud via kubectl
Compositions réutilisables
GitOps natif avec ArgoCD

Autres outils

Outil	Usage
Port	Alternative à Backstage (SaaS)
Humanitec	Platform Orchestration
Kratix	Framework de plateforme
ArgoCD	GitOps pour Kubernetes

Quand adopter le Platform Engineering ?

Indicateurs qu’il est temps

Signal	Description
Duplication	Chaque équipe réinvente la roue (CI/CD, monitoring…)
Charge cognitive	Les développeurs passent plus de temps sur l’infra que sur le code
Onboarding lent	Les nouveaux mettent des semaines à être productifs
Configurations divergentes	Chaque service est configuré différemment
Support constant	L’équipe Ops/SRE passe son temps en support ad-hoc
Scaling difficile	L’ajout de nouvelles équipes multiplie le travail d’infra

Quand c’est prématuré

Contexte	Pourquoi attendre
Petite équipe (< 20 devs)	L’overhead d’une Platform Team ne se justifie pas
Peu de services	La standardisation apporte peu de valeur
Stack simple	Si vous n’avez que quelques conteneurs, pas besoin d’une IDP
Organisation immature en DevOps	Maîtrisez d’abord les bases avant d’abstraire

Jour 1 d’un nouveau développeur :

Demander les accès (3 jours d’attente)
Comprendre comment créer un nouveau service (documentation dispersée)
Copier-coller depuis un service existant
Adapter les 47 fichiers de configuration
Demander de l’aide sur Slack 15 fois
Premier déploiement après 3 semaines

Création d’un nouveau microservice :

2-3 semaines de configuration avant d’écrire une ligne de code métier
Configuration unique, difficile à maintenir
Oublis fréquents (monitoring, sécurité, logging)

Mesurer le succès

Métriques DevEx (Developer Experience)

Métrique	Description	Cible
Time to First Deployment	Temps pour qu’un nouveau dev déploie	< 1 jour
Time to Create Service	Temps pour créer un nouveau service	< 1 heure
Self-service ratio	% d’actions faisables sans ticket	> 80%
Developer satisfaction	Score NPS interne	> 50
Cognitive load	Nombre d’outils à maîtriser	Réduction de 50%+

Les métriques DORA restent pertinentes

Le Platform Engineering vise à améliorer les métriques DORA :

Deployment Frequency ↑ : Plus facile de déployer
Lead Time ↓ : Moins de configuration manuelle
Change Failure Rate ↓ : Bonnes pratiques intégrées
MTTR ↓ : Environnements standardisés, plus faciles à debugger

À retenir

Platform Engineering = DevOps à l’échelle : C’est une évolution, pas un remplacement
La charge cognitive est le problème : Les développeurs passent trop de temps sur l’infra
L’IDP est la solution : Une plateforme self-service avec des Golden Paths
La Platform Team est une équipe produit : Ses clients sont les développeurs
Pas pour tout le monde : Pertinent à partir de 3-4 équipes et une certaine complexité
Mesurer la DevEx : Le succès se mesure à la satisfaction et productivité des développeurs

Ressources externes

Platform Engineering on Kubernetes — Introduction au Platform Engineering
Backstage.io — Framework de portail développeur (Spotify)
Team Topologies — Modèles d’organisation d’équipes
Internal Developer Platform — Ressources sur les IDP