Formulaire de sinistre en bloc pour un assureur, sans pièce jointe en base

Une photo de dégât des eaux, un constat scanné, parfois une vidéo courte : les pièces jointes d’une déclaration de sinistre pèsent en moyenne huit mégaoctets chacune, et un dossier complet peut en contenir quatre ou cinq. Stocker ce volume directement dans la table wp_postmeta, sous forme de contenu encodé, aurait rapidement transformé cette table en goulet d’étranglement pour l’ensemble du site.

Pourquoi wp_postmeta n’est pas fait pour ça

La table wp_postmeta est optimisée pour de petites valeurs, consultées fréquemment : un champ de configuration, une préférence utilisateur, un identifiant de relation entre contenus. Y stocker des fichiers de plusieurs mégaoctets encodés en base64 dégrade les performances de toutes les requêtes qui touchent cette table, y compris celles qui n’ont rien à voir avec les sinistres, puisque la table grossit pour l’ensemble du site.

Arborescence de la solution retenue

wp-content/plugins/assureur-sinistres/
├── block.json
├── src/
│   ├── index.js
│   └── edit.js
├── includes/
│   ├── class-route-upload.php
│   └── class-stockage-externe.php
└── assureur-sinistres.php

Router l’upload vers un stockage externe

Le bloc de formulaire envoie chaque pièce jointe directement vers un service de stockage objet externe, sans jamais faire transiter le fichier par une table de la base de données WordPress. Seule une référence (une URL et un identifiant) revient ensuite s’enregistrer dans wp_postmeta :

function assureur_router_piece_jointe( $requete ) {
    $fichier = $requete->get_file_params()['piece_jointe'];

    $reponse_stockage = wp_remote_post(
        'https://stockage-externe.example/api/objets',
        array(
            'headers' => array( 'Authorization' => 'Bearer ' . ASSUREUR_CLE_STOCKAGE ),
            'body'    => file_get_contents( $fichier['tmp_name'] ),
        )
    );

    if ( is_wp_error( $reponse_stockage ) ) {
        return new WP_Error( 'echec_stockage', 'La pièce jointe n\'a pas pu être transmise.' );
    }

    $donnees_stockage = json_decode( wp_remote_retrieve_body( $reponse_stockage ), true );

    return array(
        'reference_externe' => $donnees_stockage['identifiant'],
        'url_temporaire'    => $donnees_stockage['url_signee'],
    );
}

Ce que WordPress conserve réellement

Une fois le fichier transmis au stockage externe, seule la référence légère revient s’enregistrer dans wp_postmeta, associée au dossier de sinistre correspondant :

function assureur_enregistrer_reference_piece_jointe( $id_dossier, $reference_externe ) {
    $references_existantes = get_post_meta( $id_dossier, '_references_pieces_jointes', true );
    $references_existantes = is_array( $references_existantes ) ? $references_existantes : array();
    $references_existantes[] = $reference_externe;

    update_post_meta( $id_dossier, '_references_pieces_jointes', $references_existantes );
}

Cette référence occupe quelques dizaines d’octets, contre plusieurs mégaoctets pour le fichier lui-même : la table wp_postmeta reste légère quel que soit le nombre de dossiers de sinistre traités.

Consulter une pièce jointe depuis l’administration

Quand un gestionnaire de sinistre consulte un dossier, l’administration WordPress interroge le service de stockage externe à la volée, via la référence conservée, pour générer une URL signée temporaire, plutôt que de conserver un lien permanent qui exposerait durablement le fichier.

Ce que cette architecture ne traite pas

Le chiffrement du stockage externe lui-même, sa politique de rétention ou son niveau de certification réglementaire pour des données sensibles restent des sujets propres au service de stockage choisi, et sortent du périmètre de cet article centré sur l’architecture du bloc WordPress lui-même.

• Aucun fichier volumineux ne transite jamais par la base de données WordPress ;
• Le stockage externe gère lui-même la durabilité et la redondance des fichiers ;
• WordPress ne conserve qu’une référence, ce qui garde la table wp_postmeta légère quel que soit le volume de dossiers traités.

Un formulaire qui reçoit des pièces jointes ne doit jamais confondre le rôle de la base de données WordPress avec celui d’un système de stockage de fichiers : les deux ont des contraintes très différentes.

En résumé

Pour un bloc de déclaration de sinistre destiné à un assureur, router les pièces jointes vers un stockage externe et ne conserver qu’une référence légère dans wp_postmeta évite de dégrader les performances de l’ensemble du site à mesure que le volume de dossiers augmente. Le chiffrement et la conformité du stockage lui-même restent un sujet distinct, propre au service retenu.