03 — Portail Client mobile : fonctionnalités détaillées#

Surface : application mobile Kaxentra, iOS et Android, une seule application pour les deux publics. 286 fichiers d'écran comptés sous l'arbre de routage de l'application mobile, dont 146 écrans pour le contexte Client une fois les trois fichiers de disposition retirés. Relevé écran par écran effectué le 17 août 2026 sur le code source : registre de fonctionnalités partagé, arbre de routage, en-têtes de fichiers d'écran. Chaque ligne des tableaux ci-dessous a été vue dans un fichier, pas déduite d'un menu.

Le contexte Affaires de la même application est traité dans 05-portail-business-mobile.md. Le portail Client web est traité dans 02-portail-client-web.md.

1. Vue d'ensemble#

1.1 Une application, deux contextes#

Kaxentra ne publie pas deux applications. Il en publie une, et cette application sait qui vous êtes.

À l'ouverture, un compte qui porte les deux jeux de rôles voit un choix de portail : « Espace Client » ou « Mon Cabinet ». Un compte qui n'en porte qu'un n'a pas ce choix à faire — il entre directement. Le choix est mémorisé, et il est remis à zéro à la déconnexion : un compte qui possède les deux accès ne reste pas épinglé au portail de sa dernière session.

Une fois dans l'espace Client, un sélecteur de contexte décide de tout le reste. Dix contextes clients existent : particulier, travailleur autonome, entrepreneur, PME, immobilier, investisseur, succession, Affaires, Épicerie, Startup Studio — plus un contexte de repli. Basculer de contexte ne change pas d'application, ne change pas de compte, ne demande aucune migration. La bascule recompose la navigation : le deuxième onglet de la barre du bas change de nom et d'icône, le hub change de sections, le menu du bouton central change d'actions.

C'est le même mécanisme que sur le web. Ce n'est pas une adaptation mobile d'un concept web : les deux surfaces lisent la même définition de contextes, dans le paquet partagé.

1.2 Volumétrie mesurée#

1.3 Le mécanisme : une navigation pilotée par les données#

La navigation mobile n'est pas écrite en dur dans les écrans. Elle est déclarée dans un registre partagé — un fichier de 986 lignes qui associe, pour chaque contexte, une liste de sections et, dans chaque section, une liste d'entrées portant un libellé, une icône et une route réelle.

Trois conséquences, toutes vérifiables :

1. Un écran qui n'est pas dans le registre n'existe pour personne. Il peut être écrit, compilé, enregistré dans la disposition de son groupe : s'il n'est nommé nulle part, aucun menu n'y mène et aucune recherche de fonctionnalité ne le trouve. C'est le cœur de la section 5 de ce document.
2. Aucune entrée ne mène dans le vide. Les entrées non encore portées pointent vers un écran de remplacement explicite plutôt que vers un bouton mort ou une erreur de route.
3. Une entrée en double n'est pas une entrée en plus. Le registre déduplique par route en gardant la première occurrence, puis retire les sections devenues vides. « Ma vitrine » apparaîtrait trois fois sans cette règle.

1.4 Ce que « adaptatif » veut dire concrètement#

Une remarque de conception qui mérite d'être nommée. Les cinq emplacements de la barre du bas sont indexés par position, pas par balayage d'une liste de longueur variable. Ce détail a une histoire : la barre dérivait autrefois ses emplacements d'une liste de navigation dans laquelle une entrée « IA » optionnelle s'insérait au milieu. Pour un contexte sans IA, la liste ne comptait que quatre entrées — l'emplacement « Documents » affichait « Messages », et l'emplacement « Messages » retombait sur une valeur par défaut. La barre du bas d'une application est la surface la plus vue du produit ; elle ne doit dépendre d'aucun décalage.

2. Navigation mobile du contexte Client#

2.1 Arborescence#

flowchart TD
    n00["Application Kaxentra"] --> n01["Choix du portail"]
    n01 --> n02["Espace Client"]
    n01 --> n03["Mon Cabinet"]
    n02 --> n04["Sélecteur de contexte"]
    n04 --> n10["Barre du bas - 5 emplacements"]
    n10 --> n11["Accueil"]
    n10 --> n12["Onglet de contexte"]
    n10 --> n13["Bouton de création"]
    n10 --> n14["Documents"]
    n10 --> n15["Messages"]
    n12 --> n20["Réseau"]
    n12 --> n21["Mon espace"]
    n12 --> n22["Sections propres au contexte"]
    n12 --> n23["Patrimoine"]
    n12 --> n24["Outils et IA"]
    n12 --> n25["Mon compte"]
    n02 --> n30["Barre du haut"]
    n30 --> n31["Recherche"]
    n30 --> n32["Notifications"]
    n30 --> n33["Assistant IA"]
    n30 --> n34["Menu de compte"]

2.2 La barre du bas, emplacement par emplacement#

Correspondance contexte vers libellé du deuxième emplacement, telle qu'elle est déclarée :

2.3 La barre du haut#

Les deux barres ne se recoupent jamais. La barre du bas porte les destinations ; la barre du haut porte les utilitaires transversaux et le compte.

Une entrée « Réseau » a été ajoutée à cette barre puis retirée : le fil social est déjà offert par la section Réseau du hub, et une seconde porte vers le même écran consommait une largeur que la barre fait déjà déborder.

2.4 Le bouton central de création#

Le bouton central n'ouvre ni une fenêtre modale native ni une feuille de bibliothèque tierce — les deux échouent dans le mode de rendu de l'application. C'est un calque plein écran monté à la racine de la disposition, après la barre d'onglets, avec fond assombri et feuille qui monte.

La feuille garde aussi les actions épinglées et les actions récentes du membre, les récentes excluant les épinglées pour ne pas doubler la même ligne.

3. Fonctionnalités détaillées, par groupe d'écrans#

Convention de lecture : chaque tableau nomme la fonctionnalité, ce que la personne peut réellement faire depuis son téléphone, et le bénéfice. Rien n'est listé qui n'ait été vu dans le code.

3.1 Tableau de bord#

3.2 Documents#

3.3 Messages#

3.4 Demandes#

3.5 Propositions#

3.6 Signatures électroniques#

3.7 Notifications#

3.8 Assistant IA#

3.9 Approbations IA#

3.10 Activité IA#

3.11 Flux de travail IA#

3.12 Espaces de connaissance#

3.13 Calendrier et échéances#

3.14 Outils#

3.15 Listes de contrôle#

3.16 Rapports et aperçus#

3.17 Support et aide#

3.18 Profil#

3.19 Crédit et financement#

3.20 Facturation#

3.21 Crédits IA#

3.22 Abonnement#

3.23 Mes cabinets#

3.24 Sécurité#

3.25 Paramètres#

3.26 Mes finances — vue d'ensemble#

3.27 Comptes et transactions#

3.28 Immobilier, hypothèques et gestion locative#

3.29 Évaluation de propriété#

3.30 Assurances#

3.31 Dettes, retraite, dividendes, cryptoactifs#

3.32 Budgets, objectifs et santé financière#

3.33 Dossier T1/TP1 et fiscalité personnelle#

3.34 Dépenses et numérisation#

3.35 Signature de bail#

4. Capacités natives#

Ce que l'application fait parce qu'elle est native, et non parce qu'elle affiche des pages.

4.1 Tableau des capacités#

4.2 Numérisation : le parcours réel#

La numérisation n'est pas un simple téléversement d'image. Elle a été recâblée en juillet 2026 : auparavant, la photo partait vers le service documentaire, qui l'archivait sans rien en extraire. Le reçu était donc rangé, et rien n'était saisi.

Aujourd'hui, la photo part vers le service de facturation, qui exécute la reconnaissance de texte et rend les champs extraits : nom du fournisseur, date, sous-total, taxe fédérale, taxe provinciale, total, catégorie suggérée. La personne relit, corrige ce qui doit l'être, et confirme. La confirmation crée la dépense persistée.

Trois précisions honnêtes sur ce parcours :

• La reconnaissance est faite au serveur, jamais sur l'appareil. Aucun modèle n'est embarqué.
• Les champs devinés sont signalés. Le service indique lesquels des champs il a devinés ; ceux-là portent une bordure ambre et la mention « à vérifier ». Une cohérence arithmétique est recalculée à l'écran : si sous-total plus taxes ne fait pas le total à trois cents près, un avertissement s'affiche.
• Si le service d'extraction est indisponible, la pièce n'est pas perdue : le reçu est conservé, le dossier passe à l'état « à vérifier », et la saisie se poursuit à la main. En revanche, si c'est le téléversement lui-même qui échoue — réseau coupé — la capture n'est ni conservée ni rejouée. Voir 4.5.

4.3 Biométrie et verrouillage — l'état exact#

Le socle biométrique est écrit et fonctionnel. Il n'est branché sur rien. Cette section le dit sans détour, parce qu'un dossier de lancement qui annoncerait un verrouillage biométrique exposerait la marque.

Formulation autorisée : « la biométrie de votre appareil est prise en charge ». Formulation interdite : « votre application se verrouille par empreinte ». Brancher l'invite biométrique sur la restauration de session, et lire enfin la préférence déjà persistée, est un chantier court — et une condition avant toute affirmation publique.

4.4 Notifications — dans l'application, pas sur l'écran verrouillé#

L'application porte un écran de notifications complet : compteur de non-lus en direct dans la barre du haut, marquage à la visibilité réelle, action de masse à envoi unique, navigation vers l'écran concerné.

À dire tel quel. L'infrastructure de notification est préparée ; le branchement ne l'est pas. Une échéance fiscale ne vous alerte pas sur votre écran verrouillé : elle vous attend dans l'application. Ne jamais écrire « recevez une alerte » ni « soyez notifié sur votre téléphone » tant que l'enregistrement de jeton n'est pas livré.

4.5 Hors-ligne et résilience#

Le mot « hors-ligne » recouvre quatre besoins distincts. Voici ce que l'application fait de chacun.

Formulation autorisée : « l'application vous dit quand vous êtes hors ligne ». Formulation interdite : « travaillez hors ligne, tout se synchronise ensuite ».

4.6 Partage et sortie de données#

Formulation interdite. Ne jamais écrire que le membre exporte l'intégralité de ses données sans intervention. Le point d'entrée crée une demande à l'état d'attente ; aucun processus automatique ne l'exécute, et l'adresse de téléchargement reste vide. Voir le brief commun, section 1.5, écart É1.

5. Parité web vers mobile#

5.1 Le fait mesuré#

Le registre déclarait de 34 à 43 entrées par contexte là où le web en offre de 156 à 309. Et 44 écrans déjà écrits n'étaient nommés nulle part.

Ce constat est daté du 13 août 2026 et il est consigné dans le registre lui-même. Il mérite d'être compris exactement, parce qu'il ne dit pas ce qu'on croit :

• Ce n'était pas un manque d'écrans. Les 44 écrans existaient, compilaient, et étaient enregistrés dans la disposition de leur groupe. Zéro ligne d'écran à produire.
• C'était un manque de déclarations. Le registre est la source de vérité de la navigation mobile. Ce qui n'y figure pas n'est ni dans un menu, ni dans la recherche de fonctionnalités.
• La forme la plus difficile à voir. Un hub qui affiche correctement ses sections communes n'a l'air cassé nulle part. Un membre qui bascule sur « Affaires » voyait quatre sections génériques et 32 entrées — aucune de son métier — sans le moindre signe d'erreur.

5.2 Les trous mesurés, un par un#

5.3 Parité par domaine#

5.4 Ce que la parité ne veut pas dire#

Trois précisions honnêtes.

Le nombre de pages n'est pas le nombre de fonctions. Le portail Client web compte 472 pages ; le contexte Client mobile en compte 146. Cela ne signifie pas que le mobile couvre 31 % du produit. Une famille web qui s'étale sur six pages — liste, détail, création, édition, réglages, historique — tient souvent sur un seul écran mobile avec fenêtres superposées.

Une entrée déclarée n'est pas une fonction complète. Certains écrans mobiles sont volontairement en lecture seule là où le web permet la modification. C'est signalé ligne à ligne dans les tableaux de la section 3.

Un écran corrigé dans un portail et pas dans l'autre est un correctif partiel. La règle a été appliquée : l'écran de sécurité, corrigé côté Client, l'a été côté Affaires dans la même passe.

6. Parcours mobiles#

6.1 Numériser un reçu et le transformer en dépense#

flowchart TD
    p01["Appui sur le bouton central"] --> p02["Choix Numériser un reçu"]
    p02 --> p03["Appareil photo"]
    p03 --> p04["Recadrage de l image"]
    p04 --> p05["Choix de la catégorie"]
    p05 --> p06["Envoi au service d extraction"]
    p06 --> p07{"Service disponible"}
    p07 -->|"Oui"| p08["Champs extraits proposés"]
    p07 -->|"Non"| p09["Reçu conservé et saisie manuelle"]
    p08 --> p10["Revue et correction des champs"]
    p09 --> p10
    p10 --> p11["Confirmation"]
    p11 --> p12["Dépense créée et persistée"]

6.2 Signer une proposition reçue du cabinet#

flowchart TD
    q01["Notification Proposition reçue"] --> q02["Ouverture de la liste des propositions"]
    q02 --> q03["Lecture du détail"]
    q03 --> q04{"Décision"}
    q04 -->|"Accepter"| q05["Tracé de la signature au doigt"]
    q04 -->|"Refuser"| q06["Refus enregistré"]
    q05 --> q07["Signature persistée comme acceptation"]
    q07 --> q08["Facture créée côté serveur"]
    q08 --> q09["Facture visible dans Facturation"]
    q06 --> q10["Retour à la liste"]

6.3 Répondre à une demande de document#

flowchart TD
    r01["Pastille de notification"] --> r02["Écran Demandes"]
    r02 --> r03["Ouverture de la demande"]
    r03 --> r04["Lecture du statut servi par le serveur"]
    r04 --> r05["Transitions offertes par le serveur"]
    r05 --> r06["Téléversement de la pièce"]
    r06 --> r07["Choix de la catégorie"]
    r07 --> r08["Envoi"]
    r08 --> r09["Statut mis à jour"]
    r09 --> r10["Réponse du cabinet lisible dans la demande"]

6.4 Poser une question à l'assistant, crédits épuisés#

sequenceDiagram
    participant M as "Membre"
    participant A as "Application mobile"
    participant P as "Passerelle de modèles"
    participant C as "Service de crédits"
    M->>A: Pose une question
    A->>P: Envoie la demande
    P-->>A: Refus pour crédits insuffisants
    A-->>M: Bandeau avec trois issues
    M->>A: Choisit le modèle ouvert
    A->>P: Rejoue la demande
    P-->>A: Réponse
    A->>C: Relit le solde
    C-->>A: Nouveau solde
    A-->>M: Réponse et pastille de solde à jour

6.5 Signer un bail sans compte#

flowchart TD
    s01["Réception du code par courriel"] --> s02["Ouverture de l écran Signature de bail"]
    s02 --> s03["Saisie du code"]
    s03 --> s04{"Jeton valide"}
    s04 -->|"Non"| s05["Erreur nommée en clair"]
    s04 -->|"Oui"| s06["Chargement du bail et du statut"]
    s06 --> s07["Revue des clauses"]
    s07 --> s08["Défi par code à usage unique"]
    s08 --> s09["Saisie du nom complet"]
    s09 --> s10["Signature"]
    s10 --> s11["Bail signé"]

6.6 Estimer la valeur d'une propriété#

flowchart TD
    t01["Contexte Immobilier"] --> t02["Section Mon immobilier"]
    t02 --> t03["Écran Estimation de valeur"]
    t03 --> t04["Choix de la propriété"]
    t04 --> t05["Lancement de l estimation"]
    t05 --> t06["Consommation de crédits IA"]
    t06 --> t07["Valeur marchande estimée et fourchette"]
    t07 --> t08["Résultat en fenêtre superposée"]
    t08 --> t09["Estimation persistée sur la propriété"]

6.7 Basculer vers un contexte non souscrit#

flowchart TD
    u01["Appui sur le sélecteur de contexte"] --> u02["Liste des contextes clients"]
    u02 --> u03{"Module accordé"}
    u03 -->|"Oui"| u04["Bascule et recomposition du hub"]
    u03 -->|"Inconnu ou en cours de lecture"| u04
    u03 -->|"Refusé"| u05["Contexte marqué verrouillé"]
    u05 --> u06["Remède dérivé des voies d acquisition réelles"]
    u06 --> u07{"Déjà au palier maximal"}
    u07 -->|"Oui"| u08["Message adapté sans invitation à monter de forfait"]
    u07 -->|"Non"| u09["Lien vers la page des forfaits"]

6.8 Reprendre une saisie interrompue#

flowchart TD
    v01["Ouverture d un formulaire long"] --> v02["Saisie en cours"]
    v02 --> v03["Enregistrement automatique du brouillon"]
    v03 --> v04["Interruption - appel ou fermeture"]
    v04 --> v05["Réouverture de l écran"]
    v05 --> v06["Bandeau de reprise"]
    v06 --> v07{"Choix"}
    v07 -->|"Reprendre"| v08["Champs restaurés"]
    v07 -->|"Recommencer"| v09["Formulaire vide"]
    v08 --> v10["Envoi"]
    v09 --> v10

7. Contraintes mobiles, cibles tactiles et accessibilité#

7.1 Contraintes assumées et leurs réponses#

7.2 Cibles tactiles — l'état réel, mesuré#

La cible visée est celle des deux plateformes et du référentiel d'accessibilité : 44 points de côté au minimum. C'est l'intention. Voici la mesure.

À dire tel quel. Le dimensionnement des cibles est appliqué écran par écran, sans jeton commun. Il est donc inégal, et il ne peut pas être vérifié automatiquement. Formulation autorisée : « les surfaces principales visent la cible de 44 points ». Formulation interdite : « toutes les cibles respectent 44 points » — aucune mesure ne le soutient.

7.3 Accessibilité — ce qui est fait, et ce qui ne l'est pas#

Formulation autorisée : « travail d'accessibilité engagé, volume mesuré, couverture partielle ». Formulation interdite : « conforme ». Aucun rapport de conformité n'existe au 17 août 2026, et la couverture mesurée est d'environ un fichier d'interface sur quatre.

8. Exigences de publication en magasin d'applications#

8.1 Le point bloquant, relevé le 17 août 2026#

Le nom de l'application, l'identifiant de paquet iOS, le nom de paquet Android et le schéma d'URL portent encore la dénomination interne antérieure — pas la marque publique.

C'est le point le plus urgent de tout ce document, et voici pourquoi : un identifiant de paquet ne se change plus après la première soumission. Il est l'identité permanente de l'application dans chaque magasin. Le corriger après coup signifie publier une deuxième application, perdre les installations, perdre les évaluations, et demander à chaque membre de réinstaller.

Le schéma d'URL de l'application porte la même dénomination : il apparaît dans le retour d'authentification et dans les liens de partage. Le changer plus tard casse les liens déjà transmis.

Action requise avant toute soumission : aligner le nom d'application, les deux identifiants de paquet et le schéma d'URL sur la marque publique, puis régénérer la préparation native et les ressources visuelles.

8.2 Exigences techniques#

8.3 Captures d'écran et éléments visuels#

8.4 Fiche de magasin#

8.5 Points de refus à anticiper#

9. Ce qui n'est pas couvert#

Deux catégories, et elles ne se confondent pas. Volontairement absent signifie qu'un choix a été fait et qu'il est défendable. Pas porté signifie que le travail reste à faire.

9.1 Volontairement absent#

9.2 Pas porté — familles du web Client sans équivalent mobile nommé#

Relevé par comparaison des familles de routes du portail Client web et de l'arbre mobile. Une famille absente par son nom peut être servie sous un autre nom au mobile ; les cas connus sont signalés.

9.3 Capacités natives préparées mais non branchées#

Catégorie distincte, et la plus dangereuse pour un dossier de lancement : la dépendance est déclarée, la configuration est posée, les métadonnées natives existent — et aucun code ne s'en sert. Vu de la configuration, tout a l'air livré. Vu du produit, rien ne l'est.

9.4 Absent des deux surfaces — à dire tel quel#

9.5 Ce que ce document n'a pas pu vérifier#

Kaxentra — dossier de lancement. Document interne, version 1.0 du 17 août 2026. Marque publique : Kaxentra. Éditeur : i2t Digital. Les éléments marqués [HYPOTHÈSE] ne sont pas publiables en l'état. Les personas d'extension communautaire (E01–E08) décrivent des fonctionnalités non livrées.