Les tests de modèles de langage se résument souvent à des benchmarks, des scores de programmation ou quelques questions complexes. J’ai voulu tester autre chose : la capacité d’un modèle local à réaliser un petit projet complet avec très peu d’informations de départ.
Pour cette expérience, j’utilise Qwen3.8-27B en Q8, exécuté localement, avec seulement deux grandes sources d’information :
- la base de données statique du jeu EVE Online ;
- la documentation et les exemples du moteur 3D GeeXLab.
L’objectif est volontairement simple à formuler : créer une représentation 3D de la carte d’EVE Online, permettre la navigation dans les systèmes stellaires et générer leurs planètes de manière procédurale.
L'idée : donner un objectif, pas la solution
Le but n'est pas de fournir au modèle une architecture détaillée puis de lui demander de remplir les fonctions une par une.
Au contraire, je veux lui donner le minimum nécessaire et observer comment il transforme une idée en projet.
Il doit donc lui-même déterminer :
- comment exploiter la base de données d'EVE ;
- quelles tables et quelles informations sont utiles ;
- comment reconstruire les connexions entre systèmes ;
- comment représenter plusieurs milliers de systèmes dans une scène 3D ;
- comment gérer les énormes coordonnées utilisées par EVE ;
- comment permettre la sélection et la navigation ;
- comment générer visuellement les planètes à partir des quelques informations disponibles.
C'est précisément cette partie qui m'intéresse.
Écrire une fonction Python correcte est une chose. Comprendre un problème incomplet, élaborer une solution, rencontrer une difficulté puis modifier son approche en est une autre.
Un bon terrain de jeu pour tester le raisonnement
EVE Online est particulièrement intéressant pour cette expérience.
La base contient énormément de données, mais il faut comprendre leur organisation avant de pouvoir en faire quelque chose : régions, constellations, systèmes solaires, stargates, planètes, lunes, etc.
Le modèle doit progressivement reconstruire une représentation logique proche de :
Région → Constellation → Système solaire → Objets célestes
Les stargates permettent ensuite de transformer les systèmes en véritable graphe afin de dessiner les routes entre les étoiles.
Mais un autre problème apparaît rapidement : les coordonnées astronomiques d'EVE ne peuvent pas simplement être envoyées telles quelles dans une scène 3D.
Il faut donc trouver une représentation adaptée, par exemple en recentrant et en changeant l'échelle des coordonnées :
Position scène = (Position EVE - Centre) × Échelle
Ce sont exactement les petits problèmes d'ingénierie que je veux voir le modèle identifier sans lui donner directement la solution.
Des planètes procédurales plutôt que des milliers d'assets
La seconde partie du projet consiste à représenter les systèmes solaires.
Il serait évidemment absurde de créer manuellement les textures et modèles de chaque planète.
Le programme doit donc utiliser les informations disponibles dans EVE et compléter ce qui manque par génération procédurale.
Une planète peut par exemple être définie par son type et son identifiant EVE. Cet identifiant devient une seed déterministe utilisée pour générer couleurs, relief, nuages, atmosphère ou éventuellement anneaux.
Ainsi, la planète n'est pas réellement stockée sous forme d'asset : elle est reconstruite de la même manière à chaque lancement.
Cette partie est intéressante parce qu'elle oblige le modèle à distinguer les données réelles du jeu de ce qui peut être généré uniquement pour leur représentation graphique.
Les erreurs font partie du test
Je ne cherche pas spécialement à voir Qwen produire immédiatement un programme parfait.
Je veux surtout observer ce qu'il fait lorsqu'il se trompe.
S'il invente une fonction GeeXLab qui n'existe pas, la question devient : est-il capable de comprendre l'erreur, retourner dans la documentation et trouver une autre méthode ?
Même chose si la carte fonctionne avec quelques systèmes mais s'effondre à 15 FPS lorsqu'on affiche toute la galaxie.
Va-t-il simplement modifier quelques paramètres ou comprendre qu'il faut revoir la méthode de rendu, réduire les draw calls, utiliser l'instancing ou regrouper certaines données ?
Pour moi, c'est là qu'un test de vibe coding devient beaucoup plus intéressant qu'un benchmark classique.
Ce que je vais mesurer
Je vais surtout suivre quelques indicateurs simples :
- nombre d'interventions humaines nécessaires ;
- nombre de prompts ;
- erreurs rencontrées et erreurs corrigées sans aide ;
- qualité de l'architecture produite ;
- capacité à utiliser une documentation inconnue ;
- capacité à modifier une solution devenue mauvaise ;
- performances finales de l'application.
Je conserverai également les mauvais choix et les hallucinations rencontrées pendant le développement. Ils font partie du résultat.
Pourquoi faire ce test avec un modèle local de 27B ?
Qwen3.8-27B n'est évidemment pas un modèle géant fonctionnant dans un datacenter. Dans mon cas, il tourne localement en Q8.
C'est justement ce qui rend l'expérience intéressante.
La question n'est pas de savoir s'il peut battre tous les modèles commerciaux sur un benchmark de code, mais plutôt :
Est-ce qu'un modèle local de cette taille est déjà capable de devenir un véritable assistant de développement, capable de prendre un objectif assez vague et de le transformer progressivement en application fonctionnelle ?
EVE Online et GeeXLab devraient fournir un terrain suffisamment complexe pour le découvrir.
Et si, à partir d'une base de données, d'une documentation moteur et de quelques lignes décrivant l'objectif, le modèle arrive effectivement à construire et déboguer cette carte 3D presque seul, ce sera probablement beaucoup plus parlant qu'un score supplémentaire sur un benchmark.
