1. Pourquoi les primes l'emportent sur les appels à l'aide ?
Les appels aux bénévoles génèrent des réponses ponctuelles. Un membre aide une fois, se sent bien, puis retourne à l'observation passive — car il n'y avait aucune trace, aucune récompense, aucun suivi. Une prime transforme la même demande en un contrat public, tarifé et persistant : titre, récompense, propriétaire, statut et historique que tout le monde sur le serveur peut consulter.
La tarification est essentielle. Une prime de 20 euros pour une tâche de documentation signale que le travail a une réelle valeur. Les membres qui ne se porteraient jamais volontaires répondent aux travaux tarifés, car le travail tarifé élimine l'ambiguïté quant à la reconnaissance de leurs efforts.
2. Le cycle de vie : quatre commandes, cinq états
Sovereign implémente les primes comme une machine à états stricte : OPEN → IN_PROGRESS → REVIEW → PAID, avec un chemin CLOSED explicite pour les publications abandonnées. Toute personne ayant une Identity Bridge peut créer une prime avec `/bounty create <Titre> | <Montant>` (minimum 5 EUR, stocké en cents), parcourir les primes ouvertes avec `/bounty list`, en prendre une avec `/bounty claim <ID>`, et soumettre le travail terminé avec `/bounty done <ID>`.
La machine à états effectue le travail de modération pour vous. Une prime ne peut pas être réclamée deux fois, le créateur ne peut pas réclamer sa propre publication, et seul le travailleur assigné peut soumettre. Chaque transition notifie la bonne personne : le créateur reçoit un message privé lorsque sa prime est réclamée et à nouveau lorsque le travail est soumis, et la soumission apparaît dans le Dashboard Exchange pour approbation.
Les fonds ne sont libérés qu'après approbation explicite dans le Dashboard. Cela maintient la boucle humaine là où cela compte — la confiance — et automatisée partout ailleurs.
// Command routing and the guard clauses that make the state machine safe
switch (action) {
case 'create': return await createBounty(tenantId, member.id, args); // -> OPEN
case 'list': return { reply: await listBounties(tenantId) }; // 5 latest OPEN
case 'claim': return await claimBounty(tenantId, member.id, args); // OPEN -> IN_PROGRESS
case 'done': return await completeBounty(tenantId, member.id, args); // IN_PROGRESS -> REVIEW
}
// Guards enforced inside the transition functions:
// - status must match the expected state or the command is rejected
// - creatorId !== workerId (no self-claims)
// - only the assigned workerId may call /bounty done
// Funds are released after owner approval: Dashboard > Exchange (REVIEW -> PAID)3. Ajuster les primes pour qu'elles favorisent la rétention, pas seulement la production
Les primes efficaces sont petites, spécifiques et réalisables en une soirée. Une communauté qui publie trois nouvelles primes ou plus par semaine donne aux membres une raison constante de consulter le serveur : le travail ouvert est une raison régulièrement renouvelée de revenir, ce qui est exactement le comportement que les ingénieurs de rétention essaient de créer.
L'approche cumulative consiste à publier des primes pour des éléments qui améliorent le fonctionnement de la communauté : scripts d'intégration, documentation, création de clips, couverture de modération, logistique événementielle. Chaque prime complétée est un actif permanent, et non un livrable unique.
Le minimum filtre le bruit. Une prime inférieure à 5 EUR ne vaut pas la surcharge de la machine à états ni l'attention qu'elle détourne du travail réel. Le prix plancher, comme la porte de REVIEW, est un contrôle de la fraude et du spam déguisé en règle de produit.