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) -> ouverture d'une conversation sécurisée.
16. Conversation in-app (filtrée anti-scam/anti-coordonnées).
17. Escalade volontaire vers appel/visio (reporté MVP2 en natif ; MVP1 = passage volontaire hors-app assisté par recommandations de sécurité).
18. 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.

14. Messagerie et mise en relation progressive#

14.1 Le parcours par paliers#

Chaque étape est volontaire et réversible (blocage possible à tout moment).

14.2 Décision : audio/visio in-app au MVP1 ?#

Recommandation : NON au MVP1 (OUT OF SCOPE O2). WebRTC + modération temps réel + coûts + conformité = trop lourd pour tester H1-H3. MVP1 : on facilite le passage volontaire (ex. lien de visio externe suggéré) avec fort accompagnement sécurité, et on mesure l'appétence pour l'intégrer nativement en MVP2. Contre-argument assumé : la visio in-app renforcerait l'anti-scam (preuve de vie) — d'où sa priorité haute en MVP2.

14.3 Règles de sécurité de la messagerie#

• Coordonnées masquées (§12.2) jusqu'à un stade avancé/consenti.
• Alertes anti-scam non bloquantes.
• Pas d'envoi de fichiers/argent dans le MVP1 (réduit la surface d'attaque).
• Signalement/blocage toujours accessibles.
• Rappels de sécurité contextuels (1er message, avant rencontre).

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 ; ouverture conversation. Règles : RM-11. P0. Dép : US-033.

Épopée E — Messagerie & Sécurité#

US-040 — Échanger avec un match · CA : messagerie in-app ; coordonnées masquées ; horodatage ; blocage possible. Règles : RM-13, RM-14. P0. Dép : US-034.

US-041 — Être alerté d'un risque d'arnaque · CA : bannière non bloquante sur signaux scam ; conseils sécurité. 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 — Une conversation ne peut s'ouvrir qu'après intérêt réciproque (match).
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) sont masquées dans la messagerie jusqu'à un stade avancé/consenti.
14. RM-14 — Le numéro de téléphone et l'email ne sont jamais exposés publiquement.
15. RM-15 — Les alertes anti-scam sont informatives ; une sanction automatique lourde nécessite une confirmation humaine ou des signaux forts cumulés.
16. RM-16 — Tout utilisateur peut signaler/bloquer à tout moment ; un blocage est immédiat.
17. RM-17 — Le référent a des droits strictement limités (attestation) ; fonctionnalité optionnelle ; il ne voit pas les conversations.
18. RM-18 — Séparation stricte entre données d'identité (sensibles) et données de profil (publiables) ; minimisation par défaut.
19. RM-19 — L'utilisateur peut supprimer son compte ; déclenche purge/anonymisation conforme (droit à l'oubli).
20. RM-20 — Toute donnée sensible est chiffrée (au repos et en transit) ; accès journalisé.
21. RM-21 — Toute décision de modération est motivée, notifiée et susceptible de recours, et journalisée (audit).
22. RM-22 — Un compte en revue a un accès restreint (ni proposé, ni contact) jusqu'à décision.
23. RM-23 — Les poids/seuils du matching sont modifiables en back-office sans redéploiement.
24. 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 → Conversation → Conversation « qualifiée » → Passage visio/rencontre → 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 sérviabilité, 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.

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#

• Entretien vidéo de vérification ; audio/visio in-app.
• IA anti-fraude / anti-deepfake ; reverse image ; graphe anti-multi-comptes.
• Matching avancé (ML sur données réelles, tout en gardant l'explicabilité).
• Référent enrichi & implication famille (workflows multi-acteurs).
• Premium complet & monétisation ; verification premium.
• Multilingue complet, RTL arabe abouti.

V2 / Vision — Nouvelle catégorie#

• Khetabas certifiées (comptes pro, portefeuille, recommandations, suivi de relation).
• Communautés et accompagnement matrimonial.
• IA coach (préparation à la rencontre, à la discussion familiale).
• Analyse de compatibilité avancée ; services partenaires (organisation mariage, accompagnement pré/post-mariage).
• Extension internationale (autres communautés à approche matrimoniale).

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.