PD-101 — Rapport de confrontation (Étape 3)¶

Ce rapport est produit par l'orchestrateur Claude (P2 — CONFRONTEUR) avant la gate PMO 3. Il confronte la spécification et les tests pour identifier convergences, divergences et zones d'ombre.

1. Sources confrontées¶

Spécification : PD-101-specification.md (étape 1)
Tests : PD-101-tests.md (étape 2)

2. Convergences¶

CON-01 : Les 10 invariants (INV-01 à INV-10) sont intégralement couverts par la matrice de couverture des tests. Chaque invariant possède au moins un test dédié (TC-INV-XX) et/ou un test nominal/erreur le vérifiant.
CON-02 : Les 12 critères d'acceptation (CA-01 à CA-12) sont tous référencés dans la matrice de couverture. Aucun CA orphelin.
CON-03 : Les 8 scénarios de test de la spec (ST-01 à ST-08) ont chacun un équivalent dans les tests (TC-NOM-01 à TC-NOM-06, TC-ERR-01, TC-ERR-07). Les observables correspondent.
CON-04 : Les paramètres numériques contractuels (seuil 10 MB, retry max 3, backoff ½/4, jitter, taille max 500 MB) sont cohérents entre spec §5.4 et tests (TC-NOM-02, TC-ERR-03, TC-ERR-01, TC-NR-01, TC-NR-04).
CON-05 : La table de transitions d'états (spec §5.6) est reflétée fidèlement dans TC-INV-09 et TC-NEG-07. Les états terminaux (COMPLETED, CANCELLED) sont testés comme sans transition sortante (TC-NR-02).
CON-06 : Les 6 points à clarifier de la spec (Q-01 à Q-06) sont repris intégralement dans la section « Règles non testables » des tests (§9), avec le même niveau de criticité (Majeur/Mineur).
CON-07 : Le modèle de formats et contraintes de données (spec §3.2) est couvert par les tests négatifs TC-NEG-01 à TC-NEG-06, qui vérifient le rejet 400 pour chaque champ invalide.
CON-08 : La continuité background (spec flux 5.3) est couverte par TC-NOM-05 et TC-ERR-05 avec unicité de notification et cohérence d'état au retour foreground.
CON-09 : Le mécanisme purgeStale() (INV-07, spec flux ST-07) est couvert par TC-NOM-06 et TC-NR-05 avec vérification au démarrage du flux et trace d'exécution.
CON-10 : Le mode capture optimisée (spec flux 5.2) est couvert par TC-NOM-03 avec consentement explicite, optimized=true, hash sur version transformée, et interdiction de réversion.

3. Divergences¶

⚠️ Les conflits ne doivent JAMAIS être lissés. Chaque divergence est rendue visible.

DIV-01 : Numérotation discontinue TC-ERR-06 manquant
Source A (Spécification) : ERR-06 (HTTP 4xx fonctionnel) est défini et distinct d'ERR-09 (format métadonnée invalide).
Source B (Tests) : TC-ERR-04 couvre ERR-06 et ERR-09 ensemble, mais TC-ERR-06 n'existe pas dans la numérotation (saut de TC-ERR-05 à TC-ERR-07).
Impact : Ambiguïté sur la couverture d'ERR-06 en tant que cas distinct. Un HTTP 4xx fonctionnel (ex : quota dépassé, document déjà existant) n'est pas nécessairement une erreur de format de métadonnée. La fusion implicite masque un delta de couverture.
DIV-02 : Disclaimer EXIF non testé
Source A (Spécification §5.1 étape 5) : « Affichage disclaimer métadonnées EXIF et confirmation explicite » est une étape obligatoire du flux nominal A.
Source B (Tests) : Aucun scénario ne vérifie l'affichage du disclaimer EXIF ni la confirmation explicite de l'utilisateur. TC-NOM-04 couvre le transcodage Photos, pas le disclaimer EXIF.
Impact : Étape fonctionnelle contractuelle du flux nominal sans couverture de test. Le disclaimer EXIF est distinct de l'avertissement de transcodage (le premier concerne tous les fichiers, le second uniquement les assets Photos transcodés).
DIV-03 : Scénarios d'invariants sans GIVEN/WHEN/THEN complets
Source A (Spécification) : Les invariants INV-01 à INV-10 sont décrits avec des observables précis.
Source B (Tests §5) : TC-INV-01, TC-INV-02, TC-INV-03, TC-INV-04, TC-INV-05, TC-INV-06, TC-INV-07, TC-INV-08, TC-INV-09, TC-INV-10 sont référencés dans la matrice et la table §5, mais seuls les observables sont indiqués — aucun scénario GIVEN/WHEN/THEN détaillé n'est fourni pour ces tests (contrairement aux TC-NOM et TC-ERR qui ont des scénarios complets).
Impact : Tests d'invariants non exécutables en l'état sans interprétation supplémentaire. Un testeur devra inférer les préconditions et les étapes de déclenchement.
DIV-04 : Worker de réconciliation post-crash non testé
Source A (Spécification §5.7) : « Crash post-commit : État DB valide, reprise asynchrone par worker de réconciliation ».
Source B (Tests) : Aucun scénario ne vérifie la reprise asynchrone post-crash par le worker de réconciliation.
Impact : Mineur pour cette story (le worker est hors scope immédiat), mais la garantie d'atomicité multi-composant affirmée en spec n'est pas couverte par les tests.
DIV-05 : Performance upload — conditions de test incomplètes
Source A (Spécification §5.4) : « Upload perf cible 100MB : 30 s P95, WiFi stable, device de référence iPhone 12/A14 ».
Source B (Tests TC-NR-03) : « Rapport campagne P95 » sans préciser les conditions de réseau (débit min WiFi, latence) ni le protocole de mesure (nombre de runs, warm-up, exclusion outliers).
Impact : Le test de performance est non reproductible sans protocole documenté. Deux campagnes pourraient donner des résultats contradictoires.

4. Zones d'ombre¶

ZO-01 : Génération du doc_id — La spec (§3, §3.2) mentionne que le doc_id est un UUID v4 généré à l'étape 2 du flux, mais ne précise pas qui le génère (client mobile ou backend). Les tests valident le format mais pas l'origine. Si le client génère le doc_id, un risque de collision ou de spoofing existe. Si le backend le génère, le flux d'initialisation doit le retourner.
ZO-02 : Taille de chunk multipart configurable — La spec (§5.4) indique « Taille chunk multipart : 5 MB défaut, [5, 50] MB range, Clamp [5,50] ». Aucun test ne vérifie le comportement aux bornes (chunk de 5 MB exactement, chunk de 50 MB, tentative de configuration à 4 MB ou 51 MB avec clamp).
ZO-03 : Hash SHA3-256 : point de calcul exact — La spec (§5.1 étape 6) dit « Calcul sha3_256 sur fichier probatoire [...] puis chiffrement local ». Mais en mode capture optimisée (§5.2), le fichier probatoire est la version transformée. La question : le hash est-il calculé sur le flux en mémoire (avant écriture disque) ou sur le fichier temporaire écrit ? Cela impacte INV-07 (purge) et la consommation mémoire.
ZO-04 : Comportement réseau en background iOS — La spec (flux 5.3) affirme que l'upload continue en arrière-plan. iOS impose des contraintes strictes sur les tâches réseau en background (URLSession background configuration obligatoire, 30s de grâce en Expo/React Native). Ni la spec ni les tests ne précisent le mécanisme technique ni les limites de la continuité background.
ZO-05 : Reprise après FAILED — La spec (§5.6) autorise FAILED -> UPLOADING (nouvelle tentative utilisateur). Aucun test ne couvre ce scénario de reprise explicitement. Le comportement attendu n'est pas précisé : reprend-on depuis le début (nouveau chiffrement) ou depuis le dernier chunk ?
ZO-06 : Annulation d'un upload simple — TC-ERR-07 et ST-03 couvrent l'annulation d'un upload multipart. L'annulation d'un upload simple (< 10 MB) n'est pas testée. Le comportement côté S3 diffère (pas d'AbortMultipartUpload à appeler).
ZO-07 : Concurrence de flux — Ni la spec ni les tests ne précisent le comportement si l'utilisateur lance un second upload pendant qu'un premier est en cours. Sérialisation ? Parallélisme ? File d'attente ?
ZO-08 : Validation fonctionnelle du hash (INV-05) — La spec exige « recalcul contrôlé » et TC-INV-05 mentionne « corruption binaire détectée ». Mais le point de vérification n'est pas précisé : qui recalcule (client avant envoi ? backend à réception ?) et quand ? Le backend ne peut pas recalculer car il n'a pas accès au clair (INV-01). Le client est donc la seule entité capable de cette validation — mais contre quoi compare-t-il ?

5. Recommandation¶

Procéder — convergence confirmée, aucun conflit bloquant
Rework nécessaire — divergences à résoudre avant de continuer
Escalade — décision humaine requise sur un point structurant

Justification : La couverture globale est solide (10/10 invariants, 12/12 CA). Cependant : - DIV-02 (disclaimer EXIF non testé) est un trou de couverture sur une étape contractuelle du flux nominal. - DIV-03 (scénarios d'invariants sans GIVEN/WHEN/THEN) rend 10 tests non exécutables en l'état. - ZO-05 et ZO-08 révèlent des ambiguïtés fonctionnelles dans la spec elle-même (reprise après FAILED, validation fonctionnelle du hash côté client).

Les divergences DIV-01, DIV-04, DIV-05 sont mineures et peuvent être traitées en correction incrémentale.