Avant les mots, la preuve. Voici VoteChain — une application de vote sur la blockchain Ethereum, qui tourne sur Android et iOS, codée à 100 % en Kotlin Multiplatform. Le résultat de plusieurs mois de soirées de code. Regarde d’abord, je t’explique tout ensuite.
Le 20 janvier 2025, je me lançais un défi ambitieux : mon challenge Kotlin Multiplatform : coder une application Android et iOS partagée en KMP, plus un smart contract sur la blockchain Ethereum. En 6 mois. Sans écrire une seule ligne de Swift.
Nous sommes en juillet 2026. Le challenge est terminé.
Oui, tu as bien compté. 18 mois au lieu de 6.
Et pourtant, je te le dis sans détour : je considère ce challenge comme une réussite. Pas malgré le retard — avec le retard. Parce qu’entre la ligne de départ et la ligne d’arrivée, la vraie vie s’est invitée. Et c’est précisément ce qui rend ce bilan intéressant.
Voici tout ce que j’ai livré, tout ce qui a été difficile, et tout ce que j’en retire. Sans filtre.
Ce que j’ai livré
Commençons par le concret. À l’arrivée :
Une application Android et iOS, 100 % Kotlin Multiplatform. Elle s’appelle VoteChain. Logique métier partagée, UI en Compose Multiplatform sur les deux plateformes. Elle tourne sur iOS. Et je n’ai pas écrit une seule ligne de Swift — j’y reviens plus bas, parce qu’il y a une petite subtilité.
Un smart contract de vote, écrit en Solidity et déployé sur le testnet Sepolia. VoteChain permet de réaliser des votes directement sur la blockchain Ethereum. L’idée m’est venue naturellement : les élections présidentielles françaises approchent en 2027, et je me suis demandé à quoi ressemblerait un vote infalsifiable, transparent, vérifiable par tous. Plutôt que d’en débattre, je l’ai codé.
Une stack digne de la production, appliquée à un projet personnel. Coroutines, Koin pour l’injection de dépendances, Napier pour le logging multiplatform, ethers.kt pour l’interaction Ethereum côté Android, web3swift côté iOS, Reown (WalletConnect) pour la connexion wallet, Hardhat côté smart contract. Les mêmes exigences que celles que j’ai connues chez Coyote, Deezer et Ledger — appliquées à un projet personnel.
Une architecture multi-module, avec des plugins Gradle précompilés. Même en solo, j’ai structuré VoteChain comme un projet d’équipe : modules découpés par responsabilité, configuration Gradle centralisée dans des plugins précompilés — la même approche que je défendais dans cet article. Parce qu’une bonne architecture est ce qui te permet de reprendre le code après trois semaines d’interruption sans tout relire. Sur un projet mené quelques soirs par semaine, c’est elle qui a sauvé le challenge.
Une transparence s’impose quand même : tous les cas d’erreur ne sont pas gérés. Une transaction qui échoue en plein milieu, un wallet qui se déconnecte au mauvais moment. C’est un choix délibéré : sur un projet solo aux soirées comptées, j’ai priorisé le chemin nominal de bout en bout plutôt qu’une gestion d’erreurs exhaustive sur un périmètre réduit. En production, ce serait l’inverse.
Autre limite : côté iOS, je n’ai pas pu tester le flow de vote de bout en bout. Je n’avais que le simulateur et impossible d’y installer MetaMask pour signer une transaction réelle. L’app tourne sur iOS, l’UI et la logique partagée sont validées, mais la signature de bout en bout n’a été vérifiée que sur un appareil Android physique.
Quand la vraie vie s’invite dans ton challenge
Pourquoi 18 mois au lieu de 6 pour ce challenge Kotlin Multiplatform ?
Parce qu’entre-temps, je suis devenu papa. Et j’ai déménagé.
Je pourrais te sortir l’excuse classique — « je n’avais plus le temps ». Ce serait faux. Le temps existait toujours. Il avait juste changé de forme : quelques soirs par semaine, une fois la maison endormie. Fini les longues sessions de code du week-end.
Et c’est là que j’ai appris quelque chose d’important : ce qui fait tenir un projet sur la durée, ce n’est pas la motivation. C’est la discipline.
Deux choses m’ont permis d’aller au bout.
La première : j’avais promis. Publiquement, ici même, sur ce blog et sur mes réseaux sociaux. Abandonner, c’était trahir ma parole. Et ça, ce n’était pas négociable.
La seconde : j’ai traité ce projet perso comme un projet professionnel. Une liste de tâches, la même méthode de gestion de projet que j’applique en entreprise. Chaque soir, pas besoin de réfléchir à quoi faire : la liste le savait déjà.
Le challenge a pris du retard. Il n’a jamais été abandonné.
Le mur : appeler du Swift depuis Kotlin Multiplatform
Venons-en au moment le plus dur du challenge.
Pour interagir avec Ethereum côté Kotlin, j’utilise ethers.kt. Une excellente librairie avec un défaut bloquant pour mon projet : à ce jour, elle n’est compatible qu’Android.
Côté iOS, il me fallait une alternative. La référence s’appelle web3swift, une librairie qui n’est d’ailleurs plus maintenue aujourd’hui. Et comme son nom l’indique, elle est écrite en Swift.
Tout développeur KMP voit le problème arriver : Au moment où j’écris cet article, Kotlin Multiplatform ne sait pas appeler du Swift directement. L’interop Kotlin/Native est en Objective-C, pas en Swift.
La solution ? Écrire des wrappers Objective-C qui exposent les fonctionnalités Swift dans un format que KMP peut consommer, et intégrer les Swift Packages dans le build Gradle grâce au plugin spmForKmp.
Pour être honnête avec toi, écrire ces wrappers a été pénible. Quand quelque chose ne fonctionnait pas, le débogage était une plaie : des erreurs de compilation, des headers qui ne se génèrent pas, des types qui ne traversent pas la frontière Kotlin/Objective-C comme prévu. Et aucun message d’erreur pour te dire où chercher. Des soirs entiers ont disparu là-dedans.
Mais le mur est tombé. Et l’histoire ne s’arrête pas là : j’aide aujourd’hui le mainteneur d’ethers.kt à migrer la librairie vers Kotlin Multiplatform.
Tu commences par contourner une limite, tu finis par contribuer à la supprimer.
La surprise que je n’avais pas vue venir
Avant de commencer, je pensais que le smart contract serait la partie la plus difficile. Territoire inconnu, nouveau langage, nouveau concept, nouvelle techno.
Erreur.
La vraie difficulté s’est cachée dans ma zone de confort : l’intégration iOS de Reown (WalletConnect) dans Compose Multiplatform. Cette librairie fournit une modale native pour connecter un wallet comme MetaMask.
Sur Android, intégration classique. Sur iOS, faire cohabiter une modale native avec une UI entièrement en Compose Multiplatform, c’est une autre histoire.
Un mot sur le choix du wallet, d’ailleurs. Pour signer les transactions de vote, j’ai utilisé MetaMask et pas un Ledger. L’ironie : j’ai contribué chez Ledger au SDK Kotlin Multiplatform qui permet justement de signer des transactions avec un hardware wallet… mais à ce jour, il n’est pas encore release.
C’est la leçon de ce challenge : ce ne sont pas les technologies que tu ne connais pas qui te bloquent le plus longtemps. Ce sont les combinaisons que personne n’a documentées.
L’accélérateur que je n’attendais pas : l’IA
Il y a un facteur qui a littéralement changé la donne de ce challenge : les outils d’IA.
Soyons précis, parce que le sujet mérite d’être éclairci. L’IA ne fait pas le travail à ta place. Elle ne conçoit pas ton architecture, elle ne choisit pas le découpage de tes modules, elle ne sait pas pourquoi ton wrapper Objective-C doit exposer telle signature plutôt que telle autre.
Et surtout : quand elle génère du code qui viole des principes d’architecture, c’est l’expérience qui le voit immédiatement. Sans elle, tu acceptes tout, y compris les erreurs.
Mais quand tu sais exactement ce que tu veux construire, elle exécute à une vitesse redoutable. Le boilerplate, les explorations de doc, les premières versions d’un écran Compose : ce qui me prenait un soir entier ne me prenait que quelques minutes.
L’IA n’a pas remplacé mes 10 ans d’expérience. Elle les a démultipliés. C’est toute la différence entre un développeur qui pilote et un prompteur qui espère. Sans elle, ce challenge aurait probablement pris 24 mois au lieu de 18.
Alors, cette promesse « zéro Swift » ?
Tenue. Zéro ligne de Swift écrite en 18 mois.
Par contre, et c’est ma confession de ce bilan. J’ai écrit de l’Objective-C en 2026.
C’est ça, un vrai projet : tu pars avec un plan, et la réalité technique t’oblige à t’adapter.
Ce que je retiens — et ce qui arrive ensuite
Trois leçons de ces 18 mois de challenge Kotlin Multiplatform :
Un challenge ne se juge pas à sa deadline, mais à sa ligne d’arrivée. Devenir papa et déménager en plein milieu aurait pu tout arrêter. La discipline des petits pas a tenu.
KMP tient sa promesse — jusque dans les cas difficiles. Une app iOS complète, une modale wallet native, une lib Swift intégrée : tout est passé, sans quitter l’écosystème Kotlin.
L’IA est un multiplicateur d’expertise, pas un substitut. Elle a compressé 24 mois en 18. Mais c’est l’expérience qui dirige, elle qui exécute.
Ce bilan n’est que le début. C’est ici que je partagerai tout ce que ce challenge m’a appris.
➡️ Rejoins la newsletter. Reçois du contenu que tu ne trouveras nulle part ailleurs.
