Le domaine d'AlgoExplorer ne résout plus, laissant Lora, Allo et Pera couvrir Algorand

La fenêtre qui s'est refermée

La vitrine publique la plus utilisée d'Algorand sur sa propre chaîne ne répond plus. Le domaine algoexplorer.io échoue à la résolution DNS, et l'Internet Archive n'en conserve rien après mai 2024 ; l'explorateur communautaire plus modeste Blockpack (blockpack.app) a lui aussi disparu, sans capture d'archive après mars 2025. Ni l'un ni l'autre n'est présenté ici comme un service en activité. À l'arrêt d'AlgoExplorer, développeurs, auditeurs et simples utilisateurs ont perdu le moyen par défaut de vérifier une transaction, de consulter le solde d'un compte ou de déboguer un smart contract — et aucun remplaçant unique ne s'est imposé. Ce sont désormais quatre explorateurs aux tempéraments différents qui se partagent la tâche, sur une infrastructure d'API gratuite sur laquelle une bonne partie de l'écosystème s'appuie elle aussi.

Les explorateurs de 2026

Lora¹, l'explorateur open source maintenu par la Algorand Foundation² dans le cadre de sa boîte à outils pour développeurs AlgoKit³, fait office d'option officielle par défaut. Allo.info⁴, développé par Nodely⁵ (ex-AlgoNode), est la déclinaison orientée analyse. Pera Explorer⁶ vient de l'équipe derrière le Pera Wallet. AlgoGazer⁷ est un projet communautaire pensé pour le mobile, lancé en 2025.

La position de Pera porte un conflit qu'il vaut la peine de nommer : l'explorateur est exploité par la même entreprise que le portefeuille, ses badges « vérifié » et « suspect » relèvent de son propre jugement — les conditions du programme de vérification précisent qu'il ne s'agit pas d'une approbation — et son interface privilégie naturellement les parcours Pera Wallet, y compris les invites de téléchargement et les inscriptions d'actifs conçues pour sa propre application. Les utilisateurs d'autres portefeuilles ont tout intérêt à considérer les paramètres on-chain bruts visibles sur Lora ou Allo comme la référence neutre.

Une vérification en direct de Lora le 11 août 2026 l'a montré affichant l'état courant du mainnet, avec des blocs arrivant toutes les trois secondes environ et des frais de transaction de 0.001⁸ ALGO. Le projet est activement maintenu, avec un commit le 7 août 2026 et une version v2.4.0-beta.2 publiée le 21 mai 2026 sur GitHub⁹.

Le problème de métadonnées sur lequel Lora travaille

Un Algorand Standard Asset (ASA) — un jeton émis directement sur la couche de base, d'un stablecoin à un NFT — n'inscrit sur le registre qu'un nom, un nom d'unité, une offre totale, des décimales et une URL. Tout ce qui rend un jeton lisible pour un acheteur, son image, sa description et ses attributs, n'a jamais eu de foyer dédié on-chain. L'écosystème a improvisé, à travers trois générations de métadonnées hors chaîne, chacune avec son défaut propre :

La version 2.4.0-beta.1, publiée le 14 avril 2026, a ajouté la « prise en charge arc-89 » : Lora peut désormais lire les métadonnées d'un actif depuis un registre interne à Algorand, plutôt que d'assembler des fichiers hors chaîne. La spécification¹⁰ ARC-89 décrit sans détour l'état antérieur — l'absence de stockage natif des métadonnées a poussé l'écosystème à adopter des « solutions loin d'être idéales », notamment en « bricolant les rôles RBAC de l'ASA pour obtenir la mutabilité des métadonnées d'actif ». Restait à savoir, au moment de la rédaction de la bêta, si ce registre atteindrait le MainNet, et les téléchargements du SDK associé demeurent modestes, à 65 par mois lorsque la version a été documentée.

D'où viennent les données : Nodely

Une grande partie de ces outils repose sur Nodely, le fournisseur d'infrastructure né d'AlgoNode, qui exploite toujours les points de terminaison Algorand gratuits les plus connus (mainnet-api.algonode.cloud et testnet-api.algonode.cloud). Ses propres chiffres, à jour sur la page d'accueil de 2026 : plus de 115M+ requêtes API par jour réparties sur plus de 20+ zones géographiques, plus de 75+ indexeurs au service de ces requêtes, plus de 75+ clients et plus de 5+ chaînes compatibles AVM prises en charge. L'offre gratuite ne demande aucune clé API, propose 60 requêtes par seconde et par navigateur sur la page d'accueil actuelle (l'ancienne page de documentation en indique 50), un quota front-end de 6M requêtes ou 150GB par mois, une passerelle IPFS et un objectif de niveau de service de 99.95%. Les offres payantes montent en puissance à partir de là.

Deux points invitent au scepticisme. D'abord, les chiffres de SLO sont des engagements de Nodely lui-même, renvoyant à ses pages de statut plutôt qu'à un audit indépendant. Ensuite, l'offre gratuite est un produit d'appel plafonné par des quotas : la page d'accueil la présente comme un moyen de démarrer gratuitement puis de migrer vers l'auto-hébergement ou une offre payante une fois le projet rentable, et une demande qui franchit régulièrement les plafonds se heurte à une limitation HTTP 429. La protection structurelle contre l'enfermement, elle, est bien réelle : le service de base de Nodely s'appuie, selon ses propres termes, sur des « API de nœud et d'indexeur OSS vanilla », si bien qu'un projet peut pointer le même code client vers son propre nœud sans rien réécrire.

algod vs indexeur : ce qu'un explorateur interroge vraiment

Les explorateurs ne sont que des interfaces pour deux services distincts. Algod est l'API REST du démon de nœud — la source de vérité en direct sur l'état courant (dernier round, soldes des comptes, paramètres des actifs) et le point de terminaison par lequel les transactions sont soumises au réseau. L'indexeur est un service séparé qui catalogue tout l'historique de la chaîne dans une base de données interrogeable, ce qui alimente l'historique des comptes, les journaux de transferts d'actifs et les pages d'activité. Un développeur peut faire tourner les deux en local via AlgoKit LocalNet — algokit localnet start démarre un bac à sable privé sous Docker, avec algod sur localhost:4001 et l'indexeur sur localhost:8980 — ou s'appuyer sur les versions hébergées de Nodely.

Des fonds de test, désormais encadrés

Pour développer sur TestNet, il faut des ALGO de test qui ne coûtent rien. Lora Fund¹¹, qui répond aussi à l'ancienne adresse bank.testnet.algorand.network, est le faucet actuel, et il est délibérément moins ouvert qu'auparavant. L'avertissement de la page est explicite : « Pour aider à protéger ce réseau, nous imposons des limites de fonds quotidiennes. Veuillez vous connecter pour alimenter votre compte. » Connecter un portefeuille lie chaque demande à une identité on-chain plutôt qu'à une adresse IP anonyme, ce qui bloque les vecteurs d'abus scriptés les moins coûteux.

Le compromis, c'est un déficit de transparence. Le chiffre exact du plafond n'est pas imprimé sur la page du faucet ; la vidéo explicative de l'Algorand Foundation elle-même évoque 10 ALGO de test par jour, mais le développeur qui consulte la page ne voit que l'avertissement générique. La limite est toutefois lisible par machine : l'API AlgoKit Dispenser¹² (api.dispenser.algorandfoundation.tools) expose un point de terminaison qui renvoie la limite quotidienne en vigueur, et les demandes dépassant le plafond reviennent avec une erreur fund_limit_exceeded qui inclut la limite et l'horodatage de réinitialisation. Les remboursements sont pris en charge, et les limites se réinitialisent chaque jour à minuit UTC. Un développeur qui atteint le plafond sans décortiquer l'erreur JSON peut légitimement conclure que le faucet est cassé — un problème de documentation pour une conception anti-abus par ailleurs sensée.

L'interface en ligne de commande d'AlgoKit enveloppe le même service (algokit dispenser fund --receiver <address> --amount <microAlgos>), y compris un mode CI dont le jeton d'accès est délivré pour 30 jours, afin que les pipelines de tests automatisés puissent alimenter des adresses pendant les builds. Pour les développeurs qui ne veulent aucune chaîne publique, LocalNet est un bac à sable éphémère : il embarque 30,000 clés de participation pré-générées et est conçu pour être réinitialisé, si bien que tout ce qu'il contient est jetable. FNet, un devnet temporaire destiné à tester le prochain protocole d'incitation par blocs, peut lui aussi être réinitialisé, et chaque nouvelle instance porte un hash de genèse distinct ; son site actuel renvoie une erreur SSL, sa documentation restant consultable via la Wayback Machine — une réserve pour quiconque s'y fierait aujourd'hui.

Vérifier un jeton soi-même

Un parcours concret sur Lora : ouvrir la page de l'USDC (ID ASA 31566704¹³¹⁴ sur MainNet). La vue de l'actif affiche l'offre totale, six décimales, le champ URL pointant vers centre.io et — surtout — les quatre rôles administratifs qu'un créateur d'ASA peut attribuer. L'émetteur d'USDC sur le mainnet a défini une adresse Manager et une adresse Freeze, une adresse Reserve identique au créateur, et aucune Clawback. Chaque rôle compte : un Manager peut reconfigurer l'actif et modifier les autres rôles, une adresse Freeze peut geler les jetons détenus par un compte précis, et une adresse Clawback peut reprendre des jetons. Que l'un de ces rôles soit défini est un fait concernant le contrôle de l'émetteur, non un verdict sur le jeton — mais c'est précisément le fait qu'un acheteur devrait vérifier avant de se fier à un ASA inconnu. L'historique des transactions situé sous les paramètres de l'actif liste les transferts en direct avec leurs frais, chacun renvoyant à une vue complète de la transaction avec expéditeur, destinataire, montant, horodatage et bloc.

Cette dernière page résume tout l'intérêt de l'exercice. Algorand finalisant chaque bloc en moins de trois secondes et sans fork, une transaction affichée dans un bloc est définitive — aucune confirmation probabiliste n'est à attendre, ce qui fait du travail de l'explorateur une affaire de visibilité plutôt que d'interprétation. La fenêtre qu'offrait AlgoExplorer s'est refermée ; ce qui la remplace, c'est un ensemble d'outils plus restreint, une couche d'API gratuite mais plafonnée par des quotas, et un faucet qui vous demande de vous identifier avant de distribuer de la monnaie de test.