Deux ans : c’est la durée de conservation maximale recommandée pour un CV non retenu, avant qu’il ne doive disparaître du serveur. Cette limite engage directement la responsabilité de l’hébergeur d’une plateforme de recrutement, puisqu’un CV contient un nom, une adresse, parfois une photo, une situation familiale en creux, un parcours de santé implicite. C’est une donnée à caractère personnel au sens plein, et son hébergement mérite une checklist d’infrastructure précise, indépendante de la façon dont le formulaire de candidature est construit côté front.
Cette liste s’adresse au développeur qui installe, configure et maintient le serveur derrière une plateforme WordPress de recrutement. Elle ne traite pas des champs du formulaire ni du consentement affiché à l’utilisateur : ce sujet appartient à l’équipe produit. Elle se concentre sur ce qui se passe une fois le CV déposé, entre la base de données, le système de fichiers et les sauvegardes.
Chiffrement des données au repos et en transit
Le protocole HTTPS ne suffit pas à couvrir l’ensemble de la chaîne. Un CV transite en clair vers le serveur puis, souvent, repose sans chiffrement dans un dossier wp-content/uploads classique. Pour un cabinet de recrutement, il faut vérifier trois points : le volume de stockage est-il chiffré au niveau du système de fichiers (LUKS ou équivalent chez l’hébergeur), la base de données MySQL utilise-t-elle un chiffrement au repos, et les sauvegardes qui en sortent sont-elles elles-mêmes chiffrées avant d’être copiées ailleurs. Sans ces trois couches, le chiffrement en transit ne protège qu’un tiers du trajet réel de la donnée.
Isoler le dossier des candidatures
Une pratique efficace consiste à sortir les fichiers de CV du dossier public uploads pour les stocker dans un répertoire non exposé au web, servi ensuite par un script PHP qui vérifie les droits avant de renvoyer le fichier. Cela évite qu’une simple énumération d’URL ne donne accès à des centaines de CV.
Durée de conservation et purge automatisée
La conservation indéfinie d’un CV non retenu est l’erreur la plus fréquente constatée sur ce type de plateforme. La recommandation généralement admise fixe une durée de deux ans après le dernier contact avec le candidat, sauf accord explicite de ce dernier pour une conservation plus longue en vue de futures opportunités. Côté infrastructure, cela se traduit par une tâche planifiée qui identifie et supprime les fichiers et les enregistrements concernés, plutôt que par une bonne intention notée dans un document interne jamais exécutée.
wp eval '
$candidats = get_posts([
"post_type" => "candidature",
"meta_key" => "date_dernier_contact",
"meta_compare" => "<",
"meta_value" => date("Y-m-d", strtotime("-2 years")),
"numberposts" => -1,
]);
foreach ($candidats as $candidat) {
$chemin_cv = get_post_meta($candidat->ID, "chemin_cv", true);
if ($chemin_cv && file_exists($chemin_cv)) {
unlink($chemin_cv);
}
wp_delete_post($candidat->ID, true);
}
'
Cette commande, lancée via une tâche cron système hebdomadaire, garantit que la purge a réellement lieu, sans dépendre d’une visite sur le site (le pseudo-cron intégré de WordPress ne se déclenche que si un visiteur charge une page). Elle doit être testée en environnement de recette avant tout déploiement en production, avec une sauvegarde préalable.
Contrôle des accès et traçabilité
Qui peut consulter un CV sur le serveur ? La réponse doit être limitée aux comptes strictement nécessaires. Un accès SSH large, partagé entre plusieurs collaborateurs sous un identifiant unique, empêche toute traçabilité en cas d’incident. Voici les points à vérifier :
- Chaque personne ayant accès au serveur dispose de son propre compte système, avec sa propre clé SSH ; aucun mot de passe partagé.
- Les accès à la base de données transitent par un compte applicatif dédié, distinct du compte administrateur MySQL.
- Les journaux d’accès au serveur web sont conservés une durée raisonnable et consultables en cas de signalement d’incident.
- Les accès administrateur WordPress à la liste des candidatures sont journalisés, par exemple via un plugin d’audit ou un hook personnalisé sur
save_postet sur la consultation des pièces jointes. - Toute extraction manuelle de données (export CSV, dump SQL partiel) fait l’objet d’une trace écrite indiquant qui, quand, pourquoi.
Sous-traitants et hébergeur
L’hébergeur qui stocke les CV est un sous-traitant au sens du RGPD. Il doit apparaître dans le registre des traitements du cabinet de recrutement, avec un contrat qui précise la localisation des données, les mesures de sécurité appliquées et les modalités de restitution ou de suppression en fin de contrat. Un hébergement situé hors de l’Union européenne n’est pas interdit en soi, mais il ajoute une couche de vérification (clauses contractuelles types, décision d’adéquation) qu’il vaut mieux anticiper avant la mise en production plutôt que de la découvrir lors d’un contrôle.
| Mesure | Risque couvert |
|---|---|
| Chiffrement du volume de stockage | Vol physique du disque ou de la sauvegarde |
| Purge automatisée après deux ans | Conservation excessive, sanction en cas de contrôle |
| Comptes SSH individuels | Absence de traçabilité en cas d’incident interne |
| Contrat avec l’hébergeur | Sous-traitance non encadrée |
Une règle simple à appliquer sur tous nos projets de ce type : si une mesure de protection des données n’est pas automatisée par un script ou une tâche planifiée, elle finira par ne plus être appliquée du tout.
Gestion des sauvegardes
Les sauvegardes constituent souvent l’angle mort des audits de sécurité. Un CV supprimé de la base de production peut rester des mois dans une sauvegarde non chiffrée, oubliée sur un stockage secondaire. Il faut donc appliquer la même politique de rétention aux sauvegardes qu’aux données vivantes : rotation limitée, chiffrement systématique de l’archive avant son transfert, et suppression effective des sauvegardes les plus anciennes plutôt qu’un archivage perpétuel par prudence mal placée.
En résumé
Héberger les candidatures d’un cabinet de recrutement demande une discipline d’infrastructure qui dépasse largement la simple case à cocher du formulaire de consentement. Chiffrement à chaque étape, purge automatisée et vérifiable, accès individualisés et tracés, contrat clair avec l’hébergeur : ce sont ces quatre piliers qui transforment une conformité déclarative en conformité réelle, celle qui résiste à un contrôle comme à un incident de sécurité.
