Les anciennes bases de données à fichiers plats encodent leur schéma en largeurs de caractères fixes : le prénom occupe par exemple 8 caractères, le numéro de rue 4, et ainsi de suite. Ajouter un champ plus tard est douloureux — pas d'ALTER TABLE, chaque enregistrement doit être réécrit et chaque programme touchant au fichier mis à jour. Sur un gros système legacy, « ajouter un champ » peut représenter des semaines de travail risqué.

L'astuce classique de survie, c'est le padding : des caractères blancs supplémentaires à la fin d'un enregistrement, ou répartis en blocs à l'intérieur. Besoin d'une initiale de deuxième prénom ? On rogne un caractère sur le padding. La longueur de l'enregistrement reste identique, rien n'a à être déplacé, et les modules indifférents au nouveau champ ne voient qu'un caractère dans un espace qu'ils ignoraient déjà.

L'équipe de Brenda exploite un mainframe IBM avec des fichiers plats VSAM et pratique cet exercice depuis des décennies. Pour alimenter un reporting moderne, l'entreprise a engagé des prestataires pour construire un pipeline ETL vers une base relationnelle, en leur fournissant le copybook décrivant la structure des enregistrements. En chemin, les développeurs ETL ont découpé plusieurs blocs de padding à de mauvais offsets — des champs de la forme SOME_USEFUL_FIELD PADDING PADDING PADDING SOME_OTHER_FIELD sont devenus des colonnes absorbant chacune une partie du padding.

Au début, tout semblait correct : les caractères de padding étaient stockés en base mais supprimés à l'affichage, et la concaténation des colonnes reproduisait toujours l'enregistrement d'origine. L'erreur fatale : les tests n'avaient été menés que contre le mainframe de production. Contre le mainframe de développement, on aurait vu les fonctionnalités en cours qui consommaient déjà une partie de ce padding.

Le pipeline a passé la recette, est entré en production et a tourné quelques semaines — jusqu'à ce que l'équipe mainframe livre ses nouvelles fonctionnalités, qui ont commencé à écrire de vraies données dans le padding mal découpé. Les rapports se sont remplis de données parasites. Les prestataires, leur mission terminée, ont répondu « works as designed ». Ce sont donc les développeurs mainframe qui ont dû trouver d'autres champs de padding — qui ne corrompraient pas les rapports que la direction aimait consulter.