Considérations d'audit de la blockchain

Fonctionnement

Chaque transaction dans une blockchain est liée cryptographiquement à la précédente. Une fois écrite, une transaction ne peut pas être modifiée sans récrire l'ensemble de la chaîne. C'est techniquement possible mais économiquement impraticable dans les réseaux importants. Cette immuabilité n'est donc pas une propriété absolue. C'est une propriété économique fondée sur le coût d'une manipulation.

ISA 500.5 s'applique ici : l'auditeur évalue la fiabilité de l'information de blockchain en tant que source d'éléments probants. Deux catégories de risques de fraude doivent être testées en priorité : la saisie de données inexactes avant la blockchain (le réseau validera une transaction fausse si elle est correctement formatée), et les contrats intelligents qui ne font pas ce qu'ils étaient censés faire. S'y ajoute le risque d'attaque à 51 % (contrôle temporaire du réseau pour récrire l'historique), plus rare mais à documenter.

Pour les transactions au sein de chaînes privées ou autorisées, le processus de validation centralisé ressemble à un contrôle interne classique : identifiez le gestionnaire du nœud validateur, testez les logs de validation et confirmez que le protocole de consensus a été suivi. Pour les blockchains publiques sans autorité centrale (Bitcoin, Ethereum), l'immuabilité elle-même remplace le contrôle interne, mais au prix d'une transparence complète et d'une puissance de calcul distribuée.

Parmi tous les risques liés à la blockchain, les contrats intelligents sont le plus mal compris. Un contrat intelligent est un morceau de code qui s'exécute automatiquement une fois les conditions pré-programmées remplies. Si l'entité l'utilise pour enregistrer une répartition de revenus, ISA 540 (estimations comptables) s'applique : le code lui-même est la méthode d'estimation, et le comportement du code doit être audité avant que n'importe quelle transaction soit acceptée comme élément probant. Quand le client déploie une usine à gaz de contrats intelligents imbriqués, et que personne dans l'équipe ne lit le code, le dossier est trop léger pour soutenir une opinion.

Exemple pratique : Steinberg Logistics GmbH

Steinberg Logistics GmbH, une entreprise allemande de transport, enregistre les confirmations de livraison via une blockchain privée Hyperledger Fabric pour automatiser les paiements aux sous-traitants. Chaque livraison confirmée déclenche un contrat intelligent qui répartit 15 % du fret entre le chauffeur (11 %) et l'entreprise mère (4 %).

Étape 1 : Identification du risque Constat initial : le processus de revenu entièrement automatisé dépend de la validité de la saisie initiale (confirmation de livraison), de l'intégrité du contrat intelligent lui-même, du processus de validation du nœud Hyperledger, et de l'absence de contrôle manuel sur les allocations de pourcentage une fois déployées. Note de documentation : Demander le code source du contrat intelligent et les logs de déploiement réseau. Identifier le gestionnaire du nœud validateur et les protocoles de gestion des clés privées.

Étape 2 : Test du code du contrat intelligent En analysant le code source, on constate une division 11/4 sans arrondir. Sur 1 000 transactions de fret de 100 EUR chacune, cela produit 1 000 × 100 × 0,04 = 4 000 EUR à la mère, et 1 000 × 100 × 0,11 = 11 000 EUR aux chauffeurs. Reste : 85 000 EUR pour l'entreprise. En testant trois contrats de fret manuels, l'auditeur confirme que les pourcentages correspondent aux résultats en blockchain. Note de documentation : Vérifier le code du contrat par rapport au mémo d'intention commercial. Confirmer que le gestionnaire du nœud a archivé le code du contrat et les logs de déploiement. Documenter la version du code exécuté.

Étape 3 : Validation du processus de consensus Hyperledger Fabric utilise un processus de validation où au moins trois nœuds doivent signer chaque transaction. Vérifier les logs de validation (signés avec des clés privées gérées par des administrateurs nommés) pour trois transactions de test : toutes les trois contiennent les trois signatures requises. Note de documentation : Demander les logs d'audit Hyperledger pour la période d'essai. Confirmer les noms des administrateurs de nœuds validateurs et les processus de contrôle d'accès aux clés privées.

Étape 4 : Risque de saisie initiale Une confirmation de livraison inexacte produit une transaction blockchain inexacte. L'équipe d'audit teste le processus de saisie : un chauffeur utilise une application mobile pour prendre une photo de signature et confirmer le poids du fret. Cela alimente le contrat intelligent. Tester trois confirmations de saisie en vérifiant les photos et les poids signalés par rapport aux documents de fret papier : toutes les trois correspondent. Note de documentation : Tester les contrôles de saisie de données (photo requise, signature requise, poids calculé par balance calibrée). Documenter les résultats des tests.

Résultat Rien dans la blockchain n'est auto-validant. Ces données reflètent ce qu'on y a saisi, et un processus de validation qui s'est déroulé comme prévu. Chez Steinberg, le registre distribué fournit une fiabilité suffisante pour soutenir un élément probant sur les revenus à condition que le contrat intelligent ait été audité une seule fois au déploiement, que les nœuds validateurs soient gérés selon le protocole documenté, et que la saisie initiale soit testée sur un échantillon. C'est une automatisation, pas une magie.

Ce que les auditeurs et les examinateurs confondent

Immuabilité ne veut pas dire certitude. Une transaction immuable dans la blockchain prouve que la transaction a existé et n'a pas été modifiée après enregistrement. Elle ne prouve pas que l'événement économique sous-jacent s'est réellement produit ou que la saisie de départ était exacte. ISA 500.A20 exige de l'auditeur qu'il évalue la fiabilité de la source d'information, pas seulement que le registre soit interne et intact.

Absence de contrôle central ne signifie pas absence de risque de fraude. Les blockchains publiques ne disposent pas d'autorité centrale parce que la fraude est censée être impossible (une modification de l'historique coûterait plus cher que la valeur fraudée). Mais ISA 240.13 exige tout de même de l'auditeur qu'il évalue les risques de fraude au sein de la transaction d'origine. Un enregistrement erroné dans Ethereum reste enregistré de façon immuable, et à moins qu'un fork de la blockchain n'annule la transaction, l'erreur persiste.

Un contrat intelligent n'est pas une boîte noire de confiance. Si le contrat intelligent gouverne une estimation comptable ou une allocation de revenus, ISA 540.13 l'oblige à être testé et documenté. Nous constatons que trop de cabinets traitent le code déployé comme acquis et testent seulement le résultat en chaîne. Le code lui-même doit être lu et évalué par quelqu'un qui peut vérifier que le comportement correspond à l'intention.

Comparaison pertinente : Blockchain vs tenue de livres centralisée

Aucune blockchain ne supprime le risque. Elle le déplace de la manipulation de registre à la saisie initiale et à la logique du contrat intelligent.

Où la distinction importe dans une mission

Supposons que votre client utilise une blockchain pour enregistrer les titres de propriété de biens immobiliers. L'objectif est de créer un registre immuable qui remplace le registre foncier gouvernemental. Un titre enregistré ne peut pas être retracté ou modifié.

Quatre vérifications s'imposent : le titre a-t-il été correctement saisi au départ (la vérification d'identité du propriétaire a-t-elle eu lieu), le consensus du réseau a-t-il fonctionné comme prévu (les trois nœuds validateurs ont-ils approuvé), le contrat intelligent qui crée le titre a-t-il enregistré la bonne propriété (le code fait-il ce qu'il était censé faire), et existe-t-il un processus de remédiation si une erreur est détectée après enregistrement ?

Si l'auditeur se concentre sur l'immuabilité et ignore la saisie initiale, il accepte les titres erronés comme immuables. Si l'auditeur ne vérifie pas le code, il suppose que le contrat intelligent fonctionne comme prévu sans l'avoir testé. La blockchain n'élimine pas ces risques d'audit.

Termes connexes

Éléments probants: Ce que l'auditeur recueille pour soutenir son opinion. Une transaction blockchain n'est un élément probant que si sa source est fiable.

ISA 500: La norme qui gouverne la nature, le calendrier et l'étendue des procédures analytiques et des tests d'éléments probants.

Estimations comptables: Les contrats intelligents qui gouvernent la répartition des revenus ou l'allocation automatique des coûts sont des estimations au sens d'ISA 540.

Processus de validation des risques: Identifier où la blockchain est utilisée pour enregistrer des événements économiques significatifs, comme ISA 315 l'exige.

Contrôles sur les systèmes IT: La gestion des nœuds validateurs, les logs de consensus, et les contrôles d'accès aux clés privées.

Fraude: ISA 240 exige que l'auditeur évalue les risques d'erreur intentionnelle, y compris la saisie initiale de données incorrectes dans la blockchain.

---