Les audits IA publiés par Biatec Wallet ont mis au jour une faille critique dans la signature des swaps

Un registre d'audit rédigé par des machines

En mai 2021, le projet aujourd'hui baptisé Biatec Wallet livrait sa première version publique : créer un portefeuille, le protéger 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 étoffée sous la marque Biatec¹, tourne toujours entièrement dans le navigateur, et elle a adopté une pratique peu banale pour un petit portefeuille communautaire : publier des rapports d'audit de sécurité datés, rédigés par des modèles d'IA, directement dans son dépôt GitHub public², aux côtés d'un registre vivant de tous les risques que ces audits ont mis au jour.

Le rapport le plus récent, daté du 4 août, s'ouvre sur un avertissement que la plupart des projets préféreraient enfouir : « Le résultat principal est négatif : cet audit relève une constatation critique et une constatation élevée, toutes deux constituant des voies réalistes vers la perte totale des fonds d'un compte. » Les deux constatations portent sur la fonction de swap — le seul endroit du portefeuille où la clé privée de l'utilisateur est brièvement exposée à la réponse d'un serveur distant —, et la manière dont elles ont été découvertes puis corrigées donne la juste mesure de ce qu'un tel programme d'audit auto-publié peut garantir, et de ce qu'il ne peut pas.

Un portefeuille qui ne touche jamais à vos clés

Biatec Wallet est un portefeuille Algorand gratuit et open source, non-custodial, créé par Scholtz & Company, jsa., de Bratislava, en Slovaquie (identifiant d'entreprise 51 882 272, TVA SK2120828105) et développé sous la marque Biatec. Non-custodial signifie qu'aucun tiers ne détient jamais les clés privées : pas de serveur backend, pas de formulaire d'inscription, pas de KYC, et le fichier du portefeuille est chiffré en AES-256 et stocké dans l'IndexedDB du navigateur. Le mot de passe ne sert qu'en local, pour chiffrer et déchiffrer — il n'est jamais transmis où que ce soit, 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 présente comme le premier portefeuille Algorand open source ; d'après les articles de presse, 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'un navigateur et d'un mot de passe : ouvrez wallet.biatec.io³ — le README du projet signale que l'ancien domaine a-wallet.net n'est qu'un miroir obsolète du même déploiement —, 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 est créé localement. Par défaut, l'application tourne sur mainnet, connectée aux nœuds publics d'AlgoNode, avec des réglages permettant de changer de fournisseur — notamment le nœud Algorand et l'infrastructure d'indexer de Biatec.

Comment fonctionne le programme d'audit

Le processus est codifié dans un fichier nommé ai-audit-instructions.md : saisir « do new audit » dans le dépôt déclenche une nouvelle passe confiée à un modèle d'IA, qui doit se comporter comme le ferait « une société professionnelle d'audit de smart contracts et de sécurité des portefeuilles » — sceptique, adversariale et précise sur la gravité, chaque constatation étant rattachée à des chemins de fichiers et des numéros de ligne précis. Chaque rapport consigne le commit audité, le modèle utilisé et la version des instructions appliquée ; le registre des risques reprend indéfiniment toutes les constatations, sans jamais supprimer de ligne, et conserve les entrées closes pour la traçabilité.

La constatation : des swaps signés à l'aveugle

La constatation critique, suivie sous la référence AW-2026-043, concerne la seule partie d'un portefeuille qui doit, par conception, accorder un instant sa confiance à un inconnu. Lorsqu'un utilisateur échange un actif contre un autre, le portefeuille demande à un agrégateur — Deflex, Folks Router ou Biatec Router — de calculer la route et de renvoyer les transactions non signées de l'opération. Le portefeuille décode ces transactions et les signe directement avec la clé privée brute du compte. Ce que l'audit a mis en évidence, c'est qu'aucun des trois chemins ne validait quoi que ce soit des transactions fournies par le serveur : ni que l'émetteur correspond bien au compte de l'utilisateur, ni le destinataire ou le montant par rapport au devis affiché, ni même le genesis ID du réseau — et ces transactions ne sont jamais présentées à l'utilisateur avant signature. L'utilisateur clique sur un unique bouton Execute et un lot opaque de transactions distantes est signé avec sa clé.

L'enjeu tient au fonctionnement même des transactions Algorand. Une transaction signée peut porter des champs qui vont bien au-delà de « payer X à Y » : un champ closeRemainderTo clôture le compte, balayant l'intégralité de son solde ALGO — ou, sur un transfert d'actif, la totalité des jetons détenus — vers l'adresse que ce champ désigne, tandis qu'un champ rekeyTo transfère l'autorité de signature sur le compte à une tout autre clé. Sur Algorand, le rekeying permet à un compte de déléguer son autorité de signature à une clé différente ; le registre enregistre alors quelle clé signe effectivement. Une API d'agrégateur compromise ou malveillante pourrait renvoyer exactement une telle transaction, et le portefeuille la signerait et la soumettrait en silence — contournant les avertissements rouges de clôture et de rekey qu'une remédiation antérieure (AW-2026-001) avait ajoutés à toutes les autres surfaces de signature de l'application.

Deuxième constatation : un contrôle de domaine qui fait confiance à l'attaquant

La constatation de gravité élevée, AW-2026-044, se situe dans la nouvelle fonction de signature de données arbitraires ARC-60. ARC-60 étend WalletConnect — le protocole à QR code qui permet à une application web de se connecter à un portefeuille et de demander des signatures sans jamais détenir les clés — afin qu'un DApp connecté puisse demander une signature d'authentification sur des données arbitraires, base des flux de connexion sans mot de passe. Avant de signer, le portefeuille affiche le domaine demandeur, l'objet de la demande et un aperçu complet des données. L'audit a constaté que le contrôle de liaison au domaine était autoréférentiel : le domaine revendiqué comme le authenticatorData censé l'attester arrivent tous deux dans la même requête contrôlée par le DApp et ne sont comparés que l'un à l'autre, jamais au pair réel de la session WalletConnect. Un DApp malveillant pouvait donc obtenir une signature valide liée au domaine de son choix — précisément l'usurpation de connexion que le commentaire du code source de cette fonction annonce prévenir.

Ce qui figure dans le code actuel — et ce qui n'est pas encore vérifié

Un correctif a été intégré le jour même de la publication du rapport (commit 0b3947e, « feat: enhance ARC-60 security and DEX aggregator transaction validation »). Un nouvel utilitaire partagé, assertSwapTransactionSafe, s'exécute désormais sur chaque transaction avant que l'un des trois agrégateurs ne signe, et rejette tout le lot si l'émetteur ne correspond pas au compte connecté ou si une transaction porte un champ de rekey ou de clôture. Côté ARC-60, un nouveau contrôle domainMatchesSessionOrigin compare le domaine revendiqué au nom d'hôte du pair réel de la session WalletConnect plutôt qu'à la charge utile de la requête elle-même.

Le correctif est sur master et dans le portefeuille déployé : les messages de refus du garde-fou sont présents dans le bundle JavaScript minifié servi par a-wallet.net, ce qui confirme que le code de validation est bien livré dans ce que les utilisateurs exécutent réellement, et les deux domaines servent la même build (36221a6, 13 août). Ce qui n'a pas encore eu lieu, c'est la vérification du correctif par le programme qui a trouvé la faille. La plus récente entrée du registre des risques est l'audit du 4 août lui-même, qui portait sur un commit antérieur ; le commit de validation est arrivé séparément le même jour, et aucun rapport d'audit postérieur ne figure dans le dépôt pour revérifier AW-2026-043 et AW-2026-044 en tant que constatations closes.

Ce statut non vérifié mérite d'être mis en regard de ce qu'est réellement ce programme. Les audits sont réalisés par des modèles d'IA selon le cahier des charges propre au projet, sans qu'aucun cabinet de sécurité indépendant ne soit nommé dans les six rapports, et le dépôt ne publie aucune release taguée — les builds sortent directement du pipeline CI/CD —, de sorte qu'il n'existe aucune étape de certification de version sur laquelle s'appuyer. Le rapport du 4 août indique lui-même explicitement que ses principales constatations ont été tracées dans le code source statique, et non prouvées sur un déploiement en fonctionnement. En tant qu'expérience de transparence, le programme est réellement inhabituel — la plupart des portefeuilles publient des synthèses d'audit, pas les fichiers bruts du type « 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 s'autofinance

Biatec est indépendant d'Algorand Inc. et de l'Algorand Foundation et ne reçoit de financement récurrent ni de l'un ni de l'autre, selon sa FAQ, mais il a bénéficié de subventions ponctuelles de la communauté xGov. Le dépôt xGov enregistre 10 000 ALGO pour AWallet lui-même et 60 000 ALGO pour son ordonnanceur de paiements au statut Approved ; deux propositions de 2024 — une demande rétroactive de 36,912 ALGO et un projet d'identité on-chain à 148,999 ALGO — sont listées comme Final. La formulation du projet lui-même, dans le résumé de la proposition rétroactive, est qu'AWallet est « l'un des portefeuilles les plus avancés d'Algorand ».

L'empreinte financière derrière cette affirmation est modeste. L'adresse de don publiée détient 25.6 ALGO et environ 1.03 USDT on-chain ; le Discord du projet compte 411 membres, dont 7 en ligne au moment de la vérification ; la publication sociale récente la plus visible au sujet du portefeuille, sur Bluesky, a recueilli un seul like. Le développement, lui, n'est pas en sommeil : le dépôt a reçu un push le 15 août, affiche 672 étoiles, et ses deux principaux contributeurs totalisent respectivement 546 et 62 commits.

Un point de concentration que le lecteur doit garder en tête : l'écran de swap du portefeuille passe par l'agrégateur de Biatec lui-même, aux côtés des deux routeurs tiers, et Biatec exploite aussi le nœud Algorand et l'infrastructure d'indexer auxquels le portefeuille peut se connecter. Rien de tout cela n'est problématique en soi — la conception non-custodiale fait 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 constitue la frontière de confiance qui compte, et le routeur de l'équipe se trouve en plein dessus.

La même société slovaque a bâti autour d'Algorand une panoplie plus large : une passerelle de paiement gratuite et open source qui permet aux marchands d'accepter directement de l'ALGO, de l'USDC ou de l'USDT sur leur propre compte, sans intermédiaire financier ni compte de portefeuille, un système de vote open source, et le cadre de stablecoin national Stabilitas, que notre rédaction avait déjà observé à l'arrêt depuis 2023. Le programme d'audit du portefeuille, quelles qu'en soient les limites, est l'élément de ce portefeuille de projets où l'équipe expose son travail de la façon la plus inspectable.