Tester une application juste avant sa mise en production ne suffit plus à garantir la qualité des logiciels modernes, selon un article publié sur le blog de JetBrains par Kerry Beetge. L’idée centrale consiste à répartir les contrôles qualité sur l’ensemble du cycle de vie du développement logiciel, afin que les défauts apparaissent plus près du moment où ils sont introduits, plutôt que d’être découverts après l’accumulation de changements et de complexités supplémentaires.
L’article relie cette évolution à la dépendance croissante au code généré par l’intelligence artificielle ; il indique, en citant une enquête de Stack Overflow réalisée en 2025, que 84 % des développeurs utilisent des outils d’intelligence artificielle ou prévoient de les utiliser dans le processus de développement. JetBrains estime que l’augmentation du volume de code produit par ces outils rend les revues répétées et évolutives encore plus importantes, tout en maintenant la nécessité d’une validation humaine en raison du risque de propagation d’erreurs dans le résultat automatisé.
Du contrôle préalable à la mise en production à l’assurance continue
L’article distingue l’assurance qualité des logiciels (SQA), qui suit le respect des exigences opérationnelles, de fiabilité, de sécurité et des normes tout au long du cycle de développement, du contrôle qualité traditionnel (QC), qui se concentre généralement sur le produit final et traite les défauts de manière réactive. L’approche continue permet de détecter les problèmes pendant l’écriture ou l’intégration du code, lorsque leur correction est moins coûteuse et davantage liée au contexte initial du changement.
L’article indique que les cycles de publication sont passés, dans les environnements de développement modernes, de plusieurs mois à quelques jours, tandis que les pipelines CI/CD permettent au code de passer du commit à la production avec une intervention humaine limitée. Il ne suffit donc pas de s’appuyer sur un seul outil ; chaque couche de test révèle un type différent de problème.
Que couvrent concrètement les outils ?
- Analyse statique : elle examine le code sans l’exécuter afin de détecter les défauts, les vulnérabilités et les violations des normes de codage ; Qodana en est un exemple.
- Tests unitaires : ils vérifient le fonctionnement individuel des fonctions et des composants, avec notamment JUnit, Jest, PyTest et NUnit.
- Tests d’intégration : ils examinent l’interaction entre les services, les interfaces API et le flux de données ; Postman et Soap UI comptent parmi les outils utilisés.
- Tests fonctionnels et tests d’interface : ils simulent les parcours utilisateur dans le navigateur à l’aide d’outils tels que Playwright, Cypress et Selenium.
- Tests de performance : ils mesurent le comportement sous charge et contribuent à détecter les goulets d’étranglement, les fuites de mémoire et la lenteur des requêtes, à l’aide d’outils comme JMeter, LoadRunner et k6.
- Tests de sécurité : ils combinent SAST, SCA, l’analyse des dépendances, DAST ainsi que la détection des secrets ou des clés API insérés par erreur.
Comment choisir les outils et les intégrer au travail ?
L’article propose d’évaluer les outils en fonction de leur intégration au CI/CD, de leur prise en charge des langages et des frameworks utilisés, de leur capacité à automatiser les tâches répétitives, de leur évolutivité avec la croissance du code et des équipes, de la fourniture de rapports exploitables, ainsi que des pratiques de sécurité propres à l’outil lui-même.
Sur le plan de la mise en œuvre, il recommande de déplacer les contrôles au moment de l’écriture du code, d’automatiser les tests répétitifs, de les exécuter à chaque commit ou build et de surveiller la dette technique au moyen d’indicateurs tels que la complexité du code, la duplication et la couverture des tests. Il souligne également la nécessité d’intégrer les contrôles de sécurité au processus habituel d’assurance qualité, plutôt que de les reporter à une revue distincte avant la publication.
Lecture de certi.news
Le véritable changement proposé par l’article ne consiste pas à ajouter un nouveau test, mais à redistribuer la responsabilité de la qualité au sein du cycle de développement. Cette approche est utile aux équipes qui travaillent avec des publications rapprochées ou qui s’appuient sur des architectures distribuées et des dépendances externes, mais elle ne supprime ni les tests manuels ni le jugement des ingénieurs ; l’automatisation, notamment celle fondée sur l’intelligence artificielle, peut accélérer la détection des problèmes sans garantir à elle seule l’exhaustivité de la couverture ou l’exactitude des résultats. En outre, la source fournit des recommandations générales et des exemples d’outils, mais elle ne propose pas de cadre quantitatif pour les comparer et n’établit pas de résultats comparatifs indépendants en matière de performance.