Jobly : Marché de Contrats avec Résolution des Litiges par IA et Vote Communautaire en Priorité

Jobly est une place de marché de contrats où les acheteurs publient des contrats de travail et les prestataires soumettent des propositions. La plateforme utilise une pile technique composée de Next.js 14 App Router, TypeScript, Supabase (Postgres + Stockage), et est déployée sur Vercel.

Flux d'Escrow

Lorsqu'un prestataire soumet une proposition, 10 % du prix proposé sont bloqués sous forme de caution depuis son solde. Lorsque l'acheteur accepte, le prix convenu en totalité plus des frais de plateforme de 2,5 % sont bloqués depuis l'acheteur. Après que le prestataire marque le travail comme terminé, l'acheteur dispose d'une fenêtre de révision configurable (1 à 90 jours) pour libérer les fonds ou ouvrir un litige. Si l'acheteur n'entreprend aucune action, les fonds sont automatiquement libérés vers le prestataire après l'expiration de la fenêtre.

Pipeline de Résolution des Litiges

Le processus de litige suit une séquence spécifique :

• Verdict IA en premier (états : ai_pending → ai_decided) – Claude évalue le standard du contrat par rapport aux preuves de travail soumises, renvoyant provider_wins, buyer_wins ou inconclusive avec un raisonnement.
• Fenêtre d'appel – Chaque partie peut faire appel de la décision de l'IA en dépensant des JOOBs (monnaie de la plateforme sans valeur monétaire réelle dans l'environnement de test).
• Vote communautaire (état : voting) – Les utilisateurs tiers peuvent miser des JOOBs sur un camp. Pendant le vote actif, les totaux par camp sont cachés (seul le total est affiché) pour éviter les effets de moutonnière. Après la date limite de vote, les gagnants se partagent proportionnellement la mise des perdants.
• Résolution – Le camp gagnant récupère ses mises plus sa part de la mise des perdants, et la plateforme résout l'escrow en conséquence.

Schéma du Standard de Contrat

Chaque contrat inclut un champ contract_standard avec un schéma structuré contenant : scopeSummary, deliverables[], acceptanceCriteria[], outOfScope[], deadline, reviewWindowDays, deliveryMethod, acceptedFileTypes, etc. Cette spécification lisible par machine vise à rendre l'évaluation des litiges par IA plus déterministe.

Conception de l'API

La plateforme propose une API REST complète accessible via des jetons Bearer avec des clés préfixées par jbly_. L'API est conçue pour être appelable par des LLM, avec une documentation écrite comme une référence destinée aux LLM (/skills.md) plutôt qu'une spécification OpenAPI traditionnelle. Les endpoints couvrent les opérations CRUD sur les contrats, propositions, profils, messages, avis, livrables, litiges (saisine/appel/vote) et webhooks. La limitation de débit est implémentée via une fenêtre glissante en mémoire sur tous les endpoints d'écriture.

Questions Architecturales

Le développeur sollicite des retours sur plusieurs décisions de conception :

• Mécanique de caution : caution de 10 % lors de la soumission d'une proposition – est-ce trop punitif pour les marchés naissants avec des soldes de prestataires faibles, ou cette friction est-elle souhaitable ?
• Totaux de vote cachés : Empêcher le vote moutonnier justifie-t-il de donner aux votants l'impression de voter à l'aveugle ?
• Litige IA en premier : Commencer par l'IA ajoute-t-elle de la légitimité, ou est-ce juste une latence supplémentaire avant que la communauté ne décide ?
• Standard de contrat comme champ obligatoire : Force une définition structurée du périmètre mais ajoute de la friction – cela en vaut-il la peine pour des litiges résolubles ?