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.
Une grille de décision pour la frontière de propriété
Quand les clients nous demandent de tracer la ligne concrètement, nous passons par quatre questions plutôt que de remettre un organigramme générique. Première question : combien d’équipes devraient résoudre ce même problème indépendamment si la plateforme n’existait pas ? Si la réponse est une ou deux, un composant de plateforme partagé est prématuré—laissez l’équipe le posséder et revenez-y quand une troisième équipe demande la même chose. Deuxième question : quelle est la surface d’impact si on se trompe ? La gestion d’identité et des secrets revient presque par défaut à la plateforme, car une erreur là n’est pas confinée au namespace d’une seule équipe.
Troisième question : cette décision doit-elle changer souvent en réponse aux besoins produit, ou est-ce une infrastructure stable qui évolue à un rythme plus lent, lié aux correctifs de sécurité et aux mises à jour du fournisseur ? Les décisions qui changent vite et sont propres au produit—pourcentages de rollout de feature flags, seuils d’autoscaling par service liés au trafic d’une charge particulière—reviennent à l’équipe qui possède le résultat produit. Les décisions lentes, de forme infrastructure—réseau du cluster, durcissement des images de base, flotte de runners CI—reviennent à la plateforme.
Quatrième question, la plus souvent oubliée : qui est réveillé à 3h du matin quand ça casse, et cette personne a-t-elle l’accès et le contexte pour réparer sans réveiller quelqu’un d’autre ? Si les équipes applicatives doivent déboguer des composants possédés par la plateforme pendant un incident, la plateforme a en pratique externalisé son astreinte sans externaliser son autorité. Nous poussons les clients à rendre cela explicite dans la documentation du golden path elle-même, pas seulement dans un runbook que personne ne lit avant que l’incident soit déjà en cours.
Ce que nous avons observé quand le partage est mauvais
L’anti-pattern le plus courant : une équipe plateforme qui construit pour un hypothétique quatrième utilisateur avant que les trois premiers n’aient adopté quoi que ce soit. Nous sommes intervenus sur des missions où un groupe plateforme avait passé deux trimestres à construire un outil de scaffolding de service totalement générique avec des dizaines de leviers de configuration, pendant que les trois équipes qu’il devait servir bricolaient encore leurs propres Dockerfiles parce que l’outil ne supportait pas encore leur stack réelle. La généralité achetée avant l’adoption est un coût irrécupérable sans preuve derrière.
L’échec inverse est une équipe plateforme qui ne dit jamais non. Chaque demande ponctuelle d’une équipe applicative devient une branche permanente du chemin pavé, et dix-huit mois plus tard la plateforme maintient une douzaine de variantes légèrement différentes du même chart Helm, chacune n’ayant qu’une seule équipe comme utilisateur. Ce n’est pas de l’ingénierie de plateforme—c’est du DevOps distribué et mal documenté portant le badge d’une équipe plateforme. Le correctif est presque toujours le même : publier des critères clairs pour ce qui mérite une place sur le golden path, et laisser tout le reste vivre dans le dépôt de l’équipe demandeuse, soutenu mais pas possédé centralement.
Recruter l’équipe plateforme sans affamer la livraison produit
Une question que nous recevons dans presque chaque mission : d’où viennent les ingénieurs plateforme ? Retirer vos meilleurs ingénieurs infra des équipes produit pour staffer un nouveau groupe plateforme est le réflexe évident, et c’est aussi comme ça qu’on finit avec une équipe plateforme dotée d’une expertise infra profonde mais sans compréhension vécue de ce qui rend pénible le quotidien d’une équipe produit. Nous préférons faire tourner les ingénieurs dans l’équipe plateforme pour une durée fixe—six à neuf mois—plutôt que d’en faire un aller simple permanent. Les rotations apportent des points de douleur frais, et ramènent la pensée plateforme dans les équipes produit à leur retour.
Le ratio d’effectifs compte moins que ne le laissent penser la plupart des organigrammes. Nous avons vu une équipe plateforme de deux personnes bien servir quinze équipes produit, parce que le travail de la plateforme est de prendre un petit nombre de décisions à fort levier plutôt que de servir personnellement chaque demande. Nous avons aussi vu une équipe plateforme de dix personnes ne rien faire bouger pour cinq équipes produit, parce qu’elle était dimensionnée pour construire plutôt que pour dire non et entretenir un petit nombre de chemins bien rodés. Dimensionnez l’équipe aux décisions qu’elle doit posséder, pas au nombre de tickets qu’elle pense recevoir.
Quel que soit le modèle de staffing choisi, imposez un niveau de service à l’équipe plateforme elle-même—délai de réponse pour les exceptions au golden path, disponibilité de l’infrastructure CI partagée, fenêtre de dépréciation documentée avant qu’un composant partagé change de façon cassante. Les équipes produit tolèrent bien mieux les opinions d’une plateforme une fois qu’elles font confiance à sa fiabilité.