Un simulateur de tarif n’a pas besoin de connaître l’identité de la personne qui le remplit pour produire une estimation fiable. C’est ce principe simple, souvent négligé dans la précipitation d’un cahier des charges, qui a guidé la conception de ce bloc : si le calcul ne dépend que de l’âge et d’un niveau de garantie choisi, rien n’oblige à transmettre quoi que ce soit à un serveur, ni même à demander un nom ou une adresse électronique avant d’afficher un résultat.
Ce billet détaille la construction d’un bloc de simulation de cotisation pour une mutuelle, pensé dès le départ pour rester conforme au RGPD par construction plutôt que par ajout de mentions légales après coup. La souscription en ligne, qui suit la simulation et implique cette fois des données personnelles, relève d’un parcours distinct non traité ici.
Poser la question avant d’écrire le code
La première réunion de cadrage avec la mutuelle a permis de trancher une question essentielle : la simulation devait-elle vraiment demander une identité avant d’afficher un résultat ? La réponse a été non. Une estimation de tarif basée sur l’âge et un niveau de garantie ne nécessite aucune information nominative, et chaque donnée demandée en trop constitue un risque RGPD et un frein à la conversion.
Une formule de calcul entièrement publique
Le barème de tarification, fourni par la mutuelle sous forme de grille par tranche d’âge et par niveau de garantie, a été intégré directement dans le script du bloc, sous forme d’un objet JavaScript statique :
const bareme = {
essentiel: { '18-30': 32, '31-45': 41, '46-60': 58, '61+': 79 },
confort: { '18-30': 48, '31-45': 62, '46-60': 87, '61+': 118 },
premium: { '18-30': 71, '31-45': 92, '46-60': 129, '61+': 174 },
};
function estimerTarif( age, niveau ) {
const tranche = age <= 30 ? '18-30' : age <= 45 ? '31-45' : age <= 60 ? '46-60' : '61+';
return bareme[ niveau ][ tranche ];
}
Le bloc côté éditeur : deux réglages, rien de plus
Le formulaire visible sur le site ne comporte que deux champs : un curseur d’âge et un choix de niveau de garantie. Aucun champ nom, aucun champ courriel, aucun champ téléphone. Le résultat s’affiche instantanément, recalculé à chaque changement, sans bouton « valider » ni aller-retour serveur.
<RangeControl
label="Âge"
value={ age }
onChange={ ( valeur ) => setAge( valeur ) }
min={ 18 }
max={ 75 }
/>Ce que cette approche évite concrètement
- Aucun registre de traitement supplémentaire à tenir pour cette simulation
- Aucune donnée personnelle à sécuriser, puisqu’aucune n’est collectée à cette étape
- Aucun consentement à recueillir avant d’afficher une simple estimation
Le point de bascule vers la souscription
Une fois le tarif affiché, un bouton « Être rappelé pour souscrire » ouvre un second formulaire, distinct, celui-là bien soumis aux règles de collecte de données personnelles classiques : mentions d’information, case de consentement, formulaire chiffré en transit. La séparation nette entre les deux étapes, purement technique, a aussi simplifié l’analyse juridique menée par la mutuelle avant mise en ligne.
Un détail souvent oublié : le stockage local du navigateur
Le bloc conserve la dernière simulation dans le stockage local du navigateur, pour la retrouver si l’utilisateur revient sur la page. Ce stockage reste strictement local à l’appareil, jamais transmis à un serveur, et ne contient que l’âge et le niveau choisis, aucune information identifiante.
function memoriserSimulation( age, niveau ) {
try {
localStorage.setItem( 'derniere_simulation', JSON.stringify( { age, niveau } ) );
} catch ( erreur ) {
// navigation privée ou stockage désactivé : on ignore simplement
}
}Cette précaution évite de faire échouer l’ensemble du bloc si le stockage local n’est pas disponible, un cas fréquent en navigation privée. Le simulateur continue de fonctionner normalement, sans mémorisation entre deux visites, ce qui reste largement préférable à une erreur affichée dans l’interface.
Face à une demande de simulateur, la première question à poser n’est jamais « comment on calcule le tarif », mais « a-t-on vraiment besoin d’une identité pour répondre à cette question » : la réponse change souvent toute l’architecture du bloc.
Notre verdict
Un simulateur de cotisation qui ne dépend que de critères non identifiants gagne à rester entièrement côté client, sans aucune requête serveur ni collecte de donnée personnelle. Cette approche réduit à la fois le risque juridique pour la mutuelle et la friction ressentie par un visiteur qui veut simplement une estimation rapide, sans engagement.
