Le jeu de recette crée une erreur absente du dossier initial

Le support a retrouvé un incident sur votre portail métier. L’équipe prépare un jeu de recette en remplaçant les valeurs identifiantes, puis le chargement s’arrête sur une contrainte d’unicité. Le dossier initial ne présentait pourtant aucun doublon à cet endroit. Les deux comptes distincts ont reçu le même alias : la préparation du test a créé une panne différente de celle que les développeurs devaient comprendre.

Le risque est de corriger l’application pour une erreur introduite par ses propres données de recette. Un masque constant, une valeur tronquée ou deux alias que la base compare comme égaux peuvent produire ce défaut. À l’inverse, inventer une nouvelle valeur pour chaque ligne peut faire disparaître un doublon volontaire et rendre vert le test qui devait protéger son refus.

Nous allons suivre cette transformation jusqu’aux contraintes réellement exécutées, comparer douze cas fictifs dans SQLite et distinguer unicité, relation parent-enfant et résultat métier attendu. Le laboratoire a produit 91 assertions réussies. Il ne charge aucun export client, ne teste aucune application installée et ne démontre pas que les données transformées d’une organisation sont anonymes.

Notre accompagnement en développement web sur mesure peut reprendre le dossier avec support, QA et développeurs. Un audit technique de votre application web rapproche schéma, fixtures, préparation et règle métier avant de décider si la correction porte sur le logiciel ou sur le jeu qui devait le vérifier.

Pour qui : la recette échoue après transformation des données

Le même ticket produit une autre erreur sur le poste de test

Ce diagnostic concerne les applications dont les incidents sont reproduits avec des fixtures préparées, des données synthétiques ou une transformation autorisée. Le signal utile est un chargement qui échoue avant l’action décrite dans le ticket. Le support voulait éprouver une validation, mais la préparation refuse déjà un second compte. Le test n’a pas encore rencontré la décision que le dossier devait observer.

Rapprochez le scénario, le schéma utilisé et la version du générateur. Une erreur SQL peut être une protection correcte contre une fixture devenue incohérente. Il faut expliquer à quelle étape la collision apparaît avant d’accuser la migration ou le backend. Gardez également le résultat initial attendu : une nouvelle panne reproductible ne remplace pas la reproduction de l’incident choisi.

Une préparation verte peut aussi retirer le refus attendu

Le second signal faible est un scénario de doublon qui ne refuse plus rien après une modification du générateur. Les noms sont désormais tous différents, et la suite affiche moins d’erreurs. Ce changement peut avoir supprimé la propriété qui devait déclencher le contrôle. Un import réussi n’est alors pas la preuve que l’application accepte mieux ses dossiers valides.

Le périmètre reste la fidélité technique d’un jeu de test. Il ne porte pas sur l’autorisation de copier une base ni sur la certification d’une méthode d’anonymisation. Une équipe qui dispose déjà de scénarios entièrement inventés peut rencontrer les mêmes collisions en changeant ses factories. La valeur ajoutée du diagnostic vient de la comparaison des propriétés, sans demander des identités réelles pour expliquer le défaut.

Anatomie de la collision : deux valeurs distinctes deviennent égales

Une substitution constante réduit le nombre de valeurs possibles

Dans notre cas B, deux alias fictifs distincts passent une contrainte UNIQUE. Leur transformation remplace chacun par la même valeur « hidden ». Le premier compte entre dans la base ; le second est refusé. Le moteur applique le schéma demandé. Modifier ce schéma pour charger le lot ferait disparaître la protection, sans rendre la nouvelle fixture représentative du dossier initial.

La collision peut être moins visible qu’un masque constant. Dans C, deux valeurs « actor-001 » et « actor-002 » sont réduites à leurs cinq premiers caractères. Leur partie discriminante a disparu. Une longueur de champ conforme et un format lisible ne prouvent pas la conservation de la distinction. Le contrôle doit examiner le résultat après toutes les étapes de transformation, pas seulement l’alias fabriqué au départ.

La comparaison du moteur ne se limite pas aux caractères affichés

Les cas D et E conservent des chaînes qui paraissent différentes. D emploie « Client-A » et « client-a » avec la collation SQLite NOCASE. E emploie « actor » et « actor » suivi d’un espace avec RTRIM. Chaque deuxième insertion est refusée dans son schéma. La recette doit retrouver la collation ou l’expression qui participe à l’égalité, au lieu de comparer les aperçus à l’œil.

Ces comportements sont bornés à nos tables SQLite. La collation NOCASE native traite ici la casse ASCII ; elle ne prouve aucune équivalence générale des accents ou des caractères Unicode. Un index fonctionnel, une normalisation applicative ou une collation d’un autre moteur peut produire une égalité différente. Retrouvez ces décisions sur la base qui sert réellement l’application avant de transposer un témoin.

Retrouver la contrainte et la propriété que le test devait garder

Nommer la portée de l’unicité avant de réécrire les alias

Une adresse ou une référence peut être unique dans toute la table, dans une organisation ou dans une combinaison de colonnes. Les cas H et I distinguent cette portée : le même alias entre dans deux organisations avec notre clé composée, mais sa répétition dans une seule organisation est refusée. Ce résultat SQL ne démontre aucune isolation des droits entre ces organisations.

Relevez les colonnes, les valeurs absentes autorisées et la comparaison utilisée. Le contrat de la fixture précise aussi la propriété métier : comptes distincts, référence répétée volontairement ou occurrence appartenant au même client. Ces notions ne se déduisent pas de la présence d’un identifiant technique différent. Deux lignes ayant chacune leur clé primaire peuvent encore violer la même règle d’unicité.

Garder la différence entre un témoin valide et un témoin à refuser

Un cas nominal doit rester chargeable avec ses relations utiles. Un cas conçu pour éprouver un doublon doit conserver ce doublon jusqu’au contrôle qui le refuse. Le générateur ne doit pas réparer automatiquement toutes les valeurs répétées. Il produirait une nouvelle population, facile à charger mais incapable de montrer si l’application protège encore la décision décrite dans le ticket.

Cas concret : L prépare deux occurrences volontairement égales, dont la seconde est refusée. Une transformation qui attribue un alias différent à chaque ligne permet ensuite deux insertions. Le test a changé de sens. Son verdict doit signaler que le refus attendu a disparu ; ajouter ces deux lignes à la recette comme nouveaux comptes valides ferait perdre la preuve du défaut étudié.

Exercice corrigé : douze transformations dans une base SQLite fictive

Prévoir le résultat avant de charger les valeurs transformées

Le laboratoire utilise Python 3.14.7 et SQLite 3.51.2, avec des bases en mémoire distinctes. Les comptes, organisations et commandes sont entièrement inventés. Les neuf premières comparaisons observent un schéma avant puis après transformation. Deux cas examinent une relation parent-enfant. Le dernier conserve un doublon intentionnel comme témoin de refus, puis montre sa disparition après invention d’un alias par ligne.

Pour chaque ligne, choisissez si le second compte sera admis, si la commande perdra son parent ou si une erreur attendue disparaîtra. Le moteur effectue réellement les insertions et retourne ses refus. Le pilote ne charge aucune donnée personnelle et ne sollicite ni API, ni migration client, ni session du portail. La réussite des assertions indique que les résultats locaux observés correspondent aux cas annoncés.

Lire les collisions comme une preuve du pilote, sans fréquence client

Sur les neuf comparaisons d’alias A à I, six transformations créent un refus d’unicité absent de leur fixture initiale, soit 66,7 % de ces témoins sélectionnés. Le ratio montre pourquoi il faut tester plusieurs transformations et plusieurs portées. Il ne mesure pas une fréquence des échecs de masquage en entreprise. Conservez aussi les réussites A et H, afin de ne pas conclure qu’une substitution provoque toujours une collision.

Les douze cas produisent 91 assertions réussies, dont les contrôles de lignes persistées et de clés étrangères. Le seuil de recette proposé est de 0 % de collisions non prévues sur vos témoins nominaux. Refusez également une transformation qui retire un refus volontaire comme L. Ces deux décisions portent sur la fidélité du scénario convenu, sans fixer un taux universel d’acceptation pour tous les imports de données.

Distinguer NULL, chaîne vide et valeur utilisable par l’application

Paradoxalement, deux valeurs absentes peuvent passer l’unicité

Dans F, notre colonne accepte NULL et sa contrainte UNIQUE considère les deux valeurs absentes comme distinctes. Les deux comptes entrent. Dans G, la chaîne vide est une valeur répétée et la seconde insertion échoue. La documentation SQLite des contraintes, consultée le 14 octobre 2026, décrit cette distinction pour UNIQUE. Elle ne définit pas le comportement métier de votre application.

Remplacer tout champ gênant par NULL peut donc rendre un chargement vert tout en retirant une précondition du parcours. Le formulaire, la recherche ou la validation peuvent encore demander une référence présente. La QA doit éprouver cette décision après chargement. Une fixture acceptée par la base n’est pas automatiquement un compte que le portail sait utiliser pour reproduire l’incident choisi.

Qualifier la comparaison dans le moteur installé

La documentation des collations SQLite distingue BINARY, NOCASE et RTRIM. Notre témoin D est également chargé sous BINARY : les deux écritures ASCII y restent admises. Cette comparaison isole la décision du moteur, sans attribuer l’échec à une obligation de rendre tous les alias minuscules.

Une application Symfony utilisant PostgreSQL ou MySQL peut avoir des contraintes et normalisations différentes de notre pilote. Rejouez le témoin dans sa version de moteur, avec son index et ses migrations. Si une normalisation intervient avant l’écriture, observez sa sortie. Copier seulement le nom d’une contrainte dans un schéma SQLite simplifié ne certifie pas le comportement de l’environnement qui recevra votre correction.

Conserver les relations quand les identifiants sont réécrits

Une clé parent changée doit retrouver ses références enfants

J remplace les parents 1 et 2 par 10 et 20. Les commandes fictives gardent pourtant 1 et 2 comme référence. Notre connexion active et vérifie les clés étrangères avant les insertions ; les deux commandes sont refusées. Il s’agit d’une incohérence de correspondance, distincte de la collision d’alias. La corriger demande de retrouver les relations consommées par le scénario.

K applique la même correspondance aux parents et aux enfants. Les commandes 101 et 102 sont retrouvées sous les parents 10 et 20, et le contrôle ne trouve aucun enfant orphelin persisté. Le résultat prouve ces relations locales. Il ne couvre ni document joint, ni cache, ni index de recherche, ni événement déjà en attente qui porterait encore un ancien identifiant ailleurs dans l’application.

Vérifier la protection au lieu de supposer qu’elle fonctionne

La documentation des clés étrangères SQLite demande de qualifier leur activation par connexion. Le laboratoire l’exécute puis lit son état. Une simple clause dans la définition de table ne suffit pas à démontrer que le témoin orphelin sera effectivement refusé par la connexion utilisée pour charger la recette.

Le circuit réel doit également relever transaction, ordre de chargement et contrôles qui suivent la préparation. Désactiver une protection pour charger plus facilement transforme la preuve recherchée. Un rapport de génération doit distinguer lignes préparées, écritures admises et relations retrouvées. Un nombre total correct peut encore cacher une commande rattachée au mauvais compte, même lorsque toutes les clés existent.

Construire un jeu qui conserve la cause du ticket

Choisir les distinctions et répétitions qui appartiennent au scénario

Le métier et la QA décrivent les propriétés utiles : deux comptes distincts, deux occurrences du même compte, une référence répétée ou une valeur absente. Le développement traduit ces propriétés dans la fixture. Une génération par ligne est adaptée à certains objets distincts ; elle est incorrecte si les lignes représentent la même identité ou si le doublon constitue précisément le refus à tester.

Le générateur garde un manifeste du scénario, du schéma et de sa version. Il annonce quelles relations sont conservées et quelles propriétés sont volontairement violées. Ce document rend le test transmissible au support. Un collègue doit pouvoir expliquer pourquoi le deuxième compte est attendu comme accepté ou refusé, sans consulter une correspondance vers des personnes réelles pour comprendre le verdict.

Ne pas confondre fidélité fonctionnelle et anonymisation démontrée

La CNIL distingue anonymisation et pseudonymisation. Remplacer les identifiants directs par des alias ne suffit pas à rendre toute réidentification impossible. Notre réussite SQL ne démontre aucune propriété de confidentialité : les données étaient fictives dès leur création.

Dans votre organisation, les responsabilités compétentes qualifient une éventuelle transformation de données personnelles et son usage autorisé. Le dossier technique peut commencer avec des valeurs entièrement inventées qui reproduisent l’égalité ou la relation nécessaire. Garder un identifiant réel n’apporte aucune preuve supplémentaire à notre collision. Il faut porter séparément la fidélité du test et les conditions de préparation de ses données.

Recetter le générateur puis le parcours qui échouait

Comparer les propriétés avant et après préparation

La recette relève les distinctions attendues, les répétitions volontaires et les relations nécessaires. Elle compare ces propriétés après génération, normalisation, chargement et lecture applicative. Un alias correctement produit peut encore être tronqué lors d’un export ou normalisé par le code avant insertion. La preuve doit atteindre la dernière représentation qui participe au contrôle étudié.

Un scénario nominal reste bloqué si une collision nouvelle empêche son chargement. Un scénario de refus reste bloqué si le générateur élimine son doublon volontaire. Ces critères complètent le nombre de lignes obtenu. Si le seul moyen de rendre le test vert consiste à retirer la contrainte, retrouvez d’abord quelle propriété le jeu a changée et quelle règle l’application devait protéger.

Retrouver le résultat métier après la réussite du chargement

Une fois la fixture admise, jouez l’action minimale du ticket dans le parcours installé. Retrouvez l’objet, la décision, le motif et l’effet attendu. Le support demandait peut-être une correction de devis ou un refus de référence déjà utilisée ; la création de deux comptes ne clôt pas cette question. Notre laboratoire SQL s’arrête avant les écrans et les traitements du portail.

La CI peut reconstruire le scénario depuis une base vide avec la version de migration requise. Un test d’intégration utilise le moteur réel lorsque sa contrainte porte l’invariant. Les vérifications d’interface et d’autorisation gardent leur propre périmètre. La comparaison doit aussi montrer qu’un défaut injecté reste détectable : un chargement systématiquement vert pourrait révéler une préparation qui a retiré toutes les erreurs utiles.

Lorsque ces scénarios accompagnent une refonte du logiciel métier, conservez la version du jeu avec celle de l’application et les refus qu’elle doit encore produire. Cette preuve de recette permet aux métiers de comparer les lots sans attribuer au nouveau code une erreur fabriquée par la préparation des données.

Erreurs fréquentes : réparer la base pour une fixture devenue fausse

Supprimer la contrainte ou inventer un suffixe sans retrouver l’identité

Retirer UNIQUE permet à B de charger les deux comptes, mais ne conserve pas le schéma qui protégeait l’application. Ajouter un suffixe aléatoire peut résoudre la collision sans préserver les répétitions attendues ailleurs. Ces deux réponses changent le test avant d’avoir compris son modèle. Le premier dossier à fermer est celui de la transformation, avec les classes qu’elle fusionne ou qu’elle sépare.

Une troisième erreur consiste à garder seulement les caractères visibles. D et E montrent que la comparaison exécutée possède ses propres règles. Une quatrième remplace tous les champs par NULL et prend l’absence de refus SQL pour un résultat métier. Le témoin F oblige justement à prolonger la recette jusqu’à la recherche ou la validation qui consomme la valeur absente.

Déclarer l’incident reproduit à partir d’un autre message d’erreur

Le support a décrit une action et un résultat. Un échec de chargement sur un alias devenu commun ne reproduit pas automatiquement ce résultat. Nommez le défaut de fixture séparément, puis retrouvez le ticket initial après correction du jeu. Cette distinction évite de livrer une modification de règle métier dont la seule preuve était une collision fabriquée pendant la préparation.

Le coût caché se mesure dans les enquêtes détournées : temps de recherche sur la migration, échanges avec le support et corrections du générateur avant de rejouer l’action. Notre laboratoire ne mesure aucune économie client. Votre suivi peut relever ce délai et les tickets dont la reproduction reste impossible, sans promettre qu’une politique d’alias réduira automatiquement toutes les anomalies de recette.

Plan d’action : remettre le bon scénario devant la règle à vérifier

Réunir schéma, scénario et transformations réellement exécutées

Les entrées du dossier sont un scénario fictif minimal, ses propriétés attendues, le schéma et l’ordre des transformations. Ses sorties sont les valeurs chargées, les refus et les relations retrouvées. La QA porte les distinctions et répétitions ; le développement porte générateur et normalisation ; le responsable du parcours confirme la décision métier. La journalisation distingue l’échec de préparation de celui de l’action testée.

Le runbook indique la version du jeu à reconstruire, la migration requise et le seuil qui bloque sa diffusion. Le repli revient au générateur connu avec ses fixtures compatibles ; il ne supprime pas les contraintes pour terminer l’import. Le monitoring de recette sépare collisions nouvelles, parents absents et résultats applicatifs inconnus. Ces responsabilités rendent le défaut transmissible lorsque le premier développeur n’est plus disponible.

Étendre seulement après conservation des témoins positifs et négatifs

Commencez par un scénario qui chargeait avant le changement et un scénario qui devait être refusé. Ajoutez les collations, champs absents et relations réellement consommés. Différez les tables dont le contrat reste inconnu. Le critère de sortie doit conserver la réussite du nominal et le refus voulu, puis permettre à une autre personne de rejouer le ticket sans inventer ses propres données.

L’audit technique de l’application peut cadrer cette comparaison lorsque préparation, schéma et backend ont évolué séparément. La correction retenue porte sur la première transformation qui modifie la propriété utile. Un générateur plus complexe n’est pas automatiquement nécessaire : un petit scénario synthétique peut suffire si ses distinctions et ses limites restent explicables.

• Conserver une fixture nominale qui distingue réellement les deux comptes attendus.
• Refuser la diffusion du jeu si sa transformation retire le doublon volontaire.
• Comparer les références enfants aux nouveaux parents avant de rejouer le ticket.
• Différer le parcours dont la collation ou la portée d’unicité reste inconnue.

Guides complémentaires : préparer les données et protéger le test utile

Choisir les données et leur environnement de reproduction

Le guide des données de test réalistes traite propriétés, génération et conditions d’usage. Celui de l’environnement local proche de la production replace le schéma parmi les différences qui peuvent changer le résultat. Ils prolongent le dossier quand le seul alias ne suffit plus à expliquer la reproduction.

Choisissez le premier pour qualifier quelles propriétés conserver dans le jeu. Reprenez le second lorsque la même fixture produit un refus différent entre poste et environnement partagé. Notre SQLite reste un banc de comparaison borné ; la version du moteur et les contraintes du parcours réel doivent encore être rapprochées avant d’attribuer l’écart au logiciel.

Conserver un refus voulu pendant l’évolution de l’application

La méthode pour tester un legacy sans bloquer ses livraisons distingue comportement observé et décision métier. Les tests des workflows à exceptions organisent ensuite les partitions et refus. Ils aident à conserver le sens de L au lieu de rendre sa fixture nominale pour faire passer la suite.

Le premier devient pertinent lorsqu’un refactoring retire une dépendance et déplace la manière de préparer le test. Le second aide à nommer les propriétés que les cas positifs et négatifs protègent. Dans les deux parcours, une nouvelle factory doit garder l’exception utile observable avant que l’équipe puisse lui confier la non-régression du prochain changement.

Conclusion : garder la propriété du ticket dans les données de recette

Le masquage peut fusionner deux valeurs distinctes ou séparer deux occurrences qui devaient rester égales. Une collision de préparation et un doublon métier ne racontent donc pas le même défaut. Retrouvez la transformation, la comparaison du moteur et le résultat attendu avant de modifier le schéma qui protège l’application.

Les douze cas fictifs distinguent ces décisions avec des insertions réellement exécutées. Ils montrent également pourquoi NULL peut passer, pourquoi la portée d’une clé composée compte et pourquoi les enfants doivent suivre les parents réécrits. Leurs 91 assertions prouvent ce pilote SQLite, sans valider votre portail ni une méthode d’anonymisation de données personnelles.

Le dossier se prolonge jusqu’à l’action du ticket avec le moteur et le schéma installés. Un chargement corrigé doit permettre de retrouver son résultat métier, tout en conservant les refus volontaires. La QA peut alors expliquer ce que la fixture garantit et ce qu’il reste à vérifier dans les écrans, les droits ou les effets externes.

Dawap peut examiner votre scénario, le générateur et les contraintes qui empêchent sa reproduction. Notre accompagnement en développement web sur mesure vise une correction testable que support et développeurs peuvent rejouer avec des données adaptées, puis conserver lorsque l’application évolue.