Considérations d'audit de la blockchain

Fonctionnement

La blockchain fonctionne comme un grand livre où chaque transaction 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, ce qui est techniquement possible mais économiquement impraticable dans les réseaux importants. Cela signifie que l'immuabilité n'est pas une propriété absolue ; c'est plutôt une propriété économique fondée sur le coût d'une manipulation.
L'auditeur applique ISA 500.5 en évaluant la fiabilité de l'information de blockchain en tant que source d'éléments probants. Trois risques de fraude doivent être testés : la saisie de données inexactes avant la blockchain (le réseau validera une transaction fausse si elle est correctement formatée), la modification de transactions existantes via une attaque à 51 % (contrôle temporaire du réseau pour récrire l'historique), et les contrats intelligents qui ne font pas ce qu'ils étaient censés faire.
Pour les transactions au sein de chaînes de blocs 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.
Les contrats intelligents sont le risque 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.

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
L'équipe d'audit identifie que le processus de revenu entièrement automatisé dépend de : (1) la validité de la saisie initiale (confirmation de livraison), (2) l'intégrité du contrat intelligent lui-même, et (3) le processus de validation du nœud Hyperledger. Aucun contrôle manuel ne teste 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
Le code du contrat déploie 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.
Conclusion
Les données de blockchain ne sont pas auto-validantes. Elles reflètent ce qu'on y a saisi, et elles reflètent un processus de validation qui s'est déroulé comme prévu. Le registre distribué lui-même alimente à Steinberg une fiabilité suffisante pour soutenir un élément probant sur les revenus à condition que (1) le contrat intelligent ait été audité une seule fois au déploiement, (2) les nœuds validateurs soient gérés selon le protocole documenté, et (3) la saisie initiale soit testée sur un échantillon. C'est une automatisation, pas une magie.

Ce que les auditeurs et les examinateurs confondent

• Immutabilité comme 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 comme 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.
• Contrats intelligents comme boîtes noires de confiance. Si le contrat intelligent gouverne une estimation comptable ou une allocation de revenus, ISA 540.13 l'oblige à être testé et documenté. Trop de cabinets traitent le code déployé comme une confiance 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.
• Confusion entre clé privée et signature de validation. ISA 315.A98 impose à l'auditeur de comprendre les contrôles d'accès aux systèmes qui produisent les éléments probants. Une coopérative agricole bretonne (chiffre d'affaires 22 M EUR) utilisait Hyperledger pour tracer les certifications bio. L'équipe avait validé que trois nœuds signaient chaque transaction, mais n'avait pas vérifié qui détenait les clés privées de signature : les trois clés étaient en réalité gérées par le même administrateur informatique. Le consensus distribué était une fiction. L'inspection a soulevé la séparation des fonctions absente et la nécessité de tester la chaîne de garde des clés.

Comparaison pertinente : Blockchain vs tenue de livres centralisée

| Dimension | Blockchain | Tenue de livres centralisée |
|---|---|---|
| Source d'éléments probants | Registre distribué validé par plusieurs nœuds | Système centralisé géré par une autorité unique |
| Immuabilité | Impossible à modifier après confirmation (coûteux à l'échelle) | Modifiable par administrateur ; journaux d'audit requis |
| Test du contrôle interne | Valider le consensus et le processus de nœud | Tester les contrôles d'accès et les approbations |
| Risque de saisie initiale | Élevé (pas d'approbation avant enregistrement) | Moyen (approbation documentée, mais pas immuable) |
| Exemple de déploiement audit | Contrats intelligents d'allocation automatique | Modules de revenu SAP avec approbations manuelles |
La blockchain ne supprime pas 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é.
L'auditeur doit vérifier trois choses : (1) le titre a-t-il été correctement saisi au départ (par exemple, la vérification d'identité du propriétaire a-t-elle eu lieu), (2) le consensus du réseau a-t-il fonctionné comme prévu (les trois nœuds validateurs ont-ils approuvé), et (3) 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) ?
Si l'auditeur se concentre uniquement sur l'immuabilité et ignore l'étape 1, il accepte les titres erronés comme immuables. Si l'auditeur ignore l'étape 3, il suppose que le code fonctionne comme prévu sans l'avoir vérifiée. 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.
Éléments probants suffisants et appropriés (ISA 500) : La norme qui gouverne la nature, le calendrier et l'étendue des procédures analytiques et des tests d'éléments probants.
Contrôles généraux informatiques : La gestion des nœuds validateurs, les logs de consensus et les contrôles d'accès aux clés privées.
Contrôles applicatifs : Les contrôles automatisés intégrés dans les applications qui interfacent avec la blockchain, notamment les contrôles de saisie initiale.
Facteurs de risque de 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.
Procédures d'évaluation des risques : Les procédures qui identifient où la blockchain est utilisée pour enregistrer des événements économiques significatifs, comme ISA 315 l'exige.