Un tMap qui duplique 2 millions de lignes : anatomie d'un sinistre Talend à 180 000 €

Le décor est banal. Un consultant Talend intervient en régie sur le SI décisionnel d'un acteur de l'énergie. Sa mission : enrichir un job d'alimentation du datamart de facturation, en ajoutant une jointure entre la table des contrats et une table de référence tarifaire fraîchement créée. Quelques composants, un tMap, deux tDBInput, un tDBOutput vers Snowflake. Une demi-journée de travail estimée.

Dans l'écran de configuration du tMap, la jointure se paramètre via le Lookup Model et la Match Model. Le consultant relie la clé contrat à la table tarifaire, teste sur un échantillon de 500 lignes, obtient un résultat cohérent, commite et déploie. Le job tourne la nuit suivante en production sans lever la moindre exception. Vert partout dans la Talend Management Console.

Le problème : la table de référence tarifaire contenait plusieurs versions tarifaires par contrat (historisation des avenants). Avec une jointure laissée en cardinalité « all matches » au lieu de « unique match », chaque contrat ressort autant de fois qu'il a de tarifs historisés. Sur l'échantillon de test, par chance, aucun contrat n'avait d'avenant. En production, sur 1,2 million de contrats, la cible a gonflé à plus de 3 millions de lignes. Un dommage qui ne déclenche aucune alarme : le job est un succès technique.

Un ETL ne « casse » pas toujours bruyamment. Ici, rien ne plante. Les volumes en cible augmentent, mais aucun seuil de monitoring n'était posé sur le nombre de lignes attendues. Le datamart alimente ensuite un moteur de refacturation interne qui agrège les montants par contrat. Comme les lignes dupliquées portent des montants réels, les totaux explosent sans paraître absurdes ligne à ligne.

La détection survient neuf jours plus tard, quand le contrôle de gestion s'étonne d'un chiffre d'affaires prévisionnel en hausse de 38 % sur le segment concerné. Entre-temps, deux campagnes de relance ont été préparées sur des montants faux, et un reporting trimestriel a déjà circulé en interne. La remise en état suppose de :

• identifier et purger les lignes fantômes sans toucher aux lignes légitimes ;
• rejouer l'historique du datamart sur la fenêtre impactée ;
• recalculer les agrégats de facturation et invalider les relances erronées ;
• produire une note de réconciliation pour la direction financière.

Aucune donnée n'a été « perdue ». Et pourtant le préjudice est lourd. C'est la signature d'un sinistre immatériel : ce qui coûte cher, ce n'est pas la donnée disparue, c'est le travail humain et le temps d'exploitation gâchés par une donnée fausse mais crédible.

Reconstitution du coût, tel qu'il a été chiffré par l'expert mandaté :

Total : 180 000 €. Pour un freelance facturant 600 € la journée, c'est l'équivalent de 300 jours de mission. Sans assurance, le sinistre efface plusieurs années de marge.

La gravité d'un sinistre Talend ne se mesure pas en lignes de code, mais en jours de production faussée chez le client. Un bug d'une heure peut coûter des semaines de remise en état.

Le consultant n'a rien fait de malhonnête. Il a testé, déployé proprement, sans alerte. Pourtant, sur le plan juridique, la faute professionnelle est caractérisée : un développeur Talend expérimenté est réputé connaître l'impact d'une cardinalité de jointure et tester sur un jeu de données représentatif, incluant les contrats à avenants.

En régie comme au forfait, le consultant est tenu d'une obligation de moyens renforcée. Le client n'a pas à prouver une intention de nuire : il lui suffit d'établir un manquement aux règles de l'art (ici, l'absence de test sur les cas d'historisation et l'absence de contrôle de volumétrie) et un lien avec le préjudice. C'est précisément le périmètre de l'assurance RC Pro, qui prend en charge les conséquences pécuniaires des erreurs, omissions et négligences commises dans la mission.

Point décisif : la RC Pro couvre les dommages immatériels non consécutifs, c'est-à-dire ceux qui ne découlent pas d'un dommage matériel ou corporel. Dans un sinistre ETL, c'est presque toujours ce poste qui pèse le plus lourd. Une garantie qui exclut ou sous-plafonne les dommages immatériels purs est, pour un consultant data, une fausse protection.

Au-delà de l'assurance, ce sinistre rappelle trois pratiques de robustesse propres au métier :

1. Tester sur un jeu de données représentatif, incluant volontairement les cas tordus (contrats multi-tarifs, doublons clés, valeurs nulles), et jamais sur un simple échantillon « propre ».
2. Poser un contrôle de volumétrie en sortie de job : comparer le nombre de lignes attendu au nombre produit, via un tAssert ou un tLogRow de contrôle, et faire échouer le job en cas d'écart anormal.
3. Documenter la cardinalité de chaque jointure dans le job : un commentaire « unique match attendu » dans le tMap sauve les relectures futures.

Ces réflexes réduisent la fréquence des sinistres. Ils n'éliminent pas le risque résiduel : l'erreur humaine est inhérente au développement. C'est ce risque que la RC Pro transforme en cotisation maîtrisée plutôt qu'en dette personnelle. Pour comprendre l'ensemble du périmètre couvert, consultez notre page assurance consultant Talend.