Les développeurs sont pris entre la joie (ou la pression) d’utiliser des agents pour livrer 10 fois plus rapidement aujourd’hui et la crainte de savoir comment ils géreront ce code demain. L’écart entre le code « vibe » et le code pouvant être déployé auprès de millions d’utilisateurs est vaste et facile à sous-estimer. Combler l’écart nécessite du soin, de l’expertise et des efforts, et les résultats viendront plus tard. Les agents sont capables d’effectuer des tâches de programmation de plus en plus complexes, mais sans la qualité dont nous avons besoin. Que manque-t-il et comment pouvons-nous combler le vide ?
Sonar
Pourquoi le code généré par l’agent se dégrade : le problème de ballonnement
Le code d’entreprise doit effacer trois barres : il doit être maintenable, fiable et sécurisé. Les agents IA prêts à l’emploi peuvent manquer les trois. Concentrons-nous sur le problème de maintenabilité le plus important et le plus visible, à savoir la surcharge : validation redondante, contrôles défensifs qui ne peuvent pas se déclencher, fonctions quasi-dupliquées, code mort que rien ne supprime. UN None vérifier un paramètre tapé comme dict. UN try/except autour d’un appel qui ne lance jamais. Deux fonctions identiques à l’exception de la négation dans leur instruction return.
Le ballonnement varie considérablement selon le modèle. Le classement LLM de Sonar exécute chaque modèle frontière via plus de 4 400 tâches Java et analyse le code généré. Pour compléter le benchmark, GPT-5.4 High a généré 1 159 000 lignes de code avec un taux de réussite de 81,05 %, tandis que Claude Opus 4.7 Thinking n’a généré que 336 000 lignes de code pour renvoyer un taux de réussite supérieur à 82,52 %. Différents modèles génèrent un code radicalement différent pour obtenir des résultats similaires.
