Dans cet article
- L'assurance qualité, ce n'est pas « quelqu'un qui clique partout avant la livraison »
- Les niveaux de tests qui comptent pour vous en tant que décideur
- Pourquoi un défaut coûte plus cher à mesure qu'il est découvert tard
- Tests automatisés ou manuels : quand utiliser chacun
- Attention à vos données de test
- Ce qu'il faut demander à votre fournisseur avant de signer
- Les signes que la qualité est négligée sur votre projet
Réponse courte : les tests logiciels et l'assurance qualité ne sont pas une étape finale avant la livraison ; ils déterminent combien votre système vous coûtera après son lancement. Deux systèmes au budget identique divergent sur un point : a-t-il été construit avec une couverture de tests qui détecte les défauts avant votre client, ou est-ce votre client qui sert de batterie de tests ? Dans le premier cas, vous payez la qualité une seule fois, pendant la construction. Dans le second, vous la payez chaque mois en pannes, en correctifs d'urgence et en confiance érodée.
L'assurance qualité, ce n'est pas « quelqu'un qui clique partout avant la livraison »
L'image répandue chez les chefs d'entreprise est que la qualité consiste à ce qu'une personne ouvre les écrans et appuie sur les boutons pendant la dernière semaine du projet. C'en est une toute petite partie, et la moins efficace. La véritable assurance qualité est un dispositif qui fonctionne dès le premier jour : des exigences rédigées assez précisément pour être testables, un code couvert par des tests automatisés exécutés à chaque modification, un environnement de préproduction qui reproduit la production, et un circuit de déploiement qui ne laisse aucune modification atteindre la production avant d'avoir franchi ces étapes.
La différence pratique est simple : dans le premier cas, un défaut apparaît quelques minutes après avoir été écrit ; dans le second, votre client le découvre un mois plus tard, alors que vous avez déjà construit d'autres fonctionnalités sur la même erreur.
Les niveaux de tests qui comptent pour vous en tant que décideur
On n'attend pas de vous que vous connaissiez le détail technique, mais que vous sachiez ce que vous payez. Voici les niveaux que toute proposition technique sérieuse devrait nommer :
- Tests unitaires : ils vérifient isolément les plus petits éléments de logique. Ce sont les plus rapides et les moins chers, et ce sont eux qui empêchent une petite modification de fausser le total d'une facture, une remise ou un calcul de taxe.
- Tests d'intégration : ils vérifient que les composants communiquent correctement entre eux et avec les systèmes externes : passerelle de paiement, livraison, plateformes de facturation, messagerie. La plupart des défaillances réelles se trouvent ici, et non dans le code lui-même.
- Tests de bout en bout : ils simulent un parcours utilisateur complet du début à la fin, de l'ouverture de la page à la confirmation de la commande et à la réception de la notification.
- Tests de performance et de charge : ils répondent à une question à laquelle aucun autre test ne répond : que se passe-t-il quand mille utilisateurs arrivent dans la même minute au lieu de dix ? C'est le niveau que les équipes sautent, et le système s'effondre alors le jour de votre plus grande campagne.
- Tests de sécurité : la recherche des vulnérabilités courantes avant que quelqu'un d'autre ne les trouve. La référence pratique est la liste OWASP Top 10 des risques critiques pour les applications web ; la voir citée dans un plan de tests est un signe clair de maturité.
- Recette utilisateur : vous et votre équipe faites fonctionner le système selon vos scénarios métier réels, et non selon un script idéal préparé par le développeur. Cette étape relève de votre responsabilité, et aucune validation ne doit intervenir avant elle.
Pourquoi un défaut coûte plus cher à mesure qu'il est découvert tard
Quiconque a mené un projet logiciel connaît la règle : un défaut repéré pendant la rédaction des exigences se corrige en modifiant une phrase. Le même défaut repéré après le lancement exige un diagnostic, une correction, de nouveaux tests, un redéploiement, et généralement en plus la réparation des données corrompues entre-temps et des excuses aux clients concernés. Le problème, c'est que cet écart n'apparaît jamais dans un devis : le fournisseur qui a retiré les tests du périmètre paraît donc moins cher. En réalité, il n'a fait que reporter la facture, et l'alourdir.
Tests automatisés ou manuels : quand utiliser chacun
Les tests manuels sont indispensables pour juger l'expérience utilisateur, les cas limites et tout ce qui exige un jugement humain. Mais ils ne peuvent pas servir de filet de sécurité permanent, car personne ne revérifiera deux cents écrans à la main après chaque petite modification. Les tests automatisés sont ce qui rend le développement continu possible : vous écrivez le test une fois, il s'exécute des milliers de fois, et il vous dit en quelques minutes si la modification du jour a cassé quelque chose que votre équipe a construit il y a un an. La règle pratique : automatisez tout ce qui est répétitif et touche à l'argent ou aux données, et laissez au jugement humain tout ce qui touche au ressenti du produit.
Attention à vos données de test
Un sujet échappe à l'examen de nombreuses équipes : copier la base de données de production dans l'environnement de préproduction pour que les développeurs puissent tester dessus. Cela signifie que les noms, numéros de téléphone et adresses de vos clients se trouvent désormais dans un environnement aux accès plus larges et à la protection plus faible. La loi sur la protection des données personnelles (PDPL) de l'Arabie saoudite, supervisée par l'Autorité saoudienne des données et de l'intelligence artificielle (SDAIA), encadre le traitement des données personnelles quel que soit le nom que vous donnez à l'environnement qui les contient. La solution est simple et bien connue : des données générées synthétiquement, ou des données réelles dont les champs sensibles sont masqués avant la copie.
Ce qu'il faut demander à votre fournisseur avant de signer
- Un plan de tests écrit dans le périmètre des travaux, et non une promesse orale que « le système sera testé ».
- Des tests exécutés automatiquement à chaque modification via une chaîne d'intégration continue, avec blocage du déploiement en cas d'échec d'un test.
- Un environnement de préproduction distinct de celui qui sert les clients, avec une indication claire de l'origine de ses données.
- Un rapport de couverture périodique, lu à la fois comme un pourcentage et comme une tendance : la couverture augmente-t-elle à mesure que le système grandit, ou diminue-t-elle ?
- Une période de garantie après le lancement qui définit ce qui constitue un défaut corrigé gratuitement et ce qui relève d'une nouvelle demande de développement.
Les signes que la qualité est négligée sur votre projet
Nul besoin d'une formation technique pour les repérer : chaque correction casse autre chose, chaque déploiement est précédé d'une tension visible dans l'équipe, personne n'ose toucher à un ancien module « parce qu'il fonctionne et que nous ne savons pas ce que cela affecterait », et les pannes sont signalées par vos clients plutôt que par votre supervision. Ce ne sont pas des problèmes distincts : ce sont les symptômes de l'absence d'un filet de tests qui permettrait à l'équipe de modifier les choses en toute confiance.
Chez Origami, nous considérons la couverture de tests comme une partie du produit, et non comme une ligne de support : un système qu'on ne peut pas modifier en toute sécurité au bout de deux ans n'est pas un système réussi, aussi beau qu'il ait paru le jour de la livraison.
Sources
Questions fréquentes
Quelle part du budget d'un projet logiciel faut-il consacrer aux tests ?
Il n'existe pas de pourcentage unique correct, mais la règle pratique veut que les tests fassent partie de l'estimation de chaque fonctionnalité plutôt que d'être une ligne budgétaire séparée que l'on supprime sous la pression des coûts. Les systèmes qui manipulent de l'argent, des données personnelles ou des intégrations gouvernementales exigent une couverture plus élevée qu'un simple site vitrine.
Puis-je réduire les coûts en retirant les tests du périmètre des travaux ?
Vous pouvez réduire la première facture, pas le coût. Un défaut découvert après le lancement exige un diagnostic, une correction, un redéploiement et la réparation des données corrompues, le tout payé plus tard et plus cher. Un devis qui a supprimé les tests n'est pas moins cher ; il a simplement reporté la facture.
Quelle est la différence entre la recette utilisateur et les autres tests ?
Les autres tests relèvent de l'équipe technique et vérifient que le système fonctionne comme il a été conçu. La recette utilisateur relève de vous et de votre équipe, et vérifie que le système sert réellement votre activité selon vos scénarios réels. Aucune validation ne doit intervenir avant qu'elle soit terminée.
Est-il acceptable d'utiliser de vraies données clients dans l'environnement de test ?
C'est une pratique courante et risquée. La loi sur la protection des données personnelles (PDPL) encadre le traitement des données personnelles quel que soit l'environnement où elles se trouvent, et les environnements de test ont généralement des accès plus larges et une protection plus faible. L'alternative consiste à utiliser des données générées synthétiquement, ou des données réelles dont les champs sensibles sont masqués.
Suivez Origami sur Google
Ajoutez Origami à vos sources préférées : nos articles apparaîtront en premier pour vous dans la recherche Google et les actualités à la une.
