La Renaissance du Provider Crossplane pour OVH : Une Histoire de Communauté


Introduction

Il y a deux ans, j’ai commencé une mission simple mais ambitieuse : offrir aux utilisateurs d’OVHcloud une manière Kubernetes-native de gérer leurs ressources cloud via Crossplane. Aujourd’hui, je suis fier d’annoncer que le provider Crossplane pour OVH renaît, plus complet, plus stable, et soutenu par une communauté engagée.

Ce récit est à la fois un retour d’expérience personnel et une annonce officielle : le provider est à nouveau pleinement maintenu, avec désormais plus de 135 ressources cluster-scoped et namespaced, couvrant presque tout le provider Terraform OVH, et totalement compatible avec Crossplane 1.x et 2.x.

Les Débuts : Pourquoi créer ce provider ?

À l’époque, un vide existait : aucun provider Crossplane officiel ou communautaire n’existait pour OVHcloud.

Crossplane commençait seulement à émerger comme un pilier du Platform Engineering moderne — une manière d’exposer les ressources cloud via l’API Kubernetes. Même si peu d’équipes l’utilisaient (5 à 10%), celles qui y croyaient comprenaient sa puissance.

Je voulais leur offrir une alternative.

J’ai donc développé le premier provider Crossplane pour OVH, afin de :

  • gérer OVH comme on gère GCP ou AWS, via des CRDs ;
  • appliquer GitOps au provisioning cloud ;
  • unifier la gestion multicloud via l’API Kubernetes ;
  • aider les équipes plateforme à construire des plateformes self-service modernes.

Partager la Vision

J’ai présenté le provider à Aurélie Vache, qui a été extrêmement enthousiaste, bienveillante et encourageante.

Mais la position d’OVHcloud était claire :

Les providers communautaires ne peuvent pas être considérés comme des providers officiels.

C’est compréhensible : cela demande des ressources, du support, et un engagement long terme.

J’ai même proposé de donner le provider à OVH, pour qu’il soit maintenu en interne et synchronisé avec le provider Terraform.

Aucune réponse.

Ajouté à une charge de travail immense dans ma vie pro, j’ai dû mettre le projet en pause.

Pendant presque un an, le provider est resté en sommeil.

Le Tournant : Quand la communauté s’en mêle

Un jour, je suis contacté par NicolasKevin, et Ferréol de Theseus.

Ils m’annoncent quelque chose d’inattendu :

Ils utilisent le provider en production pour fournir un service de Database-as-a-Service à l’État français.

Nous avons échangé, discuté, partagé nos visions.

Ils étaient très satisfaits du provider.

Ils ont même tenté de convaincre OVH de le maintenir.

Réponse d’OVH :

« On n’a pas les ressources. La majorité de nos clients utilisent Terraform. »

En tant que Platform Engineer, c’était difficile à comprendre. Crossplane n’est pas un outil IaC de plus.

C’est l’API du cloud moderne.

Mais cette discussion m’a apporté quelque chose d’essentiel :

de la motivation.

L’Étincelle : un Pull Request inattendu

Quelques semaines plus tard, je tombe sur un commit de Fabien :

un PR pour mettre le provider à jour vers Crossplane 2.0.

Ce fut le déclic.

Je me suis dit :

« C’est un travail communautaire. Des gens en dépendent. Ce serait injuste de laisser l’innovation mourir. »

Alors je suis revenu.

J’ai remis le projet en ordre.

Mise à jour des ressources.

Compatibilité complète.

Nettoyage du code.

Tests avancés.

Le provider renaissait avec la version v2.9.0 (Release Note).

La Reprise : Une équipe de mainteneurs

L’open-source n’est jamais un projet solitaire.

Je suis très heureux que Endre Karlson et Alegrowin aient rejoint le projet comme mainteneurs.

Nous nous sommes engagés à en faire un provider :

  • stable
  • actif
  • évolutif
  • aligné avec Terraform et les nouvelles API OVH

Aujourd’hui, nous supportons :

  • 135+ ressources OVH
  • plus de 95% du provider Terraform
  • Crossplane 1.x et 2.x
  • une feuille de route en croissance

La communauté a ramené le provider à la vie.

Pourquoi c’est important

Crossplane transforme la manière dont les plateformes cloud sont conçues. L’écosystème OVH mérite lui aussi :

  • une approche déclarative
  • une gestion GitOps
  • une API Kubernetes pour le provisioning
  • un standard commun multi-cloud

Ce provider ouvre cette voie.

Non pas parce que le vendor l’a voulu, mais parce que la communauté l'a choisi.

La Suite

Nous travaillons déjà sur :

  • de la documentation enrichie
  • des exemples concrets
  • le support des futures API Terraform
  • l’ajout de services manquants
  • des tests automatisés avancés
  • des cas d’usage réels pour les plateformes internes

Contributions et retours sont les bienvenus.

L’open-source avance grâce à ceux qui s’impliquent.

Conclusion

Cette aventure m’a appris quelque chose de fondamental :

Quand un fournisseur cloud ne fournit pas l’innovation, la communauté la construit elle-même.

Merci à toutes celles et ceux qui ont soutenu, utilisé, contribué ou simplement cru en ce provider.

Pour les équipes qui construisent des plateformes, des services gouvernementaux, des SaaS ou des infrastructures modernes :

le provider Crossplane OVH est là, vivant, robuste, et maintenu.

Continuons à pousser l’écosystème open-source vers l’avant.


False
Ismail KABOUBI 15 novembre 2025
Partager cet article
Étiquettes
Pourquoi Terraform n’est pas fait pour le Platform Engineering