Terraform est efficace pour gérer de l’infrastructure ; pas des workflows data.

À force de s’en servir en conjonction avec Snowflake, Accor en est arrivé à ce constat. Entre absence de validation locale, gestion manuelle des dépendances et nécessité d’outils externes pour contrôler la qualité des données, la mise à l’échelle et la collaboration s’en trouvaient limitées.

Le groupe hôtelier a fini par basculer vers une stack associant dbt Core pour les transformations et un Airflow managé (Astro) pour l’orchestration, avec la bibliothèque Cosmos – proposée par le fournisseur d’Astro – pour faire la passerelle. Cette dernière déduit automatiquement le lignage des tâches et déclenche les contrôles de data quality immédiatement après la matérialisation d’une table ou d’une vue lors d’un dbt run.

Une déploiement Airflow « léger » qui rafraîchit uniquement les DAG

Le passage au tandem dbt-Airflow a impliqué un changement des pratiques de data engineering. Entre autres, passer d’étapes séparées pour la création et le peuplement de tables à une action unique utilisant exclusivement la commande SQL SELECT.

Chaque équipe possède son repo et déploie indépendamment. Tout part d’un template géré avec Copier. L’ensemble est réconcilié dans le projet principal, poussé vers Astro. Les scripts CI/CD sont centralisés dans un dépôt étiqueté.

Par défaut, Astro reconstruit l’image Docker à chaque modification. Le déploiement : dure alors environ 5 minutes. Il existe toutefois un mode « léger » dont Accor a tiré parti. Celui-ci synchronise simplement les DAG (graphes acycliques dirigés, représentant les tâches à exécuter) et évite ainsi un rebuild.

Pour exploiter ce mécanisme, le pipeline CI/CD place chaque projet dbt dans le répertoire dags/ du projet principal. Le déploiement dure alors environ 1 minute. Il couvre 95 % des exécutions. L’autre option reste utilisée pour l’upgrade des dépendances et les changements sur l’image de base (i.e. modification des fichiers include, requirements.txt ou Dockerfile).

Imbriquer chaque projet dbt dans le répertoire dags/ permet à Cosmo de générer automatiquement les tâches Airflow correspondantes. Et de construire des DAG sans intervention manuelle. Les tests peuvent se faire en local, avec dbt run et dbt test.

Accor vise un pipeline pour chaque équipe

Avec une telle configuration multilocataire, les cycles d’upgrade d’Airflow peuvent ralentir. Il n’y a, par ailleurs, pas moyen de prioriser des jobs. Et l’existence d’un seul chemin CI/CD vers la prod pose la question du point unique de défaillance, en plus des risques de conflit de noms et de bibliothèques.

Accor réfléchit donc à donner à chaque équipe son pipeline et à découpler la propriété du code. Tout en permettant l’hibernation des workflows à faible trafic.

Illustration générée par IA

The post Accor a écarté Terraform de sa stack data engineering appeared first on Silicon.fr.

Le couperet est tombé : IBM arrête le support du CDKTF (Cloud Development Kit pour Terraform).

Cette boîte à outils permet de générer des fichiers de configuration en utilisant des langages impératifs (TypeScript, Python, Java, C# et Go). Elle s’inspire de l’AWS Cloud Development Kit – et en réutilise des bibliothèques.

IBM estime que le projet n’a pas trouvé sa place. Il est vrai que la traction sur les canaux communautaires et au-delà est restée minimale.
Le CDKTF n’a en tout cas jamais été stabilisé. Jusqu’à la dernière version, sortie en juin 2025, les changements non rétrocompatibles sont demeurés monnaie courante.

Un tout autre contexte qu’OpenTofu

Dans ce contexte, IBM s’affirme d’autant plus ouvert à l’idée d’un fork (le code est sous licence MPL). Ce n’est effectivement pas la même histoire qu’avec OpenTofu. Ce projet concurrent de Terraform avait émergé à l’été 2023. HashiCorp, alors encore indépendant, venait de changer la lience de ses produits. Exit la MPL (Mozilla Public License), place à la BSL (Business Source License), qui a eu pour principal effet d’interdire d’« embarquer » ou d’« héberger » les éditions communautaires desdits produits dans le cadre de toute offre commerciale destinée à un usage en prod.

Lancé sous l’impulsion d’entreprises dont le modèle économique reposait au moins en partie sur Terraform, OpenTofu avait été stabilisé début 2024. Entre-temps, une autre initiative avait vu le jour : OpenBao, pensé comme un substitut à Vault, autre produit HashiCorp.

IBM est offciellement devenu propriétaire de HashiCorp en février 2025, quasiment un an après avoir annoncé son projet d’acquisition. En attendant un éventuel fork du CDKTF, il invite à utiliser la commande cdktf synth –hcl pour convertir les fichiers .tf en HCL (HashiCorp Configuration Language).

Illustration © zeeika – Adobe Stock

The post IBM recentre Terraform sur le langage HCL appeared first on Silicon.fr.