Comment nous avons bâti Unicorn Games en 7 jours : architecture, binôme avec l'IA et standards web allégés
Le jeu grand public sur navigateur est en panne. Ouvrez n'importe quel portail de jeux en ligne aujourd'hui depuis votre téléphone ou votre ordinateur portable. Avant même d'apercevoir le moindre élément de jeu, vous subissez des bandeaux de cookies intrusifs, des vidéos publicitaires obligatoires de trente secondes, des boutons qui sautent sous vos doigts et de lourds moteurs WebAssembly de cinquante mégaoctets qui transforment votre appareil en radiateur.
Nous avons voulu prouver le contraire. Notre objectif était de vérifier si un développeur indépendant, travaillant en symbiose avec des modèles d'intelligence artificielle modernes, pouvait concevoir, programmer et déployer une plateforme de jeu complète comptant plus de dix classiques en exactement sept jours ouvrés.
Sans bureaucratie d'entreprise. Sans bibliothèques obèses. Sans tunnels publicitaires piégés. Rien que des jeux de cartes et de réflexion à soixante images par seconde, sans installation préalable et appuyés sur les standards ouverts du web.
Voici le plan d'architecture précis, le relevé technique au jour le jour et les choix d'ingénierie qui ont donné naissance à Unicorn Games.
Le manifeste architectural : le refus du superflu
La rapidité sur le web ne doit rien au hasard. Elle provient d'une succession de refus délibérés.
Dès le lundi matin, avant d'aligner la moindre instruction de code, nous avons posé cinq impératifs techniques absolus :
1. Affichage initial complet en moins d'une seconde. Même sur une connexion mobile médiocre, la table de jeu doit apparaître intégralement en moins de mille millisecondes.
2. Aucune dépendance à des moteurs de jeu externes. Aucun recours à Phaser, Unity WebGL ou aux compilations Godot. Pour des jeux de cartes traditionnels, ces outils représentent des mégaoctets de graisse inutile.
3. Affichage sur HTML5 Canvas 2D couplé à des machines à états finis autonomes. La logique de jeu fonctionne sous forme de fonctions mathématiques pures, sans toucher au DOM.
4. Génération statique totale côté serveur pour toutes les pages de navigation. Chaque jeu, règle et guide stratégique doit exister sous forme de page HTML pré-générée pour assurer un référencement immédiat et sans décalage visuel.
5. Zéro décalage de mise en page (CLS = 0). Aucun élément ne doit bouger sur l'écran après le premier affichage.
Ces principes ont guidé notre choix d'outils : Next.js avec son App Router pour la génération statique et la diffusion rapide sur le réseau mondial, TypeScript pur pour les moteurs de simulation, HTML5 Canvas 2D pour la fluidité graphique et Firebase pour la base de données sans serveur.
Le sprint de 7 jours : journal technique détaillé
Mener à bien une telle plateforme en cent soixante-huit heures impose de traiter chaque journée comme une livraison complète.
Jour 1 : Moteurs de cartes autonomes et état déterministe
Les jeux de cartes semblent simples en surface jusqu'à ce qu'on en écrive les règles fondamentales. Une partie de Solitaire Klondike ou de FreeCell ne se résume pas à faire glisser des images : c'est une machine à états finis qui vérifie des règles strictes à chaque déplacement.
Le lundi a été consacré au socle commun : une architecture de paquets et de colonnes programmée en TypeScript pur, sans aucun lien avec l'affichage.
Le système a été scindé en trois couches étanches :
En séparant ainsi la logique du navigateur, nous avons pu simuler des centaines de milliers de parties dans Node.js avant même de créer le premier bouton d'interface.
Jour 2 : La suite des solitaires (Klondike, FreeCell et Spider)
Le mardi a été dédié au rendu graphique et à la prise en charge des commandes tactiles et souris pour les solitaires emblématiques.
Dessiner des cartes sur HTML5 Canvas réserve des pièges :
L'affichage doit s'adapter aux écrans mobiles haute résolution. Dessiner directement sur un canvas standard sur un smartphone récent produit des cartes floues. Nous avons mis au point un module d'ajustement qui lit le ratio de pixels de l'appareil, multiplie la zone de dessin interne par cette valeur et réduit la taille affichée via les styles CSS. Les cartes sont ainsi devenues parfaitement nettes.
Le traitement des entrées a nécessité l'unification des événements de pointage. Clics de souris, stylets et doigts sur écran tactile passent par un convertisseur de coordonnées unique. Au toucher, le système calcule la position virtuelle sur le canvas, identifie la carte visée et évalue la distance minimale avant d'amorcer le déplacement.
Le mardi soir, Klondike, FreeCell et Spider Solitaire tournaient à soixante images par seconde sans la moindre saccade.
Jour 3 : Jeux de plis et joueurs virtuels intelligents
Le mercredi a vu naître les jeux de plis : Hearts et Spades.
Ces jeux reposent sur le niveau de jeu de leurs adversaires automatisés. Si l'ordinateur joue n'importe comment, l'intérêt retombe. S'il met plusieurs secondes à calculer les probabilités, la page se fige.
Nous avons élaboré une prise de décision rapide par règles expertes :
À Spades, les joueurs virtuels évaluent leur jeu avant la première carte en comptant leurs As, leurs Rois protégés et leurs coupes potentielles. Si leur partenaire annonce un contrat Nil, ils passent en protection : ils jouent leurs couleurs longues pour aider le partenaire à défausser ses cartes dangereuses et couvrent les plis litigieux avec leurs gros atouts.
À Hearts, ils surveillent les défausses adverses pour repérer qui ne possède plus de Trèfles ou de Carreaux. Lors de la traque de la Dame de Pique, ils purgent les petits Piques pour affaiblir les autres joueurs tout en conservant leurs propres protections.
Ces calculs s'exécutent en moins de deux millisecondes, garantissant des réponses immédiates sans perturber l'animation.
Jour 4 : Grilles et logique pure (Démineur et 2048)
Le jeudi, nous avons quitté les cartes pour aborder les grilles numériques.
Le Démineur exige de préserver le joueur dès sa première action :
Le premier clic ne doit jamais révéler une mine. La grille place les mines aléatoirement seulement après cette première action, assurant une ouverture sécurisée à chaque début de partie.
Pour dévoiler les cases vides contiguës, nous avons mis en œuvre un parcours en largeur (BFS) itératif. Une approche récursive classique risquerait de saturer la pile d'exécution sur de très grands tableaux ; une file d'attente traitée par une simple boucle while dévoile le terrain en moins de trois millisecondes sur une grille d'expert.
Pour 2048, nous avons misé sur une transformation matricielle. Gérer les quatre directions par quatre fonctions distinctes engendre un code confus. Nous avons unifié le traitement : chaque coup applique une rotation à la grille pour aligner le mouvement vers la gauche, exécute une fonction unique de fusion des tuiles, puis rétablit la grille dans son orientation initiale.
Jour 5 : Déploiement international et pages statiques
Le vendredi a été réservé à l'infrastructure générale, à l'accessibilité et aux langues étrangères.
Un site de jeu qui ne parle qu'anglais se prive de la grande majorité des joueurs de la planète. Nous avons créé une structure d'adresses capable de gérer dix langues intégrales : anglais, espagnol, allemand, français, italien, portugais, néerlandais, polonais, chinois et hindi.
Plutôt que d'utiliser des modules de traduction exécutés sur le navigateur qui ralentissent le chargement et font sauter le texte, nous avons intégré les traductions directement dans la phase de compilation statique de Next.js.
Chaque jeu, article et guide stratégique est transformé en fichier HTML fixe pour chacune des dix langues. Quand un joueur se connecte depuis Paris ou Rome, la page s'affiche dans sa langue maternelle en moins de quarante millisecondes.
Jour 6 : Ajustements tactiles, mémoire et synthèse sonore
Le samedi a été la journée de la chasse aux ralentissements et à la consommation mémoire.
Trois décisions clés ont transformé l'expérience :
Premièrement, la suppression des fichiers audio externes. Télécharger des fichiers MP3 engendre des retards agaçants quand on manipule les cartes rapidement. Plutôt que de charger des sons sur le réseau, nous utilisons l'API Web Audio pour fabriquer les sons de cartes et de boutons directement avec le processeur via des oscillateurs. Aucun appel réseau, aucun temps mort.
Deuxièmement, la maîtrise du ramasse-miettes de mémoire. Si un jeu recrée des objets en mémoire à chaque image affichée, le navigateur doit périodiquement faire une pause pour nettoyer la mémoire, ce qui provoque des saccades. Nous avons mis en place des réserves d'objets réutilisables pour les coordonnées et les touches tactiles. La cadence d'affichage est ainsi devenue parfaitement régulière.
Troisièmement, la configuration du cache de bordure avec Cloudflare. Nos fichiers statiques étant immuables, les serveurs répartis sur le globe renvoient les pages directement depuis leur mémoire vive, sans solliciter le serveur central.
Jour 7 : Déploiement mondial, contrôle qualité et ouverture
Le dimanche était le jour du lancement. Nous avons relié le domaine officiel, généré les images d'illustration pour les réseaux sociaux et soumis l'ensemble à des audits stricts.
Chaque page a passé avec succès les tests officiels Core Web Vitals :
Le dimanche soir, Unicorn Games était accessible mondialement : dix titres aboutis, une ouverture instantanée sur tous les appareils et aucune publicité pour gâcher le plaisir.
Choix techniques : ce que nous avons délibérément écarté
Un bon travail d'ingénieur se mesure aussi à ce qu'il refuse d'implémenter.
Voici ce que nous avons rejeté après réflexion :
Nous avons écarté WebGL et Three.js. Voir des cartes tourner en trois dimensions est flatteur lors d'une démonstration, mais cela vide rapidement la batterie des téléphones et allonge le temps de chargement. Pour des jeux en deux dimensions, un canvas HTML5 bien calibré assure soixante images par seconde sans chauffer les appareils.
Nous avons refusé les outils de pistage publicitaire tiers. Ces mouchards ajoutent des centaines de kilo-octets de scripts, déposent des cookies indésirables et dégradent les performances. Nous avons préféré une mesure discrète et respectueuse de la vie privée qui comptabilise les parties sans ralentir les joueurs.
Nous avons exclu la navigation monopage pour les guides et articles de blog. Les pages statiques HTML pures sont lues sans délai par les moteurs d'indexation et s'affichent instantanément dès la première seconde.
L'apport réel de l'intelligence artificielle dans ce projet
Nous n'aurions jamais pu mener ce chantier en sept jours sans l'aide de l'intelligence artificielle. Mais notre façon de l'employer n'a rien à voir avec les recettes magiques souvent évoquées.
Nous ne lui avons jamais demandé de générer des jeux entiers toute seule. Cela produit un code fragile qui casse dès la première anomalie.
L'intelligence artificielle a servi de partenaire méthodique sur trois aspects précis :
D'abord, la rédaction des tests unitaires. Pour nos moteurs de cartes, l'IA a rédigé des centaines de cas de contrôle pointus pour vérifier le bon comportement des règles dans des situations inhabituelles.
Ensuite, l'ébauche des algorithmes complexes. Pour les rotations de grilles et les calculs de chemins, l'IA nous a fourni des structures de base que nous avons ensuite affinées et intégrées manuellement à notre moteur graphique.
Enfin, la traduction multilingue. Transposer des milliers de lignes de règles de jeu en neuf langues avec les bons termes techniques aurait réclamé des semaines de travail. L'IA a accompli cette tâche en quelques minutes avec une grande précision de vocabulaire.
En revanche, l'intelligence artificielle s'est montrée incapable de régler les sensations de jeu : ajuster la résistance sous le doigt, calibrer le rebond des cartes ou doser le retour sonore. Ces finitions ont demandé des tests physiques répétés et une oreille humaine.
Ce que disent les chiffres
Le résultat concret de cette semaine de travail se vérifie dans les mesures réelles :
L'intégralité du code JavaScript nécessaire pour faire tourner une partie de Klondike Solitaire sur Unicorn Games pèse moins de quatre-vingt-dix kilo-octets une fois compressé. C'est plus léger qu'une simple image publicitaire sur les sites de jeux ordinaires.
Le temps de chargement initial reste inférieur à huit cents millisecondes partout dans le monde. La table de jeu s'affiche dès que le fichier HTML parvient au navigateur.
Le web n'a pas besoin de nouveaux sites surchargés qui prennent les joueurs pour des cibles commerciales. Il a besoin d'outils rapides, nets et respectueux conçus selon les principes du web ouvert.
Game developer and founder at Unicorn Games. Specializes in combinatorial game theory, solvability algorithms, and classic card & puzzle game development. Every guide is fact-checked against mathematical game states and empirical play benchmarks.
