La qualité du code ne change jamais - ou l'IA remet-elle cette idée en question ? L'analyse statique associée à l'IA représente la solution

D'après JetBrains

JetBrains est une société à responsabilité limitée internationale spécialisée dans le développement de logiciels, qui conçoit des outils destinés aux développeurs et aux chefs de projet. L'entreprise a son siège social à Amsterdam et dispose de bureaux en Chine, en Europe et aux États-Unis. JetBrains propose divers environnements de développement intégrés (EDI), tels que IntelliJ IDEA, PyCharm, WebStorm et CLion. Elle a également créé en 2011 le langage de programmation Kotlin, qui peut s'exécuter dans une machine virtuelle Java (JVM).

Qodana est un outil d'analyse de la qualité du code qui utilise l'analyse statique pour aider les utilisateurs à réaliser des revues de code, à mettre en place des contrôles de qualité et à appliquer les directives relatives à la qualité du code. Lancé officiellement en juillet 2023, il est compatible avec les EDI de l'écosystème JetBrains, s'intègre aux pipelines CI/CD et prend en charge l'analyse de code dans plus de 60 langages de programmation.

Cet article est adapté de l'intervention de Kai Schmithuesen lors du JetBrains Game Development Day 2026. Découvrez ci-dessous la vidéo complète de la présentation et la séance de questions-réponses, ou poursuivez votre lecture !


Nous allons tout d’abord définir ce que nous entendons par « qualité du code », puis examiner son impact sur les résultats de l’entreprise, le rôle de l’IA dans ce domaine, son influence sur la qualité et les moyens de la préserver au sein de votre équipe.

Vous pouvez appliquer les méthodologies décrites ici à de nombreuses solutions, mais nous allons également étudier un exemple concret avec Qodana.

La qualité du code est un sujet qui a parfois tendance à être négligé, en particulier dans le développement de jeux vidéo où d’autres problèmes peuvent accaparer votre attention. Cependant, d’après les échanges que nous avons eus avec de nombreux clients de JetBrains lors de conférences sur le développement de jeux vidéo, il existe une prise de conscience quant à l’importance de ce sujet. Cela dit, il n’existe pas de bonnes pratiques établies dans le secteur du jeu vidéo ; c’est pourquoi nous partageons dans cette présentation certaines de ces bonnes pratiques issues d’autres secteurs.

Qu’entend-on par « qualité du code » ?

La définition de ce sujet, pourtant crucial, peut s’avérer « floue ». Si vous interrogez dix collègues, vous obtiendrez probablement autant de réponses différentes. Le premier point concerne l’exactitude.

Exactitude : mon code fait-il ce pour quoi je l’ai conçu ?
Performances : un aspect crucial pour les jeux vidéo, est-il suffisamment rapide ?
Stabilité : le code plante-t-il ou non, et quel est son niveau de stabilité du point de vue des joueurs ?
Sécurité : également importante si vous ne voulez pas faire la une de l’actualité du secteur parce que vous avez été piraté.
Facilité de maintenance : mon code fonctionne-t-il aujourd’hui et fonctionnera-t-il encore dans quelques années ? Surtout que certains jeux restent en service pendant 10 à 12 ans.
Réutilisabilité : c’est un sujet qui prend de plus en plus d’importance pour les grands studios : puis-je réutiliser le code que j’ai déjà développé pour d’autres projets ? Tous ces éléments vous donnent un aperçu de ce qu’implique la qualité du code.


Si vous vous rendez sur des forums aussi animés que X ou LinkedIn, par exemple, vous constaterez que l’importance de la qualité du code fait l’objet d’un débat animé. D’une personne affirmant ne pas se soucier de l’aspect de son code à l’autre extrême, « Mon code doit être magnifique et irréprochable avant que je ne le publie », en passant par toutes les nuances intermédiaires. Les opinions divergent énormément.

L’équipe de Qodana souligne que la qualité du code peut avoir un impact réel sur votre activité et sur l’accueil réservé à votre jeu. Un studio AAA a perdu 33 % de sa valeur une semaine après le lancement.

Les temps de chargement de GTA ont été réduits de 70 % simplement en corrigeant deux petites failles dans le code. Le temps de chargement est passé de 6 à 2 minutes (grâce à un joueur), puis Dark Souls a été hors ligne pendant 2 mois en raison de failles d’exécution de code à distance (problème de sécurité) ; si vous perdez des joueurs au cours de ces deux mois, il y a de fortes chances qu’ils ne reviennent pas, ce qui a un impact concret sur le chiffre d’affaires. Un code de mauvaise qualité ne reste pas seulement de votre côté. Il se répercute sur vos joueurs, ce qui peut entraîner des demandes de remboursement et de mauvaises critiques.


Lorsque l’on consulte IGN ou PC Gamer, la qualité, les bugs et la stabilité du jeu influencent toujours les notes. Cela détermine en fin de compte le nombre de joueurs que vous attirerez, et les jeux bogués mènent à des joueurs mécontents. Il existe quelques exemples de grands studios qui s’en sortent malgré tout, comme Bethesda, mais c’est un risque que vous ne devriez pas prendre.

Pourquoi du code de mauvaise qualité est-il commercialisé ?

Dans de nombreuses discussions, nous constatons que la simple pression liée à la mise sur le marché de votre jeu est immense. Le calendrier de développement est un véritable problème, comme en témoigne le nombre de développeurs de jeux ayant dû faire face à des périodes de « crunch » ou travailler des heures supplémentaires – soit plus de la moitié d’entre eux. Cela incite de nombreux studios à chercher comment utiliser l’IA pour remédier à ce problème.

L’IA, en particulier dans le développement de jeux, est un sujet très débattu. Cependant, 95 % des développeurs Unity (Rapport 2026 sur les développeurs de jeux Unity) l’utilisent au travail pour faciliter le processus de codage, ce qui montre que l’IA, si elle est utilisée correctement, peut être un outil utile.

Vous pouvez créer des prototypes beaucoup plus rapidement, tester de nouvelles mécaniques de jeu, etc. Auparavant, cela prenait plusieurs mois, mais aujourd’hui, quelques jours suffisent pour écarter ce qui ne fonctionne pas. Vous n’avez plus à consacrer autant de temps aux problèmes de code standard, ce qui se traduit par un gain d’efficacité.


L’objectif n’est pas de supprimer des développeurs des équipes, mais simplement de permettre à votre équipe d’utiliser l’IA pour se consacrer à des tâches plus intéressantes. Cependant, cette rapidité et l’utilisation de l’IA s’accompagnent d’un inconvénient potentiel en matière de qualité du code. L’IA peut générer beaucoup de code très rapidement ; ce code n’est pas nécessairement meilleur ou pire, mais il augmente considérablement le nombre de problèmes. Auparavant, vous écriviez peut-être quelques centaines de lignes. Aujourd’hui, en même temps, l’IA peut en écrire 10 000. Cela entraîne des problèmes concrets, par exemple :

Un code lent : mon jeu est-il à la hauteur en termes de performances ? Est-il stable ? Est-il vulnérable ou présente-t-il des failles de sécurité potentielles ? La bonne et la mauvaise nouvelle, c’est que le code généré par l’IA n’est pas nécessairement pire que celui généré par l’homme ; il semble assez comparable en termes de nombre total de problèmes, mais il présente des défaillances différentes de celles du code humain.

En matière de logique et d’erreurs, il génère 1,7 fois plus de problèmes que le code écrit par des humains. Quant à la maintenabilité, etc., il s’avère moins performant et, plus inquiétant encore, il risque également de créer davantage de problèmes de sécurité qu’un développeur humain. Ces conclusions proviennent d’une étude menée par CodeRabbit, un fournisseur d’IA.


Cependant, la question n’est pas nécessairement de savoir quel type de problèmes est généré par qui (les humains ou l’IA), mais la seule question que nous posons est : « Notre code est-il globalement à la hauteur et répond-il à nos normes de qualité ? » C’est là que l’analyse statique peut nous aider. La bonne nouvelle, c’est que vous pouvez utiliser l’analyse statique pour couvrir pratiquement tous ces six domaines.

Utiliser l’analyse statique de code pour résoudre les problèmes des développeurs de jeux

En matière d’exactitude, vous disposez d’inspections standard. Vous pouvez également vérifier les seuils de couverture de code, qui prennent de plus en plus d’importance. Non seulement en termes de couverture, mais aussi quant à la manière de les utiliser.

Les performances constituent un domaine que l’analyse statique peut couvrir. Quant à la stabilité, on peut citer quelques exemples : la sécurité null, les fuites de ressources, les inspections d’exceptions, les inspections de sécurité et l’analyse des composants logiciels – vérifier la présence de dépendances obsolètes ou effectuer une analyse de contamination dans le cadre de votre analyse statique pour détecter des problèmes plus complexes tels que les scripts SQL, etc.

Du point de vue de la maintenabilité, vous pouvez repérer les « code smells », la complexité du code et les doublons. C’est un domaine dans lequel l’IA excelle. Elle détecte volontiers les doublons, mais n’apprécie guère la refactorisation. Si vous ne disposez pas d’un moyen de contrôler cela, cela nuira considérablement à votre maintenabilité à l’avenir, car personne ne sera plus en mesure de comprendre votre code à un certain stade.

Il en va de même pour la réutilisabilité : le code dupliqué complique les choses, et l’analyse statique permet de vérifier si votre code respecte vos propres normes de codage internes, afin d’adopter une approche uniforme, quel que soit le projet sur lequel vous travaillez. De cette manière, vous pouvez également partager votre code beaucoup plus facilement.

L’IA génère ce genre de problèmes, la raison la plus courante étant qu’elle a été entraînée sur des sources obsolètes. Ces sources sont toutes épuisées et peu de nouveaux travaux voient le jour, ce qui peut entraîner des dépendances obsolètes et d’autres problèmes similaires.

L'analyse statique associée à l'IA en tant que la solution


L’inconvénient, c’est que ce type d’analyse existe depuis longtemps, mais pour une bonne raison. L’une d’elles est que les résultats sont déterministes.

Si vous lancez dix fois une analyse avec un outil d’analyse statique de code, il vous donnera dix fois le même ensemble de résultats. Si vous l’exécutez dix fois, cela ne vous coûte pas plus cher non plus, car cela ne consomme aucun jeton. Si vous soumettez le même morceau de code dix fois à l’IA, vous obtiendrez vingt réponses différentes.

C’est rapide et peu coûteux ; si l’on compare un réviseur basé sur l’IA à l’analyse statique, cette dernière est généralement beaucoup plus rapide. Pour en revenir au caractère déterministe, vous pouvez associer chaque résultat à une inspection spécifique et comprendre pourquoi il s’agit d’un problème.

Cela deviendra de plus en plus important à mesure que les exigences de conformité ne cessent de se renforcer. L’une des plus importantes est la nouvelle loi européenne sur la cyber-résilience, déjà en vigueur dans certaines régions. Une partie de cette loi vous oblige à créer une nomenclature logicielle. Si vous utilisez l’IA, cela s’avérera difficile. Si vous utilisez l’analyse statique du code et que vous pouvez établir une relation biunivoque entre le résultat et le code source, vous aurez plus de chances d’être en conformité. Cependant, les deux méthodes présentent leurs avantages et leurs inconvénients.

Avantages et inconvénients de l’analyse statique et de l’analyse par IA

Elle ne peut pas comprendre l’intention de votre code, car elle se contente essentiellement de rechercher des modèles. C’est là que l’IA entre en jeu. Si vous souhaitez vérifier que le code fait ce que vous attendez de lui à travers différents fichiers ou dans l’ensemble de votre projet, ou encore détecter des problèmes liés à la logique, c’est là que l’IA prend tout son sens.

Idéalement, vous devriez donc utiliser une combinaison d’analyse statique pour couvrir les bases, complétée par l’IA. Un humain écrit le code, et l’IA peut également en écrire une partie. Ensuite, une fois que vous lancez votre pipeline, l’analyse statique se charge de l’analyse initiale. Qodana peut détecter d’éventuels problèmes, mais aussi créer automatiquement des corrections rapides. Vous pouvez donc toujours automatiser le processus, même sans IA.

Ces corrections rapides ne sont pas générées par QIA, ce qui vous offre les avantages généraux de l’analyse statique : rapidité, absence de coût supplémentaire et fiabilité. Vous passerez ensuite à l’outil d’IA de votre choix pour examiner le reste et créer des corrections pour d’autres problèmes complexes, tels que des erreurs de logique ou des refactorisations. Cela peut compléter votre pipeline.

Idéalement, vous obtenez alors une boucle : l’IA renvoie le code dans le pipeline vers votre analyse statique afin que celle-ci puisse reconfirmer que ce que l’IA a créé est conforme et respecte vos normes de qualité et de sécurité du code. Vous pouvez ensuite fusionner le code dans votre branche principale.

Cela peut sembler chronophage, mais l’ironie est que cela ne prend probablement que quelques minutes à chaque fois et peut vous faire gagner du temps à l’avenir. Ce sont quelques minutes investies pour éviter de passer des heures plus tard si des problèmes n’avaient pas été détectés.

Que révèlent les chiffres ?

Certaines études ont déjà démontré les avantages de cette approche. En combinant l’analyse statique et les appels aux LLM, le nombre de tokens utilisés a diminué de 72 à 92 %, tout en augmentant le volume de code utilisé dans le cadre de cette étude. Une deuxième étude a révélé que cette combinaison permettait de réduire jusqu’à 33 % le nombre de vulnérabilités dans le code LLM intégré à la branche « master ».


Voici un bref exemple illustrant à quoi cela peut ressembler dans Qodana ou dans l’outil d’analyse statique de votre choix. Nous prenons en charge les moteurs de jeu les plus courants dès l’installation. Voici à quoi cela ressemble dans Qodana même. En tant que développeur, vous ne passeriez normalement pas beaucoup de temps ici. Cette fonctionnalité est particulièrement utile pour un chef d’équipe ou un chef de projet. L’un des membres de l’équipe Qodana a réalisé ce projet d’exemple ci-dessous en « vibe-coding ». Il s’agissait d’une interface utilisateur bancaire écrite en Java, et la partie « vibe-coding » n’a pris que quelques minutes pour être mise en place et fonctionner.


Qodana a détecté 126 problèmes et vous offre un moyen pratique d’avoir un aperçu rapide de ce qui est important. Vous pouvez ensuite leur appliquer des corrections rapides. Il existe différentes façons de configurer cela (avec des niveaux d’automatisation variables).

Ici, nous l’avons intégré dans un pipeline GitHub Actions. Nous avons ensuite placé les problèmes restants dans la « Baseline ». Une fois qu’ils se trouvent dans la « Baseline », ils ne vous ralentissent plus. La prochaine fois que vous lancerez une analyse avec Qodana et que vous détecterez de nouveaux problèmes, idéalement, trois d’entre eux seront corrigés automatiquement, et vous n’en verrez que deux nouveaux. Il est donc plus facile de déterminer comment employer votre temps.

Si l’on examine les cinq problèmes restants, on constate que certains indiquent du code dupliqué. Bien que vous puissiez les visualiser depuis Qodana, vous ne pouvez pas les corriger à partir de là. Ainsi, si nous ouvrons cela dans IntelliJ IDEA, vous pouvez voir que cela nous amène à l’emplacement exact dans la base de code d’IntelliJ IDEA.

Cela fonctionne avec nos EDI, mais aussi avec Visual Studio, Visual Studio Code et Cursor. Vous pouvez également utiliser notre outil de CI. Ici, vous pouvez passer en revue les problèmes, comme le code en double, en passant la souris dessus (selon votre solution), puis en accédant aux « Actions supplémentaires », puis aux « Actions IA », et laisser l’IA corriger ces problèmes à votre place.


Vous pouvez effectuer cette opération manuellement ou via un agent, en la semi-automatisant pour qu’elle s’exécute en arrière-plan, tandis que vous attendez que le code soit nettoyé. Si vous souhaitez en savoir plus, n’hésitez pas à nous contacter : nous pourrons vous montrer comment l’utiliser, ou vous et votre équipe pourrez l’essayer gratuitement.


Une fois que vous demandez à l’IA d’ajouter des tests, ceux-ci finissent par s’accumuler dans tous les dépôts, et même des processus aussi simples que le linting peuvent devenir lents. Avez-vous déjà rencontré ce problème ?

Dans certains cas, il faut passer par dix étapes différentes pour publier du code. La plupart du temps, cela est dû au fait que quelqu’un a lancé le processus, mais que personne ne revoyait jamais le pipeline pour déterminer ce qui était pertinent et ce qui ne l’était pas ; or, l’analyse statique ne devrait pas vous ralentir. Ainsi, dans Qodana, un mode dit « pull request » ne vérifie que les fichiers modifiés et ne devrait prendre qu’une minute ou deux.

Dans quelle mesure les agents intégrés de JetBrains dans les EDI peuvent-ils lire les outils d’analyse statique de l’EDI ?

Rider dispose d’une fonctionnalité appelée « Hooks ». Chaque fois que l’agent génère du code, il appelle les Hooks dans Rider. L’un d’entre eux sert à reformater le code, tandis que l’autre vérifie les problèmes actuels dans un fichier, effectue le linting, identifie les problèmes et les signale à l’agent ; celui-ci peut alors régénérer le code selon vos normes ou corriger uniquement ce que vous lui demandez. Ce processus est déterministe : l’agent est donc contraint d’utiliser les hooks, et non pas simplement invité à le faire. Le hook est activé et exécuté à chaque fois.

Remarque : les technologies d’IA largement adoptées sont relativement récentes et les résultats issus de cette explosion de données doivent toujours être examinés de manière approfondie, y compris les données présentées dans cet article.

Essayez Qodana gratuitement