Platform Engineering vs DevOps : ce qui a vraiment changé (et ce qui n'a pas changé)

Le passage de DevOps au Platform Engineering

DevOps disait "tu le construis, tu le gères." Chaque développeur gère sa propre infrastructure, déploie ses propres services, configure son propre monitoring. En théorie, ça crée de la responsabilisation. En pratique, ça crée 15 façons différentes de déployer un service, 8 configurations de monitoring différentes, et chaque équipe qui réinvente le même pipeline CI/CD.

Le platform engineering est la correction. Au lieu que chaque équipe construise son infrastructure à partir de zéro, une équipe plateforme fournit des outils opiniâtres en libre-service qui rendent la bonne chose facile et la mauvaise chose difficile.

Le changement est réel mais survendu. Pour les équipes de moins de 30 ingénieurs, le platform engineering est souvent du surcoût. Pour les équipes de plus de 50, c'est nécessaire. Cet article couvre les patterns pratiques. Pour voir comment on déploie l'infrastructure, consulte notre guide IaC et notre guide Kubernetes.

Ce qu'est vraiment le Platform Engineering

Le platform engineering n'est pas un outil. Ce n'est pas Backstage. Ce n'est pas Kubernetes. C'est une approche : construire des outils internes qui rendent les développeurs productifs sans qu'ils aient besoin de devenir des experts en infrastructure.

La métrique clé : le temps jusqu'au premier deploy d'un nouveau service. Si un développeur met 2 jours pour passer de "j'ai besoin d'un nouveau service" à "il tourne en staging", ta plateforme a un problème. Si ça prend 15 minutes, ta plateforme fonctionne.

Golden Paths

Un golden path est un template opiniâtre pour créer un nouveau service. Il inclut tout ce dont un développeur a besoin : structure du projet, pipeline CI/CD, Dockerfile, manifestes Kubernetes, configuration du monitoring et documentation.

golden-path-typescript-api/
├── src/
│   ├── index.ts                    # Point d'entrée avec health check
│   ├── routes/                     # Définitions des routes
│   └── services/                   # Logique métier
├── test/
│   ├── unit/
│   └── integration/
├── Dockerfile                      # Build multi-stage optimisé
├── .github/workflows/
│   └── ci-cd.yaml                  # Build, test, push, deploy
├── kubernetes/
│   ├── base/
│   │   ├── deployment.yaml
│   │   ├── service.yaml
│   │   └── kustomization.yaml
│   └── overlay/
│       ├── staging/
│       └── production/
├── monitoring/
│   ├── alerts.yaml                 # Règles d'alerte standards
│   └── dashboard.json              # Template de dashboard Grafana
├── docs/
│   └── runbook.md                  # Template de runbook opérationnel
├── .env.example
├── package.json
├── tsconfig.json
└── README.md

Un développeur lance platform create-service --name my-api --template typescript-api, répond à 5 questions (nom du service, équipe, besoin d'une base de données, public ou interne), et obtient un projet entièrement fonctionnel avec CI/CD, monitoring et manifestes de déploiement. Premier deploy en 15 minutes.

Principes du Golden Path

Ce qui fait un bon vs mauvais Golden Path

Infrastructure en libre-service

Les développeurs ne devraient pas avoir besoin de créer un ticket pour obtenir une base de données, une instance Redis ou un nouveau namespace Kubernetes. Le libre-service signifie qu'ils peuvent provisionner ce dont ils ont besoin via une UI, un CLI ou une API.

// Platform CLI : provisionner une base de données PostgreSQL
// $ platform db create --name my-api-db --size small --env staging
interface DatabaseRequest {
    name: string;
    size: 'small' | 'medium' | 'large';  // Opiniâtre : 3 tailles, pas de specs arbitraires
    environment: 'dev' | 'staging' | 'production';
    team: string;
    backupRetention: number;  // Par défaut : 7 jours staging, 30 jours production
}

// En coulisses : Terraform s'exécute, crée l'instance RDS,
// stocke les credentials dans Secrets Manager, crée un K8s secret,
// ajoute un dashboard de monitoring, notifie l'équipe

Ce qu'il faut proposer en libre-service

La frontière : libre-service pour les ressources scopées à une équipe. Sur demande pour les ressources qui affectent toute l'organisation.

Portails développeurs internes

Un portail développeur interne est un catalogue de tous les services, leurs propriétaires, leurs APIs, leurs runbooks et leur état de santé. Backstage (par Spotify) est le plus connu, mais ce n'est pas la seule option.

Ce qu'un portail doit montrer

Backstage vs Alternatives

Pour les équipes de moins de 30 ingénieurs, Backstage c'est de l'overkill. Un dépôt Git bien organisé avec des fichiers README, un wiki Notion partagé et un simple tableur de catalogue de services couvre 80% du besoin.

Pour les équipes de plus de 50 ingénieurs, le problème du catalogue devient réel. Des services sont créés et oubliés. Les propriétaires partent et personne ne sait qui maintient quoi. Un portail avec suivi de la propriété et dashboards de santé devient essentiel.

Le problème de la documentation

Personne ne lit ton wiki. Ce n'est pas un problème de personnes. C'est un problème d'emplacement. La documentation qui vit séparément du code qu'elle décrit devient obsolète en quelques semaines.

Documentation qui fonctionne

Architecture Decision Records (ADRs)

Chaque décision technique significative reçoit un ADR :

# ADR-003 : Utiliser PostgreSQL comme base de données principale

## Statut : Accepté

## Contexte
On a besoin d'une base de données pour le nouveau service. Options considérées : PostgreSQL, MySQL, DynamoDB.

## Décision
PostgreSQL 15 via le provisioning de base de données en libre-service de la plateforme.

## Conséquences
- L'outillage standard (sauvegardes, monitoring, migrations) fonctionne directement
- L'équipe n'a pas besoin d'expertise DynamoDB
- Latence légèrement plus élevée que DynamoDB pour les patterns d'accès clé-valeur (acceptable)

Les ADRs empêchent de redébattre les mêmes décisions. Quand un nouveau membre de l'équipe demande "pourquoi PostgreSQL ?", la réponse est dans le repo, pas dans la mémoire de quelqu'un.

Mesurer l'expérience développeur

Si tu investis dans une plateforme, mesure si elle aide réellement :

Les quatre premières sont des métriques DORA. Les trois dernières sont spécifiques à la plateforme. Suis-les toutes. Si le time-to-first-deploy s'améliore mais que la satisfaction développeur baisse, la plateforme ajoute de la complexité sans valeur.

Quand le Platform Engineering est du surcoût

Le platform engineering n'est pas gratuit. Une équipe plateforme coûte 2-5 ingénieurs à temps plein. Les golden paths ont besoin de maintenance. Les outils en libre-service ont besoin de développement et de support. Un portail a besoin de contenu.

Ne construis pas de plateforme quand

• Ton équipe fait moins de 20 ingénieurs (le surcoût dépasse le bénéfice)
• Tu as moins de 5 services (pas assez d'opportunité de standardisation)
• Tu es une startup qui pourrait pivoter (la plateforme sera gaspillée)
• Ton processus d'ingénierie est déjà rapide (si le time-to-deploy est déjà à 30 minutes, tu n'as pas besoin d'une équipe plateforme pour l'améliorer)

Construis une plateforme quand

• Tu as 50+ ingénieurs qui déploient 10+ services
• La création d'un nouveau service prend plus d'un jour
• Les équipes réinventent les mêmes patterns d'infrastructure
• L'astreinte est douloureuse parce que chaque service a un monitoring différent
• La satisfaction développeur est basse à cause de la friction d'infrastructure

La plateforme minimale viable pour une équipe de 30-50 personnes :

1. Un template golden path (le type de service le plus courant)
2. Template de pipeline CI/CD (partagé, paramétré)
3. Monitoring standard (dashboards Grafana auto-provisionnés)
4. Catalogue de services (même si c'est juste un tableur)
5. Un guide plateforme d'une page ("comment créer un nouveau service")

C'est tout. Pas de Backstage, pas de portail custom, pas d'infrastructure en libre-service. Juste des templates et des standards. Ajoute de la complexité quand l'équipe dépasse l'approche simple.

Erreurs courantes

1. Construire une plateforme avant d'avoir de la standardisation. Si chaque service utilise un langage, un framework et une méthode de déploiement différents, une plateforme ne peut pas aider. Standardise d'abord, puis construis la plateforme.

2. Backstage avant 50 ingénieurs. Backstage est puissant mais complexe. Pour les petites équipes, le coût de mise en place et de maintenance dépasse le bénéfice.

3. Des golden paths qui ne sont jamais mis à jour. Un template d'il y a 2 ans avec des dépendances obsolètes et des patterns dépréciés fait plus de mal que de bien. Maintiens-le comme un produit.

4. Tout en libre-service. Les rôles IAM et les changements réseau ne devraient pas être en libre-service. Le blast radius d'une erreur est trop grand.

5. Mesurer l'activité, pas les résultats. "On a construit 15 fonctionnalités de plateforme" ce n'est pas du succès. "Le time-to-first-deploy est passé de 2 jours à 30 minutes" c'est du succès.

6. Ignorer la satisfaction développeur. Une plateforme qui force les développeurs dans des patterns qu'ils détestent sera contournée. Parle à tes utilisateurs (les développeurs) régulièrement.

7. Pas de documentation. Une plateforme en libre-service sans documentation, c'est juste un autre type de boîte noire.

Points clés à retenir

• Le platform engineering n'est pas un outil, c'est une approche. Construis des outils internes qui rendent les développeurs productifs sans qu'ils aient besoin d'expertise en infrastructure. Le golden path est le produit central.

• Le time to first deploy est la métrique clé. Si un développeur peut passer d'une idée à un service fonctionnel en 15 minutes, la plateforme fonctionne. Si ça prend 2 jours, non.

• Commence simple. Un golden path, un template CI/CD, du monitoring standard. Ajoute de la complexité quand l'approche simple ne suffit plus. La plupart des équipes de moins de 30 ingénieurs n'ont pas besoin de Backstage.

• La documentation vit avec le code. Docs API auto-générées, runbooks dans le repo, ADRs pour les décisions. Les pages wiki deviennent obsolètes. Les docs dans le repo restent à jour.

• Mesure les résultats, pas l'activité. Métriques DORA plus satisfaction développeur. Si les chiffres ne s'améliorent pas, l'investissement plateforme ne fonctionne pas.

• L'équipe plateforme est une équipe produit. Leurs utilisateurs sont les développeurs. Leur produit est la plateforme interne. Ils ont besoin de boucles de feedback, de recherche utilisateur et d'itération, comme n'importe quelle équipe produit.

On construit des plateformes internes et de l'outillage développeur dans le cadre de nos services cloud et de notre pratique de consulting. Si tu as besoin d'aide sur ta stratégie de platform engineering, parle à notre équipe ou demande un devis. Consulte aussi notre page méthodologie pour voir comment on aborde la culture d'ingénierie.