Dossier d'Analyse Fonctionnelle — MVP1#

Plateforme matrimoniale de confiance inspirée de la Khetaba marocaine#

Nom de code produit : (à définir — pistes : « Khtoba », « Amana », « Wsila », « Nseeb »)

Version du document : 1.0

Date : 9 août 2026

Auteur : Product Management / Business Analysis

Statut : Draft pour validation avant phase UX/UI → Architecture → Backlog → Dev MVP1

⚠️ Préambule — Challenge critique du concept (à lire avant tout)#

Cette section n'est pas de la complaisance. Comme demandé (§33), elle challenge le concept avant de dérouler le dossier. Si ces points ne sont pas traités, le produit échouera quelle que soit la qualité d'exécution.

Les 5 risques mortels du concept#

1. Le paradoxe du démarrage à froid (cold start) est ici plus violent que sur une app de dating classique.

Une app matrimoniale « peu de profils mais très compatibles » n'a de valeur QUE si le pool de profils est suffisamment dense pour que le matching trouve réellement des correspondances. Or votre proposition de valeur (« 3 profils ultra-compatibles ») exige un bassin large dès le départ. C'est contradictoire : au lancement vous aurez 200 profils dans une ville, dont peut-être 4 femmes de 28-32 ans à Casablanca cherchant un profil donné. Le matching « intelligent » ne pourra rien proposer. Mitigation obligatoire : lancer sur une niche géographique + démographique ultra-concentrée (ex. Marocains de Belgique/France 27-38 ans), et non « le Maroc et la diaspora ». Densité > couverture.

2. La barrière de vérification d'identité forte VA réduire drastiquement le taux de conversion à l'inscription.

Demander une pièce d'identité + selfie vidéo + liveness AVANT de laisser voir quoi que ce soit fera fuir 60-80 % des inscrits (benchmarks KYC fintech). L'hypothèse H1 (« les utilisateurs acceptent une vérification forte ») est l'hypothèse la plus risquée du produit. Recommandation : ne pas imposer la vérification identité en amont. La rendre progressive et contextuelle — on peut créer son profil et explorer, mais on ne peut pas être proposé ni contacter sans « Identité vérifiée ». La vérification devient une clé qui déverrouille de la valeur, pas un péage à l'entrée. (Voir §9 Parcours et §11 Trust.)

3. Le sujet CNDP / données biométriques est un risque juridique bloquant au Maroc, pas un détail RGPD.

Le traitement de données biométriques (liveness, reconnaissance faciale pour anti-deepfake) et le scoring de personnes relèvent d'une autorisation préalable de la CNDP (loi 09-08), pas d'une simple déclaration. Un « Trust Score » sur des personnes physiques est juridiquement sensible. Recommandation MVP1 : externaliser le KYC/liveness à un prestataire certifié (le prestataire porte une partie de la conformité biométrique) et NE PAS stocker les documents d'identité en clair côté produit — ne conserver qu'un statut « vérifié » + hash + référence prestataire. Consulter un juriste CNDP avant le développement, pas après.

4. « Trust Score » visible = risque de dérive discriminatoire ET de gaming.

Un score affiché crée une hiérarchie sociale (les « bas scores » deviennent des parias), incite au gaming, et sera perçu comme une notation des personnes — culturellement explosif sur un sujet aussi intime que le mariage. Recommandation forte : ne PAS afficher de score chiffré aux autres utilisateurs. Afficher un « Trust Passport » à badges (Identité ✓, Téléphone ✓, Vidéo ✓, Référent ✓) — binaire, factuel, non hiérarchisant. Garder un score numérique interne uniquement pour la modération et le classement de matching. (Voir §11.)

5. Le risque « Tinder avec vérification » est réel et le vrai différenciateur n'est PAS la techno mais le RITUEL.

La vérification est copiable en 6 mois par un concurrent. Ce qui ne l'est pas : le parcours progressif orienté intention matrimoniale (valeurs avant photo, mise en relation par paliers, implication possible d'un référent/famille) et la curation (peu de profils, sérieux imposé par la friction). Le moat = friction assumée + rituel culturel + réputation de sérieux. Tout le produit doit protéger cet actif.

Points faibles secondaires à surveiller#

• Déséquilibre de genre : les plateformes matrimoniales attirent structurellement plus d'hommes que de femmes. Sans les femmes, produit mort. → prévoir un traitement asymétrique (gratuité/priorité côté femmes, modération anti-harcèlement stricte) dès le MVP.
• Coût unitaire du KYC : chaque vérification identité coûte ~0,3–1,5 € chez un prestataire. À l'échelle, ça pèse. → modèle économique doit l'absorber (verification premium payante, ou vérification légère au MVP).
• Liveness/anti-deepfake fiable = cher et non-trivial. Ne pas le sur-promettre au MVP1. Un liveness passif basique + revue humaine suffit pour tester le concept.

Décision structurante recommandée pour le MVP1#

Ne pas construire tout l'arbre de confiance à 7 niveaux. Le MVP1 doit prouver 3 hypothèses avec le minimum de machinerie. On garde : Email + Téléphone + Identité (KYC externalisé) + Profil complet + Référent optionnel. On reporte en MVP2 : entretien vidéo de vérification, IA anti-deepfake avancée, Khetaba certifiée. Le reste du dossier applique cette ligne.

1. Executive Summary#

Le produit. Une plateforme de mise en relation matrimoniale (web + mobile) qui digitalise le rôle traditionnel de la Khetaba marocaine (entremetteuse de confiance). Elle s'adresse d'abord aux Marocains et à la diaspora maghrébine cherchant un mariage sérieux, avec une architecture conçue pour une extension internationale ultérieure.

Le problème. Les apps de rencontre (Tinder, Bumble, Badoo) et même les apps « communautaires » (Muzz) souffrent de faux profils, d'usurpation, de superficialité basée sur la photo, de scams sentimentaux et d'un manque de sérieux. Sur un sujet aussi engageant que le mariage, l'absence de confiance est rédhibitoire.

La proposition de valeur. « Moins de profils, mais des profils réels, sérieux et réellement compatibles. » Trois piliers non négociables : TRUST (la personne est réelle et vérifiée), COMPATIBILITY (elle correspond à un vrai projet de vie), INTENTION (elle cherche vraiment le mariage).

Le différenciateur. Ce n'est pas « Tinder + KYC ». C'est un rituel numérique : vérification progressive, découverte des profils par les valeurs avant la photo, matching explicable (pas une boîte noire), mise en relation par paliers volontaires, et possibilité d'impliquer un référent de confiance (préfiguration de la Khetaba 2.0).

Le périmètre MVP1. Prouver 3 hypothèses : (H1) les gens acceptent une vérification forte si elle déverrouille de la valeur ; (H2) ils préfèrent peu de profils très compatibles ; (H3) la confiance améliore la qualité des échanges. Le MVP1 embarque : onboarding + vérifications (email, téléphone, identité KYC externalisée), profil structuré + questionnaire valeurs/personnalité, Trust Passport à badges, matching curé (3-5 profils/jour, explicable), mise en relation progressive avec messagerie sécurisée, anti-scam basique, modération hybride, back-office. Sont reportés : entretien vidéo de vérification, IA anti-deepfake, Khetaba certifiée, appels audio/vidéo in-app (voir arbitrage section 14).

Recommandation clé. Lancer sur une niche dense (ex. diaspora maghrébine en Europe, 27-38 ans) plutôt que « tout le Maroc + diaspora », pour résoudre le cold start. Externaliser le KYC. Ne pas afficher de score chiffré. Sécuriser la conformité CNDP avant le dev.

2. Vision du produit#

Vision (3-5 ans). Devenir la référence de la mise en relation matrimoniale de confiance pour le monde maghrébin et sa diaspora, puis pour toute communauté partageant une approche matrimoniale sérieuse (Sud-asiatique, Moyen-Orient, communautés religieuses pratiquantes) en créant une nouvelle catégorie : la Trusted Matrimonial Platform / Digital Khetaba.

Mission. Redonner aux personnes qui cherchent sincèrement à se marier un environnement sûr, digne et efficace, en remplaçant l'incertitude et la superficialité par la confiance et la compatibilité réelle.

Ce que le produit N'EST PAS :

• une app de dating / rencontres sans lendemain ;
• un catalogue de photos à swiper ;
• un lieu de conversations multiples sans objectif.

Ce que le produit EST :

• un tiers de confiance numérique qui vérifie, filtre et met en relation avec intention matrimoniale ;
• un parcours ritualisé qui respecte le sérieux de la démarche et, à terme, la place de la famille et de la Khetaba.

North Star Metric candidate : nombre de mises en relation « de qualité » par mois (= match mutuel entre deux profils vérifiés ayant échangé au-delà d'un seuil), plutôt que le nombre d'inscrits ou de messages (métriques de vanité pour ce produit).

3. Problématique#

3.1 Problèmes des solutions existantes#

3.2 Insight central#

Sur le marché du mariage, l'incertitude sur l'autre (est-elle réelle ? sérieuse ? compatible ?) est un coût psychologique majeur. Traditionnellement, la Khetaba absorbait ce coût : elle connaissait les familles, garantissait le sérieux, présélectionnait. La digitalisation a supprimé ce tiers de confiance sans le remplacer. Le produit réintroduit ce tiers de confiance sous forme numérique.

3.3 Hypothèses à valider (les vraies questions du MVP)#

• H1 - Adoption de la friction : les utilisateurs acceptent-ils une vérification forte ? (hypothèse la plus risquée)
• H2 - Curation vs abondance : préfèrent-ils 3 profils très compatibles à 300 profils à swiper ?
• H3 - Confiance -> qualité : la confiance augmente-t-elle réellement la qualité des échanges et le passage à la rencontre ?

4. Proposition de valeur#

4.1 Énoncé principal#

« On ne commence pas par regarder quelqu'un. On commence par savoir si cette personne est réelle, sérieuse et compatible. »

Moins de profils, mais des profils fiables et réellement compatibles.

4.2 Value Proposition Canvas (synthèse)#

Douleurs adressées (Pains) : peur des faux profils, peur des arnaques, fatigue du swipe, honte/stigmatisation des apps de dating, perte de temps avec des non-sérieux, insécurité (surtout les femmes), difficulté d'impliquer la famille.

Gains recherchés (Gains) : trouver un(e) conjoint(e) sérieux(se) et compatible, dans un cadre digne et respectueux, avec un sentiment de sécurité, un gain de temps (curation), et la possibilité d'un cadre familial/traditionnel.

Créateurs de valeur (Gain creators) : vérification multi-niveaux, Trust Passport, matching explicable orienté valeurs, mise en relation progressive, référent de confiance, anti-scam intégré.

Réducteurs de douleur (Pain relievers) : badges de vérification, absence de swipe, profils limités/jour, coordonnées jamais exposées, modération humaine, alertes anti-arnaque.

4.3 Différenciateurs défendables (le moat)#

1. Rituel de confiance progressif (copiable techniquement, difficile à copier culturellement et en réputation).
2. Réputation de sérieux (effet marque : « ici les gens sont vrais et cherchent le mariage »).
3. Curation par la friction (moins mais mieux) - contre-intuitif, donc difficile à imiter pour un acteur habitué au volume.
4. Écosystème Khetaba/famille (barrière future : réseau de Khetabas certifiées = actif inimitable).
5. Compétence conformité (maîtrise CNDP/RGPD/biométrie = barrière opérationnelle réelle).

5. Personas#

Persona 1 - Salma, 30 ans, Casablanca (cœur de cible national)#

Cadre marketing, diplômée, pratiquante modérée. A testé des apps de dating, dégoûtée par le harcèlement et les profils non sérieux. Veut se marier dans les 2 ans. Cherche la sécurité et le sérieux. Sensible à la confidentialité (peur du regard social). Besoin clé : se sentir en sécurité et respectée ; ne pas être « exposée ».

Persona 2 - Yassine, 34 ans, Bruxelles (cœur de cible diaspora)#

Ingénieur, MRE 2e génération. Veut une conjointe partageant valeurs et culture, difficile à trouver localement. Prêt à un mariage transnational. Fatigué des présentations familiales hasardeuses. Besoin clé : accéder à un pool sérieux et culturellement compatible sans dépendre uniquement du réseau familial.

Persona 3 - Nadia, 41 ans, Lyon (diaspora, seconde union)#

Divorcée, un enfant. Cherche une union sérieuse et respectueuse de sa situation. Craint les jugements et les profils qui « perdent son temps ». Besoin clé : filtres fins (situation familiale, enfants) et interlocuteurs matures et vérifiés.

Persona 4 - Karim, 28 ans, Rabat (jeune sérieux)#

Jeune actif, veut se marier « bien » mais n'aime pas les apps de dating (contraire à ses valeurs). Serait rassuré par un cadre sérieux qu'il pourrait présenter à sa famille. Besoin clé : légitimité morale/culturelle de la démarche.

Persona 5 (secondaire, MVP2) - Lalla Fatima, Khetaba professionnelle#

Entremetteuse reconnue localement. Veut digitaliser son activité, accéder à des candidats vérifiés, gérer son portefeuille. Persona d'écosystème, hors périmètre MVP1 mais l'architecture doit l'anticiper.

Persona 6 (secondaire) - Le Référent (parent/frère/ami de confiance)#

Impliqué à la demande du candidat pour attester de son sérieux. Rôle optionnel, périmètre MVP1 limité (attestation), extensions en MVP2.

Anti-persona (à exclure/décourager) : le chercheur de rencontres sans intention de mariage, le harceleur, le scammeur, le curieux non vérifiable.

6. Analyse concurrentielle#

6.1 Cartographie#

6.2 Positionnement concurrentiel (le « white space »)#

Muzz est le concurrent le plus proche mais reste une app de swipe avec vernis matrimonial. Les sites matrimoniaux traditionnels ont l'intention mais pas la vérification moderne ni la diaspora maghrébine. La Khetaba a la confiance totale mais ne scale pas.

Le territoire vacant : la combinaison [vérification forte moderne] × [matching explicable orienté valeurs] × [rituel progressif] × [ancrage culturel maghrébin/diaspora] × [préfiguration Khetaba/famille]. Personne n'occupe ce croisement.

6.3 Différences fondamentales vs dating classique#

• On ne swipe pas ; on découvre par paliers (valeurs -> personnalité -> projet -> photo).
• On ne peut pas contacter sans vérification + intérêt réciproque.
• Le matching est explicable (« pourquoi ce profil »), pas une boîte noire à photos.
• Les coordonnées personnelles ne fuient jamais.
• La famille/le référent peut entrer dans la boucle (impensable sur Tinder).

7. Positionnement#

Catégorie créée : Trusted Matrimonial Platform — « Digital Khetaba ».

Phrase de positionnement :

Pour les personnes qui cherchent sincèrement à se marier et en ont assez des apps de rencontre superficielles et risquées, [Produit] est la plateforme matrimoniale de confiance qui vérifie chaque personne, ne propose que des profils réellement compatibles, et accompagne la mise en relation par étapes — là où les apps de dating misent sur le volume et la photo, nous misons sur la confiance, la compatibilité et l'intention.

Territoire de marque : sérieux, dignité, sécurité, respect, modernité assumée mais ancrée dans la tradition (la Khetaba comme héritage revalorisé, pas ringardisé).

Ton & code culturel : ni religieux excluant, ni occidentalisé déraciné. Culturellement pertinent mais techniquement universel (valeurs paramétrables, pas figées sur une seule culture -> extension internationale).

Ce qu'on refuse dans le positionnement : tout code visuel/verbal de « dating » (flammes, swipe, « match tonight », gamification de la séduction). Chaque écran doit signaler sérieux et sécurité.

8. Principes fondateurs#

Ces principes sont des contraintes de conception : toute décision produit doit s'y conformer.

1. TRUST FIRST. Aucune interaction entre utilisateurs sans qu'ils soient réels et vérifiés. La confiance précède la découverte.
2. INTENTION FIRST. Tout le produit filtre pour l'intention matrimoniale sérieuse. La friction est un feature, pas un bug : elle éloigne les non-sérieux.
3. COMPATIBILITY OVER ATTRACTION. On présente les valeurs et le projet de vie avant la photo. Le matching optimise la compatibilité, pas l'attractivité.
4. CURATION OVER ABUNDANCE. Peu de profils, choisis, expliqués. Pas de swipe infini.
5. PROGRESSIVE DISCLOSURE. Découverte du profil ET escalade du contact par paliers volontaires. Rien ne se dévoile trop vite (ni la photo, ni les coordonnées).
6. EXPLAINABILITY. Le matching et la confiance sont explicables (« pourquoi ce profil », « pourquoi ce badge »). Pas de boîte noire.
7. PRIVACY BY DESIGN & BY DEFAULT. Séparation stricte identité / profil. Les données sensibles ne sont jamais visibles par les autres. Minimisation.
8. DIGNITY & NON-DISCRIMINATION. Pas de score public hiérarchisant. Respect de la personne, notamment des femmes et des profils en seconde union.
9. SAFETY BY DEFAULT. Anti-scam et anti-harcèlement activés par défaut, protection asymétrique du genre le plus exposé.
10. CULTURALLY ROOTED, TECHNICALLY UNIVERSAL. Ancrage maghrébin dans l'expérience, généricité dans l'architecture (valeurs/critères paramétrables).

9. Parcours utilisateur#

9.1 Parcours nominal candidat (happy path)#

1. Découverte / Splash -> valeur affichée : « la plateforme matrimoniale de confiance ».
2. Onboarding (3-4 écrans) : explique TRUST / COMPATIBILITY / INTENTION et la démarche par étapes.
3. Inscription (email + mot de passe, ou téléphone). Consentements RGPD/CNDP explicites.
4. Vérification email (lien/OTP).
5. Vérification téléphone (OTP SMS). Numéro jamais visible publiquement.
6. Création du profil structuré (identité déclarative, vie pro, vision du mariage).
7. Questionnaire valeurs & personnalité (guidé, découpé, sauvegarde progressive).
8. Définition des critères (indispensables / importants / secondaires / rédhibitoires).
9. Vérification d'identité (KYC externalisé) : document officiel + selfie + liveness passif. Déclenchée au moment où l'utilisateur veut être proposé/contacter — pas à l'inscription.
10. Constitution du Trust Passport (badges obtenus).
11. Validation du profil (auto-complétude + éventuelle revue humaine si signaux).
12. Réception des propositions (3-5 profils compatibles, expliqués).
13. Découverte progressive d'un profil (valeurs -> personnalité -> projet -> compatibilité -> photo).
14. Action : Intéressé(e) / Pas pour moi / Demander une mise en relation.
15. Match (intérêt réciproque). ⚠️ PAS de messagerie texte : le match n'ouvre aucune conversation écrite.
16. Proposition de call in-app — seule action possible pour faire progresser la relation (call-first strict). Tant qu'un call n'est pas accepté par les deux, le match reste en attente (ni texte, ni coordonnées).
17. Planification du call : les deux acceptent, un créneau est confirmé.
18. Call audio/visio in-app (WebRTC chiffré, coordonnées masquées, conseils de sécurité). Le call est l'unique porte d'entrée de la relation — cf. §14.2. No-show / refus répété = signal anti-scam.
19. Déblocage des coordonnées après un call jugé concluant par les deux, à double consentement (rappel sécurité, événement tracé, révocable).
20. Poursuite hors-app & rencontre réelle (avec conseils de sécurité) et, en option, implication du référent/famille.

9.2 Exceptions et cas d'erreur (à traiter)#

9.3 Décision de conception : quand imposer le KYC ?#

Option A — KYC en amont (avant profil). Confiance maximale du pool. Contre : effondrement du taux de conversion (H1 en danger).

Option B — KYC contextuel (recommandé). L'utilisateur crée son profil et explore, mais ne peut être proposé ni contacter sans « Identité vérifiée ». Le KYC devient une clé de valeur, pas un péage.

Recommandation : Option B. Elle teste H1 sans tuer l'entrée, et aligne friction et valeur perçue.

10. Fonctionnalités MVP1 (priorisation MoSCoW)#

Pour chaque item : Priorité | Valeur utilisateur | Complexité | Dépendances | Justification (pourquoi inclus/exclu).

MUST HAVE (le MVP ne fonctionne pas sans)#

SHOULD HAVE (fortement souhaitable, arbitrable selon budget/temps)#

COULD HAVE (si temps résiduel)#

OUT OF SCOPE (explicitement hors MVP1)#

11. Trust & Identity#

11.1 Les niveaux de confiance (arbitrage MVP1)#

11.2 Trust Passport (recommandation vs Trust Score affiché)#

Problème du score chiffré : hiérarchisation sociale, gaming, perception de « notation des personnes » — inacceptable culturellement et risqué juridiquement (§ préambule risque 4).

Recommandation : Trust Passport à badges (public) + Trust Score numérique (interne only).

• Public (visible par les autres) : badges binaires factuels — Identité vérifiée, Téléphone vérifié, Email vérifié, Profil complet, Référent confirmé. Pas de note, pas de classement affiché.
• Interne (invisible, réservé matching + modération) : un score 0-100 servant à ordonner les propositions et prioriser la modération.

11.3 Méthodologie de calcul du Trust Score interne (proposition)#

Score = somme pondérée de composantes, borné 0-100, avec plancher/plafond pour éviter la discrimination.

Principes anti-discrimination :

• Le score ne mesure jamais l'attractivité ; uniquement la fiabilité.
• Transparence : l'utilisateur voit ses propres badges et comment les améliorer (« ajoute un référent »), mais pas un chiffre stigmatisant.
• Explicabilité : toute pénalité majeure = notification + motif + recours.
• Non-visibilité croisée : on ne montre jamais le score interne d'autrui.
• Le score alimente le ranking et la priorité de modération, pas un rejet automatique brutal (revue humaine sur les cas limites).

11.4 Données visibles vs jamais visibles#

• Visibles par les autres : prénom/pseudonyme, âge, ville (grain large), profession/secteur, éléments de profil déclarés, badges du Trust Passport, photo (selon paliers).
• JAMAIS visibles par les autres : document d'identité, selfie/liveness, numéro de téléphone, email, adresse précise, score interne, historique de modération, données du référent.

12. Anti-fraude (faux profils) & Anti-scam#

Section stratégique. On distingue deux menaces : (A) faux profils / usurpation d'identité et (B) scams sentimentaux / arnaques.

12.1 Menaces et défenses (faux profils)#

12.2 Anti-scam sentimental (signaux) — MVP1 basique mais présent#

Signaux détectables : demande d'argent, urgence financière, histoire émotionnelle stéréotypée, poussée rapide vers WhatsApp/Telegram, refus systématique de visio, incohérences, pression émotionnelle, demande de documents personnels ou de données bancaires, partage rapide de coordonnées.

Mécanisme MVP1 :

1. Masquage automatique des numéros/emails/liens dans la messagerie (regex + variantes obfusquées) → « Le partage de coordonnées est protégé à ce stade. »
2. Détection de mots-clés/patterns (argent, virement, IBAN, « aide-moi financièrement », urgence) → bannière d'alerte non bloquante : « Cette conversation présente des signaux pouvant indiquer une arnaque. Ne partagez jamais d'argent ni de coordonnées bancaires. »
3. Éducation contextuelle : rappels de sécurité au 1er message, avant 1re rencontre.
4. Signalement 1-clic contextualisé (« demande d'argent », « harcèlement », « faux profil »…).

Éviter les faux positifs : l'alerte est informative, pas un bannissement automatique. La sanction (suspension/ban) passe par confirmation humaine ou accumulation de signaux forts. Seuils calibrés et révisables via back-office.

12.3 Parcours d'un profil suspect#

Détection (auto ou signalement) → Statut « en revue » (accès restreint : ne peut plus être proposé/contacter) → Analyse humaine (back-office) → Décision : OK / vérification renforcée / suspension / ban → Notification motivée à l'utilisateur → Recours possible.

Principe : présomption de bonne foi sauf signaux forts ; proportionnalité ; traçabilité de chaque décision (audit).

13. Matching#

13.1 Principes#

• Pas de swipe, pas d'infini. Le système pousse un nombre limité de profils (3-5/jour).
• Explicable : chaque proposition affiche « Pourquoi ce profil ».
• Gates durs d'abord, scoring ensuite.

13.2 Algorithme (approche recommandée : moteur de règles pondérées, PAS de ML au MVP1)#

Justification : pas de données d'entraînement au lancement ; besoin d'explicabilité ; un moteur de règles est transparent, ajustable en back-office et suffisant pour tester H2.

Étape 1 — Filtres durs (gates éliminatoires) :

• critères rédhibitoires de chaque partie respectés (des deux côtés) ;
• intention matrimoniale compatible (délai, enfants incompatibles = exclus) ;
• fourchette d'âge, périmètre géographique / mobilité, situation matrimoniale acceptée ;
• les deux profils vérifiés (Identité + complétude).

Étape 2 — Score de compatibilité (sur les survivants) :

Score = w1·Valeurs + w2·VisionMariage + w3·Personnalité + w4·ProjetFamilial + w5·Géo + w6·Préférences

• Valeurs : proximité sur les axes déclarés (famille, religion/pratique, finances, éducation…).
• Vision du mariage : délai, enfants (nombre), rôle pro, résidence, mobilité.
• Personnalité : mix similarité/complémentarité selon axe (communication, gestion de conflit…).
• Préférences pondérées par niveau (indispensable > important > secondaire).

Étape 3 — Sélection & diversité : on retient les meilleurs scores mais on plafonne à 3-5/jour et on introduit une légère diversité (éviter de ne montrer qu'un seul « type »). Réciprocité prise en compte (proposer aussi là où l'autre a des chances d'être intéressé).

13.3 « Pourquoi ce profil ? » (explication affichée)#

Exemple : « 4 valeurs communes (famille, fidélité, finances, éducation) · vision familiale compatible · même projet géographique · attentes similaires sur les enfants · personnalité complémentaire sur la communication. »

→ Généré à partir des composantes qui ont le plus contribué au score. Jamais de photo mise en avant dans l'explication.

13.4 Paramétrage#

Les poids w1..w6, les seuils, le nombre de propositions/jour sont configurables en back-office (pas en dur), pour itérer sans redéploiement.

13.5 Catalogue des critères de recherche — page dédiée : criteria.html#

Les critères de recherche sont les filtres que l'utilisateur active pour affiner ses propositions. Ils alimentent le matching (§13.2) et servent de levier d'offre (Basic 3 · Gold 9 · Diamond illimités, cf. §24.3).

Deux catégories :

• Socle (toujours actif, hors quota) : disponible pour toutes les offres, ne compte pas dans le quota. Garantit une base de compatibilité minimale et évite que Basic soit inutilisable.
• Affinement (compté dans le quota 3/9/∞) : l'utilisateur choisit lesquels activer, dans la limite de son offre.

Socle — toujours actif (hors quota)#

Affinement — comptés dans le quota (belle palette, par familles)#

Règles :

• RM-21 — Le nombre de critères d'affinement activables simultanément dépend de l'offre (Basic 3 · Gold 9 · Diamond illimités). Le socle reste toujours actif et gratuit.
• RM-22 — Le critère origine / communauté est 100 % optionnel et déclaratif ; il n'est jamais imposé, jamais rendu obligatoire pour être proposé, et fait l'objet d'une information RGPD/CNDP (donnée sensible potentiellement discriminatoire — cf. §22). L'utilisateur peut ne pas le renseigner ni l'utiliser.
• RM-23 — Aucun critère ne doit permettre un usage discriminatoire prohibé ; la modération et les CGU encadrent les combinaisons abusives.

Palette indicative et extensible : le catalogue exact (et le rattachement socle/affinement) est paramétrable en back-office pour itérer sans redéploiement.

14. Messagerie et mise en relation progressive#

14.1 Le parcours par paliers — call-first strict : le call est l'unique porte#

Décision produit structurante. Après le match, il n'y a AUCUNE messagerie texte. La seule action possible pour faire progresser une relation est de proposer / accepter un call in-app. Tant qu'aucun call n'a lieu, le match reste en attente (ni texte, ni coordonnées). Le call n'est pas une « escalade » optionnelle : c'est le point de passage obligatoire du produit.

Chaque étape est volontaire et réversible (blocage possible à tout moment). Le produit n'offre pas de chat écrit : il n'existe pas d'espace de conversation texte à « habiter ». Le seul chemin est le call in-app.

14.2 Décision : call in-app au MVP1 en mode call-first strict — OUI#

Décision retenue : le call audio/visio in-app entre DANS le périmètre MVP1 (révision de la position initiale MVP2) et devient l'unique canal de mise en relation (pas de messagerie texte). Justification : le call est le rite de passage — c'est lui qui (a) filtre les scammeurs (un fraudeur refuse l'appel / ne se présente pas — preuve de vie), (b) casse la superficialité, (c) supprime le « bavardage sans intention », et (d) conditionne le déblocage des coordonnées à double consentement. Le retirer, ou le doubler d'un chat, viderait le parcours de son différenciateur.

Arbitrage assumé (friction). Le call-first strict est le parcours à plus forte friction : accepter un appel sans avoir échangé un mot peut freiner, notamment côté féminin dans une démarche prudente. C'est un pari de positionnement cohérent avec « moins mais vrai ». Mitigations : cadrage rassurant avant le call (rappel que le n° reste masqué, call in-app, durée courte, possibilité de couper/signaler à tout instant), audio proposé en premier (moins engageant que la visio), et mesure fine du taux d'acceptation du call comme KPI critique (si trop bas, réévaluer).

Coût et complexité assumés (transparence). Cette décision alourdit le MVP1 :

• Technique : WebRTC + serveurs TURN/relais (NAT traversal), gestion de la signalisation, qualité réseau.
• Modération : le live est difficile à modérer en temps réel → au MVP1, pas d'enregistrement, signalement en un clic pendant/après le call, et le call reste court et cadré.
• Coûts : bande passante relais + éventuel prestataire CPaaS (ex. brique WebRTC managée) pour ne pas tout construire.
• Conformité : le call n'est pas enregistré (minimisation) ; le déblocage des coordonnées est un traitement sensible → double consentement explicite, rappel de sécurité, journalisation (preuve en cas de litige), possibilité de révoquer.

Option de repli si le budget/délai MVP1 est contraint : démarrer par call audio seul (moins coûteux que la visio riche) via une brique managée, la visio venant juste après. Le principe du parcours (sas texte → call pivot → déblocage à double consentement) reste identique.

14.2.b Règles du déblocage des coordonnées#

• Ne se déclenche jamais avant un call effectivement réalisé et jugé concluant par les DEUX parties.
• Double consentement : chacun doit cliquer explicitement « débloquer mes coordonnées ». Un seul clic ne suffit pas.
• Rappel de sécurité affiché au moment du déblocage (ne jamais envoyer d'argent, garder les échanges prudents…).
• Traçabilité : l'événement (qui, quand, réciprocité) est journalisé — utile en cas de signalement ultérieur.
• Révocable : un utilisateur peut re-masquer / bloquer à tout moment ; le blocage coupe l'accès même après déblocage.

14.3 Règles de sécurité de la mise en relation#

• Aucun canal texte libre : pas de chat écrit à sécuriser/modérer (surface d'attaque réduite d'emblée). Les seuls échanges avant call sont des actions cadrées (proposer/accepter un call, proposer un créneau).
• Coordonnées masquées (§12.2) : jamais visibles avant call concluant + double consentement (§14.2.b).
• Call non enregistré, chiffré ; signalement/blocage accessibles pendant et après le call.
• Pas d'envoi de fichiers/argent dans le MVP1 (réduit la surface d'attaque).
• Rappels de sécurité contextuels : avant le call (n° masqué, durée courte, couper à tout moment) et avant la rencontre (lieu public, prévenir un proche).
• Anti-scam déporté sur le comportement : sans texte à analyser, les signaux clés deviennent le refus / no-show répété du call et les demandes hors-cadre — remontés à la modération.

15. Modération#

15.1 Modèle hybride#

Couche automatique : règles (mots-clés scam, coordonnées, contenus interdits), détection comportementale basique (rythme anormal, multi-signalements), gates de vérification.

Couche humaine : file de modération priorisée (par gravité + score interne), vérification renforcée, décision finale sur cas sensibles.

15.2 Workflow#

Signalement / détection → Triage automatique (priorité) → Analyse humaine → Décision (rien / avertissement / restriction / suspension / ban) → Notification motivée → Recours → Traçabilité (audit log).

15.3 Principes#

• Proportionnalité, présomption de bonne foi, explicabilité, droit de recours.
• Protection renforcée du genre le plus exposé (traitement prioritaire des signalements de harcèlement).
• Tout est journalisé (qui a décidé quoi, quand, pourquoi) pour conformité et amélioration.

16. Back-office#

16.1 Fonctions MVP1#

• Gestion des utilisateurs (recherche, fiche, historique, statut).
• Statuts de vérification ; valider/refuser une identité (revue des cas KYC douteux).
• Gestion des signalements (file, prise en charge, décision).
• Gestion des comptes suspendus/bannis + recours.
• Consultation des alertes anti-fraude/anti-scam.
• Gestion des référents (attestations).
• Paramétrage du matching (poids, seuils, nb propositions/jour).
• Gestion de contenus (textes d'onboarding, questionnaires, listes de valeurs).
• Statistiques / KPIs (dashboard).

16.2 Rôles (RBAC)#

Principe : moindre privilège, séparation des fonctions (le vérificateur ne modère pas forcément), audit log sur toute action sensible.

17. User Stories (backlog MVP1 — prêt pour sprint 1)#

Format : US-ID — Titre / En tant que … je veux … afin de … / Critères d'acceptation / Règles métier / Priorité / Dépendances.

Priorités : P0 = Must sprint 1, P1 = Must, P2 = Should.

Épopée A — Compte & Authentification#

US-001 — Créer un compte · En tant que candidat je veux créer un compte afin d' accéder à la plateforme.

• CA : email+mot de passe (ou téléphone) ; consentement RGPD/CNDP obligatoire ; email unique ; mot de passe robuste ; compte créé en statut « non vérifié ».
• Règles : RM-01, RM-19. P0. Dépend : —

US-002 — Se connecter / mot de passe oublié · CA : login sécurisé ; réinit par email/OTP ; throttling anti-brute-force. P0. Dép : US-001.

US-003 — Vérifier mon email · CA : lien/OTP ; expiration ; renvoi limité ; badge « Email vérifié » à succès. P0. Dép : US-001.

US-004 — Vérifier mon téléphone · CA : OTP SMS ; nombre d'essais limité ; numéro stocké chiffré et non public ; badge « Téléphone vérifié ». P0. Dép : US-001. Règles : RM-14.

Épopée B — Vérification d'identité (Trust)#

US-010 — Vérifier mon identité (KYC) · afin d' obtenir le badge « Identité vérifiée » et pouvoir être proposé/contacter.

• CA : upload doc officiel + selfie + liveness via prestataire ; feedback si illisible ; statut (vérifié / en revue / refusé) ; document jamais exposé aux autres ni stocké en clair côté produit (référence prestataire uniquement).
• Règles : RM-02, RM-03, RM-20. P0. Dép : US-001.

US-011 — Comprendre pourquoi vérifier · CA : écran pédagogique (bénéfice, ce qu'on ne partage pas). P1. Dép : US-010.

US-012 — Reprendre une vérification échouée · CA : nouvelle tentative limitée ; escalade revue humaine. P1. Dép : US-010.

Épopée C — Profil & Compatibilité#

US-020 — Renseigner mon profil · CA : sections identité déclarative / vie pro / vision mariage ; sauvegarde progressive ; indicateur de complétude. Règles : RM-04. P0. Dép : US-001.

US-021 — Répondre au questionnaire valeurs & personnalité · CA : questionnaire découpé, reprenable ; résultats stockés pour matching ; aucune bonne/mauvaise réponse affichée. P0. Dép : US-020.

US-022 — Définir mes critères · CA : 4 niveaux (indispensable / important / secondaire / rédhibitoire) ; rédhibitoires appliqués comme filtres durs. Règles : RM-05. P0. Dép : US-020.

US-023 — Ajouter mes photos (dévoilement progressif) · CA : photo floutée par défaut, dévoilée par palier ; modération à l'upload. P1/P2. Dép : US-020.

US-024 — Voir mon Trust Passport · CA : badges obtenus + « comment améliorer » ; pas de score chiffré affiché. Règles : RM-07. P1. Dép : US-003,004,010,020.

Épopée D — Découverte & Matching#

US-030 — Recevoir mes propositions · afin de découvrir des profils compatibles. CA : 3-5 max/jour ; uniquement profils vérifiés+complets ; message honnête si aucun. Règles : RM-06, RM-08, RM-12. P0. Dép : US-021,022 + pool.

US-031 — Découvrir un profil progressivement · CA : ordre valeurs -> personnalité -> projet -> compatibilité -> photo. P0. Dép : US-030.

US-032 — Comprendre « pourquoi ce profil » · CA : explication basée sur les composantes de compatibilité. Règles : RM-09. P0. Dép : US-030.

US-033 — Exprimer mon intérêt / passer · CA : actions Intéressé(e) / Pas pour moi / Demander mise en relation ; intérêt non révélé si non réciproque. Règles : RM-10. P0. Dép : US-031.

US-034 — Être notifié d'un match · CA : match = intérêt réciproque ; aucune messagerie ne s'ouvre, seule action offerte = proposer un call. Règles : RM-11. P0. Dép : US-033.

Épopée E — Call in-app & Sécurité (call-first strict)#

US-040 — Proposer / accepter un call avec un match · CA : après match, seule action = proposer/accepter un call ; pas de chat texte ; tant que non accepté par les deux, match en attente. Règles : RM-11, RM-13. P0. Dép : US-034.

US-040b — Réaliser le call in-app · CA : planification d'un créneau ; call audio/visio WebRTC chiffré, coordonnées masquées, non enregistré ; couper/signaler à tout moment ; no-show/refus répété = signal anti-scam. Règles : RM-13, RM-14. P0. Dép : US-040.

US-040c — Débloquer les coordonnées après un call · CA : proposé uniquement après call jugé concluant par les deux ; double consentement explicite ; rappel sécurité ; événement tracé ; révocable. Règles : RM-13. P0. Dép : US-040b.

US-041 — Être alerté d'un risque d'arnaque · CA : signaux comportementaux (refus/no-show du call, demandes hors-cadre) ; conseils sécurité avant call. Règles : RM-15. P0. Dép : US-040.

US-042 — Signaler / bloquer un utilisateur · CA : motifs prédéfinis ; blocage immédiat ; création d'un dossier modération. Règles : RM-16. P0. Dép : US-040.

US-043 — Recevoir des conseils avant une rencontre · CA : check-list sécurité affichée à l'étape rencontre. P2. Dép : US-040.

Épopée F — Référent (Should)#

US-050 — Inviter un référent de confiance · CA : invitation par lien ; le référent atteste connaître l'utilisateur ; badge « Référent confirmé » ; totalement optionnel ; droits limités (attestation seule). Règles : RM-17. P2. Dép : US-020.

Épopée G — Confidentialité & Compte#

US-060 — Gérer ma confidentialité · CA : visibilité paramétrable dans les limites autorisées ; voir quelles données ne sont jamais partagées. Règles : RM-18. P1. Dép : US-020.

US-061 — Supprimer mon compte / droit à l'oubli · CA : suppression effective ; purge/anonymisation selon obligations ; confirmation. Règles : RM-19, RM-20. P0. Dép : US-001.

Épopée H — Back-office (interne)#

US-070 — Modérer les signalements · CA : file priorisée ; décision + motif ; notification + recours ; audit log. P0. Dép : US-042.

US-071 — Valider/refuser une identité · CA : revue KYC douteux ; changement de statut tracé. P0. Dép : US-010.

US-072 — Paramétrer le matching · CA : poids/seuils/nb propositions éditables sans redeploy. P1. Dép : US-030.

US-073 — Consulter le dashboard KPIs · CA : indicateurs §23 ; filtres période. P1. Dép : données.

Épopée I — Notifications#

US-080 — Recevoir les notifications essentielles · CA : proposition, intérêt reçu, match, message, vérif terminée, alerte sécurité ; canaux push + email ; opt-out granulaire. P1. Dép : US-030+.

18. Règles métier#

Liste numérotée, référencée par les User Stories.

1. RM-01 — Un email/téléphone ne peut être associé qu'à un seul compte actif.
2. RM-02 — Un utilisateur non vérifié (identité) ne peut pas être proposé ni contacter un autre utilisateur.
3. RM-03 — Le document d'identité et les données biométriques ne sont jamais visibles par un autre utilisateur ni stockés en clair côté produit (référence prestataire uniquement).
4. RM-04 — Un profil doit atteindre un seuil de complétude (incl. valeurs & critères) avant d'entrer dans le pool de matching.
5. RM-05 — Les critères rédhibitoires des deux parties sont des filtres durs : un profil violant un rédhibitoire n'est jamais proposé.
6. RM-06 — Seuls les profils vérifiés + complets peuvent être proposés.
7. RM-07 — Le Trust Score chiffré n'est jamais affiché ; seuls les badges du Trust Passport sont publics.
8. RM-08 — Le nombre de propositions par utilisateur/jour est limité et configurable (défaut 3-5).
9. RM-09 — Toute proposition doit être explicable (« pourquoi ce profil »).
10. RM-10 — L'intérêt d'un utilisateur n'est révélé à l'autre que s'il est réciproque.
11. RM-11 — Call-first strict : après un match, aucune messagerie texte n'est offerte. La seule action pour progresser est proposer/accepter un call in-app. Tant qu'aucun call n'a eu lieu, le match reste en attente (ni texte, ni coordonnées).
12. RM-12 — Si aucun profil compatible n'existe, le système ne fabrique pas de faux profils ; il informe honnêtement.
13. RM-13 — Les coordonnées personnelles (téléphone, email, liens) ne sont jamais dévoilées avant un call jugé concluant par les deux parties ET un double consentement explicite ; le déblocage est tracé et révocable.
14. RM-13b — Le call in-app n'est pas enregistré ; il est chiffré ; signalement/blocage possibles pendant et après.
15. RM-14 — Le numéro de téléphone et l'email ne sont jamais exposés publiquement.
16. RM-15 — Les alertes anti-scam sont informatives ; une sanction automatique lourde nécessite une confirmation humaine ou des signaux forts cumulés.
17. RM-16 — Tout utilisateur peut signaler/bloquer à tout moment ; un blocage est immédiat.
18. RM-17 — Le référent a des droits strictement limités (attestation) ; fonctionnalité optionnelle ; il ne voit pas les conversations.
19. RM-18 — Séparation stricte entre données d'identité (sensibles) et données de profil (publiables) ; minimisation par défaut.
20. RM-19 — L'utilisateur peut supprimer son compte ; déclenche purge/anonymisation conforme (droit à l'oubli).
21. RM-20 — Toute donnée sensible est chiffrée (au repos et en transit) ; accès journalisé.
22. RM-21 — Toute décision de modération est motivée, notifiée et susceptible de recours, et journalisée (audit).
23. RM-22 — Un compte en revue a un accès restreint (ni proposé, ni contact) jusqu'à décision.
24. RM-23 — Les poids/seuils du matching sont modifiables en back-office sans redéploiement.
25. RM-24 — Protection asymétrique : les signalements de harcèlement sont traités en priorité.

19. Modèle de données fonctionnel#

Modèle logique (entités, attributs clés, relations). La séparation Identity/Profile est structurante pour la confidentialité.

19.1 Entités#

19.2 Notes de conception#

• Séparation Identity / Profile = table/service distinct, chiffrement renforcé, accès très restreint (RM-18).
• TrustScore.scoreInternal jamais sérialisé vers les clients publics ; seuls badges[] exposés.
• Message.sanitizedContent = version affichée (coordonnées masquées) ; content brut conservé chiffré pour modération/audit selon durée légale.
• Match.stage matérialise le parcours progressif (§14).

20. Architecture fonctionnelle#

Vue orientée services (fonctionnelle, pas technologique). Découpage en domaines pour permettre l'extension internationale et l'ajout de la Khetaba.

20.1 Vue d'ensemble#

                 +---------------------------+
 FRONT-OFFICE    |  App Mobile   |  Web App  |
                 +-------+-------------+------+
                         |             |
                    +----v-------------v----+
                    |     API Gateway       |  (auth, rate limit, routing)
                    +----+------------------+
                         |
   +---------+-----------+-----------+-----------+-----------+
   |         |           |           |           |           |
+--v--+  +---v---+   +---v----+  +---v---+   +----v----+  +---v-----+
|Auth |  |Identity|  |Matching|  | Trust |   |Messaging|  |Fraud/   |
|Svc  |  |Verif.  |  |Engine  |  |Service|   |Service  |  |Anti-scam|
+-----+  +---+---+   +--------+  +-------+   +----+----+  +---------+
             |                                     |
      +------v------+                       +------v------+
      | KYC Provider|                       | Notification|
      | (externe)   |                       | Service     |
      +-------------+                       +-------------+

 BACK-OFFICE : Administration | Vérification | Modération | Reporting/KPIs
 DATA : Identity Store (chiffré, isolé)  |  Profile/Match Store  |  Audit Log

20.2 Services (responsabilités)#

20.3 Recommandations technologiques (justifiées, non imposées)#

• Externaliser le KYC/liveness (prestataire spécialisé conforme) plutôt que le construire : réduit coût, risque et charge de conformité biométrique. Alternative rejetée : KYC maison → coût & risque juridiques trop élevés au MVP.
• Matching = moteur de règles (pas de ML) au MVP1 : explicabilité + absence de données d'entraînement. ML envisagé en MVP2 quand données disponibles.
• Isolation du domaine Identity (store séparé, chiffré, accès restreint) : exigence de confidentialité, pas un choix de confort.
• Approche modulaire (services logiques clairement séparés) même si déployée en monolithe modulaire au départ : permet d'ajouter Video/Khetaba sans refonte. On ne recommande pas un micro-services complet au MVP (sur-ingénierie pour valider un concept).
• Notifications via un service dédié multi-canal (push provider + email + SMS gateway pour critique).

21. UX / UI & Écrans du MVP1#

21.1 Principes UX#

• Codes « sérieux/sécurité », jamais « dating » (pas de swipe, pas de flammes).
• Progressive disclosure partout (formulaires découpés, découverte par paliers).
• Feedback de confiance permanent (badges visibles, « ce que nous ne partageons pas »).
• Réduction de l'anxiété (surtout femmes) : rappels de sécurité, contrôle, sobriété visuelle.
• Accessibilité & multilingue (FR/AR au moins ; support RTL pour l'arabe à prévoir tôt).

21.2 Liste complète des écrans#

Écrans ajoutés vs liste initiale : 9 (statut vérif), 23 (liste conv), 26 (check-list rencontre), 33 (aide sécurité) — nécessaires au parcours réel.

21.3 Wireframes prioritaires (à produire en phase UX)#

Découverte progressive (19-20), Trust Passport (17), Conversation + anti-scam (24-25), KYC (7-9). Ce sont les écrans qui portent la différenciation.

22. Sécurité & confidentialité#

22.1 Cadre légal#

• RGPD (diaspora UE) et loi 09-08 / CNDP (Maroc) — les deux s'appliquent selon la localisation des utilisateurs.
• Données biométriques & scoring : autorisation préalable CNDP probable ; base légale RGPD = consentement explicite + intérêt légitime encadré. À sécuriser juridiquement AVANT le dev (risque bloquant, cf. préambule).

22.2 Mesures MVP1#

22.3 Données jamais visibles par les autres utilisateurs (rappel)#

Document d'identité, selfie/liveness, numéro de téléphone, email, adresse précise, score interne, historique de modération/signalements, informations du référent, géolocalisation fine.

23. KPIs du MVP1#

23.1 Funnel complet (à instrumenter)#

Inscriptions → Vérif email → Vérif tel → Vérif identité → Profil complété → Profil validé → Propositions reçues → Intérêt exprimé → Match → Call proposé → Call accepté (les deux) → Call réalisé → Call concluant → Coordonnées débloquées → Rencontre déclarée.

23.2 Les 8 KPIs prioritaires (liés aux hypothèses)#

Cibles à recalibrer après baseline — elles servent à définir « le MVP marche / ne marche pas », pas à s'auto-satisfaire.

23.3 Métriques de garde-fou (anti-vanité)#

Ne PAS piloter sur : nombre total d'inscrits, nombre de messages, temps passé (typiquement des métriques de dating, ici trompeuses). Le bon signal = qualité des mises en relation, pas volume d'activité.

24. Modèle économique#

24.1 Options#

24.2 Recommandation#

• MVP1 : gratuit / quasi-gratuit pour maximiser l'apprentissage (valider H1-H3 avant de monétiser). Éventuellement une vérification premium optionnelle pour tester la disposition à payer pour la confiance.
• Attention pricing & positionnement : ne jamais vendre « plus de profils » d'une manière qui casse la promesse de curation. Premium doit vendre plus de pertinence / plus de serviabilité, pas plus de volume.
• Asymétrie genre : envisager la gratuité/priorité côté femmes pour équilibrer le pool (levier de croissance, pas seulement éthique).
• Khetaba/commission = principal moteur de revenu à terme (V2), pas au MVP1.

24.3 Grille d'abonnements proposée (3 offres) — page dédiée : pricing.html#

Principe (révisé). Pas d'offre gratuite : la plateforme est 100 % sur abonnement dès l'inscription (public réellement engagé). La sécurité/vérification est identique dans toutes les offres — la confiance n'est jamais un privilège payant. La différenciation porte sur trois leviers : le nombre de profils proposés/mois, la finesse des critères de recherche (ville, local/étranger, profession, origine…) et les prises de contact/mois. Les profils restent curés (jamais un flux brut) pour préserver H2 et « moins, mais vrai ».

Critères de recherche = levier de précision. Ce sont les filtres du matching (ville, local/étranger, profession, origine, valeurs…). Plus l'offre est élevée, plus l'utilisateur peut en activer simultanément (3 → 9 → illimités) : on vend de la précision de recherche, pas du volume.

Socle identique à toutes les offres (non différenciant) : vérification d'identité (KYC), call in-app chiffré, coordonnées protégées jusqu'au double consentement, anti-arnaque & modération.

Prix et quotas indicatifs (hypothèses à valider en bêta : élasticité, consentement à payer, marché Maroc vs diaspora). Remise annuelle ~20 % envisagée.

Options à la carte (add-ons) : Profils supplémentaires (curés) · Contacts supplémentaires · Session Khetaba ponctuelle · Pack familles (référent à droits étendus).

Logique de la grille :

• La confiance n'est pas monétisée : elle est due à tous. On monétise la capacité de mise en relation (profils + contacts) et l'accompagnement humain.
• Diamond = marge & humain : l'accompagnement Khetaba/conseiller est le vrai différenciateur premium (préfigure l'écosystème Khetaba certifiée du MVP2/Vision).
• Quotas mensuels : plus simples à communiquer ; à surveiller le risque de consommation en début de mois (ajustable en hebdomadaire si besoin).

⚠️ Point de vigilance (cold-start) — assumé. Le choix 100 % payant, sans gratuit ni essai, rend l'amorçage du pool plus difficile (une plateforme matrimoniale vide ne convertit pas), avec un risque accru sur l'équilibre de genre. Mitigations : lancement sur une niche dense, amorçage ciblé, suivi serré du remplissage du pool. Si le démarrage cale, envisager un essai court ou une gratuité ciblée sur le genre sous-représenté — sans revenir à un plan gratuit permanent.

Cohérence MVP1 : cette grille est une cible de monétisation. La reco de tester d'abord la valeur (H1-H3) reste valable — mais le choix produit d'un accès payant dès le départ est acté ici et devra être mesuré tôt (taux de conversion à l'abonnement, cold-start).

25. Risques#

26. MVP1 / MVP2 / Vision#

MVP1 — Tester le concept (les 3 hypothèses)#

Vérifications (email/tel/identité KYC), profil + valeurs + personnalité + critères, Trust Passport (badges), matching curé explicable, découverte progressive, mise en relation + messagerie sécurisée, anti-scam basique, modération hybride, back-office, notifications, confidentialité/suppression.

MVP2 — Approfondir confiance & écosystème#

Le MVP2 n'est déclenché qu'après validation des hypothèses H1-H3 en bêta. Il approfondit les deux piliers différenciants (Trust, Compatibility) et pose les bases de l'écosystème (référent, famille, monétisation). Chaque fonctionnalité est décrite ci-dessous ; les User Stories ne seront rédigées qu'au lancement effectif du MVP2, sur données réelles.

F-MVP2-1 — Entretien vidéo de vérification#

• Pourquoi. Renforcer le niveau de confiance au-delà du KYC documentaire : un court entretien vidéo (asynchrone ou avec un vérificateur) prouve qu'une personne réelle, cohérente avec son profil, est derrière le compte. C'est le « niveau 5 » de confiance esquissé au MVP1.
• Pour qui. Les utilisateurs qui veulent un badge de confiance supérieur ; les femmes de la niche, particulièrement sensibles à la preuve de sérieux ; à terme, exigence possible avant certaines mises en relation.
• Comment. Enregistrement vidéo guidé (phrase à lire + mouvement de tête = liveness actif), stocké chiffré dans l'Identity Store isolé, jamais visible des autres utilisateurs. Revue humaine par un vérificateur, ou semi-automatique. Résultat = badge « Vérifié·e par vidéo », pas la vidéo elle-même.
• Valeur. Différenciateur fort vs tout concurrent ; augmente la qualité perçue et la sécurité.
• Risque. Friction élevée (abandon), coût humain, données biométriques sensibles (DPIA obligatoire). → optionnel, incitatif (pas bloquant), consentement explicite, suppression sur demande.

F-MVP2-2 — Call in-app enrichi (le socle audio/visio est en MVP1)#

Note : la brique de base — call audio/visio in-app + planification + déblocage des coordonnées à double consentement — a été remontée au MVP1 (rite de passage du parcours, cf. §14.2). Le MVP2 ne fait qu'enrichir cette brique.

• Pourquoi. Améliorer la qualité et la sécurité du call une fois le socle validé en conditions réelles.
• Pour qui. Utilisateurs actifs ; modération (meilleurs outils live).
• Comment (enrichissements MVP2). Visio HD robuste et repli réseau avancé (SFU) ; détection de deepfake en temps réel (preuve de vie renforcée) ; salle d'attente / créneaux récurrents ; qualité adaptative ; éventuelle médiation par un référent lors du call.
• Valeur. Fiabilise le rite de passage et durcit l'anti-scam (deepfake live).
• Risque. Coût infra (SFU), complexité modération live. → introduire après stabilisation du socle MVP1, jamais d'enregistrement.

F-MVP2-3 — IA anti-fraude & anti-deepfake#

• Pourquoi. Le MVP1 se contente d'anti-scam basique (règles + signalement). À l'échelle, il faut détecter automatiquement faux documents, photos volées, visages générés par IA et deepfakes.
• Pour qui. Toute la base (protection collective) ; l'équipe de modération (priorisation des cas).
• Comment. Reverse image search (photo déjà présente ailleurs sur le web), détection de visages synthétiques/deepfake, analyse de cohérence document↔selfie, scoring de risque alimentant la file de modération. L'humain garde la décision finale.
• Valeur. Passage à l'échelle sans exploser les coûts de modération ; barrière à l'entrée technique.
• Risque. Faux positifs (bannir un vrai utilisateur), biais des modèles. → l'IA propose, l'humain tranche ; recours utilisateur systématique.

F-MVP2-4 — Graphe anti multi-comptes#

• Pourquoi. Empêcher qu'un même individu (ou un fraudeur) crée des dizaines de comptes — problème structurel des plateformes de rencontre.
• Pour qui. Protection de la base et de la modération ; intégrité du matching.
• Comment. Graphe de corrélation entre signaux (empreinte d'appareil, IP, patterns comportementaux, réutilisation de documents/photos hachés) pour relier des comptes suspects. Déclenche vérification renforcée ou suspension.
• Valeur. Réduit spam, arnaques industrialisées et manipulation du matching.
• Risque. Vie privée (fingerprinting), faux liens (foyers partageant une IP). → transparence, seuils prudents, revue humaine avant sanction.

F-MVP2-5 — Matching avancé (ML explicable)#

• Pourquoi. Le MVP1 utilise un moteur de règles pondérées (volontairement, faute de données). Une fois des données réelles de mises en relation « de qualité » accumulées, un modèle peut améliorer la pertinence.
• Pour qui. Tous les utilisateurs (meilleures propositions) ; le produit (meilleure North Star Metric).
• Comment. ML entraîné sur les signaux de succès réels, mais l'explicabilité reste obligatoire (« pourquoi ce profil » toujours affiché). Approche hybride : le ML pondère, les règles métier et rédhibitoires restent des garde-fous durs.
• Valeur. Meilleure compatibilité = plus de rencontres réussies = cœur de la proposition de valeur.
• Risque. Boîte noire, biais discriminatoires, dérive vers l'optimisation de l'engagement (piège dating). → auditer les biais, ne jamais optimiser le « temps passé », garder l'explication visible.

F-MVP2-6 — Référent enrichi & implication de la famille#

• Pourquoi. Passer du référent « confirmation simple » (MVP1) à de vrais workflows multi-acteurs : un proche/famille peut accompagner certaines étapes — c'est le pont culturel vers la Khetaba traditionnelle.
• Pour qui. Utilisateurs (surtout la niche traditionnelle) qui souhaitent impliquer un tiers de confiance ; les familles.
• Comment. Rôles et permissions granulaires (le référent voit/valide certaines étapes définies par l'utilisateur, jamais les conversations privées sauf accord explicite) ; invitations, notifications dédiées, journal d'actions. Totalement optionnel.
• Valeur. Authenticité culturelle, confiance accrue, différenciation majeure vs dating occidental.
• Risque. Complexité UX, risque de contrôle/pression familiale. → l'utilisateur reste maître, granularité fine, possibilité de retirer un référent à tout moment.

F-MVP2-7 — Premium & monétisation#

• Pourquoi. Le MVP1 reste gratuit (valider H1-H3 avant de monétiser). Le MVP2 introduit un modèle cohérent avec le positionnement sérieux — sans vendre « plus de profils » (ce qui détruirait le positionnement).
• Pour qui. Utilisateurs engagés prêts à payer pour la qualité/sécurité ; modèle économique de la plateforme.
• Comment. Pistes : vérification premium (KYC approfondi, badge supérieur), filtres avancés, analyse de compatibilité détaillée, priorité de traitement — jamais du volume brut. Traitement asymétrique possible (gratuité côté sous-représenté pour l'équilibre de genre).
• Valeur. Revenus alignés sur la confiance et la compatibilité, pas sur l'addiction.
• Risque. Monétiser trop tôt tue la croissance ; payer pour « être vu » recrée le biais dating. → introduire progressivement, tester le consentement à payer, garder le cœur gratuit.

F-MVP2-8 — Multilingue complet & RTL arabe abouti#

• Pourquoi. Le MVP1 vise une niche ; l'extension exige un support linguistique de première classe, dont l'arabe en RTL (droite-à-gauche) réellement soigné, clin d'œil direct à la « الخطّابة ».
• Pour qui. Diaspora et marché marocain/maghrébin ; futurs marchés.
• Comment. Internationalisation (i18n) complète, mise en page RTL native (pas un simple miroir), français/arabe/anglais au minimum, contenus et notifications localisés.
• Valeur. Adoption, crédibilité culturelle, préparation de l'international.
• Risque. Dette technique si repoussé trop tard. → architecture i18n-ready dès le MVP1 (déjà prévu), contenu ajouté au MVP2.

V2 / Vision — Nouvelle catégorie#

La Vision incarne pleinement la catégorie « Digital Khetaba / Trusted Matrimonial Platform ». Ces fonctionnalités transforment la plateforme d'un outil de mise en relation en un écosystème d'accompagnement matrimonial. Elles sont directionnelles : à préciser selon la traction réelle.

F-V-1 — Khetabas certifiées (comptes professionnels)#

• Pourquoi. Digitaliser réellement le métier de la Khetaba : le MVP1 en pose l'esquisse (référent), la Vision en fait un acteur pro à part entière — potentiellement le vrai moteur de revenu.
• Pour qui. Khetabas professionnelles ; familles cherchant un accompagnement humain ; utilisateurs voulant une médiation de confiance.
• Comment. Compte pro vérifié (certification de la plateforme), portefeuille de candidats, recommandations de profils, organisation de mises en relation, suivi de l'avancement d'une relation, accompagnement des familles. Modèle : commission ou abonnement pro.
• Valeur. Différenciation catégorielle absolue ; nouvelle source de revenu ; pont tradition↔numérique.
• Risque. Qualité/éthique des Khetabas, responsabilité de la plateforme, confidentialité. → certification stricte, chartes, contrôle des accès aux données.

F-V-2 — Communautés & accompagnement matrimonial#

• Pourquoi. Créer de l'appartenance et de la confiance sociale autour du projet de mariage, au-delà du one-to-one.
• Pour qui. Communautés partageant une approche matrimoniale ; utilisateurs cherchant conseils et pairs.
• Comment. Espaces thématiques modérés, contenus d'accompagnement, événements. Modération renforcée (le sujet est sensible).
• Valeur. Rétention, effet réseau, crédibilité.
• Risque. Modération coûteuse, dérives. → cadrage strict, modération hybride éprouvée au MVP1.

F-V-3 — IA coach relationnel#

• Pourquoi. Aider les utilisateurs à préparer la rencontre, la discussion familiale, la progression de la relation — de l'outil de matching vers l'accompagnement.
• Pour qui. Utilisateurs peu à l'aise avec la démarche ; primo-arrivants sur ce type de plateforme.
• Comment. Assistant guidant (conseils de conversation, préparation d'un premier appel, médiation des attentes), respectueux de la vie privée, sans se substituer au consentement humain.
• Valeur. Réduit l'anxiété, améliore la qualité des rencontres, augmente les succès.
• Risque. Conseils inadaptés, dépendance, sensibilité culturelle. → ton prudent, garde-fous, jamais de décision à la place de l'utilisateur.

F-V-4 — Analyse de compatibilité avancée#

• Pourquoi. Approfondir la promesse « compatibilité réelle » avec une analyse plus riche que le matching (valeurs, personnalité, projet de vie croisés en profondeur).
• Pour qui. Couples en réflexion sérieuse avant engagement ; option premium plausible.
• Comment. Rapports de compatibilité détaillés et explicables, points de convergence/vigilance, sujets à aborder. Toujours transparent, jamais un « score » couperet.
• Valeur. Renforce le pilier Compatibility ; justifie du premium.
• Risque. Fausse promesse « scientifique », déterminisme. → présenter comme aide à la réflexion, pas comme vérité.

F-V-5 — Services partenaires (pré/post-mariage)#

• Pourquoi. Étendre la valeur au-delà de la rencontre : organisation du mariage, accompagnement pré et post-mariage — capturer tout le parcours matrimonial.
• Pour qui. Couples aboutissant à un projet concret ; partenaires (organisateurs, conseil).
• Comment. Place de marché de partenaires de confiance (curés/vérifiés), intégrations, éventuelles commissions.
• Valeur. Nouvelles sources de revenu, cycle de vie utilisateur étendu, écosystème complet.
• Risque. Dispersion, dilution du cœur produit. → n'ouvrir qu'une fois le cœur solide et rentable.

F-V-6 — Extension internationale#

• Pourquoi. L'architecture est pensée dès le MVP1 pour dépasser le seul cadre marocain ; la Vision ouvre à d'autres communautés partageant une approche matrimoniale (confiance, sérieux, famille).
• Pour qui. Nouveaux marchés/communautés ; croissance.
• Comment. Localisation culturelle (pas seulement linguistique) : critères, valeurs et rituels adaptables par communauté ; conformité par juridiction (RGPD et équivalents).
• Valeur. Marché adressable démultiplié ; la catégorie « Trusted Matrimonial Platform » devient globale.
• Risque. Complexité réglementaire et culturelle par pays. → expansion progressive, marché par marché, jamais générique.

27. Roadmap (indicative)#

Estimation totale MVP1 : ~5-7 mois selon taille d'équipe. La phase 0 (légal) conditionne tout et ne doit pas être compressée.

28. Conclusion et recommandations#

28.1 Ce qui rend ce produit défendable#

Le produit ne gagne pas parce qu'il ajoute de la vérification à du dating. Il gagne s'il incarne réellement une nouvelle catégorie : un tiers de confiance numérique structuré autour de TRUST · COMPATIBILITY · INTENTION, où la friction est assumée comme un signal de sérieux, et où la Khetaba/famille a une place. C'est un produit de confiance et de rituel, pas de volume.

28.2 Les 6 recommandations décisives#

1. Sécuriser la conformité CNDP/biométrie AVANT le développement — risque bloquant n°1.
2. KYC contextuel, pas à l'entrée — pour tester H1 sans tuer la conversion.
3. Lancer sur une niche dense (ex. diaspora maghrébine 27-38 ans en Europe) — seule façon de résoudre le cold start.
4. Trust Passport à badges, jamais de score public — évite la dérive discriminatoire et le risque juridique.
5. Matching = moteur de règles explicable au MVP1 — pas de ML sans données, l'explicabilité est un différenciateur.
6. Rester gratuit au MVP1 — valider les 3 hypothèses avant de monétiser ; la Khetaba est le vrai moteur de revenu, mais plus tard.

28.3 Le piège à éviter#

Ne pas céder, sous pression de croissance, aux réflexes du dating : swipe, volume, score d'attractivité, monétisation du « plus de profils ». Chacun de ces choix, isolément raisonnable, détruit le positionnement. Le produit doit être discipliné : moins, mais vrai.

28.4 Prochaines étapes#

Ce dossier permet de passer directement à : UX/UI (maquettes) → Architecture technique détaillée → Backlog priorisé (les US §17 sont prêtes) → Développement MVP1 → Bêta niche → Mesure H1-H3 → Décision MVP2.

Fin du dossier d'analyse fonctionnelle MVP1.