Politique de confidentialité

Une distinction essentielle : calcul local et services du site

Viager Repère a été conçu pour que le visiteur puisse saisir une valeur de bien, un bouquet, une rente ou une hypothèse de durée dans son navigateur. Le moteur affiche ensuite un scénario indicatif et ses hypothèses. Le fonctionnement prévu ne transmet pas ces chiffres à un serveur pour produire une page personnelle, ne les ajoute pas à l'URL et ne crée pas de résultat indexable.

Cette promesse concerne les champs de calcul et doit être vérifiée dans la version publiée. Elle ne signifie pas qu'un site web ne reçoit jamais aucune donnée technique : l'hébergement, les journaux de sécurité, le consentement publicitaire ou un éventuel contact peuvent avoir un fonctionnement distinct. La Méthodologie explique ce qui est local dans les outils et ce qui relève des hypothèses éditoriales.

Ce que les outils ne demandent pas

Les formulaires de Viager Repère ne doivent demander aucun nom, adresse exacte, acte, pièce d'identité, donnée de santé ou justificatif de propriété. Pour tester un calcul, utilisez des données fictives ou arrondies et conservez vos documents dans votre environnement de confiance. Ne placez pas un nom de vendeur, une date de naissance complète ou l'adresse d'un logement dans un champ libre qui n'est pas nécessaire au scénario.

Les résultats, âges, montants et filtres générés restent dans la page générique. Le bouton de partage partage la page ou copie son lien, pas le contenu personnel d'un scénario. Une capture d'écran peut néanmoins contenir des chiffres que vous ne souhaitez pas diffuser : relisez-la avant de la transmettre dans un signalement, en suivant les consignes de Contact.

Données techniques : ce qui doit correspondre au déploiement

Un serveur peut traiter les informations nécessaires pour délivrer une page, détecter une erreur ou protéger le service. La présente architecture ne fournit pas le nom de l'hébergeur, les journaux activés, leur durée, les mesures de sécurité, les sous-traitants ni les éventuels transferts. Il serait trompeur de donner ici une durée ou une liste de prestataires inventée.

Si un formulaire est ajouté, il ne doit recueillir que les informations nécessaires à un signalement éditorial. Le site ne doit pas inviter à téléverser un acte, une pièce d'identité ou un document médical. La durée de conservation des messages, l'accès interne et la suppression doivent être arrêtés avant la mise en production.

Publicité AdSense et CMP

Le site.yaml prévoit une monétisation AdSense et une CMP, avec des espaces publicitaires dans le flux de lecture. La publicité ne doit pas interrompre l'action puis le résultat d'un outil. La CMP doit être alignée avec les services réellement actifs : catégories, finalités, fournisseurs, partenaires, durée des choix, refus et retrait du consentement.

Ne déduisez pas la liste des cookies d'une documentation générique. Avant publication, testez une première visite sans choix, un refus, une acceptation et un retrait depuis le panneau prévu. Notez les scripts qui se chargent dans chaque état, les noms de cookies ou identifiants effectivement observés, leur fournisseur et leur durée. La page Cookies doit reprendre cet inventaire daté, pas une liste de démonstration.

Le blueprint indique google_adsense comme fournisseur CMP prévu, mais cette configuration doit être comparée au service réellement installé. Si un outil d'audience, une vidéo, une carte ou un autre partenaire est ajouté, la présente page et la page Cookies devront être révisées. Aucune donnée publicitaire ne doit être décrite comme nécessaire au calcul local.

Contact, droits et informations à finaliser

L'identité du responsable, la voie de contact et les modalités de traitement d'une demande doivent apparaître dans les mentions légales et sur la page Contact. Comme ces informations ne sont pas encore fournies dans le projet, ne publiez pas une adresse ou un nom d'exemple. La version release devra indiquer le canal réellement surveillé et les informations vérifiées par l'éditeur.

Les formulations relatives aux droits des personnes, aux bases juridiques, aux durées et aux éventuelles demandes auprès d'une autorité doivent également être validées avec la configuration française réellement retenue. Cette page ne doit pas promettre une suppression instantanée, une réponse dans un délai non défini ou l'absence de tout traitement technique.

Exemple fictif : comparer deux visites

Dans un scénario fictif, Élodie ouvre le simulateur avec une valeur de bien inventée, un bouquet rond et deux horizons de durée. Le calcul s'effectue dans son navigateur ; elle ferme l'onglet et le site ne peut pas reconstituer son scénario à partir d'une URL. Elle revient le lendemain sur la page générique et saisit de nouvelles hypothèses.

Dans un second scénario, elle accepte un service publicitaire dans la CMP. Ce choix peut activer les traceurs prévus par le fournisseur après consentement, mais il ne change pas la formule locale du simulateur. Pour savoir ce qui s'est réellement produit, il faut vérifier le panneau et les scripts de la version publiée ; l'exemple ne constitue pas un inventaire technique.

Vérifications avant une mise en ligne

Avant de publier, comparez :

• le comportement des champs et résultats avec la promesse de calcul local ;
• l'absence de paramètres de scénario dans les URL, le partage et les pages indexables ;
• la configuration du serveur, des logs et du formulaire de contact ;
• la CMP en première visite, en refus, en acceptation et après retrait ;
• les scripts AdSense, leur position dans le parcours et les fournisseurs affichés ;
• les identités, coordonnées, durées et canaux de demande avec les mentions légales.

La page Cookies détaille les traceurs à partir de la configuration réelle. La page À propos précise le rôle éditorial du site. Viager Repère vise une information claire et sobre ; il ne prétend pas remplacer la vérification juridique et technique nécessaire avant publication.