Blockchain · fiche technologique
Solidity et OpenZeppelinFiche technologique · Blockchain
Développer en Solidity avec OpenZeppelin.
Solidity est le langage des contrats intelligents sur Ethereum et les réseaux compatibles. OpenZeppelin en est la bibliothèque de référence pour ne pas réécrire à la main les mécanismes sensibles. Voici quand les choisir, et comment nous les intégrons à votre projet.
Le besoin
Ce que vous attendez d'un contrat intelligent.
Vous ne cherchez pas un langage : vous cherchez des règles qui s'appliquent seules, sans intermédiaire, et que chacun peut vérifier.
Un contrat intelligent est un programme enregistré sur une blockchain. Une fois déployé, il s'exécute exactement comme il a été écrit, pour tout le monde, et ses règles ne dépendent plus d'un serveur que vous contrôlez. C'est sa force, et c'est ce qui rend l'erreur coûteuse.
Solidity est le langage le plus utilisé pour écrire ces programmes sur Ethereum et sur les réseaux compatibles avec sa machine virtuelle. Autour de lui, on trouve les outils de test, les bibliothèques et les relecteurs les plus nombreux : c'est un argument de maintenance et de sécurité autant que de productivité.
OpenZeppelin est une bibliothèque de contrats très utilisée et régulièrement relue par l'écosystème : jetons, droits d'accès, mise en pause, mises à jour. S'appuyer dessus évite de réécrire à la main les mécanismes les plus sensibles, et d'y introduire de nouvelles failles. La démarche complète, du cadrage au déploiement, est décrite dans notre expertise smart contracts.
Des règles écrites une fois
Les conditions d'émission, de transfert ou de paiement sont dans le code, lisibles par tous. Plus de ressaisie, plus de discussion sur ce qui avait été convenu.
Des erreurs difficiles à rattraper
Un contrat déployé ne se corrige pas comme un site web. Quand des mises à jour sont prévues, elles sont elles-mêmes un choix d'architecture qu'il faut justifier.
Un langage qui évolue
Solidity change de version régulièrement. Depuis la version 0.8, un dépassement arithmétique interrompt l'opération au lieu de passer inaperçu : un garde-fou précieux, à connaître.
Applications concrètes
Ce qu'on en fait, concrètement.
Six usages courants, du plus simple au plus structurant. Chacun peut se combiner avec les autres.
Jetons de fidélité, de paiement interne ou de gouvernance
Un jeton fongible (norme ERC-20) avec un plafond d'émission, des rôles distincts et, si nécessaire, une pause d'urgence.
Titres numériques, billets et objets uniques
Représenter un droit, un billet ou un objet de collection (normes ERC-721 et ERC-1155), avec des règles de transfert propres à votre activité.
Paiements conditionnels
Des fonds libérés seulement quand une condition vérifiable est remplie : livraison confirmée, échéance atteinte, double validation.
Calendriers de distribution
Répartir des jetons ou des fonds selon un calendrier défini à l'avance, sans intervention manuelle ni tableur à rapprocher.
Votes et décisions collectives
Des propositions, des votes pondérés et l'exécution automatique de la décision une fois le seuil atteint.
Preuves horodatées
Ancrer l'empreinte d'un document ou d'un événement sur la chaîne pour en prouver l'existence, sans publier le document lui-même.
Un exemple lisible
Un jeton plafonné, avec ses garde-fous.
Moins de quarante lignes qui montrent la différence entre écrire un contrat et l'encadrer : l'essentiel vient d'OpenZeppelin, notre code ne porte que la règle propre à l'activité.
- La base du jeton vient d'OpenZeppelin : une implémentation de référence de la norme ERC-20, que l'on n'a pas à réécrire.
- Des rôles distincts : qui peut émettre n'est ni celui qui peut mettre en pause, ni celui qui administre.
- Une erreur personnalisée : l'échec est explicite pour l'application, et moins coûteux en gaz qu'un message texte.
- Le plafond est vérifié avant toute émission : la règle métier tient en une ligne.
- La pause s'applique à tous les mouvements de jetons en un seul point, sans la répéter dans chaque fonction.
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;
import {ERC20} from "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import {AccessControl} from "@openzeppelin/contracts/access/AccessControl.sol";
import {Pausable} from "@openzeppelin/contracts/utils/Pausable.sol";
/// Jeton d'exemple : émission plafonnée, rôles distincts, pause d'urgence.
contract JetonExemple is ERC20, AccessControl, Pausable {
bytes32 public constant EMETTEUR = keccak256("EMETTEUR");
bytes32 public constant GARDIEN = keccak256("GARDIEN");
uint256 public immutable PLAFOND;
error PlafondDepasse(uint256 demande, uint256 restant);
constructor(address admin, uint256 plafond) ERC20("Jeton exemple", "JEX") {
PLAFOND = plafond;
_grantRole(DEFAULT_ADMIN_ROLE, admin);
}
function emettre(address vers, uint256 montant) external onlyRole(EMETTEUR) {
uint256 restant = PLAFOND - totalSupply();
if (montant > restant) revert PlafondDepasse(montant, restant);
_mint(vers, montant);
}
function mettreEnPause() external onlyRole(GARDIEN) {
_pause();
}
function reprendre() external onlyRole(GARDIEN) {
_unpause();
}
function _update(address de, address vers, uint256 montant) internal override whenNotPaused {
super._update(de, vers, montant);
}
}
Faire le bon choix
Solidity : oui, ou pas ?
Un bon conseil technologique commence par ce qu'il déconseille. Voici les situations où Solidity s'impose, et celles où il vaut mieux faire autrement.
Elle convient quand
- Votre projet vise Ethereum ou un réseau compatible avec sa machine virtuelle, comme Polygon, Arbitrum, Optimism, Base ou BNB Chain.
- Vous voulez un jeton, un registre de droits, un paiement conditionnel ou un vote dont les règles ne doivent dépendre de personne.
- Vous tenez à disposer d'outils de test, de relecteurs et de développeurs faciles à trouver : cela compte autant pour la maintenance que pour le lancement.
- Le contrat doit s'intégrer à des portefeuilles et à des services existants, qui parlent déjà le langage des contrats Ethereum.
Il vaut mieux l'éviter, ou la compléter, quand
- Votre besoin est un simple suivi de données : une base de données classique est moins chère, plus rapide et corrigeable à tout moment.
- Vos règles changent souvent : un contrat se modifie mal. Mieux vaut garder cette logique hors chaîne et ne placer sur la chaîne que ce qui doit être vérifiable par tous.
- Le projet vise un réseau qui n'est pas compatible EVM, par exemple Solana : Solidity n'y est pas l'outil adapté.
- Aucune revue indépendante n'est prévue alors que le contrat manipulera des fonds : une relecture externe est recommandée avant le déploiement principal.
Comparer
Solidity face aux autres choix.
Le langage dépend d'abord du réseau visé. Ce tableau situe Solidity par rapport à deux alternatives que l'on rencontre dans les projets.
| Critère | Solidity | Vyper | Rust sur Solana |
|---|---|---|---|
| Réseaux visés | Ethereum et réseaux compatibles avec sa machine virtuelle (EVM) | Ethereum et réseaux compatibles EVM | Solana, qui a sa propre machine virtuelle |
| Écosystème | Le plus large : bibliothèques, outils de test, relecteurs | Plus restreint, centré sur la simplicité de lecture | Propre à Solana, avec ses outils et son modèle de comptes |
| Philosophie | Langage complet, avec héritage entre contrats | Syntaxe volontairement réduite, proche de Python | Programmes écrits en Rust |
| Quand le choisir | Choix par défaut d'un projet sur un réseau EVM | Quand la simplicité d'une relecture prime et que l'équipe le maîtrise | Quand le projet vise Solana |
| Notre position | Mis en œuvre dans nos projets | À évaluer avec vous si le besoin le justifie | Intégrable selon votre projet |
Positionnement indicatif : le bon choix dépend du réseau, de l'équipe et du niveau de risque.
Notre façon de l'intégrer
Comment nous l'intégrons.
Une méthode en quatre temps, pensée pour qu'aucune décision sensible repose sur une seule personne.
Cadrer les règles, pas le code
Nous écrivons d'abord en français ce que le contrat doit garantir, et ce qu'il ne doit jamais permettre. Ce texte devient la référence des tests.
Composer avec des briques éprouvées
Nous partons des contrats OpenZeppelin pour les mécanismes standards (jeton, droits, pause) et n'écrivons à la main que la règle propre à votre activité.
Tester, simuler, relire
Tests automatisés, scénarios d'erreur, analyse statique, puis relecture croisée du code. Les résultats vous sont présentés point par point.
Déployer par paliers
Réseau de test d'abord, puis réseau principal avec des limites réduites avant ouverture. Nous pouvons coordonner la revue indépendante recommandée dès que des fonds sont en jeu ; nous ne la remplaçons pas.
Aller plus loin
De la technologie au projet.
La technologie se choisit après le besoin : voici les expertises qui portent le projet, et les technologies voisines à comparer.
Expertises métier
- Développement de smart contractsLa démarche complète, du cadrage aux tests et au déploiement, pour vos règles métier.
- Tokenisation d'actifsReprésenter des droits ou des actifs par des jetons, avec les restrictions de transfert adaptées.
- Portefeuilles et intégrations Web3Connecter le contrat à une interface et aux portefeuilles de vos utilisateurs.
- Sécurité et gouvernanceDroits d'administration, multi-signatures, revue indépendante et exploitation après mise en ligne.
Technologies voisines
Toutes les technologies du pôle
Questions fréquentes
Les questions qu'on nous pose sur Solidity.
Des réponses courtes, pour décider avant de lancer un chiffrage.
Sources
Fiche relue en novembre 2026.
Que change la version 0.8 de Solidity pour la sécurité ?
Depuis la version 0.8, le compilateur vérifie par défaut les opérations arithmétiques : un dépassement de capacité interrompt la transaction au lieu de produire silencieusement un résultat faux. Cela élimine une famille entière d'erreurs classiques, mais pas toutes : les règles d'accès, l'ordre des appels entre contrats et les hypothèses métier restent à relire.
Un contrat qui utilise OpenZeppelin est-il automatiquement sûr ?
Non. OpenZeppelin fournit des briques très utilisées et régulièrement relues, ce qui réduit fortement le risque sur les mécanismes standards. Mais la sécurité d'un contrat dépend aussi de la manière dont ces briques sont assemblées, des rôles attribués et de la règle métier ajoutée. C'est pourquoi nous testons le contrat entier et recommandons une revue indépendante dès que des fonds sont en jeu.
Quelle version de Solidity faut-il utiliser ?
Une version récente de la branche 0.8, fixée précisément dans le projet et accompagnée des notes de version consultées avant chaque montée de version. Une version trop ancienne prive des corrections du compilateur ; une version publiée la veille n'a pas encore été éprouvée. Pour un contrat qui gère de la valeur, nous privilégions une version déjà largement utilisée et documentée.
Solidity suffit-il pour réaliser une application complète ?
Non : Solidity ne couvre que les règles qui s'exécutent sur la chaîne. Une application complète demande aussi une interface, la connexion aux portefeuilles, un suivi des transactions et souvent un service qui lit et indexe les événements du contrat. Ces éléments relèvent de nos intégrations de portefeuilles et d'applications Web3.
Pouvez-vous reprendre ou relire un contrat écrit par un autre prestataire ?
Oui, sous réserve de disposer du code source et des instructions de déploiement. Nous commençons par une relecture : lisibilité, cohérence avec les règles attendues, droits d'administration, dépendances. Nous vous présentons des constats classés par priorité. Cette relecture n'est pas un audit de sécurité indépendant, et nous ne la présentons pas comme tel.
Un contrat à écrire, à relire ou à reprendre ?
Décrivez-nous les règles que votre contrat doit appliquer : nous vous disons si Solidity est le bon outil, et comment l'encadrer avant tout déploiement.