ADR : Distinction rôles "product builder" vs "dev autonome avec sens produit"¶
Contexte¶
Romain et Alban cherchaient chacun à recruter "un product builder". Au meeting 2026-04-30, Denis identifie qu'ils ne décrivent pas le même profil :
- Romain : profil produit-first avec un fond tech. Beaucoup de parties prenantes, beaucoup de data, beaucoup d'allers-retours UX.
- Alban : profil dev-first avec sens produit. Ancien dev, capable d'owner techniquement un sujet en autonomie.
Risque de confusion côté Charlotte (recrutement) : envoyer les mêmes candidats sur deux besoins différents.
Options envisagées¶
Option A : Maintenir un rôle "product builder" unique¶
- Inconvénients : confond deux besoins distincts, recrutement inefficace, mauvaises affectations.
Option B : Deux fiches de poste distinctes¶
- Description : formaliser la distinction dans deux job descriptions séparées avec process de recrutement adaptés.
- Avantages : clarté pour les candidats, alignement des process internes, recrutement ciblé.
Décision¶
Option retenue : B — Deux rôles distincts
Profil A — Dev autonome avec sens produit (besoin Alban / besoin tech back-office)¶
- Background tech solide (ex : ancien dev). À l'aise avec Cursor / IA.
- Rattaché à la team tech. Process tech (review plans, criticité, stack commune).
- Capable d'owner du build de bout en bout, en autonomie.
- Sens produit suffisant pour parler aux utilisateurs internes (Mélanie, account managers).
- Use case immédiat : reprendre la gestion des projets d'Alban (ADR 2026-04-30 passation gestion projets).
Profil B — Produit avec fond tech (besoin Romain)¶
- Ownership produit-first.
- Comprend la donnée et la tech assez pour cadrer, pas pour coder seul.
- Beaucoup de parties prenantes, allers-retours UX, exploration métier.
- La tech est conséquence, pas point de départ.
- Pas spécifiquement rattaché à la team tech sur l'autorité, mais respecte les garde-fous criticité.
Process recrutement¶
- Process tech existant (5 étapes) → adapté pour le profil A (long terme, exigeant).
- Process plus léger → pour les freelances / missions courtes / profils B exploratoires.
- Charlotte (recrutement) à briefer après la réunion Romain/Denis lundi.
Conséquences¶
Positives attendues¶
- Charlotte peut sourcer correctement chaque profil
- Pas de candidat "frustré" mis dans la mauvaise case
- Crée la base pour de futurs recrutements (alignement vocabulaire interne)
- Facilite l'intégration : profil A entre par la team tech avec onboarding défini, profil B entre côté produit avec d'autres KPIs
Négatives acceptées¶
- Plus de complexité de naming / RH
- "Product builder" devient un terme à éviter en interne sans précision
Reversibilité¶
- Coût d'annulation : bas, pas de structure lourde.
Plan d'implémentation¶
- [x] Décision prise au meeting 2026-04-30
- [ ] Romain + Denis (lundi 11h) : rédiger fiche de poste profil A (dev autonome back-office)
- [ ] Romain + Charlotte : décaler le call recrutement initialement prévu, attendre output Romain/Denis
- [ ] Quand le besoin profil B sera ré-armé (Romain) : rédiger une fiche de poste séparée
- [ ] Mettre à jour la nomenclature interne (Slack, Notion, Linear) — éviter "product builder" sans qualificatif
Métriques de succès¶
- Recrutement profil A pour gestion projets aboutit sans erreur de casting
- Pas de candidat refusé en fin de process à cause d'une incompréhension du rôle
Sources¶
Révisions¶
- 2026-04-30 : créée et acceptée (status: accepted)