Vinoo Ganesh (Kepler) fait du FDE une stratégie produit, histoires de terrain à l'appui

• Vidéo : How Forward Deployed Engineering is done at Kepler, chaîne AI Engineer
• Qui parle : Vinoo Ganesh, cofondateur et CEO de Kepler, sept ans chez Palantir
• Format : 22 min 20, AI Engineer World's Fair 2026, mise en ligne le 28 juillet 2026 (5 850 vues au 10 novembre 2026)
• Originalité : 4/5
• Qualité de l'information : 5/5

Phoenix exigeait 2,3 millions de keyspaces Cassandra et 14 To de RAM pour démarrer un serveur. Vinoo Ganesh se souvient ainsi de ce système de stockage que Palantir a conçu vers 2013 sans parler à ses clients (vers 3:02). Les données d'un grand client financier contenaient des dates vides, que le système convertissait au 1^er janvier 1970 ; il a alors créé une tranche de dix minutes pour chaque intervalle entre 1970 et 2013. Le produit est mort à l'arrivée. Cette histoire ouvre le meilleur talk de la playlist forward deployed engineering.

Vinoo Ganesh a passé sept ans chez Palantir et a été déployé en Irak et en Afghanistan. Il y a créé Project Frontline, le programme de rotation qui transformait des ingénieurs logiciels en FDE : environ 350 personnes l'ont suivi selon lui, et il en retrouve beaucoup comme FDE chez OpenAI, Anthropic ou xAI. Il a monté un programme comparable chez Citadel, puis cofondé Kepler, où il construit la fonction FDE. Il trouve émouvant, dit-il, d'entendre tant d'intervenants raconter comment Palantir travaillait autrefois.

Une stratégie produit

Sa thèse reprend une formule récente de Shyam Sankar, CTO de Palantir (vers 2:01) : le FDE relève de la stratégie produit. On juge un FDE à ce qu'il a fait entrer dans le produit. Vinoo Ganesh contredit au passage d'autres intervenants de la série : chez Palantir, le FDE a d'abord servi à découvrir Foundry, et le modèle de vente est venu après, ce qui rend secondaires les comparaisons de taille de contrat. Il rejette aussi la définition du FDE comme ingénieur logiciel tourné vers le client : un ingénieur qui se contente de rendre le client heureux fait le travail d'un architecte solutions.

Ce que les clients demandent, et ce dont ils ont besoin

Un transporteur remet à Palantir un cahier des charges de 47 pages : un tableau de bord sur mesure, 14 indicateurs, des alertes avec exploration détaillée, trois mois de développement estimés, après quatre mois de cadrage (vers 5:05). Un ingénieur dont la famille habite près du site finit par s'y rendre et pose une question au répartiteur : « What's the first thing you do with this information Monday morning? » (que faites-vous en premier de cette information le lundi matin ?). Réponse : vérifier les camions en retard et appeler pour réorganiser. Une alerte Slack construite en quatre heures règle l'affaire. Ganesh en tire une lecture (le client décrit une solution, le FDE doit retrouver le problème) et une règle : si la correction prend moins d'une journée, on la livre sans en faire un sujet de stratégie produit. Celui qui définit le problème possède la solution, et gagne la confiance qui ouvre l'accès aux vrais sujets.

Une ingénieure qualité des données bloque pendant un an la migration de fichiers CSV vers Parquet, qui soulagerait les pipelines (vers 8:10). L'équipe finit par l'observer sur place : elle télécharge les CSV sur son poste Windows et les ouvre d'un double-clic pour vérifier les données, et Parquet n'a pas de lecteur natif équivalent. L'équipe écrit une visionneuse Parquet dans la nuit ; la migration est validée en deux jours et le pipeline passe d'environ 17 heures à 2 heures. Ganesh en tire une liste de signaux à guetter : une tâche répétée, un copier-coller entre deux outils, un soupir d'exaspération, un changement d'onglet, un téléphone sorti au milieu d'une tâche. Il y ajoute une question d'ouverture : quelle est la partie la plus pénible de votre matinée ? Aucune documentation ne contient ces informations, et pour les voir l'ingénieur a besoin d'un badge chez le client.

Le langage comme outil de verrouillage

Ventes, opérations, finance et développeurs désignent le même client par quatre mots (customer, client, billing entity, org ID), et chaque traduction casse une intégration ou un pipeline (vers 12:13). Le FDE recense les termes surchargés, les points d'intégration, les couches de traduction et les frontières entre systèmes, puis fixe le vocabulaire : les noms définissent les entités, les verbes les opérations. L'ontologie de Palantir est née de ce travail, et Ganesh en assume la conséquence : un client qui adopte votre produit adopte votre langage, et celui qui fixe le langage devient la fondation de toutes les solutions suivantes. Il cite les skills et les MCP comme exemples récents. Dit sans fard, l'argument décrit une stratégie d'enfermement du client.

Le script temporaire qui a duré

Pour un client, Ganesh écrit un script Groovy de rétention des données, censé être provisoire (vers 16:16). Douze mois plus tard, le script tourne partout chez un client de près de 100 000 personnes ; ses collègues le surnomment « vinoo.groovy », et des invités de son mariage viennent en t-shirt à ce nom. Il en tire cinq questions à se poser avant de livrer : recevrai-je un appel à 2 heures du matin dans six mois, quel compromis je fais, à qui je transmets, qui répond quand ça casse, faut-il intégrer au produit ou jeter ? Sa règle : tout bricolage finit en production, donc livrez comme si le code devait tourner dix-huit mois.

Les limites

Le titre annonce Kepler, mais le talk raconte Palantir : on apprend tout au plus que Ganesh y monte la fonction FDE avec une ingénieure fondatrice présente dans la salle. Les chiffres viennent de souvenirs (2,3 millions de keyspaces à 5 Mo donnent plutôt 11,5 To que 14). Et l'éloge de l'enfermement par le langage mettra mal à l'aise ceux qui travaillent côté client.

Pour une ESN

Les cinq questions avant de livrer un script s'appliquent telles quelles aux consultants, qui laissent derrière eux des scripts provisoires à chaque mission. La règle des dix-huit mois et la liste des signaux d'observation feraient un bon support de formation pour des équipes de delivery. Le passage sur le vocabulaire décrit une réalité des missions data : le consultant qui nomme les entités du client finit souvent par tenir son référentiel. Le comparatif FDE, consultant, architecte, régie détaille ce qui sépare ces postures.

Verdict

Originalité : 4/5. La thèse vient de Shyam Sankar, mais les histoires sont inédites, et l'idée du langage comme outil de verrouillage n'apparaît dans aucun autre talk de la série.

Qualité de l'information : 5/5. Chaque histoire débouche sur une règle applicable, avec des listes de contrôle réutilisables : signaux d'observation, cinq questions avant de livrer, règle des dix-huit mois. Le talk le plus dense de la playlist.

À regarder en entier, de préférence avec votre équipe de delivery. Si vous ne deviez voir qu'une vidéo de la série, prenez celle-ci.

Barème : l'originalité mesure l'apport d'idées neuves (1 : discours entendu partout ; 5 : idée qui change la façon de penser le sujet). La qualité de l'information mesure la précision et l'utilité de ce qu'on apprend (1 : vague ou promotionnel ; 5 : dense, précis, applicable). Cet article fait partie d'une série de neuf retours sur la playlist FDE de l'AI Engineer World's Fair 2026.