Smart contract, ce que c’est et ce que ça ne fait pas

Oubliez le mot intelligent, il n’y a aucune intelligence là-dedans.

L’image juste est celle du distributeur automatique. Vous mettez 2 euros, vous appuyez sur le bouton, la barre tombe. Pas de caissier, pas de discussion. Si vous avez mis assez, vous êtes servi. Sinon, rien ne se passe.

Un smart contract fait exactement ça, avec de l’argent et des conditions. C’est un programme déposé sur une blockchain, c’est-à-dire un registre partagé entre des milliers de machines qui se mettent d’accord sur ce qui est vrai. Une fois déposé, il exécute sa règle, et personne ne peut la changer en douce, pas même celui qui l’a écrite.

L’idée n’est pas neuve. Elle a été décrite dans les années 1990 par le cryptographe Nick Szabo, bien avant qu’une technologie permette de la réaliser.

Ce que ça remplace. Non pas le contrat, mais l’exécution du contrat. La partie où quelqu’un doit vérifier que la condition est remplie, puis déclencher le virement.

Voici un cas simple et parlant. Un client dépose le montant d’un chantier. L’argent ne part chez le prestataire que si le client valide le livrable.

Le langage s’appelle Solidity. Il ressemble à du JavaScript et sert à écrire des programmes pour Ethereum et le millier de réseaux compatibles.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract ReceptionChantier {
    address public client;
    address public prestataire;
    uint256 public montant;
    bool    public livrableValide;

    // Le constructeur ne tourne QU'UNE FOIS, au depot du contrat.
    // Le mot payable signifie qu'on peut lui envoyer de l'argent a ce moment-la.
    constructor(address _prestataire) payable {
        client       = msg.sender;   // celui qui depose devient le client
        prestataire  = _prestataire;
        montant      = msg.value;    // la somme reellement recue
    }

    // require bloque tout si la condition est fausse, et rend l'argent.
    function validerLivrable() external {
        require(msg.sender == client, "Seul le client peut valider.");
        livrableValide = true;
    }

    function liberer() external {
        require(livrableValide, "Le livrable n'a pas ete valide.");
        uint256 a = montant;
        montant = 0;                 // on remet a zero AVANT d'envoyer
        (bool ok, ) = prestataire.call{value: a}("");
        require(ok, "Le transfert a echoue.");
    }
}

⚠ La ligne montant = 0; placée AVANT l’envoi n’est pas un détail de style. C’est la parade à l’attaque la plus classique du domaine, celle où le destinataire rappelle la fonction pendant qu’elle s’exécute pour se faire payer plusieurs fois. On met le compteur à zéro d’abord, on paie ensuite. Des millions ont été volés faute de cette inversion.

Ce que vous devez retenir de ce code. Il tient en 30 lignes, il est public, et il fait exactement ce qu’il dit. C’est sa force et c’est son danger.

Quatre usages où ça apporte quelque chose que l’informatique classique n’apporte pas.

La séquestre entre 2 parties qui ne se font pas confiance. L’argent est bloqué par le code, pas par l’une des parties. Personne ne peut partir avec.

Le paiement à la livraison vérifiée. Une expédition suivie déclenche le règlement à l’arrivée, sans facture relancée ni email de rappel.

Les droits d’auteur qui se versent seuls. À chaque revente d’une œuvre, une part revient à son auteur automatiquement, sans qu’il ait à réclamer.

La règle de gouvernance qui s’applique à tous, y compris à celui qui l’a écrite. C’est l’usage le plus sous-estimé, et le plus proche de ce que cherchent les entreprises.

Le point commun de ces 4 cas. Ce n’est jamais la vitesse ni le coût, c’est le retrait du pouvoir discrétionnaire. Plus personne ne peut décider de ne pas exécuter.

Maintenant la partie qu’on vous dira rarement en réunion commerciale.

1. Le code figé. Une fois déposé, on ne corrige pratiquement pas. Un défaut d’écriture devient permanent et public, donc exploitable par quiconque le remarque. « Le code fait loi » sonne bien jusqu’au jour où le code contient une faute de frappe.

2. Le coût d’exécution. Chaque écriture se paie. Sur les réseaux encombrés, une opération complexe peut coûter cher et à un prix imprévisible. Lire est gratuit, écrire ne l’est pas.

3. Le flou juridique. En cas de litige, il n’est pas toujours clair qui répond. Celui qui a écrit le code, celui qui l’a déployé, celui qui s’en est servi. En France, un smart contract n’a aucune valeur contractuelle par lui-même.

4. L’absence de bouton annuler. Une somme envoyée à la mauvaise adresse est perdue. Définitivement. Aucun service client, aucun recours, aucune écriture inverse.

⚠ Et la limite qui les résume toutes. On remplace la confiance envers une institution par la confiance envers du code. Le problème se déplace, il ne disparaît pas. Encore faut-il que quelqu’un ait relu ce code, et que vous sachiez qui.

Ramenons ça au concret, parce que le cadre a changé cet été.

Depuis le 1er juillet 2026, conserver des crypto-actifs pour le compte d’un tiers exige un agrément européen complet. Entité européenne, 150 000 euros de capital, gouvernance documentée. Exercer sans expose à 2 ans de prison et 30 000 euros d’amende.

La conséquence pratique est nette. Votre prestataire informatique n’a pas le droit d’opérer le coffre-fort. S’il vous propose de détenir les fonds entre vous et vos clients, demandez-lui son agrément avant toute chose.

Ce qui reste parfaitement faisable. Écrire la règle, la déposer, la faire déclencher, et tracer. Le mouvement d’argent, lui, passe par votre banque ou par un établissement autorisé.

C’est la ligne que nous tenons sur les équipes d’agents IA que nous opérons. Le code décide du déclenchement, un tiers agréé exécute, et le journal reste consultable.

Elle tient en une phrase et elle élimine 9 projets sur 10.

Qui refusez-vous de croire sur parole ?

Si la réponse est personne, vous n’avez pas besoin de blockchain. Une base de données classique et un contrat écrit feront le travail, pour bien moins cher et avec un bouton annuler.

Si la réponse est l’autre partie, et qu’aucun tiers de confiance ne convient aux 2, alors le smart contract prend son sens. Il n’apporte pas de la vitesse, il apporte l’impossibilité de tricher.

Et si la réponse est vous-même, c’est-à-dire si vous voulez vous interdire à vous-même de changer d’avis, c’est l’usage le plus élégant. Une règle que son auteur ne peut plus contourner vaut mieux qu’une promesse.

Le réflexe qui vous fera gagner du temps. Avant d’écrire une ligne, écrivez la règle en français, avec les conditions et les montants. Si vous n’y arrivez pas en 10 lignes, le problème n’est pas technique.