KAIROS

Cahier des charges fonctionnel détaillé — MVP V0.1

Plateforme intelligente de mise en relation universelle par l’intention

Version : 0.1
Statut : Document de travail — À valider

Commanditaire : SCI

Opérateur de conception et de développement :

www.quentumspace.com

Documents de référence :

• KAIROS — Document de cadrage V0.1 https://spacesortium.com/read-blog?id=1859

• KAIROS — Modèle conceptuel canonique V0.1 https://spacesortium.com/read-blog?id=1870

1. Objet du document

Le présent cahier des charges définit le périmètre fonctionnel détaillé du MVP de KAIROS.

Il traduit en comportements applicatifs les principes formulés dans le document de cadrage et dans le Modèle conceptuel canonique.

Il doit permettre de répondre précisément aux questions suivantes :

• que peut faire l’utilisateur ;

• quels écrans lui sont présentés ;

• comment une intention est créée ;

• comment l’intelligence artificielle l’interprète ;

• quelles informations doivent être confirmées ;

• comment une intention devient active ;

• comment les correspondances sont détectées ;

• comment elles sont classées ;

• comment elles sont expliquées ;

• quand une notification doit être envoyée ;

• comment le consentement intervient ;

• comment une mise en relation est ouverte ;

• comment un utilisateur peut refuser, bloquer ou signaler ;

• comment les intentions expirent ou sont clôturées ;

• comment le système recueille du feedback ;

• quelles fonctions appartiennent réellement au MVP.

Ce document ne définit pas encore l’architecture technique détaillée ni le choix des technologies.

2. Finalité du MVP

Le MVP doit démontrer une hypothèse fondamentale :

Une même architecture d’intention peut comprendre et rapprocher des besoins humains appartenant à des domaines différents, sans obliger l’utilisateur à commencer par choisir une catégorie.

Le MVP doit donc démontrer la chaîne complète :

Expression libre

→ Compréhension

→ Structuration

→ Clarification éventuelle

→ Validation

→ Activation

→ Matching

→ Ranking

→ Notification

→ Consentement

→ Connection

→ Feedback

3. Principe fonctionnel directeur

Dans une plateforme traditionnelle, l’utilisateur doit comprendre la structure de la plateforme.

Il choisit généralement :

Catégorie → Sous-catégorie → Formulaire → Critères → Publication

KAIROS inverse cette relation.

L’utilisateur exprime simplement ce qu’il veut.

Le système prend en charge la complexité nécessaire pour transformer cette expression en représentation exploitable.

La doctrine fonctionnelle du produit est donc :

L’utilisateur exprime. KAIROS structure. L’utilisateur valide. KAIROS rapproche. Les personnes décident.

Figure F1 — Vue fonctionnelle globale du MVP KAIROS : parcours complet d’une intention, de son expression initiale à son interprétation, sa validation, son activation, son matching, son classement, sa notification, son consentement et sa mise en relation, avec les couches transverses d’identité, de confidentialité, de localisation, de confiance, de modération et d’administration.

4. Périmètre fonctionnel du MVP

Le MVP doit comprendre les fonctions suivantes :

5. Fonctions exclues du MVP

Les fonctionnalités suivantes sont considérées comme des évolutions ultérieures sauf décision contraire du commanditaire :

• vidéo avancée ;

• analyse vidéo profonde ;

• matching visuel avancé ;

• recherche vocale complète ;

• mode Meet temps réel complet ;

• suivi permanent de proximité ;

• paiement ;

• réservation ;

• signature de contrats ;

• réputation complexe ;

• certification de compétences avancée ;

• profils professionnels premium ;

• traduction instantanée avancée ;

• recommandations prédictives ;

• intégration WhatsApp native ;

• marketplace transactionnelle ;

• matching international avancé ;

• intelligence prédictive de disponibilité.

Cette séparation est essentielle afin d’éviter qu’un MVP de validation devienne prématurément une plateforme universelle complète.

Figure F2 — Périmètre fonctionnel du MVP KAIROS : distinction entre les fonctionnalités incluses dès la version V0.1, les capacités préparées mais volontairement limitées, et les évolutions prévues pour les versions ultérieures afin de maîtriser le périmètre de développement et la montée en puissance du produit.

6. Acteurs fonctionnels

6.1 Utilisateur

Personne disposant d’un compte KAIROS.

Elle peut :

• créer un profil ;

• exprimer des intentions ;

• les modifier ;

• les suspendre ;

• recevoir des propositions ;

• accepter ou refuser une mise en relation ;

• échanger ;

• signaler ;

• bloquer ;

• fournir du feedback.

6.2 Modérateur

Personne autorisée à traiter :

• signalements ;

• contenus problématiques ;

• comportements abusifs ;

• intentions interdites ;

• comptes suspects.

6.3 Administrateur

Dispose de fonctions de gestion :

• utilisateurs ;

• Domain Models ;

• politiques fonctionnelles ;

• modération ;

• métriques ;

• configuration de certains seuils.

6.4 Intelligence KAIROS

La couche IA peut :

• interpréter ;

• extraire ;

• reformuler ;

• identifier les informations manquantes ;

• proposer une structuration ;

• contribuer au matching ;

• contribuer au classement.

Elle ne possède pas le pouvoir de transformer une inférence en vérité sans mécanisme de validation approprié.

Figure F3 — Acteurs et responsabilités fonctionnelles du MVP KAIROS : répartition des rôles entre l’utilisateur, l’intelligence KAIROS, le système, le modérateur et l’administrateur, avec séparation claire entre expression, compréhension, proposition, gouvernance, supervision et contrôle humain.

7. Objets métier principaux

Le MVP doit implémenter au minimum les objets conceptuels suivants :

User

Profile

Expression

Intent

Intent Frame

Assertion

Clarification

Media

Match Candidate

Ranking Result

Notification

Consent

Connection

Location

Freshness

Verification Claim

Feedback Signal

Report

Block

8. Écran d’accueil

L’écran d’accueil doit permettre à l’utilisateur de comprendre immédiatement la proposition de valeur.

Il doit notamment offrir deux actions principales :

Je cherche

Pour exprimer un besoin.

Je propose

Pour exprimer une offre, une disponibilité, un bien, un service ou une compétence.

Une zone d’expression directe pourra être proposée dès l’accueil.

Exemple :

Que cherchez-vous ou que souhaitez-vous proposer ?

9. Création de compte

FR-KAI-001

L’utilisateur doit pouvoir créer un compte.

Le MVP doit au minimum supporter :

• nom ou pseudonyme selon politique retenue ;

• téléphone ou e-mail ;

• mot de passe ou mécanisme d’authentification retenu ;

• acceptation des conditions d’utilisation ;

• acceptation de la politique de confidentialité.

FR-KAI-002

Le système doit pouvoir vérifier au minimum un canal de contact.

Exemple :

Téléphone vérifié ou e-mail vérifié.

10. Profil utilisateur

Le Profil doit être distinct des Intentions.

Un utilisateur peut avoir plusieurs intentions actives simultanément.

Exemple :

Amir

• cherche un appartement ;

• vend un ordinateur ;

• propose des cours ;

• cherche un graphiste.

Le profil peut comprendre :

• identité affichée ;

• photo facultative ;

• zone générale ;

• langue ;

• préférences ;

• vérifications éventuelles ;

• intentions actives ;

• intentions clôturées selon politique.

11. Création d’une intention

FR-KAI-010

L’utilisateur doit pouvoir lancer une nouvelle intention depuis :

• l’accueil ;

• son espace personnel ;

• un bouton principal « + ».

FR-KAI-011

Il doit choisir l’orientation initiale :

SEEK

Je cherche / j’ai besoin

ou

OFFER

Je propose / je vends / je suis disponible

Cette orientation pourra être corrigée si l’IA détecte une ambiguïté.

12. Expression libre

L’utilisateur ne doit pas être obligé de remplir préalablement une liste de champs.

FR-KAI-020

Il doit pouvoir fournir une expression textuelle libre.

Exemple :

Je cherche une lampe vintage à Alger pour moins de 15 000 DA.

FR-KAI-021

Il doit pouvoir joindre une ou plusieurs photographies.

FR-KAI-022

La structure interne de la plateforme ne doit pas exiger le choix préalable d’une catégorie.

13. Conservation de l’expression originale

L’Expression constitue la source originale.

KAIROS doit conserver la distinction entre :

ce que l’utilisateur a réellement fourni

et

ce que l’IA en a déduit.

Exemple :

Utilisateur :

« Je cherche cette lampe. »

Photo jointe.

IA :

« Type supposé : lampe vintage de table »

Le second élément est une inférence.

Il ne doit jamais remplacer silencieusement le premier.

14. Interprétation par l’IA

FR-KAI-030

Après soumission, KAIROS analyse l’expression.

L’IA peut notamment identifier :

• SEEK ou OFFER ;

• action recherchée ;

• objet ;

• service ;

• personne ;

• compétence ;

• lieu ;

• période ;

• disponibilité ;

• prix ;

• budget ;

• caractéristiques ;

• contraintes ;

• préférences.

15. Construction de l’Intent Frame

L’analyse doit produire un Intent Frame exploitable.

Exemple :

orientation: SEEK

action: OBTAIN_SERVICE

object: football_coaching

beneficiary: child

location: Hydra

time: Saturday morning

 budget_max: 2500 DZD

Tous les attributs ne sont pas obligatoires.

Le modèle doit rester adaptatif.

16. Provenance des informations

Chaque information importante doit pouvoir être associée à sa provenance.

Les statuts fondamentaux sont :

DECLARED

Déclarée explicitement par l’utilisateur.

INFERRED

Déduite par l’IA.

CONFIRMED

Confirmée par l’utilisateur.

VERIFIED

Vérifiée par un mécanisme reconnu.

DISPUTED

Contestée ou corrigée.

Exemple :

Figure F5 — Construction de l’Intent Frame et traçabilité de la provenance des informations dans KAIROS : à partir de l’expression multimodale de l’utilisateur, l’IA extrait et structure les attributs, distingue les éléments déclarés des informations inférées, associe un niveau de confiance à chaque donnée, puis soumet l’ensemble à la validation ou à la correction de l’utilisateur.

17. Clarification

KAIROS doit pouvoir identifier les informations réellement nécessaires qui manquent.

FR-KAI-040

Une clarification ne doit être déclenchée que lorsqu’elle améliore significativement :

• compréhension ;

• matching ;

• sécurité ;

• faisabilité.

Exemple :

Utilisateur :

Je cherche un coach de football.

KAIROS peut demander :

Dans quelle zone ?

puis éventuellement :

Pour quel jour ou quelle période ?

Il ne doit pas automatiquement transformer l’échange en questionnaire exhaustif.

La doctrine reste :

Demander le minimum nécessaire, au moment où cela devient nécessaire.

18. Validation de l’intention

Avant activation, l’utilisateur doit pouvoir visualiser ce que KAIROS a compris.

L’écran présente par exemple :

Vous cherchez :

Coach de football

Pour :

Votre enfant

Lieu :

Hydra

Quand :

Samedi matin

Budget :

Maximum 2 500 DA

L’utilisateur doit pouvoir :

• valider ;

• modifier ;

• supprimer un attribut ;

• répondre à une clarification.

Figure F4 — Parcours fonctionnel de création et d’activation d’une Intention dans KAIROS : expression libre de l’utilisateur, analyse par l’IA, clarification éventuelle, construction de l’Intent Frame, validation et correction par l’utilisateur, puis activation de l’Intention pour son entrée dans le processus de matching.

19. Activation

Après validation, l’Intent passe à l’état :

ACTIVE

L’intention devient alors éligible au matching.

Elle doit être :

• indexée ;

• disponible pour le moteur de matching ;

• visible selon sa politique de visibilité ;

• modifiable par son propriétaire.

20. Machine d’états de l’Intention

Le cycle minimum est :

DRAFT

→ SUBMITTED

→ INTERPRETING

→ éventuellement NEEDS_CLARIFICATION

→ READY_FOR_VALIDATION

→ VALIDATED

→ ACTIVE

Puis :

• PAUSED

• FULFILLED

• EXPIRED

• CANCELLED

et finalement :

CLOSED

Figure F6 — Fonctionnement du moteur de matching par intention de KAIROS : analyse sémantique et contextuelle des intentions actives, évaluation multicritère des correspondances, classement des résultats pertinents et accompagnement de l’utilisateur jusqu’à l’initiation d’une mise en relation choisie et consentie.

21. Modification d’une intention active

FR-KAI-050

L’utilisateur doit pouvoir modifier une Intention active.

Une modification importante peut déclencher :

• nouvelle interprétation ;

• nouvelle validation ;

• recalcul des matchs.

Exemple :

Budget :

15 000 DA → 20 000 DA

Les correspondances doivent pouvoir être recalculées.

22. Suspension

L’utilisateur doit pouvoir suspendre une Intention.

État :

PAUSED

Une intention suspendue :

• n’est plus utilisée pour de nouveaux matchs ;

• n’est pas supprimée ;

• peut être réactivée.

23. Accomplissement

L’utilisateur peut déclarer une intention :

FULFILLED

Exemple :

J’ai trouvé mon coach.

KAIROS peut alors demander un feedback.

24. Expiration

Certaines intentions peuvent posséder une date ou une période de validité.

Exemple :

Je cherche un photographe pour samedi prochain.

Après la date, l’Intention peut passer automatiquement en :

EXPIRED

Le système peut demander :

Cette recherche est-elle toujours d’actualité ?

25. Domain Models

KAIROS doit utiliser un noyau commun tout en permettant des enrichissements par domaine.

Exemple automobile :

• marque ;

• modèle ;

• année ;

• prix.

Exemple service :

• compétence ;

• disponibilité ;

• zone ;

• tarif.

Exemple logement :

• type ;

• location/achat ;

• surface ;

• budget ;

• localisation.

Ces structures doivent être utilisées pour améliorer la compréhension et le matching sans imposer à l’utilisateur un formulaire catégoriel au début de son parcours.

Figure F7 — Architecture fonctionnelle du MVP KAIROS : articulation entre les données d’entrée, le cœur intelligent de la plateforme — compréhension, structuration de l’intention, matching et apprentissage — et les sorties opérationnelles destinées à l’utilisateur, sous les principes transverses de sécurité, de gouvernance, de contrôle humain, de confiance et d’évolutivité.

26. Matching Engine

Le moteur recherche des intentions complémentaires.

Le principe n’est donc pas simplement :

trouver deux contenus similaires.

Mais :

trouver deux intentions susceptibles de se satisfaire mutuellement.

Exemple :

SEEK

Je cherche un coach de football samedi matin à Hydra.

et :

OFFER

Coach disponible à Hydra le samedi matin.

27. Facteurs de matching

Le MVP doit pouvoir considérer notamment :

• compatibilité sémantique ;

• objet/service ;

• localisation ;

• distance ;

• temporalité ;

• disponibilité ;

• budget ;

• prix ;

• préférences ;

• contraintes ;

• fraîcheur des données.

28. Match Candidate

Lorsqu’une compatibilité suffisante existe, KAIROS crée un :

MATCH CANDIDATE

Il représente une hypothèse de compatibilité.

Il ne constitue ni une garantie ni une mise en relation.

29. Score multidimensionnel

Le système doit pouvoir conserver plusieurs dimensions.

Exemple :

semantic_match 0.94

location_match 0.90

time_match 1.00

 budget_match 1.00

availability_match 0.88

freshness 0.95

Un score global peut être calculé pour le classement.

Cependant, les facteurs doivent rester conceptuellement distincts.

30. Ranking

Le moteur doit classer les Match Candidates.

Le MVP doit permettre au minimum :

• le plus pertinent ;

• le plus proche ;

• le moins cher ;

• classement par défaut KAIROS.

L’architecture doit permettre ultérieurement des politiques personnalisées.

31. Explicabilité

Chaque proposition importante doit pouvoir être accompagnée d’une explication.

Exemple :

Pourquoi cette proposition ?

• correspond à votre recherche ;

• située à 1,8 km ;

• disponible samedi matin ;

• tarif inférieur à votre budget ;

• disponibilité récemment confirmée.

Cette fonction est fondamentale pour la confiance.

32. Fraîcheur

Certaines informations possèdent une durée de validité.

Exemples :

• position ;

• disponibilité ;

• prix ;

• horaires.

KAIROS doit pouvoir distinguer :

À JOUR

Information récente.

À REVALIDER

Information dont la fiabilité temporelle diminue.

OBSOLÈTE

Information trop ancienne pour être utilisée normalement.

Figure F8 — Séquence d’interactions et flux de données du MVP KAIROS : circulation coordonnée des actions utilisateur, traitements IA, données, notifications et décisions depuis l’expression initiale d’un besoin jusqu’à la présentation des résultats, la mise en relation sécurisée et le suivi de l’interaction.

33. Géolocalisation du MVP

La géolocalisation doit être facultative selon les usages.

Le MVP doit permettre :

• pays ;

• wilaya ;

• commune ;

• zone approximative ;

• rayon.

La position précise ne doit pas être nécessairement communiquée à l’autre partie.

Principe :

Utiliser une localisation pour matcher ne signifie pas la divulguer.

Figure F9 — Parcours utilisateur du MVP KAIROS : de l’expression initiale du besoin à la mise en relation, en passant par la clarification assistée par l’IA, la découverte de résultats pertinents, leur comparaison, l’initiation du contact et le suivi de l’échange dans une expérience simple, sécurisée et maîtrisée.

34. Notifications

L’utilisateur doit être averti lorsqu’une correspondance suffisamment pertinente apparaît.

Exemple :

3 nouvelles opportunités correspondent à votre recherche.

L’utilisateur doit pouvoir gérer :

• notifications activées/désactivées ;

• fréquence ;

• intentions concernées.

35. Écran de résultats

Pour une intention active, KAIROS affiche les propositions classées.

Chaque carte peut présenter :

• titre ;

• distance ou zone ;

• prix ;

• disponibilité ;

• éléments pertinents ;

• niveau de compatibilité ;

• explication.

L’utilisateur peut :

• consulter ;

• accepter une proposition ;

• ignorer ;

• masquer ;

• signaler.

36. Consentement

Le matching ne doit jamais ouvrir automatiquement une relation.

Le système doit recueillir un consentement approprié.

Exemple :

Souhaitez-vous entrer en contact avec cette personne ?

L’utilisateur peut :

Accepter

ou

Refuser.

37. Consentement réciproque

Pour certains modes de relation, la Connection ne s’ouvre qu’après consentement mutuel.

Conceptuellement :

A accepte B

B accepte A

→ MUTUAL_ACCEPTED

→ CONNECTION_OPEN

38. Connection

Une fois ouverte, la Connection permet au minimum :

• échange de messages ;

• consultation des informations autorisées ;

• fermeture de la relation ;

• signalement ;

• blocage.

Le partage d’informations personnelles supplémentaires reste soumis aux politiques définies.

39. Messagerie MVP

Le MVP doit intégrer une messagerie simple.

Fonctions minimales :

• envoyer texte ;

• recevoir texte ;

• voir les messages ;

• connaître l’Intention à l’origine de la Connection ;

• bloquer ;

• signaler.

Figure F10 — Vision de KAIROS comme infrastructure de mise en relation intentionnelle : connexion des talents, projets, entreprises, territoires et acteurs de la société afin de transformer les intentions exprimées aujourd’hui en opportunités concrètes, collaborations utiles et impacts durables demain.

40. Mode Meet

Le Meet complet n’est pas nécessairement inclus dans le MVP.

Toutefois, son architecture fonctionnelle doit être anticipée.

Le principe futur est :

Compatibilité

Proximité

Meet activé A

Meet activé B

→ Meet Signal

La première notification pourra rester neutre :

Une correspondance potentielle se trouve à proximité.

La position exacte de l’autre personne ne doit pas être révélée automatiquement.

41. Confiance

Le système doit distinguer :

Identité

Vérification

Réputation

Compatibilité

Une personne très compatible n’est pas nécessairement vérifiée.

Une personne vérifiée n’est pas nécessairement compatible.

42. Vérifications MVP

Le MVP peut au minimum prendre en charge :

• e-mail vérifié ;

• téléphone vérifié.

L’architecture doit permettre ultérieurement :

• identité vérifiée ;

• entreprise vérifiée ;

• document vérifié ;

• compétence vérifiée.

43. Block

Un utilisateur doit pouvoir bloquer un autre utilisateur.

Le Block doit empêcher :

• nouveau matching direct approprié ;

• messages ;

• notifications relationnelles ;

• nouvelles Connections.

44. Report

L’utilisateur doit pouvoir signaler :

• profil ;

• intention ;

• message ;

• comportement ;

• contenu.

Les catégories peuvent comprendre :

• fraude ;

• harcèlement ;

• contenu illicite ;

• fausse information ;

• spam ;

• autre.

45. Modération

Une interface de modération doit permettre :

• consultation des signalements ;

• historique utile ;

• décision ;

• avertissement ;

• suppression de contenu ;

• suspension de compte ;

• clôture du signalement.

Figure F10 — Vision de KAIROS comme infrastructure de mise en relation intentionnelle : connexion des talents, projets, entreprises, territoires et acteurs de la société afin de transformer les intentions exprimées aujourd’hui en opportunités concrètes, collaborations utiles et impacts durables demain.

46. Administration

L’administration MVP doit permettre au minimum :

Utilisateurs

• recherche ;

• consultation ;

• suspension.

Intentions

• consultation ;

• désactivation.

Signalements

• traitement.

Domain Models

• consultation/configuration basique.

Indicateurs

• nombre d’utilisateurs ;

• intentions ;

• matchs ;

• Connections ;

• signalements.

47. Feedback

Après interaction, KAIROS peut demander :

Cette proposition était-elle pertinente ?

ou :

Avez-vous trouvé ce que vous cherchiez ?

Réponses possibles :

• oui ;

• non ;

• partiellement.

Le feedback peut également préciser :

• mauvaise compréhension ;

• mauvaise localisation ;

• indisponibilité ;

• prix incorrect ;

• proposition pertinente.

48. Apprentissage

Les Feedback Signals peuvent contribuer à l’amélioration du système.

Toutefois :

un feedback opérationnel ne devient pas automatiquement une donnée d’entraînement.

Les données destinées à entraîner ou ajuster des modèles devront relever d’une politique distincte.

Figure F12 — Vision de l’impact durable de KAIROS : transformation progressive des intentions d’aujourd’hui en réalisations de demain, à travers des opportunités mieux connectées, des organisations plus performantes, des territoires plus attractifs, une croissance partagée et un impact durable au service des générations futures.

49. Confidentialité

KAIROS doit fonctionner selon un principe de minimisation.

Ne doivent être collectées ou conservées que les informations nécessaires à :

• fournir le service ;

• effectuer le matching ;

• permettre la mise en relation ;

• assurer la sécurité ;

• respecter les obligations applicables ;

• améliorer légitimement le service.

50. Informations sensibles

Une attention particulière doit être portée à :

• localisation précise ;

• identité ;

• téléphone ;

• e-mail ;

• conversations ;

• photos ;

• informations potentiellement sensibles déduites par l’IA.

51. Principe de non-divulgation

Une information utilisée par KAIROS pour effectuer un calcul ne doit pas nécessairement être communiquée à l’autre partie.

Exemple :

KAIROS peut savoir :

distance = 34 mètres

mais afficher uniquement :

À proximité.

52. Cas d’usage MVP n°1 — Objet

Expression

Je cherche une lampe vintage à Alger, maximum 15 000 DA.

Attendu

KAIROS identifie :

• SEEK ;

• objet = lampe ;

• style = vintage ;

• localisation = Alger ;

• budget ≤ 15 000 DA.

Le système cherche les offres complémentaires.

53. Cas d’usage MVP n°2 — Service

Expression

Je cherche un coach de football pour mon fils samedi matin à Hydra.

Attendu

KAIROS identifie :

• SEEK ;

• service = coaching football ;

• bénéficiaire = enfant ;

• jour = samedi ;

• période = matin ;

• localisation = Hydra.

Si le budget manque mais que des résultats peuvent déjà être proposés, KAIROS peut ne pas bloquer immédiatement l’intention.

54. Cas d’usage MVP n°3 — Compétence

Expression

Je suis graphiste et disponible cette semaine.

Attendu

KAIROS identifie :

• OFFER ;

• compétence = graphisme ;

• disponibilité = semaine courante.

Le moteur peut ensuite rapprocher cette intention de besoins complémentaires.

55. Critères d’acceptation fondamentaux

Le MVP sera considéré conceptuellement valide si les trois cas précédents utilisent la même chaîne fonctionnelle fondamentale, sans développement d’un parcours entièrement différent pour chaque domaine.

Autrement dit :

Objet

Service

Compétence

doivent être représentables avec :

Expression → Intent Frame → Intent → Matching → Match Candidate → Consent → Connection

Figure F13 — Vision prospective de KAIROS : mise en réseau des talents, des porteurs de projets, des organisations, des territoires et de la société autour d’un même écosystème d’opportunités, afin de transformer les intentions d’aujourd’hui en collaborations, réalisations et impacts durables pour l’Algérie de demain.

56. Critère d’acceptation — interprétation

Étant donné

qu’un utilisateur saisit :

Je cherche une lampe vintage à Alger.

Quand

KAIROS analyse son expression.

Alors

le système doit :

• reconnaître une orientation SEEK ;

• identifier l’objet « lampe » ;

• identifier « vintage » comme caractéristique ;

• identifier Alger comme localisation ;

• distinguer ce qui a été déclaré de ce qui a été inféré.

57. Critère d’acceptation — clarification

Étant donné

qu’une donnée nécessaire au matching manque.

Quand

le système estime que cette information est importante.

Alors

KAIROS peut poser une question ciblée.

Mais :

aucune clarification non nécessaire ne doit empêcher arbitrairement l’activation d’une intention suffisamment exploitable.

58. Critère d’acceptation — validation

Avant activation :

l’utilisateur doit pouvoir voir et corriger la représentation que KAIROS a construite de son intention.

59. Critère d’acceptation — matching

Un Match Candidate ne peut être généré que si les Intentions présentent une compatibilité fonctionnelle suffisante selon la politique active.

La simple présence des mêmes mots ne suffit pas.

60. Critère d’acceptation — consentement

Aucune Connection nécessitant un accord mutuel ne doit être ouverte sans les consentements requis.

61. Critère d’acceptation — blocage

Un Block actif doit avoir priorité sur toute proposition de mise en relation entre les utilisateurs concernés selon la politique retenue.

62. Principaux écrans du MVP

Le MVP devrait prévoir au minimum :

1. Splash / démarrage

2. Connexion / inscription

3. Onboarding

4. Accueil

5. Je cherche / Je propose

6. Expression d’une intention

7. Ajout de photo

8. Clarification IA

9. Validation Intent Frame

10. Intention active

11. Liste des intentions

12. Résultats / Match Candidates

13. Détail d’un Match

14. Explication du Match

15. Consentement

16. Connection

17. Messagerie

18. Profil

19. Préférences

20. Notifications

21. Report

22. Block

23. Administration

24. Modération

63. Navigation principale proposée

Une première navigation mobile pourrait comprendre :

Accueil

Intentions

Opportunités

Messages

Profil

Le bouton de création d’une nouvelle intention doit rester particulièrement visible.

Figure F14 — Vision de l’écosystème KAIROS : mise en réseau des talents, porteurs de projets, entreprises, territoires, acteurs de l’innovation et société autour d’une même intelligence des opportunités, afin de favoriser davantage d’emplois, de collaborations, d’innovation, d’attractivité territoriale et d’impact durable.

64. Indicateurs fonctionnels du MVP

La phase pilote devrait mesurer notamment :

Compréhension

Taux d’Intent Frames validés sans correction majeure.

Clarification

Nombre moyen de questions nécessaires avant activation.

Matching

Taux de Match Candidates consultés.

Pertinence

Taux de propositions déclarées pertinentes.

Mise en relation

Taux de Match Candidates aboutissant à une Connection.

Résultat

Taux d’Intentions déclarées FULFILLED.

Sécurité

Taux de signalements et blocages.

65. Métrique particulièrement importante

Une mesure essentielle pourrait être :

Time to Relevant Opportunity

c’est-à-dire :

le temps écoulé entre l’expression initiale de l’utilisateur et la présentation de sa première opportunité réellement pertinente.

Cette métrique correspond directement à la promesse de KAIROS :

la bonne rencontre au bon moment.

66. Invariants fonctionnels du MVP

1. L’utilisateur n’est pas obligé de commencer par une catégorie.

2. L’expression originale doit rester distinguable de l’interprétation IA.

3. Une information inférée n’est pas automatiquement une vérité.

4. L’utilisateur peut corriger l’IA.

5. L’Intention constitue l’objet central.

6. Une Intention peut exister sans annonce publique traditionnelle.

7. Matching ≠ Ranking.

8. Matching ≠ Connection.

9. Proximité ≠ consentement.

10. Utiliser une localisation ≠ la divulguer.

11. L’utilisateur garde le contrôle de ses Intentions.

12. Le Block prévaut sur la mise en relation.

13. KAIROS doit pouvoir expliquer une proposition importante.

14. Les informations temporelles doivent gérer leur fraîcheur.

15. L’universalité ne supprime pas les politiques propres aux domaines.

67. Arbitrages à obtenir du commanditaire

Avant gel de la V1.0 du cahier des charges, plusieurs décisions devront être prises avec Monsieur MELLAH.

Positionnement

• Algérie uniquement au lancement ?

• International dès le MVP ?

• Généraliste immédiatement ?

• Domaines pilotes prioritaires ?

Identité

• pseudonyme autorisé ?

• identité réelle obligatoire ?

• vérification d’identité dès le MVP ?

IA

• français ?

• arabe ?

• arabe algérien ?

• anglais ?

Matching

• score visible ou non ?

• seuil minimal ?

• nombre maximal de propositions ?

Géolocalisation

• précision autorisée ;

• durée de validité ;

• géolocalisation obligatoire ou non.

Meet

• MVP ou phase ultérieure ?

Communication

• messagerie uniquement ?

• WhatsApp ?

• téléphone ?

Modèle économique

• gratuit ;

• freemium ;

• abonnement ;

• paiement par service ;

• offre professionnelle.

68. Définition de Done du MVP

Le MVP pourra être considéré comme fonctionnellement complet lorsque :

• un utilisateur peut créer son compte ;

• créer une Intention SEEK ou OFFER ;

• l’exprimer librement ;

• joindre une photo ;

• recevoir une interprétation IA ;

• corriger ou confirmer celle-ci ;

• activer l’Intention ;

• recevoir des Match Candidates ;

• comprendre pourquoi ils sont proposés ;

• accepter ou refuser ;

• ouvrir une Connection lorsque les règles le permettent ;

• échanger ;

• clôturer l’Intention ;

• fournir du feedback ;

• bloquer ou signaler ;

• et lorsqu’un administrateur peut superviser les opérations essentielles.

69. Résultat attendu du MVP

Le MVP n’a pas pour objectif de prouver que KAIROS sait déjà couvrir tous les secteurs de la vie humaine.

Il doit prouver quelque chose de plus fondamental :

qu’un même langage conceptuel et un même moteur peuvent transformer différentes formes d’intentions humaines en opportunités pertinentes sans imposer préalablement aux utilisateurs la structure interne du système.

70. Formule fonctionnelle de référence

La formule fonctionnelle du MVP devient :

JE M’EXPRIME

↓

KAIROS COMPREND

↓

JE VALIDE

↓

MON INTENTION DEVIENT ACTIVE

↓

KAIROS IDENTIFIE DES COMPLÉMENTARITÉS

↓

IL LES CLASSE ET LES EXPLIQUE

↓

JE CHOISIS

↓

L’AUTRE PARTIE CHOISIT

↓

LA CONNECTION S’OUVRE

↓

L’EXPÉRIENCE AMÉLIORE LE SYSTÈME

Conclusion

Ce cahier des charges fonctionnel marque une nouvelle étape dans la maturation de KAIROS.

Le document de cadrage définissait la vision.

Le Modèle conceptuel canonique définissait le langage fondamental du système.

Le présent Cahier des charges fonctionnel détaillé commence à transformer ce langage en comportements concrets et testables.

KAIROS peut désormais être décrit non plus seulement comme une idée ou comme une architecture conceptuelle, mais comme un produit dont les parcours, règles, états, responsabilités et conditions d’acceptation peuvent être spécifiés puis implémentés.

La prochaine étape documentaire sera donc :

KAIROS — Architecture technique de référence — V0.1

Elle devra traduire ce cahier fonctionnel en composants logiciels réels : services, moteurs IA, modèles de données, API, architecture de matching, stockage, sécurité, géolocalisation, notifications, observabilité et infrastructure de déploiement.