maximus/Simpl-Resultat

Fork 0

feat(licence): révocation vérifiée en ligne — une clé remboursée retombe en Gratuite #365

New issue

Closed

opened 2026-09-30 23:53:53 +00:00 by maximus · 5 comments

maximus commented

2026-09-30 23:53:53 +00:00

Owner

Corps réécrit par /analyze le 2026-10-01. Le corps d'origine du 2026-09-30 est archivé en commentaire.

Contexte

Constat de Max le 2026-09-30, pendant le go-live Stripe (maximus/la-compagnie-maximus#141) : achat réel d'une licence Base, remboursement complet, licence révoquée côté serveur, mais la clé reste pleinement fonctionnelle dans l'app.

La cause, vérifiée sur main (a9fa34d) :

L'édition se résout hors ligne, depuis la clé seule : current_entitlements → entitlements_from_dir → resolve_license_entitlements (signature Ed25519 et exp). Les clés durent 36525 jours depuis maximus-api#63 : exp ne joue aucun rôle d'anti-révocation.
/v1/licenses/verify n'est appelé que pour lister les machines (verify_inner). Une réponse {valid:false, reason:"revoked"} pose un drapeau de session dans LicenseContext (#347, D13) : il affiche un message, ne touche pas l'édition et disparaît à la fermeture de l'app.
auto-update est gatée sur l'édition locale (FEATURE_TIERS, entitlements.rs) : une clé révoquée garde aussi les mises à jour automatiques.

Les conditions de vente du site disent « le remboursement entraîne la révocation de la licence » (sales.refund_desc). Seule la moitié serveur est tenue.

Ce que cette issue change au principe « rien ne part sans action »

Ce contrôle est la première requête que l'app fait seule au démarrage. Aujourd'hui les mises à jour, les cours et la rétroaction partent sur un clic ; le contrôle du compte Maximus (check_subscription_status) a une garde de 24 h mais ne part qu'à l'ouverture de Paramètres → Utilisateurs. Les bornes qui encadrent cette exception :

aucune requête sans clé enregistrée : l'édition Gratuite ne contacte jamais le serveur ;
au plus une tentative par 24 h ;
la requête porte le produit et la clé, rien d'autre : ni identifiant machine, ni nom d'ordinateur, ni donnée d'usage ;
chaque tentative est écrite dans le Journal de l'app, et le guide dit ce qui part et quand ;
la mention dans la politique de confidentialité est suivie par maximus/la-compagnie-maximus#184.

Décisions (2026-10-01)

D1 — au démarrage, au plus une tentative par 24 h. Le contrôle part au lancement, si une clé est enregistrée et que la dernière tentative date de plus de 24 h, qu'elle ait abouti ou non. C'est la garde de check_subscription_status (auth_commands.rs). Écartés : un appel à chaque démarrage (le serveur verrait chaque ouverture de l'app) et un contrôle à la seule ouverture de la carte Licence (un remboursé qui n'ouvre jamais cette page resterait en Base).
D2 — la révocation est nommée là où le verrou apparaît. La carte Licence l'affiche, et chaque écran verrouillé (UpsellGate) ajoute une ligne « votre clé a été révoquée » au-dessus de l'invite d'achat. Pas de bandeau global.
D3 — fail-open. Erreur réseau, délai dépassé, 429, 5xx, réponse illisible : l'état ne change pas. Un utilisateur légitime hors ligne n'est jamais rétrogradé, et une clé déjà connue comme révoquée le reste.
D4 — un seul état, un seul point d'écriture. Toute réponse « révoquée » du serveur pour la clé enregistrée, quelle que soit la commande qui l'apprend, pose le même état persistant. Cela remplace D13 de #347 (« rien n'est persisté ») pour le cas révoqué. D12 est inchangée : le jeton d'activation ne pèse toujours pas sur l'édition.

Conception

État persistant

Un fichier license.check dans le dossier de données, en JSON :

{"key_sha256": "<condensé SHA-256 de la clé>", "attempted_at": 1759363200, "revoked": false}

Il remplace le marqueur license.revoked et l'horodatage séparé du corps d'origine. Une autre clé enregistrée ne correspond plus au condensé : l'état est ignoré, donc un contrôle est dû au démarrage suivant.
Jamais la clé en clair. sha2 est déjà une dépendance.
Absent, illisible, JSON invalide ou condensé d'une autre clé : traité comme « pas d'état », c'est-à-dire non révoquée et contrôle dû. Un fichier corrompu ne doit pas rétrograder un client légitime.

Résolution de l'édition

entitlements_from_dir rend ("free", []) quand l'état dit revoked: true pour la clé courante. resolve_license_entitlements reste pure. get_edition, check_entitlement (auto-update) et le gating du front suivent sans autre changement : isEntitled refuse tout en Gratuite.

Contrôle

Une commande, par exemple check_license_revocation, dont la logique vit dans des fonctions sans AppHandle (dossier temporaire et serveur mockito) :

Dû quand une clé est enregistrée et que l'état est absent, ou que attempted_at date de plus de 24 h, ou qu'il est dans le futur (horloge reculée).
attempted_at est écrit avant l'appel : deux appels concurrents n'en font qu'un, et « une tentative par 24 h » tient quel que soit le résultat.
POST /v1/licenses/verify avec {product, license_key}. Le serveur répond toujours 200.
{valid:false, reason:"revoked"} : revoked: true. {valid:true} : revoked: false. not_found, expired et toute erreur : état inchangé.
La commande rend l'issue du contrôle (non dû, valide, révoquée, serveur non joint, autre), que le front écrit dans le Journal.

Aucun chemin serveur ne réactive une licence révoquée aujourd'hui (revokeLicense passe is_revoked à vrai et désactive les machines, rien ne fait l'inverse) : la levée sur valid:true ne sert qu'à une correction manuelle de la base.

Autres sources de la révocation

activate_machine, list_activated_machines et deactivate_machine : sur LicenseError::LicenseRevoked, poser l'état avant de rendre l'erreur.
Cours du Bilan. fetch_price_inner (balance_commands.rs) traduit tout 403 en PremiumRequired sans lire error.code, alors que licenseAuth.ts distingue license_revoked de premium_required. Lire error.code, ajouter LicenseRevoked à FetchPriceError et à PriceErrorCode, le relier à la clé existante balance.priceFetching.errors.licenseRevoked, et poser l'état. Le jeton envoyé appartient à la clé enregistrée : store_license_in le supprime quand la clé change (#347).

Front

LicenseContext lit l'état révoqué depuis Rust (par exemple un champ revoked de LicenseInfo, rendu par read_license et store_license). Le drapeau de session LICENSE_REVOKED et markRevoked disparaissent : après une réponse « révoquée », useLicenseMachines recharge le contexte.
Une clé révoquée ressaisie reste en Gratuite, y compris juste après la saisie (aujourd'hui VALIDATE_DONE prend l'édition de la clé).
Le contrôle part une fois par montage du fournisseur, après le premier chargement réussi avec une clé. Si l'état a changé, le contexte est rechargé.
Carte Licence : édition Gratuite, bandeau license.errors.licenseRevoked, boutons « Entrer une clé » et « Acheter ». La section Machines disparaît avec l'édition.
UpsellGate : une ligne (nouvelle clé upsell.revoked, FR et EN) quand la clé enregistrée est révoquée.

Tâches

Rust : état license.check (lecture tolérante, écriture, condensé de la clé) et prise en compte dans entitlements_from_dir.
Rust : commande de contrôle, garde de 24 h, attempted_at écrit avant l'appel, fail-open, issue du contrôle rendue au front.
Rust : état posé sur LicenseRevoked par les trois commandes réseau, et par le 403 license_revoked des cours (FetchPriceError::LicenseRevoked).
Rust : read_license et store_license rendent l'état révoqué de la clé ; enregistrement de la commande dans lib.rs.
TS : LicenseContext (état lu depuis Rust, contrôle au démarrage, rechargement), useLicenseMachines (rechargement au lieu de markRevoked), LicenseCard, UpsellGate, licenseService.ts, balance.service.ts.
TS : chaque tentative dans le Journal (logInfo).
i18n FR et EN : upsell.revoked ; relire license.errors.licenseRevoked et balance.priceFetching.errors.licenseRevoked.
Docs : amendement #365 de l'ADR 0017 (D13 remplacée, première requête au démarrage et ses bornes), docs/architecture.md, docs/guide-utilisateur.md et docs.editions.tips (clé révoquée, et ce que l'app envoie et quand), CHANGELOG.md et CHANGELOG.fr.md.

Tests

Les décisions se testent sans AppHandle : dossier temporaire pour l'état, serveur mockito pour verify, valeurs attendues en littéraux.

Clé valide et état révoqué de la même clé : Gratuite, sans features.
État d'une autre clé, fichier illisible, JSON invalide : édition de la clé.
auto-update refusé après révocation (is_entitled sur l'édition résolue).
Contrôle : revoked pose l'état ; valid:true le lève ; not_found, expired, erreur réseau, 429, 5xx, corps illisible le laissent tel quel.
Garde : aucune requête sans clé, ni avant 24 h (mock avec expect(0)) ; requête due sans état, après 24 h, avec une autre clé, avec un attempted_at dans le futur ; attempted_at écrit même quand l'appel échoue.
La requête ne porte que product et license_key.
Le fichier d'état ne contient pas la clé.
Les trois commandes réseau et le 403 des cours posent l'état sur license_revoked ; un 403 premium_required ne le pose pas.
Front : le contexte prend l'état révoqué de Rust ; une clé révoquée ressaisie reste en Gratuite ; UpsellGate et LicenseCard nomment la révocation ; le contrôle part une seule fois et recharge le contexte quand l'état change.
Le bloc « revocation lasts the session » de LicenseContext.test.ts est réécrit : l'état vient de Rust et survit à la session.

Tests existants touchés : entitlements_from_dir et verify_* (license_commands.rs), fetch_price_inner (balance_commands.rs), entitlements.rs, LicenseContext.test.ts, useLicenseMachines.test.ts, LicenseCard.render.test.tsx.

Critères d'acceptation

Après un remboursement complet, l'app en ligne retombe en Gratuite au premier démarrage où un contrôle est dû, auto-update compris, et l'état révoqué reste affiché d'une session à l'autre.
Hors ligne, ou si le serveur est injoignable ou en erreur, aucune rétrogradation.
Une autre clé valide redonne son édition.
Aucune requête sans clé enregistrée, et au plus une tentative par 24 h.
La requête ne porte que le produit et la clé ; le fichier d'état ne contient pas la clé.
Un refus license_revoked des cours s'affiche comme une révocation, plus comme « abonnement premium requis ».
cargo test, npm test et la CI verts.
Vérification manuelle avec une licence réellement révoquée : la clé du contrôle d'achat du 2026-09-30 l'est déjà.

Limites assumées

Aucun changement hors ligne. Bloquer le serveur de licences suffit à garder l'édition : c'est le soft-paywall de l'ADR 0017, pas un contrôle d'accès.
Supprimer le fichier d'état rend l'édition jusqu'au contrôle suivant, qui est alors dû dès le prochain démarrage.
Une app laissée ouverte n'est pas recontrôlée avant son redémarrage : aucun minuteur en cours de session.
not_found et expired n'ont aucun effet. not_found peut venir d'une base serveur restaurée ou d'une licence émise en mode test.
Budget de requêtes. Les routes de licence partagent 5 requêtes par minute et par adresse IP. Le parcours « limite de machines » en prend 4 : avec le contrôle du démarrage on atteint 5, sans marge. Un 429 est déjà expliqué à l'utilisateur, et n'a aucun effet sur le contrôle.

Dépendances

#347 (D12, D13) et #350, mergées. Cette issue touche le même fichier que #350 : rien d'autre ne doit le réécrire en parallèle.
maximus/la-compagnie-maximus#184 : mention du contrôle périodique dans la politique de confidentialité.
maximus/la-compagnie-maximus#141 (go-live) : la vente est ouverte depuis le 2026-09-29.

Complexité

Moyenne, plus large que #350 : un PR, Rust et front, sans migration de base ni changement serveur.

> Corps réécrit par `/analyze` le 2026-10-01. Le corps d'origine du 2026-09-30 est archivé en commentaire. ## Contexte Constat de Max le 2026-09-30, pendant le go-live Stripe (maximus/la-compagnie-maximus#141) : achat réel d'une licence Base, remboursement complet, licence **révoquée côté serveur**, mais la clé reste pleinement fonctionnelle dans l'app. La cause, vérifiée sur `main` (`a9fa34d`) : - L'édition se résout **hors ligne, depuis la clé seule** : `current_entitlements` → `entitlements_from_dir` → `resolve_license_entitlements` (signature Ed25519 et `exp`). Les clés durent 36525 jours depuis maximus-api#63 : `exp` ne joue aucun rôle d'anti-révocation. - `/v1/licenses/verify` n'est appelé que pour lister les machines (`verify_inner`). Une réponse `{valid:false, reason:"revoked"}` pose un drapeau de session dans `LicenseContext` (#347, D13) : il affiche un message, ne touche pas l'édition et disparaît à la fermeture de l'app. - `auto-update` est gatée sur l'édition locale (`FEATURE_TIERS`, `entitlements.rs`) : une clé révoquée garde aussi les mises à jour automatiques. Les conditions de vente du site disent « le remboursement entraîne la révocation de la licence » (`sales.refund_desc`). Seule la moitié serveur est tenue. ## Ce que cette issue change au principe « rien ne part sans action » **Ce contrôle est la première requête que l'app fait seule au démarrage.** Aujourd'hui les mises à jour, les cours et la rétroaction partent sur un clic ; le contrôle du compte Maximus (`check_subscription_status`) a une garde de 24 h mais ne part qu'à l'ouverture de Paramètres → Utilisateurs. Les bornes qui encadrent cette exception : - aucune requête sans clé enregistrée : l'édition Gratuite ne contacte jamais le serveur ; - au plus **une tentative par 24 h** ; - la requête porte le produit et la clé, rien d'autre : ni identifiant machine, ni nom d'ordinateur, ni donnée d'usage ; - chaque tentative est écrite dans le Journal de l'app, et le guide dit ce qui part et quand ; - la mention dans la politique de confidentialité est suivie par maximus/la-compagnie-maximus#184. ## Décisions (2026-10-01) - **D1 — au démarrage, au plus une tentative par 24 h.** Le contrôle part au lancement, si une clé est enregistrée et que la dernière tentative date de plus de 24 h, qu'elle ait abouti ou non. C'est la garde de `check_subscription_status` (`auth_commands.rs`). Écartés : un appel à chaque démarrage (le serveur verrait chaque ouverture de l'app) et un contrôle à la seule ouverture de la carte Licence (un remboursé qui n'ouvre jamais cette page resterait en Base). - **D2 — la révocation est nommée là où le verrou apparaît.** La carte Licence l'affiche, et chaque écran verrouillé (`UpsellGate`) ajoute une ligne « votre clé a été révoquée » au-dessus de l'invite d'achat. Pas de bandeau global. - **D3 — fail-open.** Erreur réseau, délai dépassé, 429, 5xx, réponse illisible : l'état ne change pas. Un utilisateur légitime hors ligne n'est jamais rétrogradé, et une clé déjà connue comme révoquée le reste. - **D4 — un seul état, un seul point d'écriture.** Toute réponse « révoquée » du serveur pour la clé enregistrée, quelle que soit la commande qui l'apprend, pose le même état persistant. Cela remplace D13 de #347 (« rien n'est persisté ») pour le cas révoqué. D12 est inchangée : le jeton d'activation ne pèse toujours pas sur l'édition. ## Conception ### État persistant Un fichier `license.check` dans le dossier de données, en JSON : ```json {"key_sha256": "<condensé SHA-256 de la clé>", "attempted_at": 1759363200, "revoked": false} ``` - Il remplace le marqueur `license.revoked` et l'horodatage séparé du corps d'origine. Une autre clé enregistrée ne correspond plus au condensé : l'état est ignoré, donc un contrôle est dû au démarrage suivant. - **Jamais la clé en clair.** `sha2` est déjà une dépendance. - Absent, illisible, JSON invalide ou condensé d'une autre clé : traité comme « pas d'état », c'est-à-dire non révoquée et contrôle dû. Un fichier corrompu ne doit pas rétrograder un client légitime. ### Résolution de l'édition `entitlements_from_dir` rend `("free", [])` quand l'état dit `revoked: true` pour la clé courante. `resolve_license_entitlements` reste pure. `get_edition`, `check_entitlement` (`auto-update`) et le gating du front suivent sans autre changement : `isEntitled` refuse tout en Gratuite. ### Contrôle Une commande, par exemple `check_license_revocation`, dont la logique vit dans des fonctions sans `AppHandle` (dossier temporaire et serveur mockito) : - **Dû** quand une clé est enregistrée et que l'état est absent, ou que `attempted_at` date de plus de 24 h, ou qu'il est dans le futur (horloge reculée). - `attempted_at` est écrit **avant** l'appel : deux appels concurrents n'en font qu'un, et « une tentative par 24 h » tient quel que soit le résultat. - `POST /v1/licenses/verify` avec `{product, license_key}`. Le serveur répond toujours 200. - `{valid:false, reason:"revoked"}` : `revoked: true`. `{valid:true}` : `revoked: false`. `not_found`, `expired` et toute erreur : état inchangé. - La commande rend l'issue du contrôle (non dû, valide, révoquée, serveur non joint, autre), que le front écrit dans le Journal. Aucun chemin serveur ne réactive une licence révoquée aujourd'hui (`revokeLicense` passe `is_revoked` à vrai et désactive les machines, rien ne fait l'inverse) : la levée sur `valid:true` ne sert qu'à une correction manuelle de la base. ### Autres sources de la révocation - `activate_machine`, `list_activated_machines` et `deactivate_machine` : sur `LicenseError::LicenseRevoked`, poser l'état avant de rendre l'erreur. - **Cours du Bilan.** `fetch_price_inner` (`balance_commands.rs`) traduit tout 403 en `PremiumRequired` sans lire `error.code`, alors que `licenseAuth.ts` distingue `license_revoked` de `premium_required`. Lire `error.code`, ajouter `LicenseRevoked` à `FetchPriceError` et à `PriceErrorCode`, le relier à la clé existante `balance.priceFetching.errors.licenseRevoked`, et poser l'état. Le jeton envoyé appartient à la clé enregistrée : `store_license_in` le supprime quand la clé change (#347). ### Front - `LicenseContext` lit l'état révoqué depuis Rust (par exemple un champ `revoked` de `LicenseInfo`, rendu par `read_license` et `store_license`). Le drapeau de session `LICENSE_REVOKED` et `markRevoked` disparaissent : après une réponse « révoquée », `useLicenseMachines` recharge le contexte. - Une clé révoquée ressaisie reste en Gratuite, y compris juste après la saisie (aujourd'hui `VALIDATE_DONE` prend l'édition de la clé). - Le contrôle part une fois par montage du fournisseur, après le premier chargement réussi avec une clé. Si l'état a changé, le contexte est rechargé. - Carte Licence : édition Gratuite, bandeau `license.errors.licenseRevoked`, boutons « Entrer une clé » et « Acheter ». La section Machines disparaît avec l'édition. - `UpsellGate` : une ligne (nouvelle clé `upsell.revoked`, FR et EN) quand la clé enregistrée est révoquée. ## Tâches - [ ] Rust : état `license.check` (lecture tolérante, écriture, condensé de la clé) et prise en compte dans `entitlements_from_dir`. - [ ] Rust : commande de contrôle, garde de 24 h, `attempted_at` écrit avant l'appel, fail-open, issue du contrôle rendue au front. - [ ] Rust : état posé sur `LicenseRevoked` par les trois commandes réseau, et par le 403 `license_revoked` des cours (`FetchPriceError::LicenseRevoked`). - [ ] Rust : `read_license` et `store_license` rendent l'état révoqué de la clé ; enregistrement de la commande dans `lib.rs`. - [ ] TS : `LicenseContext` (état lu depuis Rust, contrôle au démarrage, rechargement), `useLicenseMachines` (rechargement au lieu de `markRevoked`), `LicenseCard`, `UpsellGate`, `licenseService.ts`, `balance.service.ts`. - [ ] TS : chaque tentative dans le Journal (`logInfo`). - [ ] i18n FR et EN : `upsell.revoked` ; relire `license.errors.licenseRevoked` et `balance.priceFetching.errors.licenseRevoked`. - [ ] Docs : amendement #365 de l'ADR 0017 (D13 remplacée, première requête au démarrage et ses bornes), `docs/architecture.md`, `docs/guide-utilisateur.md` et `docs.editions.tips` (clé révoquée, et ce que l'app envoie et quand), `CHANGELOG.md` et `CHANGELOG.fr.md`. ## Tests Les décisions se testent sans `AppHandle` : dossier temporaire pour l'état, serveur mockito pour `verify`, valeurs attendues en littéraux. - [ ] Clé valide et état révoqué de la même clé : Gratuite, sans features. - [ ] État d'une autre clé, fichier illisible, JSON invalide : édition de la clé. - [ ] `auto-update` refusé après révocation (`is_entitled` sur l'édition résolue). - [ ] Contrôle : `revoked` pose l'état ; `valid:true` le lève ; `not_found`, `expired`, erreur réseau, 429, 5xx, corps illisible le laissent tel quel. - [ ] Garde : aucune requête sans clé, ni avant 24 h (mock avec `expect(0)`) ; requête due sans état, après 24 h, avec une autre clé, avec un `attempted_at` dans le futur ; `attempted_at` écrit même quand l'appel échoue. - [ ] La requête ne porte que `product` et `license_key`. - [ ] Le fichier d'état ne contient pas la clé. - [ ] Les trois commandes réseau et le 403 des cours posent l'état sur `license_revoked` ; un 403 `premium_required` ne le pose pas. - [ ] Front : le contexte prend l'état révoqué de Rust ; une clé révoquée ressaisie reste en Gratuite ; `UpsellGate` et `LicenseCard` nomment la révocation ; le contrôle part une seule fois et recharge le contexte quand l'état change. - [ ] Le bloc « revocation lasts the session » de `LicenseContext.test.ts` est réécrit : l'état vient de Rust et survit à la session. Tests existants touchés : `entitlements_from_dir` et `verify_*` (`license_commands.rs`), `fetch_price_inner` (`balance_commands.rs`), `entitlements.rs`, `LicenseContext.test.ts`, `useLicenseMachines.test.ts`, `LicenseCard.render.test.tsx`. ## Critères d'acceptation - [ ] Après un remboursement complet, l'app en ligne retombe en Gratuite au premier démarrage où un contrôle est dû, `auto-update` compris, et l'état révoqué reste affiché d'une session à l'autre. - [ ] Hors ligne, ou si le serveur est injoignable ou en erreur, aucune rétrogradation. - [ ] Une autre clé valide redonne son édition. - [ ] Aucune requête sans clé enregistrée, et au plus une tentative par 24 h. - [ ] La requête ne porte que le produit et la clé ; le fichier d'état ne contient pas la clé. - [ ] Un refus `license_revoked` des cours s'affiche comme une révocation, plus comme « abonnement premium requis ». - [ ] `cargo test`, `npm test` et la CI verts. - [ ] Vérification manuelle avec une licence réellement révoquée : la clé du contrôle d'achat du 2026-09-30 l'est déjà. ## Limites assumées - **Aucun changement hors ligne.** Bloquer le serveur de licences suffit à garder l'édition : c'est le soft-paywall de l'ADR 0017, pas un contrôle d'accès. - **Supprimer le fichier d'état** rend l'édition jusqu'au contrôle suivant, qui est alors dû dès le prochain démarrage. - **Une app laissée ouverte** n'est pas recontrôlée avant son redémarrage : aucun minuteur en cours de session. - **`not_found` et `expired`** n'ont aucun effet. `not_found` peut venir d'une base serveur restaurée ou d'une licence émise en mode test. - **Budget de requêtes.** Les routes de licence partagent 5 requêtes par minute et par adresse IP. Le parcours « limite de machines » en prend 4 : avec le contrôle du démarrage on atteint 5, sans marge. Un 429 est déjà expliqué à l'utilisateur, et n'a aucun effet sur le contrôle. ## Dépendances - #347 (D12, D13) et #350, mergées. Cette issue touche le même fichier que #350 : rien d'autre ne doit le réécrire en parallèle. - maximus/la-compagnie-maximus#184 : mention du contrôle périodique dans la politique de confidentialité. - maximus/la-compagnie-maximus#141 (go-live) : la vente est ouverte depuis le 2026-09-29. ## Complexité Moyenne, plus large que #350 : un PR, Rust et front, sans migration de base ni changement serveur.

maximus added the

status:triage

type:feature

source:human

labels 2026-09-30 23:53:53 +00:00

feat(licence): révocation vérifiée en ligne — une clé remboursée retombe en Gratuite #365

Contexte

Ce que cette issue change au principe « rien ne part sans action »

Décisions (2026-10-01)

Conception

État persistant

Résolution de l'édition

Contrôle

Autres sources de la révocation

Front

Tâches

Tests

Critères d'acceptation

Limites assumées

Dépendances

Complexité

Contexte

Decision proposee (option A, choisie par Max le 2026-09-30)

Taches

Criteres d'acceptation

Dependances

Questions ouvertes (a trancher au /analyze)