Le fonctionnement asynchrone d'une chaîne ETL : optimisation et flexibilité

Une chaîne ETL classique fonctionne en trois temps qui s’attendent les uns les autres : on extrait tout, on transforme tout, puis on charge tout. Tant que l’extraction n’est pas terminée, la transformation ne démarre pas. Tant qu’un seul enregistrement coince, le lot entier patiente. C’est simple à dessiner sur un tableau blanc, et c’est exactement ce qui fait dérailler une reprise à volume réel.

Dans une chaîne synchrone, le débit du tout est celui de l’étape la plus lente. Un enregistrement bloqué ne ralentit pas seulement lui-même : il immobilise tous ceux qui le suivent.

Le lot, c’est le problème — pas la solution

Traiter par lots donne une fausse impression de contrôle. On lance le batch du soir, on attend le rapport du matin. Sauf qu’un batch est un objet tout-ou-rien : il réussit en entier ou il échoue, et quand il échoue à 80 %, on ne sait souvent pas dire où. On rejoue tout. On repaie le coût d’extraction et de transformation des 80 % qui étaient déjà bons, pour atteindre les 20 % restants.

Plus le volume monte, plus cette logique se retourne contre vous. Un million d’enregistrements derrière un seul cas limite mal géré, et la fenêtre de bascule y passe.

L’asynchrone découple les étapes

Le passage à l’asynchrone consiste à couper les liens rigides entre extraction, transformation et chargement. Chaque étape devient un poste indépendant, relié aux autres par une file d’attente :

1. l’extraction dépose les enregistrements dans une file, à son propre rythme ;
2. la transformation consomme cette file dès qu’un enregistrement est disponible, sans attendre que l’extraction soit finie ;
3. le chargement prend le relais de la même façon, en aval.

Aucune étape n’attend que la précédente ait terminé l’ensemble du travail. Elles travaillent en parallèle sur des enregistrements différents. Pendant que le dernier extrait arrive, les premiers sont déjà chargés.

L’optimisation vient du parallélisme et de l’isolement

Découplé, chaque poste se dimensionne pour ce qu’il fait. La transformation est coûteuse en CPU ? On multiplie ses consommateurs sans toucher à l’extraction. Le système cible accepte un nombre limité de connexions ? On plafonne le seul étage de chargement, sans brider le reste de la chaîne.

Surtout, un enregistrement qui échoue ne bloque plus la file. Il part dans une file d’erreurs dédiée — diagnostiqué, corrigé, rejoué individuellement — pendant que les autres continuent d’avancer. Le débit n’est plus dicté par le pire cas, mais par le rythme normal du flux. C’est le même principe que la qualification record par record : ce qui passe avance, ce qui échoue est traité à part.

La flexibilité vient de la même rupture

Le découplage paie une seconde fois quand le projet change — et il change toujours. Ajouter une règle de transformation, insérer une étape d’enrichissement, brancher une seconde cible : dans une chaîne asynchrone, c’est un consommateur de plus sur une file existante. On ne reconstruit pas le pipeline, on greffe un poste.

Le rejeu en bénéficie tout autant. Une règle corrigée à mi-parcours ne force pas à relancer toute la reprise : on ne réinjecte que les enregistrements concernés, depuis leur file. La chaîne absorbe la correction au lieu de repartir de zéro.

Ce que ça change pour une migration

Une migration n’est pas un transfert ponctuel qu’on réussit ou qu’on rate d’un bloc. C’est un flux d’enregistrements, chacun avec son propre verdict. Une chaîne synchrone force ce flux à se comporter comme un lot monolithique, avec toute la fragilité que cela implique.

L’asynchrone redonne au flux sa vraie nature : des unités indépendantes qui avancent, échouent et se corrigent sans se bloquer mutuellement. C’est ce socle qui rend possibles les boucles Run / Fix de notre méthodologie. L’optimisation et la flexibilité ne sont pas deux options qu’on ajoute ensuite — ce sont les conséquences directes d’avoir cessé de tout faire attendre tout le monde.