Plateforme intelligente de mise en relation universelle par l’intention.

Document de cadrage

Version 0.1

Document de travail

Commanditaire :

 SCI

Opérateur de conception et de développement :

Nature du document :

Première formalisation fonctionnelle de la vision et des besoins exprimés par le commanditaire.

Préambule

Le présent document a pour objet de formaliser la vision fonctionnelle d’un projet d’application mobile intelligente commandé à Quentumspace par SCI.

Le projet repose sur une idée directrice :

Permettre à toute personne de rechercher, proposer ou exprimer un besoin librement, sans être contrainte de parcourir des catégories ou de remplir des formulaires prédéfinis, puis laisser l’intelligence artificielle comprendre cette intention et rapprocher les offres et les demandes pertinentes.

L’application ambitionne ainsi de devenir une plateforme de mise en relation universelle, capable de traiter des situations aussi diverses que la vente d’un objet, la recherche d’un emploi, la demande d’un service, le recrutement d’un joueur de football, la location d’un logement ou la recherche d’un accompagnement ponctuel.

Le présent document constitue une base de cadrage fonctionnel. Il ne constitue pas, à lui seul, un cahier des charges technique définitif, une spécification d’architecture, un devis, ni un engagement contractuel sur un périmètre de livraison ou un calendrier.

I. Présentation générale du projet

1.1. Nature du projet

Le projet consiste à concevoir et développer une application mobile unique de mise en relation entre :

• des personnes qui cherchent ;
• des personnes qui proposent ;
• des personnes qui vendent ;
• des personnes qui offrent un service ;
• des personnes qui se présentent ou se rendent disponibles.

La plateforme doit pouvoir accueillir des besoins et des offres relevant de domaines très différents, sans imposer à l’utilisateur une organisation préalable en catégories.

L’utilisateur doit pouvoir exprimer son intention :

• en texte ;
• en photo ;
• en vidéo ;
• ou par une photo seule.

L’intelligence artificielle intervient ensuite pour comprendre, structurer, enrichir et rapprocher les intentions compatibles.

1.2. Proposition de valeur

La plateforme vise à répondre à trois difficultés classiques des systèmes de petites annonces et de mise en relation :

1. La difficulté de savoir où chercher.
2. La difficulté de formuler correctement une offre ou une demande.
3. La difficulté de trouver la bonne personne au bon moment et au bon endroit.

La proposition de valeur peut être résumée ainsi :

Publier en quelques secondes, trouver sans chercher dans des cases, et laisser l’IA rapprocher les bonnes personnes au bon moment.

1.3. Ambition du projet

L’ambition n’est pas de créer une application spécialisée dans un seul secteur, mais une infrastructure numérique de mise en relation par l’intention, capable de s’adapter à une grande variété d’usages.

Le projet doit pouvoir commencer par un périmètre maîtrisé, puis évoluer progressivement vers une couverture multidomaine plus large.

II. Principes fonctionnels fondamentaux

2.1. L’intention avant la catégorie

Le principe fondateur de la plateforme est le suivant :

L’utilisateur exprime ce qu’il veut, ce qu’il possède ou ce qu’il peut proposer. La plateforme détermine ensuite comment structurer cette information.

L’utilisateur ne doit pas être obligé de connaître à l’avance :

• la catégorie appropriée ;
• les critères techniques nécessaires ;
• le vocabulaire exact ;
• les filtres à utiliser ;
• la structure d’une annonce.

La catégorie, lorsqu’elle est utile au fonctionnement interne ou à la présentation des résultats, doit être déduite par le système, et non imposée comme point de départ.

2.2. Une application, deux modes fondamentaux

La plateforme doit proposer deux modes principaux dans une même application :

Mode A — Je propose / je vends / je suis

L’utilisateur décrit librement :

• ce qu’il possède ;
• ce qu’il vend ;
• ce qu’il propose ;
• ce qu’il sait faire ;
• ce qu’il peut fournir ;
• ou ce qu’il est disponible à faire.

Il peut publier directement son contenu ou demander à l’IA de l’aider à préparer une offre.

Mode B — Je cherche / j’achète / j’ai besoin

L’utilisateur décrit librement :

• ce qu’il recherche ;
• ce qu’il souhaite acheter ;
• le service dont il a besoin ;
• la personne qu’il souhaite rencontrer ;
• ou la prestation qu’il souhaite obtenir.

La demande devient active et peut recevoir des propositions compatibles.

2.3. La multimodalité comme principe d’accès

Le texte ne doit pas être une obligation.

Une offre ou une demande peut être exprimée :

• uniquement par écrit ;
• uniquement par une photo ;
• par plusieurs photos ;
• par une vidéo ;
• par une combinaison de texte, photos et vidéo.

L’IA doit pouvoir exploiter les informations disponibles, sans exiger systématiquement une saisie manuelle exhaustive.

2.4. La simplicité comme exigence prioritaire

L’application doit être conçue pour permettre une publication ou une recherche en quelques secondes.

L’utilisateur ne doit pas être confronté à un parcours lourd de type :

Catégorie → Sous-catégorie → Formulaire → Filtres → Validation → Publication

Le parcours privilégié est :

Intention → Compréhension → Validation → Mise en relation

III. Parcours utilisateur

3.1. Parcours général

1. Expression libre

L’utilisateur écrit, photographie, filme ou envoie une image.

2. Compréhension par l’IA

L’IA identifie l’intention, les éléments utiles et les éventuelles informations manquantes.

3. Structuration

L’IA reformule, extrait les critères et prépare une offre ou une demande exploitable.

4. Validation

L’utilisateur vérifie, complète ou corrige les informations proposées.

5. Publication ou activation

L’offre ou la demande devient active sur la plateforme.

6. Matching

Le système recherche et identifie les offres ou demandes compatibles.

7. Notification et mise en relation

Les parties sont informées et peuvent accepter le contact.

3.2. Parcours du mode « Je propose »

Exemple : « Je possède une lampe vintage. »

L’utilisateur peut :

1. Envoyer directement son message.
2. Ajouter une ou plusieurs photos.
3. Demander à l’IA de préparer l’offre.
4. Répondre aux questions ciblées de l’IA, si nécessaire.
5. Vérifier la description, les critères et les conditions.
6. Valider et publier.

L’IA peut notamment proposer :

• une description reformulée ;
• une identification présumée de l’objet ;
• des caractéristiques déduites ;
• des informations manquantes à confirmer ;
• une estimation de critères utiles au matching, sans nécessairement imposer une catégorie.

3.3. Parcours du mode « Je cherche »

Exemple : « Je cherche une lampe vintage. »

L’utilisateur peut :

1. Décrire son besoin.
2. Ajouter une photo de référence, si disponible.
3. Préciser son budget ou sa zone, directement ou à la demande de l’IA.
4. Valider la demande.
5. Recevoir des propositions compatibles.
6. Être informé lorsqu’une nouvelle offre correspond à sa recherche.

3.4. Questions ciblées de l’IA

Lorsque les informations sont insuffisantes, l’IA doit pouvoir poser des questions pertinentes.

Exemples :

• « Quel budget souhaitez-vous consacrer à cet achat ? »
• « Dans quelle zone recherchez-vous ce service ? »
• « Pour quelle date ou quelle heure ? »
• « Souhaitez-vous acheter ou louer ? »
• « Le véhicule doit-il être disponible immédiatement ? »
• « Cherchez-vous un joueur amateur ou professionnel ? »

L’objectif n’est pas de reproduire un formulaire, mais de poser uniquement les questions nécessaires à la compréhension et au matching.

IV. Compréhension et structuration par l’intelligence artificielle

4.1. Rôle général de l’IA

L’intelligence artificielle constitue le principal moteur de compréhension de la plateforme.

Elle doit notamment pouvoir :

• interpréter le langage naturel ;
• identifier l’intention de l’utilisateur ;
• distinguer une offre d’une demande ;
• extraire les critères utiles ;
• reconnaître des objets ou des éléments visuels ;
• interpréter des informations temporelles et géographiques ;
• reformuler et compléter une annonce ;
• proposer des questions ciblées ;
• contribuer au classement des correspondances.

4.2. Compréhension de l’intention

L’IA doit chercher à comprendre ce que l’utilisateur veut accomplir, et non uniquement les mots employés.

Exemples :

4.3. Structuration des informations

À partir d’un contenu libre, l’IA doit pouvoir produire une représentation structurée comprenant, selon le cas :

• l’intention principale ;
• l’objet ou le service concerné ;
• les caractéristiques pertinentes ;
• la localisation ;
• la date et l’heure ;
• la disponibilité ;
• le budget ou le prix ;
• les conditions particulières ;
• les éléments visuels ;
• les informations à confirmer.

Cette structuration doit rester adaptative : tous les champs ne sont pas nécessaires pour tous les usages.

4.4. Compréhension des images et vidéos

Le système doit pouvoir exploiter les contenus visuels.

Cas 1 — Objet reconnu

Si l’IA reconnaît un produit ou un objet, elle peut en déduire certains critères :

• nature de l’objet ;
• marque ou modèle présumé ;
• caractéristiques visibles ;
• état apparent ;
• éléments de comparaison.

Ces informations doivent pouvoir être confirmées ou corrigées par l’utilisateur.

Cas 2 — Objet non reconnu

Même si l’objet n’est pas identifié avec précision, le système doit pouvoir :

• conserver les images ;
• comparer les caractéristiques visuelles ;
• rechercher des similarités ;
• proposer des matchs visuels ;
• permettre à l’utilisateur de corriger ou préciser son intention.

Cas 3 — Vidéo

La vidéo peut notamment être utile pour :

• présenter un joueur sportif ;
• montrer le fonctionnement d’un appareil ;
• présenter un véhicule ;
• démontrer une compétence ;
• illustrer un service ou une prestation.

4.5. Amélioration progressive

Le système doit pouvoir apprendre des corrections et validations des utilisateurs.

Exemples :

• correction d’une identification ;
• modification d’un critère ;
• confirmation d’une correspondance ;
• rejet d’un match jugé incorrect ;
• précision apportée à une annonce.

Cette amélioration doit être encadrée par des mécanismes de qualité, de confidentialité et de contrôle.

V. Moteur de matching universel

5.1. Principe

Le moteur de matching constitue le cœur fonctionnel de la plateforme.

Il doit rapprocher :

• une demande et une offre ;
• une offre et une demande ;
• deux profils compatibles ;
• un besoin ponctuel et une disponibilité ;
• un objet recherché et une proposition visuelle similaire.

Le matching ne doit pas dépendre exclusivement d’une correspondance exacte de mots-clés.

5.2. Critères de compatibilité

Selon le domaine, le moteur peut prendre en compte :

• la nature du besoin ;
• les caractéristiques du bien ou du service ;
• la localisation ;
• la distance ;
• la date et l’heure ;
• la disponibilité ;
• le prix ou le budget ;
• l’état ;
• les préférences ;
• les contraintes particulières ;
• la compatibilité visuelle ;
• la fraîcheur de la position ;
• les corrections et validations antérieures.

5.3. Matching multidomaine

Le système doit être capable de traiter des usages très différents avec une logique commune.

Exemple :

« Je cherche un coach de foot pour mon fils, samedi matin à Hydra. »

peut être rapproché de :

« Disponible samedis matins, Hydra, 2 000 DA la séance. »

Le moteur doit comprendre que la correspondance repose sur plusieurs dimensions :

Intention + Objet + Temps + Lieu + Conditions

et non sur une simple identité textuelle.

5.4. Matching visuel

Une recherche peut reposer uniquement sur une image.

Le système doit pouvoir comparer :

• une photo d’un objet recherché ;
• une photo d’un objet proposé ;
• des caractéristiques visuelles ;
• des similarités d’apparence.

Le matching visuel doit être présenté comme une correspondance possible, et non comme une garantie d’identité parfaite.

5.5. Classement des résultats

L’utilisateur doit pouvoir choisir le mode de classement souhaité, notamment :

• Le plus proche
• Le moins cher
• Le plus pertinent
• Le plus proche et le moins cher, selon les possibilités retenues

Le système doit également pouvoir intégrer la fraîcheur des informations de localisation.

5.6. Fraîcheur de la position

Les offres dont la position n’a pas été vérifiée depuis trop longtemps doivent pouvoir être automatiquement placées plus bas dans les résultats.

Cette règle doit être paramétrable et clairement expliquée à l’utilisateur.

Elle peut notamment tenir compte :

• de la date de dernière vérification ;
• de la précision de la position ;
• du consentement de l’utilisateur ;
• de la nature du service ou du bien ;
• de la nécessité réelle d’une localisation actualisée.

VI. Géolocalisation et mode « Meet »

6.1. Principe général

La plateforme doit intégrer une fonction de proximité permettant de détecter une éventuelle compatibilité entre un chercheur et un offreur présents dans une même zone.

Cette fonction est désignée dans le présent document sous le nom de mode Meet, conformément à la vision exprimée par le commanditaire.

6.2. Fonctionnement envisagé

Lorsqu’un chercheur et un offreur :

• ont des intentions compatibles ;
• se trouvent dans un rayon choisi ;
• et ont activé les conditions nécessaires à la proximité ;

le système peut envoyer une alerte aux deux parties.

Les rayons envisagés comprennent :

• 10 mètres ;
• 20 mètres ;
• 50 mètres ;
• 100 mètres ;
• ou une distance libre définie par l’utilisateur.

6.3. Signal neutre

La première notification doit pouvoir rester neutre.

Exemple :

« Une correspondance potentielle se trouve à proximité. »

L’identité de l’autre personne ne doit pas nécessairement être révélée immédiatement.

6.4. Consentement réciproque

Si les deux parties acceptent de se contacter :

• les profils peuvent s’ouvrir ;
• la conversation peut être initiée ;
• le contact peut se faire dans l’application ;
• ou via WhatsApp, selon le choix retenu.

Le système doit éviter qu’une simple proximité géographique entraîne automatiquement une divulgation d’identité ou un contact non désiré.

6.5. Points d’attention

Le mode Meet devra faire l’objet d’une conception spécifique concernant :

• le consentement explicite ;
• la confidentialité de la localisation ;
• la précision et la fraîcheur de la position ;
• la prévention du harcèlement ;
• la maîtrise des notifications ;
• la possibilité de désactivation ;
• la sécurité des échanges ;
• les limites d’utilisation en arrière-plan.

Ces éléments devront être précisés avant toute mise en production.

VII. Domaines d’application

7.1. Principe d’universalité

La plateforme doit pouvoir accueillir les domaines suivants sans imposer à l’utilisateur de choisir une catégorie au préalable.

Les catégories ci-dessous servent principalement à documenter le périmètre fonctionnel envisagé, à organiser les tests et à identifier les besoins spécifiques éventuels.

7.2. Domaines identifiés

VIII. Notifications, préférences et contact

8.1. Notifications personnalisables

Chaque utilisateur doit pouvoir définir ses préférences de notification.

Les paramètres envisagés comprennent :

• tout le pays ;
• une wilaya ;
• une zone géographique ;
• un rayon autour d’un point ;
• un budget ;
• un type de besoin ;
• une disponibilité ;
• une fréquence de notification.

8.2. Activation et désactivation

L’utilisateur doit pouvoir :

• activer ou désactiver les notifications ;
• modifier ses critères ;
• suspendre une demande ;
• réactiver une demande ;
• choisir les types de correspondances qui l’intéressent.

8.3. Contact après correspondance

Le contact doit pouvoir se faire :

• dans l’application ;
• via WhatsApp ;
• ou par un autre canal retenu dans les spécifications ultérieures.

Le passage d’un signal de correspondance à un contact effectif doit rester soumis à l’acceptation des parties, selon les règles définies par la plateforme.

IX. Confiance, sécurité et gouvernance fonctionnelle

9.1. Nécessité d’un cadre de confiance

Une plateforme de mise en relation universelle doit intégrer des mécanismes permettant de limiter :

• les fausses offres ;
• les demandes frauduleuses ;
• les profils fictifs ;
• les contenus illicites ;
• les comportements abusifs ;
• les erreurs d’identification de l’IA ;
• les contacts non désirés.

9.2. Validation et correction

L’utilisateur doit pouvoir :

• corriger les informations extraites par l’IA ;
• modifier une annonce ;
• supprimer une publication ;
• signaler une erreur ;
• signaler un contenu problématique ;
• bloquer un utilisateur ;
• refuser une mise en relation.

9.3. Position et confidentialité

La géolocalisation doit être traitée comme une donnée sensible du fonctionnement de la plateforme.

Le système devra prévoir, selon les choix de conception :

• le consentement à la localisation ;
• la possibilité de désactivation ;
• la maîtrise de la précision communiquée ;
• la conservation limitée des données nécessaires ;
• la protection des informations personnelles ;
• la gestion des autorisations mobiles.

9.4. Responsabilité de la plateforme

La plateforme doit distinguer clairement :

• les informations déclarées par l’utilisateur ;
• les informations déduites par l’IA ;
• les informations vérifiées ;
• les correspondances proposées ;
• les engagements effectivement pris entre les parties.

Une correspondance proposée par l’IA ne doit pas être présentée comme une garantie de qualité, de disponibilité, d’identité ou de conformité.

X. Périmètre fonctionnel envisagé du MVP

10.1. Principe de progressivité

Compte tenu de l’ambition universelle du projet, il est recommandé de distinguer :

• la vision complète, telle qu’exprimée par le commanditaire ;
• le MVP, destiné à valider les parcours essentiels ;
• les évolutions ultérieures, destinées à enrichir progressivement la couverture fonctionnelle.

Le MVP ne doit pas nécessairement implémenter immédiatement toutes les possibilités du projet final.

10.2. Socle fonctionnel recommandé pour le MVP

Le périmètre initial pourrait comprendre :

Création de compte et profil utilisateur

Choix entre « Je propose » et « Je cherche »

Saisie libre en texte

Ajout de photos

Assistance IA pour structurer l’offre ou la demande

Validation et publication

Moteur de matching sur les critères essentiels

Recherche et réception de propositions

Notifications de correspondance

Géolocalisation de base

Contact dans l’application

Administration et modération de base

Important : cette liste constitue une proposition de cadrage initial, et non une validation définitive du périmètre du MVP.

10.3. Fonctionnalités susceptibles d’être déployées progressivement

Selon les arbitrages techniques, budgétaires et opérationnels, les fonctionnalités suivantes pourraient être intégrées dans une phase ultérieure :

• matching visuel avancé ;
• analyse vidéo approfondie ;
• mode Meet complet ;
• détection de proximité en temps réel ;
• intégration WhatsApp ;
• apprentissage avancé à partir des corrections ;
• mécanismes de vérification renforcée ;
• couverture de domaines spécialisés ;
• fonctionnalités professionnelles et B2B avancées ;
• systèmes de réputation ou de confiance ;
• outils analytiques et statistiques.

XI. Architecture fonctionnelle générale

Le présent document ne fixe pas encore l’architecture technique, mais il permet d’identifier les principaux ensembles fonctionnels.

Application mobile

Interface utilisateur et parcours d’expression libre

Couche de compréhension IA

Intention · Structuration · Questions · Reformulation

Moteur de matching

Compatibilité · Classement · Proximité · Fraîcheur

Services de plateforme

Profils · Publications · Notifications · Contact · Administration

Cette représentation est fonctionnelle. Les choix relatifs aux technologies, aux modèles d’IA, aux bases de données, à l’hébergement, à la sécurité et aux intégrations devront faire l’objet d’une étude technique distincte.

XII. Questions à arbitrer avec le commanditaire

Avant de figer le cahier des charges définitif, plusieurs points devront être précisés avec Monsieur MELLAH Riadh.

12.1. Positionnement et modèle économique

• L’application sera-t-elle gratuite pour tous les utilisateurs ?
• Un modèle freemium est-il envisagé ?
• Des options payantes seront-elles proposées ?
• La plateforme sera-t-elle généraliste dès le lancement ou commencera-t-elle par quelques domaines prioritaires ?
• Le projet vise-t-il d’abord l’Algérie ou un déploiement international dès la première version ?

12.2. Périmètre du MVP

• Quelles fonctionnalités doivent impérativement être présentes dans la première version ?
• Le mode Meet doit-il être inclus dès le MVP ?
• La vidéo doit-elle être prise en charge dès le lancement ?
• Le matching visuel doit-il être opérationnel dès la première version ?
• Quels domaines serviront de cas d’usage prioritaires pour les tests ?

12.3. Géolocalisation et mode Meet

• La localisation sera-t-elle obligatoire ou facultative ?
• Les rayons de 10, 20, 50 et 100 mètres sont-ils définitifs ?
• L’utilisateur pourra-t-il définir un rayon libre ?
• Quelle durée de validité sera retenue pour la position ?
• Le signal neutre devra-t-il être activé par défaut ou uniquement sur demande ?
• Le contact via WhatsApp sera-t-il intégré dès le lancement ?

12.4. Intelligence artificielle

• Quels niveaux d’assistance sont attendus ?
• L’IA doit-elle seulement structurer ou également recommander ?
• Quelles langues doivent être prises en charge au lancement ?
• Les contenus en arabe, français, anglais et dialecte algérien doivent-ils être traités ?
• Quelle place sera accordée à la validation humaine des informations déduites ?
• Quelles données pourront être utilisées pour améliorer le système ?

12.5. Confiance et modération

• Une vérification d’identité est-elle prévue ?
• Quel système de signalement doit être intégré ?
• Des profils professionnels vérifiés seront-ils proposés ?
• Quelles règles s’appliqueront aux offres réglementées ou sensibles ?
• Quel niveau de modération humaine sera nécessaire ?

12.6. Exploitation et propriété

• Qui sera propriétaire de l’application, du code et des données ?
• Qui assurera l’hébergement et l’exploitation ?
• Qui prendra en charge les coûts des services d’IA et d’infrastructure ?
• Quel sera le rôle exact de QuentumSpace après la livraison ?
• Quelles seront les modalités de maintenance et d’évolution ?

XIII. Évolutions futures envisageables

La vision exprimée par Monsieur MELLAH permet d’envisager une évolution progressive vers une plateforme capable de devenir un véritable réseau intelligent de mise en relation.

Parmi les évolutions possibles :

• recherche et matching vocal ;
• compréhension avancée des vidéos ;
• recommandations personnalisées ;
• matching prédictif ;
• détection de disponibilité en temps réel ;
• profils professionnels enrichis ;
• vérification de compétences ou de documents ;
• systèmes de réputation ;
• paiements intégrés ;
• réservation de services ;
• gestion de contrats ou de transactions ;
• outils professionnels B2B ;
• intégration de partenaires externes ;
• extension internationale ;
• mécanismes de traduction et d’interprétation multilingue.

Ces évolutions ne font pas partie automatiquement du périmètre initial. Elles constituent une réserve de développement permettant de préserver l’ambition du projet.

XIV. Synthèse fonctionnelle

Le projet peut être résumé par le schéma suivant :

Une intention libre

Texte · Photo · Vidéo · Photo seule

L’intelligence artificielle

Comprend · Structure · Complète · Reformule

Le matching universel

Offres ↔ Demandes · Critères · Temps · Lieu · Budget

La mise en relation

Notification · Consentement · Contact · Proximité

 Conclusion

Le projet commandé à QuentumSpace par  SCI présente une ambition claire : transformer la manière dont les personnes expriment leurs besoins et trouvent des offres, en remplaçant la logique traditionnelle des catégories par une logique d’intention, de compréhension et de rapprochement intelligent.

L’application doit permettre à un utilisateur de dire simplement :

« Je cherche… »

ou :

« Je propose… »

puis de laisser l’intelligence artificielle prendre en charge la complexité de la structuration et du matching.

La valeur du projet réside donc moins dans la multiplication des catégories que dans la capacité du système à comprendre des situations humaines variées et à identifier des compatibilités pertinentes.

Pour QuentumSpace, la prochaine étape consiste à transformer cette vision en un cahier des charges fonctionnel détaillé, puis en une étude technique et un plan de développement, en distinguant le MVP, les fonctionnalités avancées et les évolutions futures.

Statut du document

Document suivant : Cahier des charges fonctionnel détaillé — V0.1, avec les écrans, les parcours, les règles métier, les cas d’usage, les critères d’acceptation et la distinction précise entre MVP et évolutions.