Pi Network annonce 300 applications sur sa Mainnet : combien sont réellement utilisées ?

Pi Network a placé un nouveau décompte d'applications au centre de son premier sommet sur l'écosystème. Plus de 300 applications Mainnet sont signalées, aux côtés d'une audience revendiquée de plus de 60 millions de Pionniers engagés, de 18,1 millions de personnes ayant passé des contrôles d'identité et de plus de 420 000 nœuds. Aucun de ces chiffres ne mesure l'utilisation répétée d'une application ou la valeur des biens et services payés en PI. Le sommet fournit une nouvelle raison d'examiner ce qu'est une application Mainnet et ce que son registre public peut montrer.

Pi Network a déclaré qu'il existe plus de 300 applications Mainnet alors qu'il prépare un sommet des développeurs en novembre, ajoutant un nouveau décompte publié à ses affirmations sur la taille de son écosystème.

Dans une annonce du 15 octobre, le projet a programmé son premier Pi Ecosystem Summit du 17 au 19 novembre. Il a indiqué que l'événement en ligne comprendrait des lancements de plateforme, des démonstrations de développeurs, des présentations de partenaires et d'applications, ainsi que des détails sur un autre hackathon. Sa déclaration a donné le total de 300 applications, mais n'a pas fourni de répertoire de toutes les applications comptées, d'utilisation par application, d'utilisateurs payants ou de valeur transactionnelle qui leur est attribuable.

Le sommet met un chiffre sur la couche applicative

La déclaration de Pi décrit un réseau de distribution existant avec plus de 60 millions de Pionniers engagés, l'authentification, les paiements et la découverte d'applications. Il cite séparément plus de 18,1 millions d'utilisateurs entièrement vérifiés KYC et plus de 420 000 nœuds. Ces mesures ont des unités différentes. Un nœud est un participant à l'infrastructure, un utilisateur vérifié est une personne qui a passé un processus déclaré, et une application Mainnet est un logiciel associé au réseau en direct. Aucun des trois n'est automatiquement un client payant de l'un des deux autres.

L'annonce offre une cible d'audit opportune. Un décompte de plus de 300 est suffisamment important pour examiner les catégories, mais la déclaration publique ne fournit pas d'inventaire horodaté ni de définition cohérente pour l'inclusion. Les applications pourraient accepter des paiements PI, utiliser l'authentification sans paiements, fournir des informations, héberger un jeu ou se connecter à des outils de développement. Un répertoire d'applications actuel pourrait n'afficher qu'un sous-ensemble sélectionné. Rapporter les 300 comme 300 entreprises actives ajouterait des faits que le projet n'a pas revendiqués.

Ceci est distinct du récent calendrier de protocole du réseau. Un article sur le Protocole 28 a examiné la préparation des nœuds avant l'activation Mainnet prévue le 16 octobre. Il a nommé les mises à niveau de contrat et la gestion des données de transaction comme changements techniques. La nouvelle annonce du sommet concerne l'inventaire des applications et ce que les développeurs ont construit. Une mise à niveau réussie des nœuds n'établit pas qu'une application répertoriée a des clients payants.

C'est également différent de l'entonnoir KYC. Une analyse précédente du backlog de vérification de Pi a séparé les utilisateurs autorisés à progresser des portefeuilles qui ont réellement dépensé des PI. Le décompte des applications ajoute une autre étape : il doit y avoir un logiciel disponible, accessible et digne d'y revenir. Éliminer un goulot d'étranglement d'identité et ajouter une application sont tous deux des événements observables. Une transaction par un utilisateur actif est un troisième événement, nécessitant un enregistrement séparé.

Le programme du sommet pourrait améliorer les preuves. Pi promet des démonstrations d'outils de développement spécifiques et d'applications partenaires. Une démonstration peut montrer qu'une fonctionnalité s'exécute, tandis que des paiements répétés sur plusieurs semaines montreraient une utilisation continue. L'annonce ne s'engage pas à publier la rétention au niveau des applications ou les reçus des marchands pendant l'événement. Un inventaire des applications et des exemples de paiements reproductibles permettraient aux lecteurs d'évaluer le décompte avant tout total promotionnel ultérieur.

Le déploiement sur le Mainnet et l'inscription au répertoire sont deux étapes distinctes

Le guide de lancement pour développeurs de Pi décrit comment un créateur passe du Testnet au Mainnet. Le développeur crée une application Mainnet distincte dans le portail, vérifie son URL, connecte un portefeuille d'application et complète une liste de contrôle. Un portefeuille multisignature entrant pour les paiements d'utilisateur à application nécessite une demande et un examen. Les paiements d'application à utilisateur ne sont disponibles que pour les applications Testnet et certaines applications Mainnet selon la formulation actuelle du guide. La décision d'un développeur de créer une entrée Mainnet ne signifie donc pas que tous les chemins de paiement possibles sont actifs.

Les règles d'inscription au répertoire imposent une autre étape. Pour apparaître dans l'interface de l'écosystème Mainnet sélectionnée du navigateur Pi, une application doit être fonctionnelle, intégrer l'authentification Pi, répondre aux exigences d'identité pour son développeur et respecter les politiques sur les transactions et l'expérience utilisateur. Une application peut exister sur le Mainnet sans être acceptée dans cette liste sélectionnée. La mise à jour antérieure de Pi sur les applications ajoutées indique que la liste n'inclut pas toutes les applications Mainnet ou prêtes pour le Mainnet et que des répertoires tiers peuvent en montrer davantage.

Cette différence fournit un moyen direct de tester le chiffre du sommet. Si Pi affirme qu'il y a plus de 300 applications Mainnet, cela signifie-t-il des entrées de portail avec une configuration Mainnet active, des applications avec des portefeuilles approuvés, des applications répertoriées dans le navigateur, ou un ensemble plus large incluant des services auto-hébergés ? L'annonce d'octobre ne le précise pas. Un journaliste ne peut pas substituer le nombre visible dans le navigateur au chiffre du projet sans d'abord démontrer que les deux appliquent la même règle d'inclusion.

La distinction n'est pas une accusation que le chiffre est faux. Les répertoires de produits sélectionnent souvent un ensemble plus restreint que l'univers total des logiciels déployés. Pi décrit explicitement cette pratique. Le problème journalistique est la reproductibilité. Une liste datée avec les identifiants des applications, leur statut et leurs capacités de paiement permettrait à un lecteur indépendant de reproduire le total. Sans cela, le décompte reste un chiffre rapporté par l'entreprise, utile comme affirmation sur l'échelle mais faible comme mesure de l'utilisation continue.

Une application pourrait satisfaire aux exigences de qualité et de politique tout en ayant peu de trafic. Inversement, une application indépendante non répertoriée pourrait attirer des utilisateurs. L'inclusion dans le répertoire est une décision de sélection ; le trafic et les transactions sont des enregistrements comportementaux. La fonction de staking du répertoire de Pi ajoute une autre complication : les Pionniers et les entreprises peuvent staker des PI pour améliorer la position d'une application dans l'interface de l'écosystème. Pi a déclaré que le stake peut augmenter l'exposition et les impressions, avec un trafic utilisateur potentiel. Un classement plus élevé dans le répertoire est en partie fonction de la promotion stakée et ne peut à lui seul vérifier la demande organique.

L'annonce de staking identifie les applications Mainnet, les applications App Studio et des services tels que les échanges centralisés parmi les catégories du répertoire. Ce mélange signifie qu'un analyste doit filtrer l'interface avant de traiter chaque tuile comme une application Mainnet. Cela rend également difficile la comparaison entre catégories : un lien d'échange, une expérience de créateur et une application avec un portefeuille Mainnet approuvé peuvent être affichés côte à côte tout en servant des objectifs différents.

La capacité de paiement est une mesure plus étroite que l'existence de l'application

Pi a ajouté le support d'App Studio pour les applications Mainnet et les paiements en direct dans l'application en mars. Sa déclaration du Pi Day indiquait que quatre applications App Studio avaient été invitées à passer au Mainnet et à intégrer de vrais paiements en PI. La même publication expliquait les interactions de paiement persistantes, qui peuvent laisser une fonctionnalité achetée active au-delà d'une seule session. Quatre est un décompte des applications App Studio invitées à ce moment-là, pas le nombre total d'applications Mainnet sur l'ensemble du réseau.

Une mise à jour antérieure d'App Studio de janvier décrivait l'intégration des paiements en jetons de test. Elle permettait aux créateurs d'expérimenter sans déplacer de vrais PI entre utilisateurs et applications. Comparer un prototype de paiement de test avec un achat Mainnet complété confondrait une activité simulée et une activité économiquement significative. En octobre, les outils d'App Studio s'étaient développés, mais l'annonce du sommet n'a pas rapporté le nombre de paiements réels effectués via ses produits.

Le chemin de paiement Mainnet est observable en principe. Un utilisateur autorise un transfert, l'application traite le rappel, et un registre enregistre la transaction PI réglée. La chaîne publique peut révéler un paiement vers un portefeuille connu, mais une adresse de portefeuille seule peut appartenir à un développeur, un échange, un test interne ou un utilisateur ordinaire. Pour mesurer la demande des consommateurs, l'opérateur de l'application devrait identifier son adresse de réception de production et divulguer suffisamment d'informations sur son service pour distinguer les ventes des auto-transferts, des incitations ou des mouvements répétés des mêmes pièces.

Un décompte de frais ou de paiements peut induire en erreur dans les deux sens. Une application peut générer quelques grosses commandes de marchands, tandis qu'une autre exécute des milliers de petites actions payantes. Le PI brut transféré n'est pas un revenu net si les utilisateurs reçoivent des remboursements ou des récompenses. Une application avec abonnements pourrait avoir une forte rétention et moins de transferts individuels. Les portefeuilles payants répétés, les acheteurs distincts, les achats complétés et la période mesurée rendraient la comparaison plus solide. Le projet n'a pas publié ces quatre champs pour ses plus de 300 applications dans la publication du sommet.

La bibliothèque de paiement de Pi promet une intégration rapide pour les développeurs utilisant des piles web prises en charge. Son guide de développement de janvier décrivait un moyen d'ajouter une fonctionnalité de paiement en moins de dix minutes. L'intégration du code est un jalon technique, pas une preuve que les clients ont ensuite acheté un service. La distinction est visible dans de nombreux réseaux de paiement : accepter un instrument et générer du commerce sont des résultats différents.

Certaines applications peuvent être précieuses sans facturer en PI. Un utilitaire peut utiliser l'authentification Pi pour servir des utilisateurs vérifiés, fournir des informations ou connecter les Pionniers à une activité extérieure. Le sommet pourrait raisonnablement présenter de tels logiciels. Il serait inexact de considérer l'absence de paiement dans chaque application comme la preuve que l'application n'a pas d'utilisateurs. La mesure correcte doit correspondre au produit : sessions répétées pour un outil gratuit, commandes complétées pour un marchand, déploiements actifs pour un service de développeur, ou conversions payantes pour une application dont le modèle économique les exige.

Un audit doit garder quatre dénominateurs distincts

Les chiffres publiés peuvent être placés dans un tableau de mesure simple sans diviser des quantités dissemblables. Les plus de 60 millions de Pionniers engagés de Pi décrivent l'audience la plus large qu'il revendique. Ses plus de 18,1 millions d'utilisateurs vérifiés décrivent les personnes ayant passé le KYC. Ses plus de 300 applications Mainnet décrivent des logiciels. Ses plus de 420 000 nœuds décrivent l'infrastructure réseau. Un ratio d'adoption valide nécessiterait le nombre d'utilisateurs distincts d'une application spécifiée sur une période définie, divisé par une population éligible clairement définie. Pi n'a pas fourni ce numérateur dans l'annonce.

Diviser 18,1 millions de personnes vérifiées par 300 applications donnerait environ 60 333 personnes par application sous l'hypothèse artificielle d'une répartition uniforme. L'arithmétique utilise les minimums arrondis du projet et n'est pas une mesure de l'audience d'une application. La même personne peut utiliser plusieurs applications ou aucune, et une application peut attirer un groupe bien plus petit que la moyenne théorique. Rapporter le quotient comme « utilisateurs par application » serait une erreur numérique, pas une analyse originale. La conclusion significative est qu'aucun pont publié ne relie le pool d'utilisateurs rapporté à l'activité des applications.

Une meilleure méthode demanderait une exportation datée de l'inventaire de plus de 300 applications et étiquetterait chaque entrée par étape. Pour chacune, enregistrer si elle a une URL fonctionnelle, une authentification Pi, une approbation de portefeuille Mainnet, une adresse de paiement divulguée, des paiements PI complétés pendant une fenêtre spécifiée, et une mesure des utilisateurs distincts récurrents. Les opérateurs pourraient refuser de divulguer des informations privées sur les clients ; des décomptes agrégés et des transactions publiques pourraient encore permettre une vérification utile. L'exercice exposerait l'écart entre la portée possible et l'utilisation réelle du service sans supposer que toutes les applications sont identiques.

L'inventaire devrait indiquer si l'application est sélectionnée dans Pi Browser ou auto-hébergée via SoloHost. Pi dit que SoloHost permet aux développeurs de publier des applications d'IA auto-hébergées, et son annonce d'octobre regroupe ce produit avec sa plateforme de développement. Un service exécuté sur un nœud peut être une application au sens logiciel ordinaire sans être une application web avec un portefeuille de paiement Mainnet. Combiner ces catégories peut être défendable si Pi dit comment il les compte. D'ici là, un audit indépendant devrait préserver leurs statuts séparés.

Les règles d'annuaire de Pi offrent une autre vérification. Elles exigent des transactions Pi uniquement pour les applications cherchant la liste Mainnet pertinente, tandis que le projet a discuté séparément d'un rôle potentiel de stablecoin ailleurs dans son écosystème. La fonctionnalité OUSD a documenté qu'aucune intégration de paiement lancée ni mécanisme de demande de jeton n'avait été spécifié. Un futur changement dans les règles de listage des applications ou une exception étroite nécessiterait une mise à jour de politique datée. L'annonce du sommet elle-même ne révise pas la page d'annuaire actuelle ni ne fait d'OUSD une méthode de paiement d'application existante.

Cinq applications listées montrent ce que le décompte principal dissimule

Une mise à jour antérieure de Pi offre un petit exemple nommé de la façon dont le projet sélectionne les applications. Elle a annoncé cinq ajouts à l'interface de l'écosystème Mainnet, notamment un jeu de serpent, des applications de commerce électronique et des services d'information sur le jeton PI. Pi a déclaré que ces cinq applications avaient passé les contrôles de qualité, de fonctions complètes, d'utilité et de conformité aux politiques. L'exemple prouve que l'annuaire sélectionné peut admettre différents types de logiciels. Il ne révèle pas à quelle fréquence chacune a été ouverte ni combien quiconque y a dépensé.

Classer les cinq selon leur fonction déclarée est plus utile que de traiter leur inclusion comme un seul résultat économique. Un jeu peut enregistrer des sessions fréquentes mais peu de paiements. Un site d'information peut être lu sans aucun transfert de jetons. Une application de commerce peut afficher des commandes brutes, des commandes remboursées, des reçus marchands et des acheteurs récurrents. Même au sein du petit groupe, il n'existe pas de métrique unique qui transforme le nombre de cinq en demande de PI. L'exemple montre pourquoi l'inventaire plus large de plus de 300 nécessite des types d'applications avant qu'un nombre d'utilisation agrégé puisse être interprété.

Pi a explicitement averti dans cette mise à jour que sa liste Mainnet omettait de nombreuses applications tierces. Une application rejetée ou non soumise n'est pas nécessairement inutilisable. Le projet distingue la sélection dans l'annuaire de la disponibilité plus large, et les annuaires externes peuvent montrer plus de candidats. Un instantané indépendant du navigateur pourrait donc établir le nombre de tuiles visibles à une date donnée, mais ne peut pas confirmer le nombre total d'applications actives. Réconcilier les deux nécessiterait l'inventaire du portail développeur ou une méthodologie publiée par Pi.

La question de ce qui est considéré comme prêt pour le Mainnet complique encore un audit. Un développeur peut préparer un portefeuille et une URL en attendant l'approbation des paiements entrants ; une application peut exécuter un service qui ne nécessite aucun paiement. Le projet pourrait compter une configuration Mainnet fonctionnelle avant qu'un curateur ne la liste. Un champ de statut pour les approbations de paiement, le dernier accès réussi et le déploiement en production rendrait ces distinctions visibles sans publier les données privées des clients. Pi n'a pas fourni ce tableau champ par champ avec sa publication du sommet d'octobre.

Il y a une chronologie utile dans le matériel officiel. La sortie de l'App Studio en janvier a commencé avec les interactions de paiement Test-Pi. La mise à jour de mars a invité quatre créations sélectionnées vers la capacité de paiement Mainnet. La documentation développeur ultérieure a élargi ce que les constructeurs pouvaient faire avec le stockage local, le partage de fichiers et les données de staking spécifiques à l'application. L'annonce du sommet d'octobre présente plus de 300 applications Mainnet. Les points de terminaison décrivent des populations différentes, donc soustraire quatre de 300 ne calculerait pas le nombre de nouvelles applications payantes. Une chronologie claire préserve ce que chaque chiffre comptait au moment de sa publication.

Une couverture antérieure de la première année de réseau ouvert de Pi décrivait App Studio parmi les principaux produits publics du projet. La revendication d'octobre concerne un inventaire ultérieur. Toute comparaison avec la première année doit utiliser la même définition d'application et éviter d'importer un total plus ancien de KYC ou de migration dans le présent. Une rétrospective peut établir quand une fonctionnalité est apparue ; elle ne comble pas la série manquante d'utilisateurs actifs d'octobre.

Le meilleur argument pour Pi concerne un public prêt

Pi a assemblé des vérifications d'identité, des portefeuilles, un chemin de découverte basé sur navigateur, des outils de paiement d'application et une large base de participants revendiquée. Un développeur qui construit un produit utile peut potentiellement le distribuer via les canaux existants au lieu d'acquérir chaque utilisateur indépendamment. Plus de 300 applications Mainnet signalées peuvent signifier que de nombreuses équipes ont déjà fait le travail de préparation de logiciels de réseau en direct. Le sommet promet de montrer leurs produits et de publier des outils supplémentaires. Aucun de ces faits ne devrait être effacé simplement parce que les chiffres publics de rétention sont absents.

L'argument sceptique est tout aussi concret. La distribution ne force pas un utilisateur à revenir à une application. Le KYC vérifie l'identité d'un titulaire de compte selon le processus du projet ; il ne montre pas que cette personne a du PI discrétionnaire, a besoin d'un produit donné, ou effectue un achat. Les classements d'annuaires peuvent refléter le staking pour la promotion. Les outils de création d'applications peuvent augmenter les comptes d'expériences plus rapidement que les comptes d'entreprises avec des clients récurrents. Ce sont des raisons de demander des enregistrements d'utilisation, pas des raisons de supposer que les applications ont échoué.

Une couverture antérieure de l'économie d'App Studio examinait les coûts supportés par les créateurs et soulignait que les soumissions de hackathon ne sont pas la même chose que les produits actifs. Le sommet actuel introduit un autre hackathon et plus de fonctionnalités développeur. Un décompte des soumissions après l'événement mesurerait la participation à ce concours. La part atteignant plus tard le Mainnet, restant en ligne et recevant des utilisateurs récurrents mesurerait un résultat plus exigeant.

Un opérateur pourrait rendre l'argument positif mesurable en publiant un rapport de cohorte. Identifiez les applications listées avant une date choisie, puis divulguez combien fonctionnent encore 30 et 90 jours plus tard et combien ont des utilisateurs distincts qui reviennent ou paient. Un rapport comparable un trimestre plus tard révélerait si les nouveaux outils développeur aident les applications à retenir les utilisateurs, pas seulement à se lancer. Pi n'a pas promis un tel rapport pour novembre. L'absence de promesse doit être énoncée clairement, sans convertir une demande de rapport en un livrable annoncé.

L'observation indépendante comporte des limites pratiques. Pi Browser peut exiger un compte, un KYC ou des autorisations d'application. Les étiquettes de portefeuille ne sont pas toujours publiques. Un explorateur de blocs peut montrer des transactions sans montrer pourquoi elles ont eu lieu. Un journaliste extérieur peut vérifier des applications nommées, des contrats publics et des transactions d'exemple, mais ne peut pas déduire chaque session utilisateur privée à partir d'une chaîne. Un audit complet peut donc rester partiellement dépendant des divulgations des développeurs et du projet. La séparation la plus importante est entre ce qui a été reproduit indépendamment et ce que Pi ou une équipe d'application a rapporté.

Un échantillon d'audit possible pourrait commencer par les cinq applications que le projet lui-même a nommées dans sa mise à jour précédente. Un journaliste enregistrerait si chaque URL se charge maintenant, si la connexion fonctionne, si la fonction offerte peut être accomplie et si un paiement est demandé. Une deuxième passe après 30 jours vérifierait si les mêmes fonctions fonctionnent toujours. Ce serait un test direct de disponibilité pour cinq applications nommées, et non une estimation pour les 300. Élargir l'échantillon nécessite un cadre d'échantillonnage complet, que le post du sommet ne fournit pas.

Pour une application revendiquant des ventes, l'opérateur pourrait divulguer une adresse de portefeuille et une période pendant laquelle elle a été utilisée exclusivement pour des reçus de production. Un journaliste pourrait alors calculer les expéditeurs distincts et le total de PI reçu à partir du registre, tout en précisant que les dépôts sur les exchanges, les transferts de développeurs et les remboursements peuvent encore fausser ces comptages. Un transfert bancaire ou d'exchange ne peut pas être attribué à un achat client sans preuve supplémentaire. Pour un service gratuit, l'opérateur pourrait divulguer des agrégats d'utilisateurs actifs et de rétention préservant la vie privée. Différentes méthodes, honnêtement étiquetées, sont préférables à un seul score d'« adoption » non étayé.

Le modèle économique de l'application détermine également si le PI est impliqué du tout. Les outils de développement de Pi offrent la connexion, la découverte et les paiements comme des capacités séparables. Un créateur peut utiliser les deux premières sans la troisième. L'affirmation « plus de 300 applications » pourrait être entièrement exacte alors qu'un sous-ensemble seulement dispose d'un portefeuille de paiement approuvé pour des transferts réels. L'invitation de Pi en mars à quatre créations App Studio démontre un chemin d'approbation plus étroit pour une catégorie, mais ne dit rien de concluant sur le nombre d'applications codées indépendamment qui acceptent des paiements aujourd'hui.

Novembre peut révéler des produits, mais pas des années de rétention

L'événement du 17 au 19 novembre est programmé comme un sommet en ligne, et non comme une date à laquelle chaque fonctionnalité annoncée est garantie d'entrer en production. Pi dit qu'il fournira des mises à jour de plateforme, des démonstrations de développeurs, des vitrines de partenaires et d'applications, et plus d'informations sur un hackathon. Une présentation peut démontrer un outil fonctionnant dans un cadre contrôlé. Un outil déployé et une application l'utilisant avec des clients sont des étapes ultérieures, vérifiables séparément.

Si une application nommée publie une adresse de portefeuille de production et montre une transaction qu'un lecteur peut reproduire, l'article peut établir une capacité particulière. Si elle publie un mois de données distinctes de portefeuilles payants avec remboursements et tests exclus, l'article peut discuter de l'utilisation. Si elle n'offre qu'une démonstration vidéo, l'article devrait l'appeler une démo. Ces classifications relèvent du reportage produit ordinaire, et non d'une norme spéciale imposée à Pi.

L'annonce du projet ne rapporte pas de date de lancement commune pour les plus de 300 applications, leur disponibilité ou la part acceptant les paiements PI. Elle nomme les dates du sommet et les sujets qu'il entend couvrir. Le prochain ordre du jour publié et les applications spécifiques sélectionnées pour les démonstrations sont les documents immédiats qui peuvent réduire l'écart entre l'affirmation des 300 applications et l'utilisation observable.

Quoi surveiller

• Inventaire des applications : Une liste Pi datée définissant quelles applications composent le total déclaré de plus de 300.
• Statut de production : Applications nommées avec des URL Mainnet fonctionnelles, des portefeuilles approuvés et des transactions en direct reproductibles.
• Utilisation répétée : Divulgations par les développeurs ou le réseau d'utilisateurs distincts revenant sur une période spécifiée de 30 ou 90 jours.
• Paiements : Achats en PI complétés, séparés des actions Testnet, incitations, remboursements et transferts internes.
• Annonces du sommet : L'ordre du jour du 17 au 19 novembre, les outils déployés et les règles du hackathon, chacun avec un statut daté.

FAQ