Holi — Whitepaper Synthèse

0) Executive summary

Holi adresse un problème concret: transformer une planification voyage familiale/groupe fragmentée en plan journalier exécutable et adaptable[R1]. Le verdict opérationnel reste GO conditionnel, avec discipline de scope et validation métrique stricte.

1) Problème utilisateur et segment cible

1.1 Problème central

La friction principale observée n’est pas l’inspiration destination, mais la fragmentation des contraintes et l’arbitrage collectif (enfants, timing, météo, énergie, fermetures)[R1].

1.2 Segment prioritaire

• Prioritaire: familles avec enfants (densité de contraintes la plus forte)[R3].
• Secondaire: groupes d’amis (alignement de préférences et coordination)[R4].

1.3 JTBD

« Aidez-nous à converger vite vers un plan du jour faisable pour tout le groupe, avec plan de secours quand la réalité change. »

2) Marché, concurrence et substituts

• Les planificateurs existants couvrent déjà une part du besoin (Wanderlog, Roadtrippers, Sygic)[R5].
• Les plateformes cartes sont des substituts puissants pour découverte/navigation, mais pas pour arbitrage collaboratif explicite[R6].
• Les assistants IA accélèrent la génération d’itinéraires et augmentent le risque de commoditisation[R7].

Implication: Holi gagne uniquement avec un wedge clairement défendable et une exécution orientée contraintes réelles[R2].

3) Proposition de valeur et produit V1

Holi convertit des contraintes hétérogènes en plan journalier partagé et replanifiable.

In-scope V1

1. Onboarding + profil voyage
2. QCM contraintes hard/soft
3. Swipe collaboratif + signal consensus/conflit
4. Modes Planning / Travel
5. Chatbot borné au contexte de contraintes
6. Sortie plan A / plan B

Out-scope V1

• Booking end-to-end
• Feed inspiration social
• Géoloc continue par défaut

Base de design: synthèses TASK-131 et claims C-121 à C-123.

4) Modèle business et monétisation

Trajectoire recommandée: V1 freemium + affiliation contextuelle, puis premium en montée, sponsorisation POI uniquement après validation trust[R8].

La stratégie reste conditionnée par des tests terrain sur CTR/CVR/churn et perception de biais commercial[R9].

5) Faisabilité technique et conformité

• Collaboration realtime: faisable (Supabase/Firebase patterns documentés)[R10].
• Telegram-first: voie d’intégration pragmatique en V1[R11].
• Conformité localisation: opt-in explicite, retrait simple, mode borné uniquement[R12].

6) Risques majeurs

1. Commoditisation IA si perte du wedge.
2. Friction onboarding si QCM surchargé.
3. Perte de confiance si densité commerciale trop tôt.
4. Risque policy/privacy si géoloc élargie sans garde-fous.

7) Hypothèses critiques à valider

• A-105: friction QCM acceptable vs valeur perçue
• A-106: acceptation géoloc bornée
• A-107: valeur exécution Telegram-first
• A-109: hybride freemium+affiliation monétise tôt sans casser la confiance
• A-110: seuil de sponsorisation acceptable

8) Décision et gates du POC

Décision: GO POC 8 semaines, avec revue go/no-go stricte.

KPI gates

• Activation ≥35% des groupes avec shortlist partagée
• Collaboration ≥60% des groupes avec ≥2 participants actifs
• Signal monétisation: CTR affilié utile (8–12%) [À VÉRIFIER]
• Satisfaction: signal majoritaire de gain de temps

Règle: ≥3/4 KPI = GO phase 2; sinon NO-GO/pivot.

9) Références

1. R1 — C-101/C-103/C-110/C-118 (SOURCE-REGISTRY): artefact primaire montrant la fragmentation des contraintes et la charge d’orchestration. Source: opportunity/SOURCE-REGISTRY.yaml.
2. R2 — C-117/C-120: verdict stratégique « wedge constraint-first + collaboration », condition de poursuite produit. Source: opportunity/SOURCE-REGISTRY.yaml.
3. R3 — C-102/C-109: segment famille comme lead segment le plus robuste. Source: opportunity/SOURCE-REGISTRY.yaml.
4. R4 — C-111: segment secondaire groupes d’amis (coordination). Source: opportunity/SOURCE-REGISTRY.yaml.
5. R5 — C-113: positionnement concurrents planning. Sources vérifiées accessibles: sygic.com/travel, roadtrippers.com. (Wanderlog signalé indisponible lors de l’audit du 2026-04-10.)
6. R6 — C-114: substituts maps. Sources: google.com/maps, maps.me.
7. R7 — C-116: risque substitution IA conversationnelle. Sources: chatgpt.com, guidegeek.com.
8. R8 — C-134/C-135/C-136/C-138: faisabilité affiliation + contraintes store billing. Sources: GetYourGuide Partner, Google Play Billing, Apple Payments Guidelines, trivago advertising.
9. R9 — A-109/A-110: hypothèses de confiance et performance commerciale à valider en pilote. Source: opportunity/ASSUMPTIONS.md.
10. R10 — C-124/C-125: patterns realtime collaboration. Sources: Supabase Realtime, Firestore real-time queries at scale.
11. R11 — C-130/C-131: faisabilité intégrations Telegram/WhatsApp sandbox. Sources: Telegram Bot API, Twilio WhatsApp.
12. R12 — C-126/C-127/C-128/C-129: contraintes privacy/policy sur la géolocalisation. Sources: Apple CoreLocation, Google Play background location, EU consent withdrawal, EFF location privacy.

Traçabilité complète: SOURCE-REGISTRY.yaml, sources-verified.md, WHITEPAPER-V1.md.