Pourquoi Terraform n’est pas fait pour le Platform Engineering

Do you practice DevOps or Cloud today? You’ve surely already experienced this frustrating sit​uation: you’re developing a new feature or a critical application, but everything stops because you need to create a Jira ticket to provision a database, an S3 bucket, or any other cloud service. Welcome to the world of TicketOps. This process, too widespread in companies, creates bottlenecks, silos, and breaks the agility IT and DevOps teams have spent years building.

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, frustration des développeurs et ralentissement de l’innovation.

Pourquoi Terraform n’est pas adapté au Platform Engineering

Terraform est populaire, il fonctionne bien pour gérer des ressources ponctuellement. Mais Terraform n’est pas idéal pour du Platform Engineering. Voici pourquoi:

  • Cycle manuel : Un terraform apply est nécessaire pour chaque modification. Pas idéal pour des ressources évolutives et dynamiques.
  • Absence d'API native : Impossible d'exposer facilement votre infrastructure en self-service via une API simple.
  • Manque de réconciliation continue : Terraform n’ajuste pas automatiquement votre infra en continu selon l'état désiré.

Bref, pour une plateforme "as-a-service", Terraform est vite limité.

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

Kubernetes n’est plus simplement un orchestrateur de conteneurs. Aujourd'hui, Kubernetes est un véritable control plane universel pour toute votre infrastructure. Comment ? Avec le modèle KRM (Kubernetes Resource Model) et les CRD (Custom Resource Definitions).

Imaginez ça :

  • Vous voulez une base de données ? Vous appliquez un YAML.
  • Vous avez besoin d'un bucket Cloud Storage ? Encore un YAML.
  • Vous souhaitez un cache Redis ? Toujours ce bon vieux YAML.

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

Lors de son intervention durant le Control Plane Day with Crossplane 2023, Kelsey Hightower, Developer Advocate chez Google et figure emblématique de l’écosystème Cloud Native, a clairement affirmé que 

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

Cette affirmation revêt une importance particulière, Kelsey étant largement reconnu pour son expertise et son influence dans la communauté Kubernetes et Cloud Native, notamment par ses nombreuses conférences, démonstrations en direct et contributions qui ont guidé l’adoption des bonnes pratiques modernes d’infrastructure.



Passez au niveau supérieur : Exposez tout via des API REST, gRPC et SDKs

Quand on regarde cette architecture, on comprend tout de suite où elle veut en venir : donner de l’autonomie aux équipes sans perdre le contrôle. Kubernetes joue ici le rôle de véritable control plane central, basé sur le modèle KRM (Kubernetes Resource Model). Les équipes – qu’elles soient produit, DevOps ou développement – peuvent provisionner elles-mêmes les services 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


Ce qui est intéressant, c’est que cette API n’est pas un simple gadget. Elle devient un point d’entrée standard, utilisable avec des bibliothèques clientes (Go, Python, JavaScript, Java), des outils CLI ou une plateforme interne type Backstage. Résultat : les équipes ne perdent plus de temps dans des tickets et les cycles de livraison s’accélèrent.

En arrière-plan, la plateforme s’occupe de réconcilier en continu les ressources avec vos fournisseurs cloud et vos outils clés (Google Cloud, GitLab, Kubernetes, Vault, Okta…). Et pendant que vos équipes consomment ces services en self-service, vos équipes Platform Engineering, SRE et DevSecOps peuvent appliquer les bonnes pratiques, les règles de sécurité et les standards de fiabilité de l’entreprise.

C’est exactement le genre de modèle qui permet d’industrialiser le cloud à l’échelle sans créer de friction. Vous gardez la gouvernance et les équipes, elles, gagnent en vitesse. C’est le meilleur des deux mondes.

Allons encore plus loin. Vous pouvez exposer vos services comme une API first-class. Avec vos CRD, vous pouvez générer automatiquement des fichiers protobuf , puis exposer facilement une API REST, gRPC et même fournir des SDK pour chaque langage que vos développeurs utilisent.

Vos développeurs n'auront même plus à écrire un YAML. Ils utilisent 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 observés chez ceux qui ont sauté le pas :

  • 🚀 +50% de productivité des développeurs
  • 🕒 -36% de temps entre le commit et la mise en prod (lead time)
  • 🧘 +40% d'amélioration de la qualité logicielle
  • 📈 75% des grandes entreprises adopteront ce modèle d'ici fin 2025 (selon Gartner)
Ces chiffres ne sortent pas de nulle part, ils viennent directement du terrain, notamment du rapport "State of DevOps" de Puppet et de Gartner.


Bye-bye TicketOps, Bonjour Self-Service

Fini l'époque des tickets Jira interminables pour un simple provisionnement. Adoptez Kubernetes comme base de votre Platform Engineering avec KRM et CRD pour offrir à vos équipes une expérience véritablement self-service.

Votre infrastructure sera enfin agile, évolutive, API-first, et vos développeurs vous remercieront (peut-être même avec des cookies). 🍪

Alors, prêt à abandonner Terraform et à plonger dans le futur 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 simple mise en place de clusters Kubernetes :

  • Nous écrivons des contrôleurs Kubernetes sur‑mesure, capables d’automatiser vos processus métier et vos besoins spécifiques.
  • Nous intégrons des solutions de composition puissantes comme Crossplane or​ Kro , qui vous permettent de transformer Kubernetes en un véritable moteur de provisioning multi‑cloud.
  • Nous travaillons avec les contrôleurs existants comme Config Connector (KCC), qui exposent nativement les services des grands cloud providers via des CRDs Kubernetes.
  • Nous savons construire des plateformes complètes et API‑first, en exposant vos services via REST, gRPC et SDKs multi‑langages, pour unifier l’accès et accélérer l’adoption par vos équipes.

Ce que nous offrons, c’est un savoir‑faire unique pour industrialiser vos plateformes cloud : gouvernance, sécurité et self‑service à grande échelle. Si votre ambition est de bâtir 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é.

Pourquoi Terraform n’est pas fait pour le Platform Engineering
Ismail KABOUBI 25 juillet 2025
Partager cet article
Dans les coulisses d’Edixos
Retour sur notre histoire, nos projets les plus fous et ce qui fait de nous des experts Kubernetes à part.