Aller au contenu

Posture freelances — test fit / post-validation

Statut : acquis, formalisé S18 (05/05/2026). Le cadre partagé vit sur cette page. Les mappings nominatifs historiques restent dans l’archive locale.

Le principe

Un freelance peut claquer la porte demain. On ne l'onboard pas comme un salarié.

Deux phases distinctes :

Phase Posture Onboarding Channel Slack Concertation
Test fit (livraison V0) Distance, pas d'investissement temps Minimal Non Pull, on demande quand on a besoin
Post-validation Mise en boucle, capitalisation expertise Complet Oui Échanges réguliers, on valorise le contexte

Phase test fit

Posture

« Donne-nous ton livrable, on passe et go next. » — Romain (synchro S18)

  • Pas d'investissement temps côté Romain × Nicolas
  • Pas de channel Slack commun — la communication passe par mail / Linear
  • Pas de présentation à la team interne ou aux autres freelances
  • Le freelance livre sa V0, on évalue, on décide
  • Critère d'évaluation : qualité du livrable + capacité à apporter une approche structurellement indépendante des autres (cf. pari fiabilité)

Pourquoi cette distance

  • Économise du temps de Romain et Nicolas (≠ valeur ajoutée)
  • Protège l'organisation si le freelance ne va pas au bout
  • Force le freelance à livrer en autonomie (signal fort sur sa capacité opérationnelle)

Phase post-validation

Une fois le test fit validé, le freelance bascule en boucle :

  • Channel Slack dédié ou commun avec les autres free post-validation
  • Mise en contexte : accès aux décisions structurantes, doctrine, ADR
  • Échanges réguliers : weekly 30 min, partage de la vision produit
  • Capitalisation explicite de son expertise dans le wiki / la doctrine

Cas d'application (patterns abstraits)

Les cas nominatifs et les appréciations individuelles restent dans l’archive locale. Les patterns partageables sont :

Signal observé Décision de pilotage
Livrable autonome, expliqué et comparable Valider le test fit, puis ouvrir l’accès au contexte et aux rituels
Changement d’approche non concerté ou livrable inexploitable Terminer le contrat convenu, capitaliser ce qui reste utile, puis arrêter
Expertise pertinente mais collaboration transverse prématurée Garder les échanges via le DRI jusqu’à validation du fit
Proposition hors du problème cadré Reposer le brief et exiger un livrable testable avant tout onboarding

Conventions de pilotage

Romain reste le hub

Pas de call croisé direct entre freelances. Si un freelance a une question pour un autre, ça passe par Romain. Évite le téléphone arabe et garantit que les comparaisons se font sur chiffres (golden dataset), pas sur opinions.

Les comparaisons se font sur chiffres

Pas de débat "approche A vs approche B est mieux" en synchro. On laisse les outputs tourner sur le golden dataset, on mesure la convergence, on arbitre sur la donnée.

Brief commun, livrables comparés

Chaque freelance reçoit le même brief sur le même périmètre (ex. extraction documents). Leurs outputs alimentent la même vue comparative via API POST sur les 5 dossiers du golden dataset.

Trace historique

Doctrine formalisée en mai 2026 à partir de plusieurs tests de collaboration. Le détail nominatif reste dans l’archive locale.

Sources

  • Source legacy : bricks-os/wiki/operations/posture-freelances.md (copie complète dans le backup local)
  • Pari fiabilité