Qu’est-ce que le DYOR ?

DYOR est l’abréviation de « do your own research », c’est-à-dire faire ses propres recherches. Dans le contexte des actifs crypto, cela signifie ne pas prendre d’emblée la promotion, des publications ou les conclusions d’autrui pour des faits, mais chercher soi-même les matériaux d’origine, croiser les preuves, et séparer ce qui est déjà confirmé de ce qui reste inconnu.

Le DYOR n’est pas une certification uniforme, ni une méthode pour rendre un projet fiable ou pour éviter des pertes. Il s’apparente plutôt à un processus de vérification de l’information : établir d’abord ce qu’une affirmation prétend précisément, puis apprécier quels matériaux peuvent l’étayer, si ces matériaux s’appliquent encore à la version actuelle, et quelles conclusions ne sont que des conjectures. Un résultat de recherche n’est pas non plus une simple étiquette « on peut acheter » ou « on ne peut pas acheter ».

La recherche part d’une affirmation vérifiable

« Ce projet est bon », « la communauté est forte » ou « la technologie est en avance » sont tous difficiles à vérifier directement. Une affirmation plus précise indique où chercher des preuves, par exemple :

• si une adresse donnée est bien le contrat de token que le projet emploie actuellement ;
• si l’offre totale de tokens peut augmenter, et qui détient le droit d’en émettre davantage ;
• si le contrat peut suspendre, mettre à niveau ou geler certaines opérations ;
• de quels marchés et de quelle période provient le volume d’échanges affiché sur une page ;
• quelle version du code un rapport d’audit donné a examinée ;
• si un partenariat, une intégration ou une fonction produit a été confirmé par les parties concernées ;
• si une fonction annoncée comme en service trouve un enregistrement correspondant dans le code, l’interface ou l’activité en chaîne.

Écrire l’affirmation d’abord évite aussi de mélanger des questions différentes. Que le code source d’un contrat ait été publié ne signifie pas que le code soit exempt de failles ; que l’identité d’une équipe ait été publiée ne signifie pas que le produit puisse tenir tous ses plans ; et que des personnes négocient en chaîne ne signifie pas que ces transactions viennent d’utilisateurs indépendants ou représentent une demande durable.

Des affirmations différentes exigent des preuves de nature différente

Aucune source unique ne peut répondre à toutes les questions. Les preuves couramment employées en recherche se répartissent en plusieurs catégories :

Une « source officielle » convient pour confirmer ce qu’un projet déclare de lui-même, mais cela reste un matériau publié par le projet. Les sources indépendantes peuvent offrir un autre point de vue, et peuvent aussi citer des informations erronées ou périmées. Une conclusion fiable vient généralement de plusieurs sources corroborant la même affirmation précise, et non du fait d’étiqueter un site « digne de confiance » puis d’accepter l’ensemble de son contenu.

Vérifie d’abord le réseau et l’adresse du contrat, ensuite le nom et l’icône

Les tokens en chaîne peuvent porter le même nom et employer la même icône et le même code de cotation. Pour identifier un actif numérique, le nom du réseau et l’adresse du contrat sont généralement plus distinctifs qu’un nom d’affichage ; pour un token non fongible, le numéro de token peut devoir être vérifié également.

Le site ou la documentation d’un projet peuvent fournir une adresse de contrat, et un explorateur de blocs peut afficher la transaction de déploiement de cette adresse, ses soldes, les transferts de tokens et les appels de contrat. La présentation des explorateurs de blocs par Ethereum.org énumère des données en chaîne courantes telles que blocs, transactions, comptes, contrats et tokens.

Une adresse doit encore être croisée. Un site contrefait peut tout autant afficher un contrat qui existe réellement, et des résultats de recherche ou des publications sur les réseaux sociaux peuvent renvoyer vers un faux token de même nom. Ce qu’une mention « vérifié » signifie précisément sur une page dépend des règles de vérification du service concerné ; on ne peut pas conclure d’après une seule icône ou étiquette.

Un enregistrement en chaîne peut établir ce qui s’est produit, sans expliquer automatiquement pourquoi

Une blockchain peut enregistrer quand une adresse donnée a lancé une transaction, comment des actifs se sont déplacés, et comment l’état d’un contrat a changé. Cette catégorie d’enregistrement convient pour vérifier les variations d’offre, la direction des fonds, les votes de gouvernance et le fait qu’une fonction donnée ait été appelée.

Un enregistrement en chaîne n’indique généralement pas directement au lecteur l’identité réelle derrière une adresse, et ne peut pas expliquer à lui seul l’objet d’une transaction. Une personne peut contrôler plusieurs adresses, et plusieurs personnes peuvent agir via l’adresse d’une même plateforme dépositaire. Un nombre d’adresses ne peut pas être assimilé directement à un nombre d’utilisateurs, et un décompte de transferts de tokens ne peut pas être assimilé directement à un degré d’adoption réelle.

Les données en chaîne peuvent en outre passer par de l’indexation, de l’étiquetage et des calculs avant d’être affichées. Les champs de transaction vérifiables indépendamment en chaîne relèvent de l’enregistrement du protocole, tandis que les étiquettes d’adresses, les classifications de détenteurs et les graphiques statistiques fournis par un service comportent un jugement supplémentaire. En employant cette catégorie de résultats, il faut examiner la base de calcul, les réseaux couverts et la date de mise à jour.

Un code source vérifié indique seulement que le code correspond à la version déployée

Un contrat intelligent est un programme déployé sur une blockchain qui exécute des opérations selon son code. Sur les réseaux employant la machine virtuelle Ethereum (Ethereum Virtual Machine, EVM), comme Ethereum, la vérification du code source recompile généralement le code publié avec les mêmes réglages, puis le compare au code machine réellement exécuté à l’adresse du contrat. Le code machine est le résultat compilé que le réseau exécute directement. La note d’Ethereum.org sur la vérification des contrats distingue ce type de contrôle de correspondance de la vérification formelle ; la vérification formelle emploie des méthodes mathématiques pour contrôler si un programme satisfait des propriétés spécifiées à l’avance. D’autres réseaux exigent de contrôler le code du programme selon leurs propres mécanismes de déploiement et de versions.

Ainsi, « le code du contrat est vérifié » indique généralement que le code vu par le lecteur correspond au programme en chaîne ; cela n’indique pas que le code ait passé un audit de sécurité, ni que le programme soit dépourvu de failles logiques. Les commentaires et les noms de variables dans un code publié peuvent aussi être trompeurs ; le comportement réel dépend de la logique exécutable.

Il faut en outre établir si un contrat d’entrée transmet les demandes à un autre code d’implémentation. Une telle entrée est souvent appelée contrat proxy. Un proxy évolutif permet à un compte détenant le droit correspondant de remplacer le code d’implémentation ; la documentation des contrats proxy d’OpenZeppelin explique comment proxy, contrat d’implémentation et administrateur de mise à niveau fonctionnent de concert. Ne lire que le code court de l’adresse du proxy elle-même peut faire manquer à la fois le contrat qui exécute réellement les fonctions et les droits de mise à niveau.

Un dépôt de code présente un historique de développement, ce qui n’équivaut pas aux fonctions en production

Un dépôt de code public peut présenter fichiers, enregistrements de commits, étiquettes de version, discussions de problèmes et contributeurs. Un commit est une modification de code enregistrée, et une étiquette de version sert souvent à marquer une publication donnée. Ils peuvent aider à vérifier si un projet continue de modifier son code, quand une fonction donnée a été ajoutée, et ce qui a changé entre les versions.

La note de GitHub sur l’activité d’un dépôt présente des enregistrements tels que poussées, fusions, poussées forcées et changements de branches. Une activité abondante ne signifie pas une qualité de code élevée, et peu de commits n’indiquent pas nécessairement qu’un projet se soit arrêté ; mises à jour automatiques, code copié et développement hors dépôt public influent tous sur les chiffres de surface.

Le code du dépôt doit aussi correspondre à la version réellement déployée. En étudiant une application en chaîne, il convient d’examiner si des étiquettes de publication, des enregistrements de déploiement ou des informations de vérification de contrat relient une version du dépôt à une adresse en chaîne ; sinon on ne peut confirmer que « ce code existe dans le dépôt », et non qu’il tourne en production.

Un rapport d’audit se lit selon le périmètre, la version, la date et le traitement des constats

Un audit de sécurité consiste pour des professionnels à examiner du code, une conception ou des hypothèses de fonctionnement dans un certain périmètre et sur une certaine période, et à consigner les problèmes trouvés. À la lecture d’un rapport, ce qui compte n’est pas seulement qu’« un audit a été fait », mais aussi :

• si les fichiers, adresses de contrat ou commits de code examinés sont clairement indiqués ;
• si le code a connu des changements importants après l’achèvement de l’audit ;
• quels composants, dépendances externes et conditions de fonctionnement se situent hors du périmètre du contrôle ;
• quels problèmes le rapport a trouvés, et comment le projet a répondu ;
• si les correctifs ont été re-contrôlés, et si des problèmes non corrigés subsistent ;
• si le rapport a été publié par la partie auditrice, et si un lien renvoie au fichier complet.

Un audit ne peut pas prouver l’absence de faille inconnue. La documentation de préparation au réseau principal d’OpenZeppelin explique de même qu’un audit ne peut pas garantir qu’un code soit exempt d’erreurs. Prendre une ancienne version, un module partiel ou un rapport dont les constats n’ont pas été re-contrôlés pour une preuve de sécurité de tout le système dépasse ce que le rapport lui-même peut étayer.

Un livre blanc expose un plan, ce qui n’est pas un relevé de réalisation

Un livre blanc présente généralement le problème qu’un projet entend résoudre, son approche de conception, ses dispositions sur les tokens ou son plan de développement. Il convient pour confirmer quels objectifs un projet a publiquement avancés, mais ne peut pas prouver à lui seul que ces objectifs ont été atteints.

Pendant la recherche, on peut vérifier séparément les affirmations vérifiables d’un livre blanc au regard de la documentation actuelle, des publications de code, du déploiement en chaîne et des fonctions réelles. Une date de feuille de route passée sans enregistrement de publication correspondant, des règles de tokens non conformes au contrat déployé, ou une documentation longtemps non mise à jour sont autant d’écarts à confirmer ; ils ne prouvent pas en eux-mêmes qu’un projet soit trompeur.

Une documentation peut aussi décrire une version ancienne. La date de publication d’une page, sa dernière modification, le réseau applicable et le numéro de version déterminent si un passage peut servir pour le système actuel. En l’absence de date ou d’information de version, marque la conclusion comme incertaine plutôt que de compléter toi-même le contexte manquant.

L’attention sur les réseaux sociaux n’est pas une preuve de fait

Mentions d’appréciation, partages, effectifs de groupes et intérêt dans les recherches décrivent la diffusion d’un contenu ; ils ne peuvent pas prouver directement des fonctions techniques, l’identité d’utilisateurs, la sécurité des fonds ou une demande de marché. Un compte peut être contrefait ou détourné, et des interactions peuvent venir de programmes automatisés ou d’une promotion coordonnée.

Les réseaux sociaux conviennent mieux pour repérer des affirmations à vérifier que comme preuve unique d’une affirmation. Lorsqu’une adresse de contrat, une mise à jour de version, un incident de sécurité ou une relation externe est en jeu, on peut revenir à la documentation du projet, au dépôt de code, aux enregistrements en chaîne et aux déclarations d’origine des parties concernées pour confirmation.

Le fait qu’une source divulgue ses intérêts importe aussi. L’auteur d’un contenu peut détenir le token concerné, recevoir une rémunération, participer au projet ou en tirer profit par un lien de recommandation. Une absence de divulgation ne prouve pas en soi que le contenu soit faux, mais le lecteur ne peut pas en apprécier un conflit d’intérêts potentiel, de sorte que le poids de cette preuve doit rester distinct des matériaux vérifiables de façon indépendante.

Un processus de vérification complet conserve les questions non résolues

Le résultat d’un DYOR ne devrait pas être seulement une série de liens ; il devrait aussi indiquer ce à quoi chaque preuve a répondu. Un processus général de vérification de l’information peut se consigner ainsi :

1. réécrire une appréciation vague en une affirmation précise et vérifiable ;
2. trouver le matériau d’origine le plus proche de cette affirmation, et consigner l’éditeur, la date et la version ;
3. croiser avec des enregistrements en chaîne, du code, un rapport complet ou une autre source indépendante ;
4. distinguer les faits directement observés, les déductions tirées de ces faits et l’opinion personnelle ;
5. écrire les conflits entre sources, et quelles preuves manquent encore ;
6. lorsqu’un contrat, un droit, une version ou une relation externe ne peut pas être confirmé, garder « incertain » ; ne pas prendre un vide pour une conclusion affirmative ou négative.

Une même conclusion de recherche cesse de valoir avec le temps. Les contrats peuvent être mis à niveau, les droits d’administration transférés, la documentation et le périmètre d’audit modifiés, et la liquidité comme la répartition des tokens évoluent aussi. En citant une information mouvante, conserve le moment auquel la donnée se rapporte ; n’écris pas un contrôle unique comme une conclusion permanente.

Un signal d’alerte courant appelle à poursuivre la vérification, non à condamner d’emblée

Les situations suivantes indiquent que les matériaux disponibles sont insuffisants ou en conflit, et exigent une vérification supplémentaire :

• une adresse de contrat n’apparaît que dans des publications ou messages privés dont l’origine ne peut pas être confirmée ;
• le nom, l’icône et le code de cotation sont identiques, mais le réseau ou l’adresse du contrat diffère ;
• une page déclare le code open source, sans dépôt ni enregistrement de vérification correspondant à la version déployée ;
• un audit est annoncé, sans fournir de rapport complet, de version examinée ni d’état des correctifs ;
• la description de l’offre ou des droits dans le livre blanc ne concorde pas avec le comportement actuel du contrat ;
• un langage tel que « rendement garanti » ou « sans risque » est employé, ou un sentiment d’urgence est fabriqué ;
• un soutien d’institutions externes est annoncé, mais la partie concernée n’a publié aucune déclaration vérifiable correspondante ;
• un administrateur peut mettre à niveau, suspendre ou déplacer des actifs, mais la description publique ne mentionne pas ces droits ;
• une capture d’écran de données n’a ni source, ni période, ni lien re-contrôlable ;
• une discussion ne cite que des articles se reprenant les uns les autres, sans matériau d’origine à trouver au bout.

Un signal d’alerte isolé ne peut pas prouver automatiquement qu’un projet soit frauduleux. Par exemple, qu’une équipe de développement ne publie pas toutes les identités, que les mises à jour de code soient peu fréquentes, ou qu’un contrat comporte des droits d’administrateur peuvent chacun avoir des raisons différentes. Une conclusion doit correspondre à des engagements précis, à la structure technique et à des enregistrements vérifiables.

Le DYOR a des limites, et ne doit pas servir à rejeter la faute sur les personnes lésées

Un lecteur ordinaire ne peut pas auditer seul tout le code, vérifier chaque information sur une équipe ni détecter une attaque professionnelle. Des informations peuvent être délibérément cachées, interfaces et comptes peuvent être contrefaits, et audits comme données publiques peuvent aussi avoir des angles morts. Faire ses propres recherches ne peut réduire qu’une partie du déficit d’information ; cela ne peut pas transformer tout risque inconnu en risque connu.

« Tu aurais dû faire tes propres recherches » ne peut pas non plus remplacer une divulgation exacte des informations importantes par le projet, ni excuser une déclaration mensongère. Lorsqu’une personne subit une perte du fait de matériaux trompeurs, d’une contrefaçon ou d’une faille technique, lui reprocher simplement de « ne pas avoir fait son DYOR » néglige l’asymétrie d’information et le niveau d’expertise requis.

Lorsqu’une question exige un jugement technique, de sécurité, fiscal ou juridique spécialisé, une vérification ordinaire de l’information ne peut couvrir ni la même étendue de preuves ni la même responsabilité.

FAQ

Lire le livre blanc suffit-il à accomplir un DYOR ?

Non. Un livre blanc expose principalement les objectifs et la conception d’un projet. Il reste à vérifier si le code actuel, le déploiement, les droits, l’activité en chaîne, le périmètre d’audit et la version de la documentation concordent avec ces affirmations.

Un code de contrat vérifié signifie-t-il qu’il est sûr ?

Non. La vérification du code source confirme principalement que le code publié correspond au code machine déployé. Elle ne trouve pas automatiquement toutes les failles logiques, et n’élimine ni droits de mise à niveau, ni dépendances externes, ni risque opérationnel.

Les données en chaîne ne peuvent pas être falsifiées : une conclusion tirée d’elles est-elle donc fiable à coup sûr ?

Les enregistrements de transactions en chaîne peuvent être vérifiés, mais étiquettes d’adresses, attribution d’identité, nombre d’utilisateurs et motifs des transactions exigent généralement une explication supplémentaire. Une base de calcul erronée, ou prendre plusieurs adresses pour plusieurs utilisateurs, produira de même une conclusion fausse.

Une équipe anonyme est-elle forcément peu fiable ?

On ne peut pas conclure d’après le seul anonymat. Une identité publiée peut ajouter des informations vérifiables, mais ne peut rien prouver quant au code, à la sécurité ou aux engagements ; l’anonymat réduit les matériaux vérifiables sur l’identité et le parcours, et ce déficit d’information devrait être consigné explicitement.

Le DYOR peut-il me dire quel actif je devrais acheter ?

Non. Le DYOR est un processus de vérification de l’information, des sources et des inconnues. Il ne produit pas automatiquement une conclusion d’achat, de vente ou de conservation adaptée à une personne donnée, et il ne peut pas prédire les prix futurs.

Concepts associés

Poursuis avec actif numérique, contrat intelligent, token crypto et clé privée, ou reviens au glossaire des cryptomonnaies.

Sources

• Ethereum.org : Block explorers — les données de blocs, transactions, comptes, contrats et tokens qu’un explorateur de blocs peut afficher.
• Ethereum.org : Verifying smart contracts — la différence entre correspondance du code source, code machine et vérification formelle.
• OpenZeppelin Docs : Upgrades Plugins FAQ — la relation entre proxy, contrat d’implémentation et administrateur de mise à niveau.
• OpenZeppelin Docs : Preparing for mainnet — audits, vérification du code source, droits d’administration et limites d’un audit.
• GitHub Docs : Using the activity view — enregistrements des changements, poussées, fusions et activité de branches d’un dépôt.