09 — Recueil d'histoires utilisateur — personas Affaires (P12 à P15) et rôles métier#

Portée. Ce recueil couvre les quatre personas de forfait du Portail Affaires — P12 CPA solo (forfait Solo, 49 $/mois), P13 Cabinet en croissance (Cabinet Pro, 149 $/mois), P14 Cabinet établi (Équipe, 299 $/mois), P15 Grand cabinet (Entreprise, 599 $/mois) — et les neuf rôles métier que la plateforme expose comme contextes professionnels : Comptable, Fiscaliste, Auditeur, Conseiller, Paie, Incorporateur, Gestion, Facturation, Administration de cabinet. Il ajoute quatre familles transversales : relation cabinet ↔ client, gouvernance de cabinet, intelligence artificielle côté cabinet, et surfaces spécialisées (mobile, vitrine et appels d'offres, opérations terrain, secteurs verticaux).

Ancrage. Chaque histoire vise un écran présent dans le registre de navigation adaptative du Portail Affaires (apps/portal-adminclient/src/config/navigation.ts, 1 367 lignes), dans l'inventaire du module de relation client (apps/portal-adminclient/src/app/(admin)/crm/_nav.ts), dans le registre de contextes partagé web/mobile (packages/shared-core/src/config/contexts.ts), ou dans l'arborescence des 125 fichiers d'écran du contexte Affaires de l'application mobile. Une histoire dont l'écran existe mais n'est nommé par aucune entrée de menu porte le statut Livré (accès direct) et le dit. Une histoire dont la capacité n'existe pas encore sous cette forme porte Planifié.

Référence de brief : ../00-brief-commun.md — marque, palette, prix réels, personas, ton. Recueil jumeau, côté Client : 08-user-stories-client.md — personas P01 à P11.

Version : 1.0 — 17 août 2026 Statut : Référence active Volume : 4 personas de forfait · 9 rôles métier · 26 blocs d'histoires · 1 233 histoires nommées · 52 fonctionnalités Gherkin complètes (nominal + erreur)

1. Méthode et conventions#

1.1 Forme canonique d'une histoire#

Toute histoire de ce recueil s'écrit sous la forme suivante, sans variante :

En tant que <rôle exercé au moment de l'action>
Je veux <capacité observable dans le produit>
Afin de <bénéfice mesurable pour le cabinet ou pour son client>

Quatre règles d'écriture, non négociables :

1. La capacité est observable. « Je veux verrouiller la période comptable après clôture » est une capacité. « Je veux plus d'efficacité » n'en est pas une.
2. Le bénéfice appartient au cabinet ou à son client, jamais à l'éditeur. « Afin de ne pas facturer une heure déjà facturée » est un bénéfice. « Afin d'augmenter la rétention » n'en est pas un.
3. Une histoire tient dans un écran ou un parcours court. Si elle demande trois écrans et deux sièges, c'est une épopée : elle se découpe.
4. Le rôle est celui de la personne, pas celui du forfait. Un CPA solo qui produit une paie écrit son histoire en tant que « responsable de la paie », pas en tant que « forfait Solo ».

1.2 Identifiants#

Un identifiant est immuable. Une histoire retirée garde son numéro et prend le statut Retiré ; le numéro n'est jamais recyclé. Les neuf rôles utilisent les jetons COMPTABLE, FISCALISTE, AUDITEUR, CONSEILLER, PAIE, INCORPORATEUR, GESTION, FACTURATION, ADMINISTRATION.

1.3 Colonnes des tableaux#

Signification exacte des statuts — c'est le point de rigueur du document :

• Livré — l'écran existe et une entrée de navigation le nomme dans au moins un contexte professionnel. La personne peut le trouver sans connaître son adresse.
• Livré (accès direct) — l'écran existe et répond, mais aucune entrée de menu ne le nomme. Il s'atteint par une adresse directe, par un lien reçu, ou depuis un écran voisin. C'est une capacité réelle à découvrabilité nulle. Elle se corrige par une entrée de navigation, jamais par du développement.
• Planifié — la capacité n'existe pas encore sous cette forme. Aucune histoire Planifié ne se présente comme disponible dans un support commercial.
• Retiré — la capacité a existé et a été supprimée volontairement. Le numéro reste, la ligne dit pourquoi.

Pourquoi cette distinction existe. Le registre de navigation du Portail Affaires porte, dans ses propres commentaires, la trace de plusieurs modules complets — moteur de sondages, trésorerie, marketing, levée de fonds, appels d'offres, opérations terrain, Studio — qui répondaient côté serveur sans qu'aucune entrée de menu ne les nomme. Un écran que personne ne peut atteindre est, du siège de la personne, un écran absent. Ce recueil refuse donc de compter comme « livré » ce qui n'est pas atteignable.

1.4 Critères d'acceptation#

Chaque histoire porte au minimum cinq critères, un par type. Ils se rédigent au présent de l'indicatif, à la voix active, et se vérifient par une observation.

Règle de vérification héritée du projet : un code de retour 200 n'est pas une preuve. Une histoire est vérifiée quand la donnée a été saisie dans l'interface réelle, rechargée, retrouvée, quand le chemin d'erreur a été déclenché volontairement, et — pour tout flux à deux sièges — quand la contrepartie a été ouverte et a montré le résultat.

1.5 Échelle d'estimation#

Suite de Fibonacci tronquée, en points d'effort d'équipe. Le point n'est pas une journée.

Règle d'affinage : aucune histoire au-dessus de 8 n'entre dans un incrément. Aucune histoire n'entre sans ses critères d'acceptation écrits.

1.6 Définition de « terminé »#

Une histoire est terminée quand les dix points suivants sont vrais, vérifiés dans cet ordre :

1. Les critères d'acceptation sont tous vérifiés dans l'interface réelle, en session authentifiée, depuis un siège du forfait visé.
2. La donnée saisie survit à un rechargement complet de la page web ou de l'écran mobile.
3. Le chemin d'erreur a été déclenché volontairement et affiche le message du serveur, pas un repli générique.
4. Le refus de droit — module non souscrit, plafond de sièges atteint, plafond de clients atteint, crédits IA épuisés — affiche l'offre avec le prix réel du catalogue et un lien qui mène à un écran existant.
5. L'écran est atteignable par le menu dans au moins un contexte professionnel, sans connaître son adresse. À défaut, l'histoire porte Livré (accès direct) et une action de navigation est ouverte.
6. Le texte est en français du Québec, sans anglicisme évitable ; la version anglaise canadienne existe si le module est bilingue.
7. Les contrastes respectent WCAG 2.2 AA ; la navigation au clavier atteint chaque action ; les icônes seules sont annoncées.
8. Les surfaces déclarées sont couvertes : Web+Mobile signifie que les deux ont été vérifiées.
9. Pour tout flux à deux sièges, la capacité est vérifiée depuis le siège de la contrepartie : le cabinet voit ce que le client a déposé, le client voit ce que le cabinet a demandé.
10. Pour toute sortie produite par un modèle, la source et le coût en crédits sont affichés, et le compteur de crédits a bougé du montant annoncé.

Ce qui ne compte pas comme terminé : une démonstration sur données fabriquées, un rapport d'agent, une capture d'écran, un test qui vérifie la présence d'un bouton sans cliquer dessus, un module dont l'écran répond mais qu'aucun menu ne nomme.

1.7 Priorisation MoSCoW appliquée au lancement du 17 novembre 2026#

1.8 Rappel des forfaits Affaires — bornes qui contraignent les histoires#

Ces quatre bornes — sièges, clients, crédits — sont des objets d'histoires à part entière : chaque persona porte au moins une histoire sur l'atteinte de sa limite et sur ce que l'écran affiche à ce moment-là.

1.9 Les neuf rôles métier et leur contexte technique#

Le registre de contextes partagé web/mobile déclare neuf contextes professionnels : comptable, fiscaliste, auditeur, conseiller, paie, incorporateur, gestion, facturation, administration, plus un contexte general de repli.

Écart mesuré, à consigner tel quel : le registre de navigation adaptative du Portail Affaires n'énumère que huit contextes — il ne connaît pas incorporateur. Les capacités d'incorporation existent bel et bien et sont atteignables (entrée « Incorporation » du groupe Risques & Conformité, famille « Conseil d'administration », écrans mobiles d'incorporation, de registres et de résolutions), mais elles se consomment depuis les contextes audit, conseil et administration. Les histoires du rôle Incorporateur portent donc leur surface réelle, jamais un contexte inventé.

2. Carte des rôles professionnels et des familles d'histoires#

flowchart LR
  subgraph roles["Roles metier"]
    r1["Comptable"]
    r2["Fiscaliste"]
    r3["Auditeur"]
    r4["Conseiller"]
    r5["Paie"]
    r6["Incorporateur"]
    r7["Gestion"]
    r8["Facturation"]
    r9["Administration"]
  end
  subgraph familles["Familles d histoires"]
    f1["Tenue de livres et tresorerie"]
    f2["Declarations et planification"]
    f3["Certification et conformite"]
    f4["Mandats de conseil"]
    f5["Cycles de paie"]
    f6["Incorporation et gouvernance"]
    f7["Pilotage du cabinet"]
    f8["Cycle de revenu"]
    f9["Plateforme et droits"]
    f10["Relation cabinet client"]
    f11["Intelligence artificielle"]
  end
  r1 --> f1
  r1 --> f10
  r2 --> f2
  r2 --> f10
  r3 --> f3
  r3 --> f11
  r4 --> f4
  r4 --> f11
  r5 --> f5
  r5 --> f10
  r6 --> f6
  r7 --> f7
  r7 --> f10
  r8 --> f8
  r8 --> f10
  r9 --> f9
  r9 --> f11
  f1 --> f11
  f2 --> f11
  f5 --> f8
  f6 --> f3
  f7 --> f8

flowchart TD
  p12["P12 CPA solo - Solo 49"] --> b1["Autonomie complete un siege"]
  p13["P13 Cabinet en croissance - Cabinet Pro 149"] --> b2["Equipe de cinq et affectation"]
  p14["P14 Cabinet etabli - Equipe 299"] --> b3["Certification conseil gouvernance"]
  p15["P15 Grand cabinet - Entreprise 599"] --> b4["Multi organisation et plateforme"]
  b1 --> lim1["Limite 25 clients - 20 credits"]
  b2 --> lim2["Limite 5 sieges 150 clients - 100 credits"]
  b3 --> lim3["15 sieges clients illimites - 500 credits"]
  b4 --> lim4["Sieges illimites - 2000 credits"]
  lim1 --> ecran["Ecran de plafond avec prix reel du catalogue"]
  lim2 --> ecran
  lim3 --> ecran
  lim4 --> ecran

3. Bloc 1 — P12 · CPA solo (forfait Solo, 49 $/mois)#

Rappel en quatre lignes. P12 exerce seul. Il porte tous les chapeaux : tenue de livres, déclarations, facturation, relance, réponse au client. Son forfait lui donne un siège, vingt-cinq clients et vingt crédits IA par mois — il n'a donc ni équipe à qui déléguer ni marge pour un usage d'IA non ciblé. Sa contrainte n'est pas la profondeur fonctionnelle mais le temps : chaque geste qui exige deux écrans au lieu d'un lui coûte une heure facturable. Son critère d'adoption est simple : peut-il finir une journée de travail sans quitter la plateforme, et depuis son téléphone quand il est chez un client ?

3.1 Gherkin — P12#

Fonctionnalité: Plafond de vingt-cinq clients du forfait Solo
  En tant que CPA solo au forfait Solo
  Je veux être averti quand j'atteins la limite de clients incluse
  Afin de choisir mon changement de forfait avant d'être bloqué en pleine saison

  Contexte:
    Étant donné un cabinet abonné au forfait Solo à 49,00 $ par mois
    Et que ce forfait inclut 1 siège, 25 clients et 20 crédits IA par mois
    Et que je suis authentifié comme unique membre du cabinet

  Scénario: Création du vingt-cinquième client et avertissement de plafond
    Étant donné que mon cabinet compte 24 clients actifs
    Quand j'ouvre l'écran des clients
    Et que je crée une fiche cliente nommée "Boulangerie du Coteau"
    Alors la fiche est enregistrée et apparaît dans la liste
    Et l'écran des quotas indique "25 sur 25 clients utilisés"
    Et un avertissement nomme le forfait supérieur et son prix réel de 149,00 $ par mois
    Et après rechargement complet de la page, le compteur affiche toujours 25 sur 25

  Scénario: Refus à la vingt-sixième fiche, avec offre chiffrée
    Étant donné que mon cabinet compte déjà 25 clients actifs
    Quand je tente de créer une vingt-sixième fiche cliente
    Alors la création est refusée
    Et le message affiché est celui renvoyé par le serveur, pas un texte générique
    Et le message nomme la limite atteinte et le forfait qui la lève
    Et le prix affiché est celui du catalogue, soit 149,00 $ par mois ou 1 430,00 $ par année
    Et aucune fiche partielle n'est enregistrée
    Et après rechargement, le compteur affiche toujours 25 sur 25

Fonctionnalité: Demande de document au client et réception dans le dossier
  En tant que CPA solo
  Je veux demander une pièce à mon client et la recevoir dans son dossier
  Afin de cesser de reconstituer un dossier à partir de ma boîte de courriels

  Contexte:
    Étant donné un client existant nommé "Clinique Sainte-Foy"
    Et un dossier de mission ouvert pour l'exercice courant
    Et que le client dispose d'un accès à son portail

  Scénario: Demande envoyée, document déposé, cabinet averti
    Quand je crée une demande de document intitulée "Relevé bancaire de décembre"
    Et que je fixe la date attendue au 15 janvier
    Et que j'envoie la demande au client
    Alors la demande apparaît dans la liste des demandes avec le statut "En attente"
    Et le client voit la demande depuis son propre portail
    Quand le client téléverse un fichier PDF de relevé
    Alors la demande passe au statut "Reçue" du côté du cabinet
    Et le document est classé dans le dossier du client, pas dans un dépôt séparé
    Et l'horodatage du dépôt est affiché
    Et après rechargement de la page, le document et son statut sont toujours présents

  Scénario: Fichier refusé par le serveur pour cause de format non accepté
    Étant donné une demande de document ouverte
    Quand le client tente de déposer un fichier exécutable
    Alors le dépôt est refusé
    Et le message affiché au client est celui du serveur et nomme le format refusé
    Et la demande reste au statut "En attente" du côté du cabinet
    Et aucun document partiel n'apparaît dans le dossier
    Et le cabinet ne reçoit aucune notification de réception

Ce que cette série ne couvre pas. Elle ne traite ni la production d'une paie complète (le CPA solo qui offre ce service lit le bloc du rôle Paie), ni les mandats de certification (bloc Auditeur), ni la gestion d'une équipe — P12 n'a qu'un siège et les histoires de sièges, de rôles et d'affectation sont portées par P13 et par le chapitre de gouvernance. Elle ne couvre pas non plus l'ouverture d'une seconde organisation, réservée aux forfaits Équipe et Entreprise, ni les capacités de plateforme (clés d'interface applicative, points d'ancrage sortants, authentification unique d'entreprise). Enfin, elle ne décrit aucun automatisme de production fiscale de bout en bout : la transmission électronique est une capacité livrée, mais la conformité de chaque transmission relève du jugement professionnel et n'est pas une histoire produit.

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.