Passé cette semaine à réellement pousser un build en production sur les trois chemins plutôt que de simplement les décrire, donc voici le journal — ce que j'ai lancé, ce qui a cassé, ce que je sauterais si je le refaisais.
Jour 1, matin — le sous-domaine en un clic
J'ai commencé par l'option la plus rapide : appuyer sur publier, obtenir votrenom.buildmidas.com sans DNS, sans création de compte, sans coût. Environ quatre secondes. C'est le mouvement à faire quand on veut juste savoir si quelqu'un s'intéresse à l'idée — partager le lien, observer ce qui se passe, itérer. Je m'attendais presque à me heurter à un mur une fois que l'app aurait besoin de vrais éléments backend — comptes, base de données, couche multijoueur WebSocket — mais non, c'est hébergé et géré aussi. Rien à configurer de mon côté. Bonne première journée.
Jour 1, après-midi — essayer de casser le déploiement SFTP
C'est la partie qui me rendait le plus nerveux. Une fois qu'un produit dépasse le sous-domaine et a besoin de son propre nom de domaine, on déploie via SFTP directement depuis la page de build. Je l'ai pointé vers un serveur qui avait déjà un webroot rempli d'anciens fichiers, en m'attendant presque à un écrasement. Au lieu de ça, l'agent de déploiement a inspecté le serveur, choisi une stratégie, et — voici le détail qui comptait — sauvegardé le webroot préexistant avant de toucher à quoi que ce soit. Chaque version déployée après ça est aussi conservée, et revenir en arrière ne prend qu'un clic. Donc quand j'ai délibérément expédié un build cassé vingt minutes plus tard juste pour tester, le rollback a pris à peu près le même temps que pour remarquer que le build était cassé. J'en ai dit plus sur pourquoi ça compte dans Itérer sans crainte — en résumé, l'historique des versions transforme les déploiements d'un moment où on retient son souffle en un non-événement.
Ce que je sauterais la prochaine fois : j'ai passé vingt minutes à essayer de le piéger avec une structure de sous-dossiers imbriqués bizarre avant de me rappeler que tout l'intérêt, c'est que c'est votre serveur, votre domaine, vos fichiers — l'outil n'est qu'un déménageur prudent, pas un gardien. Effort gaspillé à tester quelque chose qui n'a jamais été le vrai risque.
Jour 2 — le chemin vers la boutique, que je n'ai pas terminé
Je n'ai en fait pas terminé celui-ci, et c'est probablement la remarque la plus utile. La publication sur les stores — Android vers Google Play, extensions vers Chrome Web Store et Firefox Add-ons — passe par vos propres comptes développeur, avec des fiches et déclarations de confidentialité préparées par des agents. C'est réel, mais c'est aussi un processus de plusieurs jours avec des files d'attente de validation hors de tout contrôle, donc je me suis arrêté après l'étape de préparation de la fiche. Si vous visez une distribution en store, prévoyez ce budget séparément ; j'ai décrit le parcours complet dans From prompt to app store.
Ce qui a décidé quelle voie suivre, sur le moment
Dès le deuxième jour, le choix s'est presque fait tout seul :
| Ce que je faisais | Voie choisie |
|---|---|
| Tester si l'idée avait un pouls | Sous-domaine, le jour même |
| Besoin d'un vrai domaine de marque | Sous-domaine d'abord, puis SFTP vers mon propre serveur |
| Un utilitaire que les gens trouveraient sur un store | Page de destination sur sous-domaine + publication en store pour l'app |
| Projet client sur leur infrastructure | SFTP vers leur serveur, versionné |
Fin de semaine
Dès le vendredi, j'avais un site marketing sur mon propre domaine, le produit lui-même en ligne sur un sous-domaine, et une fiche de store à moitié prête — les trois voies actives en même temps pour le même projet, construites et itérées depuis le même chat du début à la fin. C'est apparemment l'état final normal pour tout projet sérieux, pas un cas particulier. J'aurais aimé m'y attendre dès le premier jour au lieu de traiter les trois voies comme des décisions séparées.
