À chaque nouvelle version d'un nouveau modèle de langage, le discours est le même : révolution imminente, changement radical du métier de développeur. Et la hype autour de la sortie de GPT5 n'échappe pas à la règle. Aussi, pour tester ses performances en contexte réel, j’ai choisi trois cas concrets, allant d’un simple CRUD à la reproduction d’un jeu de société complet.
Pour ces tests, j’ai utilisé Junie, un agent intégré à l’éditeur JetBrains, qui permet d’appeler GPT-5 directement depuis l’IDE.
Premier test classique : un blog administrable sous Laravel, Vue et Inertia. Sans indications détaillées, GPT-5 a généré les éléments nécessaire et offre un résultat fonctionnel, mais loin des bonnes pratiques Laravel (validation inline plutôt qu’avec des FormRequest, duplication de code, pas de vérification des permissions).
En ajoutant un fichier guidelines.md dans .junie avec mes conventions précises (namespace, utilisation de policies, réutilisation de formulaires...), le résultat a été bien plus conforme à mes attentes. Le contrôleur ressemblait à ce que j’aurais codé moi-même mais avec quelques bugs liés à des détails de version et d’implémentation.
Ce premier exemple est simple mais c'est aussi celui sur lequel je suis le plus exigeant car je connais à l'avance le code que je souhaite obtenir. Sans être guidé, le modèle a très rapidement tendance à produire un code qui n'est pas optimal. En revanche, avec plus de contexte et des règles spécifiques le résultat est grandement amélioré. Cette amélioration est encore plus significative si le projet a déjà été commencé et si il peut prendre exemple sur le code existant pour "comprendre" ce qui est attendu.
Pour ce 2ème teste j'ai demandé à l'agent de me créer un composant React qui génére une grille de lettres avec des mots cachés à l'intérieur. La principal difficulté de cet exercice est de créer une grille aléatoire et de trouver comment placer les mots.
GPT-5 a produit un algorithme fonctionnel, mais qui n'est pas optimal (s'inspirant un peu trop de stackoverflow).
words.forEach(word => {
// ...
let attempts = 0;
const maxAttempts = 100;
while (!placed && attempts < maxAttempts) {
const row = Math.floor(Math.random() * height);
const col = Math.floor(Math.random() * width);
// ...Pour générer la grille, il va tenter de placer un mot aléatoirement et voir si cela fonctionne avant de retenter jusqu'à que ça marche.
Une approche plus robuste est de calculer les positions possibles pour le mot pour ensuite les tester de manière aléatoire plutôt que de tester des position que l'on sait impossible (par exemple un mot de 7 lettres dans une grille de 8x8 ne peut pas être placé a beaucoup d'endroit dans la grille).
Dans ce cas là, on voit que l'agent est capable de générer un code qui semble fonctionner au premier abord mais qui prend des racourcis qui génère des bugs sur le long terme (pour notre exemple, il pourrait ne trouver aucune grille même au bout de 100 tentatives à cause de l'aléatoire).
GPT 5 ne change rien au problème qui vient de la nature de ces modèles. Ils simulent la logique mais dans les fait, sur des exemples spécifiques, se retrouve à reproduire les données d'entrainements et les bugs qu'elles contiennent.
Pour le dernier test on va recréer le jeu de société Lacuna en version web en fournissant les règles dans un fichier rules.md (sans lui donner le visuel du jeu).
Sur cet exemple le résultat est bluffant. Malgré la complexité (gestion des tours, règles de placement, phase finale de scoring), GPT-5 a rapidement produit un prototype jouable, avec des choix UX intéressants.
N'ayant pas essayé de créer le jeu moi même je ne jugerais pas le code ici mais le code est bien découpé en fonction et les éléments particuliers sont commentés ce qui permet une bonne reprise du code.
GPT-5 ne révolutionne pas le développement et propose des résultat sensiblements identiques aux modèles précédents (comme Claude Code par exemple). Il reste soumis aux mêmes limites que ses prédécesseurs : hallucinations, bugs, dépendance au contexte et difficulté à garantir des bonnes pratiques.
De mon côté, je trouve que dans l'état actuel, les modèles sont déjà suffisant pour automatiser des tâches répétitives et avoir des pistes de réflexions sur certains problèmes. Il est plus intéréssant de voir comment ces modèles pourront se minifier pour fonctionner en consommant moins de ressources et fonctionner potentiellement en local.
Aussi, en tant que développeur j'ai plutôt tendance à voir leur utilité pour remplacer les tâches pénibles plutôt que pour remplacer ce qui m'intérèsse vraiment dans le métier : la réflexion et la logique. Je ne souhaite pas devenir lead dev d'agents.