Chapitre 4 — Responsabilité, régulation et limites de l'autonomie algorithmique

Dans une blockchain publique, il n'existe pas de "propriétaire" du système. L'infrastructure fonctionne par agrégation de rôles distincts : développeurs, validateurs, opérateurs de nœuds, utilisateurs, acteurs économiques. En cas d'incident, cette dispersion complique l'attribution de responsabilité.

Chaque acteur participe à sa manière : les développeurs écrivent les clients, les validateurs exécutent le consensus, les utilisateurs signent les transactions. Le protocole exécute mécaniquement, ce qui sépare l'intention de l'exécution.

Le droit cherche un responsable identifiable. Mais dans une blockchain, la "cause" peut être un assemblage d'actions légitimes. La responsabilité se déplace vers le design et la gestion du risque : audits, garde-fous, processus de contrôle.

Dans une blockchain, le code est exécutoire. Un smart contract produit des effets concrets : transferts d'actifs, changements d'état. Cela implique des contraintes de déterminisme, d'absence d'IO libre et de coût d'exécution.

Un bug n'est pas seulement une erreur : dans un système "code is law", un bug peut devenir une règle de facto. Les responsabilités viennent autant des vulnérabilités que des choix d'architecture : oracles, garde-fous, gouvernance.

Le protocole choisit ce qui est possible : qui peut valider, quel coût pour attaquer, quelle finalité. Ces choix redistribuent le pouvoir mais sont présentés comme neutres. Changer ces règles exige une coordination qui révèle le pouvoir réel.

"Code is law" signifie que les règles sont exécutées automatiquement. Mais le code est écrit par des humains, interprété via des implémentations et peut être modifié. Entre clients, upgrades et gouvernance, la "loi" technique reste une construction sociale.

L'architecture définit : ce qui est vérifiable, ce qui est public, qui peut participer, quelle transparence est imposée. Ce sont des décisions normatives touchant aux droits, à l'équité, à la liberté, à la responsabilité.

Le pouvoir non élu peut se cristalliser chez les mainteneurs de clients, les gros validateurs, les opérateurs d'infrastructure, les exchanges. Ce pouvoir s'exerce sans voter, par sélection logicielle ou contrôle d'accès.

Le droit demande : qui a l'obligation, qui a commis la faute, qui indemnise ? Or dans une blockchain, l'opérateur peut être inconnu, le système est transnational, le dommage peut venir d'une combinaison protocole + smart contract + oracle.

Une blockchain est globale mais le droit est territorial. Un État ne peut pas "modifier" la chaîne, mais peut interdire des services, contraindre des acteurs localisés, réguler l'accès à la liquidité.

La blockchain produit des traces horodatées utiles comme preuves. Mais "preuve technique" n'est pas automatiquement "preuve juridique" : il faut prouver l'identité derrière une clé, l'intention, le contexte.

On régule ce qui est saisissable : entreprises, services, plateformes. Ces acteurs peuvent implémenter KYC/AML, filtrage d'adresses, reporting, restrictions géographiques. La régulation change l'expérience utilisateur sans éteindre la chaîne.

KYC réintroduit une forme d'institution : identification, blocage, sanctions. Cela heurte l'idéologie initiale de désintermédiation, mais répond à des contraintes de fraude et de protection du consommateur.

Le défi est de réguler sans casser les propriétés : vérifiabilité, résilience, résistance à la censure. Cela mène à des compromis : encadrer certaines applications, imposer des audits, exiger des obligations aux stablecoins.

Un smart contract est un programme déployé sur la chaîne, exécuté par tous les nœuds. Il matérialise une règle : si conditions, alors action. Le contrat devient une norme exécutable qui applique sans interprétation.

Le code exécute ce qui est écrit, pas ce qui est "juste". Le réel est ambigu : exceptions, force majeure. Sans mécanismes d'échappement, le système peut devenir injuste. Les garde-fous améliorent la sécurité mais réintroduisent des points de pouvoir.

Un tribunal peut juger qu'une action est illégitime, mais la blockchain l'a exécutée. On ne peut pas effacer un état sans fork ou mécanisme prévu. Les remèdes passent par forks, compensations, gels ou migrations.

Dans un système hybride, l'IA peut recommander, classer ou décider. Si un smart contract exécute automatiquement sur la base du score IA, l'IA devient décisionnaire de facto. Un registre d'artefacts vérifiables (version du modèle, données, logique) permet de reconstruire la chaîne de décision.

Un système hybride empile trois sources de biais : données, modèles et règles. La blockchain peut tracer versions et pipelines mais ne garantit pas l'équité, seulement la vérifiabilité. Un hash garantit la fidélité au pipeline, pas la justice.

Le risque majeur est la fermeture du recours : si une décision IA déclenche une action automatique, la contestation devient tardive ou impossible. Des garde-fous techniques sont nécessaires : timelocks, fenêtres de contestation, human-in-the-loop, pause.

L'explicabilité répond à "pourquoi", l'auditabilité à "peut-on vérifier", la traçabilité à "peut-on reconstruire". Un registre IA+blockchain peut prouver versions et intégrité (hash/Merkle/horodatage) sans exposer les données sensibles.

Dans un système hybride, plusieurs responsabilités se superposent : fournisseur du modèle, équipe MLOps, opérateurs du protocole, gouvernance, responsables métier. Un registre d'attestations permet de rendre l'imputation possible et de limiter la dilution.

Le modèle réaliste n'est pas "un responsable unique", mais une responsabilité distribuée avec preuve de contribution. On substitue l'opacité par une chaîne de preuves : qui a fait quoi, quand, sur quelle version, avec quelle règle.

Quand une décision est irréversible (gel, exclusion, refus, sanction), le risque est l'atteinte aux droits : erreur, discrimination, absence de recours. Plus l'automatisation est forte, plus il faut des garde-fous : finalité graduelle, contestation, contrôles.

Un système autonome doit prévoir sa propre limite : conditions de "mode dégradé". Déclencheurs : anomalie statistique, attaque, dérive de modèle, crise humaine. Le point clé est la gouvernance : qui peut activer la pause, sous quelles conditions.

Réintroduire l'humain ne veut pas dire "tout centraliser". L'enjeu est de construire un humain contrôlé par des procédures : human-in-the-loop, comité multi-acteurs, transparence des interventions, règles de contestation.