Gaël PENESSOT

Gaël PENESSOTOct 22, 2026

Tu maîtrises Python et SQL. Mais ton Git se limite à git add, git commit et git push. Git apparaît dans la majorité des offres data. Pas comme un nice to have. Comme un prérequis. Et la réalité, c'est que la plupart des profils data utilisent Git sans le comprendre. Commit, push, prier pour que ça marche. Les fondamentaux tiennent en quelques heures de pratique. Branches, merges, pull requests. Pas besoin de 6 mois. Par contre, pas de raccourci : il faut pratiquer. 3 ressources gratuites pour commencer : - GitHub Skills : cours interactifs intégrés à GitHub avec feedback en temps réel https://skills.github.com/ - Pro Git : le livre de référence, gratuit, disponible en français https://lnkd.in/ewmVa7X4 - Learn Git Branching : exercices interactifs pour comprendre branches et merges https://lnkd.in/epHCYiSw Si ce post t'a été utile, enregistre-le pour y revenir :)

Gaël PENESSOTOct 21, 2026

DuckDB a passé 7 ans à être une base embarquée. Aujourd'hui, il devient officiellement un serveur. La v2.0 sort ce mercredi. Plus de 10 000 commits depuis la v1.5, sortie en mars. Dans le lot, une nouveauté règle une limite que beaucoup finissent par croiser en prod. Un fichier .duckdb, un seul process qui écrit. Ton pipeline met à jour la base pendant que ton app Streamlit la lit. Erreur de verrou sur le fichier. Jusqu'ici, la réponse classique, c'était de migrer vers PostgreSQL. Ou de bricoler des copies du fichier. En bêta depuis mai, l'extension Quack passe en version stable avec la v2.0. Une session DuckDB sert ses bases sur le réseau. Les autres DuckDB s'y attachent et envoient leurs requêtes. Trois instructions suffisent : - quack_serve() démarre le serveur - ATTACH 'quack:...' branche la base distante - CONNECT envoie tes requêtes là-bas Les requêtes tournent côté serveur. Les résultats reviennent en streaming. CONNECT ne se limite pas à DuckDB. Pointé sur PostgreSQL ou MySQL, il envoie ton SQL à la base au lieu de rapatrier les tables. Ce que ça change pour toi : - ton pipeline et ton app passent par le même serveur, sans conflit de verrou - un collègue interroge tes tables sans que tu lui envoies le fichier - tu requêtes la base de prod sans télécharger les tables en local Deux réserves avant de tout migrer. Par défaut, le serveur n'écoute qu'en local. Pour l'ouvrir au réseau, il faut un reverse proxy avec TLS devant. La v2.0 change aussi le format de stockage par défaut. Teste sur une branche et épingle ta version avant de mettre à jour en prod. Enregistre ce post si ça t'a plu ;)

Gaël PENESSOTOct 20, 2026

Ce qu'on ne t'a pas dit sur le métier de data analyst. La vérité sur Jean-Michel et son Excel. 1. "Tu vas analyser des données toute la journée" En vrai, tu vas : - Chercher où sont les données - Demander les accès - Attendre les accès - Découvrir que les données n'existent pas L'analyse, c'est les 20% qui restent. 2. "SQL et Python, c'est suffisant" Oui. Mais personne ne t'a dit qu'il faudrait aussi : - Git (parce que ton collègue a écrasé ton script) - Excel (oui, encore Excel en 2026) - La capacité d'expliquer un LEFT JOIN à quelqu'un qui ne veut vraiment pas comprendre 3. "Les données sont dans la base" Elles sont : - Dans 4 bases différentes avec des conventions de nommage incompatibles - Dans un Excel sur le bureau de Jean-Michel - Dans un PDF scanné en 2009 - Dans la tête du commercial qui est en vacances jusqu'au 15 4. "Tu travailleras avec des gens data-driven" Tu travailleras avec des gens qui veulent des insights. Pas de mauvaises nouvelles. Pas de nuances. Et surtout, pas que leurs intuitions soient contredites. 5. "C'est un métier d'avenir" C'est vrai. Ton avenir ressemblera à ça : - Expliquer pourquoi la somme des pourcentages dépasse 100% - Refaire le même graphique avec d'autres couleurs six fois - Etre le seul à savoir pourquoi le dashboard est cassé Le jour où tu maîtrises ce chaos mieux que les autres, tu deviens la personne dont tout le monde a besoin. C'est ça, le vrai avenir du métier. Dis-moi ce qui t'a le plus surpris en poste.