Aller au contenu

Gate 5 — Plan Review — PD-107

Version : v1 Date : 2026-02-14 Reviewer : ChatGPT (GPT-5.3-codex) Type : AMBIGUITY


1. Résumé

Le plan PD-107 est globalement structuré, séquencé, et techniquement crédible pour une implémentation iOS/Expo avec module natif. La couverture fonctionnelle est bonne sur les flux nominaux (activation, unlock, fallback, révocation). Les principales ambiguïtés concernent surtout les interfaces inter-modules, la migration PD-99 → PD-107 et la profondeur des tests sur certains invariants de sécurité. Les risques sont identifiés, mais certaines mitigations restent trop déclaratives pour sécuriser l'exécution sans itérations supplémentaires.


2. Points forts

  • Décomposition en 17 tâches cohérente, avec dépendances majoritairement explicites et ordonnancement lisible.
  • Choix technique biometryCurrentSet pertinent et aligné avec INV-107-07 (révocation sur changement biométrique système).
  • Architecture claire autour de UnlockOrchestrator + PolicyEngine, adaptée aux exigences F-107-06/08/09.
  • Prise en compte explicite des erreurs critiques (lockout, revoke, clock skew, indisponibilité audit).
  • Matrice de couverture CA/INV fournie, utile pour la traçabilité gate.

3. Écarts identifiés

ID Type Sévérité Description Recommandation
AMB-01 Hypothèse implicite Haute Migration PD-99 → PD-107 mentionnée mais non spécifiée (idempotence, rollback, gestion corruption legacy, versioning du format). Ajouter une spec de migration détaillée: algorithme pas-à-pas, marqueurs de version, stratégie de reprise, tests de non-régression migration.
AMB-02 Ambiguïté interface Haute Contrat d'interface incomplet entre unlockOrchestrator, biometricKeychain, policyEngine (types d'erreurs, mapping codes natifs↔domain, états machine exacts). Définir des contrats TS stricts (DTO, enum d'états, enum d'erreurs, transitions autorisées) + tableau de mapping erreurs iOS vers erreurs domaine.
AMB-03 Couverture sécurité/tests Haute Les tests listés ne démontrent pas explicitement la preuve d'INV-107-04 (aucun bypass SRP) et INV-107-06 (aucune collecte biométrique brute). Ajouter tests dédiés + assertions négatives (absence d'appels/stockage interdits), et checklist de preuve par invariant dans T15/T16/T17.
AMB-04 Chemin critique Moyenne Chemin critique réel sous-estimé: T1→T2→T3→T5→T8/T9→T12→T14→T17 + dépendance device réel non planifiée en capacité/calendrier. Formaliser le critical path avec jalons, buffer de validation device, et critères "go/no-go" intermédiaires.
AMB-05 Risk mitigation Moyenne Risques listés mais mitigations peu opérationnelles (pas de plan B si module natif bloquant, pas de seuils de décision). Ajouter playbooks de mitigation avec seuils: fallback technique, owner, délai max, décision d'escalade.
AMB-06 Audit probatoire Moyenne "Événements signés backend" non détaillé côté protocole (schéma payload signé, horodatage, anti-rejeu, stratégie offline prolongée). Spécifier protocole d'audit: signature/verif, nonce/idempotency key, politique de retry/backoff/DLQ, limites de queue locale.
AMB-07 Cohérence dépendances Faible T13 dépend de T8/T9, mais store impacte potentiellement T5/T7 (compteurs lockout, états REVOKED) sans dépendance explicite. Revalider la DAG et expliciter les dépendances fonctionnelles store↔orchestrator pour éviter couplages tardifs.

4. Scoring

Critère Score Justification
feasibility 8.0/10 Plan techniquement réalisable avec Expo prebuild + module natif
coverage 7.5/10 Bonne couverture mais tests INV-107-04/06 insuffisants
risk_mitigation 6.5/10 Risques identifiés mais mitigations déclaratives
coherence 7.8/10 Dépendances claires, quelques couplages implicites
Moyenne 7.45/10

5. Recommandation

RESERVE

Justification : Le plan est réalisable et bien avancé, mais il reste des ambiguïtés structurantes (migration, contrats d'interface, preuves de sécurité sur invariants critiques, mitigation opérationnelle). Conformément aux règles de scoring: moyenne >= 7 mais au moins un critère < 8 ⇒ RESERVE. Un passage en GO nécessite de lever AMB-01/02/03 en priorité.