Crossplane : gérer son cloud comme des ressources Kubernetes

Terraform calcule un plan, l'applique, écrit un state, et s'arrête. C'est un outil en ligne de commande, pas un service qui tourne. Un processus court, lancé à la main ou par une pipeline, qui ne réconcilie l'état désiré avec l'infrastructure réelle qu'au moment où on l'invoque. Entre deux apply, si quelqu'un modifie une ressource à la console, ajuste une règle de pare-feu en urgence ou supprime un bucket par erreur, Terraform ne le sait pas. La dérive s'installe silencieusement, et on ne la découvre qu'au prochain plan, parfois des semaines plus tard, sous la forme d'un diff inattendu qu'il faut décrypter. Le state, lui, devient un fichier critique qu'il faut verrouiller, stocker et protéger, sous peine de corruption.

Crossplane renverse le modèle. L'infrastructure n'est plus un plan qu'on applique ponctuellement, c'est une ressource Kubernetes réconciliée en continu. Un control plane tourne en permanence et compare sans relâche l'état désiré, décrit dans des manifests, à l'état réel chez le fournisseur cloud. Toute dérive est corrigée automatiquement par les boucles de contrôle, le même mécanisme qui fait que Kubernetes maintient le nombre de réplicas d'un Deployment. Quelqu'un supprime une ressource à la main ? Le control plane la recrée. Quelqu'un change un paramètre hors process ? Il le ramène à l'état déclaré. Ce n'est pas un outil qu'on lance, c'est un système qui veille.

Crossplane s'étend par providers. Un provider apporte le savoir-faire pour piloter un fournisseur externe, AWS, Azure, GCP, mais aussi n'importe quelle ressource hors de Kubernetes. Une fois le provider installé, ses ressources deviennent des objets Kubernetes à part entière.

Ces objets, ce sont les managed resources. Chaque managed resource représente une ressource externe du fournisseur, exposée derrière une API Kubernetes unique et cohérente. Un bucket S3, une base de données managée, un réseau virtuel : tout devient un objet qu'on décrit en YAML, qu'on applique avec kubectl, et que le control plane réconcilie. La granularité est fine, calquée sur l'API du fournisseur.

Au-dessus, les compositions et les Composite Resource Definitions changent l'échelle. Une Composite Resource Definition déclare une nouvelle API, et une composition décrit comment cette API se traduit en un assemblage de managed resources. L'équivalent Crossplane d'un module Terraform, c'est cette Composite Resource exposée comme un point d'API. Concrètement, une équipe plateforme peut définir une abstraction « base de données de production » qui cache derrière elle l'instance, le réseau, les règles de sécurité et les sauvegardes, et l'exposer en self-service. Les équipes applicatives demandent une base via une ressource Kubernetes simple, sans connaître les détails du fournisseur. C'est le cœur de l'usage : offrir des briques d'infrastructure self-service à travers des API maison.

Comme tout est ressource Kubernetes, le GitOps tombe sous le sens. Argo CD ou Flux appliquent des manifests d'infrastructure exactement comme ils appliquent des manifests applicatifs. Le dépôt Git devient la source de vérité de l'infra, le control plane réconcilie en continu vers cet état, et la boucle GitOps se ferme sans outillage spécifique. Là où brancher Terraform sur du GitOps demande des wrappers, des runners et une gestion du state, Crossplane parle nativement le langage des contrôleurs Kubernetes. La même chaîne Argo CD pour le GitOps qui déploie vos applications déploie alors votre infrastructure.

L'opposition avec Terraform tient en un mot : réconciliation. Terraform fonctionne en mode impératif déclenché, on demande explicitement l'application. Crossplane réconcilie en continu. Cette différence a des conséquences concrètes au-delà de la dérive. Sur un champ immuable, par exemple, Terraform détruit et recrée la ressource pour appliquer le changement, ce qui peut casser un service en production sans prévenir. Crossplane ne supprime une ressource externe que si l'objet correspondant disparaît de Kubernetes et que la politique de suppression l'autorise. Le comportement par défaut protège mieux l'existant. L'approche conservatrice et à la demande de Terraform peut aussi mener à des situations de blocage où l'état désiré et l'état réel ne convergent plus, un piège que la réconciliation continue évite par construction.

Face à Pulumi, la frontière est différente. Pulumi reste fondamentalement un moteur de déploiement piloté par du code dans un langage généraliste, lancé ponctuellement, avec un state à gérer, comme Terraform mais en TypeScript, Python ou Go. La logique impérative déclenchée est la même. Crossplane n'est pas un outil de déploiement, c'est un plan de contrôle vivant. La question n'est pas « quel langage pour décrire l'infra » mais « veut-on un outil qu'on lance ou un système qui réconcilie ».

Le poids de Crossplane dans l'écosystème ne relève plus du pari. Le projet a gradué au plus haut niveau de la CNCF le 6 novembre 2025, après cinq ans dans la fondation. Plus de 3 000 contributeurs venus de 450 organisations, et des plateformes internes bâties dessus chez Nike, SAP, IBM ou Akamai. La graduation CNCF est un signal concret : c'est le marqueur qu'un projet est jugé mûr et largement adopté en production.

Crossplane n'est pas la réponse à tout, et le vendre comme tel serait malhonnête. La courbe d'apprentissage est réelle : il faut maîtriser Kubernetes, le modèle des contrôleurs, les Composite Resource Definitions et les compositions avant d'être productif. Pour une équipe qui ne vit pas déjà dans Kubernetes, c'est un investissement lourd. La maturité des providers varie selon les fournisseurs et les services : certains couvrent l'intégralité de l'API cloud, d'autres traînent du retard sur les ressources récentes, et c'est un point à vérifier avant de s'engager sur un périmètre précis.

Surtout, le control plane devient une pièce critique. Tant que Terraform ne tourne pas, il ne casse rien. Le control plane Crossplane, lui, est toujours actif et porte la responsabilité de l'état de votre infrastructure. S'il tombe, la réconciliation s'arrête ; s'il est mal configuré, il peut agir à mauvais escient sur des ressources de production. Il faut donc l'opérer comme un composant de production à part entière : haute disponibilité, sauvegarde de son état, supervision, contrôle d'accès strict. On gagne la réconciliation continue, on hérite d'un système critique de plus à tenir debout.

Le verdict est tranché. Pour une plateforme interne qui expose des briques d'infrastructure en self-service, réconciliée et GitOps-native, Crossplane est le bon outil, à condition d'assumer Kubernetes et d'opérer le control plane sérieusement. Pour du provisioning ponctuel, un environnement qu'on monte et qu'on jette, une infra simple sans besoin de self-service ni de plateforme, Terraform ou OpenTofu restent plus directs et moins coûteux à mettre en route. Le choix ne dépend pas de la mode, il dépend de si vous construisez une plateforme ou si vous provisionnez de l'infra.

Pour situer Crossplane dans l'outillage IaC, voir notre guide Terraform pour l'infrastructure as code, notre dossier sur la migration de Terraform vers OpenTofu, notre analyse de Pulumi en 2026, le guide Argo CD et le GitOps et notre tour d'horizon platform engineering et IDP.

• Crossplane vs Terraform, blog Crossplane : control plane contre outil CLI, réconciliation continue, champs immuables, deadlock.
• Managed Resources, documentation Crossplane : managed resources, API unifiée, politique de suppression.
• Crossplane Graduation Announcement, CNCF : graduation CNCF, contributeurs, organisations en production.
• Crossplane, page projet CNCF : statut de maturité et historique du projet dans la fondation.