Le cahier des charges d'un smart contract est une spécification écrite qui indique aux développeurs et aux auditeurs ce que les contrats doivent faire, sur quelle blockchain, sous le contrôle de qui et avec quels livrables. C'est le document que vous joignez à un appel d'offres (souvent appelé RFP, pour « request for proposal »), et il conditionne la qualité de chaque devis reçu. Ce guide détaille chaque rubrique, les oublis les plus fréquents et la façon dont un document précis rend les devis comparables.
Pourquoi un cahier des charges est indispensable
Un cahier des charges est indispensable parce qu'un prestataire ne peut chiffrer et planifier que ce qu'il comprend, et qu'en matière de smart contracts chaque hypothèse non écrite devient soit un dépassement de budget, soit un risque de sécurité. Sans spécification, chaque développeur comble les vides à sa manière, et vous recevez des devis qui décrivent des projets différents.
Le document remplit quatre fonctions à la fois :
- Le chiffrage. Il donne à tous les prestataires la même base pour estimer l'effort.
- La contractualisation. Il sert de référence pour savoir ce qui est inclus dans la mission et ce qui relève d'une demande de modification.
- Le développement. Il oriente les choix de conception et les tests qui prouvent que les contrats se comportent comme prévu.
- L'audit. Il indique aux auditeurs ce que le code est censé faire. Les auditeurs recherchent les écarts entre le comportement attendu et le comportement réel : sans spécification, leur capacité de vérification est limitée.
Un cahier des charges n'est pas un dossier de conception technique. Vous décrivez le comportement, les règles et les contraintes ; les développeurs proposent l'architecture. Nul besoin de savoir coder pour bien le rédiger, en revanche il faut avoir pris des décisions.
Ce que doit contenir le cahier des charges
Un cahier des charges complet répond à douze questions, présentées ci-dessous dans l'ordre où les prestataires les lisent généralement. Des réponses courtes suffisent ; des réponses absentes, non.
1. Contexte et objectifs
Présentez le projet en quelques paragraphes : le problème résolu, pour qui, et pourquoi un smart contract est préférable à un système classique. Précisez l'objectif métier (lancer un jeton, ouvrir un marché de prêt, tokeniser un fonds) et ce qui constituera un succès au lancement.
2. Utilisateurs et rôles
Recensez chaque type d'acteur et ce qu'il peut faire. Les rôles habituels sont les utilisateurs finaux, les détenteurs de jetons, un propriétaire ou administrateur, des opérateurs (par exemple un responsable de la mise à jour des prix ou de la conformité) et d'autres contrats. Pour chaque rôle, indiquez qui le détient au lancement et s'il peut être transféré.
3. Exigences fonctionnelles
Formulez les règles sous forme d'énoncés précis : « Un utilisateur peut déposer des jetons à tout moment ; les récompenses s'accumulent à la seconde ; le retrait est possible après un blocage de 7 jours. » Décrivez le parcours normal, puis les exceptions : que se passe-t-il si un solde est nul, si une échéance est dépassée, si un transfert est refusé ? Numérotez les exigences pour faciliter les échanges et les tests.
4. Économie du jeton ou paramètres
Listez chaque valeur dont dépendent les contrats : offre totale, nombre de décimales, règles d'émission et de destruction, frais et bénéficiaires, calendriers d'acquisition (vesting), modèles de taux, ratios de garantie, plafonds et limites. Pour chaque paramètre, précisez s'il est figé au déploiement ou modifiable ensuite, et par qui.
5. Blockchain cible et standards
Nommez la ou les blockchains visées et les standards à respecter, comme ERC-20, ERC-721 ou ERC-1155 sur les réseaux EVM. Ce choix influe sur le langage, les outils, les auditeurs disponibles et le coût. Si vous n'avez pas encore tranché, dites-le et demandez aux prestataires une recommandation argumentée.
6. Intégrations
Listez tous les systèmes externes dont dépendent les contrats : oracles de prix, autres protocoles, bridges (ponts entre blockchains), portefeuilles, back-end ou indexeur, prestataires d'identité ou de conformité. Chaque intégration ajoute des hypothèses de fonctionnement et de défaillance qu'il faut spécifier et tester.
7. Pouvoirs d'administration et évolutivité
Indiquez ce que l'administrateur peut modifier, suspendre ou retirer, et comment ces pouvoirs sont protégés. Les contrats seront-ils évolutifs via un proxy, ou immuables ? Les actions d'administration passeront-elles par un portefeuille multisig et un timelock ? Existe-t-il une pause d'urgence, et qui peut la lever ? Cette rubrique est souvent la plus scrutée par les utilisateurs comme par les auditeurs, car elle définit le degré de confiance que le système exige.
8. Exigences non fonctionnelles
Précisez les objectifs d'optimisation du gas s'ils comptent, les contraintes de compatibilité (version du compilateur, choix de bibliothèques open source éprouvées), les conventions de code, les exigences de documentation (par exemple des commentaires NatSpec sur les fonctions publiques) et les contraintes réglementaires, comme des restrictions de transfert ou une liste d'investisseurs autorisés.
9. Livrables
Énumérez ce que vous attendez : le code source dans un dépôt que vous contrôlez, les scripts de déploiement, la documentation technique, une suite de tests avec rapport de couverture, un déploiement sur testnet puis sur le réseau principal et, le cas échéant, une interface web ou un back-end. Précisez la licence et la propriété du code.
10. Tests
Fixez le niveau de tests minimal : des tests unitaires pour chaque fonction, des tests d'intégration pour les parcours complets et, pour une logique financière complexe, du fuzzing et des tests d'invariants (des propriétés qui doivent toujours rester vraies, comme « le total des dépôts égale la somme des soldes utilisateurs »). Indiquez la couverture attendue et demandez que les tests s'exécutent automatiquement.
11. Attentes d'audit
Indiquez que le code sera audité par une société indépendante qui ne l'a pas développé, et ce que cela implique pour les développeurs : un gel du code sur un commit identifié, une documentation remise aux auditeurs, une disponibilité pour répondre à leurs questions et du temps pour corriger les constats avant le réaudit. Définissez le périmètre d'audit attendu si vous le connaissez déjà. Gardez à l'esprit qu'un audit réduit le risque mais ne garantit pas l'absence de bugs.
12. Calendrier et budget
Donnez vos dates cibles (testnet, début de l'audit, lancement sur le réseau principal) et une fourchette de budget. Annoncer une fourchette n'affaiblit pas votre position : cela permet aux prestataires de proposer un périmètre réaliste au lieu de deviner. Prévoyez le budget d'audit à part, en plus du développement.
Les oublis les plus fréquents
Les oublis les plus fréquents concernent ce qui paraît évident au client et n'est donc jamais écrit. Le tableau ci-dessous reprend ceux qui provoquent le plus souvent des devis divergents ou des constats d'audit.
| Oubli | Conséquence |
|---|---|
| Pouvoirs d'administration flous | Les prestataires supposent des modèles de contrôle différents ; les auditeurs ne peuvent pas juger si un pouvoir est voulu |
| Paramètres « à définir » | L'effort ne peut pas être estimé, et les changements tardifs touchent du code déjà testé |
| Cas limites ignorés | Soldes nuls, arrondis, états de pause et échéances dépassées concentrent une grande partie des bugs |
| Aucune exigence de tests | La qualité des offres varie fortement, et des tests faibles alourdissent le coût de l'audit |
| Évolutivité non tranchée | Elle modifie l'architecture, le déploiement et l'effort d'audit |
| Intégrations non listées | Chaque oracle ou protocole externe ajoute un travail et un risque que personne n'a chiffrés |
| Audit non planifié | Le calendrier ne laisse pas de place à l'audit, aux corrections et au réaudit |
| Interface web non mentionnée | Certains devis l'incluent, d'autres non, et les prix deviennent incomparables |
Un test simple : demandez à une personne extérieure au projet d'expliquer ce que font les contrats et qui les contrôle. Chacune de ses questions signale une rubrique manquante.
Comment un bon cahier des charges rend les devis comparables
Un cahier des charges précis rend les devis comparables parce que tous les prestataires chiffrent le même périmètre, les mêmes livrables et les mêmes hypothèses : les écarts de prix reflètent alors des différences d'approche, et non d'interprétation.
Pour en tirer le meilleur parti :
- Imposez un format de devis commun. Demandez les mêmes rubriques à chaque prestataire : prix et devise, durée, composition de l'équipe, périmètre détaillé, hypothèses, exclusions et suites prévues après l'audit.
- Demandez aux prestataires d'expliciter leurs hypothèses. Là où le document est muet, chacun fera un choix. Rendre ces choix visibles permet de les repérer et de les trancher.
- Tenez une version unique. Si vous précisez un point pour un prestataire, transmettez la précision à tous.
- Séparez développement et audit. Envoyez d'abord le cahier des charges aux développeurs. Une fois le code prêt, le même document, mis à jour avec la conception finale, sert de base aux devis d'auditeurs indépendants.
Le guide comparer des devis de smart contract explique comment analyser les réponses reçues. Pour vérifier qu'un devis se situe dans une fourchette plausible avant de négocier, le calculateur de coût de développement applique le modèle public du site ; ses chiffres sont indicatifs et les devis réels dépendent du périmètre.
Rédiger le document en pratique
La méthode la plus rapide consiste à répondre à un questionnaire structuré, puis à transformer les réponses en un document aux exigences numérotées. La plupart des porteurs de projet peuvent produire une première version en quelques heures si les décisions clés ont déjà été prises.
Une démarche concrète :
- Rédigez d'abord le contexte et la liste des rôles : ils cadrent tout le reste.
- Écrivez les règles fonctionnelles sous forme d'énoncés courts et numérotés, en commençant par le parcours principal.
- Réunissez tous les paramètres dans une seule liste, avec leur valeur ou leur fourchette.
- Arrêtez le modèle d'administration et d'évolutivité avant de contacter les prestataires.
- Ajoutez livrables, tests, attentes d'audit, calendrier et budget.
- Faites relire le projet par une personne technique pour repérer contradictions et cas limites oubliés.
Le générateur de cahier des charges suit cette structure et produit un document à envoyer comme appel d'offres. Sur smart-contract.com, ce document sert aussi à demander des devis au même format à des développeurs, puis à des auditeurs indépendants sans engagement de développement sur le même projet.
À retenir
- Le cahier des charges d'un smart contract décrit le comportement, les rôles, les paramètres, le contrôle et les livrables ; les développeurs proposent l'architecture.
- Pouvoirs d'administration, évolutivité, paramètres et cas limites sont les rubriques les plus souvent absentes et les plus déterminantes pour la sécurité.
- Les attentes de tests et d'audit ont leur place dans le document dès le départ, avec du temps et du budget pour les corrections et le réaudit.
- Un format de devis commun et des précisions partagées avec tous rendent les devis comparables : les écarts de prix traduisent l'approche, pas l'interprétation.