Réduire les coûts d’un projet IT, c’est légitime. Arbitrer entre les fonctionnalités, prioriser, ajuster les délais : tout cela fait partie du dialogue normal entre un client et son prestataire.
Mais il est un arbitrage qui mérite qu’on s’y attarde : la décision de ne pas inclure de démarche qualité formalisée dans la prestation.
Car si ce choix paraît raisonnable sur le moment, il peut s’avérer coûteux, voire très coûteux, à un moment… inopportun !
Trois types de tests, trois rôles bien distincts
Voici une confusion que nous rencontrons régulièrement. Un décideur pense, en toute bonne foi, que les tests réalisés par les développeurs couvrent l’ensemble des risques. C’est compréhensible… mais inexact.
En réalité, il existe trois grandes familles de tests, qui ne répondent pas aux mêmes questions :
- Les tests unitaires (réalisés par les développeurs) vérifient qu’un morceau de code précis fonctionne comme prévu. C’est une bonne pratique professionnelle, et elle est systématique dans nos équipes. Mais elle ne dit rien du comportement global de l’application.
- Les tests fonctionnels (ou recette) vérifient que l’application répond aux besoins métier définis. Ils sont souvent réalisés conjointement avec le client, sur la base de scénarios utilisateurs.
- Les tests de régression vérifient qu’une nouvelle livraison n’a pas cassé ce qui fonctionnait auparavant. C’est là que réside l’angle mort le plus fréquent.
Ce dernier point est essentiel : chaque évolution d’un logiciel crée potentiellement des effets de bord sur des fonctionnalités existantes. Sans test de régression structuré, ces effets restent invisibles… jusqu’à ce qu’un utilisateur les découvre en production.
🔎 Pour en savoir plus sur ce sujet, n’hésitez pas à consulter cet article : La qualité en matière d’applications mobiles : un challenge inatteignable ?
Une situation qui parle d’elle-même
Imaginez la scène.
Une entreprise du secteur de la distribution lance une refonte partielle de son application de gestion des commandes. Le projet est cadré, le budget maîtrisé. Pour optimiser les coûts, la phase QA dédiée est écartée au profit d’une recette interne assurée par les équipes métier. Les développeurs testent leur code. Tout semble sous contrôle.
Quelques semaines après la mise en production d’une nouvelle livraison, un module de facturation commence à générer des erreurs silencieuses : des anomalies qui ne bloquent pas l’interface, mais faussent les données en arrière-plan. C’est un utilisateur qui remonte le problème, presque par hasard.
La question qui arrive alors, côté prestataire, est légitime et compréhensible : « Comment ça n’a pas été détecté avant ? »
La réponse honnête : parce que ce type d’anomalie (une régression apparue suite à une modification du code) est précisément ce que les tests de régression sont conçus pour détecter. Des tests qui n’étaient pas inclus dans la prestation retenue.
À ce stade, bien sûr, la correction peut être effectuée. Mais entre-temps, des données erronées ont circulé, des équipes ont été mobilisées en urgence, et la confiance dans l’outil a peut-être été endommagée.
Ce qu’un bug en production coûte vraiment
Donc, si on remplaçait la question « Peut-on se permettre de tester ? » par « Peut-on se permettre de ne pas tester ? » : Qu’en pensez-vous ?
Car, un bug découvert en phase de développement est corrigé en quelques heures. Le même bug découvert après mise en production peut générer, selon son degré de criticité :
- Un impact opérationnel immédiat pour les utilisateurs
- Une mobilisation en urgence des équipes techniques
- Un traitement en mode crise, donc moins efficace
- Un risque d’atteinte à l’image et la confiance auprès des équipes internes
- Un coût de correction sans commune mesure avec un test préventif
Les études sectorielles sont convergentes sur ce point : Plus un bug est détecté tard, plus sa correction coûte cher. Les références les plus citées parlent d’un coût jusqu’à 100 fois plus élevé en production qu’en phase amont*.
La qualité n’est pas une option. C’est une assurance.
Nous comprenons parfaitement les contraintes budgétaires. Et nous ne cherchons pas à imposer une démarche qualité uniforme à tous les projets. Chaque situation est différente : la criticité métier, le niveau de maturité du SI, la tolérance au risque varient d’un client à l’autre.
Mais notre rôle de partenaire technique est aussi de poser clairement les termes du choix. Quand un client décide de ne pas inclure de phase QA dans sa prestation, il ne supprime pas le risque : il choisit de le porter lui-même.
🧭 À l’inverse, une démarche qualité intégrée apporte trois choses concrètes :
- La sérénité : chaque livraison est validée avant d’atteindre vos utilisateurs.
- La traçabilité : les tests documentés constituent une mémoire du projet, utile à chaque évolution future.
- La prévisibilité : moins d’aléas, moins de crises, moins de coûts imprévus.
Et concrètement, qu’est-ce que ça change dans notre façon de travailler ?
Nos équipes QA interviennent en complémentarité des développeurs, avec une posture délibérément indépendante. Ce n’est pas un contrôle, c’est un regard différent : celui de quelqu’un dont le métier est précisément de trouver ce qui ne va pas avant que vos utilisateurs ne le trouvent.
Nous pouvons intervenir à plusieurs niveaux selon vos besoins et votre budget :
- Intégration d’une phase de tests de régression sur les projets de développement
- Mise en place d’une stratégie de tests adaptée à la criticité métier
- Accompagnement à la recette fonctionnelle
- Automatisation des tests pour les projets à fort volume d’évolutions
Pour en savoir plus sur le rôle d’un pôle QA, découvrez cet article : Quel est le rôle du pôle QA (Assurance Qualité) dans le développement logiciel et en quoi est-ce important ?
En résumé
Les tests développeurs sont nécessaires. Ils ne sont pas suffisants.
Une démarche qualité formalisée n’est pas un luxe réservé aux grands projets : c’est une décision de gestion du risque, que nous recommandons à tout décideur de prendre en connaissance de cause.
👉 Si vous souhaitez évaluer le niveau de couverture qualité adapté à votre prochain projet ou à votre SI existant, nous serions heureux d’en discuter avec vous. 💬 Parlons-en !
*Source : « Minimizing code defects to improve software quality and lower development costs » – IBM, 2008
Vous souhaitez réagir ou en savoir plus ?
On vous offre un café et, en bonus, la check-list de votre cahier des charges, pour ne rien oublier.
Vous êtes partant(e) ?