Kubernetes : et si le vrai problème n'était pas technique ?

Une équipe veut déployer une nouvelle API sur Kubernetes.

Le code est prêt, les tests passent. Mais avant de déployer, il reste quelques détails : demander un namespace, trouver comment injecter les secrets, adapter la pipeline CI/CD, ouvrir les bons flux réseau et comprendre où consulter les logs en cas de problème.

Rien d'insurmontable. Sauf que ces « quelques détails » reviennent à chaque nouveau projet.

C'est souvent à ce moment-là qu'on se demande s'il ne faudrait pas créer une équipe plateforme. Une équipe qui prendrait en charge Kubernetes, les pipelines et tout ce qui gravite autour.

L'idée se défend. Mais elle peut aussi conduire à déplacer le problème : au lieu de perdre du temps à configurer leur environnement, les développeurs en perdent à attendre une autre équipe.

Pour moi, la question n'est donc pas seulement « qui administre Kubernetes ? », mais « comment éviter que Kubernetes complique inutilement le travail des équipes ? »

Je vais prendre trois tailles d'organisation — 20, 100 et 500 développeurs — puis regarder ce qui change lorsqu'on traite la plateforme comme un produit interne. Ce sont des scénarios, pas des ratios à appliquer à la lettre.

Avant de parler d'équipe plateforme, parlons de ce qu'elle doit fournir

Un cluster à jour, des nœuds correctement dimensionnés, un réseau maîtrisé, une politique de sécurité cohérente : c'est indispensable. Quelqu'un doit s'en occuper.

Mais maintenir Kubernetes et fournir une plateforme de développement, ce n'est pas exactement le même métier.

Dans le premier cas, on s'assure que l'infrastructure fonctionne. Dans le second, on s'intéresse aussi à la façon dont les équipes l'utilisent : comment elles créent un service, le déploient, diagnostiquent un incident, récupèrent un secret ou appliquent une mise à jour.

Les deux sujets sont liés, et je ne vois aucun intérêt à les opposer. Une même équipe peut très bien porter les deux. En revanche, il faut être clair sur ce qu'on attend d'elle. Si son backlog ne contient que des montées de version de clusters, des demandes de droits et des interventions sur incident, on parle surtout d'exploitation. Pas encore d'une plateforme pensée pour ses utilisateurs.

La CNCF décrit les plateformes internes comme un ensemble de capacités mises à disposition d'autres équipes pour faciliter leur travail [1]. L'idée est simple : mutualiser ce qui a du sens, sans obliger chacun à comprendre toute la mécanique derrière.

Trois façons de s'organiser, avec des compromis différents

On présente parfois l'organisation en équipe plateforme comme l'aboutissement naturel de toute démarche DevOps. Je suis moins catégorique. Certaines entreprises n'en ont pas besoin, et d'autres auraient surtout besoin de simplifier leur fonctionnement avant de changer leur organigramme.

Premier modèle : chaque équipe se débrouille. Les développeurs maîtrisent leur application et une bonne partie de sa chaîne de déploiement. L'autonomie est forte. Avec peu d'équipes, c'est souvent efficace. Le revers apparaît quand chacun maintient ses propres templates Helm, ses variables CI et sa façon de gérer les secrets. Le même problème est résolu plusieurs fois, avec quelques variantes qui finissent par coûter cher.

Deuxième modèle : une équipe DevOps ou infrastructure centrale. Les compétences sont regroupées, les standards deviennent plus cohérents et la gestion des clusters est mieux maîtrisée. C'est souvent le modèle le plus pragmatique pour démarrer. Il a toutefois un défaut classique : si créer un environnement ou modifier une pipeline nécessite systématiquement un ticket, l'équipe centrale finit par limiter le débit de toutes les autres.

Troisième modèle : une équipe plateforme avec une logique produit. Elle ne se contente pas d'exécuter des demandes. Elle construit des services réutilisables : starters, pipelines, accès aux environnements, observabilité, déploiement en self-service. Les équipes applicatives utilisent ces capacités sans avoir à demander une intervention à chaque étape.

Le troisième modèle n'est pas automatiquement meilleur. Il demande du temps, du recul et une vraie capacité à dire non à certaines fonctionnalités. Une équipe plateforme peut elle aussi produire beaucoup de YAML et très peu de valeur.

Les principes de Team Topologies aident à lire ce problème : les interactions entre équipes et la charge cognitive comptent autant que la répartition technique des responsabilités [3].

Ce que je ferais avec 20, 100 ou 500 développeurs

Trois organisations possibles. Les effectifs mentionnés sont des hypothèses de travail, pas des préconisations chiffrées de la CNCF.

Avec 20 développeurs : je ne créerais pas une équipe dédiée par principe

Imaginons deux ou trois équipes applicatives. Je commencerais par identifier un référent Kubernetes/DevOps, avec du temps officiellement réservé pour les sujets transverses, et surtout quelqu'un capable de prendre le relais.

Ce point mérite d'être souligné : « on a un développeur qui connaît bien Kubernetes » n'est pas un modèle d'exploitation. S'il doit gérer les incidents, les mises à jour et les demandes de toutes les équipes en plus de son travail habituel, le risque est de concentrer toute la connaissance sur une seule personne.

Je viserais une capacité de l'ordre de 0,5 à 1 ETP pour les besoins communs, à ajuster selon l'exposition en production, le support attendu et les contraintes de sécurité.

À cette taille, les bons investissements sont assez terre à terre : des pipelines réutilisables, un ou deux starters maintenus, de l'Infrastructure as Code, une gestion propre des secrets, quelques dashboards compréhensibles et une documentation que quelqu'un relit vraiment.

Si tout cela tient dans la forge logicielle et quelques dépôts bien organisés, je ne vois pas l'intérêt d'installer un portail supplémentaire.

Avec 100 développeurs : une équipe plateforme commence à avoir du sens

Une dizaine d'équipes produit, c'est déjà beaucoup d'occasions de refaire les mêmes choses. Le moindre changement transversal peut provoquer dix échanges, dix adaptations et dix façons différentes de contourner un problème.

C'est à ce niveau que je regarderais sérieusement une équipe de 3 à 5 personnes, avec des compétences Kubernetes, cloud, CI/CD et développement. Le rôle de Product Owner peut être assuré par le responsable de cette équipe, au moins au début. Les fonctions sécurité et architecture doivent être associées aux choix structurants, sans devenir une validation manuelle de chaque déploiement.

Je préfère une petite équipe capable de prendre en charge un parcours de bout en bout — créer une API, la tester, la livrer et l'observer — plutôt que trois spécialistes qui se renvoient les sujets selon l'outil concerné.

Il faut aussi être lucide sur la charge d'exploitation. Une équipe de quatre personnes ne garantit pas par magie une astreinte viable 24 h/24. Avant de promettre un service permanent, on doit définir les horaires de support, les responsabilités en incident et les engagements réellement tenables.

Avec 500 développeurs : je structurerais plusieurs capacités, sans tout centraliser

À cette échelle, il devient difficile de traiter Kubernetes comme un simple sujet d'administration de clusters. Les besoins se multiplient : réseau, IAM, capacité, CI/CD, politiques de sécurité, observabilité, coûts, environnements de test, accompagnement des équipes.

Je verrais plutôt un domaine Platform Engineering avec une responsabilité produit commune et plusieurs compétences identifiables :

• Cloud & Kubernetes, pour les clusters et les fondations techniques ;
• Developer Experience & Delivery, pour la forge, les starters, les pipelines et les golden paths ;
• Observabilité & fiabilité des services communs, pour les capacités de diagnostic et les engagements de la plateforme.

Un Platform Product Lead assure la cohérence de l'offre et les arbitrages. La sécurité, l'architecture et le FinOps restent des partenaires réguliers, même s'ils n'appartiennent pas hiérarchiquement à ce domaine.

Un périmètre de 12 à 20 ETP peut servir de point de départ à la discussion, mais il serait trompeur d'en faire un ratio. Une entreprise très réglementée, multi-cloud et soumise à de fortes astreintes n'aura pas les mêmes besoins qu'une autre dont la majorité des applications utilisent quelques services managés standardisés.

Je ne chercherais pas non plus à faire entrer de force l'observabilité, l'API Management ou la sécurité dans une seule équipe géante. Des équipes expertes peuvent exposer leurs services dans un catalogue commun. Ce qui importe, c'est que les développeurs sachent où trouver le service et comment l'utiliser.

Ces chiffres donnent un cadre de réflexion, pas un dimensionnement prêt à appliquer. Je regarderais d'abord le nombre de services, la criticité de la production, les interventions manuelles et les dépendances entre équipes.

Kubernetes comme produit interne : oui, mais pas comme prétexte pour créer un portail

Le point de départ d'une plateforme produit, ce sont les usages. Pas la liste des outils à installer.

Je suis convaincu de l'intérêt d'une approche produit, mais le mot « produit » est parfois utilisé un peu vite.

Créer un portail, baptiser quelqu'un Platform Product Owner et afficher une roadmap ne suffit pas. Il faut accepter de considérer les équipes de développement comme des utilisateurs avec des besoins parfois contradictoires.

Une équipe voudra davantage de liberté sur son déploiement. Une autre réclamera un parcours entièrement standardisé. La sécurité imposera certains contrôles. L'exploitation cherchera à limiter les variantes. Ce sont de vrais arbitrages, pas de simples tickets à classer.

Le Product Ownership consiste notamment à choisir ce qu'on ne va pas développer tout de suite.

Prenons un exemple. Une équipe demande une option avancée de déploiement dont elle est la seule utilisatrice. Dans le même temps, huit équipes passent régulièrement par le support pour comprendre leurs erreurs de pipeline. Il est tout à fait défendable de traiter d'abord la seconde demande : elle supprime une friction répétée et touche davantage de monde.

Et cela se voit dans la roadmap. « Mettre en place Backstage » ou « migrer vers Argo CD » sont des chantiers techniques ; ils peuvent être nécessaires, mais ils ne disent pas à eux seuls ce qui s'améliorera pour les développeurs.

Je préfère des objectifs formulés autrement :

• permettre à une équipe de créer une API avec son pipeline et son observabilité sans intervention manuelle ;
• rendre les erreurs de déploiement assez explicites pour être traitées par l'équipe applicative ;
• réduire les demandes récurrentes d'accès ou de création d'environnement.

Ensuite seulement, on choisit les outils.

C'est également l'esprit des travaux de la CNCF sur le Product Thinking for Platforms et son modèle de maturité [2, 4]. Une plateforme, même interne, doit évoluer à partir des usages et des retours.

Un golden path, concrètement, ça change quoi ?

Exemple de parcours standard pour une nouvelle API. Il ne suppose pas de portail spécifique.

Prenons un développeur qui démarre une API Spring Boot.

Sans parcours commun, il peut passer du temps à retrouver un bon starter, recopier un .gitlab-ci.yml, identifier le registre d'images, comprendre les conventions de déploiement et retrouver l'équipe qui gère l'observabilité.

Avec un golden path bien conçu, il démarre d'un modèle maintenu. Le dépôt contient les conventions de développement ; les tests et analyses de sécurité sont déjà branchés ; la pipeline construit l'image, puis déploie sur un environnement autorisé ; les logs et les métriques sont disponibles au même endroit que pour les autres applications.

On n'a pas supprimé la complexité technique. On a évité de la faire redécouvrir à chaque projet.

Une solution comme Backstage peut fournir une interface intéressante grâce à ses Software Templates [6]. Mais un ensemble de starters GitLab, une CLI ou quelques templates bien documentés peuvent rendre le même service. Je ne commencerais pas par choisir le portail. Je commencerais par rendre le parcours fiable.

Le catalogue de services prend alors tout son sens : il explique ce qui est disponible, comment y accéder et qui en est responsable.

Chaque entrée doit avoir une documentation utile, un propriétaire identifié et des règles de support claires. Sinon le « catalogue » devient vite une page de liens que plus personne ne consulte.

Je tiens aussi à un point : le golden path doit être le chemin recommandé, pas une impasse lorsqu'on a un besoin différent. Les exceptions peuvent être cadrées, documentées, voire soumises à validation. Mais si le standard impose de contourner la plateforme pour traiter tous les cas un peu particuliers, il manque quelque chose au produit.

Qui prend la responsabilité lorsque ça casse ?

Il faut distinguer le service plateforme du service applicatif, notamment pendant les incidents.

C'est un sujet qu'on règle trop souvent après le premier incident sérieux.

Quand une application ne répond plus, qui intervient ? L'équipe plateforme parce que le pod tourne sur Kubernetes ? L'équipe de développement parce qu'elle a écrit le code ? Les Ops parce que c'est la production ?

La réponse dépend de la cause et du modèle d'exploitation, mais il faut se mettre d'accord avant l'incident. Une fuite mémoire dans l'application n'appelle pas la même réponse qu'une panne du réseau du cluster.

Voici une matrice RACI qui peut servir de base de discussion. Elle est volontairement simplifiée : R réalise, A porte la responsabilité finale, C est consulté, I est informé. R/A réunit réalisation et responsabilité finale.

Cette répartition ne remplace évidemment ni les contrats de service ni les astreintes. Elle aide surtout à rendre visibles les ambiguïtés.

La règle que je retiendrais : l'équipe plateforme est responsable de ses services communs ; les équipes applicatives restent responsables de leurs applications. Les deux doivent collaborer pour diagnostiquer ce qui se passe à la frontière.

Les métriques qui m'intéresseraient vraiment

La disponibilité des clusters, les consommations CPU et mémoire ou le coût de l'infrastructure restent utiles. Mais je me méfierais d'une équipe plateforme qui n'a que ces indicateurs à présenter.

J'aimerais savoir combien de temps il faut pour passer d'un nouveau dépôt à une première application déployée. Combien d'opérations courantes se font sans ticket. Combien d'équipes utilisent réellement les starters proposés. Et surtout, combien de temps elles perdent quand le chemin nominal ne fonctionne plus.

Il faut croiser ces données avec des mesures de fiabilité et de livraison, notamment celles popularisées par DORA [5, 7]. Et les compléter par des retours qualitatifs : un questionnaire court ou quelques échanges réguliers avec les développeurs peuvent révéler ce que les dashboards ne montrent pas.

Attention aux indicateurs faciles à embellir. Si l'utilisation du starter est obligatoire, afficher 100 % d'adoption ne démontre pas sa qualité. Si les tickets diminuent parce que les équipes ont abandonné l'idée de demander de l'aide, ce n'est pas davantage un progrès.

Une plateforme réussie n'est pas celle dont personne ne se plaint. C'est celle dont on comprend les problèmes et qu'on améliore en fonction de l'usage réel.

Par où commencer ? Une feuille de route sur six mois

Un premier parcours opérationnel vaut mieux qu'une plateforme complète encore inutilisable.

Je ne lancerais pas un grand programme de transformation avec dix chantiers parallèles. Je commencerais petit, avec une équipe volontaire et un cas d'usage fréquent.

Pendant les deux premiers mois, je regarderais le parcours réel d'une application : depuis la création du dépôt jusqu'à son premier déploiement, puis jusqu'à son diagnostic en cas de panne. Pas le processus théorique décrit dans la documentation. Le vrai, avec ses messages sur Teams, ses droits manquants et ses étapes connues uniquement de deux personnes.

Les deux mois suivants, je livrerais un premier parcours complet. Par exemple une API Java : starter, CI/CD, contrôles, image, déploiement sur Kubernetes, logs et métriques. Je chercherais quelques équipes pilotes prêtes à s'en servir sur un vrai projet, pas uniquement pendant une démonstration.

Les deux derniers mois, je corrigerais ce qui bloque, je vérifierais les usages et je déciderais seulement ensuite s'il faut ajouter un nouveau langage, un nouveau type d'application ou un nouveau service.

Ce n'est pas une promesse de calendrier valable partout. C'est une manière de limiter le risque de construire une grosse plateforme avant d'avoir prouvé qu'elle rend service. On retrouve ici l'idée d'une plateforme minimale utile, souvent associée aux pratiques de Thinnest Viable Platform [3, 5].

Alors, équipe dédiée ou pas ?

Je ne créerais pas une équipe Platform Engineering simplement parce que mon entreprise utilise Kubernetes.

Avec 20 développeurs, un référent outillé, un relais technique et quelques standards bien entretenus peuvent largement suffire. À 100, une petite équipe dédiée peut devenir un excellent investissement si les besoins se répètent. À 500, il paraît difficile de faire l'économie d'une vraie organisation des capacités communes, quitte à la fédérer entre plusieurs équipes.

Mais le nombre de développeurs ne dit pas tout. La criticité des applications, les exigences réglementaires, l'astreinte, les services managés disponibles et le niveau d'automatisation pèsent parfois bien plus lourd.

Je retiens surtout ceci : une équipe plateforme ne devrait pas devenir l'équipe qui fait Kubernetes à la place de tout le monde. Elle devrait rendre les tâches courantes simples, sûres et reproductibles, tout en laissant aux équipes applicatives la maîtrise de leurs produits.

Si, après la mise en place d'une équipe plateforme, il faut toujours ouvrir trois tickets pour déployer une API, on a peut-être amélioré l'organigramme. Pas encore l'expérience développeur.

C'est à ce résultat-là que je jugerais la démarche.

Sources et références

Les références ci-dessous éclairent les principes de Platform Engineering, d'organisation et de Developer Experience. Les effectifs proposés pour 20, 100 et 500 développeurs, ainsi que la matrice RACI, sont mes propres scénarios illustratifs, et non des ratios ou modèles officiels issus de ces publications.

1. CNCF TAG App Delivery — Platforms White Paper. Définition et objectifs d'une plateforme interne. https://tag-app-delivery.cncf.io/whitepapers/platforms/
2. CNCF TAG App Delivery — Platform Engineering Maturity Model. Modèle de maturité : adoption, interfaces, opérations et valeur. https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/
3. Team Topologies — Team Interaction Modeling with Team Topologies. Interactions entre équipes, charge cognitive et conception organisationnelle. https://teamtopologies.com/key-concepts-content/team-interaction-modeling-with-team-topologies
4. CNCF TAG App Delivery — Product Thinking for Platforms (2024). Plateforme envisagée comme un produit avec ses utilisateurs. https://tag-app-delivery.cncf.io/blog/product-thinking-for-platforms/
5. DORA — Capabilities: Platform Engineering. Golden paths, plateforme interne, autonomie et qualité des capacités proposées. https://dora.dev/capabilities/platform-engineering/
6. Backstage — Software Templates. Exemple d'outillage pour créer des composants et automatiser leur initialisation. https://backstage.io/docs/features/software-templates/
7. DORA — State of AI-assisted Software Development 2025. Travaux sur les capacités organisationnelles et le rôle de la qualité des plateformes. https://dora.dev/research/2025/dora-report/

Schémas et illustrations créés pour cet article.