L’orchestration basée sur cron échoue silencieusement. Les pipelines se terminent avec succès tout en livrant des données périmées ; la surveillance indique tout est vert tandis que les parties prenantes voient des chiffres incorrects. Au moment où les échecs deviennent visibles, la migration est urgente. Les cinq signaux ci-dessous marquent les étapes où les configurations basées sur cron ont structurellement dépassé l’approche.
Les cinq signaux
1. Plus de trois pipelines interconnectés
Les cron jobs sont indépendants. Ils s’exécutent à leur heure planifiée, un point c’est tout. Dès que vous avez “le pipeline B doit attendre que le pipeline A soit terminé, et le pipeline C a besoin des deux”, vous avez dépassé ce qu’une planification séquentielle peut exprimer.
La progression typique : vous commencez par un seul dbt build à 7h. Puis vous ajoutez un deuxième cron job pour une source de données différente. Puis un troisième. Finalement, vous définissez l’heure de démarrage du deuxième job à “90 minutes après le démarrage du premier, pour lui laisser le temps de se terminer.” Cette estimation se brise chaque fois que le premier job prend plus de temps, et il n’y a aucun mécanisme pour détecter ou gérer l’échec.
Ce n’est pas un inconvénient mineur. Les conséquences en aval sont réelles : les tableaux de bord montrent silencieusement les chiffres d’hier, les agrégations sont calculées sur des données incomplètes, les pipelines semblent réussir parce qu’aucune étape individuelle n’a échoué — l’ensemble du système s’est juste exécuté dans le mauvais ordre.
Ce dont vous avez besoin à ce stade n’est pas un plus grand cron job. Vous avez besoin d’un graphe de dépendances. Même Cloud Workflows — qui coûte des fractions de centime par exécution — vous donne la primitive “exécuter B seulement après que A réussisse” que cron ne peut fondamentalement pas exprimer.
2. Les échecs silencieux deviennent fréquents
Votre dbt build a réussi. Tous les tests ont été validés. Mais les données qu’il a traitées dataient d’hier, parce que la synchronisation en amont n’était pas terminée quand dbt a tourné.
Rien dans vos logs ne montre un problème. Les tests ont réussi parce que les données étaient cohérentes en interne — juste périmées. Les parties prenantes voient un tableau de bord avec des horodatages de dernière mise à jour datant d’hier, et elles ne savent pas si c’est un problème de données ou un problème d’affichage. Le temps que quelqu’un comprenne ce qui s’est passé, la crédibilité de l’équipe data a pris un petit coup, mais réel.
Les échecs silencieux sont le mode d’échec le plus insidieux dans l’orchestration basée sur cron. Un échec qui consigne une erreur peut être corrigé. Un échec qui rapporte un succès tout en livrant des résultats incorrects érode la confiance progressivement jusqu’à ce que quelque chose d’embarrassant se produise lors d’une réunion de conseil d’administration ou d’une présentation exécutive.
Le problème sous-jacent est que la planification cron n’a aucun concept de fraîcheur des sources. Vous ne pouvez pas dire à cron d’exécuter “dbt, mais seulement après que la synchronisation Fivetran est terminée et que la vérification de fraîcheur a réussi”. La surveillance de la fraîcheur des sources — une fonctionnalité de dbt Cloud, Dagster et Airflow — vous donne la primitive pour détecter cela. Vous définissez un SLA de fraîcheur attendu pour chaque source, et l’orchestrateur le vérifie avant de déclencher la transformation en aval. Un cron job n’a pas de mécanisme équivalent.
3. Dépendances cross-système
dbt doit attendre qu’un outil d’ingestion de données (Fivetran, Airbyte, un pipeline dlt) termine le chargement. Ou un modèle Python doit s’exécuter après la fin de dbt. Ou un rafraîchissement de tableau de bord BI ne doit se déclencher que lorsque de nouvelles données arrivent.
Ce sont des exigences de coordination, pas de planification. Les cron jobs ne communiquent pas. Vous pouvez approximer la coordination en définissant des timings soigneusement (exécuter l’ingestion à 5h, dbt à 6h), mais c’est intrinsèquement fragile. Quand l’ingestion prend plus de temps que prévu — parce que l’API source était lente, parce que le dataset a grossi, parce que quelqu’un a lancé un rechargement manuel — vos estimations de timing se brisent silencieusement.
Les dépendances cross-système sont le signal le plus clair que vous avez besoin d’un vrai orchestrateur ou au minimum de Cloud Workflows comme couche de coordination. La valeur d’un orchestrateur n’est pas d’exécuter du code — n’importe quel cron job peut faire ça. C’est de savoir si les systèmes en amont ont réussi avant de déclencher ceux en aval.
Un test pratique : si votre timing de pipeline inclut du “buffer time” (ajouter 30 minutes supplémentaires pour laisser le temps au job en amont de se terminer), vous avez un problème de dépendance cross-système que cron est mal équipé pour gérer.
4. Croissance de l’équipe au-delà de trois contributeurs
Les praticiens solo et les équipes de deux personnes peuvent gérer une configuration cron job dans leur tête. Tout le monde sait ce qui tourne quand, qui possède quoi, et où regarder quand quelque chose se casse.
Au-delà de trois contributeurs, le modèle informel s’effondre. Les gens planifient des cron jobs à différents endroits — Cloud Scheduler, GitHub Actions, crontabs de serveur, peut-être une cloud function que quelqu’un a configurée et n’a jamais documentée. Comprendre ce que fait réellement votre pipeline de données nécessite des connaissances tribales. L’onboarding d’un nouveau membre de l’équipe nécessite une orientation de la personne qui a construit la configuration originale.
Le problème n’est pas technique — c’est organisationnel. L’orchestration basée sur cron ne fournit pas une vue unifiée de “qu’est-ce qui tourne, quand, et de quoi cela dépend ?” Un orchestrateur géré (même quelque chose de léger comme Dagster+ Solo à 10 $/mois) vous donne une interface où chaque membre de l’équipe peut voir le pipeline complet, vérifier le statut des exécutions récentes, et comprendre les dépendances sans consulter la personne qui l’a configuré.
Ce n’est pas une question de complexité du workflow. Un simple build dbt quotidien géré via Dagster reste simple. La valeur est la visibilité : tout le monde peut voir qu’il a tourné à 7h, qu’il a pris 12 minutes, que tous les tests ont réussi, et que l’ingestion en amont s’est terminée à temps.
5. Engagements de SLA des parties prenantes
Quand quelqu’un dit “le rapport du conseil doit utiliser des données des 6 dernières heures”, vous êtes passé de “exécuter dbt selon un calendrier” à “s’assurer que dbt s’exécute avec succès et que les données sont fraîches dans une fenêtre définie”.
Les cron jobs s’exécutent. Ils ne vérifient pas. Un build dbt déclenché par cron qui tourne à 6h peut échouer silencieusement, tourner avec des données source périmées, ou prendre 4 heures lors d’une mauvaise journée et se terminer après la réunion du conseil à 9h. Aucun de ces scénarios n’apparaît dans le statut succès/échec d’un cron job.
La surveillance de la fraîcheur est la capacité dont vous avez besoin à ce stade. Cloud Run Jobs couvre l’exécution, mais la surveillance de la fraîcheur vit au niveau de la couche d’orchestrateur : les politiques de fraîcheur de Dagster, les vérifications de fraîcheur des sources de dbt Cloud, la gestion des intervalles de données et des SLA d’Airflow. Ces systèmes peuvent vous notifier quand les données risquent de dépasser un SLA, avant la violation, pour que vous ayez le temps d’agir.
Les engagements de SLA changent également qui se soucie des échecs de pipeline. Quand un rafraîchissement quotidien est simplement “agréable à avoir”, un échec est un inconvénient mineur géré par l’équipe data. Quand une partie prenante s’est engagée à présenter des données à une heure spécifique, les échecs de pipeline deviennent des échecs organisationnels visibles. À ce stade, vous avez besoin d’une surveillance et d’alertes qui vont au-delà de “vérifier les logs cron”.
La progression typique
La plupart des équipes passent par un arc prévisible :
- Étape 1 : Un seul cron job exécutant
dbt build. Fonctionne bien. Le coût est négligeable. - Étape 2 : Deuxième script ajouté, peut-être quelques alertes Slack pour les échecs. Encore gérable.
- Étape 3 : Les dépendances inter-pipelines augmentent. Les estimations de timing remplacent la vraie coordination. Les échecs silencieux commencent à apparaître occasionnellement.
- Étape 4 : L’équipe grossit. La propriété devient floue. Quelqu’un commence à demander “qu’est-ce qui tourne, quand et qui en est responsable ?”
- Étape 5 : Les engagements de SLA arrivent. Un échec devient visible. La migration se fait sous pression.
Reconnaître l’étape 3, planifier la migration à l’étape 4.
Ce qu’implique réellement la migration
La bonne nouvelle : migrer de cron vers un vrai orchestrateur ne nécessite pas de réécrire votre projet dbt. Si vous avez conteneurisé votre exécution dbt pour Cloud Run (l’approche recommandée), le conteneur est portable. Passer à Dagster, Airflow ou Prefect signifie changer comment et quand le conteneur est invoqué, pas ce qu’il fait.
Pour la plupart des petits et moyens projets dbt, Dagster+ Solo à 10 $/mois est le premier pas naturel vers le haut. Il vous donne une planification orientée assets, un DAG visuel, la surveillance de la fraîcheur et une vraie gestion des dépendances sans la surcharge opérationnelle d’Airflow auto-hébergé ou l’engagement à 300+ $/mois de Cloud Composer.
Le framework de décision d’orchestration dbt pour GCP couvre le spectre complet des options et quand chacune est pertinente.