480 mégaoctets : c’est le poids moyen d’un plan de chantier exporté en PDF haute résolution sur un projet de cabinet d’architecture suivi récemment, spécialisé dans les marchés publics du BTP. Un seul de ces fichiers dépassait à lui seul la limite d’upload par défaut de upload_max_filesize configurée sur l’hébergement mutualisé du cabinet, réglée à 64 Mo comme sur la grande majorité des offres grand public.
Le site du cabinet, une simple vitrine WordPress présentant les réalisations et permettant aux équipes de chantier de déposer des documents dans un espace privé, n’avait jamais été pensé pour stocker des gigaoctets de plans techniques. Le sujet ici n’est pas la visionneuse de plans côté navigateur, qui reste un développement frontend distinct, mais bien la question de l’endroit où ces fichiers doivent physiquement résider.
Le mur du quota disque
Au-delà de la limite d’upload, contournable en modifiant php.ini ou un fichier .htaccess, se posait un problème plus structurel : le quota disque global de l’offre mutualisée, fixé à 50 Go, incluait à la fois le cœur WordPress, la base de données, les sauvegardes automatiques de l’hébergeur et l’ensemble des documents déposés. Chaque nouveau chantier ajoutait plusieurs gigaoctets de plans, sans qu’aucune purge ne soit possible : les documents devaient rester accessibles pendant toute la durée légale de conservation des marchés publics.
Séparer le stockage documentaire du serveur applicatif
La solution retenue a consisté à sortir entièrement les fichiers de plans du serveur mutualisé, vers un stockage objet compatible S3, facturé au gigaoctet réellement utilisé et sans limite technique d’upload liée à PHP. WordPress ne conserve alors que les métadonnées : nom du chantier, date de dépôt, référence du lot, et un pointeur vers l’emplacement réel du fichier.
Le principe technique
Le dépôt d’un fichier depuis l’espace privé du site ne transite plus directement par le serveur d’hébergement mutualisé pour son stockage final. Le formulaire génère une URL de dépôt signée, valable quelques minutes, directement vers le bucket de stockage objet. Le fichier part donc du poste de l’utilisateur vers le stockage externe sans jamais saturer le disque de l’hébergement WordPress, ni consommer sa bande passante sortante lors des téléchargements ultérieurs.
$client = new Aws\S3\S3Client([
'version' => 'latest',
'region' => 'eu-west-3',
'credentials' => [
'key' => STOCKAGE_CLE,
'secret' => STOCKAGE_SECRET,
],
]);
$commande = $client->getCommand( 'PutObject', [
'Bucket' => 'plans-chantiers-cabinet',
'Key' => 'lot-' . $lot_id . '/' . $nom_fichier,
] );
$requete = $client->createPresignedRequest( $commande, '+15 minutes' );
$url_upload = (string) $requete->getUri();Cette URL signée est ensuite transmise au formulaire côté navigateur, qui effectue l’envoi directement vers le stockage objet. Seule la confirmation du dépôt, une fois terminé, revient vers WordPress pour enregistrer les métadonnées du document dans une table personnalisée.
Des liens temporaires plutôt que publics
Point sensible sur un projet de marché public : les plans de chantier ne doivent pas être librement accessibles à qui devine ou trouve l’URL. Le bucket de stockage a donc été configuré en accès strictement privé, et chaque téléchargement depuis le site génère une URL signée à durée de vie courte, généralement dix minutes, plutôt qu’un lien public permanent stocké tel quel dans la base de données.
- Bucket configuré en accès privé par défaut, sans exception publique.
- Génération d’une URL signée à chaque demande de téléchargement, jamais stockée telle quelle.
- Journalisation des accès aux documents pour disposer d’une traçabilité en cas de litige sur un marché.
- Suppression différée après la durée légale de conservation, gérée par une règle de cycle de vie côté stockage plutôt que manuellement.
Ce que le mutualisé garde en charge
L’hébergement mutualisé d’origine n’a pas été abandonné : il continue de faire tourner WordPress, la base de données des métadonnées et le site vitrine public. Seuls les fichiers volumineux en sont sortis. Cette approche a permis d’éviter une migration complète vers un serveur dédié, dont le coût mensuel aurait été sans commune mesure avec le problème réellement posé, qui était un problème de stockage et non de puissance de calcul.
Un repère utile sur ce type de projet : ne jamais confondre un problème de capacité de stockage avec un problème de performance serveur. Les deux appellent des solutions complètement différentes, et la mauvaise réponse coûte cher.
Pour aller plus loin
Cette architecture se généralise à tout site WordPress confronté à des documents lourds et peu consultés : archives de dossiers, exports de bases de données volumineuses, vidéos de présentation. Le principe reste identique : garder sur le serveur d’hébergement ce qui a besoin d’être exécuté, et confier au stockage objet ce qui n’a besoin que d’être conservé et servi de temps en temps, avec un contrôle d’accès strict sur les liens générés.
