Déployer un smart contract sur testnet prend un après-midi. Amener un protocole sur mainnet — et l’y maintenir — prend des mois de discipline d’ingénierie que la plupart des équipes sous-estiment.
Nous avons déployé des protocoles DeFi, des systèmes de tokens et des dApps sur mainnet. Voici ce que nous avons appris sur l’écart entre « ça marche sur Goerli » et « ça gère 10M$ de TVL sur mainnet sans casser ».
Leçon 1 : La sécurité n’est pas une phase. C’est l’architecture.
Les bugs de smart contracts les plus coûteux ne sont pas dans le code. Ils sont dans la conception.
La réentrance, la manipulation d’oracles, les attaques par flash loan — ce ne sont pas des cas limites exotiques. C’est la surface d’attaque standard de tout protocole DeFi. Si votre architecture ne les prend pas en compte dès le premier jour, aucune quantité d’audit ne vous sauvera.
Notre approche : chaque contrat commence par un modèle de menaces. Avant d’écrire une seule ligne de Solidity, nous cartographions les vecteurs d’attaque. Que se passe-t-il si un oracle rapporte un prix obsolète ? Que se passe-t-il si un utilisateur appelle cette fonction de manière récursive ? Que se passe-t-il si les prix du gas sont multipliés par 10 pendant l’exécution ?
Le modèle de menaces façonne l’architecture. Pas l’inverse.
Leçon 2 : L’optimisation du gas est une décision de conception, pas une tâche post-construction
La disposition du storage compte. Une seule variable de stockage mal placée peut coûter des milliers en gas aux utilisateurs sur la durée de vie d’un contrat. Nous avons vu des protocoles où une simple restructuration du storage — empaqueter des variables liées dans un seul slot — a réduit les coûts de gas de 30 %.
Voici ce que nous optimisons au niveau de l’architecture :
Disposition du storage. Empaqueter les variables lues ensemble dans le même slot. Utiliser des mappings au lieu de tableaux quand c’est possible. Éviter le stockage de chaînes de caractères on-chain.
Conception des fonctions. Minimiser les appels externes. Regrouper les opérations quand c’est possible. Utiliser calldata au lieu de memory pour les paramètres en lecture seule.
Patterns d’événements. Émettre des événements au lieu de stocker des données dont vous n’avez besoin que pour l’indexation off-chain. Les événements coûtent une fraction des écritures en storage.
Patterns de proxy. Si le contrat a besoin d’upgradabilité, choisissez le bon pattern de proxy dès le départ. UUPS vs. Transparent Proxy vs. Diamond — chacun a des profils de gas et des compromis de sécurité différents.
Leçon 3 : La vérification formelle détecte ce que les tests manquent
Le fuzz testing est essentiel. Nous exécutons des milliers d’entrées aléatoires contre chaque fonction. Mais le fuzz testing est probabiliste — il trouve des bugs par chance, pas par preuve.
La vérification formelle est déterministe. Elle prouve mathématiquement que certaines propriétés sont toujours vraies. Nous utilisons une combinaison des deux. Ensemble, elles fournissent un niveau de confiance qu’aucune quantité de tests unitaires seuls ne peut égaler.
Leçon 4 : Les audits indépendants sont non négociables
Nous auditons nos propres contrats en interne. Puis nous les envoyons pour un audit indépendant. Toujours.
Budgétez 30K$ à 80K$ pour un audit indépendant approfondi d’un protocole de complexité moyenne. Oui, c’est cher. C’est aussi considérablement moins cher que l’exploit qu’il prévient.
Leçon 5 : Le monitoring en mainnet n’est pas optionnel
Le déploiement sur mainnet n’est pas la ligne d’arrivée. C’est la ligne de départ.
Nous mettons en place du monitoring pour chaque protocole que nous déployons : surveillance des transactions pour détecter des patterns inhabituels, vérification de la santé des oracles de prix, suivi de la profondeur de liquidité, anomalies de coûts en gas. Les 72 premières heures après le déploiement sur mainnet sont la période la plus risquée. Nous les monitorons en permanence.
Leçon 6 : L’upgradabilité est un compromis, pas une fonctionnalité
« Rendez-le upgradeable » est la demande la plus fréquente sur laquelle nous repoussons. L’upgradabilité ajoute de la complexité, augmente les coûts en gas et introduit un risque de centralisation.
Notre règle : si le contrat gère des fonds d’utilisateurs, l’immutabilité est le défaut. L’upgradabilité se mérite par un modèle de gouvernance clair, des mises à jour avec time-lock et des contrôles multi-sig.
Le vrai coût des raccourcis
Nous avons été engagés pour sauver des protocoles qui avaient sauté les audits, ignoré l’optimisation du gas et déployé sans monitoring. Le coût de la correction des problèmes a posteriori était de 3 à 5 fois ce qu’il aurait coûté de bien faire dès le départ.
Avec les smart contracts, vous ne pouvez pas pousser un hotfix. Le code est immuable. Les enjeux sont de l’argent réel. Et les utilisateurs ne pardonnent pas.