Test de cohérence : ce qu’il vérifie et quand le lancer

Le test de cohérence (sanity testing) est une vérification rapide et ciblée qui confirme qu’un correctif ou une petite modification fonctionne comme prévu sans casser les fonctionnalités voisines. En général, un testeur essaie à la main la fonctionnalité concernée ainsi que quelques écrans liés, sans rédiger au préalable de documentation de test formelle. L’objectif est d’obtenir une réponse rapide, oui ou non, avant que la mise à jour n’atteigne les utilisateurs.

Chaque petit correctif impose la même décision à une équipe logicielle : livrer la correction tout de suite ou attendre plusieurs jours une campagne de tests complète. Sauter les vérifications expose à une réparation qui échoue sous les yeux des clients, tandis que retester tout le produit après chaque modification mineure ralentit chaque livraison. Un passage court et ciblé offre aux équipes une voie intermédiaire.

On confond souvent le test de cohérence avec le test de fumée (smoke testing), et un glossaire du secteur très utilisé a même présenté ces termes comme des synonymes. Vous verrez ci-dessous ce que comprend chaque passage, comment la méthode se situe par rapport aux techniques voisines et quand une vérification rapide suffit. Bien connaître le produit accélère le processus, c’est pourquoi de nombreuses entreprises confient ce travail à une équipe QA dédiée.

Que vérifie réellement un test de cohérence ?

Un test de cohérence commence une fois qu’un développeur a corrigé un bug. Le code corrigé est intégré à un build, une nouvelle version du logiciel prête à être testée. Le testeur examine alors trois zones :

• Le correctif lui-même : reproduire exactement les étapes qui déclenchaient le bug montre si le résultat est désormais correct.
• Les fonctionnalités qui s’appuient sur les mêmes données : chaque écran qui lit, affiche ou envoie ces informations fait l’objet d’un rapide coup d’œil.
• L’étape suivante de l’utilisateur : si les clients se rendent généralement sur une page précise ensuite, le testeur suit aussi ce parcours.

Tout ce qui sort de ces trois zones est volontairement laissé de côté. Ce périmètre réduit permet à une équipe de faire une vérification rapide après chaque correctif mineur sans retarder les livraisons.

Les passages de cohérence se font aussi, en général, sans script : le testeur travaille sans liste d’étapes préparée. La plupart du travail QA planifié suit des cas de test écrits, des instructions qui détaillent chaque action et le résultat attendu. Ici, au contraire, un testeur expérimenté qui connaît la mise à jour décide sur le moment de ce qu’il faut essayer, ce qui garde le passage court.

Un exemple de test de cohérence : un correctif, cinq vérifications rapides

Imaginez une application de prise de rendez-vous pour un réseau de cliniques. Des patients situés dans d’autres fuseaux horaires ont signalé que leurs rendez-vous confirmés s’affichaient avec une heure de décalage. Un développeur corrige le code qui convertit les heures locales, et le nouveau build arrive en test.

Un test de cohérence sur ce correctif horaire pourrait comprendre cinq vérifications :

1. Changer de fuseau horaire. Réglez un téléphone sur une autre région, réservez un créneau et vérifiez que l’écran de réservation affiche la bonne heure.
2. Ouvrir l’e-mail de confirmation. Vérifiez que l’e-mail indique la même heure de rendez-vous.
3. Ajouter la visite à un agenda. Contrôlez que l’événement apparaît à la bonne heure.
4. Déclencher le rappel. Assurez-vous que la notification envoyée par l’application mentionne le même créneau.
5. Reprogrammer une fois. Déplacer le rendez-vous relance la conversion corrigée, si bien qu’une seule modification révèle si le correctif tient aussi à cet endroit.

Si les cinq vérifications réussissent, la mise à jour peut partir avec une confiance raisonnable. Tout échec renvoie le correctif au développeur, accompagné de l’étape précise qui a échoué. Notez ce que le testeur a laissé de côté : les paiements, les profils patients, la recherche et toutes les autres fonctionnalités que la modification n’a pas touchées. Ces fonctionnalités font l’objet d’un passage complet lors de la campagne de tests habituelle avant une version plus importante.

Test de cohérence vs test de fumée : deux questions différentes

Le test de fumée intervient généralement en premier sur un nouveau build et vérifie si le logiciel est assez stable pour être examiné. Un testeur, ou un script qui répète automatiquement les mêmes étapes, ouvre l’application, se connecte et parcourt les fonctionnalités principales. Si quelque chose plante ou si un écran essentiel ne se charge pas, le build est rejeté avant tout test approfondi. Le test de cohérence arrive plus tard et pose une question plus étroite : ce correctif précis fonctionne-t-il ?

L’International Software Testing Qualifications Board (ISTQB), qui gère une certification très répandue chez les testeurs, présentait « sanity test » comme synonyme de « smoke test » dans son glossaire de 2023. L’édition actuelle définit le test de fumée comme une vérification que le logiciel est prêt pour les tests planifiés. Le test de cohérence n’y figure plus du tout. Dans le travail quotidien, pourtant, de nombreuses équipes QA distinguent nettement les deux termes.

Pour savoir qui mène habituellement les tests de fumée et de cohérence, ce qu’apporte l’automatisation et ce qui déclenche généralement un passage, lisez notre article consacré aux tests de fumée vs tests de cohérence.

Quelle place occupe le test de cohérence dans les tests de régression ?

Le test de cohérence est la forme la plus restreinte du test de régression. Une régression est une fonctionnalité qui fonctionnait auparavant et qui a cessé de fonctionner après une mise à jour ultérieure. Les tests de régression complets revérifient le produit existant pour repérer ces défaillances, un travail qui peut prendre plusieurs jours sur une grande plateforme. Un test de cohérence, lui, cherche le même problème dans une zone bien plus petite, autour d’un seul correctif.

Répartir l’effort selon la taille rappelle la pyramide des tests, un modèle de planification courant avec beaucoup de vérifications rapides et peu coûteuses à la base et quelques vérifications larges et lentes au sommet. La même logique s’applique ici : les tests de cohérence suivent presque chaque correctif, tandis qu’une campagne de régression complète attend une version.

Un terme voisin, le retest, consiste à confirmer qu’un bug signalé a réellement disparu. Chaque test de cohérence commence par là, puis regarde un cran plus loin, vers les fonctionnalités voisines du correctif.

Le tableau ci-dessous compare les trois vérifications abordées dans cette section, avec le test de fumée pour référence :

Quand lancer un test de cohérence ?

Un test de cohérence convient lorsque la modification est petite, que le risque reste circonscrit et qu’une campagne de régression complète retarderait la mise à jour pour un gain minime. Exemples courants :

• Un hotfix : cette correction urgente est livrée hors du calendrier habituel, souvent alors que des clients sont touchés, la vérification doit donc être rapide.
• Un petit correctif entre deux versions : une étiquette de prix erronée ou un bouton cassé se confirment sur-le-champ, sans tout retester.
• Un changement de paramètre : modifier une configuration, comme un taux de taxe ou un interrupteur qui active une option, change le comportement du produit sans nouveau code. Les écrans concernés méritent tout de même un coup d’œil.
• Une mise à jour d’un tiers : lorsqu’un prestataire de paiement ou un service de cartographie met à jour les outils dont dépend votre application, chaque fonctionnalité connectée passe un test de cohérence.

Certaines zones d’un produit sont corrigées encore et encore, comme le paiement ou la connexion. Pour ces points sensibles, les tests automatisés peuvent transformer les vérifications de cohérence les plus fréquentes en scripts qui s’exécutent quelques minutes après chaque mise à jour. Les testeurs ont alors plus de temps pour l’exploration manuelle.

Quand un test de cohérence mérite-t-il un script : formule du seuil de rentabilité, chiffres indicatifs

Quand un test de cohérence ne suffit pas

Le test de cohérence ne suffit plus lorsqu’une mise à jour est importante ou risquée, car les effets d’une modification d’ampleur peuvent se propager bien au-delà du code modifié. Par exemple, une nouvelle fonctionnalité, une refonte ou de nouvelles règles de paiement ou d’accès aux comptes peuvent casser des écrans qu’une vérification ciblée ne visiterait jamais.

Même une petite modification peut être risquée lorsqu’elle touche un système central, comme l’a montré la panne de Google Cloud de juin 2025. Une mise à jour de données de routine comportant quelques champs vides a déclenché une faille dans un code livré deux semaines plus tôt sans garde-fous. Selon le rapport d’incident de Google, plus de 60 produits Google Cloud et Workspace ont été indisponibles pendant environ 3 heures en conséquence. Les modifications qui touchent des systèmes centraux exigent une campagne de régression complète et un déploiement progressif, où la mise à jour atteint d’abord un petit groupe d’utilisateurs avant tous les autres.

Comment QAwerk mène-t-il les tests de cohérence entre deux versions ?

Sur les projets clients, un test de cohérence chez QAwerk se déroule en quatre temps :

1. Lire la modification. Nous examinons le rapport de bug et les notes du développeur pour comprendre le problème et la solution.
2. Lister ce que touche le correctif. Nous notons ensuite chaque fonctionnalité et chaque page qui partage des données avec le code corrigé, puis validons cette liste avec le développeur.
3. Vérifier le nouveau build à la main. Le testeur reproduit les étapes du bug d’origine, puis parcourt chaque écran lié comme le ferait un client.
4. Rendre un verdict clair. Votre équipe reçoit une réponse simple : livrer la mise à jour, renvoyer le code pour reprise ou planifier des tests de régression complets parce que la modification est allée plus loin que prévu.

Bien sûr, aucun projet ne ressemble exactement à un autre. Voici deux exemples de la façon dont cette routine se déroule avec de vrais clients :

• Simulateurs de formation chirurgicale : VirtaMed conçoit des simulateurs de réalité virtuelle sur lesquels les chirurgiens s’entraînent à la chirurgie laparoscopique avec un retour haptique, c’est-à-dire le sens du toucher recréé dans les instruments. Programmer un contact réaliste entre les instruments simulés et les organes est difficile. L’un de nos rapports de bug décrivait par exemple une vésicule biliaire qui traversait les tissus environnants. Lorsqu’un correctif mineur arrive, nos testeurs confirment la réparation puis passent en revue les fonctionnalités principales du simulateur. Ce mélange de tests de cohérence et de tests de fumée convient à un produit où une seule modification de la physique peut affecter toute une intervention.
• Vérification d’identité sur mobile : Thirdfort remplaçait ses applications iOS et Android distinctes par une seule version multiplateforme, et les nouveaux builds arrivaient souvent. Parmi les bugs critiques figuraient des erreurs lors de l’envoi des informations Source of Funds, une étape qui indique d’où provient l’argent d’un acheteur. L’application se figeait aussi pendant le chargement de l’écran de vérification d’identité renforcée. Chaque correctif était retesté avant la livraison de la mise à jour suivante. En outre, des cycles de régression couvraient les parcours de modification et de retour en arrière autour de cette étape.

Choisir les bons écrans à vérifier après une correction suppose de savoir comment un produit s’articule. Nos ingénieurs QA dédiés restent auprès d’un même client sur de nombreuses versions, si bien que les testeurs connaissent déjà les liens entre les fonctionnalités. Quand une modification se révèle plus vaste que prévu, la même équipe passe directement aux tests de régression complets, sans passation ni nouvelle intégration.

Faites vérifier votre prochain correctif avant sa mise en ligne.

Questions fréquentes

Découvrez comment nous avons construit et maintenu plus de 1 100 cas de test pour Granola, un bloc-notes IA, et automatisé 76 % de sa suite de régression

Veuillez saisir votre adresse courriel professionnelle n'est pas un courriel professionnel

Obtenir l’étude de cas