Il y a une différence fondamentale entre déployer de l’infrastructure et orchestrer de l’infrastructure. Pendant longtemps, les équipes cloud ont confondu les deux. Déployer consistait à générer un plan, l’appliquer, puis espérer que l’état réel resterait conforme à l’état désiré jusqu’au prochain changement. Or, dans un monde multi-cloud, dynamique, soumis à des modifications constantes, cette approche montre rapidement ses limites.
Crossplane s’inscrit dans une autre logique : il ne considère pas l’infrastructure comme un ensemble de scripts exécutés ponctuellement, mais comme un système vivant dont l’état doit converger en permanence vers un modèle déclaré. Cette différence conceptuelle change profondément la manière dont une organisation conçoit son architecture cloud.
Architecture interne : providers, CRDs et reconciliation loop
Crossplane fonctionne comme un ensemble de contrôleurs Kubernetes spécialisés. Chaque fournisseur cloud est encapsulé dans un “provider”, lequel expose des Custom Resource Definitions représentant des ressources cloud concrètes : bases de données, réseaux, buckets, clusters, secrets, etc.
Lorsqu’un manifeste est appliqué au cluster, le contrôleur Crossplane observe la ressource déclarée, compare son état avec l’état réel du provider cloud concerné, puis exécute les appels API nécessaires pour converger vers la configuration attendue. Cette boucle de reconciliation s’exécute en continu, ce qui signifie qu’une dérive d’état détectée peut être automatiquement corrigée sans intervention manuelle. 
Compositions : abstraction d’architecture
La véritable puissance de Crossplane apparaît lorsque l’on aborde le mécanisme de “Compositions”. Une composition permet de regrouper plusieurs ressources cloud sous une abstraction unique, créant ainsi une interface déclarative simplifiée pour des stacks complexes.
Par exemple, au lieu d’exposer directement un VPC, trois subnets, une gateway NAT, une table de routage et une base de données, une équipe plateforme peut définir une abstraction “Environment” qui encapsule tous ces composants.
apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
name: xpostgresql-environment
spec:
compositeTypeRef:
apiVersion: platform.example.org/v1alpha1
kind: XPostgresEnvironment
resources:
- name: network
base:
apiVersion: ec2.aws.crossplane.io/v1beta1
kind: VPC
spec:
forProvider:
cidrBlock: 10.0.0.0/16
- name: database
base:
apiVersion: rds.aws.crossplane.io/v1beta1
kind: DBInstance
spec:
forProvider:
engine: postgres
dbInstanceClass: db.t3.micro
Ce mécanisme permet à une équipe interne de provisionner un environnement complet avec un simple objet composite, sans exposer la complexité interne des ressources sous-jacentes.
Claims et séparation des responsabilités
Crossplane introduit également le concept de “Claims”, qui permet à une équipe applicative de demander une ressource sans connaître les détails d’implémentation. L’équipe plateforme définit la composition, tandis que l’équipe applicative consomme une abstraction.
apiVersion: platform.example.org/v1alpha1
kind: PostgresInstance
metadata:
name: app-db
spec:
parameters:
storageGB: 20
version: "14"
La plateforme décide si cette base sera provisionnée sur AWS, GCP ou Azure. L’équipe produit reste découplée du provider spécifique. Cette séparation est cruciale dans les environnements multi-cloud stratégiques.
Politiques avancées et contrôle d’accès
Crossplane peut être combiné avec des outils comme Open Policy Agent (OPA) ou Kyverno pour imposer des règles strictes sur les ressources déclarées. Par exemple, interdire la création d’instances de base de données en dehors d’un certain type, ou forcer l’activation du chiffrement.
Dans ce modèle, l’infrastructure devient soumise aux mêmes mécanismes de gouvernance que les workloads Kubernetes classiques, renforçant la cohérence globale de l’organisation.
Comparatif technique : Crossplane vs Terraform vs Pulumi
Il est impossible d’aborder Crossplane sans le comparer aux solutions existantes, notamment Terraform et Pulumi. Les trois outils visent la gestion d’infrastructure déclarative, mais leurs philosophies divergent profondément.
Terraform repose sur un modèle plan/apply. Il génère un plan d’exécution statique, l’applique, puis termine son cycle. Il n’y a pas de boucle continue native de reconciliation. La gestion de dérive d’état nécessite des exécutions régulières et une discipline organisationnelle stricte. Terraform est extrêmement mature, dispose d’un vaste écosystème, mais reste centré sur une logique transactionnelle.
Pulumi adopte une approche plus flexible en permettant l’utilisation de langages de programmation (TypeScript, Python, Go). Il offre plus de liberté, mais au prix d’une complexité accrue et d’une dépendance forte au code impératif. Pulumi facilite les logiques dynamiques, mais ne propose pas nativement un modèle continu intégré à Kubernetes.
Crossplane, quant à lui, adopte un modèle natif Kubernetes. Son principal avantage réside dans la reconciliation continue, l’intégration GitOps naturelle et la capacité à composer des abstractions réutilisables. En revanche, sa courbe d’apprentissage est plus élevée et son écosystème, bien que solide, reste plus récent que celui de Terraform.
Avantages stratégiques de Crossplane
- Multi-cloud natif et homogène
- Reconciliation continue
- Intégration GitOps transparente
- Compositions abstraites réutilisables
- Découplage équipe plateforme / équipe produit
Ce modèle correspond particulièrement aux organisations ayant déjà adopté Kubernetes comme socle d’orchestration global.
Conclusion : vers une infrastructure déclarative continue
Crossplane ne cherche pas à remplacer brutalement Terraform ou Pulumi, mais à proposer un paradigme différent, davantage aligné avec l’évolution des pratiques GitOps et des architectures cloud modernes. Là où les outils traditionnels fonctionnent par étapes discrètes, Crossplane fonctionne en permanence, en observant et corrigeant l’état réel.
Dans un environnement multi-cloud où les ressources sont dynamiques, éphémères et interconnectées, cette capacité à maintenir la convergence en continu représente une avancée significative. L’infrastructure cesse d’être un script exécuté ponctuellement pour devenir un système déclaratif vivant, intégré au cœur même de l’orchestration Kubernetes.
