L’article sur l’Infrastructure as Code pose la dérive comme le talon d’Achille du modèle : l’écart entre ce que décrit le code et ce qui existe réellement, qui ne se corrige qu’au prochain terraform plan exécuté par quelqu’un qui y a pensé. Crossplane répond à ce problème précis par un changement d’architecture, pas par un correctif : il gère l’infrastructure cloud avec le même mécanisme de réconciliation continue que Kubernetes utilise déjà pour ses propres pods.

Terraform : un modèle apply-on-demand

Terraform calcule un plan à un instant précis, à partir de l’état stocké et de la configuration, puis l’applique une fois. Entre deux exécutions, rien ne surveille activement l’infrastructure : une modification manuelle effectuée dans la console cloud entre deux apply reste invisible jusqu’au prochain terraform plan, qui la révèle sous forme de diff, sans jamais l’avoir empêchée de se produire.

# Terraform décrit l'état cible, mais ne le vérifie
# qu'au moment où quelqu'un exécute plan/apply
resource "aws_s3_bucket" "data" {
  bucket = "my-app-data"
}

Crossplane : chaque ressource cloud est un objet Kubernetes réconcilié

Crossplane étend l’API Kubernetes avec des CRD qui représentent des ressources cloud (un bucket S3, une base RDS, un cluster GKE), gérées par un contrôleur qui applique la même boucle de réconciliation que celle qui maintient un Deployment au nombre de replicas voulu. La ressource n’est jamais « appliquée une fois » : elle est surveillée en continu, et toute dérive détectée est corrigée automatiquement, sans attendre qu’un humain relance un outil.

apiVersion: s3.aws.upbound.io/v1beta1
kind: Bucket
metadata:
  name: my-app-data
spec:
  forProvider:
    region: eu-west-1
  # Le contrôleur Crossplane réconcilie cet objet en continu,
  # comme n'importe quel Deployment Kubernetes

Une modification manuelle effectuée directement dans la console cloud sur une ressource gérée par Crossplane est détectée et annulée à la prochaine boucle de réconciliation, généralement en quelques minutes, sans action humaine, exactement comme Kubernetes replace un pod supprimé manuellement.

Ce que ce changement de paradigme coûte réellement

La réconciliation continue élimine la fenêtre de dérive silencieuse, mais elle demande d’opérer un contrôleur Kubernetes supplémentaire (le contrôleur Crossplane lui-même, plus un « provider » par fournisseur cloud) à l’intérieur du cluster, une responsabilité opérationnelle que Terraform, simple binaire exécuté depuis une CI, n’impose pas. Crossplane suppose aussi une équipe déjà à l’aise avec les concepts Kubernetes (CRD, contrôleurs, kubectl) pour gérer une infrastructure qui, elle, ne tourne pas forcément dans le cluster.

L’écosystème, encore inégal selon le fournisseur

Terraform bénéficie d’une couverture quasi exhaustive de chaque fournisseur cloud, mûrie depuis près d’une décennie. Les providers Crossplane, bien que couvrant les cas d’usage principaux des fournisseurs majeurs (AWS, GCP, Azure), restent plus jeunes et moins complets sur les ressources de niche : vérifier la maturité du provider concerné avant de s’engager reste une étape obligatoire, pas un détail.

À retenir

Terraform applique un plan à un instant donné, laissant une fenêtre de dérive silencieuse entre deux exécutions ; Crossplane élimine cette fenêtre en traitant chaque ressource cloud comme un objet Kubernetes réconcilié en continu, exactement comme un Deployment. Ce changement de paradigme a un coût réel : un contrôleur de plus à opérer, une exigence de compétence Kubernetes pour gérer une infrastructure qui n’y tourne pas forcément, et un écosystème de providers encore moins mature que celui de Terraform sur les ressources de niche. Le choix se pose naturellement dès qu’une industrialisation CI/CD doit décider comment traiter la dérive d’infrastructure sur la durée, pas seulement au moment du provisionnement initial.