Création d'équipe Tech & Produit

Composer une équipe tech et produit n'est pas un problème de recrutement. C'est un problème de séquencement et de niveau de séniorité. La plupart des fondateurs et CEO que j'accompagne arrivent avec la même intuition : "il me faut un dev fullstack, un PO, un designer, et après on verra". Six mois plus tard, l'équipe a quatre personnes et personne ne sait vraiment qui fait quoi — parce que les profils ont été recrutés en parallèle au lieu d'être ordonnés.

L'erreur classique est d'empiler les profils trop tôt. On recrute un Head of Product avant qu'il y ait une équipe à diriger, on prend un data scientist avant qu'il y ait des données à analyser, on cherche un CTO senior avant qu'il y ait une stack à structurer. À chaque fois, le résultat est le même : un profil sous-occupé qui s'ennuie et qui finit par partir, et un budget brûlé qui aurait pu financer le bon recrutement au bon moment.

Mon rôle, en mission de création d'équipe, c'est de poser le bon ordre — celui qui colle à votre stade de maturité et à la réalité de ce que vous savez recruter dans 18 mois. Pas le ratio idéal théorique, le ratio pragmatique qui tient compte de votre marché, de votre stack, de votre géographie, et — depuis 2026 — de l'effet d'amplification de l'IA agentique sur la productivité d'un senior.

À quel stade, qui recruter en priorité

Stade	Tech	Produit	Erreur typique à éviter
Pré-MVP	1 fondateur tech ou Sprint Fondateur	Le fondateur business porte la vision	Recruter un PO avant d'avoir un dev qui livre
MVP livré	1er dev senior (backend ou fullstack)	Le fondateur reste PO	Prendre un junior pour économiser → dette technique
Post-PMF	+1 dev senior + 1 frontend si besoin produit visuel	1er PO (idéalement PO Technique)	Recruter un Head of Product avant que l'équipe existe
Scaling	Lead dev / Tech Lead, premiers profils data	Product Designer, 2e PO, Head of Product	Multiplier les juniors plutôt que monter en séniorité
Post-scaling	CTO senior si pas déjà là, SRE/DevOps, équipe data	Head of Product, équipe Design, Data Analyst	Importer une organisation de 200 personnes dans une 30

Côté Tech : la première équipe technique

Le premier dev : senior, backend ou fullstack

Dans 90 % des cas que j'observe, le premier dev d'une équipe tech doit être un senior — backend ou fullstack — capable de poser une architecture qui ne se cassera pas dans 18 mois. Pas un junior à fort potentiel, pas un spécialiste pointu, pas un mouton à 5 pattes. Un senior expérimenté qui a déjà vu plusieurs codebases survivre à un x10 de trafic, et qui sait quels choix sont irréversibles et lesquels peuvent attendre.

Le backend prime sur le frontend pour une raison simple : la dette d'architecture côté serveur coûte beaucoup plus cher à corriger plus tard que la dette d'UI. Une UI laide se redesigne en quelques sprints ; une base de données mal conçue ou un schéma d'API rigide bloque le produit pendant des années.

Si votre produit est très visuel (B2C grand public, app mobile dont l'expérience est l'argument de vente), un fullstack capable de tenir les deux côtés peut être plus pertinent qu'un backend pur. Mais un "fullstack" qui maîtrise réellement les deux univers est rare et coûte cher — c'est typiquement un senior à 80-100 K€ minimum.

Le frontend dev : quand ?

Quand le backend stabilise une API qui sert une UI complexe, et que le rythme de delivery côté UI devient un goulot d'étranglement. Avant ça, un fullstack ou le premier backend qui fait un peu de front suffit. Ne séparez pas backend et frontend trop tôt : vous créez deux silos qui se synchronisent mal et qui ralentissent la vélocité.

Les profils data : par étapes

Beaucoup d'équipes recrutent un data scientist en premier parce que ça sonne stratégique. C'est presque toujours une erreur. La séquence saine est : analyst → engineer → scientist.

Un data analyst comprend votre business et sait extraire les bonnes questions de vos données. C'est le premier profil utile dès qu'il y a un peu de volume. Un data engineer structure les pipelines, les entrepôts, la fiabilité du flux. Il devient nécessaire quand l'analyst passe plus de temps à débuguer des extracts qu'à analyser. Un data scientist ne devient pertinent que quand l'analyst et l'engineer ont stabilisé une base sur laquelle des modèles peuvent vraiment apporter de la valeur — sinon il reste à modéliser dans un coin sans impact.

L'infra : SRE / DevOps ou pas ?

À 1-3 développeurs, pas de SRE. Le senior backend porte la prod, et c'est très bien comme ça. À 5-10 développeurs, on commence à voir le coût d'opportunité : chaque incident en prod, chaque déploiement manuel, chaque bug d'environnement, c'est du temps qui ne va pas dans le produit. C'est là qu'un premier profil SRE/DevOps (ou un fullstack qui prend cette casquette) devient rentable. À 20+ développeurs sur du cloud, c'est un poste à temps plein.

Pour creuser le détail des profils, des fourchettes de salaire et des séquences de recrutement post-MVP : composer sa première équipe tech après le MVP — qui est le pillar article que je referme à chaque mission de création d'équipe.

Côté Produit : les rôles qui font la différence

PO classique vs PO Technique

Le Product Owner classique vient du métier ou du marketing. Il connaît les utilisateurs, il sait écrire des user stories, il porte la voix du client dans le backlog. C'est utile, c'est nécessaire — mais en 2026, ce n'est plus suffisant pour une équipe tech qui veut vraiment exploiter l'IA agentique.

Le PO Technique est le profil qui émerge depuis 12-18 mois. Il vient de l'engineering, il comprend l'architecture, il sait écrire des stories que l'IA peut exécuter sans ambiguïté. Trois PO Techniques font le travail que faisaient 30 personnes dans une organisation classique — c'est la promesse, et elle commence à se vérifier sur les équipes les plus avancées.

Si vous recrutez votre premier PO en 2026, je recommande systématiquement un PO Technique plutôt qu'un PO classique, sauf si votre produit a une dimension métier très forte (santé, juridique, finance régulée) qui justifie une expertise sectorielle pointue.

Product Designer

Indispensable dès que votre produit a une UI grand public et que le coût d'un mauvais design est mesurable (taux de conversion, support, churn). Avant ça, un fondateur qui a du goût et un dev qui sait recopier un design system suffisent pour un MVP.

Le profil à éviter : le designer pur "qui ne touche pas au code". Un Product Designer en 2026 sait au minimum lire du HTML/CSS, idéalement éditer des composants directement dans le code. Avec Claude Design et le MCP Figma, un designer compétent peut maintenir le design system lui-même dans le repo — sans dépendre d'un dev pour propager une variation de couleur.

Head of Product : quand le promouvoir ?

Pas avant qu'il y ait une équipe produit à diriger. Ça paraît évident, et pourtant je vois régulièrement des annonces "Head of Product" pour des équipes d'un seul PO. Le bon timing : 3-4 PO/Designer dans l'équipe, et un fondateur qui veut sortir du quotidien produit pour se concentrer sur la stratégie.

Promouvoir trop tôt en interne est aussi piégeux que recruter trop senior à l'extérieur. Le PO qui devient Head of Product sans étape intermédiaire se retrouve à manager des collègues qu'il avait il y a 3 mois, sans formation au management, et souvent sans légitimité technique ou business qui justifierait la promotion.

Pour le détail de chaque rôle produit, des séniorités, et de ce que l'IA agentique change : les rôles d'une équipe produit en 2026.

L'ordre de recrutement par stade

Pré-MVP : le minimum viable team

Souvent un seul fondateur tech qui code, ou un fondateur business qui passe par un Sprint Fondateur pour livrer un MVP en 2 mois sans recruter. À ce stade, recruter c'est déjà commettre — donc on attend que le PMF soit confirmé.

Post-MVP : le 1er recrutement structurant

Le premier dev senior. Pas un junior, pas un fullstack mid-level. Un senior à 70-90 K€ qui prend en charge l'architecture et qui sera le pilier sur lequel l'équipe va se construire. Ce recrutement-là est le plus stratégique des 24 prochains mois — c'est aussi le plus délicat à évaluer pour un fondateur non-technique, ce qui justifie de se faire accompagner sur la grille d'évaluation et les entretiens techniques.

Post-PMF : le passage à l'échelle

Cinquième à dixième salarié, l'équipe se densifie. C'est le moment du premier PO (idéalement PO Technique), du 2e dev pour soutenir le rythme, et selon le produit, d'un Product Designer. Le fondateur sort progressivement du quotidien produit, et la question d'un Lead Dev / Tech Lead émerge — généralement en interne, par promotion du dev senior qui a montré de l'envie de manager.

C'est aussi à ce stade que se pose la question d'un accompagnement IA agentique pour structurer les méthodes de l'équipe en train de se former — plutôt que de laisser chacun improviser et de devoir restructurer 12 mois plus tard quand les mauvaises habitudes seront installées. → Voir la prestation accompagnement IA agentique.

Scaling : managers et leads

Au-delà de 10-15 personnes, on passe d'une équipe à une organisation. C'est là que les questions de squad ou feature team, de Lead Dev vs Tech Lead, de Head of Product, deviennent réelles. La séquence type : Tech Lead, puis Engineering Manager si l'équipe dépasse 10-15 devs, puis Head of Product, puis CTO senior si pas déjà en place. Toujours dans cet ordre, jamais l'inverse.

Ce que change l'IA agentique en 2026

C'est la donnée qui rebat les cartes depuis 12 mois. Un développeur senior productif piloté par Claude Code ou Cursor en mode agentique fait 2 à 3 fois plus qu'avant à qualité égale. Concrètement, une équipe qui aurait dû passer de 8 à 15 développeurs en 18 mois en évite généralement 4 ou 5 — et ces recrutements évités se retrouvent en partie réinvestis dans la séniorité moyenne (un senior plus payé qui pilote vaut mieux que trois juniors qui produisent peu).

Deux conséquences directes pour la composition d'équipe :

On recrute moins, mais mieux. Le ratio devs juniors / devs seniors s'inverse. Là où une équipe classique tournait à 60 % juniors / 40 % seniors, une équipe IA-augmentée tourne plutôt à 70 % seniors / 30 % juniors — parce que l'IA fait le travail répétitif que faisaient les juniors, et qu'elle a besoin d'un pilote senior pour produire du code qui tient en prod. → Le vrai ROI de l'IA agentique : moins de recrutement, moins de coûts, plus de vélocité.

Le PO Technique émerge. C'est le profil le plus structurant à recruter en 2026 si vous montez une équipe produit. Pas le PO classique formé en école de commerce — un profil hybride qui vient de l'engineering ou qui s'y est plongé sérieusement. Trois PO Techniques font le travail de 30. → Le PO Technique : le profil qui va redéfinir les équipes produit.

Si vous structurez votre équipe en 2026 sans intégrer cette dimension, vous bâtissez une organisation qui sera obsolète dans 24 mois.

Erreurs classiques

Le mouton à 5 pattes. "Je cherche un fullstack senior qui maîtrise Next.js, Symfony, Rust, le mobile, le DevOps, et qui parle anglais." Cette personne n'existe pas — ou si elle existe, elle est déjà CTO chez un GAFAM. Acceptez les compromis : un excellent backend qui apprend le frontend en quelques mois vaut mieux qu'un fullstack médiocre sur les deux.

La techno exotique pour "attirer les talents". Choisir Rust ou Elixir pour un MVP B2B parce que c'est cool sur LinkedIn, c'est se condamner à un pool de candidats minuscule pendant 5 ans. Choisissez la techno que vous saurez recruter sur votre marché géographique — pas celle qui fait rêver les early adopters.

Promouvoir trop vite en management. Le senior qui devient Lead Dev en 6 mois parce qu'il était le plus à l'aise techniquement n'est pas forcément un bon manager. Et un bon manager qu'on dépouille de son temps de code en 3 mois va frustrer. Étalez les transitions : Lead Dev d'abord (technique + influence), Engineering Manager ensuite (management + people).

Sous-évaluer l'infra dès le début. Pas besoin d'un SRE temps plein pour 5 développeurs, mais ignorer la question pendant 18 mois construit une dette technique qui coûtera 6 mois à payer plus tard. Un dev senior qui porte la casquette infra à 20-30 % de son temps suffit longtemps — à condition de le reconnaître officiellement et de lui en donner les moyens.

Ce que je peux faire pour vous

Concrètement, en mission de création d'équipe :

• Audit du besoin — 1 à 2 semaines pour comprendre votre business, votre produit, votre stack, votre culture. Diagnostic des écarts entre la situation actuelle et l'organisation cible.
• Plan de recrutement priorisé — qui recruter, dans quel ordre, à quel niveau de séniorité, avec quel budget, et avec quels signaux pour valider que c'est le bon moment de chaque hire.
• Coaching du premier manager tech ou produit — accompagnement à la prise de poste pour le premier Lead Dev / Head of Product, sur 3-6 mois, pour éviter la transition ratée.
• Accompagnement opérationnel jusqu'au premier hire — sourcing, design des entretiens techniques, grilles d'évaluation, conduite des entretiens en binôme, négociation et closing du candidat retenu.

Si vous êtes en train de structurer votre équipe, c'est exactement le genre de question qu'on peut cadrer en 30 minutes : prenons un rendez-vous.

FAQ

Comment prioriser entre tech et produit pour le 1er recrutement ?

Tech avant produit, dans 80 % des cas. Tant que le fondateur peut tenir le rôle de PO (vision claire, écoute client, capacité à arbitrer), recruter un PO en premier détourne du budget qui aurait dû aller dans la capacité à livrer. Le moment où il faut basculer : quand le fondateur passe plus de temps à écrire des specs qu'à parler à des clients ou à travailler la stratégie. À ce moment-là, un PO (idéalement Technique) prend le relais et le fondateur récupère son temps stratégique.

Faut-il un CTO senior ou peut-on partir avec un lead dev ?

Tant que vous êtes sous 10 développeurs, un Lead Dev / Tech Lead suffit largement. Le rôle de CTO devient pertinent quand l'équipe doit être managée en couches (CTO → leads → devs), quand il y a un sujet de représentation extérieure (investisseurs, clients grands comptes), ou quand des dossiers transverses prennent le pas sur le code (CIR, sécurité, dette stratégique). Pour le détail des profils CTO, Head of Engineering, EM, Lead Dev et qui pour quoi à quelle taille : CTO, Head of Engineering, Lead Dev, Engineering Manager.

Quel est le ratio devs / PO sain ?

Avant 2025 : 1 PO pour 5-7 développeurs. Depuis l'arrivée de l'IA agentique : 1 PO Technique peut tenir 3 à 5 devs très productifs, ce qui ramène le ratio à environ 1 pour 4. Au-delà, le PO devient le goulot d'étranglement — pas l'inverse. Si vous voyez votre PO submergé par les questions techniques de l'équipe, c'est le signal de recruter un 2e PO ou de monter le 1er en compétence sur l'archi.

Combien de temps faut-il pour recruter le 1er dev senior ?

Comptez 3 à 6 mois entre la décision de lancer le poste et la signature, en France, pour un profil senior à 70-90 K€. Pour aller plus vite : commencez par activer votre réseau (cooptation), puis sourcez en parallèle sur 2-3 canaux (LinkedIn Recruiter, Welcome to the Jungle, votre prestataire dédié). N'attendez pas d'avoir terminé un poste pour ouvrir le suivant — mais ouvrez-les dans le bon ordre.

Mieux vaut sourcing direct ou cabinet ?

Sourcing direct si vous avez le temps et un fondateur qui aime ça (3-5h par semaine pendant 3 mois). Cabinet si vous cherchez un profil très précis ou si votre temps vaut plus que 15-20 % du salaire annuel facturé. La pire option est de faire les deux à moitié : un cabinet qu'on ne brief pas correctement et un sourcing direct qu'on fait avec 2h par semaine de bonne conscience. Choisissez et engagez-vous.

Doit-on tester en mission avant CDI ?

Pour un premier recrutement structurant (1er dev senior, 1er CTO, 1er Head of Product), la période de mission de 1 à 3 mois est devenue un standard sain. Elle protège les deux parties : le candidat évite le risque d'un CDI où il serait mal à l'aise, vous évitez le risque d'un mauvais hire structurant. Le coût pour l'entreprise est légèrement supérieur (TJM > salaire mensuel rapporté à l'heure), mais largement compensé par la qualité de l'évaluation mutuelle.

Comment évaluer le niveau réel d'un candidat senior ?

Trois leviers que j'utilise systématiquement : (1) un deep dive sur un projet réel que le candidat a livré — pas le pitch CV, le détail technique des choix qu'il a faits et de ce qu'il referait différemment ; (2) un exercice live sur un problème qu'il découvre, pour observer son raisonnement plus que sa solution ; (3) un entretien avec un pair externe (un autre senior de votre réseau, ou un consultant comme moi) qui valide la cohérence technique sans être biaisé par la pression du recrutement urgent. Sans ces trois leviers, vous évaluez surtout la capacité du candidat à passer un entretien — pas son niveau réel sur le terrain.