Quelle différence sépare l’affichage de formules de garanties comparables et la gestion de dossiers d’assurés ? Une frontière que certains projets franchissent par accident : au moment de concevoir l’affichage des formules d’une mutuelle santé, il est tentant d’ajouter un champ « bénéficiaire type » ou un exemple chiffré personnalisé, sans réaliser que ce choix de conception ouvre la porte à une confusion dangereuse entre contenu éditorial public et donnée personnelle d’assuré.
Le principe retenu ici est strict dès la conception : les formules affichées sur le site public restent des articles génériques, décrivant des niveaux de garantie (hospitalisation, optique, dentaire) sans jamais associer la moindre donnée nominative. Le simulateur de cotisation, qui lui manipule potentiellement des données liées à un profil d’assuré, reste un sujet entièrement séparé, traité dans une catégorie dédiée aux blocs interactifs.
Modéliser une formule comme un contenu générique
Chaque formule de garantie est un article du type formule, avec des métadonnées volontairement limitées à des informations structurelles publiques : niveau de remboursement par poste, plafond annuel, franchise éventuelle. Aucune de ces métadonnées ne concerne un individu, elles décrivent uniquement une offre commerciale :
register_post_type( 'formule', array(
'label' => 'Formules de garanties',
'public' => true,
'show_in_rest' => true,
) );
foreach ( array( 'formule_niveau_hospitalisation', 'formule_niveau_optique', 'formule_niveau_dentaire', 'formule_plafond_annuel' ) as $champ ) {
register_post_meta( 'formule', $champ, array(
'show_in_rest' => true,
'single' => true,
'type' => 'string',
) );
}Construire le tableau comparatif avec Query Loop
Le gabarit d’archive des formules affiche une Query Loop réglée sur une disposition en grille, avec un bloc Post Template qui aligne les niveaux de garantie sous forme de badges (bronze, argent, or) plutôt que de pourcentages bruts, plus lisibles pour un visiteur qui compare rapidement plusieurs offres :
<!-- wp:query {"query":{"postType":"formule"},"layout":{"type":"grid","columnCount":3}} -->
<!-- wp:post-template -->
<!-- wp:post-title /-->
<!-- wp:post-meta {"metaKey":"formule_niveau_hospitalisation"} /-->
<!-- wp:post-meta {"metaKey":"formule_niveau_optique"} /-->
<!-- /wp:post-template -->
<!-- /wp:query -->Pourquoi éviter le bloc de champ personnalisé générique ici
Le bloc natif d’affichage de champ personnalisé de l’éditeur de blocs a longtemps souffert d’une limite connue : il peut, selon la configuration du site, exposer n’importe quelle métadonnée d’un article, y compris des métadonnées ajoutées involontairement par une autre extension. Pour un site de ce secteur, il est plus sûr de passer par un rendu dynamique explicite, listant précisément les champs autorisés à s’afficher, plutôt que de laisser un réglage générique piocher librement dans les métadonnées de l’article.
add_filter( 'render_block', function( $contenu, $bloc ) {
if ( 'core/post-meta' !== $bloc['blockName'] ) {
return $contenu;
}
$champs_autorises = array( 'formule_niveau_hospitalisation', 'formule_niveau_optique', 'formule_niveau_dentaire', 'formule_plafond_annuel' );
if ( ! in_array( $bloc['attrs']['metaKey'] ?? '', $champs_autorises, true ) ) {
return '';
}
return $contenu;
}, 10, 2 );Ce qui ne doit jamais apparaître dans ce gabarit
La règle de conception la plus importante à faire respecter, y compris par un client pressé qui voudrait « juste ajouter un exemple concret », est l’interdiction absolue de tout champ qui accepterait une saisie identifiante : nom d’assuré, numéro de contrat, date de naissance. Ces informations n’ont aucune place dans un contenu public de type formule, qui reste par nature un contenu marketing générique.
- Aucun champ de type texte libre associé à une formule ne doit pouvoir contenir un nom propre d’assuré.
- Les exemples chiffrés affichés restent fictifs et génériques, jamais tirés d’un dossier réel.
- Le simulateur de cotisation, qui manipule potentiellement des données de profil, reste un développement distinct avec ses propres exigences de sécurité.
En résumé
Comparer des formules de garanties de mutuelle en Query Loop reste parfaitement possible sans jamais s’approcher d’une donnée nominative, à condition de modéliser les formules comme un contenu strictement générique et de verrouiller les champs personnalisés autorisés à l’affichage. Le simulateur de cotisation individualisé, plus sensible, se traite séparément.
