Les audits d'IA publiés par Biatec Wallet ont révélé un problème critique de signature d'échange.
Un traçage d'audit écrit par des machines
En mai 2021, le projet désormais appelé Biatec Wallet a lancé sa première version publique : créer un portefeuille, le sécuriser par un mot de passe, consulter les informations de base du compte — le tout dans un onglet de navigateur. Cinq ans plus tard, la même base de code, rebaptisée et développée sous la marque Biatec, fonctionne toujours entièrement dans le navigateur, et a adopté une pratique inhabituelle pour un portefeuille communautaire de petite taille : elle publie des rapports d'audit de sécurité datés, rédigés par des modèles d'IA, directement dans son répositoire public GitHub, accompagnés d'un registre en cours d'élaboration de tous les risques identifiés par ces audits.
Le rapport le plus récent, daté du 4 août, s'ouvre par un avertissement que la plupart des projets préféreraient enterrer : « Le résultat principal est négatif : cette vérification met en évidence un problème critique et un problème majeur, qui constituent des voies réalistes menant à la perte totale des fonds d'un compte. » Les deux problèmes concernent la fonctionnalité d'échange — l'unique endroit du portefeuille où la clé privée de l'utilisateur est brièvement exposée à la sortie d'un serveur distant — et la manière dont ils ont été détectés et corrigés est un bon indicateur de ce que ce type de programme d'audit auto-publié peut et ne peut pas garantir.
Un porte-monnaie qui ne touche jamais vos clés
Biatec Wallet est un portefeuille Algorand gratuit, open source et non-custodial créé par Scholtz & Company, jsa. de Bratislava, en Slovaquie (ID de l'entreprise 51 882 272, TVA SK2120828105) et développé sous la marque Biatec. Le non-custodial signifie qu'aucune tierce partie n'a jamais la possession des clés privées : il n'y a pas de serveur de back-end, aucun formulaire d'inscription et aucun KYC, et le fichier du portefeuille est chiffré avec AES-256 et stocké dans le IndexedDB du navigateur. Le mot de passe est utilisé uniquement localement pour chiffrer et déchiffrer — il n'est jamais transmis à aucun endroit, y compris à l'infrastructure de Biatec — et le portefeuille se verrouille cinq minutes après la dernière activité, effaçant la clé déchiffrée de la mémoire. Le projet se décrit comme le premier portefeuille Algorand open source ; les reportages indiquent que le portefeuille officiel d'Algorand n'est devenu entièrement open source qu'en juin 2021, un mois après la première version publique d'AWallet.
Pour l'essayer, il suffit d'ouvrir un navigateur et de choisir un mot de passe : ouvrez wallet.biatec.io — le README du projet indique que l'ancien domaine a-wallet.net est un miroir obsolète de la même implémentation — choisissez un nom de portefeuille et un mot de passe (l'application recommande douze caractères ou plus, mêlant majuscules, minuscules, chiffres et caractères spéciaux), et le fichier de portefeuille est créé localement. L'application fonctionne par défaut sur mainnet, pointant vers les nœuds publics d'AlgoNode, avec des paramètres pour basculer entre les fournisseurs — y compris le nœud Algorand de Biatec et son infrastructure d'indexer](/glossary/indexer "Un service qui organise et indexe les données de la blockchain afin que les applications puissent rapidement rechercher et récupérer des informations à partir de la blockchain.").
Comment le programme d'audit fonctionne
Le processus est codifié dans un fichier appelé ai-audit-instructions.md : saisir « do new audit » dans le dépôt déclenche un nouveau passage d’un modèle d’IA, qui doit agir comme le ferait « une société professionnelle d’audit de contrats intelligents ou de sécurité de portefeuilles » : avec scepticisme, esprit d’adversaire et précision quant à la gravité, chaque constatation étant liée à des chemins de fichiers et à des numéros de lignes spécifiques. Chaque rapport enregistre la validation de la modification, le modèle qui l’a effectuée et la version de l’instruction utilisée ; le registre des risques conserve chaque constatation à vie, ne supprimant jamais les lignes et conservant les lignes fermées pour la traçabilité.
| Concept | Real-World Implication |
|---|---|
| Six reports between July 9 and August 4, 2026, run by three different AI models (sonnet-5, fable-5, grok-4-5) | No single model defines the program; each pass is expected to re-verify prior findings against current source |
| The August 4 pass reviewed 21 commits and 48 files (+2,407/−564 lines) since the prior report | Review is diff-scoped — every release cycle is examined, not just new headline features |
| Dependency scan surfaced 15 advisories (0 critical, 9 high, 4 moderate, 2 low) | The wallet ships against a dependency tree with known high-severity advisories, none critical |
| The registry counts 20 open technical risks after August 4 | The project's own published ledger says two dozen code-level risks remain unresolved |
| Cypress E2E and live tests (Ledger, WalletConnect, a real swap) were not run | The Critical and High findings are traced in static source, not demonstrated against a running deployment |
Le constat : des swaps signés à l'aveugle
La découverte critique, recensée sous le numéro AW-2026-043, concerne la seule partie d'un portefeuille qui doit, par sa conception, faire confiance à un tiers. Lorsqu'un utilisateur échange un actif contre un autre, le portefeuille demande à un agrégateur — Deflex, Folks Router ou Biatec Router — de calculer l'itinéraire et de renvoyer les transactions non signées pour l'échange. Le portefeuille décode ces transactions et les signe directement avec la clé privée brute du compte. Ce que l'audit a révélé, c'est que les trois chemins n'ont validé aucun élément des transactions fournies par le serveur : ni que l'expéditeur est bien le compte de l'utilisateur, ni que le destinataire ou le montant correspondent bien à la quote-part affichée, ni même l'ID de génèse du réseau — et les transactions ne sont jamais rendues à l'utilisateur avant signature. L'utilisateur clique sur un bouton « Exécuter » et un lot opaque de transactions distantes est signé avec sa clé.
Les enjeux sont spécifiques au fonctionnement des transactions sur Algorand. Une transaction signée peut comporter des champs autres que « payer X à Y » : un champ « closeRemainderTo » ferme le compte, transférant son solde ALGO total — ou, en cas de transfert d’actifs, l’intégralité de la balance de jetons — vers l’adresse désignée par ce champ, et un champ « rekeyTo » transfère l’autorité de signature du compte vers une clé complètement différente. Sur Algorand, la fonctionnalité « rekeying » (un mécanisme qui permet à un compte de déléguer son autorité de signature à une autre clé, de sorte que plusieurs adresses différentes puissent être contrôlées) permet à un compte de déléguer son autorité de signature à une autre clé ; le registre consigne alors la clé qui signe réellement. Une API d’agrégateur compromise ou malveillante pourrait renvoyer précisément une telle transaction, et le portefeuille la signerait et la soumettrait en silence, contournant les avertissements de « closeRemainderTo » et de « rekeyTo » que l’application avait ajoutés à toutes les autres interfaces de signature suite à une précédente correction (AW-2026-001).
La deuxième découverte : un contrôle de domaine qui fait confiance à l'attaquant
La découverte High, AW-2026-044, concerne la nouvelle fonctionnalité de signature de données arbitraires ARC-60. ARC-60 étend WalletConnect — le protocole de code QR qui permet à une application web de se connecter à un portefeuille et de demander des signatures sans jamais avoir les clés — de sorte qu'une DApp connectée peut demander une signature d'authentification sur des données arbitraires, la base des flux de connexion sans mot de passe. Le portefeuille affiche le domaine demandeur, le but et un aperçu complet des données avant la signature. L'audit a révélé que la vérification de l'attachement au domaine était auto-référentielle : à la fois le domaine revendiqué et les données « authenticatorData » censées en attester arrivent dans la même requête contrôlée par la DApp et ne sont vérifiés que les uns par rapport aux autres, jamais par rapport au véritable homologue de la session WalletConnect. Une DApp malveillante pourrait donc obtenir une signature valide liée à n'importe quel domaine qu'elle voudrait — précisément le type de connexion usurpée que le commentaire de la source de la fonctionnalité lui-même dit qu'il empêche.
Qu'est-ce qui figure dans le code actuel — et ce qui n'est pas encore vérifié
Une correction a été apportée le même jour que la publication du rapport (commit 0b3947e, 'feat: améliorer la sécurité d'ARC-60 et DEX de validation de transaction"). Un nouvel assistant partagé, assertSwapTransactionSafe, s'exécute désormais sur chaque transaction avant que l'un des trois agrégateurs ne signe, refusant l'ensemble du lot si l'expéditeur ne correspond pas au compte connecté ou si une transaction contient un champ de rekey ou de clôture. Du côté d'ARC-60, un nouveau contrôle domainMatchesSessionOrigin compare le domaine revendiqué au nom d'hôte du peer de la session WalletConnect, plutôt que à la charge utile de la requête elle-même.
La correction est disponible sur la branche master et dans le portefeuille déployé : les messages de refus du gardien sont présents dans le bundle JavaScript minifié servi par a-wallet.net, confirmant que le code de validation est inclus dans ce que les utilisateurs exécutent réellement, et les deux domaines servent la même version (36221a6, 13 août). Ce qui n'est pas encore arrivé, c'est la vérification de la correction par le programme qui a trouvé le bug. La dernière entrée du registre des risques est l'audit du 4 août lui-même, qui a examiné un commit précédent ; le commit de validation est arrivé séparément le même jour, et aucun rapport d'audit ultérieur n'existe dans le dépôt pour ré-classer AW-2026-043 et AW-2026-044 comme résolus.
Il faut peser ce statut non vérifié contre ce que le programme est réellement. Les audits sont effectués par des modèles d'IA dans le cadre du cahier des charges du projet, sans qu'aucune société de sécurité indépendante ne soit citée dans l'un des six rapports, et le référentiel ne publie aucune version étiquetée — les builds sont déployées directement à partir du pipeline CI/CD — il n'y a donc pas d'étape de certification des versions sur laquelle s'appuyer. Le rapport du 4 août lui-même stipule clairement que ses conclusions principales ont été retracées dans le code source statique, et non vérifiées sur un déploiement en cours. En tant qu'expérience de transparence, le programme est véritablement inhabituel — la plupart des portefeuilles publient des résumés d'audits, et non les fichiers bruts « ce que nous avons trouvé ce mois-ci ». En tant que garantie de sécurité indépendante, il ne couvre pas encore ses propres correctifs les plus récents.
Un projet communautaire qui se finance lui-même
Biatec est indépendant d'Algorand Inc. et de la Fondation Algorand, ne recevant aucun financement régulier de l'une ou l'autre, selon ses FAQ, mais il a reçu des subventions communautaires ponctuelles xGov. Le référentiel xGov indique 10 000 ALGO pour AWallet lui-même et 60 000 ALGO pour son planificateur de paiement comme approuvés ; deux propositions de 2024 — une demande rétroactive de 36 912 ALGO et un projet d'identité on-chain de 148 999 ALGO — sont listées comme finalisées. Le cadre du projet lui-même, dans l'abstract de la proposition rétroactive, est que AWallet est « l'un des portefeuilles les plus avancés sur Algorand ».
La trace financière derrière cette allégation est faible. L'adresse de don publiée contient 25,6 ALGO et environ 1,03 USDT en chaîne ; le Discord du projet compte 411 membres, dont 7 en ligne au moment de la vérification ; le post social le plus récent et le plus visible concernant le portefeuille, sur Bluesky, a un seul « like ». Le développement lui-même n'est pas inactif : le dépôt a été mis à jour le 15 août, compte 672 étoiles et ses deux principaux contributeurs ont respectivement 546 et 62 commits.
Un point sur lequel un lecteur devrait se pencher : l'écran d'échange du portefeuille passe par l'agrégateur de Biatec, en plus des deux routeurs tiers, et Biatec gère également le nœud et l'indexeur Algorand auxquels le portefeuille peut se connecter. Rien de tout cela n'est un problème en soi — la conception non décentralisée signifie que le portefeuille ne signe que ce que l'utilisateur approuve — mais l'audit du 4 août montre précisément pourquoi la couche d'agrégation est la limite de confiance qui importe, et le routeur de l'équipe s'y situe directement.
La même société slovaque a développé un ensemble d'outils plus large autour d'Algorand : un portail de paiement gratuit et open source qui permet aux commerçants d'accepter des ALGO, des USDC ou des USDT directement sur leur propre compte, sans intermédiaire financier et sans nécessité de compte de portefeuille, un système de vote open source, et le cadre Stabilitas national-stablecoin qui, selon ce média, est en pause depuis 2023. Le programme d'audit du portefeuille, quelles que soient ses limites, est la partie de ce portefeuille où l'équipe montre son travail de la manière la plus vérifiable.
Source
- Biatec Wallet (a-wallet.net propose la même version)
- répositoire GitHub de scholtz/wallet — README, instructions d'audit, registre des risques, rapports d'audit, validate.ts, arc60.ts
- FAQ du portefeuille
- Changements du portefeuille
- Page de donations
- Propositions xGov 9, 90, 199, 200
- Biatec Wallet - Portefeuille de la communauté Algorand
- Biatec Wallet - Portefeuille de la communauté Algorand
- Biatec
- raw.githubusercontent.com
- raw.githubusercontent.com
- raw.githubusercontent.com
- Historique de src/scripts/aggregators/validate.ts - scholtz/wallet · GitHub
- Biatec Wallet - Portefeuille de la communauté Algorand
- Les meilleurs portefeuilles Algorand en 2026 : des places sûres pour le staking d'ALGO - Coin Bureau
Source: https://www.a-wallet.net/