Les équipes plateforme ont un problème de scaling que personne ne veut nommer. Au fur et à mesure que les organisations grandissent, l'équipe responsable de l'infrastructure devient un goulot d'étranglement : elle traite des tickets, maintient des modules Terraform, traque du drift. Les développeurs attendent des jours pour des ressources qui devraient prendre des minutes. Les opérateurs de plateforme passent plus de temps sur la maintenance et le routage de tickets que sur le vrai travail de plateforme.
Ce n'est pas un échec d'outillage. C'est un échec d'architecture. Et on pense que l'industrie est sur le point de corriger ça.
Terraform sait provisionner. Pas orchestrer une plateforme.
Terraform a participé à la démocratisation de l'Infrastructure as Code. C'était important. Mais le modèle qui en a émergé, des centaines de modules, chacun avec son propre cycle de vie, son propre versioning, son propre pipeline, ne passe pas à l'échelle comme les organisations en ont besoin.
Les upgrades de modules cassent les consommateurs en aval. Les state files driftent entre les applies. Les vérifications de conformité tournent manuellement, quand elles tournent. Chaque nouveau type de ressource, c'est un module de plus, un pipeline de plus, une doc de plus. Le coût de maintenance s'accumule plus vite que la valeur livrée.
On a vu des équipes plateforme rapporter 40% de leur temps uniquement en maintenance de modules. Le reste part en routage de tickets. Ce n'est pas du Platform Engineering ça. C'est de l'opérationnel maquillé en ingénierie de plateforme.
Infrastructure as Code, ce n'est pas la destination finale
Les plus grandes entreprises tech au monde ont déjà dépassé ce modèle. Google, Microsoft et Amazon convergent vers le même pari architectural : l'Infrastructure as CRDs.
Les Custom Resource Definitions transforment l'API Kubernetes en control plane universel. Pas juste pour les workloads, mais pour les bases de données, les enregistrements DNS, les certificats, les queues, les services cloud. Des projets comme Kro (Kubernetes Resource Orchestrator, CNCF), Azure Service Operator et AWS Controllers for Kubernetes pointent tous dans la même direction : l'infrastructure gérée nativement via Kubernetes, avec la réconciliation, la correction de drift et le GitOps intégrés au runtime.
Pas de state files à gérer. Pas de toolchain séparé à maintenir. Pas de détection de dérive ajoutée par-dessus. La boucle de contrôle gère la convergence en continu.
Ce n'est pas une prédiction. C'est déjà en production à grande échelle. L'écosystème CNCF se standardise autour de ça. La question pour la plupart des organisations, ce n'est pas si elles vont adopter ce modèle, mais quand.
Le besoin d'autonomie développeur
L'Infrastructure as CRDs résout la couche de gestion. Mais elle ne résout pas l'expérience développeur.
Donner du YAML brut et un accès cluster aux développeurs, ce n'est pas de l'autonomie. C'est un risque. Sans catalogue, sans formulaires, sans isolation par projet et sans garde-fous de conformité, la puissance de l'infrastructure Kubernetes-native reste verrouillée derrière l'équipe plateforme.
On a cherché une couche d'autonomie développeur construite pour ce nouveau paradigme. Les Internal Developer Platforms existantes étaient soit trop prescriptives, forçant un workflow spécifique, soit trop lourdes, nécessitant des mois de mise en place, soit complètement déconnectées des ressources Kubernetes-native. Rien ne collait.
C'est ce besoin qui explique pourquoi Knodex existe.
Knodex, le catalogue de demain
Knodex est un catalogue d'infrastructure open source construit sur Kro. Les équipes plateforme définissent les ressources avec des annotations Kubernetes. Knodex lit le schéma et génère l'interface. Pas de code frontend, pas de couche de configuration séparée.
Les développeurs parcourent un catalogue, remplissent un formulaire, déploient. L'isolation par namespace, le RBAC, les politiques OPA Gatekeeper et l'intégration GitOps assurent la gouvernance sans que l'équipe plateforme intervienne sur chaque requête.
L'équipe plateforme contrôle ce qui est disponible et comment c'est gouverné. Les développeurs ont de l'autonomie dans un cadre défini.
On a publié Knodex sous AGPL-3.0. Si votre infrastructure tourne déjà sur Kubernetes, la couche d'expérience développeur ne devrait pas être verrouillée derrière un éditeur. Ça s'installe avec une seule commande Helm en moins de cinq minutes.
Pourquoi ça compte maintenant
Le passage d'Infrastructure as Code à Infrastructure as CRDs s'accélère. L'écosystème CNCF va dans cette direction. Les grands cloud providers investissent dans les opérateurs Kubernetes comme interface primaire pour leurs services. Les organisations qui construisent l'autonomie développeur sur cette couche vont éliminer le goulot d'étranglement des tickets qui définit les équipes plateforme depuis dix ans.
Les autres vont continuer à recruter plus d'opérationnel, sans ajouter de valeur à leur plateforme.
On a construit Knodex parce qu'on pense que c'est un problème qui vaut la peine d'être résolu, et parce que les outils pour le résoudre existent enfin.
Tristan Paris est le fondateur de Provops, une entreprise de Platform Engineering qui aide les équipes à remplacer le chaos Terraform par de l'infrastructure accessible aux développeurs sur Kubernetes.