Méthodologie — à lire avant de citer un chiffre

1. Ce qu’est ce site

En France, la vie privée n’est pas un luxe, c’est un droit — on l’apprend à l’école, on le défend devant la CNIL, on s’en méfie quand une entreprise américaine met une caméra sur votre nez. Le problème des lunettes connectées n’est pas ce qu’elles savent faire, c’est qu’on ne sait pas ce qu’elles font en ce moment : qui est filmé, où part l’image, combien de temps elle est gardée. Ce site n’est donc ni un banc d’essai ni un guide d’achat. C’est un registre, tenu comme un livre de comptes : pour chaque modèle, ce qui est collecté, ce qui est activé par défaut, où vont les données, si l’on peut les effacer — ligne par ligne, preuve à l’appui. Les propos de chaque article sont consignés tels quels, sans enjoliver. Le suivi des sorties vit sur le site frère aiglassesdata.com, les retours d’expérience réels dans l’UX Ledger (uxledger.com) ; ici, on se contente de les relier.

2. Sources

Pages produits et annonces des fabricants (Meta, Snap, Samsung/Google), rapports des régulateurs (HmbBfDI de Hambourg, EDPB) et couverture de lancement. Chaque fiche, chaque événement, chaque ligne de caractéristiques porte un lien source. Quand une affirmation repose sur une couverture secondaire plutôt que sur une page fabricant, la note le dit.

3. « Non communiqué » est une vraie valeur

Si un fabricant n’a pas publié un chiffre, ou s’il n’a pas été vérifié contre une source citable, la case dit « Non communiqué ». Aucun chiffre de ce site n’est estimé, interpolé ou emprunté à un produit voisin. Les moyennes ne portent que sur les valeurs non nulles, et le nombre de nulls est indiqué à côté.

4. Règle de la carte de chaleur de la vie privée

Les codes sont dérivés du texte des fiches par des règles de mots-clés — « Non communiqué » → 0 ; « activé par défaut » → 3 ; « pas d’enregistrement continu » → 1 ; LED/témoin présent → 2 ; « non vérifié indépendamment » → 1 ; « traitement sur l’appareil » → 1 ; « serveurs Meta » → 2. Le texte intégral des fiches figure juste sous la carte, donc chaque code peut être vérifié contre sa phrase. Lisez la carte comme une carte, pas comme une note : une case rouge signifie « activé par défaut — vérifiez la fiche », pas « mauvais produit ».

5. Tendances de recherche

Indices Google Trends (0–100), pas des nombres de recherches. Une moyenne sur 24 heures est un instantané bruyant d’un seul jour ; le chiffre hebdomadaire est la lecture stable. Les sources sont deux captures d’écran (Canada et monde, 5 novembre 2026).

6. Articles et analyse

La couverture est collectée sur Hacker News, Bing News, les blogs tech, YouTube et Reddit (via Bing News). Google News RSS renvoie 503 depuis la sortie du Worker, donc Bing News est l’entonnoir d’actualités ; le RSS direct de Reddit renvoie 403 depuis la même sortie. Chaque article est analysé une fois par Workers AI (Llama 3.1 8B, @cf/meta/llama-3.1-8b-instruct-fp8) : un résumé de 1 à 3 paragraphes plus des champs structurés. L’analyse repose sur le titre, l’extrait et le corps récupérable ; quand le texte intégral est inaccessible, c’est marqué « snippet ». Tout ce qui est indéterminable reste null — rien n’est inventé. Un article n’entre que si son titre nomme un modèle suivi (filtre de titre : Display d’abord, puis Ray-Ban, Oakley, Galaxy Glasses, Specs). Le filtre est imparfait : un raté connu est un article de 9to5Google sur le téléphone Motorola Signature 27 classé sous snap-specs ; son chiffre de batterie est exclu de la ligne Snap avec une note, et il reste dans le registre brut pour audit.

7. La règle de notation — ce que les indices sont, et ne sont pas

En France, on sait faire la différence entre une critique et l’œuvre elle-même : qu’un critique encense un film ne fait pas du film un chef-d’œuvre, et qu’il le descende n’en fait pas un navet. Les indices de ce site fonctionnent exactement ainsi. L’indice de sentiment positif (0–100), l’indice de recommandation (0–100) et le verdict de l’auteur (buy / wait / skip / mixed, avec ses propres mots cités) mesurent l’article et son auteur — à quel point ce texte est positif, à quel point il penche vers la recommandation, et ce que son auteur a conclu. Ils ne mesurent pas le produit, et ils ne sont pas la note de ce site sur un produit. Ce site ne note jamais les produits : pas de score maison, pas de classement, pas de « meilleur choix ». Voilà la ligne : les indices qui décrivent la couverture sont conservés et publiés avec leur méthode ; tout chiffre qui se présenterait comme notre jugement sur un produit n’est pas publié. Quand un classement apparaît sur le site, c’est celui de la source elle-même (par exemple un indice Google Trends), et la page le dit.

8. Les trois registres

Les trois sont générés directement à partir des analyses par article — pas depuis experience_records, qui compte 0 ligne (l’expérience réelle vit dans l’UX Ledger).

• Annoncé contre constaté (/api/ledger/claims) : chaque key_claim portant une measured_value, avec son article source. La measured_value est le chiffre tel qu’écrit dans cet article, pas une mesure de laboratoire indépendante. Les lignes marquées « tested » viennent d’articles de prise en main / de propriétaires ou d’articles indiquant une durée d’usage ; les autres reprennent un chiffre fabricant ou d’annonce. La comparaison de batterie sur /metrics/battery/ met l’annonce fabricant du tableau de caractéristiques à côté de ces valeurs d’articles.
• Scores (/api/ledger/scores) : distributions des indices de sentiment et de recommandation (tranches 0–19 / 20–39 / 40–59 / 60–79 / 80–100), moyennes simples sur les valeurs non nulles, et comptes de verdicts par modèle et pour tout le site. Les articles sans verdict sont comptés comme « sans verdict », on ne leur en attribue jamais un.
• Modes de défaillance (/api/ledger/failures) : les issues[] groupés par la formulation exacte du problème au sein de chaque modèle. Les quasi-doublons sont conservés séparément et montrés tels quels, jamais fusionnés. Les comptes sont des mentions dans les articles analysés.

9. Contrôles de preuve

Deux contrôles déterministes tournent sur chaque analyse avant stockage, indépendamment de la formulation du modèle. D’abord, compared_products ne garde que les noms qui apparaissent mot pour mot dans le texte de preuve (titre + extrait + corps récupéré) ; compares_with est recalculé à partir de la liste survivante, jamais cru sur parole. Ensuite, un verdict_quote n’est conservé que si son texte normalisé apparaît dans le texte de preuve normalisé ; sinon il est stocké comme null. Ces contrôles ne concernent que les nouvelles analyses ; les anciennes, antérieures à leur mise en place, peuvent encore porter des éléments inventés et sont nettoyées à la ré-analyse.

10. Données live / instantané

Les chiffres viennent de l’API (D1) quand elle est joignable. Sinon, la page affiche l’instantané figé généré à partir de la même base au moment du build, et le dit dans l’en-tête. L’instantané n’est jamais présenté comme du live. Les graphiques sont rendus en direct à partir des données de l’API ou de l’instantané (ECharts). Pas de captures statiques. Le tableau de données brutes se trouve sous chaque graphique.

11. Journal des corrections

• 2026-11-07 — Batterie du Meta Ray-Ban Display. Avant : « Up to 6 hours (per buying guide; Meta figure not yet confirmed) ». Après : « Up to 6 hours per charge (mixed use); charging case adds up to 24 hours; Meta Neural Band up to 18 hours ». Source : Meta Help Center, https://www.meta.com/help/ai-glasses/1116302600085081/. L’ancienne formulation « with case 30 hours total » est remplacée et n’est plus utilisée.
• 2026-11-07 — Microphone de l’Oakley Meta HSTN. Avant : non listé (sources en conflit). Après : « 5-mic array (2 per arm + 1 near nose pad) ». Sources : Abt et Android Central. La formulation « dual beam-forming » n’est pas utilisée. Le tableau des caractéristiques gagne une colonne microphone ; le Ray-Ban Meta Gen 3 affiche « 6-mic array » (selon la fiche de confidentialité de ce site) et les autres modèles « Non communiqué ».

12. Limites

• L’analyse est une extraction par IA à partir de titres, d’extraits et de corps partiels ; la plupart des analyses reposent sur des snippets quand le texte intégral n’a pu être récupéré. Chaque chiffre extrait doit être lu comme « tel qu’écrit dans l’article », pas comme un fait vérifié.
• Le filtre de titre rate et classe mal occasionnellement (voir §6, cas Motorola). Les articles mal classés sont exclus de la comparaison concernée avec une note, jamais effacés silencieusement.
• experience_records compte 0 ligne sur ce site par conception ; l’« annoncé contre constaté » ici est dérivé de la couverture, pas mesuré en laboratoire. Une mesure indépendante exigerait les relevés d’expérience de l’UX Ledger.
• L’intérêt de recherche n’est que deux captures Google Trends (5 novembre 2026), pas une série continue.
• Les graphiques sont rendus dans le navigateur ; si la bibliothèque de graphiques ne se charge pas, le tableau de données dessous porte les mêmes chiffres.

13. Passé, présent, futur — trois segments complets, le passé est la référence

Les données de ce site se déclinent en trois segments, et il en faut les trois : le passé (ce qui est déjà arrivé), le présent (la valeur actuelle) et le futur (chaque changement à venir). On ne part jamais d’un zéro actuel en attendant que le futur change : le passé et le présent sont la référence à partir de laquelle un changement a un sens. Sans référence, le changement ne veut rien dire. Trois règles : premièrement, chaque dimension fait l’objet d’un remplissage rétrospectif — historique des prix, des caractéristiques et des lancements, des critiques et des comptes rendus d’expérience, des mentions et des événements ; tout ce qui peut être tiré d’une source publique doit l’être. Deuxièmement, les articles déjà collectés sont eux-mêmes de l’histoire : les valeurs annoncées, les valeurs constatées, les problèmes et les conclusions des 233 articles analysés de ce site sont déjà structurés et reversés dans le registre historique (voir /history/) — on n’attend pas les futurs articles pour commencer. Troisièmement, zéro n’est un point de départ acceptable que s’il n’existe vraiment aucun historique, ni dans les sources publiques ni dans les articles collectés, et cela doit être écrit sur cette page. Tout changement futur se mesure par rapport à la référence ainsi reconstituée : l’archivage et la comparaison phrase par phrase partent de cette référence. État actuel : les mesures indépendantes en laboratoire (experience_records) restent à 0 ligne — il n’existe pas encore, dans les sources publiques, de relevé structuré indépendant selon nos critères ; les valeurs mesurées en prise en main citées dans la couverture sont dans le registre historique (marquées « tested »), tenues séparées des mesures indépendantes, sans jamais les confondre.