Toomny

Marketplace de talents pour l'Afrique de l'Ouest. Les PME recrutent des prestataires du continent, paient en mobile money, et les fonds restent sécurisés jusqu'à la livraison.

Domaine : toomny.com · Statut : produit fonctionnel en français, anglais prêt sur les parcours connectés.

---

État du projet

Le parcours complet tourne : catalogue public avec forfaits et avis, commande, paiement mobile money via GeniusPay (encaissement), séquestre miroir, messagerie temps réel, litiges avec arbitrage admin, KYC avec recours humain, profils prestataires, versements en file manuelle, et back-office (commandes, litiges, KYC, utilisateurs, prestations, catégories).

Ce qui est posé depuis le premier commit et ne change pas : le modèle monétaire (entiers, multi-devises), la machine à états du séquestre, le journal comptable en ajout seul, et l'i18n FR/EN sans chaîne en dur.

Les trois règles d'architecture

Elles sortent directement de l'étude de marché et ne sont pas négociables.

1. Nous ne détenons jamais les fonds

En zone UEMOA, la détention de fonds du public est réservée aux banques, établissements financiers de paiement, SFD autorisés et établissements de monnaie électronique agréés par la BCEAO. Les agrégateurs de paiement n'ont pas de cadre propre et sont traités comme prestataires techniques.

Conséquence : le séquestre est porté par un partenaire agréé. escrow_holds n'est qu'un miroir local de l'état côté partenaire, et aucune colonne du schéma ne représente un solde détenu par Toomny. Voir src/lib/payments/types.ts.

2. Multi-devises dès le départ

Tout montant est un entier dans la plus petite unité de la devise, jamais un flottant. Le XOF n'a pas de subdivision — exponent 0 — contrairement à l'USD. L'interface n'expose que le XOF en phase 1 ; la base est déjà prête pour le cedi, le naira et le dollar. Voir src/lib/money.ts.

3. Journal comptable en ajout seul

ledger_entries n'est jamais modifié ni supprimé (trigger en base, y compris pour la clé service) ; une correction se fait par une écriture inverse. Ce journal conditionne l'attestation de revenus et l'avance sur mission, les deux produits financiers qui porteront la marge réelle. Voir src/lib/order-ledger.ts.

Contraintes de conception

• Mobile d'abord, réseau lent d'abord. Plus de 90 % du trafic viendra d'un téléphone, souvent en 3G. Polices auto-hébergées au build (zéro requête distante au runtime), pas d'image décorative, pas de parcours à plus de trois écrans.
• Bilingue FR/EN nativement. Aucune chaîne de texte en dur dans un composant. Les pages connectées suivent la langue du profil ; les pages publiques suivent le cookie de langue.
• Wave par défaut pour les versements : gratuit à la réception pour le prestataire.

Modèle économique encodé

Paramètre	Valeur	Où
Commission prestataire	10 % (1000 bps)	DEFAULT_COMMISSION_BPS
Commission client	0 %	—
Délai de versement annoncé	24 h	PAYOUT_SLA_HOURS
Validation automatique après livraison	72 h	AUTO_RELEASE_AFTER_DELIVERY_HOURS (tâche quotidienne 06:00 UTC, délai effectif 72–96 h)

L'arrondi de la commission se fait toujours au détriment de la plateforme, jamais du prestataire.

Stack

Next.js 16 · React 19 · Tailwind 4 · TypeScript · Supabase (PostgreSQL + Auth + Storage + Realtime) · Drizzle (DDL uniquement) · Vercel.

Démarrage

npm install
cp .env.example .env.local   # puis remplir
npm run db:push              # crée les tables depuis src/db/schema.ts
# puis, dans l'éditeur SQL Supabase (projet de test d'abord), jouer DANS L'ORDRE :
#   supabase/migrations/0001_security_rls.sql       # RLS, journal immuable, bucket KYC
#   supabase/migrations/0002_…_0010_…               # stats admin, trigger, rate limits, audit, realtime…
#   supabase/migrations/0011_…_0020_…               # couvertures, galerie, tags, forfaits, inquiries, réparations
npm run dev

⚠️ Sans les migrations, la base n'a aucune politique d'accès : la clé anonyme publique donnerait accès à toutes les tables. Chaque fichier est rejouable sans risque (if not exists, drop … if exists).

Scripts

Commande	Rôle
npm run dev	serveur de développement
npm run build	build de production
npm run lint	ESLint
npm run typecheck	TypeScript sans émission
npm run test	Vitest (logique métier, i18n, sécurité)
npm run db:push	pousse le schéma Drizzle vers la base (DDL uniquement)
npm run db:generate	génère les migrations Drizzle

L'accès aux données passe par le client Supabase (@/lib/supabase/server en session, @/lib/supabase/admin côté serveur après contrôle explicite) ; Drizzle ne sert qu'à créer le schéma, jamais à requêter.

Structure

src/
├── app/
│   ├── (fr)/         parcours français : landing, catalogue, commandes,
│   │                 messages, litiges, dashboard, back-office /admin
│   ├── (en)/en       version anglaise : accueil, auth, CGU
│   └── api/          auth, paiements, webhooks GeniusPay, uploads, export RGPD, cron 72 h
├── components/       landing, catalogue, commandes, dashboard, admin, auth
│   └── dashboard/pro.tsx  kit premium des espaces connectés (pastilles, stats,
│                     sections, tableaux, bandeaux) — client-safe, sans requête
├── content/          contenus éditoriaux (landing, CGU)
├── db/schema.ts      schéma Drizzle, source du DDL (jamais requêté)
├── i18n/             dictionnaires FR/EN par domaine
├── lib/
│   ├── money.ts      arithmétique monétaire en entiers
│   ├── escrow.ts     machine à états de la commande
│   ├── order-ledger.ts  écritures du journal + compteurs prestataire
│   ├── packages.ts   validation des forfaits
│   ├── payments/     contrat PaymentProvider + GeniusPay
│   └── supabase/     clients session, navigateur et service
└── proxy.ts          CSP + langue + rafraîchissement de session
supabase/migrations/ RLS, fonctions SQL, buckets, seeds de démo

Charte des espaces connectés

Les tableaux de bord, le back-office et les parcours de commande partagent un même vocabulaire visuel, défini à deux endroits seulement :

• src/app/globals.css — les briques : .btn-primary / .btn-gold / .btn-secondary / .btn-ghost / .btn-danger / .btn-success / .btn-warn (+ .btn-sm), .card et .card-pad, .chip et .chip-active, .notice et ses quatre tons, .input, le bandeau .hero-band. Les couleurs passent par des tokens (--tone-*, --action-*, rampes --color-brand-* et --color-gold-*) : aucun bg-red-500 en dur, le mode sombre suit tout seul.
• src/components/dashboard/pro.tsx — les composants : Pill et ses fonctions de ton (orderTone, serviceTone, payoutTone, disputeTone, kycTone, roleTone), ProStat, MiniStat, Section, TableCard, FilterTabs, Notice, QuickAction, Avatar, ProgressBar.

/charte affiche toutes ces briques sur une seule page, sans base de données (la route n'existe pas en production) : c'est l'écran de contrôle avant d'habiller une nouvelle page, mode clair comme sombre.

Points ouverts connus

• Versements : l'API marchand GeniusPay n'expose pas de payout. Les demandes créent des lignes queued, pilotées dans /admin/payouts (prise en charge → paiement mobile money hors app → marquage payé/échec, avec écritures payout/refund au journal). Reste : le payout automatique quand un partenaire l'exposera.
• Demandes de contact : lues et répondues dans /demandes (conversations par prestation, accusés de lecture), avec notification in-app à chaque message. Reste : notifier hors app (e-mail ou push) — aucun canal externe pour l'instant.
• Parité EN : toute la vitrine suit le cookie de langue (/en* = points d'entrée anglais garantis, lang/hreflang dynamiques, sitemap + robots). Le login et le sélecteur du header synchronisent preferred_locale dans les deux sens. Choix assumé : pas de miroirs /en/* pour les pages internes (coût SEO/maintenance) — réévaluer à l'expansion anglophone.
• Juridique : qualification du séquestre (instruction BCEAO n°001-01-2024) et accord écrit du partenaire de rétention, toujours à obtenir.