05 — Portail Affaires mobile : fonctionnalités détaillées#

Surface : contexte Affaires de l'application mobile Kaxentra, iOS et Android. Même application, même compte, même authentification que le contexte Client. 122 écrans relevés sous le groupe professionnel de l'arbre de routage, 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, configuration de l'application. Chaque ligne des tableaux ci-dessous a été vue dans un fichier.

Le contexte Client de la même application est traité dans 03-portail-client-mobile.md. Le portail Affaires web est traité dans le dossier produit.

1. Vue d'ensemble#

1.1 La bascule vers le contexte Affaires#

Un compte qui porte des rôles professionnels voit, à l'ouverture, un choix de portail : « Espace Client » ou « Mon Cabinet ». Le choix est mémorisé pour les prochaines sessions et remis à zéro à la déconnexion, pour qu'un compte à double casquette ne reste pas épinglé au portail de sa dernière session.

Une fois dans « Mon Cabinet », un sélecteur de contexte professionnel ouvre neuf contextes : comptable, fiscaliste, auditeur, conseiller, paie, incorporateur, gestion, facturation, administration.

La bascule ne change ni d'application, ni de compte. Elle recompose la navigation :

1. La section du métier actif passe en tête du hub — c'est ce qui doit tomber sous le pouce en premier.
2. Toutes les autres sections professionnelles restent servies, à la suite. Un cabinet réel ne se découpe pas en silos de persona, et le portail web ne filtre que par module souscrit.
3. Les sections communes — Réseau, Travail, Terrain, Facturation, Outils et IA, Paramètres du cabinet, Mon compte — sont servies quel que soit le contexte.

1.2 Qui utilise le contexte Affaires sur mobile#

Le mobile n'est pas une réduction du poste de travail. Il sert trois situations que le poste de travail ne couvre pas.

1.3 Volumétrie mesurée#

1.4 Le principe de composition du hub#

L'assemblage du hub professionnel est explicite dans le registre partagé. Il vaut la peine d'être lu, parce qu'il porte une décision de produit :

Section Réseau, puis Travail, puis Terrain, puis la section du métier actif, puis Facturation, puis les sections de tous les autres métiers, puis Outils et IA, puis Paramètres du cabinet, puis Mon compte — l'ensemble dédupliqué par route, la première occurrence gagnant.

Trois conséquences :

• Un module payant reste visible sans habilitation. L'écran affiche l'offre. Le masquer le rendrait introuvable pour la moitié des comptes qui y ont droit.
• Aucune entrée en double. « Ma vitrine » serait apparue trois fois sans la déduplication ; « Factures » deux fois. Une entrée en double n'est pas une entrée en plus, c'est une hésitation de plus.
• Le terrain est un module, pas une persona. La section Terrain est globale : un technicien peut être rattaché à n'importe quel contexte.

2. Navigation mobile du contexte Affaires#

2.1 Arborescence#

flowchart TD
    n00["Application Kaxentra"] --> n01["Choix du portail"]
    n01 --> n02["Mon Cabinet"]
    n02 --> n03["Sélecteur de contexte professionnel"]
    n03 --> n10["Barre du bas - 5 emplacements"]
    n10 --> n11["Tableau de bord"]
    n10 --> n12["Clients"]
    n10 --> n13["Bouton de création"]
    n10 --> n14["Agenda"]
    n10 --> n15["Plus"]
    n15 --> n20["Réseau"]
    n15 --> n21["Travail"]
    n15 --> n22["Terrain"]
    n15 --> n23["Section du métier actif"]
    n15 --> n24["Facturation"]
    n15 --> n25["Sections des autres métiers"]
    n15 --> n26["Outils et IA"]
    n15 --> n27["Paramètres du cabinet"]
    n15 --> n28["Mon compte"]
    n02 --> n30["Barre du haut"]
    n30 --> n31["Recherche"]
    n30 --> n32["Notifications"]
    n30 --> n33["Assistant IA"]
    n30 --> n34["Menu de compte"]

2.2 Les cinq emplacements de la barre du bas#

La barre professionnelle était autrefois non adaptative : ses cinq emplacements étaient écrits en dur. Elle lit désormais les mêmes emplacements indexés par position que la barre Client, ce qui permet au deuxième emplacement de se recomposer par contexte sans risquer le décalage qui avait déjà fait afficher « Messages » sur l'emplacement « Documents ».

2.3 Les neuf contextes professionnels et leur section de tête#

2.4 Le bouton central de création, par contexte#

Les routes de ces actions ont été vérifiées contre l'arbre réel du groupe professionnel. Des destinations obsolètes qui ne correspondaient à aucun écran ont été remplacées par les écrans réels.

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

3.1 Tableau de bord cabinet#

3.2 Clients#

3.3 Dossiers et engagements#

3.4 Tâches et pipeline de dossiers#

3.5 Documents et demandes#

3.6 Messages et réseau#

3.7 Comptabilité#

3.8 Facturation et paiements#

3.9 Temps et feuilles de temps#

3.10 Paie#

3.11 Fiscalité#

3.12 Audit#

3.13 Opérations terrain#

3.14 Rendez-vous#

3.15 Notifications#

3.16 Assistant IA, approbations et copilotes#

3.17 Équipe#

3.18 Paramètres du cabinet#

3.19 Sécurité du siège professionnel#

4. Le cas d'usage terrain : ce que le mobile permet et que le web ne permet pas#

4.1 Pourquoi cette section existe#

Le portail Affaires web sert 867 pages. Il ne sert pas une seule intervention.

L'opération terrain est le domaine du produit où le mobile devient la surface principale et le web la surface d'appoint. Un technicien n'ouvre pas un ordinateur portable dans un vide sanitaire, dans un stationnement, ni sur un toit. Six écrans mobiles portent ce domaine ; ils ont été écrits pour le pouce, debout, à une main.

4.2 Les trois questions et les trois écrans#

4.3 Ce que le mobile permet, exclusivement#

4.4 Les deux règles de vérité du terrain#

Première règle : déclaré n'est pas livré. L'achèvement a deux faces. Le technicien exécute et déclare ; le client réceptionne. L'écran « Ma journée » ne compte l'avancement qu'à la réception. Un tableau d'avancement qui compterait les déclarations donnerait à un cabinet une image fausse de son propre travail, et ferait facturer des interventions qu'aucun client n'a acceptées.

Seconde règle : un refus se dit, avec son motif. Chaque transition d'état relit l'état depuis le serveur, succès comme refus. Un refus affiche le message du serveur, qui nomme l'état ou le bon de travail en conflit. Un pointage refusé parce qu'un autre est déjà ouvert nomme le bon concerné. On ne se contente jamais de dire que l'action a échoué.

4.5 Ce que le terrain n'a pas#

5. Parité web vers mobile, côté Affaires#

5.1 Le fait mesuré#

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

Ce constat, daté du 13 août 2026, est consigné dans le registre lui-même. Il dit une chose précise :

• 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 une recherche.
• La cause était un découpage par persona. Le registre enfermait la comptabilité chez le comptable uniquement, l'audit chez l'auditeur uniquement, la paie chez la paie uniquement, les clefs d'API chez l'administration uniquement. Le portail web, lui, sert toutes ses sections à tous les contextes professionnels et ne filtre que par module souscrit.

5.2 Les écarts corrigés, un par un#

5.3 Parité par domaine#

5.4 Trois précisions honnêtes#

Le nombre de pages n'est pas le nombre de fonctions. Le portail Affaires web compte 867 pages ; le contexte Affaires mobile en compte 122. Une famille web étalée sur six pages tient souvent sur un écran mobile avec fenêtres superposées.

Certains écrans mobiles sont volontairement en lecture seule. C'est signalé ligne à ligne à la section 3.

Un correctif porté à un seul portail 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é professionnel dans la même passe, où le même défaut existait sous une forme pire — sans aucune branche d'erreur.

6. Parcours professionnels#

6.1 La journée d'un technicien terrain#

flowchart TD
    a01["Ouverture de l application"] --> a02["Contexte Mon Cabinet"]
    a02 --> a03["Écran Ma journée"]
    a03 --> a04["Liste des interventions du jour"]
    a04 --> a05["Ouverture du bon de travail"]
    a05 --> a06["Passage En route"]
    a06 --> a07["Avis envoyé au client"]
    a07 --> a08["Arrivée - Démarrer"]
    a08 --> a09["Pointage d arrivée"]
    a09 --> a10["Photos de l intervention"]
    a10 --> a11["Pause ou Reprendre"]
    a11 --> a12["Déclarer terminé"]
    a12 --> a13["Pointage de départ"]
    a13 --> a14["En attente de réception par le client"]
    a14 --> a15["Avancement compté seulement à la réception"]

6.2 Une transition refusée par le serveur#

sequenceDiagram
    participant T as "Technicien"
    participant A as "Application mobile"
    participant S as "Service terrain"
    T->>A: Appuie sur Démarrer
    A->>S: Demande la transition
    S-->>A: Refus avec motif
    A->>S: Relit l état du bon
    S-->>A: État courant
    A-->>T: Message du serveur nommant le bon en conflit
    T->>A: Ouvre le bon nommé
    A->>S: Ferme le pointage ouvert
    S-->>A: Pointage fermé
    A-->>T: La transition redevient possible

6.3 Faire signer une lettre de mission chez le client#

flowchart TD
    b01["Ouverture de la fiche client"] --> b02["Section Conseil"]
    b02 --> b03["Écran Propositions"]
    b03 --> b04["Ouverture de la proposition"]
    b04 --> b05["Lecture avec le client"]
    b05 --> b06{"Décision du client"}
    b06 -->|"Accepte"| b07["Tracé de la signature au doigt"]
    b06 -->|"Refuse"| b08["Refus enregistré"]
    b07 --> b09["Signature persistée comme acceptation"]
    b09 --> b10["Facture créée côté serveur"]
    b10 --> b11["Visible dans Facturation"]

6.4 Saisir une écriture au grand livre chez le client#

flowchart TD
    c01["Contexte Comptable"] --> c02["Section Comptabilité"]
    c02 --> c03["Écran Grand livre"]
    c03 --> c04["Saisie de la date et de la description"]
    c04 --> c05["Choix du compte de débit"]
    c05 --> c06["Choix du compte de crédit"]
    c06 --> c07["Saisie du montant"]
    c07 --> c08["Comptes archivés exclus du sélecteur"]
    c08 --> c09["Envoi"]
    c09 --> c10{"Réponse du serveur"}
    c10 -->|"Acceptée"| c11["Écriture publiée en deux lignes équilibrées"]
    c10 -->|"Refusée"| c12["Message de refus en français"]

6.5 Approuver une écriture proposée par un copilote#

flowchart TD
    d01["Notification Approbation en attente"] --> d02["Boîte d approbation"]
    d02 --> d03["Lecture de la ligne"]
    d03 --> d04["Ouverture du détail"]
    d04 --> d05["Lecture de la charge utile envisagée"]
    d05 --> d06{"Décision"}
    d06 -->|"Approuver"| d07["Écriture différée rejouée"]
    d06 -->|"Rejeter"| d08["Aucune écriture"]
    d07 --> d09["Résultat visible dans le domaine concerné"]
    d08 --> d10["Retour à la boîte"]
    d02 --> d11["Sélection multiple"]
    d11 --> d12["Approbation en lot"]

6.6 Générer et envoyer un relevé de compte#

flowchart TD
    e01["Contexte Facturation"] --> e02["Section Barèmes et recouvrement"]
    e02 --> e03["Écran Relevés de compte"]
    e03 --> e04["Choix du client"]
    e04 --> e05["Choix de la période"]
    e05 --> e06["Génération"]
    e06 --> e07["Relevé apparaissant dans la collection"]
    e07 --> e08["Ouverture du détail"]
    e08 --> e09["Envoi au client"]

6.7 Générer les feuillets fiscaux en lot#

flowchart TD
    f01["Contexte Paie"] --> f02["Écran Feuillets fiscaux"]
    f02 --> f03["Choix du type de feuillet"]
    f03 --> f04["Choix de l année"]
    f04 --> f05["Génération pour tous les employés actifs"]
    f05 --> f06{"Résultat du serveur"}
    f06 -->|"Feuillets produits"| f07["Nombre produit annoncé"]
    f06 -->|"Aucun produit"| f08["Sautés et rafraîchis annoncés séparément"]
    f07 --> f09["Liste rafraîchie"]
    f08 --> f09

6.8 Créer une clef d'API et en recopier le secret#

flowchart TD
    g01["Contexte Administration"] --> g02["Écran Clefs d API"]
    g02 --> g03["Saisie du nom de la clef"]
    g03 --> g04["Création"]
    g04 --> g05["Secret complet rendu une seule fois"]
    g05 --> g06["Affichage persistant et sélectionnable"]
    g06 --> g07["Copie dans le presse-papiers"]
    g07 --> g08["Fermeture"]
    g08 --> g09["Seul le préfixe reste lisible ensuite"]

7. Sécurité en contexte professionnel#

Un siège professionnel porte des données de tiers : celles des clients du cabinet. Sur un appareil personnel. Cette section dit ce qui est livré, et ce qui ne l'est pas.

7.1 Où résident les données sur l'appareil#

À dire tel quel. Les jetons de session sont dans le magasin sécurisé du système, avec exclusion des sauvegardes et des extractions de données. Les brouillons de saisie ne le sont pas : ils vivent dans un magasin local non chiffré, avec une durée de vie de sept jours et une purge paresseuse à la lecture. Sur un mandat portant des données de client, cela mérite d'être connu du cabinet.

7.2 Cloisonnement par cabinet#

7.3 Verrouillage, biométrie et expiration — état exact#

Conclusion honnête à porter au dossier de lancement. Le socle biométrique est écrit et fonctionnel ; il n'est branché sur rien. Un cabinet qui déploie l'application sur des appareils personnels doit aujourd'hui s'appuyer sur le verrouillage de l'appareil lui-même et sur la gestion de parc mobile de son choix. 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 de crédibilité pour le segment professionnel.

7.4 Ce qui protège malgré tout#

8. Ce qui n'est pas couvert#

8.1 Volontairement absent#

8.2 Pas porté#

8.3 Capacités natives : l'état exact#

Cette sous-section corrige des attentes courantes. Elle distingue la dépendance déclarée de l'usage réel.

8.4 Publication en magasin : les points bloquants mesurés#

Ces points ne sont pas des risques théoriques. Ils ont été relevés dans la configuration de l'application le 17 août 2026.

8.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.