Journal des modifications

Correction, le jour même : un oracle était pénalisé pour une activité qu'il n'a pas

4 août 2026 — Les projets dont l'activité économique ne se mesure pas en TVL — oracles, ponts, blockchains — retrouvent la note fondamentale qu'ils méritent. Sur Chainlink, cette note passe de 50 à 80 (elle valait 72 avant l'erreur). Aucun autre type de projet n'est concerné.

Les deux entrées ci-dessous décrivent des changements publiés ce matin. En vérifiant leurs premiers effets sur des analyses réelles, nous avons trouvé trois défauts dans notre propre correctif. Nous les corrigeons le jour même et nous les écrivons ici, parce qu'ils ont brièvement modifié des notes affichées.

Le plus visible concerne la nouvelle note fondamentale, désormais fondée sur un inventaire de ce qui est vérifiable : le code, l'activité économique et la structure de l'offre. Nous comptions ces trois éléments sur trois — sans voir qu'ils ne s'appliquent pas tous à tous les projets. Un oracle comme Chainlink ne gère pas de fonds déposés : il n'a pas d'activité économique au sens où on la mesure pour un protocole de finance décentralisée. Nous comptions donc cet élément comme MANQUANT alors qu'il est SANS OBJET, et sa note fondamentale est tombée de 72 à 50.

C'est exactement l'erreur que nous disions vouloir éviter, commise par le mécanisme censé l'éviter : confondre « rien à montrer » et « rien à mesurer ici ». Un élément sans objet sort maintenant du décompte au lieu de compter pour un échec. Un oracle qui remplit ses deux critères applicables n'est plus pénalisé pour le troisième, qui ne le concerne pas. Sur Chainlink, la note fondamentale passe de 50 à 80 — au-dessus des 72 qu'elle valait avant l'erreur, parce que l'ancrage vaut aussi dans l'autre sens : un projet qui peut tout prouver obtient désormais mieux qu'à l'estime.

Nous devons ici une précision sur un chiffre que nous avons nous-mêmes mal écrit dans la première version de cette page. Nous y annoncions Chainlink « remonté à 67 », en mélangeant deux choses : 67 est sa note GLOBALE, quand 80 est sa note fondamentale. Et sa note globale n'est pas revenue à 68 par hasard : l'écart d'un point ne vient pas de notre correctif mais du marché — sa note technique est passée de 52 à 40 et sa note de marché de 58 à 52 sur la même semaine.

Une deuxième correction porte sur la première version de ce correctif, publiée quelques heures plus tôt. Nous plafonnions la note dès qu'un critère était sans objet, en pensant qu'une base plus étroite justifie moins de confiance. C'était réintroduire la pénalité par la porte d'à côté : un oracle serait repassé de 80 à 65. Le bon critère n'est pas l'étroitesse mais l'ignorance. Un élément qui n'existe pas chez un projet ne nous fait rien ignorer ; un élément qui existe mais que nous n'avons pas pu lire, si. Seul le second plafonne désormais la note, et le nombre de critères évalués comme applicables est indiqué.

Ce plafond est appliqué par notre code, après la réponse du modèle, et non demandé au modèle. Nous avons déjà appris la différence : un plancher exigé en langage naturel avait été enfreint le 19 juillet, ce qui nous avait conduits à calculer la note globale nous-mêmes. Une consigne s'observe la plupart du temps ; une règle de calcul s'applique toujours.

Les deux autres défauts n'ont pas eu d'effet visible mais rendaient une partie du travail inopérante : nous lisions les données de fonds déposés à un emplacement qui n'existe pas, et notre reconnaissance des plateformes d'échange confondait les plateformes centralisées avec les protocoles décentralisés comme Uniswap. Les deux sont corrigés et couverts par des tests écrits, cette fois, à partir des données réellement renvoyées par nos sources.

Nous en tirons une conséquence sur nos propres mesures. Ces corrections font quatre changements de méthode en dix jours, et une comparaison n'a de sens qu'entre deux états stables. Nous avons donc figé aujourd'hui l'état complet de toutes les notes, projet par projet, et nous nous imposons de ne plus toucher à la méthode avant d'avoir mesuré cette version-ci sur plusieurs jours.

La note de sécurité tient compte de la nature du projet

4 août 2026 — Les jetons émis par une plateforme d'échange (LEO, WBT…), les stablecoins et les protocoles gouvernés voient cette note remonter nettement. Les memecoins et les projets non identifiés ne bougent pas. Aucun signal d'alerte réel n'est atténué.

Cette note se déduisait des seuls signaux techniques lus dans le contrat, sans savoir à quoi ce contrat appartenait. Or un jeton émis par une plateforme d'échange, un stablecoin régulé, un réseau de seconde couche et un memecoin anonyme peuvent lever exactement les mêmes signaux — la possibilité de créer des jetons, de suspendre les transferts, de mettre le contrat à jour — pour des risques réels sans commune mesure. Quand Bitfinex garde la main sur LEO, c'est le fonctionnement annoncé de son jeton, pas un piège dissimulé.

L'ampleur du défaut nous a surpris. Sur nos 264 dernières analyses, les tokens dont le contrat a réellement été vérifié obtenaient 48,5 de moyenne sur cette dimension, contre 84,6 pour ceux dont le contrat ne peut pas être audité et dont nous estimons la maturité. Autrement dit : faire vérifier son contrat était devenu une pénalité de 36 points. LEO, treizième capitalisation mondiale, sortait à 8 sur 100 — sous des tokens classés au-delà du trois millième rang.

Désormais, la nature du projet est déterminée avant la lecture des signaux, et les pouvoirs qui sont normaux pour cette nature ne comptent plus comme des anomalies de contrat. Ils ne disparaissent pas pour autant : ils sont requalifiés en risque de contrepartie — votre dépendance à l'émetteur — et doivent être énoncés dans les risques du rapport. Un pouvoir attendu reste un pouvoir.

Deux garde-fous encadrent ce changement, parce que sans eux « le contexte » deviendrait une excuse universelle. D'abord, six signaux ne sont atténués par aucun contexte, quelle que soit la taille ou la nature du projet : blocage de la revente, propriétaire dissimulé, taxes modifiables, taxes ciblables, revente totale impossible, et pouvoir de réécrire le solde d'un détenteur. Ce sont des mécanismes qui retournent le contrat contre celui qui détient le jeton, pas des pouvoirs d'administration. Ensuite, les contextes indulgents exigent une capitalisation installée : un token classé au-delà du deux-centième rang qui se déclare « jeton d'échange » n'obtient rien.

Nous devons signaler une erreur que nous avons commise dans ce même changement, et corrigée le jour même. Notre première version reconnaissait un jeton de plateforme d'échange à la simple présence du mot « exchange » dans les catégories du projet. En vérifiant sur des données réelles après la mise en ligne, nous avons découvert qu'Uniswap et Curve — des protocoles décentralisés, sans émetteur — portent eux aussi cette étiquette. Ils auraient donc bénéficié d'une indulgence réservée aux émetteurs identifiés, ce qui est précisément la faille que ce travail devait fermer. La correction est en ligne et les tests utilisent maintenant les catégories réellement renvoyées par notre source, plus celles que nous supposions.

Ce qui reste imparfait, et que nous préférons écrire : cette note se compare, dans le score global, à une note de maturité estimée pour les actifs qui n'ont pas de contrat. Ce sont deux échelles différentes agrégées dans un même chiffre. Nous n'avons pas encore de bonne réponse à ce problème.

Deux dimensions mesuraient autre chose que ce que leur nom annonce

4 août 2026 — La note de liquidité remonte fortement pour les tokens qui s'échangent surtout sur des plateformes centralisées. La note fondamentale s'écarte davantage entre les projets qui ont du code et des revenus et ceux qui n'en ont pas : elle baisse pour les memecoins, elle monte pour les projets qui peuvent le prouver.

Un lecteur nous a signalé que nos classements n'étaient pas cohérents : un jeton de plateforme d'échange noté 31, un memecoin à 54. Nous avons repris nos 264 dernières analyses pour comprendre, et il avait raison — mais pas pour la raison qu'il pensait, ni pour celle que nous pensions.

Premier défaut, sur la liquidité. Cette note ne regardait que les échanges décentralisés. Un même token pouvait donc afficher, le même jour, 58 sur 100 en « données de marché » — qui compte tous les volumes — et 8 sur 100 en « liquidité ». LEO s'échange sur Bitfinex, pas sur Uniswap : nous lui reprochions de ne pas être là où il n'a jamais eu à être. Sur 44 classements incohérents relevés, 24 venaient de deux tokens seulement, tous deux des jetons de plateforme d'échange. La note croise désormais le volume total, toutes places confondues, et le taux de rotation ; la profondeur décentralisée n'est plus utilisée quand elle n'est pas représentative.

Second défaut, sur la note fondamentale. Elle ne séparait pas les projets. Les memecoins obtenaient 33,6 de moyenne, les blockchains et protocoles 47,8 — avec un large chevauchement entre les deux. Le cas qui résume tout : deux points d'écart entre un memecoin sans aucun code public et une blockchain avec son écosystème. Sur les petites capitalisations, cette note ne variait que de 4,9 points d'un projet à l'autre, alors qu'elle porte le poids le plus lourd du calcul. Elle est maintenant ancrée sur un inventaire de ce qui est vérifiable — code, activité économique, structure de l'offre — au lieu d'être laissée à l'appréciation du modèle.

Nous maintenons une distinction à laquelle nous tenons : l'absence de preuve n'est pas une preuve d'absence. Un memecoin qui ne publie pas de code n'a rien abandonné, il n'a jamais eu de code à publier. L'inventaire distingue donc « rien à montrer » de « rien n'a pu être lu », et une donnée que nous n'avons pas su lire ne fait jamais baisser une note — elle réduit notre certitude, ce qui est écrit dans les risques.

Ce que nous n'avons PAS fait, et pourquoi. Notre première intention était de rééquilibrer le poids des six dimensions. Nous avons vérifié qu'aucune pondération ne pouvait corriger le cas signalé : le memecoin battait la blockchain sur cinq dimensions sur six, et 300 000 combinaisons de poids testées n'en ont trouvé aucune qui les remette dans l'ordre. Le défaut était dans les notes elles-mêmes, pas dans leur assemblage.

Nous avons aussi écarté un réglage qui améliorait pourtant tous nos indicateurs. Notre méthode de recherche définissait le succès comme « la note doit suivre la taille du projet » — ce qui revenait à demander au score de confirmer ce qu'il est censé évaluer. Le réglage obtenu rendait effectivement le classement plus lisse, en rapprochant simplement la note de la capitalisation. Nous l'avons rejeté. Un classement mieux rangé n'est pas un classement plus juste.

Comme le 1er août, nous avons publié dans notre dépôt de code, avant la mise en ligne, les résultats chiffrés que nous attendons et les conditions qui nous feraient annuler ces changements. La principale : si les incohérences de classement diminuent mais que la note se met à coller davantage à la capitalisation, nous reviendrons en arrière — ce serait le défaut que nous venons d'écarter, revenu par une autre porte.

Une donnée manquante s'affiche « non mesuré » au lieu d'une note inventée

1 août 2026 — Sur les tokens concernés, une ou plusieurs dimensions n'affichent plus de note mais la mention « n.m. ». La note globale est recalculée sur les seules dimensions réellement mesurées : elle monte quand les autres dimensions sont au-dessus de la moyenne, elle descend quand elles sont en dessous. Les tokens dont toutes les données sont disponibles ne bougent pas.

Jusqu'à aujourd'hui, quand les données d'une dimension étaient absentes, le modèle avait pour consigne de lui donner « environ 50 » — une note moyenne, présentée exactement comme les autres. Rien ne distinguait à l'écran un 50 mesuré d'un 50 faute de mieux.

Nous avons mesuré l'ampleur du problème sur nos 184 dernières analyses détaillées avant d'y toucher : la dimension « On-chain » valait exactement 50 dans 32,6 % des cas, soit près d'une analyse sur trois. Les autres dimensions étaient très peu concernées — « Technique » 9,8 %, « Sécurité » 4,9 %, les trois restantes autour de 1 %. Ce n'était donc pas un défaut général de la notation, mais un trou de données logé dans une case précise.

Désormais, une dimension sans données est déclarée absente plutôt que notée. Elle s'affiche « n.m. » avec une barre neutre, et elle sort du calcul de la note globale : les autres dimensions se repartagent son poids. Une donnée manquante ne pénalise donc pas le token — elle ne le flatte pas non plus.

Le sens de l'effet mérite une précision, parce que nous avons annoncé l'inverse le 26 juillet. Nous écrivions alors que ce changement « fera redescendre une partie de ces notes ». C'est vrai pour une partie d'entre elles, mais pas en moyenne : les valeurs « On-chain » réellement mesurées tournent autour de 48,8, sous la moyenne générale de 54,3. Retirer une dimension qui tire vers le bas remonte donc légèrement la note des tokens concernés, et nous nous attendons à ce que la moyenne générale monte de 54,3 à environ 55-58 plutôt qu'à baisser. Nous avions raison sur le mécanisme et imprécis sur sa direction ; nous l'écrivons ici plutôt que de laisser la phrase de juillet vivre sa vie.

Ce que nous ne savons pas encore : si cela rend les analyses plus JUSTES. Une note mieux répartie n'est pas une note plus exacte. La seule vérification qui compte est de savoir si les tokens bien notés continuent de mieux se comporter ensuite que les mal notés — aujourd'hui l'écart mesuré est de 4,2 points de performance à sept jours. Nous avons écrit avant le déploiement, et publié dans notre dépôt de code, les cinq résultats chiffrés que nous attendons ainsi que la condition qui nous ferait annuler ce changement : si cet écart de performance descend sous 2 points, nous reviendrons en arrière, même si tous les autres indicateurs s'améliorent.

Note de mesure, pour qui voudra relire nos chiffres : la mise en ligne a renouvelé le cache d'analyse. Les volumes des premières vingt-quatre heures peuvent donc paraître anormalement élevés, parce que des tokens déjà analysés sont recalculés. Cela n'a aucun effet attendu sur la répartition des notes, mais nous le signalons pour que personne n'y lise une hausse de fréquentation.

Nouveau module d'analyse graphique, et une EMA 200 plus juste

28 juillet 2026 — La valeur affichée de l'EMA 200 change sur le panneau technique — environ 2 % d'écart mesuré sur Bitcoin en journalier. Aucun signal ne change de sens, la synthèse Achat/Vente est inchangée. Un nouveau score technique apparaît, distinct de la note globale sur 100.

Le module « Chart Intelligence » ajoute un graphique en chandeliers complet et un score technique sur cinq axes : tendance, momentum, structure, volume et risque maîtrisé. Ce score est calculé, pas rédigé par l'IA : les mêmes bougies donnent toujours exactement le même résultat, ce qui permet de le comparer dans le temps.

Ce score technique ne remplace pas et ne modifie pas la note globale sur 100 du rapport d'analyse. Ce sont deux mesures distinctes : l'une ne regarde que le graphique, l'autre croise la technique, l'on-chain, les fondamentaux et le contexte de marché. Un token peut afficher un score technique bas et une note globale élevée, ou l'inverse.

Effet mesuré avant publication sur les valeurs déjà affichées : les indicateurs du panneau technique sont désormais calculés sur 500 bougies d'historique au lieu de 300. Cela ne change rien aux moyennes simples ni aux oscillateurs, mais cela corrige les moyennes exponentielles longues. Une EMA 200 calculée sur 300 bougies n'a que 100 étapes de lissage après son amorçage : elle n'a pas convergé, et surestimait la valeur. Sur Bitcoin en journalier, l'écart mesuré est de 2,01 % sur l'EMA 200 et de 0,07 % sur l'EMA 100. La nouvelle valeur est la plus exacte des deux.

Nous le signalons bien que l'effet soit favorable et qu'aucun signal ne bascule : une valeur affichée qui bouge doit être annoncée, sans quoi le journal ne servirait qu'à commenter les mauvaises nouvelles.

Le module enregistre par ailleurs son verdict daté à chaque consultation, au plus une fois toutes les six heures par token. L'objectif est de pouvoir confronter, dans plusieurs semaines, ce que le moteur annonçait à ce que le prix a réellement fait. Un outil d'analyse qui n'accepte pas d'être relu sur ses positions passées ne vaut pas grand-chose.

La note de sécurité des tokens à contrat repose désormais sur des vérifications réelles

26 juillet 2026 — Les tokens à contrat voient cette note évoluer, à la hausse comme à la baisse. Les actifs natifs (Bitcoin, Ethereum, Solana…) sont inchangés.

Jusqu'ici, la dimension de maturité était la seule note du rapport à ne reposer sur aucune donnée technique : le modèle évaluait un projet à partir de son ancienneté et de sa notoriété. Les vérifications de contrat existaient sur le site, mais uniquement dans le détecteur d'arnaques.

Elles alimentent maintenant aussi l'analyse : blocage de la revente, taxes cachées, code non publié, fonction de création de tokens, propriété du contrat non renoncée, part de liquidité verrouillée, part détenue par le créateur. Quand ces vérifications aboutissent, la dimension prend le nom « Sécurité du contrat » et la taille du projet n'entre plus dans la note — un petit projet au contrat irréprochable peut désormais mieux noter qu'une grande capitalisation au contrat opaque.

Le nom est volontairement qualifié. Cette note porte sur le contrat, et sur lui seul : elle ne dit pas si le token est un bon investissement, ni si son offre est concentrée entre quelques mains. La concentration des détenteurs est mesurée, mais elle compte dans la dimension « On-chain » — l'inscrire aussi ici la ferait peser deux fois sur la note globale. Un token peut donc afficher une sécurité de contrat élevée et une note on-chain basse : ce sont deux mesures distinctes, et il faut lire les deux.

Pour les actifs natifs, il n'y a pas de contrat à auditer : la dimension reste « Maturité » et son calcul est strictement inchangé. Une vérification impossible est signalée comme telle, jamais remplacée par une note moyenne.

Effet mesuré avant publication, sur des tokens réels : les projets dont le contrat est propre gagnent environ 7 points de note globale, ceux qui portent des signaux d'alerte environ 2. Les petites capitalisations au contrat sain montent donc sensiblement. Une seconde correction, déjà identifiée, jouera en sens inverse sur cette même population : aujourd'hui, une dimension sans données compte pour 50 — une valeur moyenne inventée — et la remplacer par un recalcul sur les seules dimensions réellement mesurées fera redescendre une partie de ces notes. Nous livrons les deux séparément pour que chaque effet reste lisible, et nous l'annonçons ici pour que la seconde ne passe pas pour un rattrapage de la première.

La dimension « Sécurité » est renommée « Maturité »

26 juillet 2026 — Aucun effet sur les scores : seul le libellé change.

En mesurant nos propres analyses passées, nous avons constaté que cette dimension était très largement déterminée par la taille du projet plutôt que par une vérification de sa sûreté. La raison est simple : aucune donnée de sécurité de contrat n'alimentait cette note. Le modèle évaluait donc l'ancienneté et la notoriété — c'est-à-dire la maturité.

Le libellé promettait davantage que ce que la note mesurait, et il pénalisait mécaniquement les petits projets, y compris les projets propres. Nous l'avons donc corrigé pour dire ce qui est réellement évalué. Le chiffre, lui, n'a pas bougé.

Les vérifications de sécurité réelles (honeypot, taxes cachées, liquidité verrouillée, concentration des détenteurs) restent assurées par le détecteur d'arnaques, qui interroge de vraies bases de sécurité. Nous travaillons à les intégrer aussi à l'analyse ; ce jour-là, la dimension reprendra le nom « Sécurité » pour les tokens dont le contrat aura réellement été vérifié.