Holi deliverablesFull knowledgeSwitch to Human versionHome

Version complète: contexte, analyses, hypothèses, risques, traçabilité des sources.

Holi — Final Whitepaper Master

Date: 2026-04-09

Version: final-v1

Owner: Isaak

Navigation des livrables

Convention de publication

Contenu master (base analytique)

Holi — Whitepaper v1

Date: 2026-04-09

Version: v1 (draft review)

Owner: Isaak

0) Executive summary

Holi vise un problème concret: transformer une planification de voyage familiale/groupe, aujourd’hui fragmentée et mentale, en plan journalier exécutable et adaptable.

Le verdict de cette V1 est **go conditionnel** sur une stratégie produit stricte:

  1. **Wedge non-négociable**: planification *constraint-first* + arbitrage collaboratif (pas un simple “chatbot voyage”).
  2. **MVP cadré**: onboarding/QCM, swipe collaboratif, modes Planning/Travel, chatbot borné, plan A/B.
  3. **Monétisation progressive**: freemium + affiliation contextuelle en V1, premium en montée, sponsorisation POI seulement en test contrôlé.
  4. **Conformité by design**: géoloc continue non-default (opt-in borné), consentement/rétractation symétriques, messagerie séquencée Telegram-first.

Sans ce cadrage, Holi tombe dans la commoditisation (ChatGPT + Maps + outils existants).

1) Problème utilisateur et segment cible

1.1 Problème central

Le problème principal n’est pas le manque d’idées de destinations; c’est la **fragmentation des contraintes** et la difficulté d’arbitrage en groupe/famille (C-101, C-103, C-110, C-118).

1.2 Segment prioritaire

1.3 Job-to-be-done (résumé)

"Aide-nous à converger vite vers un plan du jour réalisable pour tout le monde, avec plan de secours quand la réalité change."

2) Marché, concurrence et substituts

2.1 Paysage

2.2 Implication stratégique

Les alternatives couvrent déjà l’inspiration et une partie de la planification. La différenciation Holi n’est viable que si la proposition reste:

3) Proposition de valeur et produit V1

3.1 Proposition de valeur

Holi convertit des contraintes hétérogènes (enfants, fatigue, météo, timing, réservations) en un plan journalier exécutable, partagé, et replanifiable.

3.2 Périmètre V1 (in)

  1. Onboarding + profil voyage
  2. QCM contraintes (hard/soft)
  3. Swipe collaboratif + résolution de conflits
  4. Planning mode + Travel mode
  5. Chatbot borné au contexte de contraintes
  6. Sortie plan A / plan B par bloc critique

3.3 Kill-list V1 (out)

Références: C-121, C-122, C-123.

4) Modèle business et monétisation

4.1 Stack recommandée

4.2 Pourquoi ce choix

4.3 Limites explicites

Les paramètres unit economics (CTR/CVR/take-rate/churn) restent des estimations tant qu’ils ne sont pas testés sur pilotes réels.

5) Faisabilité technique et conformité

5.1 Faisabilité

5.2 Géolocalisation continue (point sensible)

6) Risques majeurs

  1. **Commoditisation IA** si Holi devient un planner générique (H)
  2. **Friction onboarding** si QCM trop long (H, A-105)
  3. **Risque confiance** si sponsorisation POI perçue comme biaisée (H, A-110)
  4. **Risque conformité/policy** sur géoloc continue (H, C-126..C-129)
  5. **Dépendance partenaires** pour l’affiliation (H, A-109)

7) Hypothèses critiques à valider

Toutes les hypothèses et deadlines sont tracées dans ASSUMPTIONS.md.

8) Décision v1 (pré-TASK-135)

**Décision de ce whitepaper v1:** poursuivre vers la recommandation finale (TASK-135) avec un **go conditionnel**.

Conditions minimales:

  1. MVP reste strictement dans le wedge défendable.
  2. Monétisation commerciale reste progressive et contrôlée.
  3. Conformité privacy/store est traitée comme contrainte de design, pas comme patch tardif.

Si une de ces conditions est abandonnée, la recommandation doit pivoter vers **no-go / hold**.

9) Références et traçabilité

Note méthodologique: plusieurs sites travel majeurs sont partiellement bloqués en extraction automatisée dans cet environnement; les claims détaillés non robustes ont été évités ou explicitement marqués comme estimations (C-119, C-139).

Recommandation finale et gates POC

Holi — Recommandation stratégique finale (TASK-135)

Décision explicite

**GO pour un POC cadré (8 semaines), puis go/no-go strict.**

Le POC ne vise pas la scale, il vise la **preuve de traction collaborative** sur un segment précis, avec instrumentation de conversion et signal de rétention.

Pourquoi ce choix

Sur base des livrables TASK-129 à TASK-134:

Scope du POC (8 semaines)

In-scope

  1. Onboarding + QCM préférences
  2. Swipe collaboratif simple (petits groupes)
  3. Plan de voyage partagé minimal (décisions + shortlist)
  4. Canal Telegram (prioritaire), WhatsApp reporté
  5. Tracking analytics minimal: activation, shortlist, action partenaire

Out-of-scope

KPI de validation (gates)

Décision à 8 semaines:

Si <2 KPI sur 4 atteints: **NO-GO / pivot fort**.

Si ≥3 KPI sur 4 atteints: **GO phase 2** (durcissement produit + canaux).

Risques principaux à surveiller

  1. Produit trop large trop tôt → dilution de valeur
  2. Dépendance acquisition payante prématurée
  3. Dette conformité si géoloc/messagerie élargies trop vite
  4. “Feature creep” hors thèse collaboration

Recommendation opératoire

Traceability

Synthèse dérivée de:

Annexes sources

Holi — Annexes sources & hypothèses (TASK-134)

Date: 2026-04-09

A) Sources externes utilisées (URLs vérifiées)

Concurrence / positionnement

Faisabilité technique / conformité

Monétisation / marché

> Vérification: voir sources-verified.md (statut reachable/protected).

B) Sources non-web (primaires)

C) Claims de référence utilisés dans WHITEPAPER-V1.md

D) Hypothèses structurantes encore ouvertes

E) Points d’incertitude explicitement assumés