Aller au contenu

Squads

Définition

Modèle d'organisation discuté par Romain et Denis depuis 2025 : structurer la team par squads fonctionnelles (un périmètre métier + ses utilisateurs internes) plutôt que par discipline pure (front / back / produit).

Pourquoi on en parle

La conversation meeting 2026-04-30 a confirmé l'orientation : "on est une squad les gars" (Romain, sur le périmètre back-office). Constat : Denis fait du back-office full-time depuis des mois, Vincent aussi côté refonte. Romain et Alban font du back-office côté produit. → Squad de fait.

État actuel (auto)

Dernière mise à jour : 2026-06-09

Vision Denis 04/06 — squads par périmètre + team "core" transverse (à arbitrer Romain)

Posée en synchro Alban × Denis du 04/06 (Romain absent) — réflexion, pas décision :

  • Petites squads permanentes par périmètre produit : investisseur (~2 back + 1 front), PDP (~1 back + 1 front), qui ne font que des features de leur périmètre, pour éviter que les gens « se marchent dessus en permanence » (L562, L629-641).
  • Une team "core" transverse sur les systèmes mutualisés (paiement, KYC…) qui expose ses outils aux autres squads (« Brixnon, tu as besoin du KYC, du paiement… »). Cette team n'apparaît pas dans la liste de référence ci-dessous → à intégrer si la vision est retenue.
  • Profils différenciés : front plus orientés produit/UX, core/back plus orientés solidité/sécurité (L611-626).
  • Précision sémantique : "internal tooling" recouvre surtout du back-office (web interne pour faire gagner du temps aux équipes), pas seulement des skills/workflows de productivité (L563-581).

Position Alban (forte) : le modèle par pôles (pôle marketing, pôle tech) a de moins en moins de sens ; « on fonctionne déjà plus en format squad » ; l'identité doit être liée aux compétences + objectif boîte, pas au métier (L584-596). Cohérent avec le recrutement backend senior actif de Denis qui rendrait cette orga atteignable vite.

Question Q3 — squad analyse / automatisation à structurer (non tranché)

Posé par Romain en synchro 25/05 : aujourd'hui le périmètre "automatisation analyse + outillage account managers" est porté par 3 freelances (Jérôme PO outillage AM, Nico PM analyse / comité, Dimitri tech outil d'analyse) avec Romain comme seul pont vers l'équipe. Question structurelle : « est-ce qu'on reste comme ça parce que ça noierait trop le contexte, ou est-ce qu'on a vocation à un peu plus réunir tout le monde ? ».

Position Denis : multiplier les projets fat noie la tech ; le concept de squad qui sépare les éléments est plutôt sain ; mais il faut des rôles transverses côté tech (pas que Romain) pour préserver la cohérence globale (architectures, conventions, sens global).

Logique posée pour Q3 : - Le sujet automatisation analyse est un run infini (les tools changent, les IA changent, les besoins changent, la typologie projet change) → squad pérenne nécessaire. - En parallèle, Romain peut retourner sur d'autres sujets (rétention investisseurs / gamification / centre de notice). - Accord acté : poursuivre deux objectifs en parallèle au Q3 si la structure le permet, pas un seul à la fois.

Pré-requis identifié : besoin d'une personne tech en interne dédiée au sujet automatisation / agents IA, en binôme avec un freelance ownership tech (potentiellement Dimitri). Cohérent avec la logique "sujets centraux Bricks gardés en interne, sujets autonomisables aux freelances" appliquée sur l'EF (Denis garde KYC / wallet, William prend versement). Profil cible non encore défini — débrief tech ↔ tech Denis × Dimitri acté comme next step pour défricher.

État opérationnel à date — pas (encore) en squads

Romain a posé cash le constat dans le call de cadrage TPC du 11/05 : aucune squad n'est véritablement opérationnelle aujourd'hui. Une bascule vers une orga par squad avait été initiée, puis abandonnée par faute de ressources produit (Romain seul au PM) et après le départ d'un PM précédemment recruté.

Les groupes de travail se forment naturellement autour des produits et des enjeux, sans structuration formelle de squad. Charlotte a synthétisé en call : "il y a plus une roadmap commune tech et produit avec deux produits, mais ça ne peut pas être un discours de squad avec des développeurs aujourd'hui".

Trajectoire — deux squads avant la multiplication

Étape 1 (objectif court terme post recrutement PM Squad Investisseur) : deux squads opérationnelles — investisseur + porteur de projet. Première étape avant de paralléliser plus largement.

Étape 2 (à terme) : multiplication des squads sur l'ensemble des sujets produit (cible ~10).

Squads cibles (liste de référence)

  • Squad investisseur — front investisseurs, back-office associé. PM en cours de recrutement via TPC + sourcing direct Charlotte. Romain reste référent produit jusqu'à l'arrivée du PM.
  • Squad porteur de projet — front PDP + back-office associé. Romain bascule comme PM owner sur ce périmètre (priorité stratégique #1 du moment : publier davantage de projets). Confirmé en call TPC du 11/05.
  • Squad back-office — gestion projets, CRM, outils internes admins. Composée à date de Romain (produit, en transition), Alban (produit + transition vers passation), Denis, Vincent. Recrutement en cours d'un dev senior pour reprendre la gestion des projets (ADR 2026-04-30).
  • Squad analyse — scope grille Product Builder V1. Romain (PM, référent produit) + Product Builders rattachés à l'outil d'analyse.
  • Squad origination — Cédric + Maxime + Angéline (volume financé, sourcing deals).
  • Squad care / support — Jérôme, Florentin, Quentin (à formaliser).
  • Squad marketing / growth — Yoann + Alban (à formaliser).

Liste opérationnelle complète à formaliser (pré-requis pour structurer l'organisation par squad).

Granularité : pas de "product owner unique" hors-tech. Chaque squad a ownership produit (Romain ou Alban à date) ET ownership technique (Denis, Vincent ou recrutement à venir).

La maille de distribution du package / bonus par squad relève du cadre d'évaluation (RH) et reste documentée en local.

Décisions liées

Projets et areas impactés

Sources