À retenir

  • Terraform n’est pas le problème — c’est le mauvais outil pour une plateforme self-service : apply manuel par changement, pas d’API native, pas de réconciliation continue.
  • Kubernetes + KRM + CRD transforment l’infrastructure en API self-service : demandez une base, un bucket ou un cache avec un simple YAML — sans ticket.
  • Kelsey Hightower lui-même l’a affirmé : Terraform n’est pas adapté à la construction de control planes façon grands fournisseurs cloud.
  • KPI remontés par les équipes ayant fait le saut : +50 % de productivité, −36 % de lead time, +40 % de qualité logicielle (Puppet State of DevOps, Gartner).

Vous faites du DevOps ou du Cloud aujourd’hui ? Alors vous avez vécu ça : vous livrez une fonctionnalité critique, mais tout s’arrête parce qu’il faut un ticket Jira pour provisionner une base de données, un bucket S3 ou n’importe quel autre service cloud. Bienvenue dans le TicketOps — un schéma qui crée des goulots d’étranglement, des silos, et casse en silence l’agilité que vos équipes ont mis des années à construire.

Soyons clairs : le fameux principe « you build it, you run it » se transforme trop souvent en « you build it, quelqu’un d’autre le met en file d’attente, et peut-être qu’un jour tu pourras le run ». Résultat : perte de temps, développeurs frustrés et innovation à l’arrêt.

Pourquoi Terraform n’est pas adapté au Platform Engineering

Terraform est populaire et fonctionne bien pour provisionner des ressources ponctuellement — mais il n’a jamais été conçu pour être le moteur d’une plateforme self-service. Trois manques structurels l’expliquent :

  • Cycle manuel — un terraform apply est nécessaire pour chaque modification. Pas viable pour des ressources dynamiques et évolutives.
  • Pas d’API native — impossible d’exposer facilement votre infrastructure en self-service via une API simple.
  • Pas de réconciliation continue — Terraform ne ramène pas automatiquement l’infrastructure vers son état désiré quand elle dérive.

Bref, pour une véritable plateforme-as-a-service, Terraform atteint vite son plafond.

Kubernetes + KRM + CRD : le nouveau modèle self-service

Kubernetes n’est plus un simple orchestrateur de conteneurs — c’est un control plane universel pour toute votre infrastructure. Le mécanisme : le modèle KRM (Kubernetes Resource Model) et les Custom Resource Definitions (CRD), qui permettent de tout gérer de façon déclarative.

Imaginez ça :

  • Besoin d’une base de données ? Vous appliquez un YAML.
  • Besoin d’un bucket Cloud Storage ? Encore un YAML.
  • Envie d’un cache Redis ? Toujours ce bon vieux YAML.

C’est du self-service pur, sans aucun ticket, grâce à Kubernetes et à des projets comme Crossplane, AWS Controllers for Kubernetes (ACK) et Google Config Connector.

Lors de son intervention au Control Plane Day with Crossplane 2023, Kelsey Hightower — Developer Advocate chez Google et figure emblématique de l’écosystème cloud native — l’a dit sans détour :

« Terraform n’est pas adapté à la création de control planes similaires à ceux des grands fournisseurs de cloud public. »

Venant d’un ingénieur dont les conférences et les démos live guident les bonnes pratiques d’infrastructure depuis une décennie, l’affirmation pèse lourd.

Passez au niveau supérieur : exposez tout via REST, gRPC et SDK

L’objectif de cette architecture est simple : donner de l’autonomie aux équipes sans perdre le contrôle. Kubernetes joue le rôle de control plane central au-dessus du KRM, et les équipes — produit, DevOps, développement — provisionnent ce dont elles ont besoin via une API unique, exposée en REST, gRPC ou même WebSocket.

Architecture Kubernetes Platform Engineering avec KRM, CRDs et API-first

Cette API n’est pas un gadget — elle devient le point d’entrée standard, utilisable depuis des bibliothèques clientes (Go, Python, JavaScript, Java), des outils CLI ou un portail interne type Backstage. Les équipes ne perdent plus de temps dans les tickets, et les cycles de livraison s’accélèrent.

En arrière-plan, la plateforme réconcilie en continu les ressources avec vos fournisseurs cloud et vos outils clés (Google Cloud, GitLab, Kubernetes, Vault, Okta…). Pendant que les équipes se servent en self-service, vos équipes Platform Engineering, SRE et DevSecOps appliquent les règles de sécurité, les standards de fiabilité et les bonnes pratiques de l’entreprise. Vous industrialisez le cloud à l’échelle sans friction : la gouvernance reste centrale, les équipes gagnent en vitesse — le meilleur des deux mondes.

Mieux encore, vous pouvez exposer vos services comme une API first-class. À partir de vos CRD, vous générez automatiquement des fichiers protobuf, puis exposez des endpoints REST ou gRPC et fournissez des SDK pour chaque langage utilisé par vos développeurs. Ils n’auront même plus à écrire de YAML — ils appelleront directement votre API de plateforme. Le rêve du développeur moderne devient réalité :

  • Zéro ticket
  • Provisioning instantané
  • Intégration GitOps transparente

Les chiffres parlent d’eux-mêmes

Voici des KPI concrets remontés par les organisations ayant fait le saut du TicketOps vers des plateformes self-service :

  • 🚀 +50 % de productivité des développeurs
  • 🕒 −36 % de lead time entre le commit et la mise en production
  • 🧘 +40 % d’amélioration de la qualité logicielle
  • 📈 75 % des grandes entreprises devraient adopter ce modèle d’ici fin 2025 (Gartner)

Ces chiffres viennent du terrain — notamment du rapport State of DevOps de Puppet et des analyses de Gartner. Vos résultats varieront, mais la direction est constante : moins d’attente, livraison plus rapide, meilleure qualité.

Bye-bye TicketOps, bonjour self-service

L’époque des tickets Jira interminables pour un simple provisionnement est révolue. Adoptez Kubernetes comme socle de votre Platform Engineering — avec KRM et CRD — et offrez à vos équipes une expérience véritablement self-service. Votre infrastructure devient agile, évolutive et API-first, et vos développeurs vous remercieront (peut-être même avec des cookies 🍪).

Alors — prêt à laisser Terraform là où il n’a jamais été conçu pour aller, et à entrer dans un futur API-first avec Kubernetes ? Vous n’allez pas le regretter. 🚀

Conclusion : comment Edixos peut vous accompagner

Chez Edixos, nous savons qu’une plateforme cloud ne se résume pas à empiler des outils : elle doit être pensée pour durer, évoluer et répondre aux besoins spécifiques de chaque organisation. Notre expertise va bien au-delà de la mise en place de clusters Kubernetes :

  • Nous écrivons des contrôleurs Kubernetes sur mesure qui automatisent vos processus métier et vos besoins spécifiques.
  • Nous intégrons des moteurs de composition puissants comme Crossplane et Kro pour transformer Kubernetes en véritable moteur de provisioning multi-cloud.
  • Nous travaillons avec des contrôleurs existants comme Config Connector (KCC), qui exposent nativement les services des grands cloud providers via des CRD Kubernetes.
  • Nous construisons des plateformes complètes et API-first — en exposant vos services via REST, gRPC et SDK multi-langages — pour unifier l’accès et accélérer l’adoption.

Ce que nous offrons, c’est un savoir-faire unique pour industrialiser vos plateformes cloud : gouvernance, sécurité et self-service à grande échelle. C’est exactement le type de travail derrière notre décennie d’histoire avec Kubernetes. Si votre ambition est une plateforme robuste qui aligne innovation, agilité et contrôle, nous avons les briques techniques et l’expérience pour y parvenir.

Parlons de vos défis Kubernetes avancés

Vous cherchez à automatiser vos opérations, modéliser vos processus métier ou industrialiser vos déploiements sur Kubernetes ? Discutons de vos enjeux et voyons comment l’API Machinery peut vous apporter vitesse, fiabilité et scalabilité.

À lire aussi

Réponses directes

Questions fréquentes

Terraform est-il mauvais ? Faut-il arrêter de l'utiliser ?

Non. Terraform est excellent pour provisionner de l'infrastructure ponctuellement et pour des changements one-shot. Il montre ses limites comme moteur d'une plateforme self-service car il exige un apply manuel par changement, n'expose aucune API native et ne réconcilie pas la dérive en continu — les trois besoins d'un control plane.

Qu'est-ce que le Kubernetes Resource Model (KRM) ?

Le KRM est le modèle d'API déclaratif de Kubernetes : vous déclarez l'état désiré en YAML, et des contrôleurs réconcilient en continu la réalité pour la faire correspondre. Avec les Custom Resource Definitions (CRD), le KRM va au-delà des conteneurs — bases de données, buckets, tout service cloud — faisant de Kubernetes un control plane universel.

Comment Kubernetes et les CRD permettent-ils un self-service d'infrastructure ?

Les CRD permettent aux équipes plateforme d'exposer les ressources cloud comme de simples API YAML. Un développeur applique un manifeste pour une base ou un cache, et un contrôleur (via Crossplane, ACK ou Config Connector) le provisionne et le réconcilie automatiquement — sans ticket Jira, sans apply manuel, avec RBAC et policies appliqués au centre.

Qu'est-ce que le TicketOps et pourquoi est-ce un problème ?

Le TicketOps est l'anti-pattern où les développeurs doivent ouvrir un ticket pour provisionner la moindre infrastructure, puis attendre qu'une autre équipe le traite. Il casse le principe « you build it, you run it », crée des goulots et des silos, et ralentit la livraison. Les plateformes self-service sur Kubernetes l'éliminent.

Puis-je exposer l'infrastructure Kubernetes en API REST ou gRPC ?

Oui. Comme les CRD sont des définitions d'API, vous pouvez en générer du protobuf et exposer des endpoints REST, gRPC ou WebSocket, plus des SDK multi-langages (Go, Python, JavaScript, Java). Les développeurs consomment la plateforme via une API unique — ou des outils comme Backstage — au lieu d'écrire du YAML.