Une équipe amont renomme une colonne sans prévenir et votre pipeline casse. Que faites-vous, et que changez-vous ensuite ?

À court terme, rétablissez le service : mappez le nouveau nom dans la couche de staging, relancez les partitions concernées et vérifiez que les chiffres en aval se réconcilient. À long terme, cessez de compter sur la bonne volonté. Mettez en place un contrat de données avec l'équipe source, validez le schéma à l'ingestion pour que les échecs soient attrapés à la frontière avec un message clair, et faites atterrir les payloads bruts sans typage, pour qu'un renommage ne détruise pas le chemin d'ingestion lui-même.

Dans l'immédiat, c'est un petit correctif : aliaser la nouvelle colonne dans le modèle de staging, relancer les partitions concernées, et réconcilier deux ou trois agrégats de confiance pour être sûr que rien n'a changé de sens en plus du nom. Je vérifie aussi dans le catalogue les autres consommateurs de cette table, parce que si cela nous a cassés, cela a probablement cassé quelqu'un d'autre qui ne l'a pas encore remarqué. Puis vient la partie systémique. Je préfère de loin que l'échec survienne à l'ingestion, avec un message disant colonne customer_id attendue, customer_identifier trouvée, plutôt que trois modèles plus loin avec une colonne nulle. La validation de schéma part donc à la frontière, et la couche brute stocke le payload tel quel, ce qui veut dire que l'ingestion continue de fonctionner et que seule la couche typée proteste. Et j'irais parler à l'équipe source, non pour me plaindre mais pour poser un contrat : voici les champs dont nous dépendons, voici l'alerting, merci de nous donner un préavis de livraison. Nous avons fait cela dans mon poste précédent, et cela a transformé un problème récurrent de 6h du matin en un message Slack une semaine à l'avance.