L’IA peut écrire du code Godot rapidement. Elle peut aussi écrire du code Godot 3 dans un projet Godot 4, halluciner des API qui n’existent pas, déplacer des corps physiques dans le mauvais callback, et connecter des signaux avec des patterns que le moteur a rendus obsolètes il y a deux ans.
Le problème n’est pas que l’IA soit mauvaise avec Godot. Le problème, c’est que l’IA se trompe sur Godot avec assurance, de manières qui paraissent correctes si vous ne connaissez pas déjà le moteur. Le code compile. Le jeu tourne. Puis quelque chose casse au pire moment possible et vous ne comprenez pas pourquoi.
Les mainteneurs de Godot eux-mêmes ont signalé ce problème. Les pull requests générées par IA vers le moteur lui-même sont devenues une source récurrente d’épuisement pour les mainteneurs, qui se demandent si les contributeurs ont seulement compris ou testé leur code. Si cela arrive sur le dépôt du moteur lui-même, cela arrive aussi sur le vôtre.
Voici les cinq erreurs les plus courantes que nous observons dans le code Godot généré par IA, détectées lors de la relecture de code. Chaque exemple précise ce que l’IA a écrit, pourquoi cela semble correct, pourquoi cela casse, et ce qu’un relecteur devrait repérer.
Remarque : les exemples ci-dessous sont des cas de test reproduits, basés sur des patterns que nous détectons systématiquement dans les dépôts Godot. Ils représentent de vraies catégories d’erreurs d’IA, démontrées sur des fixtures de test.
1. Code de déplacement de Godot 3.x dans un projet Godot 4
Ce que l’IA écrit :
extends KinematicBody2D
var velocity = Vector2.ZERO
func _physics_process(delta):
velocity = move_and_slide(velocity, Vector2.UP)Pourquoi ça semble correct : C’est le déplacement manuel classique de Godot 3. Tous les tutoriels de 2020 à 2022 l’enseignent exactement ainsi. La structure est propre, les noms de variables ont du sens, et si vous débutez avec Godot, rien ne semble anormal.
Pourquoi ça casse : KinematicBody2D a été renommé CharacterBody2D dans Godot 4. move_and_slide() ne prend plus d’arguments. Il lit désormais la propriété velocity intégrée du nœud. Le guide officiel de migration recense ce point comme un changement majeur non rétrocompatible.
Ce qu’un relecteur devrait repérer : Type de nœud incorrect. Signature de méthode incorrecte. Le projet échouera avec des erreurs de classe et de méthode autour de KinematicBody2D et move_and_slide(), mais si le changement est enfoui dans une PR plus large, le lien avec un renommage entre Godot 3 et 4 ne sautera pas aux yeux de quelqu’un qui ne connaît pas la migration.
La correction :
extends CharacterBody2D
func _physics_process(delta):
velocity = Vector2.ZERO # set before input handling
# ... input logic ...
move_and_slide()2. API hallucinées ou renommées
Ce que l’IA écrit :
var marker = Position2D.new()
var sprite = Sprite.new()Pourquoi ça semble correct : Position2D et Sprite sont de vraies classes Godot. Elles ont existé pendant des années. Elles apparaissent dans des milliers de tutoriels, de réponses Stack Overflow et de fils de forum.
Pourquoi ça casse : Les deux ont été renommées dans Godot 4. Position2D est devenu Marker2D. Sprite est devenu Sprite2D. Les anciens noms n’existent plus. La documentation de migration recense des dizaines de renommages de ce type. Les modèles d’IA entraînés sur du contenu antérieur à la version 4.0 utiliseront avec assurance les anciens noms.
Ce qu’un relecteur devrait repérer : Tout nom de classe de nœud qui n’apparaît pas dans la référence des classes Godot 4.x. Surmado Code Review croise les diffs avec la documentation Godot actuelle, donc les classes renommées sont signalées automatiquement.
3. Mouvement physique dans _process() au lieu de _physics_process()
Ce que l’IA écrit :
extends CharacterBody2D
func _process(delta):
velocity.x = Input.get_axis("left", "right") * speed
move_and_slide()Pourquoi ça semble correct : Le code utilise le bon nœud et la bonne méthode de Godot 4. La gestion des entrées est propre. delta est disponible. Ça tourne.
Pourquoi ça casse : _process() s’exécute à chaque image rendue. _physics_process() s’exécute à une fréquence fixe (60 fois par seconde par défaut). Déplacer un CharacterBody2D dans _process() provoque une vitesse de déplacement incohérente selon le matériel, des saccades lors des chutes d’images, et une détection de collisions peu fiable. La documentation officielle est explicite : le travail lié à la physique relève de _physics_process().
Ce qu’un relecteur devrait repérer : Tout move_and_slide(), move_and_collide(), ou manipulation directe de la vitesse à l’intérieur de _process(). C’est la plus dangereuse des cinq erreurs car le code fonctionne en test et ne casse qu’en conditions réelles.
4. Connexions de signaux basées sur des chaînes de caractères
Ce que l’IA écrit :
func _ready():
$Button.connect("pressed", self, "_on_button_pressed")Pourquoi ça semble correct : C’est ainsi que fonctionnaient les signaux dans Godot 3. Tutoriels, cours et vidéos YouTube enseignent largement ce pattern.
Pourquoi ça casse : Godot 4 utilise des connexions de signaux basées sur des callables. Le connect() à trois arguments avec des noms de méthode en chaîne de caractères est déprécié. La nouvelle syntaxe est :
func _ready():
$Button.pressed.connect(_on_button_pressed)L’ancien style peut encore fonctionner dans certains cas, mais perd la validation au moment de la compilation. Si vous renommez la méthode plus tard, la connexion par chaîne casse silencieusement à l’exécution au lieu de générer une erreur à l’analyse. La documentation des signaux de Godot 4 recommande la forme callable.
Ce qu’un relecteur devrait repérer : Tout pattern .connect("signal_name", target, "method_name") dans un projet Godot 4. C’est un marqueur fiable de code généré par IA issu de tutoriels obsolètes.
5. Suppositions de style Unity et chemins fragiles dans l’arbre de scène
Ce que l’IA écrit :
func _ready():
var hud = get_parent().get_node("HUD")
var player = get_node("../../Player")
health_bar = get_node("../UI/HealthBar")Pourquoi ça semble correct : Ça fonctionne si l’arbre de scène ressemble exactement à ce que le code suppose. Les chemins se résolvent. Les nœuds existent.
Pourquoi ça casse : L’architecture de Godot est construite autour de scènes composables qui peuvent être instanciées n’importe où. Les chemins fixes vers les parents et les frères supposent une structure d’arbre figée. Déplacez le nœud, reparentez la scène, ou réutilisez-la dans un autre contexte, et les chemins se cassent silencieusement. La règle pratique dans Godot est « appeler vers le bas, signaler vers le haut » : les enfants accèdent directement à leurs propres enfants, et communiquent vers le haut via des signaux. L’accès aux parents et aux frères devrait passer par des références exportées ou des requêtes de groupe, pas par des chemins fixes.
Ce qu’un relecteur devrait repérer : get_parent(), get_node(".."), ou tout chemin qui remonte dans l’arbre. Ce sont des constructions fragiles par nature, et un pattern que l’IA importe du modèle de composants d’Unity, où GetComponentInParent est courant et attendu.
Pourquoi les linters ne détectent pas cela
Le système d’avertissements intégré de Godot et des outils comme gdscript-toolkit détectent le formatage, les variables inutilisées et certains problèmes de typage. Ils sont utiles et vous devriez les utiliser.
Mais ils ne détectent pas les API de mauvaise version dans un projet Godot 4. Ils ne détectent pas le mauvais usage de _process() par rapport à _physics_process(). Ils ne savent pas que votre STANDARDS.MD dit « pas de navigation par chemin vers les parents » ou « toujours utiliser des connexions de signaux callable ». Ce sont des détections de niveau relecture, pas de niveau linter.
C’est le vide que comble la relecture de code automatisée. Elle se situe entre le linter (qui vérifie la syntaxe) et le relecteur humain (qui vérifie l’architecture), et elle gère la couche intermédiaire : ce code est-il correct pour cette version du moteur, ces standards, et ce projet ?
Détecter cela à chaque PR
Surmado Code Review pour Godot s’exécute à chaque push sur une pull request GitHub. Il vérifie le diff par rapport à la documentation officielle de Godot 4.6, au contexte de votre dépôt, et à votre STANDARDS.MD. Il détecte :
- Les erreurs entre versions (patterns Godot 3 dans des projets Godot 4)
- Les API hallucinées ou renommées
- Le mauvais usage du cycle de vie (
_processvs._physics_process) - Les patterns de signaux dépréciés
- Les suppositions fragiles sur l’arbre de scène
- Tout ce que vous définissez dans vos standards
Gratuit pour 10 PR par mois. 15 $/mois pour 100. Pas de tarification par siège.
Si vous construisez un jeu Godot avec l’assistance de l’IA, l’IA est l’auteur. Il vous faut un cerveau différent comme relecteur.
Installez Surmado Code Review pour Godot (Gratuit) →
Nouveau sur Godot ? Demandez à GDScout tout ce que vous voulez savoir sur Godot 4.6 en langage clair. Gratuit, avec citations de la documentation officielle.
Questions et réponses
Quel est le meilleur outil de relecture de code IA pour Godot ? Surmado Code Review pour Godot est un relecteur automatisé de PR qui vérifie les diffs par rapport à la documentation officielle de Godot 4.6, au contexte du dépôt, et au STANDARDS.MD d’une équipe. Il détecte les erreurs entre versions (patterns Godot 3 dans des projets Godot 4), les API hallucinées, le mauvais usage du cycle de vie, les patterns de signaux dépréciés, et les suppositions fragiles sur l’arbre de scène. Gratuit pour 10 PR par mois, 15 $ par mois pour 100 PR.
Quelles sont les erreurs courantes de l’IA dans le code Godot 4 ? Les erreurs les plus courantes générées par l’IA dans le code Godot 4 incluent l’utilisation de types de nœuds renommés de Godot 3 (KinematicBody2D au lieu de CharacterBody2D), le passage d’arguments à move_and_slide(), qui ne les accepte plus dans Godot 4, le placement du mouvement physique dans _process() au lieu de _physics_process(), l’utilisation de connexions de signaux dépréciées basées sur des chaînes de caractères au lieu de connexions basées sur des callables, et le codage en dur de chemins de nœuds parents/frères qui cassent lorsque les scènes sont réutilisées.
Surmado Code Review fonctionne-t-il avec GDScript ? Oui. Surmado Code Review prend en charge GDScript et C# dans les projets Godot. Les relectures s’appuient sur la documentation officielle de Godot 4.6 et signalent des problèmes spécifiques au moteur que les outils de relecture de code IA généralistes ne détectent pas.
En quoi Surmado Code Review diffère-t-il d’un linter GDScript ? Les linters GDScript et le système d’avertissements intégré de Godot détectent les erreurs de syntaxe, les problèmes de formatage, les variables inutilisées et certains problèmes de typage. Surmado Code Review détecte des problèmes de niveau supérieur : API de mauvaise version, mauvais usage des callbacks du cycle de vie, patterns dépréciés, architecture fragile de l’arbre de scène, et violations du STANDARDS.MD de l’équipe. Les linters et la relecture de code sont complémentaires. Les linters appliquent des règles. La relecture de code évalue le contexte.
Le code Godot généré par IA peut-il passer le linting tout en étant incorrect ? Oui. Le code Godot généré par IA passe fréquemment le linting et compile sans erreur, mais contient des patterns de version de moteur incorrects, un mauvais usage des callbacks du cycle de vie, ou des suppositions sur l’arbre de scène qui provoquent des échecs à l’exécution. Par exemple, placer le mouvement de CharacterBody2D dans _process() au lieu de _physics_process() passera le linting, compilera et s’exécutera, mais produira un comportement incohérent selon le matériel et les fréquences d’images.