AbcDonjon vivait sur iOS seul depuis son lancement. Le 8 août 2026, la fiche Google Play est passée en ligne et le jeu est devenu disponible sur les deux plateformes. Vu de l'extérieur, ça ressemble à un clic : cocher une case, exporter un second binaire, attendre la review. Ce n'est pas ce qui s'est passé. Entre le moment où le projet a été prêt à recevoir une identité Android et la mise en ligne effective, il s'est écoulé plus de six semaines — et l'essentiel de ce temps n'a rien à voir avec Google qui traîne des pieds.

Le premier blocage : un identifiant qui n'a jamais existé

Un projet Flutter généré par défaut porte un applicationId de la forme com.example.abecedonjon. Ça compile, ça tourne en debug, et le Play Store le refuse net : com.example.* est un identifiant de gabarit, pas une identité d'app. Il a fallu le remplacer par the_dead_masked_company.abcdonjon — un identifiant permanent, qui ne peut plus changer une fois la première publication faite, puisque c'est lui qui relie toutes les mises à jour futures à la même fiche Play Store.

C'est un détail de configuration Gradle, une ligne dans build.gradle.kts. Mais c'est aussi une décision qu'on ne peut prendre qu'une fois : se tromper d'identifiant au premier envoi, c'est repartir de zéro sur le Store — nouvelle fiche, nouveaux avis, nouvel historique. Sur iOS, le bundle identifier pose le même genre de contrainte, mais AbcDonjon l'avait déjà réglé au premier envoi App Store ; il fallait simplement refaire ce même choix, une deuxième fois, pour une plateforme différente, avec une convention de nommage différente.

Signer sans perdre la clé

Contrairement à iOS où Xcode et App Store Connect gèrent une bonne partie de la signature, Android demande de générer soi-même un keystore et de le protéger : c'est la même clé qui doit signer chaque mise à jour du jeu pour le reste de sa vie sur le Store. Perdre ce fichier, c'est perdre la capacité de publier une mise à jour sous la même fiche.

Le projet gère ça via un fichier key.properties, gardé hors du dépôt Git, qui référence le keystore et ses mots de passe. Le build.gradle.kts lit ce fichier s'il existe et signe en release avec ; s'il est absent — en CI, ou pour un contributeur qui clone le dépôt — la config retombe sur la signature de debug, pour que le projet continue à compiler sans exposer la clé de production à qui que ce soit.

« Sur iOS, la plateforme signe pour vous. Sur Android, la clé qui signe chaque mise à jour, c'est vous qui la générez, et vous qui devez ne jamais la perdre. »

Une exigence externe, avec une date limite

Un troisième obstacle est arrivé de l'extérieur. Google impose que toute application publiant une mise à jour à partir du 31 août 2026 cible une version de la Play Billing Library égale ou supérieure à 8.0.0 — la bibliothèque qui gère les achats intégrés. AbcDonjon utilise purchases_flutter (RevenueCat) pour son achat unique premium, et la version alors installée, la 8.x, résolvait encore un client de facturation plus ancien.

La mise à jour vers purchases_flutter 10.4.2 a réglé le problème — elle cible la variante qui résout com.android.billingclient:billing en version 8.3.0 — mais elle a aussi changé l'API d'achat elle-même : Purchases.purchasePackage() est dépréciée au profit de Purchases.purchase(PurchaseParams.package(...)), qui renvoie directement les informations client à jour et évite un aller-retour réseau supplémentaire pour les récupérer. Un changement de dépendance mineur en apparence, qui a fini par toucher le code d'achat du jeu.

Ce que Fastlane ne fait pas

AbcDonjon a un Fastfile qui automatise l'envoi des métadonnées vers App Store Connect — descriptions, notes de version, texte promotionnel, par langue et par version, avec des garde-fous qui refusent de publier si une note de version manque pour la version ciblée. Ce fichier ne déclare qu'une seule plateforme : default_platform(:ios), et un unique bloc platform :ios do. Il n'existe aucune plateforme Android dans ce dépôt.

Ça ne veut pas dire que rien n'était en place côté Android : la signature de release et l'identifiant d'application, eux, étaient prêts (voir plus haut). Mais l'automatisation qui pousse fiche produit, textes localisés et notes de version sur le Play Store, celle qu'a reçue iOS, n'a pas d'équivalent ici pour l'instant. La différence entre « le projet peut construire un binaire Android signé » et « le projet sait publier sur Android tout seul » n'était pas encore comblée le jour de la sortie — et ne l'est toujours pas.

Remettre à jour le site sans réécrire l'histoire

Le devlog publié le 22 juin 2026 sur la conception d'AbcDonjon disait, à l'époque, que « la version Android est en préparation ». C'était vrai au moment où c'était écrit. Plutôt que de corriger discrètement cette phrase une fois Android sorti — ce qui aurait fait mentir la date de publication de l'article sur son propre contenu — le texte original a été conservé tel quel, et une note d'actualisation datée du 8 août 2026 a été ajoutée en dessous, disant explicitement que le paragraphe au-dessus reste tel qu'il a été écrit à l'époque.

L'appel à l'action en pied du même article, lui, a changé sans note : « Android bientôt » a été remplacé par le badge Google Play. La différence tient dans ce que chaque bloc représente — un paragraphe daté est un témoignage à un instant donné, un bouton de téléchargement est un chemin de conversion vivant, pas une archive. Le même traitement n'a pas de sens pour les deux.

La fiche du jeu elle-même a suivi le même mouvement : badge Google Play à côté du badge App Store, mention « Android bientôt » retirée, description et données structurées mises à jour pour citer les deux plateformes, et le schéma VideoGame qui passe d'une seule URL d'achat à un tableau des deux boutiques.

Ce qui reste pour la suite

Le lexique et l'équilibrage du jeu ne changent pas d'une plateforme à l'autre — c'est le même moteur, les mêmes grilles, les mêmes langues. Ce qui change, c'est tout ce qui entoure le jeu : une identité d'app qu'on ne peut fixer qu'une fois, une clé qu'on ne peut pas perdre, une bibliothèque de facturation que Google impose de mettre à jour avant une échéance qu'on n'a pas choisie, une automatisation à écrire pour la deuxième boutique. Rien de tout ça n'est visible dans le jeu que le joueur télécharge.

C'est la différence entre sortir un jeu et ajouter une plateforme à un jeu déjà sorti : ce n'est pas le même travail refait à l'identique, en plus rapide. Chaque plateforme a ses propres règles de signature, ses propres contraintes d'identifiant, ses propres exigences de facturation, et aucune des deux ne prête sa checklist à l'autre.