Mesurer la qualité du code : quelles métriques sont fiables et lesquelles ne font que rassurer

La qualité du code ne se résume pas à un seul chiffre. La mesure ne devient fiable que si vous observez quatre éléments côte à côte : la couverture de tests des lignes modifiées, la part de doublons, la fréquence de modification des fichiers à risque et le temps nécessaire pour corriger une erreur. La norme internationale de référence en la matière est ISO/IEC 25010:2023.

Qu'est-ce que la qualité du code, au fond ?

La qualité du code n'est pas un adjectif, mais un modèle composé de plusieurs caractéristiques. La norme de référence est ISO/IEC 25010:2023, qui fait partie de la famille SQuaRE. La version révisée en 2023 décrit neuf caractéristiques de qualité du produit.

La nouveauté par rapport à la version précédente est la caractéristique Safety (sûreté), avec des sous-caractéristiques telles que la détection des risques, l'état sûr en cas de défaillance et l'avertissement de danger. En outre, Usability et Portability ont été remplacées par Interaction Capability et Flexibility ; l'ancien modèle « Quality in Use » relève, depuis 2023, de sa propre norme, ISO/IEC 25019.

Pour le travail quotidien, la norme est trop grossière pour mesurer directement. Elle reste pourtant utile, car elle structure la discussion : lorsque quelqu'un réclame « une meilleure qualité », un coup d'œil aux neuf caractéristiques suffit, en deux minutes, à clarifier laquelle est visée.

Quelles métriques disent vraiment quelque chose ?

Quatre, et elles ne fonctionnent qu'ensemble. Chacune peut être manipulée sans que la qualité augmente.

Pourquoi la couverture de tests seule est-elle trompeuse ?

Parce qu'elle compte les lignes exécutées, pas le comportement vérifié. Un test qui appelle une fonction sans rien vérifier produit cent pour cent de couverture pour cette fonction et zéro enseignement.

Avec des tests générés par IA, ce n'est pas une simple objection théorique. Un modèle qui écrit des tests pour du code existant déduit les valeurs attendues du comportement de ce code. Si le code contient une erreur, l'erreur devient une assertion. Le test est au vert et protège l'erreur.

Deux parades : premièrement, mesurer la couverture des lignes modifiées plutôt que la couverture globale — la valeur globale se dilue et bouge à peine. Deuxièmement, lancer de temps à autre des tests de mutation : ils modifient volontairement le code et vérifient qu'au moins un test s'en aperçoit. C'est la seule méthode répandue qui mesure la qualité des tests eux-mêmes. Pour en savoir plus, voir la couverture de tests pour le code d'IA.

Comment introduire des métriques de qualité sans démotiver l'équipe ?

En appliquant les métriques aux modifications plutôt qu'aux personnes, et en fixant des seuils pour le neuf plutôt que pour l'existant.

• Pas de métriques individuelles. Lignes par développeur, nombre de commits, erreurs trouvées par relecteur : tout cela produit un comportement qui améliore le chiffre, et non le produit.
• Geler l'existant, durcir le neuf. Le code historique reste tel qu'il est ; le seuil s'applique aux lignes nouvelles et modifiées. Ainsi, chaque modification devient une petite amélioration, sans que personne ait à financer un grand nettoyage.
• L'évolution plutôt qu'un instantané. Une part de doublons de neuf pour cent n'a aucun sens sans direction.
• Peu de chiffres. Quatre métriques sont lues. Vingt deviennent un rapport que personne n'ouvre.

Quelles métriques sont les plus importantes pour le développement assisté par IA ?

La part de doublons et la croissance des dépendances — les deux réagissent directement aux schémas typiques du code généré.

Pour la part de doublons, l'analyse de GitClear en fournit la justification : les blocs dupliqués comme le code copié ont nettement augmenté depuis 2022. Qui ne mesure que la couverture de tests ne voit pas ce mouvement — il se produit entre les fichiers, pas à l'intérieur.

La croissance des dépendances est le second angle mort : un outil qui ajoute des paquets au passage modifie votre surface d'attaque et votre situation en matière de licences, sans déclencher une seule des métriques habituellement surveillées.

Questions fréquentes sur les métriques de qualité

Quelle couverture de tests est bonne ?

Il n'existe pas de chiffre cible universel, et tout pourcentage cité est une convention, non une norme. Une règle plus solide : le code nouveau et modifié ne devrait pas se situer sous la couverture existante du projet. La valeur monte alors d'elle-même, sans seuil arbitraire.

Quelle est la différence entre ISO 25010 et ISO 25019 ?

ISO/IEC 25010:2023 décrit la qualité du produit, c'est-à-dire les propriétés du logiciel lui-même. L'ancien modèle « Quality in Use » — la qualité du point de vue de l'usage — est externalisé dans ISO/IEC 25019 depuis la révision de 2023.

Ai-je besoin pour cela d'un outil comme SonarQube ?

Pas forcément. La part de doublons et la complexité sont aussi fournies par des outils d'analyse libres, et la fréquence de modification par Git lui-même. Une plateforme se justifie surtout pour l'historique et la logique de seuils — c'est pour cela que la notion de Quality Gate a été forgée, voir Qu'est-ce qu'un Quality Gate.

À quelle fréquence faut-il mesurer ?

Automatiquement à chaque modification, avec une consultation une fois par mois. Regarder plus souvent crée du bruit, moins souvent fait manquer les tendances.

On mesure vite, on agit rarement. Code Guardian comble cette lacune : le résultat d'une modification n'est pas affirmé mais prouvé — avec la sortie du contrôle, et non avec l'assurance qu'un contrôle a eu lieu.

Sources

• ISO/IEC 25010:2023, Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality model (neuf caractéristiques, nouveauté : Safety ; Quality in Use externalisé vers ISO/IEC 25019).
• GitClear, The Maintainability Gap: 2026 AI Code Quality Research.

Version du 27 juillet 2026. Appréciation technique générale. Les citations de normes reflètent la structure et ne remplacent pas l'acquisition de la norme.