hackstack

Tendances

Cinq analyses sur l'ensemble du corpus. Chacune indique son statut : les analyses temporelles s'activeront quand les dates d'événement seront renseignées (Étape 6).

Note méthodologique

Le corpus est composé à ~99 % de projets gagnants (les non-gagnants ne viennent que de lablab.ai). Les taux de victoire et les comparaisons gagnants/ensemble sont donc biaisés et fournis comme indicateurs, jamais comme conclusions. La normalisation par nombre de prix, idéale, n'est pas possible : cette information n'est pas dans le corpus.

1.Saturation d'un thème

En attente — backfill Étape 6

Fréquence par trimestre, superposée au taux de victoire.

Analyse en attente de données

Cette analyse dépend de la date de l'événement (hackathon_date), absente du corpus actuel. Elle sera renseignée par le backfill du rescrape (Étape 6) et l'analyse s'activera automatiquement à ce moment-là.

2.Durée de vie d'une tendance

En attente — backfill Étape 6

Premier projet, pic, déclin.

Analyse en attente de données

Cette analyse dépend de la date de l'événement (hackathon_date), absente du corpus actuel. Elle sera renseignée par le backfill du rescrape (Étape 6) et l'analyse s'activera automatiquement à ce moment-là.

3.Stacks des gagnants vs l'ensemble

Disponible

Technologies sur-représentées chez les gagnants, avec test statistique.

2 386
Projets (avec stack)
2 315
dont gagnants
71
dont non-gagnants

Le corpus est composé à ~99 % de gagnants : la stack « des gagnants » et celle « de l'ensemble » sont presque identiques, donc le lift est proche de 1. Surtout, les rares non-gagnants proviennent tous d'une seule source (lablab), à la composition tech différente : une différence « statistiquement significative » reflète alors cet écart de source, pas un effet de victoire. À lire comme une base de référence, pas comme une conclusion — le contraste deviendra interprétable quand le rescrape (Étape 6) ajoutera des projets non primés sur toutes les sources.

  • Ethereum232 · lift 1.03✻
  • Gemini205 · lift 1.01
  • IPFS186 · lift 1.03✻
  • JavaScript183 · lift 1.03✻
  • ENS164 · lift 1.03✻
  • Polygon163 · lift 1.03✻
  • Base121 · lift 1.02
  • React112 · lift 0.98
  • Python103 · lift 0.94✻
  • Next.js98 · lift 1.01
  • Filecoin96 · lift 1.03
  • Chainlink89 · lift 1.03
  • Solidity88 · lift 1.03
  • Worldcoin88 · lift 1.03
  • GPT-482 · lift 0.90✻
  • web3.js76 · lift 1.03
  • AWS69 · lift 1.02
  • Scroll69 · lift 1.03
  • Arbitrum56 · lift 1.03
  • Claude54 · lift 0.99
  • Optimism54 · lift 1.03
  • TypeScript52 · lift 0.97
  • Llama51 · lift 0.85✻
  • Circle45 · lift 0.94✻
  • Solana43 · lift 1.01

✻ écart « significatif » au test z — à lire avec la réserve de source ci-dessus, ce n'est pas un effet de victoire.

4.Taille d'équipe et classement

Donnée absente du corpus

Corrélation entre la composition des équipes et le rang final.

Analyse indisponible

La taille des équipes (team_size) n'est présente dans aucune des sources importées, et le rescrape ne la récupérera pas nécessairement partout. Analyse indisponible tant qu'une source fiable ne fournit pas cette information — ce n'est pas une simple attente de backfill.

5.Thèmes à fort volume et faible taux de victoire

Disponible

Volume par thème et part de gagnants.

Fort volume, taux de victoire le plus bas (≥ 500 projets)

Le taux de victoire par thème est biaisé : il dépend du nombre de prix et des tracks sponsorisées de chaque événement, pas seulement de la qualité des projets. À lire comme un indicateur, pas comme une conclusion. La normalisation par nombre de prix, idéale, n'est pas possible ici : le corpus ne contient pas cette information.