Création d’un jeu web développé et déployé automatiquement chaque jour à partir des retours des utilisateurs

J’ai essayé de créer un jeu web selon un concept où les retours des utilisateurs sont collectés puis déployés le lendemain.
C’est un projet que j’ai réalisé pour me familiariser avec les outils d’IA, et le github est également public, donc n’hésitez pas à y jeter un œil.
game: https://spiralwave.frogred8.dev
github: https://github.com/frogred8/SpiralWave

• Vue d’ensemble du projet et conception
  • Motivation et objectif : expérimentation de vibe coding avec des outils d’IA avancés (Gemini, etc.) et tentative de développer un jeu web en appliquant des technologies encore jamais utilisées.
  • Orientation du développement : choix d’un mini-jeu web de type « collecte de ressources à durée limitée » où les avis des utilisateurs sont automatiquement pris en compte chaque jour.
• Création du prototype initial
  • Concept clé : un jeu de collecte de ressources et de construction d’arbre de compétences, sans compétition ni perte.
  • Utilisation de l’IA : conversion d’un croquis sur papier en prompt pour mettre en place en 30 minutes la structure de base du jeu avec TypeScript, Vite et Phaser.
• Limites de l’implémentation des logiques complexes et résolution manuelle
  • Développement de l’arbre de compétences : la logique de prérequis de base a été implémentée avec l’IA, mais la logique complexe où l’annulation d’un nœud intermédiaire entraîne l’annulation en chaîne des nœuds inférieurs n’a pas pu être résolue par l’IA, et a donc été implémentée manuellement.
  • Absence de code de test : en raison des changements fréquents de conception et de la rapidité du développement, le projet a volontairement avancé sans écrire de tests.
• Refactorisation à grande échelle et caractéristiques du débogage avec l’IA
  • Séparation de l’UI : le code UI a été séparé à cause de l’augmentation excessive de la taille d’un fichier unique, mais l’uniformité et la satisfaction structurelle sont restées faibles ; cela a confirmé que, pour les gros travaux, une méthode consistant à renforcer le prompt puis à reprendre le travail était efficace.
  • Bug d’ordre d’exécution : face à une erreur d’exécution apparue après refactorisation (ordre inversé entre mise à jour de l’état et affichage de l’UI), l’IA a surtout multiplié les guard clauses ; au final, le développeur humain a compris le flux et a simplement corrigé le problème en modifiant directement deux lignes de code.
  • Les erreurs de l’IA semblaient relativement humaines, ce qui a donné une impression étrange.
• Application de commits Git automatiques et d’un guide
  • Mise en place d’un guide de prompt : pour réduire la contrainte des instructions répétitives, un fichier de directives (GEMINI.md) récapitulant la stack technique et le mode de fonctionnement a été introduit.
  • Workflow automatisé : après la fin du travail sur le code, la configuration génère automatiquement un message de commit incluant le temps d’exécution de l’agent, le prompt d’instruction et un résumé du travail, afin de réduire l’effort de revue simple.
• Conception et optimisation de l’architecture de mise à jour automatique
  • Changement de méthode de déploiement : l’idée initiale d’un déploiement automatique en temps réel toutes les 2 heures a été abandonnée en raison d’un taux élevé de bugs à l’exécution (environ 25 %), qui nuisait à la stabilité des builds ; il a été décidé de créer et déployer séparément un build de test quotidien.
  • Workflow Cron : mise en place, avec node:cron, d’un processus d’automatisation monolithique allant de « collecte des retours → nettoyage → génération du code → build et création de release → déploiement ».
  • Mise à jour des notes de release : un fichier de liste des serveurs est partagé entre les instances Docker via un volume commun, avec un cache expirant en 5 minutes pour contrôler la charge ; les demandes multilingues des utilisateurs sont nettoyées en anglais puis retraduites afin d’afficher les notes de release.
• Fonctionnalités écartées pendant le développement
  • Fonction de recommandation (Like) des avis dans le leaderboard (absence d’identifiant et coût des appels API).
  • Outil sophistiqué de gestion des données de compétences (limites d’imagination et édition directe du JSON jugée plus efficace).
  • Mise en place d’un environnement Docker distribué par service (intégré en une seule image pour minimiser la complexité d’exploitation et de gestion).
  • Fonction d’alerte par e-mail lors de la prise en compte d’un avis utilisateur (validité de la collecte d’e-mails sans inscription et risque d’usurpation).
  • Ajout de publicités latérales (fatigue liée au processus d’approbation de la plateforme et effet jugé insuffisant par rapport au faible revenu unitaire).
• Retour d’expérience sur le développement basé sur l’IA
  • Compromis entre productivité et tests : la vitesse d’implémentation a été multipliée par environ 10, mais le temps et la fatigue nécessaires à la vérification (QA) ont augmenté de manière proportionnelle, révélant une limite.
  • Caractéristiques de la qualité du code : la qualité au niveau des fonctions est élevée, mais la lisibilité est faible, ce qui rend la compréhension du flux global difficile ; il a aussi été constaté une tendance à introduire des schémas de généralisation inutilement volumineux, même dans des situations où un hard coding localisé aurait été plus avantageux.

[recast7838]

C’est sympa.