La plupart des fondateurs pensent que la sécurité se limite à sécuriser le contrat intelligent. Mais voici quelques mythes courants contre la réalité que chaque fondateur doit comprendre. > Mythe : Dès que nous avons passé une audit, nous sommes sécurisés. Réalité : Selon moi, c’est l’un des plus grands malentendus dans Web3. Une audit n’est pas un certificat de sécurité, c’est un examen de votre code à un moment précis. Dès que vous déployez une nouvelle fonctionnalité, intégrez un autre protocole, mettez à jour un oracle ou modifiez votre infrastructure backend, votre profil de risque change. Une audit aide à réduire les risques, mais chaque mise à jour ultérieure mérite le même niveau d’attention. > Mythe : Les pirates n’exploitent que les contrats intelligents. Réalité : Je ne pense plus que ce soit vrai. Ce que nous avons observé ces dernières années, c’est que certaines des plus grandes pertes ne proviennent pas de bugs Solidity, mais de clés privées compromises, de phishing, d’échecs de contrôle d’accès, d’infrastructure backend, de signataires d’oracle et d’erreurs opérationnelles. Votre frontend, vos API, votre pipeline de déploiement, vos wallets et votre infrastructure font tous partie de votre surface d’attaque. À mon avis, les fondateurs doivent penser au-delà du contrat intelligent. Votre infrastructure, vos clés et vos processus opérationnels sont tout aussi importants. > Mythe : Nous sommes trop petits pour être une cible. Réalité : Les attaquants ne se soucient généralement pas du nombre de suivants que votre projet a. Ils ne se préoccupent que d’une chose : pouvoir extraire de la valeur. Si votre protocole détient des actifs ou possède des utilisateurs, vous êtes déjà intéressant pour quelqu’un. Attendre d’être suffisamment grand pour investir dans la sécurité est souvent trop tard. > Mythe : Un seul signataire ou clé d’administration fiable suffit. Réalité : Selon moi, chaque clé privilégiée doit être traitée comme votre trésorerie. Les clés d’oracle, les clés de déploiement, les clés de mise à niveau, les signataires multisig, les identifiants backend — chacune d’elles peut devenir un point unique de défaillance. Une seule clé compromise peut mettre en péril l’ensemble du protocole. > Mythe : Nous améliorerons la sécurité après le lancement. Réalité : Les attaquants n’attendront pas ce moment. Les fondateurs pensent souvent qu’on peut ajouter la sécurité lors des itérations suivantes. Malheureusement, les exploits ne suivent pas les calendriers produits. Le meilleur moment pour mettre en place la surveillance, la réponse aux incidents et la sécurité opérationnelle est avant que les utilisateurs ne vous confient leurs actifs. > Mythe : Les tests internes suffisent. Réalité : Votre équipe connaît le fonctionnement attendu du protocole. Un chercheur externe pense à la manière dont il peut échouer. C’est pourquoi les audits, les revues concurrentes, les programmes de bug bounty et les tests continus jouent tous des rôles différents. La sécurité bénéficie de perspectives fraîches. > Mythe : Le code ouvert signifie que quelqu’un trouvera les bogues. Réalité : Le code ouvert améliore la transparence. Il ne garantit pas que quelqu’un examinera chaque ligne de code ou signalera responsablement chaque vulnérabilité. Publier du code n’est pas équivalent à le valider. > Mythe : La sécurité est la responsabilité de l’auditeur. Réalité : C’est probablement le changement mental le plus important que les fondateurs doivent adopter. Les auditeurs aident à réduire les risques. Mais la sécurité est construite par tous : les fondateurs prenant des décisions produit, les développeurs écrivant le code, les équipes DevOps gérant l’infrastructure et les équipes opérationnelles protégeant l’accès. J’ai toujours cru que la sécurité n’est pas quelque chose que l’on termine — c’est quelque chose que l’on améliore continuellement. Conclusion finale : Le paysage de la sécurité a changé. Et je crois que notre mentalité en matière de sécurité doit évoluer avec lui. Il ne suffit plus de se concentrer uniquement sur les contrats intelligents. En tant que fondateurs, nous devons penser à sécuriser l’ensemble du protocole — des contrats et de l’infrastructure aux clés, aux contrôles d’accès et à chaque système qui maintient le protocole en fonctionnement.