Test de non-régression oublié : quand le testeur QA paie le bug du dev
Un correctif déployé en production casse le tunnel de paiement. Le développeur a livré, mais le testeur QA n'a pas relancé la suite de non-régression. Qui paie ? Décryptage d'une faute professionnelle souvent ignorée.
- La non-régression est une obligation de moyens implicite dans toute prestation QA, même si le contrat ne la cite pas.
- Si un correctif casse une fonctionnalité que vous n'avez pas re-testée, votre responsabilité contractuelle peut être engagée (art. 1231-1 Code civil).
- Le préjudice immatériel (perte de CA, frais de hotfix) se chiffre vite en dizaines de milliers d'euros.
- La RC Pro couvre les dommages immatériels consécutifs à une faute de validation, à condition que le périmètre du test soit déclaré et écrit.
Le scénario qui revient le plus souvent en cabinet
Vous êtes testeur QA en mission chez un éditeur SaaS. Un développeur corrige un bug mineur d'affichage sur la page profil. Le ticket Jira est marqué "hotfix". Vous validez le correctif sur la fonctionnalité concernée : l'affichage est bon, vous fermez le ticket. Le correctif part en production le soir même.
Le lendemain, l'équipe support découvre que le tunnel de paiement est cassé : les utilisateurs ne peuvent plus finaliser leurs commandes. Le correctif a touché un composant partagé. Personne n'a relancé la suite de non-régression complète. Six heures de panne en pleine journée, environ 42 000 € de chiffre d'affaires perdu, plus les frais de rollback et de communication clients.
Le client cherche un responsable. Le développeur invoque son périmètre strict ("j'ai corrigé ce qu'on me demandait"). Le chef de projet renvoie vers la cellule QA. La question arrive sur votre bureau : pourquoi la suite de non-régression n'a pas tourné avant la mise en production ?
Ce que dit le droit : l'obligation de moyens du testeur QA
En droit français, un prestataire de services intellectuels est soumis à une obligation de moyens. Cela signifie que vous devez mettre en œuvre toutes les diligences attendues d'un professionnel raisonnablement compétent dans votre spécialité (article 1231-1 du Code civil).
La jurisprudence sur les prestations informatiques (notamment Cass. com., 13 oct. 1992, n°90-21474, et plus récemment Cass. civ. 1re, 19 juin 2019) considère que le prestataire doit alerter, conseiller et anticiper les risques liés à son intervention. Appliqué au testeur QA, cela implique trois devoirs implicites, même lorsque le contrat est silencieux :
- Devoir d'alerte : signaler quand un correctif touche un composant transverse et nécessite une re-validation élargie.
- Devoir de conseil : recommander la suite de tests minimale avant toute mise en production, et formaliser ce qui sera ou ne sera pas testé.
- Devoir de diligence : exécuter les tests promis, et documenter ceux qui ont été écartés volontairement (avec l'accord écrit du client).
Autrement dit : si vous validez un correctif sans relancer une non-régression sur les composants impactés, et que cette omission n'est ni motivée, ni tracée, ni acceptée par écrit par le client, vous êtes exposé.
Comment le préjudice se chiffre — et pourquoi il explose vite
Le client ne vous reprochera pas seulement les six heures de panne. Le préjudice indemnisable se décompose en plusieurs postes que les juges acceptent largement :
| Poste de préjudice | Fourchette courante |
|---|---|
| Perte de chiffre d'affaires direct | 15 000 € à 80 000 € |
| Frais de hotfix d'urgence (dev + ops week-end) | 3 000 € à 12 000 € |
| Communication clients, geste commercial, avoirs | 5 000 € à 25 000 € |
| Perte d'image, churn mesurable | variable, souvent capé contractuellement |
| Frais d'expertise judiciaire si litige | 8 000 € à 30 000 € |
Un sinistre moyen de ce type tourne autour de 50 000 à 90 000 €. Pour un freelance QA facturant 500 à 700 € la journée, c'est plusieurs mois de marge nette qui partent en fumée — sans compter le risque réputationnel et la rupture de mission.
Pourquoi la clause de limitation de responsabilité ne vous sauve pas toujours
Vous avez peut-être inscrit dans votre contrat une clause limitant votre responsabilité au montant des prestations facturées sur les six derniers mois. C'est une protection utile, mais elle n'est pas absolue. Trois pièges fréquents :
- La clause peut être réputée non écrite en cas de manquement à une obligation essentielle (Cass. com., 29 juin 2010, arrêt Faurecia 3). Si la non-régression est l'essence même de votre mission, plafonner sa responsabilité à un montant dérisoire risque d'être balayé.
- Elle ne couvre pas le dol ou la faute lourde. Une non-régression "oubliée" malgré une alerte du développeur peut être qualifiée de faute lourde.
- Elle ne lie pas les tiers. Si un utilisateur final perd des données et attaque votre client, ce dernier peut se retourner contre vous sans que votre plafond contractuel s'impose au juge.
En pratique, la RC Pro reste le seul filet de sécurité réel face à un sinistre immatériel chiffré en dizaines de milliers d'euros.
Trois réflexes pour transformer votre méthodologie en preuve juridique
Au-delà de l'assurance, votre meilleure défense est documentaire. Voici trois pratiques qui font la différence devant un juge ou un expert judiciaire.
1. Le "test plan" signé avant chaque livraison
Pour chaque livraison, formalisez un document court (une page suffit) qui liste : les cas de test exécutés, ceux qui ne le seront pas (et pourquoi), la criticité estimée, et la signature du Product Owner. Cela transforme une omission en décision partagée.
2. Le rapport de test horodaté et archivé
Conservez tous vos rapports d'exécution (TestRail, Xray, JUnit) pendant au moins 5 ans — durée de la prescription civile (art. 2224 Code civil). Sans rapport, votre parole vaudra celle du client.
3. Le "go / no-go" écrit avant la mise en production
Refusez de valider une mise en production par message Slack ou par téléphone. Exigez un email ou un ticket explicite. C'est la preuve que le risque a été partagé, et que la décision finale appartient au client.
Ce que votre RC Pro doit prévoir précisément
Toutes les RC Pro ne se valent pas pour un testeur QA. Vérifiez impérativement trois points dans vos conditions particulières :
- Les dommages immatériels non consécutifs sont bien couverts (perte d'exploitation, perte de données, perte de chance commerciale). C'est l'essence du préjudice QA.
- Le périmètre déclaré mentionne explicitement "tests fonctionnels, tests automatisés, tests de non-régression, validation de mise en production". Une déclaration trop vague peut être opposée en cas de sinistre.
- Le plafond par sinistre est cohérent avec votre exposition réelle (au moins 300 000 €, idéalement 500 000 € pour les missions critiques type fintech, santé, e-commerce à fort trafic).
Pour aller plus loin sur les garanties indispensables d'un freelance tech, consultez notre guide de la RC Pro pour les freelances du numérique.
Questions fréquentes
Si, sa responsabilité peut être engagée parallèlement. Mais le testeur QA a une mission de filet de sécurité : son rôle est précisément de détecter ce que le développeur n'a pas vu. La responsabilité est souvent partagée, et le client choisit le maillon le plus solvable.
Non. La checklist doit être horodatée, signée par le client (ou son représentant) avant la mise en production, et conservée 5 ans. Une checklist non opposable juridiquement ne pèse pas lourd face à un expert judiciaire.
Oui, votre RC Pro couvre votre prestation de test, qu'elle porte sur la conception, l'exécution ou la maintenance des suites de tests. Déclarez précisément à votre assureur si vous intervenez sur l'automatisation.
Oui, la prescription de droit commun est de 5 ans à compter du jour où le client a connu ou aurait dû connaître les faits (art. 2224 Code civil). D'où l'importance de conserver vos rapports de test sur cette durée.
Oui, à partir de 9,90 €/mois, la RC Pro Insurio couvre l'ensemble des prestations de test (fonctionnels, automatisés, performance, sécurité), avec une option Cyber dédiée si vous manipulez des données de production.
Souscrivez votre assurance pro en 2 minutes
Toutes nos protections pour votre activité de Testeur QA / consultant qualité logicielle — attestation immédiate, sans engagement.
* Tarifs indicatifs « à partir de », selon votre profil, votre activité et les garanties choisies. · Voir la fiche Testeur QA / consultant qualité logicielle →
Article rédigé et vérifié par l'équipe Insurio — Tutassûr, courtier en assurance immatriculé à l'ORIAS sous le n° 22001730. Information à caractère général ne se substituant pas aux conditions de votre contrat.