Prépa bio pour l'une, fac de biologie et informatique pour l'autre. Deux ans de bar, un passage par le COBOL et des missions en ESN avant d'atterrir là où ça fait sens. Morgane et Hugo se sont rencontrés en bioinformatique à Paris, ont fait la même formation de reconversion web, et ont rejoint Paladin à quelques mois d'intervalle après que Hugo ait recommandé Morgane en cours de process. Ce live est leur retour sur une année de founding engineering : ce qu'on construit, comment on recrute, et pourquoi ça n'a rien à voir avec être senior.
1. Le zigzag vers le code, sans école d'ingénieurs
Morgane
Après le bac, une prépa bio par défaut. La découverte du code en cours de maths via MATLAB. "J'ai adoré. Je suis tombée amoureuse." Bioinformatique à Paris pour combiner les deux disciplines. Débouché peu enthousiasmant : labo pharmaceutique ou recherche. Décision : manager un bar pendant deux ans et demi avec un ami. Tentative de se former seule en data science, entretien raté. Conclusion : "Il me faut une formation vraiment en live avec un formateur." Pas de formation data science disponible à l'époque, mais une formation web. Elle y va. C'est 2016.
Hugo
Raté le concours de Sciences Po Paris. Arrivé en double cursus biologie-informatique à Grenoble "parce que j'aimais bien bidouiller des ordinateurs." Croisé Morgane en bioinformatique à Paris. À la fin, pas de vocation pour la recherche. "Beaucoup de profs nous ont dissuadés eux-mêmes : si vous voulez faire de la recherche, changez de pays." Passe par une formation COBOL via Pôle emploi, recruté par Sopra, envoyé installer des Windows Vista sur des automates bancaires de la BNP. "Le début, quoi." Morgane arrive en fin de sa formation web. Il se dit banco et enchaîne la même. Recruté derrière par Capgemini.
2. Ce qui se construit dans les premières expériences
Morgane
Mission Capgemini chez Enedis : seule développeuse sur un plateau, scripts Python, pas passionnant. Passe ensuite chez Kepler (suivi de transport de matières premières par bateau) : data engineering, Python, premiers vrais workflows. C'est là qu'elle découvre et s'implique dans Ladies of Code, une communauté pour les femmes dans la tech. Brève expérience chez une startup de location de villas de luxe. Puis un meetup Ladies of Code organisé avec Alan. Elle postule malgré le syndrome de l'imposteur. "Alan ne recrutait que des profils seniors, moi je me disais ils ne vont jamais me prendre." Elle est recrutée. Presque trois ans chez Alan, découverte du full stack, du React, et surtout d'une culture où "en tant qu'ingénieur, on était très très impliqués dans le produit, on bossait avec les designers, avec le product, on avait vraiment beaucoup d'autonomie." Passage ensuite en freelance pour découvrir les petites structures, notamment Ouraï (itinéraires de voyage en train) où elle est la seule développeuse. "J'ai adoré ce côté petite équipe, beaucoup d'autonomie, être à fond pour prendre des décisions."
Hugo
Trois ans en ESN (Capgemini puis Zenica) sur des missions pour Michelin, EDF et d'autres grands comptes. "Ça m'a donné une vision de plusieurs types de projets, mais j'avais envie de ne plus être un consultant exécutant au sein d'une autre boîte." Rejoint Inato, startup de mise en relation entre entreprises pharmaceutiques et hôpitaux pour des essais cliniques. "Il n'y a pas un endroit dans ma carrière où j'ai appris autant qu'à Inato." Découverte du front-end, de la culture du feedback toutes hiérarchies confondues, de la culture produit. Et surtout : à peine un ou deux mois après son arrivée, la boîte pivote et repart from scratch. "J'ai eu cette chance de découvrir ça. Qu'est-ce que ça voulait dire de démarrer un projet vraiment de zéro, de participer au choix de la stack technique, de mettre en place les premières briques, un système design, une architecture. C'est ça qui a été un peu la révélation." Presque quatre ans chez Inato. Rejoint ensuite Oco (startup eFounders) comme premier ingénieur, mais la boîte est rachetée par Spendesk neuf mois après. "J'ai su qu'il fallait que je m'écoute et que j'aille chercher ce que j'avais envie de trouver."
"Moi, j'ai dit : si je rêve, si coup de baguette magique, je construis mon poste idéal, ça serait quoi ? Ça serait une boîte early stage, petite équipe, tout à construire, idéalement dans le domaine de la santé. Et c'est en entendant ça qu'il a dit, ah bah tiens, j'en connais une."
3. Ce qu'on construit quand il n'y a rien au départ
Paladin est une startup qui améliore la prévention en santé via un centre de santé au travail (Sano). C'est le premier à avoir obtenu un agrément pour exercer la médecine du travail depuis plus de trente ans. L'équipe tech à l'arrivée de Morgane et Hugo : Hugo le CTO (deux semaines d'ancienneté lui-même), eux deux, puis Jarod en troisième founding engineer.
Ce qu'ils ont livré en moins d'un an à trois : une application RH pour la gestion des salariés, une application pour le centre de santé (planning, créneaux, consultations), et une application pour les salariés (accès aux visites, téléconsultations). Le tout avant que Claude Code n'existe dans sa forme actuelle.
Une décision radicale en early stage
Environ quatre mois après leur arrivée, la codebase avait un modèle de données inadapté, notamment pour une norme d'API médicale appelée FHIR (partage de données de santé). Décision : tout casser et repartir. "Si on ne le fait pas maintenant, on ne pourra jamais le faire. C'est aussi le luxe de pouvoir faire ça."
Le lancement
Le lancement était le 5 janvier 2026. "Un lancement de produit, ce n'est jamais complètement... ça ne se passe jamais sans accrocs. Donc voilà, on est arrivé, on a lancé, il y avait un peu du feu partout." La phase post-lancement : stabiliser, identifier les pain points utilisateurs, prioriser les corrections pérennes plutôt que les rustines.
"C'est aussi devoir parfois être scrappy. Des fois, on a des deadlines importantes. Il faut qu'on puisse montrer quelque chose qui n'est très loin d'être prêt, en tout cas beaucoup plus loin qu'une semaine. Et il faut être capable de faire des choix, d'aller vite, de prendre des raccourcis, tout en sachant qu'il faudra résoudre cette dette plus tard."
4. Un contexte
Founding engineer n'est pas un niveau de séniorité. C'est un contexte : arriver dans une boîte où il y a à peu près tout à faire et où on n'est pas nombreux pour le faire.
Les compétences requises
Elles dépassent le full stack traditionnel. "Ça demande de s'intéresser aux produits, de s'intéresser au design, d'être capable de faire du front, du back, de modéliser de la donnée, de bidouiller un peu d'infrastructure, d'avoir des notions en sécurité. Il faut avoir un peu l'ensemble de ses compétences ou au moins la curiosité d'aller les creuser."
Sur le niveau requis
Ni Morgane ni Hugo ne recommandent le rôle avant quelques années d'expérience. "Certes, on peut être très bon techniquement, mais sans l'expérience derrière de 'j'ai vu ça, du coup ça me rappelle telle chose', c'est compliqué de faire les bons choix." Ce qui manque souvent aux très juniors : la construction d'équipe, la communication avec le produit, la gestion de la panique en production.
Sur les profils 3-5 ans avec réflexion produit
"C'est des profils super intéressants. La réflexion produit, c'est d'être curieux, c'est d'avoir envie de bien faire les choses. La tech, ça s'apprend, on peut se former. Donc, ne pas hésiter, foncer."
Sur les profils en reconversion
"J'ai bossé avec des développeuses issues de reconversion à Alan qui étaient brillantes, incroyables. Et c'était un plaisir de bosser avec, justement, parce qu'on sentait qu'il y avait une autre expérience derrière et beaucoup de recul."
5. Un recrutement inclusif construit par les founding engineers eux-mêmes
Morgane, Hugo et Jarod ont entièrement revu le process de recrutement pour les cinq nouvelles recrues. Leur décision était respectée par l'équipe dirigeante sans filtre scolaire. "Il se trouve aussi que dans les faits, les trois premiers founding engineers recrutés, Morgane, Jarod, moi, même Hugo notre CTO, aucun de nous quatre n'a fait d'école d'ingé."
L'offre d'emploi
Rédigée pour être la plus inclusive possible, pour ne pas décourager les candidatures de profils sous-représentés. "On sait que les femmes peuvent avoir peur de postuler, avoir un syndrome de l'imposteur."
Test à la maison remplacé par du live coding
Raison principale : "Le test technique à la maison, il y a quand même un désavantage des personnes qui peuvent éventuellement se faire aider, versus une mère célibataire en poste qui doit s'occuper de ses enfants le week-end. Elle n'aura pas douze heures à y consacrer et ce n'est pas ça qu'on cherche à tester."
Réduction du stress du live coding
Le jeu de données utilisé lors de l'exercice est envoyé en amont au candidat pour qu'il puisse se familiariser. Le plan de l'entretien est transmis en avance (sans les questions). L'environnement de développement est préparé à l'avance. "On leur dit : il faudra pouvoir lancer un script, prépare ça et tout va bien se passer." Pendant l'entretien : "On leur explique qu'on est là pour bosser ensemble, qu'ils peuvent poser toutes les questions, chercher sur Google s'il y a besoin."
Deuxième entretien en présentiel
Un exercice de system design volontairement vague, avec des critères d'évaluation sur la capacité à poser des questions de clarification avant de proposer des solutions. "On veut surtout voir que la personne va poser un maximum de questions pour clarifier le sujet." Suivi de questions comportementales sur la capacité à recevoir du feedback et à gérer des désaccords.
6. Investir du temps maintenant pour en gagner après
Cinq nouvelles recrues : deux arrivées un mois et demi avant le live, trois arrivées la veille. L'équipe est passée de trois à huit ingénieurs.
La méthode
Des tickets faciles pour les premières semaines afin d'explorer la codebase sans pression de résultat. Un système de buddy : un founding engineer dédié à chaque nouveau pour assurer un suivi personnalisé. Pas de deadline sur les tâches d'onboarding. Utilisation des code reviews comme outil de formation, de feedback et de transmission des standards.
Sur la charge que ça représente
"On est moins productif, on avance moins sur le produit en ce moment, mais on le sait, on le sait tous, ça fait partie du jeu." L'avantage des arrivées en batch : mutualiser les présentations et créer une solidarité naturelle entre les nouvelles recrues.
"Il vaut mieux passer ce temps-là maintenant et que ça se passe bien, et ça va être bénéfique pour la suite."
7. Ce qu'on ferait différemment et ce qu'on a appris à valoriser
Savoir couper
Le conseil que Morgane donnerait à un nouveau founding engineer : "Pas hésiter à tout challenger et à cut ce qui est superflu. On a perdu du temps sur des fonctionnalités qui n'étaient pas forcément nécessaires. Il ne faut pas hésiter à être vraiment fort de proposition, à challenger, à enlever ce qui est en trop."
Savoir dire non
"Il faut vraiment pouvoir savoir dire non et savoir expliquer pourquoi." Hugo le reçoit encore comme feedback de son CTO : "Des fois, tu as tendance à être soit trop optimiste ou même trop gentil. Si un truc ne rentre pas dans le scope, dis non. Demande-moi de t'aider à dire non."
Les profils complémentaires valent plus que les profils similaires
"Hugo a une approche beaucoup plus théorique, technique, assez pointue, alors que moi, j'ai un esprit beaucoup plus produit. Et en fait, on s'est rendu compte que ça fonctionne très bien ensemble. Il n'y en a pas un qui est meilleur que l'autre. On a des compétences différentes et des expertises différentes. Et tant mieux."
Sur le syndrome de l'imposteur en reconversion
Morgane : "J'avais un gros syndrome de l'imposteur initialement. Et en fait, je me suis rendu compte que ce n'était pas du tout un problème. Toutes les expériences passées, notamment le fait que j'ai managé un bar pendant deux ans et demi, ça m'a appris à réagir vite, à être dans l'action." Hugo : "Si ça a été le cas, ça a très vite arrêté de l'être. Des personnes qui sortaient de reconversion, de part aussi leurs expériences d'avant, pour moi en tant que globalité étaient plus compétentes que des personnes très seniors."