Simulateur de remboursement sur un site de mutuelle : les 3 approches techniques, l’UX et les budgets en 2026
09 / 03 / 2025
Pourquoi le simulateur de remboursement est le premier levier de conversion d’une mutuelle
Le prospect qui cherche une mutuelle santé a une question principale : « combien vais-je payer de ma poche pour mes soins ? ». La fiche produit ne répond pas à cette question — elle liste des garanties en pourcentages de BR (base de remboursement) ou en euros forfaitaires, dans un langage que 80 % des prospects ne comprennent pas. Le simulateur traduit ces garanties en euros concrets, personnalisés selon le profil du prospect (formule, zone tarifaire, composition familiale) et selon l’acte de soin (consultation, hospitalisation, optique, dentaire). C’est cette traduction qui déclenche la décision : un prospect qui voit que sa mutuelle lui laisse 15 € à charge pour un spécialiste est plus avancé dans sa décision qu’un prospect qui lit « 150 % BR ». Notre article sur les exemples de remboursement mutuelle détaille comment présenter ces données de manière compréhensible.
L’impact sur la conversion est mesuré : sur les sites de mutuelles que nous accompagnons, les pages avec simulateur ont un taux de conversion 2 à 3 fois supérieur aux pages produits sans simulateur. Le simulateur est aussi un outil de montée en gamme : un adhérent qui simule ses remboursements sur sa formule actuelle et qui voit un reste à charge élevé en optique est un candidat naturel à la formule supérieure. C’est pourquoi le simulateur doit être déployé à la fois sur le site vitrine (pour les prospects) et dans l’espace client (pour les adhérents, pré-rempli avec leur formule).
Les 3 approches techniques : API, base locale ou widget
| Approche | Principe | Avantages | Limites | Budget |
|---|---|---|---|---|
| API système de gestion | Le simulateur appelle en temps réel l’API du SI de gestion de la mutuelle pour calculer le remboursement | Toujours à jour, données réelles, cohérence totale avec le back-office | Dépendance au SI (temps de réponse, disponibilité), complexité d’intégration, DORA | 15 000 — 25 000 € |
| Base de règles locale | Le moteur de calcul est hébergé côté site web, alimenté par un export périodique des règles de garantie | Autonome du SI, temps de réponse rapide, fonctionne même si le SI est indisponible | Synchronisation nécessaire à chaque évolution des garanties, risque de décalage | 8 000 — 18 000 € |
| Widget éditeur tiers | Un widget fourni par l’éditeur du système de gestion (Cegedim, In4 Group, Itelis, etc.) intégré en iframe | Rapide à déployer, maintenance par l’éditeur, données toujours à jour | UX limitée (iframe), personnalisation graphique restreinte, dépendance éditeur, RGAA difficile | 3 000 — 8 000 € |
Notre recommandation pour la majorité des mutuelles : la base de règles locale. Elle offre le meilleur rapport qualité/contrôle/budget : le simulateur est rapide (pas de latence API), personnalisable (UX maîtrisée, design system respecté, RGAA conforme) et indépendant du SI (pas de risque d’indisponibilité pendant un pic de trafic). La synchronisation avec le SI est gérée par un export structuré (JSON ou CSV) mis à jour à chaque évolution des garanties — typiquement 2 à 4 fois par an. L’API temps réel se justifie quand le simulateur doit accéder aux données personnelles de l’adhérent (formule en cours, historique de remboursement) — c’est le cas dans l’espace adhérent, pas sur le site vitrine.
Les pièges UX d’un simulateur de remboursement
Le premier piège est le jargon technique. Un simulateur qui affiche « Consultation spécialiste secteur 2 — OPTAM : remboursement 70 % BR + 100 % du dépassement plafonné à 150 % BR — RAC estimé : cf. conditions » ne convertit pas — il fait fuir. Le résultat doit être affiché en euros, en 3 lignes : « Sécurité sociale rembourse : 25 €. Votre mutuelle rembourse : 35 €. Vous payez : 15 € ». Le prospect ne veut pas comprendre le mécanisme — il veut voir le montant.
Le deuxième piège est le nombre de clics avant le résultat. Un simulateur qui demande 8 champs avant d’afficher quoi que ce soit perd 60 à 70 % de ses utilisateurs en route. La bonne pratique : un résultat visible en 3 clics maximum — (1) choix du type d’acte (consultation, hospitalisation, optique, dentaire), (2) choix du détail (spécialiste secteur 2, chambre particulière, verres progressifs), (3) affichage du résultat avec la répartition SS / mutuelle / reste à charge. Les champs complémentaires (formule, zone tarifaire) sont pré-remplis ou déduits du contexte.
Le troisième piège est l’accessibilité RGAA. Un simulateur en iframe ou en widget JavaScript est souvent inaccessible : pas de navigation au clavier, pas de labels sur les champs, résultats non vocalisables par un lecteur d’écran. Depuis juin 2025, tout nouveau simulateur doit être conforme RGAA. Cela impose que le simulateur soit intégré au DOM principal (pas en iframe), avec des labels explicites sur chaque champ, des messages d’erreur associés, un focus visible et une alternative textuelle sur chaque résultat graphique.
L’intégration du 100 % Santé : la contrainte réglementaire qui complexifie le moteur
Le dispositif 100 % Santé (optique, dentaire, audiologie) impose que le simulateur distingue clairement les paniers de soins : le panier « 100 % Santé » (reste à charge zéro sur les équipements du panier) et le panier libre (dépassements possibles, reste à charge variable). Le simulateur doit donc afficher deux résultats pour chaque acte concerné : « Si vous choisissez un équipement 100 % Santé : reste à charge 0 €. Si vous choisissez un équipement hors panier : reste à charge estimé XX € ». Cette double présentation est une obligation réglementaire (les contrats responsables doivent la rendre visible) mais aussi un levier pédagogique puissant — beaucoup d’assurés ne savent pas que le 100 % Santé existe sur leur contrat.
Le 100 % Santé évolue régulièrement (extension des paniers, révision des plafonds), ce qui renforce l’intérêt de la base de règles locale synchronisée : les mises à jour réglementaires sont intégrées dans l’export JSON sans intervention sur le code du simulateur.
Budgets et délais de développement
Le budget dépend principalement de l’approche technique choisie et du nombre d’actes couverts par le simulateur. Un simulateur « essentiel » (4 familles d’actes : consultation, hospitalisation, optique, dentaire) en base de règles locale représente 8 000 à 15 000 € HT et 4 à 6 semaines de développement. Un simulateur « complet » (toutes les lignes de garanties, y compris médecines douces, prévention, audiologie, avec les 3 paniers 100 % Santé) en API temps réel représente 18 000 à 25 000 € HT et 6 à 10 semaines. Le widget éditeur tiers est le plus rapide (3 000-8 000 € HT, 2-3 semaines) mais le moins personnalisable. Le parcours devis-souscription intègre souvent le simulateur comme étape intermédiaire entre le tarif et la souscription — le budget du simulateur est alors inclus dans le budget global du parcours. Contactez notre équipe pour un cadrage ou consultez notre grille tarifaire 2026.
En conclusion : le simulateur est l’investissement qui convertit le mieux sur un site de mutuelle
Un simulateur de remboursement bien conçu est le seul outil du site qui répond directement à la question que le prospect se pose : « combien vais-je payer ? ». Les pages produits, les tableaux de garanties et les FAQ informent — le simulateur convertit. Son budget (8 000 à 25 000 € HT) se rentabilise en quelques mois par l’augmentation du taux de conversion (×2 à ×3 sur les pages avec simulateur vs sans). Le piège à éviter : un simulateur technique qui parle le langage de l’assureur (codes CCAM, pourcentages BR) au lieu du langage du prospect (euros, reste à charge). Le simulateur parfait est celui où le prospect oublie qu’il utilise un outil — il voit simplement ce qu’il va payer.
Questions fréquentes sur le simulateur de remboursement mutuelle
Combien coûte un simulateur de remboursement pour un site de mutuelle ?
De 3 000 à 25 000 € HT selon l’approche et la couverture. Un widget éditeur tiers (intégration iframe) coûte 3 000-8 000 €. Une base de règles locale avec 4 familles d’actes coûte 8 000-15 000 €. Un simulateur complet en API temps réel connecté au SI de gestion coûte 18 000-25 000 €. Le ROI se mesure sur le taux de conversion : les pages avec simulateur convertissent 2 à 3 fois mieux que les pages produits sans simulateur.
Le simulateur doit-il être connecté au système de gestion en temps réel ?
Pas nécessairement sur le site vitrine. Pour un prospect qui ne connaît pas encore sa formule, une base de règles locale (alimentée par un export périodique des garanties) suffit et offre une meilleure UX (pas de latence, pas de dépendance au SI). La connexion API temps réel se justifie dans l’espace adhérent, où le simulateur est pré-rempli avec la formule et les données personnelles de l’adhérent.
Comment intégrer le 100 % Santé dans le simulateur ?
Le simulateur doit distinguer les deux paniers pour chaque acte concerné (optique, dentaire, audiologie) : le panier 100 % Santé (reste à charge 0 €) et le panier libre (reste à charge variable). La double présentation est obligatoire pour les contrats responsables. En pratique, le moteur de calcul applique deux jeux de règles en parallèle et affiche les deux résultats côte à côte — le prospect choisit ensuite en connaissance de cause.
Le simulateur doit-il être accessible RGAA ?
Oui, obligatoirement depuis juin 2025 pour tout nouveau simulateur. Concrètement : pas d’iframe (intégration au DOM principal), labels sur tous les champs, messages d’erreur associés au champ concerné, navigation au clavier, focus visible, résultats vocalisables par un lecteur d’écran. Un simulateur en widget tiers (iframe) est très difficilement conforme RGAA — c’est l’une des raisons pour lesquelles nous recommandons la base de règles locale avec un développement front-end maîtrisé.
Faut-il un simulateur différent sur le site vitrine et dans l'espace adhérent ?
Le moteur de calcul est le même. La différence porte sur les données d’entrée et le positionnement. Sur le site vitrine (prospect), le simulateur demande de choisir une formule et affiche un résultat estimé — c’est un outil de conversion qui mène vers le devis. Dans l’espace adhérent, le simulateur est pré-rempli avec la formule en cours et peut accéder aux données personnelles via l’API — c’est un outil de selfcare et de montée en gamme. La même base de règles alimente les deux versions, avec une couche front-end différente.
IP, si vous nous contactiez pour échanger sur vos projets digitaux ?
Tous les détails sur notre page contact ou en visio ci-dessous
Échangeons sur vos enjeux
Ils nous font confiance
