Request

Qu’est-ce que Request ?

Request est un protocole open source de demande de paiement en crypto et de rapprochement qui permet à une entreprise ou à un utilisateur de créer une demande de paiement signée de type facture, de stocker les données de cette demande dans une infrastructure décentralisée, et de faire correspondre les paiements on-chain ultérieurs à cette demande sans confier la garde des fonds à un processeur de paiement. Son problème central n’est pas de « déplacer des tokens » de manière abstraite, ce que de nombreux portefeuilles et passerelles de paiement font déjà, mais de créer un objet comptable vérifiable autour du paiement : qui l’a demandé, quel montant était dû, quelle devise ou unité de compte a été utilisée, où le règlement a eu lieu, et si le paiement peut être détecté et rapproché automatiquement.

L’avantage pratique du protocole réside donc davantage dans l’intégration aux flux de travail que dans le consensus de couche de base : Request combine des demandes de paiement signées, le stockage IPFS, l’ancrage on-chain de CIDs, des événements de référence de paiement, des webhooks, des outils d’API et un routage de paiements multi‑chaînes pour en faire un élément de base du back‑office financier, comme décrit dans la documentation de Request Network et son aperçu du protocole. docs.request.network

Request n’est pas une blockchain de couche 1 dominante, ni un rollup, ni un grand protocole DeFi de marché monétaire ; c’est une couche applicative spécialisée dans les paiements et les outils pour développeurs, construite autour de la facturation en crypto, de la détection de paiements et du rapprochement.

Fin mai 2026, les fournisseurs de données de marché classaient REQ parmi les tokens de petite à moyenne capitalisation plutôt que parmi les crypto‑actifs systémiques : CoinMarketCap plaçait Request aux environs du rang #384, tandis que CoinGecko et DeFiLlama affichaient des chiffres de capitalisation boursière sensiblement différents en raison de méthodologies et de calendriers divergents pour l’offre en circulation. Pour ce type de protocole, la TVL est un indicateur limité : la Request Network page de DeFiLlama présente des données sur la trésorerie et le marché du token plutôt qu’une TVL classique de prêt/AMM, ce qui est cohérent avec le rôle de Request en tant qu’infrastructure de paiement plutôt qu’en tant que pool de dépôts utilisateurs. Ses indicateurs d’échelle les plus pertinents sont le volume de paiements et l’activité des entreprises traitée ; le site de la fondation revendique plus de 2 milliards de dollars de volume traité et une large couverture de stablecoins, tandis que le Request Activity Dashboard géré par la communauté suit les paiements quotidiens et le volume de paiements, mais ne fournit pas de cohorte DAU/MAU propre comparable à celle des portefeuilles grand public ou des plateformes d’échange. (coinmarketcap.com)

Qui a fondé Request et quand ?

Request a été fondé en 2017 par Christophe Lassuyt et Étienne Tatur, tous deux associés au projet fintech antérieur MONEYTIS ; Y Combinator répertorie Request Network comme une entreprise Winter 2017 basée à Paris, avec Lassuyt comme Founder/CFO et Tatur comme Founder/CTO. Le contexte de lancement est important : REQ est apparu pendant le cycle d’ICO de 2017, lorsque de nombreux projets tentaient d’étendre Ethereum au‑delà des simples transferts de tokens vers la comptabilité, le commerce et l’automatisation des processus métier. Les bases de données historiques d’ICO situent la vente de tokens en octobre 2017, avec une offre initiale d’environ un milliard de REQ, bien que l’offre actuelle soit plus faible après des brûlages et des ajustements comptables des tokens. Cette « cuvée » constitue à la fois un avantage et un fardeau : Request a survécu à plusieurs cycles de marché et conserve un logiciel opérationnel, mais il porte aussi le poids réputationnel commun aux projets de tokens utilitaires de 2017 dont les premiers récits dépassaient souvent l’adoption à court terme. (ycombinator.com)

Le récit du projet s’est resserré au fil du temps.

Le cadrage initial décrivait un vaste réseau de paiement décentralisé pour les factures, les pistes d’audit, la conformité au droit commercial et les demandes de paiement globales ; l’accent produit actuel est plus opérationnel et moins idéologique, centré sur les paiements crypto via API, la facturation on-chain, la détection de paiements, le routage cross‑chain, les paiements par lots, les paiements récurrents et le rapprochement.

Cette évolution est visible dans les mises à jour 2025 de la fondation : Request a publié l’API V2, les paiements partiels, des webhooks améliorés, des workflows crypto‑vers‑fiat, des paiements par lots et des fonctionnalités de paiement cross‑chain plutôt que de chercher à devenir une nouvelle blockchain généraliste. Sur le plan institutionnel, le pivot va de « PayPal sur blockchain » vers une couche middleware pour les équipes financières, les prestataires de services de paiement et les entreprises crypto‑natives qui ont besoin d’enregistrements de paiement structurés sur plusieurs blockchains. request.network

Comment fonctionne Request Network ?

Request ne dispose pas de son propre mécanisme de consensus de type proof‑of‑work, proof‑of‑stake, DAG, ensemble de validateurs, séquenceur ou rollup. Il s’agit d’un protocole hybride off‑chain/on‑chain qui conserve la majeure partie du contenu des demandes sur IPFS, ancre l’identifiant de contenu IPFS on-chain et traite les paiements via des smart contracts sur les chaînes de règlement prises en charge.

La documentation indique que les demandes sont créées en stockant des CIDs sur Gnosis Chain, tandis que les paiements peuvent avoir lieu sur plus de 20 chaînes compatibles EVM ou sur NEAR ; le solde de la demande est alors calculé en indexant les événements de paiement on-chain associés à une référence de paiement dérivée. En termes techniques, Request est un protocole de couche applicative et une API pour développeurs qui hérite de la vivacité et de la finalité de réseaux externes tels que Gnosis, Ethereum, Base, Arbitrum, Optimism, Polygon et d’autres, plutôt que de fournir son propre budget de sécurité de couche de base. docs.request.network

Le mécanisme distinctif du protocole est la référence de paiement. Dans le modèle recommandé basé sur la référence, un identifiant unique dérivé des données de la demande lie un paiement sur blockchain à la facture ou à la demande de paiement sous‑jacente ; des contrats proxy transfèrent les fonds au destinataire et émettent des événements contenant le montant du paiement et la référence, tandis que des sous‑graphes indexent ces événements pour un rapprochement ultérieur.

Le système n’utilise pas le sharding ni les ZK‑rollups comme primitives de scalabilité natives, et son modèle de vérification se rapproche davantage d’un règlement indexé par événements assorti de métadonnées de demande signées que de la vérification cryptographique de preuves de rollup. Les Request Nodes fournissent une passerelle entre IPFS, les smart contracts et The Graph ; la fondation exploite des nœuds pour faciliter le travail des développeurs, mais recommande aux équipes en production d’exploiter leur propre nœud, ce qui est important car la dépendance à l’égard des passerelles et API hébergées par la fondation constitue un vecteur de centralisation même si les données de demande et les contrats sous‑jacents sont open source.

Les demandes privées ajoutent un chiffrement asymétrique et AES : le contenu de la demande est chiffré avec une clé AES, et cette clé est chiffrée pour la clé publique de chaque partie prenante avant d’être conservée sur IPFS. docs.request.network

Quelle est la tokenomique de req ?

REQ est un token ERC‑20 lancé à l’origine avec environ un milliard d’unités, et son profil d’offre s’apparente davantage à une offre principalement fixe avec un mécanisme de brûlage modéré qu’à un actif inflationniste à émissions continues. Fin mai 2026, Etherscan référençait le contrat du token ERC‑20 à l’adresse 0x8f8221afbb33998d8584a2b05749ba73c37a938a avec une offre maximale totale d’environ 999,416 millions de REQ, tandis que CoinMarketCap indiquait une offre en circulation d’environ 796,7 millions de REQ et que CoinGecko affichait une autre valeur d’offre en circulation, ce qui souligne que l’offre « en circulation » dépend de la manière dont les réserves, les ponts et les soldes inactifs sont classés.

Le tableau de bord communautaire signalait environ 583 000 REQ brûlés, soit une petite fraction de l’offre initiale ; l’effet déflationniste existe donc, mais il n’est pas suffisamment important en soi pour constituer la thèse d’investissement centrale. (etherscan.io)

La captation de valeur de REQ est indirecte et doit être abordée avec prudence.

La documentation identifie des contrats de token REQ et de mécanisme de brûlage qui peuvent verrouiller, ponter et brûler des REQ lorsque des demandes sont stockées, tandis que la documentation de l’API décrit des frais de protocole de 5 points de base sur les paiements traités via l’API, plafonnés autour de 25 $ ou 25 € pour les principaux stablecoins adossés au dollar et à l’euro.

Ces éléments ne correspondent pas à un rendement de staking PoS classique, et la sécurité de Request n’est pas assurée par le staking de REQ comme Ethereum l’est par les validateurs ETH. Certaines descriptions tierces présentent l’utilité de REQ en termes d’anti‑spam, de gouvernance, de staking, de remises et d’indépendance, mais la documentation technique officielle actuelle ne décrit pas un vaste marché de staking liquide, ni un calendrier de récompenses pour validateurs, ni un programme récurrent d’émissions pour les détenteurs de REQ.

L’interprétation la plus défendable de la tokenomique est donc que REQ est un token hérité de type utilitaire/gouvernance avec une offre plafonnée et des éléments de brûlage liés à l’usage, tandis que la plupart de l’utilisation du protocole à court terme se répercute plus directement sur la couche produit et les services d’API opérés par la fondation que automatiquement sur les détenteurs passifs du token. docs.request.network

Qui utilise Request ?

La différence entre la spéculation sur REQ et l’utilité réelle de Request Network est significative. Le volume de tokens sur les plateformes d’échange reflète la liquidité du marché et la rotation des investisseurs, tandis que l’usage du protocole se mesure mieux par les demandes créées, les paiements détectés, le volume de paiements, l’adoption de l’API et l’intégration dans les flux de travail financiers.

La mise à jour écosystème de Request de mai 2025 a explicitement déplacé l’accent de son reporting, passant des comptes de transactions génériques au « nombre de paiements », parce que la création, l’approbation, le rejet de factures et d’autres actions peuvent gonfler les métriques de transactions sans refléter une activité réelle de règlement.

Le tableau de bord communautaire indique également le volume de paiements et le nombre de paiements sur les chaînes prises en charge, mais il s’agit d’indicateurs quotidiens volatils qui ne doivent pas être interprétés comme des chiffres stables d’utilisateurs actifs. Sectoriellement, Request se situe à l’intersection des paiements en crypto, du règlement en stablecoins, de la facturation, de la paie, de la comptabilité et des opérations de trésorerie plutôt que de la liquidité DeFi, du gaming ou de la spéculation NFT. request.network

La preuve d’adoption la plus solide réside dans les intégrations avec des produits identifiables de finance ou d’opérations crypto, et non dans des comptes anonymes de portefeuilles. Request’s Les mises à jour de l’écosystème 2025 ont désigné comme “active builders” Animal Social Club, intrXn, 0 Finance, Allora et Request Finance, tandis que des mises à jour antérieures mentionnaient également Huma Finance, BSOS, Joba Network et d’autres participants de l’écosystème.

En octobre 2025, Kryptos a annoncé avoir intégré l’API Request Network pour alimenter la facturation au sein de Kryptos Enterprise, Request fournissant la création de factures, le règlement on-chain, les webhooks d’événements et la réconciliation. Cette annonce citait également l’instantané d’adoption propre à Kryptos, avec plus de 200 000 utilisateurs enregistrés, plus de 50 entreprises Web3 intégrées lors des premières phases, et des milliers d’intégrations de portefeuilles, CEX, DeFi et de chaînes. Ces chiffres doivent être interprétés comme une mesure de l’échelle de la plateforme partenaire plutôt que comme une adoption directe par les détenteurs de REQ, mais ils restent plus substantiels que des rumeurs de partenariats non sourcées. request.network

Quels sont les risques et défis pour Request ?

Le risque réglementaire pour Request est plus subtil que pour une bourse, un protocole de prêt ou un mixer de confidentialité, mais il n’est pas nul. Les recherches publiques et le texte des plaintes de la SEC disponibles via les résultats de recherche n’ont pas montré REQ comme un token nommé dans les principales plaintes de 2023 de la SEC contre Coinbase ou Binance, et il n’existe pas, à la fin mai 2026, de procès actif largement rapporté visant spécifiquement Request Network.

Cela ne constitue pas un “safe harbor” réglementaire. REQ a été vendu durant l’ère des ICO de 2017, il se négocie sur les marchés secondaires, et les régulateurs américains ont historiquement scruté les tokens distribués pour financer le développement de protocoles.

L’activité de paiements du protocole touche également aux questions de LBC (AML), de filtrage des sanctions, de KYC, de réglementation des stablecoins, de transmission de fonds et de déclaration fiscale, en particulier là où Request prend en charge les règlements crypto-vers-fiat, le filtrage des portefeuilles et la facturation des entreprises. Le risque de centralisation est également pratique plutôt que théorique : l’API, le tableau de bord, la page de paiement sécurisée, les Request Nodes et l’infrastructure de détection des paiements, tous opérés par la fondation, peuvent créer une dépendance opérationnelle même si les contrats, le SDK et le modèle de données restent open source. sec.gov

La concurrence est intense car le problème côté utilisateur de Request peut être attaqué sous plusieurs angles. Les processeurs de paiement traditionnels ajoutent le règlement en stablecoins ; les processeurs de paiement crypto centralisés peuvent offrir conformité, politique de rétrofacturation, rampes de sortie fiat et tableaux de bord marchands ; les portefeuilles et les bourses peuvent ajouter directement des liens de paiement ; et les fournisseurs de comptabilité crypto pour entreprises peuvent intégrer la réconciliation des factures dans leurs propres piles. Au sein du Web3, des produits de type Safe ou Coinbase Commerce, des outils de trésorerie multisig, des plateformes de paie, des prestataires de paiement en stablecoins, des tableaux de bord de comptabilité on-chain et des API de routage cross-chain peuvent chacun absorber des parties du flux de travail de Request.

La menace économique est que les 5 points de base de frais de Request et le lien avec le burn de REQ puissent être comprimés si le routage de paiement et la réconciliation deviennent des fonctionnalités d’API banalisées. Sa défensibilité dépend du fait que les développeurs considèrent l’objet de facture de Request, le standard de référence de paiement et les outils de réconciliation comme une couche d’intégration durable plutôt qu’un simple “wrapper” pratique et remplaçable. docs.request.network

Quelles sont les perspectives d’avenir pour Request ?

La feuille de route de Request à court terme semble axée sur la profondeur produit plutôt que sur la réinvention de la couche de consensus. La documentation vérifiée de 2025 et début 2026 met en avant la migration vers l’API V2, les paiements en stablecoins cross-chain, les paiements par lots, les paiements partiels, les workflows crypto-vers-fiat, les paiements récurrents, la personnalisation des frais, les améliorations du changement de portefeuille et de réseau, un suivi des paiements plus large, et la prise en charge de plus de 25 chaînes via la surface d’API. Les paiements cross-chain sont particulièrement importants car ils répondent à une vraie douleur opérationnelle : les payeurs peuvent détenir de l’USDT sur Optimism tandis que les factures demandent de l’USDC sur Base, et les équipes financières ne veulent pas gérer manuellement bridges, swaps, tokens de gas et réconciliation.

La documentation de Request indique que les paiements cross-chain prennent en charge USDC (USDC), USDT (USDT) et DAI (DAI) sur Ethereum (ETH), Arbitrum One (ARB), Base et OP Mainnet (OP), avec des routes classées selon les frais de transaction et la vitesse de traitement ; la page publique du produit cross-chain indique que Request utilise le routage LI.FI tout en conservant une logique unifiée de détection de paiement et de webhooks. request.network

L’obstacle structurel est la densité d’adoption. Request n’a pas besoin de battre Ethereum, Visa, Stripe ou chaque processeur de stablecoins de manière générale ; il lui faut suffisamment d’applications métiers, de produits de comptabilité, de PSP et d’équipes financières crypto-native standardisant leur usage autour de sa couche de demande et de réconciliation. Le scénario baissier est que les paiements en stablecoins soient intégrés directement dans les portefeuilles, les banques et les API des bourses, laissant Request comme un petit outil développeur avec une capture de valeur limitée pour le token.

Le scénario haussier est plus mesuré qu’un simple récit de prix : si le règlement en stablecoins continue de s’étendre et que les équipes financières ont besoin d’enregistrements de paiements auditables, non-custodiaux et multi-chaînes, la combinaison par Request de demandes signées, de références de paiement, de webhooks, de flux par lots, de paiements récurrents et de routage cross-chain pourrait rester une infrastructure viable.

L’avenir du projet dépend donc moins de la demande spéculative pour REQ que de la capacité de Request à convertir sa longue histoire opérationnelle en intégrations durables, en métriques d’utilisation transparentes et en un modèle de token dont le lien économique avec les paiements réels soit suffisamment clair pour que les utilisateurs institutionnels et les détenteurs de tokens puissent l’évaluer et le souscrire.