Cloud Composer : orchestrer des workflows data sur Google Cloud
En bref
Cloud Composer, officiellement renommé « Managed Service for Apache Airflow » en 2025, orchestre des workflows data complexes sur Google Cloud via la brique open source Apache Airflow.
Composer 3 masque l’infrastructure GKE sans la supprimer : « serverless » reste un raccourci inexact.
Échéance critique : les environnements Composer 1 et Composer 2.0.x s’arrêtent définitivement le 15 septembre 2026.
La tarification Composer 3 repose sur les DCU, avec un plancher réel autour de 300 $/mois.
Le service convient aux équipes sans DevOps dédié sur un stack GCP consolidé ; l’auto-hébergement reste compétitif au-delà de ce périmètre.
Votre équipe data veut la puissance d’Apache Airflow pour enchaîner ses pipelines sans gérer un cluster. Cloud Composer répond à ce besoin depuis plusieurs années. Officiellement renommé « Managed Service for Apache Airflow » en 2025, le service affiche clairement son alignement avec l’écosystème open source : les deux noms désignent le même produit, rien ne change côté APIs ni facturation. Ce qui évolue, c’est la promesse de suivre les releases upstream d’Airflow de plus près, concrétisée par la disponibilité d’Airflow 3.1 en preview début 2026. La vraie question que se posent les décideurs que nous accompagnons porte sur le coût réel, la maturité des versions et les profils pour lesquels ce service vaut son prix.
Sommaire
Calculez votre budget Cloud Composer
Estimez votre coût mensuel Cloud Composer 3 selon le modèle tarifaire DCU (tarifs 2025-2026) et comparez-le au coût total de possession d’un Airflow auto-hébergé sur GCP. Ajustez chaque paramètre selon votre situation réelle.
Environnement Composer
Conseil : 2-3 en Small, 4-6 en Medium, 6-12 en Large
Charge de travail (DAGs)
Comparaison TCO – Airflow auto-hébergé
La maintenance comprend : mises à jour Airflow, surveillance des workers, gestion des incidents, scaling manuel, upgrades de dépendances. 8 à 15 h/mois est réaliste pour un environnement stable en production. N’incluez pas le temps de développement des DAGs, commun aux deux options.
Estimation indicative basée sur le modèle tarifaire DCU de Cloud Composer 3, tarifs 2025-2026, conversion USD/EUR approximative retenue à 0,92. Les coûts réels dépendent de votre région exacte, de vos committed use discounts, du volume de logs stockés et de votre charge effective. Vérifiez les données qui s’appliquent à votre situation sur le calculateur officiel Google Cloud avant toute décision budgétaire.
Cloud Composer : qu’est-ce que c’est exactement ?
Apache Airflow, la brique open source centrale
Apache Airflow structure ses workflows sous forme de DAGs (Directed Acyclic Graphs), des graphes qui définissent l’ordre d’exécution des tâches et leurs dépendances. Le scheduling est au cœur du système : chaque DAG définit quand une tâche se déclenche, ce qu’elle attend et ce qu’elle produit. Cloud Composer prend cette brique open source et en fait une solution clé en main sur Google Cloud : plus d’installation du scheduler, plus de mise à jour manuelle des workers, plus de supervision de la base de métadonnées.
Un ingénieur data écrit ses DAGs et les déploie directement. C’est cet allègement opérationnel qui fait la valeur centrale du produit.
Le renommage en Managed Service for Apache Airflow : ce qui change (et ce qui ne change pas)
Dans la documentation officielle Google Cloud, le produit s’appelle désormais « Managed Service for Apache Airflow », avec l’ancien nom entre parenthèses. Facturation, APIs, déploiements : rien ne change côté utilisateur. Ce qui évolue, c’est la promesse d’alignement avec les releases Apache Airflow, matérialisée par la disponibilité d’Airflow 3.1 en preview dès début 2026.
Comment Cloud Composer s’appuie sur Google Kubernetes Engine
Les composants Airflow gérés automatiquement par Google
Sous le capot, le service fait tourner les composants Airflow standards (workers, scheduler, DAG processor, triggerer, web server) dans un cluster Google Kubernetes Engine. GKE orchestre ces briques, les met à l’échelle et gère leur disponibilité. Google porte l’essentiel de cette charge : vous ne voyez pas les nœuds, vous ne les patchez pas, vous ne configurez pas manuellement la tolérance aux pannes.
Composer 3 est-il vraiment serverless ?
Composer 3, disponible en disponibilité générale depuis le printemps 2025, masque entièrement la couche GKE : l’interface n’expose plus les détails du cluster, les mises à jour réseau se font sans intervention, et le versionnement « evergreen » applique automatiquement les correctifs de sécurité. Mais les ressources de calcul sous-jacentes tournent en permanence, même lorsqu’aucun DAG ne s’exécute. Vous payez une infrastructure active, toujours allumée. La confusion vient du marketing, pas du produit. Pour des équipes qui comparent avec des outils d’automatisation événementiels, c’est une distinction budgétaire qui compte vraiment.
Composer 1, 2 ou 3 : ce qui change et l’échéance du 15 septembre 2026
Les trois générations coexistent encore dans les environnements de production. Voici leur situation :
| Version | Création possible | Statut |
|---|---|---|
| Composer 1 | Non (bloquée depuis sept. 2025) | Arrêt définitif le 15 sept. 2026 |
| Composer 2 (≤ 2.0.x) | Oui | Arrêt définitif le 15 sept. 2026 |
| Composer 2 (> 2.1.0) | Oui | Supporté, non concerné |
| Composer 3 | Oui | GA, recommandé |
La date du 15 septembre 2026 est ferme. Pas de prolongation annoncée à ce jour. Si vous opérez encore sur Composer 1 ou Composer 2.0.x, la migration doit figurer dans votre roadmap maintenant, pas dans trois mois.
Ce que Composer 3 apporte concrètement : réseau simplifié et evergreen
Composer 3 supprime le VPC peering obligatoire qui compliquait les déploiements réseau, applique les correctifs de sécurité automatiquement et masque la configuration GKE. Les équipes qui subissaient des plages de maintenance imprévisibles y gagnent en stabilité opérationnelle mesurable.
Support Airflow 3.1 en preview : DAG versioning natif et Human-in-the-Loop
Début 2026, la disponibilité d’Airflow 3.1 en preview a été annoncée dans le service managé (encore en preview au moment de la rédaction). Cette version apporte le DAG versioning natif (les conflits entre versions de DAGs disparaissent), des alertes proactives sur les délais de tâches, et le Human-in-the-Loop : un pipeline data automatisé peut désormais se suspendre pour attendre une validation humaine avant de reprendre.
Tarifs de Cloud Composer : du DCU au budget mensuel réel
Le DCU expliqué sans jargon
Composer 3 facture en DCU (Data Compute Unit), une unité abstraite qui regroupe vCPU, mémoire et stockage dans un seul indicateur. Fini les trois lignes de facture séparées de Composer 2.
Exemples de budgets selon le profil d’usage
En région us-central1, le DCU revient à 0,06 $ de l’heure. En pratique, les déploiements réels oscillent entre 300 $/mois en configuration minimale et jusqu’à 1 500 $/mois en production active avec plusieurs pipelines. Ces ordres de grandeur, documentés dans les forums développeurs Google Cloud, fixent un seuil d’entrée élevé : ce service ne convient pas à des besoins d’automatisation modestes.
Franchement, ce seuil dissuade beaucoup d’équipes qui auraient pu en bénéficier. Si votre volume de pipelines ne justifie pas ce budget, regardez d’abord vers des alternatives plus légères.
Ce que Composer 2 facturait différemment
| Composante | Composer 2 | Composer 3 |
|---|---|---|
| CPU | Facturé séparément (mCPU-heures) | Inclus dans le DCU |
| Mémoire | Facturée séparément (Gio-heures) | Inclus dans le DCU |
| Frais fixes d’environnement | Oui (« Small Environment Fee ») | Absorbé dans le DCU |
Le modèle DCU simplifie la lecture de la facture pour les équipes qui réconciliaient des lignes de coût distinctes chaque mois.
Cloud Composer vs Airflow auto-hébergé : les vrais arbitrages
Quand le managé justifie son prix
Pour une équipe data sans ingénieur infrastructure dédié, opérer un cluster Airflow en production coûte cher en temps : mises à jour, supervision, gestion des secrets, scalabilité manuelle. Le service managé transforme ce coût caché en ligne budgétaire prévisible. L’intégration native avec BigQuery, Dataflow, Cloud Storage et Vertex AI fluidifie le travail sur un stack GCP consolidé. Pour ce profil, l’orchestration de workflows via le service vaut son prix.
Les cas où l’auto-hébergement reste rationnel
L’Airflow auto-hébergé sur une VM ou un cluster Kubernetes reprend l’avantage dès que le budget est serré, l’environnement multi-cloud, ou que l’équipe dispose d’une compétence infrastructure existante. Pour des besoins encore plus simples (quelques automatisations sans dépendances complexes), des outils comme n8n ou Make couvrent le besoin sans la courbe d’apprentissage d’Airflow et sans ce tarif d’entrée.
Cas d’usage concrets pour Cloud Composer
Pipelines ETL et orchestration BigQuery / Dataflow
Le service excelle dans l’enchaînement de jobs ETL/ELT récurrents : extraction depuis des APIs ou des bases sources, transformation dans Dataflow ou dbt, chargement dans BigQuery. La gestion native des dépendances entre tâches et le retry automatique rendent ces pipelines robustes face aux défaillances transitoires.
C’est le cœur du produit, celui pour lequel il a été conçu.
Workflows ML et Human-in-the-Loop avec Airflow 3.1 (preview)
Les workflows ML (entraînement, évaluation, déploiement de modèle) incluent souvent des étapes humaines : validation avant mise en production, revue de métriques. La fonctionnalité HITL d’Airflow 3.1, disponible en preview dans le service managé, suspend le pipeline et attend un signal de validation avant de reprendre. Pour les équipes qui géraient ces étapes manuellement ou via des scripts de contournement, c’est un apport structurel.
Ce qu’il faut retenir
Le service managé Apache Airflow convient aux équipes qui veulent la puissance d’Airflow sans gérer l’infrastructure, sur un stack GCP consolidé. Anticipez un budget réel à partir de 300 $/mois. Planifiez la migration vers Composer 3 avant le 15 septembre 2026 si vous opérez encore sur Composer 1 ou 2.0.x. Et gardez en tête que « serverless » reste un raccourci : l’infrastructure tourne en continu, et la facture suit.
FAQ
Le produit a changé de nom en 2025 : qu’est-ce que ça signifie concrètement ?
« Managed Service for Apache Airflow » est le nom officiel depuis 2025 ; l’ancien nom reste l’appellation courante. Les deux désignent le même service. Facturation, APIs et déploiements sont identiques : il n’y a rien à migrer pour cette seule raison.
La migration vers Composer 3 est-elle obligatoire avant septembre 2026 ?
Uniquement si vous opérez sur Composer 1 ou Composer 2 version 2.0.x. Ces environnements s’arrêtent le 15 septembre 2026. Composer 2 (versions supérieures à 2.1.0) et Composer 3 ne sont pas concernés par cette échéance.
Airflow 3.1 est-il disponible dans le service managé ?
En preview depuis début 2026. Pas encore en disponibilité générale au moment de la rédaction : consultez la documentation officielle avant de planifier une migration vers Airflow 3.1 en production.
Ce service convient-il à des besoins d’automatisation simples ?
Non. Ce tarif d’entrée le réserve aux équipes avec des workflows complexes et un volume de pipelines qui justifie cet investissement. Pour des automatisations simples sans dépendances nombreuses, des alternatives plus légères s’imposent.
Composer 3 est-il véritablement serverless ?
Pas au sens strict. L’infrastructure GKE tourne en permanence, même sans DAG actif. Composer 3 supprime la gestion opérationnelle du cluster, pas les ressources de calcul elles-mêmes.
