Qualité du code généré par les LLM : une étude pratique portant sur 12 projets

La plupart des débats sur le code généré par l’IA portent sur la question de savoir s’il fonctionne. C’est la mauvaise question. Pour des systèmes de production, la question pertinente est de savoir s’il fonctionne de manière fiable, s’il peut être maintenu par des ingénieurs qui ne l’ont pas écrit, et s’il introduit des défauts à un rythme compatible avec la livraison continue.

Nous avons entrepris de répondre à ces questions par des données, et non par des opinions.

Méthodologie

Nous avons analysé 12 projets de production livrés entre juin 2025 et janvier 2026 selon la méthode de développement orchestré par l’IA de NOSOTA. Chaque projet a été construit par un à trois ingénieurs seniors agissant comme orchestrateurs, les agents d’IA générant la majeure partie du code de production à partir de cahiers des charges structurés et sous revue humaine.

Ces projets couvrent des back-ends d’entreprise, des applications mobiles multiplateformes, des portails web et des systèmes intégrant l’apprentissage automatique. Ensemble, ils représentent plus de 200 000 lignes de code, plus de 1 400 tests automatisés et plus de 350 points de terminaison d’API REST. Chaque indicateur peut être rattaché à l’historique Git, aux journaux CI/CD et aux outils de suivi des anomalies.

Nous avons mesuré trois dimensions : la couverture de tests (couverture des lignes et des branches indiquée par l’intégration continue), la densité de défauts (nombre d’anomalies pour mille lignes de code au cours des 90 jours suivant le déploiement) et la maintenabilité (temps nécessaire à un ingénieur ne connaissant pas la base de code pour réaliser une modification non triviale).

Constat n° 1 : la couverture de tests dépasse les références du secteur

Sur les 12 projets, la couverture médiane des lignes atteint 78 %, trois projets dépassant 85 %. La couverture des branches — un indicateur plus exigeant — s’établit en moyenne à 64 %. À titre de comparaison, les enquêtes sectorielles font régulièrement état d’une couverture moyenne des lignes comprise entre 40 % et 60 % pour les bases de code d’entreprise.

L’explication est structurelle, et non héroïque. Les agents d’IA génèrent des tests dans le cadre de leur production habituelle lorsqu’ils reçoivent un cahier des charges correctement délimité. Le coût d’écriture d’un test devient quasi nul lorsque l’agent le produit en même temps que l’implémentation. Ce qui coûte cher dans les processus traditionnels — des suites de tests complètes — devient le résultat par défaut du développement orchestré par l’IA.

Le facteur déterminant est la qualité du cahier des charges. Les projets dans lesquels l’orchestrateur précisait des critères d’acceptation explicites dans chaque cahier des charges d’agent ont obtenu une couverture supérieure de 15 à 20 points de pourcentage à celle des projets où les exigences de test restaient implicites.

Constat n° 2 : la densité de défauts est plus faible, et la rigueur de la revue en est la cause

La densité médiane de défauts sur l’ensemble des 12 projets s’établit à 0,8 anomalie pour mille lignes de code au cours des 90 premiers jours. La référence du secteur pour des équipes matures se situe généralement entre 1 et 5 anomalies pour mille lignes. Deux projets n’ont enregistré aucun défaut en production pendant la période de mesure.

Ce résultat ne tient pas à ce que l’IA générerait un code parfait. Ce n’est pas le cas. Dans nos données, environ 12 % du code généré par l’IA a dû être modifié lors de la revue humaine avant fusion. Le faible taux de défauts provient du processus de revue : chaque ligne produite par l’IA passe par l’évaluation d’un ingénieur senior avant d’entrer dans la base de code. L’association de la vitesse de génération de l’IA et de la minutie de la revue humaine produit un code à la fois rapide à écrire et soigneusement contrôlé.

Les projets dans lesquels l’orchestrateur a omis ou bâclé la revue — repérables à des durées de revue plus courtes dans les métadonnées Git — présentaient des taux de défauts 3 à 4 fois plus élevés. La méthode fonctionne lorsque l’humain impliqué dans la boucle prend au sérieux sa mission de revue.

Constat n° 3 : la documentation rend le code maintenable par d’autres

La maintenabilité est la dimension sur laquelle les clients s’interrogent le moins et qu’ils paient le plus longtemps. Un système est maintenable lorsqu’un ingénieur qui ne l’a pas construit peut le comprendre rapidement et le modifier sans risque.

Dans le développement orchestré par l’IA, la documentation n’est pas ajoutée après coup : elle découle de la méthode elle-même. Chaque projet de l’échantillon a été remis avec les spécifications qui ont guidé les agents d’IA, les comptes rendus des décisions d’architecture, la documentation de l’API et un code commenté pour expliquer l’intention, et non la syntaxe. La revue qui recherche les défauts dans la production de l’IA vérifie aussi que le code s’explique de lui-même.

Il en découle deux conséquences pratiques. D’abord, le client échappe à la dépendance à un fournisseur : la connaissance du système réside dans le dépôt de code, et non dans la tête de ceux qui l’ont construit. Ensuite, le développement peut passer d’une équipe à une autre — ingénieurs internes, autre prestataire ou nouvelles recrues — avec un temps d’appropriation minimal, car la nouvelle équipe part des mêmes spécifications et des mêmes décisions que l’équipe d’origine.