Platform Engineering : Traiter votre infrastructure comme un produit

Le Platform Engineering est LA tendance qui transforme le DevOps en 2025. Mais au-delà du buzzword, qu’est-ce qui change vraiment ? Retour d’expérience après avoir construit une plateforme interne pour 50+ développeurs.

Le problème : DevOps n’a pas tenu ses promesses

La promesse initiale

“You build it, you run it” — Werner Vogels, Amazon CTO

La réalité 5 ans après

Développeurs noyés dans Kubernetes, Terraform, CI/CD
Copier-coller de config entre projets
10 façons différentes de déployer
Onboarding nouveau dev : 2 semaines d’infra

Constat : Chaque équipe réinvente la roue.

Platform Engineering : La solution

Principe de base

Traiter l’infrastructure comme un produit interne avec des utilisateurs (les développeurs) et des features.

Ce n’est PAS du Platform Engineering

❌ “On a fait un repo avec des scripts Terraform” ❌ “Voici 50 pages de doc sur comment déployer” ❌ “Demandez au channel #ops-help”

C’est du Platform Engineering

✅ git push → Déploiement automatique ✅ Self-service : créer env de dev en 1 clic ✅ Documentation intégrée et exemples ✅ Observabilité par défaut ✅ Sécurité built-in

Architecture d’une plateforme moderne

┌──────────────────────────────────────┐
│      Developer Experience Layer      │
│  (CLI, Portal, IDE extensions)       │
└────────────┬─────────────────────────┘
             │
┌────────────▼─────────────────────────┐
│     Platform Orchestration Layer     │
│  (Backstage, Portal Interno)         │
└────────────┬─────────────────────────┘
             │
┌────────────▼─────────────────────────┐
│      Platform Capabilities           │
│  • CI/CD         • Observability     │
│  • Databases     • Secrets           │
│  • Networking    • Security          │
└────────────┬─────────────────────────┘
             │
┌────────────▼─────────────────────────┐
│      Infrastructure Layer            │
│  (K8s, Cloud providers, etc.)        │
└──────────────────────────────────────┘

Les 5 capacités essentielles

1. Self-service provisioning

Avant :

# 47 étapes manuelles pour créer un service
1. Créer le repo GitHub
2. Configurer les secrets
3. Setup CI/CD
4. Provisionner la database
5. Configurer le load balancer
...

Après (avec Platform Engineering) :

$ platform create service my-api --template=nodejs-api
✓ Repository created
✓ CI/CD configured
✓ Database provisioned
✓ Observability enabled
✓ Security scanning active

🚀 Service ready in 2 minutes!

2. Golden Paths

Offrir des chemins simples pour les cas d’usage courants :

# platform.yaml
service:
  type: api
  language: typescript
  database: postgres
  cache: redis

# C'est tout ! La plateforme s'occupe du reste

Ce qui est généré automatiquement :

Dockerfile optimisé
CI/CD pipeline
Tests automatisés
Observability (metrics, logs, traces)
Scaling rules
Security policies

3. Progressive disclosure

Niveau 1 (Simple) :
  platform deploy

Niveau 2 (Configuré) :
  platform deploy --env=staging --scale=3

Niveau 3 (Avancé) :
  platform deploy --config=custom.yaml

Niveau 4 (Expert) :
  Accès direct à K8s, Terraform, etc.

Principe : Simple par défaut, puissant si besoin.

4. Observabilité intégrée

Chaque service déployé sur la plateforme a automatiquement :

// Metrics automatiques (sans code)
- request_duration_ms
- request_count
- error_rate
- cpu_usage
- memory_usage

// Logs structurés
- Format JSON standardisé
- Correlation IDs
- Sensitive data masking

// Tracing distribué
- OpenTelemetry par défaut
- Propagation automatique

5. Documentation vivante

Documentation générée automatiquement :

┌─────────────────────────────────────┐
│  Service: payment-api               │
├─────────────────────────────────────┤
│  Status: 🟢 Healthy                 │
│  Owner: @payments-team              │
│  On-call: @john-doe                 │
│                                     │
│  📊 Dashboards                      │
│  📝 API Docs (OpenAPI)              │
│  🔍 Logs & Traces                   │
│  📈 SLOs & Alerts                   │
│  🏗️  Architecture Diagram           │
│  📚 Runbooks                        │
└─────────────────────────────────────┘

Tech Stack : Notre retour d’expérience

Portal : Backstage

Backstage (Spotify) est devenu le standard de facto.

Pourquoi Backstage :

Open source + large communauté
Plugin ecosystem riche
Service catalog natif
Templates (Software Templates)

Notre stack autour de Backstage :

Portal: Backstage
IaC: Terraform + Crossplane
CI/CD: GitHub Actions + ArgoCD
Observability: Grafana Stack (Loki, Tempo, Mimir)
Secrets: Vault
Service Mesh: Istio

Alternative : Portail custom

Si Backstage est trop lourd, on peut créer un portail simple :

// pages/create-service.tsx
export default function CreateService() {
  const templates = [
    { id: 'nodejs-api', name: 'Node.js API', icon: '🟢' },
    { id: 'python-worker', name: 'Python Worker', icon: '🐍' },
    { id: 'react-app', name: 'React App', icon: '⚛️' },
  ];

  return (
    <div>
      <h1>Create New Service</h1>
      <TemplateGrid templates={templates} />
    </div>
  );
}

Backend : Simple API qui orchestre Terraform, GitHub, etc.

Métriques de succès

Après 6 mois de Platform Engineering chez notre client :

Developer Productivity

Time to first deploy : 2 semaines → 1 heure (-97%)
Déploiements/jour : 3 → 45 (+1400%)
Time to resolution : 4h → 45min (-81%)

Platform Adoption

Services migrés : 48/50 (96%)
Developer satisfaction : 8.4/10
Self-service rate : 92% (vs 0% avant)

Business Impact

Lead time : 2 semaines → 2 jours (-86%)
MTTR : 2h → 15min (-87%)
Incidents infra : -60%

Organisation : L’équipe Platform

Composition

Platform Team (5 personnes) :
- 1 Product Manager (Platform as Product!)
- 2 Platform Engineers
- 1 DevEx Engineer
- 1 Tech Writer

Rôles clés :

Product Manager Platform

Roadmap plateforme
Priorisation features
Relation avec les “clients” (dev teams)

Platform Engineer

Build capabilities
Infrastructure as Code
Reliability & Performance

DevEx Engineer

CLI, portals, IDE plugins
Documentation
Developer feedback

Relation avec les équipes dev

┌─────────────────┐
│ Platform Team   │ ← Build & maintain platform
└────────┬────────┘
         │ Provide capabilities
         │ Support & training
    ┌────▼─────────────────┐
    │  Development Teams   │ ← Use platform
    └──────────────────────┘
         Use self-service
         Give feedback

Important : Platform Team ≠ Ops Team bottleneck.

Migration progressive : Notre approche

Phase 1 : Pilot (2 mois)

1 équipe volontaire
1 capability : CI/CD
Beaucoup de feedback

Phase 2 : Early Adopters (3 mois)

3-4 équipes
Ajout capabilities : database, observability
Documentation améliorée

Phase 3 : Rollout (6 mois)

Toutes les équipes
Plateforme complète
Support intensif

Phase 4 : Optimisation (continu)

Nouvelles capabilities
Performance & coûts
Developer Experience

Erreurs à éviter

Erreur 1 : Construire sans utilisateurs

❌ “On va construire la plateforme parfaite, puis on la déploie”

✅ “On commence avec 1 équipe, on itère en continu”

Erreur 2 : Ignorer le change management

La technique seule ne suffit pas :

Formation continue
Office hours
Champions dans chaque équipe
Célébrer les early adopters

Erreur 3 : Réinventer la roue

Utiliser l’existant :

Backstage au lieu de portal custom
Crossplane au lieu de Terraform custom
Grafana au lieu de dashboards custom

Erreur 4 : Oublier la sécurité

Security doit être built-in :

Secrets management (Vault)
Policy as Code (OPA)
Security scanning (Snyk, Trivy)
Compliance automation

Ressources pour démarrer

Open Source Tools

Backstage - Developer portal
Crossplane - Infrastructure as APIs
Score - Workload specification
OPA - Policy as Code

Lectures recommandées

“Team Topologies” - Manuel Pais & Matthew Skelton
“Platform Strategy” - Gregor Hohpe

Communautés

Platform Engineering Community (Slack)
CNCF Platforms Working Group

Conclusion

Platform Engineering n’est pas juste du DevOps rebrandé. C’est un changement de mindset :

De “Donner accès à l’infra” À “Construire un produit pour les développeurs”

Les bénéfices sont réels :

Productivité développeur ↑
Time to market ↓
Satisfaction équipes ↑
Coûts infra optimisés

Commencez petit :

Identifier 1 pain point critique
Construire 1 capability simple
Mesurer l’impact
Itérer

Et vous, où en êtes-vous dans votre journey Platform Engineering ?

Le problème : DevOps n’a pas tenu ses promesses#

La promesse initiale#

La réalité 5 ans après#

Platform Engineering : La solution#

Principe de base#

Ce n’est PAS du Platform Engineering#

C’est du Platform Engineering#

Architecture d’une plateforme moderne#

Les 5 capacités essentielles#

1. Self-service provisioning#

2. Golden Paths#

3. Progressive disclosure#

4. Observabilité intégrée#

5. Documentation vivante#

Tech Stack : Notre retour d’expérience#

Portal : Backstage#

Alternative : Portail custom#

Métriques de succès#

Developer Productivity#

Platform Adoption#

Business Impact#

Organisation : L’équipe Platform#

Composition#

Relation avec les équipes dev#

Migration progressive : Notre approche#

Phase 1 : Pilot (2 mois)#

Phase 2 : Early Adopters (3 mois)#

Phase 3 : Rollout (6 mois)#

Phase 4 : Optimisation (continu)#

Erreurs à éviter#

Erreur 1 : Construire sans utilisateurs#

Erreur 2 : Ignorer le change management#

Erreur 3 : Réinventer la roue#

Erreur 4 : Oublier la sécurité#

Ressources pour démarrer#

Open Source Tools#

Lectures recommandées#

Communautés#

Conclusion#