Un profil utile montre sources, déductions et commandes

Séparer données fournies, observées et déduites

Les données fournies comprennent champs de compte, intérêts choisis et contenu saisi. Les données observées couvrent l’usage déclaré des fonctions, clics, horaires et historique d’interaction. Les données déduites sont des préférences, habitudes ou étiquettes calculées. Gardez à part l’état du système, comme l’offre du compte ou une fonction active : il modifie l’expérience sans constituer une conclusion sur la personne. Cette séparation empêche une supposition de ressembler à une déclaration explicite. L’ICO décrit également le profilage comme une analyse de plusieurs sources servant à classer ou prévoir certains aspects.

Exiger sept champs par élément

Chaque ligne doit afficher valeur, type, origine, date de création ou mise à jour, finalité déclarée, effet produit et commande disponible. « Aime voyager » ne suffit pas sans préciser choix direct, conversations répétées ou service connecté. Un degré de confiance peut aider s’il a une signification, mais ne doit pas cacher l’origine derrière un score décoratif. Indiquez aussi la portée : compte entier, appareil, personnage ou fonction. Un champ absent devient une question précise ; il ne prouve pas que le trajet correspondant n’existe pas.

Relier chaque élément à un effet concret

Un élément mérite d’être vu parce qu’il change quelque chose. Reliez-le à la mémoire, au classement, aux suggestions, notifications, audience, publicité ou décision de fonction. My Ad Center constitue un exemple actuel : certaines catégories sont visibles et des informations de compte, activité ou zone peuvent être contrôlées pour la personnalisation publicitaire. Le réglage Android de données partagées montre qu’un index local peut avoir ses propres sources alors que l’activité du compte reste séparée. Une app de compagnie ne devrait donc pas présenter un interrupteur comme la commande de systèmes sans rapport.

Distinguer correction, suppression, arrêt et remise à zéro

Corriger une préférence erronée doit préserver les choix sans rapport. Supprimer une conversation source devrait préciser si l’étiquette dérivée est recalculée. Arrêter la personnalisation future devrait dire si l’ancien profil reste conservé. Une remise à zéro doit lister ce qu’elle efface, garde et reconstruira. Des procédures officielles d’accès ou correction peuvent exister selon la région, sans devenir une conclusion universelle. Le test produit reste simple : une personne ordinaire comprend-elle la conséquence étroite de chaque action, sans deviner quelle autre mémoire ou copie sera touchée ?

Tester l’actualisation par un changement anodin

Modifiez une préférence explicite et anodine, notez l’heure, puis observez l’élément et la fonction qui changent. Annulez-la et vérifiez si le profil s’actualise, change d’état ou exige une réinitialisation. Une seule variation est plus lisible qu’une série d’activités artificielles. Notez compte, appareil, fonction et version. Si la déduction demeure, cherchez une autre source avant de conclure à une panne. Une bonne interface fournit assez de provenance pour distinguer délai, plusieurs sources et commande réellement sans effet.

Revoir le profil après chaque nouvelle fonction

Conservez un reçu après inscription et après ajout de mémoire, voix, image, connexion externe, communauté ou amélioration de modèle. Pour chaque surface, inscrivez les nouveaux champs fournis, observés ou déduits, leur public, leur effet et leurs commandes. Comparez profil, export et explication de confidentialité, car aucun écran ne couvre nécessairement tout. Le registre en sept champs apporte la traçabilité : « l’app me connaît » devient une série d’éléments que l’on peut examiner, contester ou garder volontairement, avec une prochaine date de vérification.

Continuer sur ce thème