PD-264 — Plan d'implémentation¶

0. Contexte et décisions architecturales¶

Constats d'audit Gate 3 intégrés¶

Le plan adresse les 11 constats résiduels de l'audit Gate 3 v3 :

Phase 0 — Go/No-Go¶

Verdict Go/No-Go : GO — Aucune hypothèse bloquante.

1. Découpage en composants¶

TASK-1 — Migration DDL (nonce VARCHAR(64) → BYTEA NOT NULL)¶

Responsabilité : Migrer la colonne nonce de VARCHAR(64) nullable vers BYTEA NOT NULL (16 octets) avec contrainte CHECK et index unique.

Fichiers : - src/database/migrations/XXXXXXXXX-PD264NonceByteaMigration.ts (nouveau)

Opérations DDL (3 phases dans une même migration) :

Phase A — Conversion des données existantes :

-- Convertir les nonces hex existants en binaire
UPDATE vault_secure.timestamp_tokens
SET nonce = decode(nonce, 'hex')
WHERE nonce IS NOT NULL AND nonce != '';
-- Pour les lignes sans nonce (NULL), générer un nonce de remplissage traçable
-- Le nonce sera 16 octets de zéros + marqueur dans metadata
UPDATE vault_secure.timestamp_tokens
SET nonce = E'\\x00000000000000000000000000000000'
WHERE nonce IS NULL OR nonce = '';

Note : La Phase A nécessite la désactivation temporaire du trigger d'immutabilité. Cette opération est documentée en TASK-1 et exécutée dans la migration TypeORM avec réactivation immédiate.

Phase B — ALTER COLUMN :

ALTER TABLE vault_secure.timestamp_tokens
  ALTER COLUMN nonce SET DATA TYPE BYTEA USING nonce::bytea,
  ALTER COLUMN nonce SET NOT NULL;

Phase C — Contraintes et index :

-- CHECK constraint taille exacte (défense en profondeur, réponse R04)
ALTER TABLE vault_secure.timestamp_tokens
  ADD CONSTRAINT chk_nonce_length CHECK (octet_length(nonce) = 16);
-- Index unique anti-rejeu
CREATE UNIQUE INDEX idx_timestamp_token_nonce
  ON vault_secure.timestamp_tokens(nonce);

Down migration :

DROP INDEX IF EXISTS vault_secure.idx_timestamp_token_nonce;
ALTER TABLE vault_secure.timestamp_tokens DROP CONSTRAINT IF EXISTS chk_nonce_length;
ALTER TABLE vault_secure.timestamp_tokens
  ALTER COLUMN nonce SET DATA TYPE VARCHAR(64) USING encode(nonce, 'hex'),
  ALTER COLUMN nonce DROP NOT NULL;

Observable : Migration exécutable sans erreur sur schéma PD-55 existant (npm run typeorm migration:run).

TASK-2 — Entity TypeORM (TimestampToken)¶

Responsabilité : Adapter l'entité TypeORM pour refléter le nouveau type BYTEA NOT NULL.

Fichiers : - src/modules/tsa/entities/timestamp-token.entity.ts (modification)

Changements :

// Avant (PD-55)
@Column({ type: 'varchar', length: 64, nullable: true })
nonce?: string;

// Après (PD-264)
@Column({ type: 'bytea', nullable: false })
nonce!: Buffer;

Observable : Compilation TypeScript sans erreur ; aucune référence à nonce comme string dans le module TSA.

TASK-3 — Service de génération de nonce (NonceService)¶

Responsabilité : Générer des nonces cryptographiques 128 bits via CSPRNG, valider format et unicité.

Fichiers : - src/modules/tsa/services/nonce.service.ts (nouveau)

Interface publique :

@Injectable()
export class NonceService {
  /**
   * Génère un nonce cryptographique de 128 bits (16 octets).
   * Utilise crypto.randomBytes (CSPRNG).
   * INV-264-01 : fail-closed, aucune exception de mode.
   */
  generate(): Buffer;

  /**
   * Valide la présence et la taille d'un nonce.
   * INV-264-01, INV-264-02 : fail-closed.
   */
  validatePresence(nonce: Buffer | null | undefined): void;

  /**
   * Compare deux nonces en temps constant.
   * INV-264-03, INV-264-04 : crypto.timingSafeEqual.
   */
  compareEqual(nonceRequest: Buffer, nonceResponse: Buffer): boolean;

  /**
   * Vérifie l'unicité du nonce en base.
   * INV-264-05 : défense en profondeur (complément de l'index unique).
   */
  checkUniqueness(nonce: Buffer, repository: Repository<TimestampToken>): Promise<void>;
}

Contraintes : - generate() : crypto.randomBytes(16) — CSPRNG exclusif (INV-264-01) - compareEqual() : crypto.timingSafeEqual(a, b) — temps constant obligatoire (INV-264-04) - validatePresence() : throw NonceValidationError si null/undefined/taille != 16 - checkUniqueness() : throw NonceDuplicateError si nonce déjà en base

Observable : Tests unitaires sur génération (taille, type Buffer) et comparaison (temps constant vérifié).

TASK-4 — Service de validation nonce TSA (NonceValidationService)¶

Responsabilité : Orchestrer la validation complète du nonce dans le flux TSA (garde d'entrée, validation réponse, unicité, automate d'états).

Fichiers : - src/modules/tsa/services/nonce-validation.service.ts (nouveau)

Interface publique :

@Injectable()
export class NonceValidationService {
  /**
   * Garde d'entrée : vérifie qu'une requête contient un nonce valide
   * AVANT d'entrer dans l'automate d'états.
   * INV-264-01, CA-264-01 : fail-closed, garde d'entrée.
   */
  validateRequestNonce(nonce: Buffer | null | undefined): void;

  /**
   * Validation complète de la réponse TSA :
   * 1. Présence nonce en réponse (INV-264-02)
   * 2. Égalité binaire temps constant (INV-264-03, INV-264-04)
   * 3. Unicité en base (INV-264-05)
   *
   * @returns ValidationResult avec état ACCEPTED ou REJECTED + motif
   */
  validateResponseNonce(
    nonceRequest: Buffer,
    nonceResponse: Buffer | null | undefined,
    repository: Repository<TimestampToken>,
  ): Promise<NonceValidationResult>;
}

États de validation (enum) :

export enum NonceValidationStatus {
  ACCEPTED = 'ACCEPTED',
  REJECTED_ABSENT = 'REJECTED_ABSENT',
  REJECTED_MISMATCH = 'REJECTED_MISMATCH',
  REJECTED_DUPLICATE = 'REJECTED_DUPLICATE',
  REJECTED_INVALID_SIZE = 'REJECTED_INVALID_SIZE',
}

Transitions d'état (réponse R06) : - RESPONSE_RECEIVED → RESPONSE_ACCEPTED : validation complète OK - RESPONSE_RECEIVED → RESPONSE_REJECTED : validation échouée (motif tracé) - RESPONSE_REJECTED est un état in-memory transitoire — aucune écriture DB ; les transitions interdites (INV-264-12) sont testées via tentative d'appel aux méthodes de transition qui refusent l'opération

Observable : Chaque rejet produit un log structuré { event: 'NONCE_REJECTED', reason: string, batchId: string }.

TASK-5 — Intégration dans le BatchTimestampProcessor¶

Responsabilité : Activer le nonce dans le flux de timestamping existant (processor BullMQ).

Fichiers : - src/modules/tsa/processors/batch-timestamp.processor.ts (modification) - src/modules/tsa/enums/tsa-error-code.enum.ts (modification : ajout codes nonce)

Nouveaux codes d'erreur :

// Nonce Errors
NONCE_MISSING_IN_REQUEST = 'TSA_NONCE_MISSING_IN_REQUEST',
NONCE_MISSING_IN_RESPONSE = 'TSA_NONCE_MISSING_IN_RESPONSE',
NONCE_MISMATCH = 'TSA_NONCE_MISMATCH',
NONCE_DUPLICATE = 'TSA_NONCE_DUPLICATE',
NONCE_INVALID_SIZE = 'TSA_NONCE_INVALID_SIZE',

Séquence dans le processor (INV-264-06, INV-264-13, réponse R10) :

1. Vérifier batch SEALED
2. nonceService.generate() → nonce 16 octets
3. nonceValidation.validateRequestNonce(nonce) → garde d'entrée
4. → État REQUEST_EMITTED
5. Appeler QTSA avec nonce dans TimeStampReq
6. → État RESPONSE_RECEIVED
7. nonceValidation.validateResponseNonce(nonceReq, nonceResp, repo)
   ├─ ACCEPTED → continuer
   └─ REJECTED → log + return erreur (aucune écriture DB/audit/Merkle)
8. → État RESPONSE_ACCEPTED
9. Transaction DB atomique :
   ├─ INSERT timestamp_tokens (avec nonce BYTEA)
   ├─ UPDATE timestamp_batches SET status = 'TIMESTAMPED'
   └─ COMMIT
10. → État TOKEN_PERSISTED
11. Post-commit asynchrone : append-only journal + agrégation Merkle
    (via événement BullMQ ou callback, réconciliation PD-55 en cas d'échec)

Observable : Log structuré à chaque transition d'état ; absence de writes DB si rejet nonce.

TASK-6 — Suite de tests contractuels¶

Responsabilité : Implémenter les 18 TC + 5 NR + 3 TC migration.

Fichiers : - src/modules/tsa/services/nonce.service.spec.ts (nouveau) - src/modules/tsa/services/nonce-validation.service.spec.ts (nouveau) - src/modules/tsa/processors/batch-timestamp.processor.spec.ts (modification) - src/modules/tsa/__tests__/nonce-integration.spec.ts (nouveau) - src/modules/tsa/__tests__/nonce-timing.spec.ts (nouveau) - src/modules/tsa/__tests__/nonce-migration.spec.ts (nouveau)

Mapping TC → Niveau de test :

TC supplémentaires migration (réponse R01, R02, R03) :

• TC-MIG-01 : Migration up sur schéma PD-55 vierge (aucun token existant) → succès, schema cible atteint.
• TC-MIG-02 : Migration up sur schéma PD-55 avec tokens existants (nonce hex + nonce NULL) → conversion correcte, CHECK constraint respectée, down migration restaure l'état.
• TC-MIG-03 : Post-migration, trigger trg_timestamp_token_immutable toujours actif → UPDATE rejeté.

Convention TC-264-07 ESCALADE en CI (réponse R05) : - Exit code 0 si critères statistiques atteints - Exit code 0 + artifact timing-escalation.json si premier échec, relance nécessaire - Exit code 1 + artifact timing-audit-required.json si deuxième échec → bloquant Gate 8, non bloquant Gate ⅗ - Pipeline CI : le job timing est dans un stage séparé security-timing, marqué allow_failure: true pour Gate ⅗, allow_failure: false pour Gate 8

Convention TC-264-17 Nightly (réponse R07) : - Retry automatique (3 tentatives, backoff exponentiel) - Si TSA indisponible après 3 tentatives : skip avec artifact nightly-tsa-unavailable.json contenant diagnostic - Le skip ne compte pas comme succès : le nightly reste unstable

Observable : Rapport Jest avec couverture ≥80% sur le code PD-264.

TASK-7 — Intégration Prolog (vérification formelle)¶

Responsabilité : Mettre à jour les règles Prolog RFC 3161 pour atteindre 18/18.

Fichiers : - formal-verification/prolog/rfc3161-rules.pl (modification) — ou emplacement équivalent - formal-verification/prolog/pd264-nonce.pl (nouveau)

Observable : Exécution suite Prolog → 18/18 (CA-264-10, TC-264-15).

2. Flux techniques¶

Flux nominal (happy path)¶

┌────────────────────────────────────────────────────────────────────┐
│  BatchTimestampProcessor.handleTimestamp(job)                      │
│                                                                    │
│  1. batch = batchService.getBatch(batchId)                        │
│     ├─ batch.status != SEALED → throw BATCH_NOT_SEALED            │
│     └─ OK                                                          │
│                                                                    │
│  2. nonce = nonceService.generate()   ← crypto.randomBytes(16)    │
│     └─ nonce: Buffer (16 octets)                                   │
│                                                                    │
│  3. nonceValidation.validateRequestNonce(nonce)                    │
│     ├─ null/undefined/length!=16 → throw NONCE_MISSING_IN_REQUEST │
│     └─ OK → [STATE: REQUEST_EMITTED]                               │
│                                                                    │
│  4. tsaResponse = qtsaClient.requestTimestamp({                    │
│       messageImprint: batch.rootHash,                              │
│       hashAlgorithm: SHA-256,                                      │
│       nonce: nonce                 ← injecté dans TimeStampReq     │
│     })                                                             │
│     └─ [STATE: RESPONSE_RECEIVED]                                  │
│                                                                    │
│  5. validationResult = nonceValidation.validateResponseNonce(      │
│       nonce, tsaResponse.nonce, timestampTokenRepo                 │
│     )                                                              │
│     ├─ REJECTED_ABSENT → log + return error (aucune écriture)     │
│     ├─ REJECTED_MISMATCH → log + return error (aucune écriture)   │
│     ├─ REJECTED_DUPLICATE → log + return error (aucune écriture)  │
│     └─ ACCEPTED → [STATE: RESPONSE_ACCEPTED]                      │
│                                                                    │
│  6. BEGIN TRANSACTION                                              │
│     ├─ INSERT INTO timestamp_tokens (..., nonce, ...)              │
│     ├─ UPDATE timestamp_batches SET status='TIMESTAMPED'           │
│     └─ COMMIT                                                      │
│     └─ [STATE: TOKEN_PERSISTED]                                    │
│                                                                    │
│  7. Post-commit (async, idempotent) :                              │
│     ├─ Append-only journal (vault_merkle.merkle_leaves)            │
│     ├─ Agrégation Merkle (vault_merkle.merkle_trees)               │
│     └─ Échec → réconciliation via worker PD-55                     │
│                                                                    │
│  8. return { batchId, success: true, tokenId, genTime }            │
└────────────────────────────────────────────────────────────────────┘

Flux de rejet (nonce invalide)¶

┌────────────────────────────────────────────────────────────────────┐
│  Validation nonce échouée (étape 5)                                │
│                                                                    │
│  validationResult.status = REJECTED_*                              │
│                                                                    │
│  1. Logger.warn({ event: 'NONCE_REJECTED', reason, batchId })     │
│  2. Aucun INSERT dans timestamp_tokens                             │
│  3. Aucun append dans vault_merkle.merkle_leaves                   │
│  4. Aucune inclusion Merkle dans vault_merkle.merkle_trees         │
│  5. Batch status → FAILED (avec errorCode NONCE_*)                 │
│  6. return { batchId, success: false, errorCode, errorMessage }    │
└────────────────────────────────────────────────────────────────────┘

Flux de crash (INV-264-13)¶

┌────────────────────────────────────────────────────────────────────┐
│  Cas A : crash AVANT commit (étape 6)                              │
│  → Transaction rollback automatique (PostgreSQL)                   │
│  → Aucun token persisté, aucun append, aucun Merkle               │
│  → État cohérent                                                   │
│                                                                    │
│  Cas B : crash APRÈS commit, AVANT post-commit (étape 7)          │
│  → Token persisté en base (valide)                                 │
│  → Append-only/Merkle potentiellement absents                      │
│  → Worker de réconciliation PD-55 détecte le manque               │
│  → Rattrapage idempotent (sans doublon)                            │
└────────────────────────────────────────────────────────────────────┘

2b. Diagrammes Mermaid¶

Graphe de dépendances entre composants (TASKs)¶

graph TD
    TASK1["TASK-1<br/>Migration DDL<br/>nonce VARCHAR→BYTEA"]
    TASK2["TASK-2<br/>Entity TypeORM<br/>TimestampToken"]
    TASK3["TASK-3<br/>NonceService<br/>generate / compare / uniqueness"]
    TASK4["TASK-4<br/>NonceValidationService<br/>orchestration validation"]
    TASK5["TASK-5<br/>BatchTimestampProcessor<br/>intégration flux TSA"]
    TASK6["TASK-6<br/>Tests contractuels<br/>18 TC + 5 NR + 3 MIG"]
    TASK7["TASK-7<br/>Prolog RFC 3161<br/>vérification formelle"]

    TASK1 --> TASK2
    TASK2 --> TASK3
    TASK3 --> TASK4
    TASK2 --> TASK5
    TASK4 --> TASK5
    TASK1 --> TASK6
    TASK3 --> TASK6
    TASK4 --> TASK6
    TASK5 --> TASK6
    TASK5 --> TASK7

    PD55["PD-55<br/>Module TSA existant<br/>trigger immutabilité"]
    PD39["PD-39<br/>Architecture TSA<br/>entities, enums"]
    PD237["PD-237<br/>Merkle persistence<br/>merkle_trees, merkle_leaves"]

    PD55 -.->|hérité| TASK1
    PD55 -.->|hérité| TASK2
    PD39 -.->|hérité| TASK5
    PD237 -.->|post-commit| TASK5

    style TASK1 fill:#e6f3ff,stroke:#0066cc
    style TASK2 fill:#e6f3ff,stroke:#0066cc
    style TASK3 fill:#fff2e6,stroke:#cc6600
    style TASK4 fill:#fff2e6,stroke:#cc6600
    style TASK5 fill:#ffe6e6,stroke:#cc0000
    style TASK6 fill:#e6ffe6,stroke:#006600
    style TASK7 fill:#f2e6ff,stroke:#6600cc
    style PD55 fill:#f0f0f0,stroke:#999
    style PD39 fill:#f0f0f0,stroke:#999
    style PD237 fill:#f0f0f0,stroke:#999

Diagramme de séquence — Flux nominal multi-service¶

sequenceDiagram
    participant BullMQ as BullMQ Job
    participant Processor as BatchTimestampProcessor
    participant NonceS as NonceService
    participant NonceV as NonceValidationService
    participant QTSA as QTSA Client (mock)
    participant PG as PostgreSQL
    participant Merkle as Merkle Worker (PD-237)

    BullMQ->>Processor: handleTimestamp(job)
    Processor->>Processor: batchService.getBatch(batchId)
    Note over Processor: Vérifie batch.status == SEALED

    Processor->>NonceS: generate()
    NonceS-->>Processor: nonce: Buffer(16)
    Note over NonceS: crypto.randomBytes(16) — INV-264-01

    Processor->>NonceV: validateRequestNonce(nonce)
    Note over NonceV: Garde d'entrée — CA-264-01
    NonceV-->>Processor: OK

    Note over Processor: [STATE: REQUEST_EMITTED]

    Processor->>QTSA: requestTimestamp({rootHash, nonce})
    QTSA-->>Processor: TimeStampResp {token, nonce}

    Note over Processor: [STATE: RESPONSE_RECEIVED]

    Processor->>NonceV: validateResponseNonce(nonceReq, nonceResp, repo)
    NonceV->>NonceS: compareEqual(nonceReq, nonceResp)
    Note over NonceS: crypto.timingSafeEqual — INV-264-04
    NonceS-->>NonceV: true
    NonceV->>PG: SELECT COUNT(*) WHERE nonce = ?
    Note over PG: Vérification unicité — INV-264-05
    PG-->>NonceV: 0
    NonceV-->>Processor: ACCEPTED

    Note over Processor: [STATE: RESPONSE_ACCEPTED]

    Processor->>PG: BEGIN TRANSACTION
    Processor->>PG: INSERT timestamp_tokens (nonce BYTEA)
    Processor->>PG: UPDATE timestamp_batches SET status='TIMESTAMPED'
    Processor->>PG: COMMIT
    Note over PG: Atomicité — INV-264-13

    Note over Processor: [STATE: TOKEN_PERSISTED]

    Processor-->>Merkle: post-commit async
    Merkle->>PG: INSERT merkle_leaves
    Merkle->>PG: UPDATE merkle_trees

    Processor-->>BullMQ: {success: true, tokenId, genTime}

Diagramme de séquence — Flux de rejet (nonce mismatch)¶

sequenceDiagram
    participant Processor as BatchTimestampProcessor
    participant NonceV as NonceValidationService
    participant NonceS as NonceService
    participant PG as PostgreSQL

    Note over Processor: [STATE: RESPONSE_RECEIVED]

    Processor->>NonceV: validateResponseNonce(nonceReq, nonceResp, repo)
    NonceV->>NonceS: compareEqual(nonceReq, nonceResp)
    NonceS-->>NonceV: false (mismatch)

    NonceV-->>Processor: REJECTED_MISMATCH

    Note over Processor: Logger.warn({event: 'NONCE_REJECTED', reason: 'MISMATCH'})
    Note over Processor: Aucun INSERT timestamp_tokens
    Note over Processor: Aucun append merkle_leaves
    Note over Processor: Aucune agrégation merkle_trees

    Processor->>PG: UPDATE timestamp_batches SET status='FAILED', errorCode='NONCE_MISMATCH'
    Processor-->>Processor: return {success: false, errorCode}

3. Mapping invariants → mécanismes¶

4. Mapping critères d'acceptation → mécanismes¶

5. Mapping tests (TC-*) → mécanismes + observables¶

6. Gestion des erreurs¶

7. Impacts sécurité¶

Risques et mitigations¶

Journalisation¶

• Chaque rejet nonce → log structuré warn avec : { event, reason, batchId, timestamp }
• Chaque acceptation nonce → log info avec : { event: 'NONCE_ACCEPTED', batchId, nonceHash } (hash du nonce, pas le nonce brut)
• Aucun nonce en clair dans les logs (uniquement hash SHA-256 tronqué pour corrélation)

Conformité¶

• RFC 3161 §2.2 : nonce obligatoire dans TimeStampReq → INV-264-01
• RFC 3161 §2.4.2 : vérification nonce dans TimeStampResp → INV-264-02, INV-264-03
• RFC 3161 §4.6 : protection anti-rejeu → INV-264-05, INV-264-07

8. Hypothèses techniques¶

9. Points de vigilance (risques, dette, pièges)¶

Risques techniques¶

1. Migration sur données existantes : Si des tokens PD-55 existent avec nonce = NULL, la Phase A de migration les remplit avec 0x00...00. Ces tokens sont identifiables mais ne sont pas conformes INV-264-01 (pas de CSPRNG). C'est acceptable car ils sont antérieurs au contrat PD-264. Le CHECK constraint octet_length = 16 sera respecté.

2. Désactivation temporaire du trigger : La Phase A de migration nécessite un UPDATE (pour convertir les données), ce qui est bloqué par trg_timestamp_token_immutable. La migration doit : (1) DROP TRIGGER trg_timestamp_token_immutable, (2) UPDATE, (3) CREATE TRIGGER trg_timestamp_token_immutable. Ceci est fait dans une seule transaction de migration. Risque : si la migration échoue entre drop et recreate → rollback automatique par PostgreSQL.

3. Concurrence TC-264-06 : Le test de concurrence dépend d'un PostgreSQL réel (pas de mock). Nécessite un environnement de test d'intégration avec base réelle.

4. Faux positifs TC-264-07 : Le protocole statistique peut échouer sur infra bruyante (CI partagée). Convention : relance unique sur infra stable avant escalade.

5. TC-264-14 dépendance openssl : La version openssl doit supporter les OID et formats utilisés par la TSA mock. Vérifier la version en CI.

Dette technique identifiée¶

• Le BatchTimestampProcessor est actuellement un placeholder (QTSA_UNREACHABLE). PD-264 active le nonce mais le client QTSA complet reste hors périmètre (spec §4 exclusions). Les tests utilisent un mock TSA conforme RFC.
• L'état RESPONSE_REJECTED est in-memory (pas de table rejected_responses). Si un besoin futur de traçabilité des rejets émerge, une table dédiée sera nécessaire.

Pièges¶

• Ne pas confondre Buffer.equals() et crypto.timingSafeEqual() : Buffer.equals() n'est PAS en temps constant. Utiliser exclusivement timingSafeEqual.
• Ne pas logger le nonce en clair : Logger uniquement le hash SHA-256 tronqué.
• Ne pas oublier le 2>&1 pour les appels openssl en CI (capture stderr).
• Ne pas utiliser Math.random() même pour des IDs de corrélation (learning PD-63 : crypto.randomUUID() obligatoire).

10. Hors périmètre¶

11. Contraintes techniques¶

Dépendances inter-PD¶

Framework de test¶

• Runner : Jest (standard projet, confirmé par *.spec.ts existants)
• Tests d'intégration : PostgreSQL réel requis pour TC-264-06 (concurrence), TC-264-09 (trigger), TC-264-19 (fault injection)
• Tests unitaires : mocks TypeORM Repository
• Tests sécurité (TC-264-07) : statistiques via bibliothèque npm (ex: simple-statistics ou implémentation inline Welch t-test)
• Environnement CI : DATABASE_URL, CI=true, NODE_ENV=test

Compatibilité ESM/CJS¶

• Dépendances ESM-only identifiées : aucune (le module TSA utilise des packages CJS standards)
• Runner : Jest (CJS compatible)

12. Checklist INV/CA pré-Gate 5¶

Couverture : 14/14 INV couverts, 12/12 CA couverts. Aucune ligne vide.