À qui s’adresse « Platform Engineering 2026 : construire une Internal Developer Platform » ?

Aux praticiens DevOps / platform / SRE qui veulent un lab concret 2026 sur platform engineering 2026. Prérequis et niveau sont indiqués en tête de page.

Faut-il un cluster ou un compte cloud pour platform engineering 2026 ?

Oui dans la plupart des labs WOW (kube local, Free Tier ou sandbox). Suivez la section Prérequis pour outils, droits et coûts.

Ce tuto remplace-t-il la doc officielle ?

Non : c’est un parcours hands-on orienté DevOps Elastic Hayway. Gardez la doc upstream pour les API et breaking changes.

Platform Engineering 2026 : Internal Developer Platform (gui

À la fin de ce tutoriel, vous saurez définir le Platform Engineering, expliquer une Internal Developer Platform (IDP), poser un golden path self-service, et dérouler un lab minimal en ca-central-1 (service template + checklist) sans facture inutile.

Niveau : Intermédiaire · Temps estimé : 50–70 min · Versions cibles : concepts IDP 2026 · AWS CLI v2 · GitHub Actions (OIDC) · Kubernetes 1.31+ (optionnel) · Dernière vérification : 2026-09-11 · Region : ca-central-1

Slug : wow-platform-engineering-2026 · Série : WOW (1/50) · Mot-clé SEO : platform engineering · Publish : HOLD

→ Suivant : Backstage : catalogue services et IDP · Aussi : Argo CD GitOps · Démarrer avec AWS

Prérequis

Bases DevOps : Git, CI/CD, conteneurs — Docker · Kubernetes
Compte AWS de lab (profil lab) — Démarrer avec AWS
Notions IaC utiles — Installer Terraform
Un dépôt GitHub pour pousser un service template

Coût estimé : 0–2 € si vous restez Free Tier / lecture et détruisez toute ressource créée. Pas de NAT Gateway, RDS ou EKS « pour tester l’IDP ».

export AWS_PROFILE=lab
export AWS_DEFAULT_REGION=ca-central-1
aws sts get-caller-identity

Ce que nous allons construire

Platform Engineering / IDP (WOW 1/50) — ca-central-1
  ├── Définition Platform Engineering vs outillage DevOps
  ├── Capacités IDP (catalog, templates, envs, secrets, obs)
  ├── Architecture de référence DEH
  ├── Lab golden path : service-template + CI OIDC sketch
  ├── Scorecard d’adoption + anti-patterns
  └── Quiz + FAQ + maillage WOW

(Schéma — alt : « Équipe plateforme expose un golden path self-service vers AWS ca-central-1 via une IDP ».)

Étape 1 — Pourquoi le Platform Engineering en 2026 ?

Le DevOps a popularisé collaboration et automatisation. En pratique, beaucoup d’équipes accumulent trop d’outils (CI, registries, K8s, secrets, tickets) et trop peu de chemins pavés. Chaque service réinvente Dockerfile, pipeline, IAM, monitoring et runbooks.

Le Platform Engineering répond à ça : une équipe plateforme traite la plateforme comme un produit interne. Les développeurs sont les clients. L’objectif n’est pas « plus de YAML », c’est réduire le cognitive load et le time-to-first-deploy.

Pression 2026	Réponse plateforme
Time-to-market	Templates + self-service
Sécu / compliance	Guardrails dans le golden path
Multi-équipes	Catalogue + ownership
Coût cloud	Tags, quotas, envs standard
Toil ops	Moins de tickets one-off

Étape 2 — Qu’est-ce qu’une Internal Developer Platform ?

Une IDP est le produit livré par l’équipe plateforme : portail + APIs + templates + automatisations pour créer, déployer et opérer un service sans ticket à chaque étape.

Ce n’est pas un wiki seul, un cluster Kubernetes nu, ni un bot Slack qui fait kubectl apply sans audit.

C’est plutôt :

Catalogue (ownership, APIs, docs)
Templates / golden paths
Environnements standard + politiques
CI/CD pré-câblé (build, scan, deploy)
Secrets & identité (OIDC, Vault/ESO)
Observabilité dès le jour 1
Scorecards (tests, SLO, SBOM)

Backstage, Port, Humanitec ou une stack maison (Git + Actions + Argo + Crossplane) sont des implémentations. L’IDP est le contrat d’expérience développeur.

Terme	Sens DEH
Golden path / paved road	Chemin recommandé, supporté, sécurisé par défaut
Platform as product	Roadmap, UX, SLAs internes, feedback
Self-service	Créer service/env sans ticket (dans les garde-fous)
Thinnest viable platform	1–2 golden paths d’abord, pas 40 outils
Cognitive load	Charge mentale pour livrer en prod

Étape 3 — Capacités minimales (MVP)

Avant d’acheter un portail, validez ce MVP :

Create service depuis un template (nom, owner, langage)
Pipeline : lint, tests, build image, scan (Trivy)
Deploy non-prod (GitOps ou pipeline gated)
Identité cloud sans clés longues (OIDC → AWS ca-central-1)
Tags : Owner, Service, Env, CostCenter
Docs : README + runbook minimal
/health + logs structurés
Offboarding : destruction / freeze

Si vous avez (1)+(2)+(4), vous avez déjà une thinnest viable platform. Le catalogue Backstage vient ensuite — wow-backstage-idp.

Étape 4 — Architecture de référence DEH

[ Dev / App team ]
      │  self-service (PR / portal / CLI)
      ▼
[ Platform plane ]
  ├── Service templates (Git)
  ├── CI (GitHub Actions + OIDC)
  ├── GitOps (Argo CD) — option
  ├── Policy (OPA / Conftest) — option
  └── Secrets (SOPS / Vault / ESO) — option
      ▼
[ AWS ca-central-1 ]
  ├── Workloads tagués
  ├── ECR / IAM roles (OIDC)
  └── Runtime : ECS/Fargate, EKS ou App Runner (selon path)

Les app teams consomment le golden path. La plateforme expose des interfaces stables et mesure l’adoption. Elles ne gèrent ni le réseau partagé, ni les baselines IAM root.

Étape 5 — Lab : golden path minimal (service-template)

Objectif : un squelette réutilisable (metadata + health + Dockerfile + sketch OIDC) en ca-central-1. Pas de cluster EKS complet.

5.1 — Identité lab

export AWS_PROFILE=lab
export AWS_DEFAULT_REGION=ca-central-1
aws sts get-caller-identity
aws configure get region

Attendu : ARN du profil lab ; region ca-central-1.

5.2 — Scaffold

mkdir -p service-template/{src,.github/workflows,.idp}
cd service-template

cat > .idp/metadata.yaml << 'EOF'
apiVersion: deh.platform/v1
kind: Service
metadata:
  name: demo-payments
  owner: team-payments
  description: Exemple golden path IDP 2026
spec:
  language: node20
  region: ca-central-1
  tags:
    Owner: team-payments
    Service: demo-payments
    Env: nonprod
    CostCenter: platform-lab
EOF

cat > README.md << 'EOF'
# service-template (DEH golden path)
- Health : GET /health → 200
- Tags AWS : Owner, Service, Env, CostCenter
- Region : ca-central-1
- Secrets : OIDC CI → rôle IAM (pas de clés longues)
EOF

5.3 — App + Dockerfile

cat > src/server.js << 'EOF'
const http = require("http");
const port = process.env.PORT || 8080;
http.createServer((req, res) => {
  if (req.url === "/health") {
    res.writeHead(200, { "content-type": "application/json" });
    res.end(JSON.stringify({ ok: true, region: process.env.AWS_REGION || "local" }));
    return;
  }
  res.writeHead(200, { "content-type": "text/plain" });
  res.end("demo-payments golden pathn");
}).listen(port, () => console.log(`listening on ${port}`));
EOF

cat > Dockerfile << 'EOF'
FROM node:20-alpine
WORKDIR /app
COPY src/server.js .
ENV PORT=8080
EXPOSE 8080
USER node
CMD ["node", "server.js"]
EOF

Test local optionnel :

docker build -t demo-payments:lab .
docker run --rm -p 8080:8080 -e AWS_REGION=ca-central-1 demo-payments:lab
# curl -s localhost:8080/health

5.4 — Sketch CI OIDC

# .github/workflows/ci.yml
name: ci-golden-path
on:
  push:
    branches: [main]
  pull_request:
permissions:
  id-token: write
  contents: read
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: docker build -t demo-payments:${{ github.sha }} .
      # Prod plateforme : Trivy + push ECR + configure-aws-credentials OIDC
      # role-to-assume: arn:aws:iam::ACCOUNT:role/deh-gha-platform
      # aws-region: ca-central-1

En lab, configurez l’OIDC seulement si le rôle IAM existe déjà. Sinon gardez build local + checklist : la valeur est le contrat (metadata, health, tags, zéro secret long).

5.5 — Checklist onboarding + cleanup

[ ] metadata.yaml rempli
[ ] /health → 200
[ ] Dockerfile non-root
[ ] CI sans AWS_ACCESS_KEY_ID long
[ ] Region ca-central-1
[ ] Runbook 1 page (on-call, rollback)
[ ] Cleanup images / ressources taguées

docker rm -f $(docker ps -aq --filter ancestor=demo-payments:lab) 2>/dev/null || true
docker rmi demo-payments:lab 2>/dev/null || true

Étape 6 — Adoption et anti-patterns

KPI	Cible MVP
Time-to-first-deploy	< 1 jour
% services sur golden path	> 70 % à 6 mois
Tickets « crée mon pipeline »	en baisse
Configs one-off en incident	→ 0 sur le paved road

Anti-patterns : portail obligatoire sans UX ; 15 golden paths au mois 1 ; contournements non documentés ; secrets dans Slack ; pas d’offboarding.

Erreurs fréquentes

Erreur	Impact	Correction
IDP = « cluster partagé »	Chaos multi-tenant	Contrat self-service clair
Backstage sans template	Portail vide	1 golden path d’abord
Clés IAM longues en CI	Fuites	OIDC + rôles courts
Region us-east-1 par défaut	Coût / cohérence	Forcer `ca-central-1`
Pas de tags Owner/Service	FinOps flou	Tags dans le template
Plateforme = tickets déguisés	Pas de self-service	Automatiser le happy path

Quiz (5 questions)

1. Le Platform Engineering vise surtout à : – A. Remplacer les devs par du YAML
– B. Réduire le cognitive load via une IDP produit
– C. Interdire Kubernetes

2. Une IDP est : – A. Un wiki uniquement
– B. Le produit interne (templates, self-service, guardrails)
– C. Un compte AWS root partagé

3. Un golden path désigne : – A. Un VPN
– B. Le chemin recommandé et supporté pour créer/déployer
– C. Un type d’instance EC2

4. Region lab DEH imposée : – A. us-east-1
– B. ca-central-1
– C. eu-west-3

5. Identité CI → AWS préférée en 2026 : – A. Access keys longues dans le repo
– B. OIDC + assume-role court
– C. User root

Réponses : 1‑B · 2‑B · 3‑B · 4‑B · 5‑B

FAQ

Platform Engineering = DevOps ?

Non. DevOps est une culture. Le Platform Engineering est une équipe produit qui livre une IDP pour industrialiser le happy path.

Backstage dès le jour 1 ?

Non. D’abord 1 template + CI + tags + docs. Le catalogue vient quand le volume de services le justifie.

IDP DIY ou produit ?

DIY (Git + Actions + Argo + Crossplane) si la stack est maîtrisée. Backstage/Port accélèrent UX et catalogue. Selon taille et compétences.

Pourquoi ca-central-1 ?

Standard lab DevOps Elastic Hayway : cohérence entre tutos, FinOps et IAM comparables.

Combien de golden paths au démarrage ?

Un ou deux (ex. HTTP conteneurisé + job batch). Trop de chemins = toil plateforme.

Comment forcer l’adoption ?

Mesurez le time-to-deploy, documentez le paved road, rendez le contournement plus dur, traitez le feedback comme un produit.

Pour aller plus loin

Maillage série WOW


← Précédent	— (premier tuto WOW)
→ Suivant	Backstage : catalogue services et IDP
Aussi	Argo CD · OPA · DevSecOps · System design

Meta publication (SEO)

Title SEO : Platform Engineering 2026 : Internal Developer Platform (guide FR)
Meta description : Platform Engineering 2026 : construire une IDP (golden paths, self-service, OIDC). Lab service-template en ca-central-1, FAQ, quiz et check-list DEH.
Focus keyword : platform engineering
Secondary : internal developer platform, golden path, IDP
Image : assets/web/devopelastichayway/cover-wow-platform-engineering-2026-1200x630.webp (à générer)
Catégorie : WOW / Platform · Niveau : Intermédiaire
URL cible : https://devopelastichayway.com/tutoriels/wow-platform-engineering-2026/
Post live : N/A (nouveau) · slug wow-platform-engineering-2026 · Publish : HOLD (draft only — feu vert Maître requis)

← Catalogue Tutoriels

Pour aller plus loin — hubs live

Hub DevOps

Retour parcours Catalogue Tutoriels — hub de la série et leçons sœurs.