Erreur numéro un : écrire un cahier des charges au lieu d'une phrase
Les personnes qui se sont déjà fait avoir par de mauvais logiciels ont tendance à ouvrir le générateur et à taper un paragraphe entier. Système de notation, préférences d'unités, mode hors ligne, thème de couleurs, tout ça préchargé avant même que la première réponse n'arrive. Ça semble être une démarche sérieuse. Ça ne l'est pas. Le générateur lit votre phrase unique, déduit ce que vous voulez probablement dire, et revient avec un plan en une quinzaine de secondes — « un journal d'entraînement pour grimpeurs » devient un journal de séances, une vue de suivi des cotations, et un tableau de bord, avec l'échelle V pour le bloc et les cotations YDS pour les voies choisies par défaut, car c'est ce qu'utilisent la plupart des grimpeurs. Il vous indique ce qu'il a choisi, directement dans le plan, pour que vous puissiez corriger en une ligne si vous êtes l'exception. Écrire le paragraphe à l'avance ne permet pas de sauter cette étape. Vous obtenez quand même un plan, vous devez quand même le lire, et vous avez maintenant passé trois minutes à taper des contraintes que le plan vous aurait présentées de toute façon, dans l'ordre qui compte réellement pour votre projet.
Le plan n'est pas un formulaire à remplir. C'est du texte, et vous répondez en texte. « En fait, mets des cotations Font, je suis en Europe » est une modification complète. Tout comme « ajoute un champ partenaire/journal d'assurage, je grimpe avec différentes personnes. » Chaque modification régénère le plan, pas le build — vous ajustez le cap avant que la partie coûteuse ne démarre, vous ne recommencez pas depuis le début. Approuver ce plan est la dernière décision que vous êtes tenu de prendre. Tout ce qui suit relève de la génération et de la vérification.
Erreur numéro deux : surveiller le flux comme un terminal figé
Le build s'exécute côté serveur, et l'inquiétude ici est presque toujours une fausse alerte : quelqu'un fixe un flux d'activité silencieux pendant deux minutes et suppose qu'il est bloqué. Ce n'est pas le cas — il se trouve dans une phase qui ne produit pas de sortie visible à chaque seconde, et le flux indique précisément dans quelle phase vous êtes pour cette raison. Vous pouvez fermer complètement l'onglet. L'exécution ne vit pas dans votre navigateur.
Ce à quoi vous devez réellement vous attendre varie beaucoup selon la nature du projet. Le journal d'escalade — quelques pages, un modèle de données local, aucun appel à une API externe — se termine en moins de trois minutes, ce qui est typique pour tout ce qui relève essentiellement de « enregistre ça, trace un graphique de ça, affiche-moi une liste ». Dès qu'un build nécessite un vrai backend, une authentification, une base de données avec des relations, des tâches en arrière-plan, comptez plutôt huit à douze minutes, car il y a désormais génération et migration de schéma, et la passe de vérification s'exécute une seconde fois sur le code serveur plutôt que sur du simple balisage. Les jeux sont encore plus lents, car ils nécessitent une génération d'assets : sprites, effets sonores, parfois une seconde passe visuelle si la première tentative ne rend pas bien à la taille prévue pour l'affichage. Et l'empaquetage natif, un véritable APK installable, pas une vue web enveloppée dans une coquille, est confié à une véritable chaîne d'outils. Gradle, signature, tout ça. Cette seule étape peut ajouter cinq à dix minutes en plus de tout le reste, et c'est la phase où un flux silencieux signifie que la chaîne d'outils fait son travail, pas que quelque chose s'est cassé.
Le coût honnête de ce modèle, c'est que vous perdez le retour instantané, caractère par caractère, de voir le code s'afficher en direct dans un éditeur. Ce qui le remplace, c'est un système qui survit à la mise en veille de votre ordinateur portable et aux coupures wifi, que vous pouvez consulter depuis votre téléphone, et qui continue de fonctionner que vous soyez là à le surveiller ou non. Pour un build de quatre-vingt-dix secondes, ce compromis passe presque inaperçu. Pour le build backend de douze minutes, c'est la différence entre surveiller un terminal et aller chercher un café.
Erreur numéro trois : confondre généré avec terminé
C'est celle qui coûte cher. Un build qui se termine vite et qui n'a pas été vérifié n'est pas un build terminé, c'est un brouillon qui s'exécute — et c'est dans cet écart que les générateurs de sites rapides se forgent leur mauvaise réputation, en livrant des formulaires sans assainissement et des boutons inaccessibles au clavier. Avant que cette plateforme ne déclare quoi que ce soit terminé, des agents de vérification distincts le passent en revue : code, sécurité, liens, SEO, accessibilité et conformité par rapport au plan que vous avez approuvé. C'est une passe véritablement indépendante, pas le même agent qui relit sa propre production en hochant la tête.
Le contrôle de sécurité traque les problèmes basiques qui causent réellement des dégâts en production : une clé API intégrée dans le code côté client, un formulaire acceptant des entrées sans assainissement, un endpoint faisant confiance à un identifiant utilisateur fourni par le client au lieu de le déduire de la session. Le contrôle d'accessibilité n'est pas un linter qu'on peut faire taire avec un commentaire — il vérifie les vrais ratios de contraste et l'accessibilité des éléments interactifs au clavier.
La conformité est celle que l'on sous-estime le plus. Il est facile pour une passe de génération de laisser tomber discrètement quelque chose que vous aviez demandé — ce champ partenaire/journal d'assurage issu de votre modification de plan, par exemple — trois fichiers plus loin dans le build, dépriorisé sans que personne n'ait décidé de l'abandonner. La conformité relit votre plan approuvé face au résultat réel et détecte l'écart. Quand elle en trouve un, le correctif est appliqué et revérifié automatiquement ; vous n'obtenez pas une liste de tâches, vous obtenez soit un correctif que vous ne voyez jamais, soit rien à corriger dès le départ. Les mécanismes précis de ce que chaque vérificateur contrôle, et ce qui se passe quand quelque chose échoue deux fois de suite, sont détaillés dans Comment les builds se vérifient eux-mêmes. La seule chose à retenir de cette section : terminé signifie validé, pas généré. Confondez les deux et vous finirez par livrer la clé exposée ou le bouton inaccessible.
Ce que vous obtenez en évitant ces trois erreurs
- Un produit fonctionnel dans un aperçu réel que vous pouvez parcourir en cliquant — une véritable instance en fonctionnement avec vos données connectées, pas une capture d'écran de ce à quoi ça ressemblera.
- Un fil de discussion qui y est rattaché, où « assombris l'en-tête et ajoute une page de statistiques » produit une version deux à côté de la version un. L'ancienne version ne disparaît pas ; elle reste disponible comme solution de repli pendant que la nouvelle prend la place dans l'aperçu en direct.
- Des boutons qui font vraiment quelque chose : publier en direct, télécharger le code, générer des installateurs natifs, publier sur une boutique. Pas des fenêtres modales de vente déguisées en boutons.
Ce bouton « télécharger le code » mérite qu'on s'y attarde, car c'est ce qui distingue un outil auquel vous confieriez quelque chose de réel d'un outil que vous n'utiliseriez que pour des prototypes jetables. Si le code vous appartient véritablement, avec une structure de fichiers lisible et sans verrouillage exotique au-delà de ce que vous avez réellement demandé, alors la plateforme doit continuer à mériter votre prochaine session au lieu de se reposer sur le fait que vous êtes déjà coincé à l'intérieur.
