J’ai construit un Pipeline Builder pour Palantir Foundry — Voici pourquoi la France manque d’experts Foundry

Salut. Je m’appelle Michaël Lozano. Pendant six ans, j’ai travaillé sur Palantir Foundry chez Airbus, via Capgemini. J’ai livré plus de 80 produits data. 98% de disponibilité. 4.8/5 de satisfaction client. Des chiffres qui claquent, mais derrière, il y a des nuits blanches, des pipelines qui cassent à 3h du mat’, et des réunions interminables pour expliquer pourquoi le modèle ne marche pas si les données d’entrée sont pourries.

Aujourd’hui, je suis freelance. Et j’ai construit un outil open-source : DataFlow Canvas. C’est un visual pipeline builder pour Foundry. Drag-and-drop, génération automatique de code PySpark avec les fameux `@transform_df`, gestion de la lineage, collaboration en temps réel via Firebase. Bref, l’outil que j’aurais rêvé avoir quand je débutais sur Skywise.

Mais avant de vous parler de DataFlow Canvas, il faut qu’on parle d’un problème plus large. Un problème structurel. Pourquoi la France manque cruellement d’experts Palantir Foundry. Et pourquoi, si vous cherchez quelqu’un qui sait vraiment ce qu’il fait, vous tombez souvent sur des profils… approximatifs.

Foundry, c’est pas du Python qu’on apprend à la fac

Palantir Foundry, c’est une plateforme. Une grosse plateforme. Pas juste un Jupyter Notebook avec un joli logo. C’est un écosystème complet : Ontology, Code Workbooks, Foundry ML, Pipeline Builder, Contour, Workshop, Slate… La liste est longue. Et chaque module a ses propres subtilités, ses pièges, ses bonnes pratiques qui ne sont écrites nulle part.

On n’apprend pas Foundry à l’école. Il n’y a pas de cours « Introduction à Foundry » à Télécom Paris ou à l’INSA. Il n’y a pas de certification officielle reconnue par l’industrie (les certifications Palantir existent, mais elles sont internes, réservées aux employés Palantir et à leurs partenaires directs). Résultat ? On apprend Foundry sur le tas. En cassant des choses. En lisant la documentation en diagonale à 2h du matin parce que le pipeline de prod est tombé. En demandant à un collègue qui, lui aussi, apprend sur le tas.

C’est un cycle vicieux. Les entreprises veulent des experts Foundry. Mais personne ne forme les experts Foundry. Donc les seuls « experts » disponibles sont ceux qui ont eu la chance (ou la malchance) de tomber sur un projet Foundry dans leur carrière. Et même parmi eux, beaucoup ont une connaissance superficielle. Ils savent cliquer dans l’interface. Ils savent écrire un `@transform_df` basique. Mais dès qu’il faut optimiser un pipeline qui traite 10 To de données, ou déboguer un problème de lineage cassé, ou architecturer une Ontology qui tient la route à l’échelle… là, il n’y a plus personne.

Mon expérience chez Airbus : Skywise et la maturité data de l’A350

Chez Airbus, j’ai travaillé sur Skywise, la plateforme data collaborative d’Airbus. Mon rôle ? Construire des produits data pour la maintenance des avions. Concrètement : prendre des téraoctets de données de capteurs, de logs de maintenance, de plans de vol, et les transformer en insights actionnables pour les compagnies aériennes.

Un exemple concret. Sur le programme A350, on a travaillé sur la maturité data des avions. Chaque avion génère des milliers de paramètres en vol. La question n’était pas « est-ce qu’on a les données ? » (on les avait). La question était : « est-ce que ces données sont fiables, complètes, et exploitables pour faire de la maintenance prédictive ? »

On a construit des pipelines Foundry pour évaluer la qualité des données de chaque avion. Un pipeline qui, pour chaque vol, vérifiait : est-ce que tous les capteurs essentiels ont envoyé des données ? Y a-t-il des valeurs aberrantes ? Des trous temporels ? Et on alimentait un dashboard qui donnait un score de maturité data par avion.

Ce genre de projet, c’est typiquement là où Foundry brille. Mais c’est aussi là où Foundry punit les architectes négligents. Un pipeline mal conçu, avec des joins mal optimisés ou des transformations inutiles, et vous vous retrouvez avec un job qui tourne pendant 12 heures au lieu de 30 minutes. Sur un environnement partagé, ça bloque tout le monde. Et croyez-moi, quand vous bloquez 50 data engineers chez Airbus, vous recevez des appels pas très sympas.

J’ai vu passer des dizaines de consultants sur ces projets. Beaucoup partaient au bout de 6 mois en disant « je connais Foundry ». Mais est-ce qu’ils comprenaient vraiment l’Ontology ? Est-ce qu’ils savaient pourquoi `@transform_df` était préférable à un code workbook brut pour la gouvernance ? Est-ce qu’ils maîtrisaient les mécanismes de caching de Foundry pour éviter de recalculer les mêmes datasets 10 fois ? Pour la plupart, non. Ils avaient appris à survivre. Pas à maîtriser.

Pourquoi c’est si dur de devenir un vrai expert Foundry

Foundry, c’est comme un iceberg. La partie visible, c’est l’interface web. C’est joli, c’est intuitif, on clique, ça marche (souvent). La partie immergée, c’est tout ce qui se passe en dessous :

– L’Ontology, qui est le cœur métier de Foundry. Si vous modélisez mal votre Ontology, tout ce que vous construisez dessus sera bancal. C’est comme construire une maison sur du sable. – Le système de builds, avec ses caches, ses invalidations, ses dépendances. Comprendre pourquoi un rebuild ne se déclenche pas, ou pourquoi il rebuild tout alors qu’il ne devrait rebuild qu’un seul dataset, c’est un art. – La sécurité et la gouvernance. Foundry a un modèle de permissions complexe. Comprendre les différences entre les permissions au niveau du dataset, de l’Ontology object, et du code workbook, c’est essentiel pour ne pas accidentally donner accès à des données sensibles à toute l’organisation. – L’optimisation des performances. Foundry tourne sur Spark en backend. Si vous ne comprenez pas comment Spark fonctionne (shuffles, partitions, skew), vos pipelines seront lents. Point final.

Tout ça, ce n’est pas documenté de manière centralisée. Il faut accumuler de l’expérience. Et l’expérience, ça prend du temps. Des années.

DataFlow Canvas : l’outil que j’aurais voulu avoir

C’est pour ça que j’ai construit DataFlow Canvas.

DataFlow Canvas, c’est un visual pipeline builder open-source pour Foundry. L’idée est simple : au lieu de devoir écrire tout le code PySpark à la main, vous dessinez votre pipeline sur un canvas. Vous drag-and-drop des datasets, des transformations, des sorties. Et l’outil génère automatiquement le code Foundry correspondant, avec les bons decorators `@transform_df`, la bonne gestion des inputs et outputs, et même la documentation de base.

Mais DataFlow Canvas, c’est pas juste un générateur de code. C’est aussi :

– Un moteur d’architecture IA. Vous décrivez un besoin métier en langage naturel (« je veux joindre les données de vol avec les données de maintenance et calculer le temps moyen entre deux pannes »), et l’IA vous propose un squelette de pipeline. Vous validez, vous ajustez, et hop, le code est généré. – De la collaboration en temps réel. Via Firebase, plusieurs personnes peuvent travailler sur le même canvas en même temps. Plus besoin de s’envoyer des fichiers JSON par email ou de se battre sur un Git repo. – De la gestion de lineage et de versioning. Chaque modification est trackée. Vous pouvez voir l’historique de votre pipeline, revenir en arrière, comparer les versions. – Un catalog de transformations pré-built. Joins, filtres, agrégations, window functions… Les transformations les plus courantes sont disponibles en un clic. Plus besoin de retaper les mêmes bouts de code encore et encore.

DataFlow Canvas, c’est mon cadeau à la communauté Foundry française (et mondiale). C’est open-source, c’est gratuit, et j’espère que ça aidera les équipes à accélérer leur adoption de Foundry tout en évitant les pièges classiques.

La France a besoin d’experts Foundry. Vrais.

Si vous lisez cet article, c’est peut-être que vous cherchez un expert Foundry. Ou que vous voulez devenir un expert Foundry. Dans les deux cas, voici mon conseil :

Ne vous contentez pas de l’interface web. Creusez. Comprenez ce qui se passe en dessous. Lisez la documentation (oui, elle est longue). Expérimentez. Cassez des choses en environnement de dev. Demandez à des gens qui ont de l’expérience. Et si vous ne trouvez personne… contactez-moi.

Je suis freelance. Je suis spécialisé sur Palantir Foundry. J’ai 6 ans d’expérience, 80+ produits livrés, et une obsession pour la qualité des architectures data. Je parle français, anglais, espagnol, et italien. Je suis certifié SAFe 5 Agilist et PSPO I. Et surtout, je suis passionné par Foundry au point d’avoir construit un outil open-source pour faciliter son utilisation.

Si vous avez un projet Foundry, si vous voulez auditer votre architecture, si vous avez besoin de former vos équipes, ou si vous voulez juste discuter de la meilleure façon de modéliser votre Ontology… parlons-en.

📩 Contactez-moi via studioinitiative.com

🔗 Retrouvez-moi sur LinkedIn

🛠️ Et allez voir DataFlow Canvas sur GitHub — c’est gratuit, c’est open-source, et ça pourrait bien vous faire gagner des semaines de travail.

—

Michaël Lozano est Senior Product & Delivery Lead Data, expert Palantir Foundry avec 6+ années d’expérience chez Airbus (Capgemini). Il accompagne maintenant les entreprises dans leur transformation data via Studio Initiative.