| Token / Coin | Dépôt GitHub | URL | Cap. boursière | TVL | ID Llama | TVL / Cap. | Vol 24h | Revenu 12m | Cap. / Revenu | Revenu par année | Série | Série de croissance | Score | Compromis | Statut | Fondation |
|---|
| # | Token | Score de compromis | Valorisation | Croissance | Revenus actuels | Régularité | Taille & liquidité | Qualité & maturité | MCap / Rev | TVL / MCap | Volume 24h | Revenus 12m |
|---|
Cette section documente les principes de conception et les fondements statistiques du modèle de survie. Elle s'adresse aux lecteurs qui veulent comprendre comment les scores sont construits, et non comment les interpréter (voir la FAQ pour cela).
Le modèle repose sur un jeu de données dédupliqué de projets crypto et Web3 collecté via l'API GitHub en date de May 2026. La probabilité de survie est estimée via un cadre basé sur les cohortes : plutôt que d'attribuer des scores arbitraires, le modèle mesure le taux de survie observé de projets comparables selon leur ancienneté, leur niveau d'activité et les conditions du cycle de marché. Tous les signaux proviennent exclusivement de données de dépôt publiquement disponibles.
L'âge d'un projet l'expose à davantage d'occasions d'échouer. En crypto, la survie est également façonnée par les régimes de marché externes : les marchés haussiers gonflent les conditions de survie, les marchés baissiers les mettent à l'épreuve. Les cycles de halving du Bitcoin créent un rythme supplémentaire d'environ 4 ans d'expansion et de contraction de la liquidité. Comme l'année de cohorte détermine les conditions macroéconomiques dans lesquelles un projet est né, ces effets de régime sont captés implicitement par le cadre de cohorte.
Le taux de survie de la cohorte est le taux de survie observé de tous les projets nés la même année, dans des conditions macroéconomiques comparables. Tout projet partageant une année de fondation obtient le même taux de cohorte par construction ; il ne peut donc pas classer les projets entre eux au sein d'une cohorte — c'est le rôle du score composite ci-dessous. L'onglet Score n'affiche le taux de cohorte qu'à titre de contexte, à côté du score composite.
Chacune des cinq dimensions GitHub (contributeurs, commits, stars, forks, issues ouvertes) est notée indépendamment en plaçant le projet dans l'une des cinq bandes d'activité de largeur égale dérivées de la distribution complète du jeu de données. Chaque bande porte sa propre probabilité de survie basée sur la cohorte.
Lorsque deux projets sont comparés, le modèle évalue chaque dimension individuellement. Si le projet ayant le score global le plus élevé est également en tête sur chaque dimension individuelle, le résultat est considéré comme structurellement cohérent.
Lorsqu'une dimension inverse cette relation, c'est-à-dire que le projet au score global plus faible surperforme sur un facteur spécifique, cela est traité comme un signal de divergence. Une telle divergence n'invalide pas le score global. Elle indique que le projet moins bien classé détient une force localisée sur ce critère, qui mérite un examen plus approfondi avant d'en tirer des conclusions.
Comme tous les projets partageant la même année de fondation reçoivent le même taux de survie de cohorte par construction, ce taux seul ne peut pas distinguer les projets au sein d'une cohorte. Le modèle calcule donc aussi un score composite pour chaque projet : la moyenne arithmétique de ses cinq probabilités de dimension disponibles (contributeurs, commits, stars, forks, issues ouvertes). Seuls les projets ayant au moins un score de dimension disponible obtiennent un score composite.
Ce score composite est le score principal utilisé dans tout l'outil : la jauge et le badge dans Recherche, la colonne Score dans Filtrage, la comparaison directe dans Comparer, et le résultat du calculateur de score manuel dans l'onglet Score. Le panneau de comparaison de cohorte s'y appuie également, en identifiant les cinq projets de la cohorte d'année de fondation dont le score composite se situe immédiatement au-dessus du projet analysé et les cinq immédiatement en dessous, plus un groupe Similaire distinct composé des cinq projets ayant l'écart absolu de score composite le plus faible. Les projets sans données de dimension sont exclus de la comparaison. Lorsque tous les projets d'une cohorte ont le même score composite (la cohorte la plus récente), le panneau signale l'égalité plutôt qu'un rang.
Le calculateur de score manuel calcule ce même score composite pour un projet hypothétique à partir des cinq métriques que vous entrez et de son année de fondation, en utilisant les mêmes bandes et tables de cohorte que la base de données. Il affiche aussi le taux brut de la cohorte pour cette année, à titre de contexte uniquement. La cohorte d'année de fondation la plus récente (2026) est le seul cas où le composite ne peut pas classer les projets : tous les projets qui la composent sont encore actifs au moment de la collecte, donc ils obtiennent tous 100 %.
L'onglet Filtrage liste tous les projets du jeu de données sous forme de tableau filtrable et triable. La colonne Score de chaque ligne est le même score composite décrit ci-dessus, ce qui permet de classer et filtrer les projets de façon cohérente, projet par projet, sur l'ensemble du jeu de données plutôt qu'une seule cohorte à la fois.
Les filtres peuvent être combinés librement : plage de score composite, année du premier commit, tranche ou plage exacte de capitalisation boursière, TVL, ratio TVL/capitalisation boursière, ratio capitalisation boursière/revenu (capitalisation boursière divisée par le revenu des 12 derniers mois, affiché en multiple ; les projets sans revenu sont exclus), volume 24h, série de revenus (la plus longue série d'années consécutives, n'importe où dans la fenêtre de 5 ans et pas nécessairement se terminant par l'année en cours, durant laquelle le revenu DeFi Llama d'un projet était supérieur à un minimum que vous choisissez), et série de croissance du revenu (la plus longue série d'années consécutives, n'importe où dans la fenêtre de 5 ans et pas nécessairement se terminant par l'année en cours, durant laquelle le revenu a augmenté par rapport à l'année précédente ; l'année en cours est annualisée à partir du cumul depuis le début de l'année). Le revenu est la part des frais qu'un protocole conserve, pas le bénéfice net : les coûts d'exploitation et les incitations en token ne sont pas déduits. Les chiffres de capitalisation boursière, TVL, revenu et volume proviennent de CoinMarketCap et DeFi Llama et sont actualisés indépendamment des scores dérivés de GitHub, si bien qu'un projet peut ne pas avoir de données commerciales (« Pas de données ») tout en ayant un score composite, ou l'inverse. Les résultats peuvent être triés sur n'importe quel champ filtrable et exportés en XLSX.
Le modèle décrit des tendances historiques. Il ne prédit pas les résultats individuels. Un projet peut dépasser le taux de sa cohorte, ou échouer malgré un score élevé. Les scores sont fournis à titre informatif uniquement et ne constituent pas un conseil financier.
Quelque chose semble incorrect ? Si vous repérez une incohérence ou souhaitez mieux comprendre les données, contactez-nous. Nous serons ravis d'en discuter. 💬 Contact
Que signifie réellement le score ?
Chaque onglet affiche un score composite : la moyenne arithmétique des cinq probabilités de dimension d'un projet (contributeurs, commits, stars, forks, issues ouvertes), chacune étant elle-même une probabilité de survie basée sur la cohorte pour la bande d'activité de cette dimension. Il est spécifique au projet, et non partagé au sein de toute sa cohorte (la cohorte la plus récente est la seule exception : tous ses projets sont encore actifs, donc ils obtiennent tous 100 %). C'est ce qu'affichent Recherche, Filtrage, Comparer et l'onglet Score.
Dans le calculateur de score manuel (onglet Score), le score composite est calculé à partir des cinq métriques que vous entrez et de l'année de fondation, en utilisant les mêmes bandes et tables de cohorte que la base de données. Sous le score s'affiche aussi le taux de survie brut de la cohorte pour cette année, à titre de contexte uniquement : la part de tous les projets ayant effectué leur premier commit GitHub la même année et encore actifs à la date de collecte des données (May 2026). Tout projet né la même année partage ce taux, ce n'est donc pas le score lui-même. Par exemple, si 45 % des projets ayant fait leur premier commit en 2021 sont encore actifs, ces 45 % s'affichent comme contexte pour tout projet de 2021, tandis que son score composite dépend des métriques que vous avez entrées.
Les deux sont des référentiels historiques, pas des prédictions. Ils indiquent comment des projets similaires se sont comportés dans le temps, pas si ce projet précis va survivre.
Comment « vivant » ou « actif » est-il défini ?
Un projet est considéré comme actif s'il a eu au moins un commit GitHub dans les 365 jours environ précédant la date de collecte des données (May 2026). Les projets sans activité de commit récente sont marqués comme inactifs, que leur token soit encore échangé ou leur site encore en ligne.
Quelles sont les cinq dimensions GitHub et pourquoi ont-elles été choisies ?
Les cinq dimensions sont : Contributeurs, Total des commits, Stars, Forks et Issues ouvertes. Elles ont été choisies car elles sont accessibles publiquement via l'API GitHub pour presque tous les dépôts, ce qui rend le jeu de données reproductible et comparable sur des milliers de projets.
Chaque métrique est répartie en cinq bandes d'activité de largeur égale selon la distribution du jeu de données au moment de la collecte (Bande 1 = activité la plus faible, Bande 5 = la plus élevée). Au sein de chaque bande, le taux de survie des projets de la même cohorte d'année de fondation est calculé et utilisé comme contribution de cette dimension au score.
Le total des commits et les contributeurs sont les meilleurs prédicteurs individuels de la longévité d'un projet dans le jeu de données. Stars et Forks sont des signaux plus faibles — de nombreux projets actifs et sérieux ont très peu d'étoiles.
Pourquoi les projets de 2026 obtiennent-ils toujours 100 % ?
Un projet est compté comme actif s'il a effectué au moins un commit GitHub dans les 365 jours environ précédant la date de collecte des données (May 2026). Tout projet fondé en 2026 a fait son premier commit moins d'un an avant la collecte, donc tous sont, par construction, encore actifs. Chaque taux de survie de cette cohorte est donc de 100 % : le taux de la cohorte, chacun des cinq scores de dimension, et donc aussi le score composite. Cela s'applique dans tous les onglets : Score, Recherche, Filtrage et Comparer affichent tous 100 % pour tout projet de 2026, et aucun classement n'est possible au sein de cette cohorte puisque tous les projets sont à égalité. C'est un artefact des données, pas un véritable signal de qualité ou de pérennité.
Considérez tout score de 2026 avec prudence : le chiffre reflète la fraîcheur du jeu de données, pas la solidité du projet. Pour comparer des projets de 2026 entre eux, utilisez leurs métriques brutes (contributeurs, commits, stars, forks, issues ouvertes) plutôt que le score. Dans Filtrage, tous les projets de 2026 sont à égalité à 100 %, ils se retrouvent donc en tête de tout tri par score et passent tout filtre de score minimum ; utilisez le filtre d'année de premier commit pour les exclure.
Le même mécanisme affecte partiellement la cohorte précédente : tout projet de 2025 dont le premier commit se situe dans les 365 jours précédant la collecte est actif par construction, donc son taux est légèrement surestimé. Les cohortes plus anciennes ne sont pas concernées.
Comment rechercher un projet ?
Utilisez l'onglet Recherche et saisissez le nom de domaine du projet (ex. ethereum.org), son propriétaire GitHub (ex. aave), ou son symbole de token (ex. UNI). Vous pouvez aussi coller une URL complète — l'outil en extraira automatiquement le domaine. Les résultats apparaissent au fur et à mesure de la saisie ; cliquez ou appuyez sur Entrée pour sélectionner.
Le jeu de données couvre des milliers de domaines de projets crypto et Web3. Si un projet n'apparaît pas dans les résultats de recherche, il n'est actuellement pas dans la base de données.
Mon projet est dans la base de données mais affiche « Aucune donnée GitHub disponible » — qu'est-ce que cela signifie ?
Cela signifie que le domaine du projet a été identifié comme un projet crypto, mais qu'aucun dépôt GitHub n'a pu lui être associé au moment de la collecte des données. Cela peut arriver parce que le projet n'a pas de dépôt GitHub public, que le dépôt était privé, supprimé, ou que le lien domaine-GitHub n'a pas pu être déterminé automatiquement.
Sans métriques GitHub, aucun score de survie ne peut être calculé. Environ 764 projets (7 % du jeu de données) entrent dans cette catégorie.
Mon projet n'est pas du tout dans la base de données. Que puis-je faire ?
Si le projet n'est pas indexé, vous pouvez tout de même l'analyser manuellement via l'onglet Score. Vous devrez rassembler cinq métriques depuis le dépôt GitHub du projet :
1. Rendez-vous sur le dépôt GitHub du projet.
2. Trouvez le nombre de contributeurs (indiqué sur la page principale du dépôt sous « Contributors »).
3. Trouvez le nombre total de commits (cliquez sur le lien de l'historique des commits en haut de la liste des fichiers).
4. Notez le nombre de Stars et de Forks affiché en haut du dépôt.
5. Comptez les issues ouvertes depuis l'onglet Issues.
6. Notez l'année du premier commit (l'année de fondation du projet).
Saisissez ces valeurs et l'année de fondation dans l'onglet Score et cliquez sur Calculer le score composite pour obtenir le score composite du projet.
Quelles blockchains et écosystèmes sont couverts ?
Le jeu de données couvre des projets sur Ethereum (y compris les chaînes compatibles EVM), Solana, Cosmos, Bitcoin, et plusieurs autres écosystèmes. Les principaux langages de programmation représentés incluent TypeScript, Solidity, Rust, Go, Python et C++.
La couverture n'est pas exhaustive — le jeu de données a été constitué à partir de listes de projets crypto publiquement disponibles et peut sous-représenter les écosystèmes plus récents ou plus modestes.
Quand utiliser l'onglet Score plutôt que l'onglet Recherche ?
Utilisez l'onglet Score dans l'une de ces situations :
• Le projet n'est pas dans la base de données (introuvable dans Recherche).
• Le projet apparaît dans la base de données mais n'a pas de données GitHub (« Aucune donnée GitHub disponible »).
• Vous voulez tester un scénario hypothétique — ex. : « quel serait le score si ce projet avait 50 contributeurs au lieu de 10 ? »
• Vous évaluez un projet qui n'a pas encore été lancé publiquement mais possède un dépôt GitHub.
Où trouver les métriques GitHub d'un projet s'il n'est pas dans la base de données ?
Les cinq métriques sont visibles sur n'importe quelle page de dépôt GitHub public, sans compte nécessaire :
• Stars & Forks : en haut à droite de la page principale du dépôt.
• Contributeurs : barre latérale droite de la page principale du dépôt, sous « Contributors ». Cliquez pour voir le nombre total.
• Issues ouvertes : l'onglet « Issues » à côté de « Code » et « Pull requests » en haut. Le badge affiche le nombre ouvert.
• Total des commits : cliquez sur l'icône horloge/commit en haut de la liste des fichiers (ex. « 1 234 commits »). Cela affiche le nombre total.
• Année de fondation : ouvrez l'historique des commits et faites défiler jusqu'au tout premier commit, ou consultez la date de création du dépôt dans la section « About » ou via l'API GitHub.
https://api.github.com/repos/OWNER/REPO renvoie created_at, stargazers_count, forks_count et open_issues_count en un seul appel. Pour le nombre de commits et de contributeurs, utilisez les points de terminaison /contributors et /commits.Quelle année de fondation saisir si le projet a plusieurs dépôts ?
Utilisez l'année du commit le plus ancien parmi tous les dépôts principaux. Pour les projets ayant une organisation GitHub (ex. github.com/ethereum), il s'agit généralement de l'année de création du dépôt du protocole principal ou du produit central.
En cas de doute, utilisez par défaut l'année indiquée sur le site officiel du projet ou dans son whitepaper. L'année de fondation détermine la cohorte à laquelle le projet est comparé, il est donc important d'utiliser la bonne année pour obtenir un score précis.
Les projets fondés après la date de collecte des données (May 2026) ne sont pas encore dans le jeu de données : l'onglet Score signale qu'une telle année n'est pas dans notre jeu de données tant que les données ne sont pas actualisées.
Que montre l'onglet Comparer ?
L'onglet Comparer permet de mettre deux projets côte à côte. Il affiche un radar montrant comment les cinq dimensions GitHub de chaque projet se situent l'une par rapport à l'autre (en scores de percentile au sein de leurs bandes), et affiche le score composite de chaque projet pour une comparaison directe.
La comparaison met aussi en évidence quel projet a le score composite le plus élevé et de combien de points, ainsi que l'année de fondation, le langage et le statut actif de chacun, plus une répartition par dimension qui signale où les métriques individuelles d'un projet divergent de sa position globale.
Puis-je comparer un projet de Recherche avec un projet noté manuellement ?
L'onglet Comparer permet actuellement de rechercher et comparer des projets qui sont dans la base de données. Si vous avez noté un projet manuellement dans l'onglet Score, utilisez le bouton Comparer avec un autre projet sous le résultat du score. Il remplit le premier emplacement vide de l'onglet Comparer avec votre score manuel (affiché comme « Score manuel (année) ») ; recherchez ensuite un second projet pour le comparer. Son score composite est la même valeur que celle affichée dans l'onglet Score.
Que montre l'onglet Filtrage ?
Filtrage est un tableau filtrable et triable de tous les projets du jeu de données. Sa colonne Score est le même score composite affiché dans la jauge de l'onglet Recherche (la moyenne arithmétique des cinq probabilités de dimension d'un projet), ce qui permet de classer et filtrer les projets de façon cohérente sur tout le jeu de données, pas seulement au sein d'une cohorte d'année de fondation.
Outre le score composite dérivé de GitHub, Filtrage affiche aussi la capitalisation boursière, la TVL, le ratio TVL/capitalisation boursière, le ratio capitalisation boursière/revenu, le volume 24h, et cinq années de revenu de protocole provenant de CoinMarketCap et DeFi Llama, et permet de filtrer ou trier sur n'importe quelle combinaison de ces critères. L'onglet Recherche affiche la capitalisation boursière, la TVL et le revenu actuel du projet sélectionné.
Puis-je filtrer Filtrage pour n'afficher que les projets avec des données commerciales ?
Oui. Réglez le filtre de capitalisation boursière sur une tranche autre que « Toutes », ou définissez un filtre TVL, Cap. boursière/Revenu, Volume, Série de revenus ou Série de croissance du revenu, et les lignes sans ces données disparaîtront des résultats. La capitalisation boursière, la TVL, le revenu et le volume proviennent de CoinMarketCap et DeFi Llama selon leurs propres calendriers, indépendamment de la collecte des données GitHub ; un projet peut donc avoir un score composite sans données de marché, ou des données de marché sans score GitHub. Lorsque CoinGecko ne fournit pas de capitalisation pour un projet, celle de DeFi Llama est utilisée à la place et signalée par le symbole †. Les résultats peuvent être triés sur n'importe quel champ filtrable et exportés en XLSX avec le bouton Télécharger sous le tableau.
Que montre l’onglet Compromis ?
L’onglet Compromis classe les projets selon le meilleur compromis entre valorisation, croissance, revenus actuels, régularité, taille et qualité, plutôt que selon une seule métrique. Chaque ligne affiche le score de compromis global (0–100), les six scores par bloc, MCap / Revenus, TVL / MCap, le volume 24h et les revenus 12 mois. Cliquez sur une ligne pour ouvrir le projet dans l’onglet Recherche.
Le même score est disponible dans le Filtrage sous forme de colonne Compromis triable et filtrable, ainsi que dans l’export XLSX du Filtrage.
Comment le score de compromis est-il calculé ?
Quinze critères chiffrés sont répartis en six blocs : Valorisation (MCap / Revenus, TVL / MCap), Croissance (croissance annuelle des revenus, croissance YTD 2026 annualisée, série de croissance), Revenus actuels (run-rate, revenus 12 mois), Régularité (série de revenus), Taille & liquidité (capitalisation, TVL, volume 24h / capitalisation) et Qualité & maturité (score GitHub, année du premier commit).
Chaque critère est converti en score percentile (0–100) parmi les projets actifs disposant à la fois d’une capitalisation et de données de revenus, ce qui évite que les valeurs extrêmes faussent l’échelle. Un MCap / Revenus plus bas est meilleur ; pour la plupart des autres critères, plus haut est meilleur. Le score d’un bloc est la moyenne pondérée de ses critères disponibles (les valeurs manquantes sont ignorées et les poids restants renormalisés), et le score global est la moyenne pondérée des six blocs. Par défaut, les blocs pèsent 30 % pour la valorisation, 25 % pour la croissance, 15 % pour les revenus actuels, 5 % pour la régularité, 10 % pour la taille & liquidité et 15 % pour la qualité & maturité.
À quoi servent les curseurs, les boutons ↑/↓ et les réglages avancés ?
Chaque curseur fixe le poids relatif d’un critère. Le pourcentage à côté de chaque bloc indique sa part du total, et les poids n’ont pas besoin de totaliser 100. Mettez un poids à 0 pour ignorer un critère. Le bouton ↑/↓ inverse le sens d’un critère (par exemple, passez la capitalisation en « bas = mieux » si vous préférez les petites capitalisations). Tout à la moitié place chaque poids au milieu de la plage (pondération égale), Réinitialiser rétablit les réglages d’origine, et vos réglages sont conservés dans ce navigateur.
Le plafond TVL / MCap limite les ratios extrêmes (par ex. 326x) pour qu’une anomalie de données ne domine pas ce critère. Dans Avancé, le malus de croissance et le nombre minimum de taux de croissance retirent des points au bloc Croissance quand un projet a trop peu de taux annuels calculables.
Pourquoi le classement est-il « provisoire » pendant le chargement de la page ?
Les capitalisations, la TVL et les revenus sont chargés par lots après l’ouverture de la page. Le classement est recalculé en direct à mesure que les données arrivent, et les scores portent un « ~ » tant que toutes les sources ne sont pas chargées. Une fois le chargement terminé, le classement est définitif et ne dépend pas de l’ordre d’arrivée des données. L’export XLSX n’est disponible que pour le classement définitif.
Pourquoi un projet est-il absent du classement ou affiché sans score ?
Un projet n’est noté que s’il dispose à la fois d’une capitalisation et de données de revenus (revenus 12 mois positifs). Les autres affichent « — » (ou « … » pendant le chargement). Les projets inactifs (aucun commit GitHub récent) peuvent recevoir un score dans le Filtrage, mais ne font pas partie du classement Compromis ni du groupe de référence utilisé pour les percentiles. Un critère manquant pour un projet (par exemple la TVL ou les revenus des premières années) est ignoré plutôt que compté comme zéro.
Puis-je exporter le classement ?
Oui. Le bouton Télécharger le classement en XLSX exporte le classement complet, et pas seulement les lignes affichées : les six scores par bloc, la valeur de chaque critère, le volume 24h, et une seconde feuille listant les poids, les sens et les paramètres utilisés. L’export XLSX du Filtrage inclut aussi le score de compromis et ses scores par bloc.
Que signifient les libellés PROSPÈRE / STABLE / FRAGILE / RISQUE ÉLEVÉ ?
Ces libellés sont des seuils appliqués au score composite du projet, la même valeur que celle affichée dans la jauge de Recherche et dans l'onglet Score :
• 🟢 PROSPÈRE — 75 % ou plus. Les propres dimensions GitHub du projet le placent dans des bandes d'activité à forte survie.
• 🟡 STABLE — 50–74 %. La plupart de ses dimensions se situent dans des bandes de survie au-dessus de la moyenne.
• 🟠 FRAGILE — 25–49 %. Ses dimensions sont réparties entre bandes de survie plus fortes et plus faibles, ou regroupées autour du milieu.
• 🔴 RISQUE ÉLEVÉ — En dessous de 25 %. La plupart de ses dimensions se situent dans des bandes d'activité à faible survie.
Comme le score composite est construit à partir des niveaux d'activité propres au projet plutôt que de sa seule année de naissance, ce libellé peut différer de ce que suggérerait à lui seul le taux brut de la cohorte du même projet (affiché à titre de contexte dans l'onglet Score). Un libellé PROSPÈRE reflète l'empreinte GitHub spécifique de ce projet, pas une garantie qu'il continuera de croître. L'exception est la cohorte la plus récente (2026), où tous les projets obtiennent 100 % et sont donc étiquetés PROSPÈRE car aucun n'a eu le temps de devenir inactif.
Un projet que je sais mort obtient quand même un score élevé — pourquoi ?
Le score composite décrit comment se sont comportés historiquement des projets ayant une empreinte GitHub similaire (même année de fondation, bandes d'activité similaires). Il ne vérifie pas si un projet commit encore aujourd'hui. Quatre des cinq entrées (total des commits, contributeurs, stars, forks) sont des compteurs cumulatifs, donc un projet ayant bâti une empreinte importante avant de devenir silencieux peut quand même se retrouver dans des bandes à forte survie.
En général, cependant, un projet mort obtient un score plus faible : il se situe typiquement dans des bandes à faible survie sur ses propres dimensions (commits, contributeurs, stars, forks, issues) plutôt que de bénéficier du bilan global de sa cohorte. Cela vaut aussi bien dans l'onglet Score que dans Recherche, Filtrage et Comparer.
De plus, un projet de notre base de données a pu être marqué comme « actif » au moment de la collecte des données même s'il est depuis devenu dormant. Les données datent de May 2026.
Cet outil constitue-t-il un conseil financier ?
Non. Cet outil est strictement informatif. Les scores de survie reposent sur des tendances historiques d'activité GitHub et ne tiennent pas compte de la tokenomics, de la qualité de l'équipe, du financement, de l'environnement réglementaire, des conditions de marché ou de tout autre facteur pertinent pour des décisions d'investissement.
À quelle fréquence les données sont-elles mises à jour ?
Le jeu de données actuel a été collecté en May 2026. Le statut « vivant » reflète l'activité GitHub à cette date de collecte. Des mises à jour sont prévues périodiquement, mais il s'agit d'un produit bêta et leur fréquence peut varier.
La version des données est indiquée dans le pied de page de cette page.
Comment demander l'ajout d'un projet ou signaler une donnée incorrecte ?
Contactez l'équipe CoinVentureLab via le lien de contact dans l'onglet Méthode, ou directement à contact@coinventurelab.com. Indiquez le domaine du projet, l'URL de son dépôt GitHub, et une brève description du problème.