Le DevOps classique optimise le flux : les équipes possèdent leurs pipelines, clusters et astreintes de bout en bout. L’ingénierie de plateforme optimise le levier : un groupe dédié construit des briques réutilisables—clusters comme produit, routes pavées pour les services, paquets de politiques—afin que les équipes produit passent moins de temps à réinventer l’infrastructure.
La tension porte sur la propriété du golden path. Si chaque équipe choisit son modèle CI, son runtime et sa stack d’observabilité, on va vite localement mais on accumule dérive, audits douloureux et transferts fragiles. Si la plateforme tout impose, on réduit la variance mais on risque les goulots d’étranglement et les builders frustrés.
Un partage viable : la plateforme possède des défauts opinionés (charts Helm de base, config service mesh, câblage OIDC, schémas de logs) et les prouve d’abord en interne. Les équipes applicatives gardent la logique métier, les SLO et le dernier kilomètre du déploiement—avec des garde-fous qu’on ne contourne qu’avec des exceptions documentées.
Mesurez la plateforme par l’adoption, pas le volume de tickets. Le temps jusqu’au premier déploiement prod, la part de services sur la route pavée et le MTTR quand la plateforme change valent mieux que le nombre d’épiques Jira.
Le DevOps classique reste pertinent pour les petites structures ou les îlots réglementés où l’autonomie l’emporte. L’ingénierie de plateforme paie quand vous avez des dizaines de services, des thèmes de conformité récurrents et les mêmes questions (« quel patron d’ingress est approuvé ? »).
Migrer : commencez par un golden path pour un type de charge (services HTTP sans état), publiez des SLA pour la plateforme, gardez des sorties de secours explicites. N’élargissez les chemins que quand le précédent est ennuyeusement fiable.
À lire aussi : conseil DevOps, ressources et études de cas.