Un simulateur de tarif de mutuelle santé n’a, en réalité, jamais besoin de connaître un antécédent médical pour produire un prix indicatif : l’essentiel du calcul actuariel repose sur l’âge, la composition du foyer, le département de résidence et le niveau de garantie souhaité. Pour un courtier qui propose cette simulation en ligne, la vraie difficulté n’est pas le calcul lui-même, mais la conception du formulaire et du stockage pour qu’aucune donnée de santé identifiable ne transite ni ne soit conservée.
Ce tutoriel détaille, étape par étape, la construction d’une extension de simulation qui respecte ce principe de minimisation dès sa conception, plutôt que de l’ajouter après coup sous la pression d’un audit de conformité.
Étape 1 : définir les critères réellement nécessaires au calcul
Le formulaire ne collecte que des critères actuariels standards, sans aucune question de nature médicale : date de naissance (pour l’âge), code postal (pour la zone tarifaire), nombre de personnes à couvrir, et un niveau de garantie choisi parmi des formules prédéfinies (essentielle, intermédiaire, renforcée). Aucun champ ne demande un antécédent, un traitement en cours ou une pathologie.
Étape 2 : calculer côté serveur, sans persister l’entrée
Le calcul du tarif s’effectue dans un contrôleur REST personnalisé qui reçoit les critères, calcule le résultat, et ne conserve dans aucune base de données les valeurs individuelles reçues :
add_action( 'rest_api_init', function() {
register_rest_route( 'mutuelle/v1', '/simuler', array(
'methods' => 'POST',
'callback' => 'mutuelle_calculer_tarif',
'permission_callback' => '__return_true',
'args' => array(
'annee_naissance' => array( 'type' => 'integer', 'required' => true ),
'code_postal' => array( 'type' => 'string', 'required' => true ),
'personnes' => array( 'type' => 'integer', 'required' => true ),
'formule' => array( 'type' => 'string', 'required' => true ),
),
) );
} );
function mutuelle_calculer_tarif( WP_REST_Request $request ) {
$age = gmdate( 'Y' ) - $request->get_param( 'annee_naissance' );
$zone = mutuelle_zone_depuis_code_postal( $request->get_param( 'code_postal' ) );
$base = mutuelle_tarif_base( $request->get_param( 'formule' ) );
$tarif = $base * mutuelle_coefficient_age( $age ) * $zone['coefficient'] * $request->get_param( 'personnes' );
return new WP_REST_Response( array( 'tarif_mensuel' => round( $tarif, 2 ) ), 200 );
}Aucune ligne de ce contrôleur n’appelle wp_insert_post(), update_option() ou une table personnalisée : le résultat est calculé et renvoyé dans la même requête, sans trace persistante des critères saisis.
Étape 3 : ne garder qu’un résultat agrégé pour le suivi commercial
Si le courtier souhaite néanmoins savoir combien de simulations ont été effectuées, seule une donnée agrégée et anonyme doit être incrémentée, jamais une ligne par simulation individuelle :
add_action( 'rest_after_insert_simulation', function() {
$compteur = (int) get_option( 'mutuelle_nb_simulations_jour', 0 );
update_option( 'mutuelle_nb_simulations_jour', $compteur + 1 );
} );Ce compteur ne permet à aucun moment de reconstituer le profil d’un visiteur en particulier : il ne renseigne que sur le volume global d’utilisation du simulateur.
Étape 4 : gérer le passage vers la souscription sans profil persistant
Lorsqu’un visiteur souhaite être recontacté après avoir vu son tarif, seule cette étape justifie la collecte d’une donnée personnelle identifiante : nom et coordonnées, via un formulaire distinct et explicite, avec une case de consentement clairement dissociée du calcul de tarif lui-même. Le résultat de la simulation est alors transmis en clair dans le corps de la demande de contact, sans reconstituer côté serveur un historique de session lié à un identifiant technique.
Étape 5 : purger tout stockage temporaire éventuel
Si un état intermédiaire doit être conservé quelques minutes, par exemple pour permettre de revenir en arrière dans un formulaire multi-étapes, un transient à durée de vie courte, identifié par un jeton aléatoire côté client via wp_generate_uuid4(), convient mieux qu’une session persistante liée à une adresse IP ou à un compte utilisateur :
set_transient( 'mutuelle_etape_' . $jeton, $criteres, 10 * MINUTE_IN_SECONDS );La purge automatique après dix minutes, gérée nativement par l’API des transients, évite d’avoir à mettre en place une tâche de nettoyage manuelle et limite la durée de vie de toute donnée intermédiaire.
Ce qu’il ne faut jamais faire
- Ajouter un champ libre « Précisez votre situation médicale » dans le formulaire de simulation, même optionnel : sa seule présence transforme la nature du traitement de données.
- Journaliser les paramètres de requête dans les journaux du serveur web sans filtrage, ce qui reviendrait à conserver indirectement des critères personnels dans des fichiers de log non maîtrisés.
- Réutiliser l’adresse email d’un formulaire de contact ultérieur pour retrouver et enrichir automatiquement une simulation passée, ce qui recréerait un profil sans base légale claire.
En résumé
Un simulateur de tarif de mutuelle bien conçu prouve qu’il est possible de fournir un résultat pertinent sans jamais transformer un visiteur anonyme en profil identifié. La discipline tient dans la conception du formulaire, l’absence de persistance des critères individuels, et une séparation stricte entre le calcul du tarif et la collecte volontaire de coordonnées pour un rappel commercial.
