Quatre clics pour être en ligne. Trente secondes, du début à la fin. Une seule application avec backend serveur en ligne par compte sur le plan gratuit. Une demi-seconde de latence supplémentaire sur la toute première requête qu'un sous-domaine tout neuf sert jamais, et aucune ensuite. Trois de ces chiffres sont anecdotiques — le genre qu'on note et qu'on oublie au chapitre suivant. Le « un », en revanche, est le chiffre qui change vraiment votre façon de travailler, alors c'est là-dessus que je veux passer le plus de temps dans ce chapitre.
Pourquoi la limite est de un, pas zéro et pas illimité
La plupart des outils no-code qui permettent de publier un frontend gratuitement soit ne touchent pas du tout aux applications avec backend serveur, soit les limitent si agressivement que « gratuit » n'est qu'une formalité. Ici, une création avec des comptes, une base de données ou un état multijoueur se publie via exactement le même bouton Publier qu'une page statique, et le côté serveur est hébergé et géré dans le cadre de cette action unique — pas de provisionnement de base de données séparé, pas de variables d'environnement à configurer, pas de découverte trois jours plus tard que la connexion fonctionne en aperçu et plante en production parce que le backend n'a en fait jamais été déployé. C'est réel, et c'est pourquoi les gens sont surpris quand ils atteignent le plafond : jusque-là, tout semblait illimité.
Ce n'est pas le cas. Vous obtenez exactement une application avec backend serveur en ligne à la fois sur le plan gratuit. Les créations statiques ne comptent pas dans cette limite — publiez autant de pages marketing et de portfolios que vous voulez, aucune limite là-dessus. Mais la deuxième création nécessitant sa propre base de données ou un processus persistant doit attendre son tour, entièrement construite et prévisualisable, mais pas en ligne à son URL. Si vous prototypez trois idées de SaaS dans la même semaine, une seule peut occuper de la véritable capacité de calcul ; les deux autres sont des produits terminés sans adresse. Je pense que la limite est placée à un endroit raisonnable — un bundle statique coûte quasiment rien à la plateforme pour être servi en périphérie, un processus serveur actif coûte plus — mais cela signifie que la décision de savoir quelle idée mérite le créneau doit se prendre avant de cliquer sur Publier, pas après s'être déjà attaché à en avoir deux en ligne à la fois.
Les quatre clics, pour mémoire
- Sur la carte de la création, choisissez Publier.
- Choisissez un slug — le votre-nom dans
yourname.buildmidas.com. Les slugs déjà pris suggèrent des alternatives. - Confirmez.
- Copiez l'URL depuis la carte, ou retrouvez-la plus tard sur votre page Publications.
Pas de DNS, pas de comptes externes, pas d'attente de propagation. Et à propos de cette demi-seconde : ce n'est pas une file d'attente ni un délai « repassez dans 24 heures », c'est simplement un préchauffage de cache CDN ordinaire. Le premier visiteur d'un nouveau sous-domaine peut ressentir un léger surplus de latence pendant que le nœud périphérique le plus proche récupère le bundle de fichiers ; le deuxième visiteur, et tous ceux après, le reçoivent depuis le cache. En pratique, vous ne le remarquerez pas — vous publierez, cliquerez sur le lien, et ça paraîtra déjà instantané. Je le mentionne seulement parce que quelqu'un qui capture des temps de chargement pour vivre finira par demander pourquoi la requête un et la requête dix ne sont pas identiques, et maintenant vous savez.
Le slug est la seule décision qui mérite qu'on ralentisse
Tout le reste de ce processus est mécanique ; le slug est la partie qu'une personne doit dire à voix haute ou taper de mémoire, donc ça vaut un instant de réflexion. « demo-v2-final-final » convient pour des tests internes et c'est une mauvaise chose à envoyer par texto à un client. Dites l'URL à voix haute avant de confirmer — riverside-cafe.buildmidas.com se lit bien, riverside-cafe-mvp2.buildmidas.com non. Les mots courts et génériques partent vite sur une plateforme qui existe depuis un moment, c'est pourquoi un slug déjà pris vous donne des suggestions plutôt qu'une simple erreur. Acceptez-en une ou rejetez-la, mais décidez délibérément — j'ai vu des gens prendre ce que la case proposait en pleine démo parce qu'ils avaient besoin d'un lien immédiatement, puis vivre avec un nom maladroit pendant des mois parce qu'il n'y a jamais eu de moment naturel pour le corriger.
La republication ne touche pas ce qui est en ligne tant que vous ne le décidez pas
Voici un fait qu'il vaut la peine d'intégrer tôt : modifier une création publiée ne fait pas bouger le site en ligne. Vous pouvez casser des choses, essayer un changement de mise en page radical, itérer pendant une semaine — l'URL qu'un client a déjà mise en favori continue de servir la dernière version que vous avez publiée, jusqu'à ce que vous publiiez délibérément à nouveau.
C'est toute votre histoire de retour en arrière, et elle est bonne précisément parce qu'elle est ennuyeuse. La version 6 est livrée avec un bug — un formulaire qui cesse silencieusement de s'envoyer — et vous ne cherchez pas une commande d'annulation ou un ticket de support. Vous ouvrez l'historique des versions, trouvez la version 5, la republiez. Même bouton, artefact plus ancien, l'URL en ligne bascule immédiatement en arrière. Puis vous corrigez la version 6 sans aucune pression, parce que la production n'est pas cassée pendant que vous travaillez. Le coût de ceci est un clic supplémentaire par publication, puisqu'il faut se rappeler de publier réellement au lieu de supposer qu'une modification est sortie automatiquement. Comparé à des outils où chaque enregistrement est immédiatement en ligne — parfait en démo, difficile trois semaines dans un usage réel — le clic supplémentaire est un compromis qui vaut la peine à chaque fois.
Dépublier signifie que l'URL cesse de répondre, pas « cesse d'être listée »
Beaucoup de plateformes utilisent « dépublier » pour dire masquer d'une page de galerie tout en laissant l'URL continuer à répondre silencieusement. Ici, cela signifie que l'adresse s'éteint, point final — pas de page en cache, pas de placeholder, rien ne répond. La création elle-même survit avec chaque version intacte ; republiez plus tard et le même slug revient exactement là où vous l'aviez laissé. J'ai utilisé cela pour la raison banale (une mission client s'est terminée, personne ne veut que son ancien logo flotte à une adresse publique) et pour la raison moins banale (une création a divulgué quelque chose qu'elle n'aurait pas dû, et elle devait être mise hors ligne en le temps de cliquer sur un bouton, pas en le temps de déposer un ticket auprès d'un hébergeur). Les deux situations veulent la même garantie, et les deux l'obtiennent.
Une autre chose à ne pas confondre : publier rend une URL accessible à quiconque possède le lien ; qu'elle soit découvrable — listée publiquement, parfois mise en avant dans la Vitrine — est un réglage totalement distinct. Beaucoup de sites publiés légitimes devraient rester accessibles uniquement par lien pour toujours, et une création ayant opté pour le listage public reste au fond un site publié normal, avec le même historique et le même bouton de dépublication.
