Blog

Publier un package sur PyPI. C’est un de ces trucs qui a l’air intimidant de l’extérieur, mais qui, finalement, s’avère être une question de bon timing et d’un problème assez précis à résoudre.

Tu connais cette sensation : un rapport qui sort des chiffres bizarres, un analyste qui te dit “les totaux matchent pas”, et tu passes ta journée à remonter la chaîne pour trouver où les données ont dérapé. Souvent, le problème aurait pu être détecté automatiquement si quelqu’un avait mis un test quelque part.

Documenter les colonnes d’une base source, c’est le genre de tâche que personne ne veut faire. T’as un système opérationnel avec des centaines de tables, des milliers de colonnes, et une documentation qui va de “inexistante” à “un commentaire de 2017 qui dit TODO: document this.”

La documentation, c’est le truc que personne ne veut faire. Surtout en data. T’as des centaines de colonnes dans des dizaines de tables, et quelqu’un te demande “c’est quoi le champ status dans la table orders ?” Et la réponse honnête, c’est souvent “euh… un enum je pense qui veut probablement dire X.”

Snowflake est fondamentalement SQL-first. C’est sa force : tout se pilote en SQL, des grants à la création d’objets en passant par les transformations. L’infrastructure, on a vu comment la dompter avec Terraform dans l’article précédent. Mais les transformations de données, elles, tombent dans un angle mort. Des scripts SQL éparpillés, pas de tests, pas de versioning sérieux, un seul collègue qui sait dans quel ordre tout lancer.

Il y a un moment, dans la vie d’un data engineer, où tu te retrouves avec un fichier SQL de 300 lignes qui crée des rôles, des grants, des warehouses, et tu te demandes comment t’en es arrivé là. C’est mon histoire.

Fait que j’ai construit cette app de Planning Poker. Tu sais, le truc agile d’estimation où l’équipe se rassemble pour voter sur les story points ? Ouais, j’ai décidé de la faire web et temps réel pokerplanning.net. Et puis… disons juste que je suis devenu un peu ambitieux avec le déploiement.