Comment devenir développeur Ethereum ? A quelles difficultés faut-il s’attendre ? Retour sur le parcours et l’expérience de Jonathan Serra, formateur Ethereum de l’équipe !
Bonjour Jonathan ! Est-ce que tu pourrais te présenter en quelques phrases à nos lecteurs ?
Bonjour les lecteurs du JDC ! On me connaît peut-être déjà par ma présence sur YouTube avec la chaîne Blocs où je parle de cryptomonnaie en couvrant l’aspect technique mais aussi certains concepts sur l’économie et la monnaie. Au delà de la chaîne je suis ingénieur logiciel indépendant, diplômé de l’UTT, j’ai toujours eu un vif intérêt et une grande curiosité pour l’informatique et les sciences. C’est ce qui m’a conduit à m’intéresser en profondeur à Bitcoin et Ethereum en particulier.
La plupart d’entre nous t’ont découvert sur Youtube, car tu as été le premier à présenter des cryptomonnaies en analysant en profondeur les aspects les plus techniques. Quand as-tu commencé à t’intéresser aux blockchains et pourquoi ?
La première fois où j’avais entendu parler de Bitcoin ou plus précisément de la preuve de travail, c’était selon ces termes :
“On peut gagner de l’argent en faisant des calculs avec son ordinateur, c’est cool !”
C’était en 2011, une époque où le cloud computing faisait les titres dans les presses spécialisées, alors à ce moment on pouvait vite associer Bitcoin à de la ressource partagée en cloud avec rémunération. C’est évidemment une toute autre réalité et c’est quand je m’en suis rendu compte en fin 2015 que j’ai décidé de l’étudier sérieusement. Plus on creuse le sujet, plus on se rend compte des domaines que couvre la cryptomonnaie : réseau décentralisé, protocole, cryptographie, principes de la monnaie, droit des contrats. C’est convaincu par la nécessité d’en parler que j’ai décidé de produire des vidéos sur YouTube.
Quelles sont les principales difficultés que tu as rencontrées quand tu as commencé à développer des applications décentralisées ?
Le plus compliqué est d’assembler toutes les connaissances techniques car développer une dApp nécessite de savoir programmer et être habile avec ce qui a attrait au réseau informatique. Il ne faut pas oublier qu’une dApp respecte un protocole P2P (peer-to-peer) et cela a des implications diverses et variées sur les manières de concevoir un tel programme.
La difficulté qui découle du premier défi est l’absence de contenu pédagogique digne de ce nom qui couvre tous ces sujets. Tous sont en anglais, et surtout aucun ne couvre entièrement les notions importantes pour bien développer une dApp.
Qu’est-ce qui t’as poussé à créer ta première dApp sur Ethereum ?
Encore et toujours la curiosité. La première fois que j’ai ouvert Remix, je l’ai fermé 1 minute après et j’ai fait un café pour méditer. L’interface était indigeste et je n’ai pas tout compris malgré mes compétences en programmation.
Créer une première dApp n’a rien de facile. Il faut d’abord savoir fondamentalement ce que c’est qu’une dApp, et surtout pourquoi une dApp est une dApp, ce qui revient à comprendre les fondamentaux de la technologie blockchain. Ensuite il faut se familiariser avec l’écosystème Ethereum : qu’est qu’un “account” ? Qu’est qu’un “provider” ? Qu’est ce que l’”EVM” ? Comment on déploie en contrat ? etc.
C’est seulement après ces premières prises de conscience qu’on peut ouvrir Remix et écrire du code tout en apprenant Solidity qui est aujourd’hui le langage le plus répandu.
Mon premier contrat a été une loterie avec une génération de nombres aléatoire totalement hackable… Naïvement on croit qu’une dApp peut générer des nombres de manière totalement aléatoire que personne ne peut prédire, mais c’est faux, cela est impossible sans l’utilisation des oracles.
J’ai axé mon apprentissage sur Ethereum, qui est le premier protocole à proposer un système de langage complet (turing complet) pour exécuter des contrats, en d’autres termes, autrement dit le premier à permettre de réaliser des programmes décentralisés. Il tire de sa primauté une communauté imposante et constamment active. De ce fait les outils de l’écosystème d’Ethereum sont pléthores et sont pour la plupart maintenus à jour. Il existe par ailleurs beaucoup de ressources pour chacun de ces outils.
Avec une telle réputation, Ethereum tire également une certaine aura auprès des entreprises. Il n’est pas rare que la demande client tourne autour d’Ethereum pour la simple raison qu’ils en ont entendu parler.
Si tu devais commencer à t’intéresser au développement de dApps sur une autre blockchain, laquelle choisirais-tu ? Pourquoi ?
Je serais assez partagé. Ma première réponse serait Rootstock avec Bitcoin. La raison est simple : Bitcoin bénéficie déjà d’une communauté d’experts et de passionnés alors par transitivité Rootstock en bénéficie tout autant. Rootstock est une technologie de sur-couche qui permet de créer des programmes complets en s’appuyant sur le protocole de Bitcoin. Mais le développement de Rootstock en est encore à ses débuts, même si l’on peut déjà tester cette plateforme.
Ma seconde réponse serait Cardano et Lisk. Lisk, car je trouve la technologie intéressante et élégante. Et Cardano pour le choix du langage Haskell, mais pas uniquement. La communauté autour de Cardano est composée d’experts notoires. Bien que cela ne signifie pas nécessairement que ce sera la solution ultime, cela reste un bon indicateur. Cardano a une approche unique, qui ressemble un peu à ce que propose EOS, pour la gestion des comptes.
Il est toujours difficile de commencer en tant que développeur, principalement parce qu’on passe l’essentiel de son temps à débogguer… Certains le vivent très mal et ont peur d’être « moins forts » ou « moins intelligents » que les autres développeurs. Quels conseils donnerais-tu à ceux qui débutent pour garder confiance en eux et rester sereins pendant leur apprentissage ?
Voilà ma réponse : lisez Nietzsche. C’est un sujet qui m’a toujours intéressé, faut-il être talentueux ou persévérant pour exceller dans la programmation ? En d’autres termes, faut-il être génial ou travailleur ? Voilà un aphorisme tiré du livre Humain trop humain de F. Nietzsche qui parle précisément de cela :
“Ne venez surtout pas me parler de dons naturels, de talents innés ! On peut citer dans tous les domaines de grands hommes qui étaient peu doués. Mais la grandeur leur est “venue”, ils se sont faits “génies” (comme on dit) grâce à certaines qualités dont personne n’aime à trahir l’absence quand il en est conscient. Ils possédaient tous cette solide conscience artisanale qui commence par apprendre à parfaire les parties avant de se risquer à un grand travail d’ensemble ; ils prenaient leur temps parce qu’ils trouvaient plus de plaisir à la bonne facture du détail, de l’accessoire, qu’à l’effet produit par un tout éblouissant.”
Pour apprendre à développer, ne vous concentrez jamais sur le résultat attendu. N’apprenez pas à développer pour attaquer au plus vite des projets grandiloquents, apprenez à développer en perfectionnant des détails, soyez artisans, multipliez vos projets, cela s’applique à tous les niveaux.
Mettons que vous vouliez apprendre à développer une dApp qui gère des messages qu’on récompense avec de la valeur, un grand projet en somme ; la meilleure approche que je pourrais vous conseiller, et selon votre niveau, c’est de commencer par apprendre à faire une dApp qui permet d’échanger de la valeur. C’est un projet plus simple et que vous pourrez parfaire. Après ce premier projet, vous pouvez faire une dApp qui gère des messages. Ainsi, vous aurez appris à bien faire une dApp d’échange de valeurs, et une dApp de messages : vous pouvez associer les deux pour attaquer le travail d’ensemble.
Par conséquent le débogage est une étape obligatoire vers le chemin de la perfection; vos bugs sont des opportunités pour parfaire vos compétences et acquérir de nouvelles connaissances. C’est un point crucial que j’aimerais qu’on comprenne car je l’ai compris assez tard.
Si tu devais recommencer ton processus d’apprentissage pour aller le plus rapidement possible, que changerais-tu pour t’éviter certaines erreurs ?
En tant qu’apprenant j’ai longtemps trainé un boulet qui se résume en la recherche de légitimité. Alors j’ai procédé avec une méthode assez lourde qui était de cerner la théorie avant d’attaquer la pratique. J’estimais que la légitimité s’acquiert par l’intégration de la théorie avant tout. Je vous le dis par expérience : ce n’est pas efficace pour apprendre quelques chose qui demande de fortes compétences pratiques comme la programmation.
Loin de moi l’idée que la théorie soit inutile, mais j’estime qu’apprendre en commençant par là est coûteux en énergie et en temps, et peut même parfois démotiver — une fois j’ai voulu apprendre la mécanique classique, puis quantique, en regardant les conférences de Susskind à Stanford, j’ai arrêté après 2 semaines. À mon sens il faut avoir une approche artisanale dans la programmation, on commence par faire un mauvais programme, on le perfectionne ensuite. C’est pendant l’étape du perfectionnement qu’on a une fenêtre pour assimiler la théorie et c’est précisément à ce moment que le EURÊKA fait écho.
C’est quelque chose que j’ai compris assez tard, mais étant toujours frustré d’abandonner des projets en cours, car trop complexes, j’ai fini par comprendre que mon problème résidait dans la méthode. J’ai alors créé une formation sur la programmation de dApp avec Ethereum avec cette approche méthodique qui me semble être la plus efficace : on pratique, on assimile la théorie qui découle de la pratique et on pratique encore. Je l’ai également conçu avec l’idée de pousser à perfectionner son programme.
Le métier de formateur est une casquette très différente de celle du développeur pur et dur. Qu’est-ce qui te plaît le plus dans ce métier ?
Lorsqu’on programme, on s’approprie la plupart des connaissances directement sur Internet. Que ce soit via des formations, des ressources libres, des discussions autour de certains bugs, etc. C’est un stéréotype qui a tendance à se confirmer, les programmeurs ne sont jamais les meilleurs communicants ni même les meilleurs pédagogues. Pourtant un expert dans un domaine peut être un excellent pédagogue, je peux évoquer Docteur R. Feynman par exemple. Etre bon pédagogue n’est pas en relation directe avec les compétences dans le domaine, tout dépend de l’effort que l’on fournit pour donner forme à des sujets aux apparences sinueuses.
J’ai alors souhaité m’attaquer à ce sujet : ajouter de l’harmonie là où tout semble alambiqué. L’informatique c’est exactement ça, quiconque ayant un regard extérieur y verrait un labyrinthe insondable à l’image des cartes imprimées. L’ingrédient toujours manquant pour que tout cela fasse sens est la forme. Donner de la forme à ce qui est parfois abstrait partage des connexions avec la programmation. Lorsque je fais une formation, j’ai l’impression de programmer à l’envers : quand on programme on fait abstraction; quand on forme on concrétise.
