Pourquoi certaines fonctionnalités passent les tests d'assurance qualité mais plantent quand même en production

C’est lors des migrations de base de données que le problème des données factices apparaît le plus clairement. Une migration qui ajoute un index à une table de 500 lignes dans la base de données de développement s’exécute en quelques millisecondes et passe tous les tests. La même migration sur une table de production de 8 millions de lignes bloque la table pendant 90 secondes en période de pic de trafic. Personne ne l’avait vu venir, car personne ne l’avait testée avec 8 millions de lignes.

Ce n’est pas un cas marginal. C’est un mode de défaillance courant, et ça arrive parce que les données utilisées pour les tests ne reflètent pas celles avec lesquelles l’application fonctionne réellement.

Ce que les données factices ne te révèlent pas

Point clé : les données factices et les fixtures permettent de vérifier que le code gère le cas prévu. Les données de production permettent de vérifier que le code gère le cas réel. C'est dans cet écart entre les deux que naissent la plupart des incidents en production.

Les fixtures et les factories sont utiles. Elles t’offrent un environnement de test contrôlé et reproductible. Elles te permettent d’écrire des tests qui s’exécutent en quelques secondes, d’isoler des scénarios spécifiques et d’obtenir des résultats cohérents. Tout ça reste vrai.

Ce qu’ils ne peuvent pas te donner, c’est la complexité qui s’accumule au fil du temps dans une base de données de production.

Une installation Drupal en production avec trois ans de contenu comporte des termes de taxonomie orphelins, des nœuds dont il manque des données de champ à cause d’une migration de schéma qui ne s’est pas entièrement terminée, des types de contenu présentant des anomalies d’encodage de caractères suite à une importation effectuée en 2021, et des comptes utilisateurs avec des combinaisons d’autorisations qui étaient possibles sous une ancienne configuration de rôles mais qui ne devraient pas exister sous la configuration actuelle. Rien de tout ça ne se trouve dans les fixtures, car celles-ci ont été écrites pour représenter l’aspect que les données devraient avoir, et non leur aspect réel après des années d’utilisation en conditions réelles.

Une application Django en production avec des utilisateurs actifs présente des schémas de requêtes que l’on ne retrouve pas dans une base de données de développement. Certains filtres, rapides sur 10 000 enregistrements, se transforment en balayages complets de la table lorsqu’on passe à 2 millions d’enregistrements. Certaines jointures qui fonctionnent bien isolément se comportent différemment sous les schémas de charge générés par une utilisation réelle. Une requête N+1, imperceptible en développement, devient un incident de performance en production.

Le problème des données factices, ce n’est pas que les développeurs écrivent de mauvaises fixtures. C’est que les fixtures sont un modèle de la réalité, et que les modèles sont toujours incomplets.

Ce que signifie réellement la « complexité de production »

Point clé : les bases de données en production sont complexes de trois façons que les fixtures ne peuvent pas reproduire : le volume (la quantité de données), l’entropie (les incohérences accumulées liées à l’utilisation réelle) et le comportement des requêtes (la façon dont le moteur de base de données se comporte réellement sous des modèles de charge réels). Ces trois aspects sont importants pour les tests.

Le volume est la dimension la plus évidente. Une fonctionnalité qui gère 100 enregistrements ne gère pas de la même manière 10 millions d’enregistrements ; cela dépend de l’indexation, de la planification des requêtes et de l’allocation de mémoire. Les tests à l’échelle du développement ne font pas toujours ressortir ces différences.

L’entropie est moins visible, mais tout aussi importante. Les vraies bases de données de production contiennent des données qui ne correspondent pas aux attentes actuelles du schéma, car les schémas évoluent et les migrations sont rarement parfaitement rétroactives. Une migration de contenu Drupal datant d’il y a cinq ans a peut-être laissé des champs dans des états auxquels le code actuel de l’application ne s’attend pas, car ce code a été écrit après la migration et part du principe que les données sont « propres ». Tester avec des fixtures écrites pour correspondre au schéma actuel fait complètement passer à côté de ces cas.

Le comportement des requêtes est ce qu’il y a de plus difficile à reproduire artificiellement. Les moteurs de base de données prennent des décisions différentes concernant les plans d’exécution des requêtes en fonction des statistiques des tables, de la cardinalité des index et de la répartition des données. Une requête qui s’exécute efficacement sur un petit ensemble de données de développement homogène peut déclencher un plan d’exécution différent sur un grand ensemble de données de production hétérogène. La seule façon de tester ça de manière fiable, c’est de tester avec des données qui ont les mêmes propriétés statistiques que celles de production.

Comment fonctionne le clonage de données en pratique

Point clé : le clonage de données au niveau de l’octet crée une copie équivalente à l’état de la base de données de production dans un environnement de test. Associé à l’anonymisation des données, cela offre aux développeurs un environnement de test présentant la même complexité que la production, sans exposer les données réelles des utilisateurs.

Upsun est une plateforme en tant que service (PaaS) qui gère la couche d’infrastructure de ta pile d’applications pour que ton équipe n’ait pas à s’en occuper. Lorsqu’un environnement de test est créé à partir d’une branche de production sur Upsun, cet environnement inclut un clone au niveau octet de la base de données de production à ce moment précis. Ce n’est pas une copie du schéma. Ce n’est pas une base de données vide préremplie de données de test. C’est une copie fidèle des données telles qu’elles existent en production au moment du clonage, jusqu’aux mêmes enregistrements orphelins, aux mêmes anomalies d’encodage et aux mêmes statistiques de requêtes.

Le clonage s’effectue au niveau de la couche de stockage, ce qui signifie qu’il est rapide, quelle que soit la taille de la base de données. Cloner une base de données de 80 Go ne prend pas 80 Go de temps, car la plateforme traite cette opération comme une opération sur le système de fichiers plutôt que comme un transfert de données.

Pour la plupart des équipes, le processus se déroule comme ça :

# Create a new environment branched from production
upsun branch feature/new-search-index main

# The environment spins up with a full clone of production data
# Your feature code runs against real data from the first commit

L’environnement de la branche du développeur contient désormais les mêmes 8 millions de lignes que la migration va rencontrer en production. L’ajout d’index qui a bloqué la table de production pendant 90 secondes apparaît en développement, avant son déploiement, quand il est encore possible de le corriger.

Anonymisation : rendre les données de production sûres à utiliser

Point clé : le clonage des données de production n’est utile que si les développeurs peuvent y accéder en toute sécurité et les partager avec les équipes d’assurance qualité. L’anonymisation supprime ou masque les informations personnelles identifiables avant que le clone n’atteigne un environnement hors production, ce qui répond à la fois aux exigences de confidentialité et aux besoins pratiques des processus de développement réglementés.

La préoccupation évidente liée à l’introduction de données de production dans les environnements de développement, c’est la confidentialité. Les bases de données de production contiennent de vraies données utilisateur : adresses e-mail, noms, références de paiement, dossiers médicaux, tout ce que l’application stocke. Ces données ne devraient pas être accessibles à tous les développeurs de l’équipe, et elles ne devraient pas apparaître dans les URL de l’environnement de test partagées avec les clients pour révision.

La purification des données s’effectue dans le cadre du processus de création de branche, avant que les données clonées n’atteignent l’environnement de test. Un hook de purification remplace les champs sensibles par des valeurs réalistes mais fictives : les vraies adresses e-mail sont remplacées par des adresses générées, les noms sont modifiés, les données de paiement sont masquées. La base de données conserve sa complexité structurelle et son volume, tandis que les informations permettant d’identifier les utilisateurs sont supprimées.

Pour un projet Drupal, un hook de nettoyage utilisant Drush pourrait ressembler à ça :

hooks:
  deploy: |
    if [ "$PLATFORM_ENVIRONMENT_TYPE" != production ]; then
      drush -y sql:sanitize --sanitize-email=user+%uid@example.com
    fi

Le hook s’exécute automatiquement sur tous les environnements hors production, ce qui signifie que le nettoyage est structurel plutôt que procédural. Il ne dépend pas de quelqu’un qui se souvienne de le lancer ; il s’exécute parce que la configuration le prévoit.

Le résultat, c’est un environnement de test avec des données à l’échelle de la production, des modèles de requêtes aussi complexes qu’en production, et aucune info réelle sur les utilisateurs. L’équipe d’assurance qualité peut tester dessus. Les développeurs peuvent déboguer dessus. Les auditeurs peuvent vérifier que l’environnement reflète bien les conditions de production. Personne n’a accès aux vraies données des utilisateurs.

Ce que ça change pour l’assurance qualité et la confiance dans les mises en production

Point clé à retenir : quand l’équipe d’assurance qualité valide une fonctionnalité qui a été testée avec de vraies données de production, cette validation a une signification différente de celle d’un test effectué sur des données factices. L’écart entre « validé par l’assurance qualité » et « fonctionne en production » se réduit considérablement.

Le changement concret réside dans la signification des résultats de test.

Lorsqu’une fonctionnalité passe le contrôle qualité dans un environnement alimenté par des fixtures, le résultat est le suivant : cette fonctionnalité fonctionne correctement avec des données idéalisées dans un environnement contrôlé. C’est utile, mais ça laisse de côté une catégorie de défaillances que seules les données de production pourraient révéler.

Lorsqu’une fonctionnalité passe le contrôle qualité dans un environnement cloné à partir de la production, ça veut dire que cette fonctionnalité fonctionne correctement avec les données réelles qu’elle va rencontrer en production, y compris les cas limites, le volume et l’entropie accumulée due à l’utilisation en conditions réelles. C’est un indicateur nettement plus fiable.

Pour les applications réglementées où la validation par l’assurance qualité fait partie du processus de conformité, cette distinction est importante pour les auditeurs. La preuve d’un test sur des données équivalentes à celles de production est plus solide que celle d’un test sur des données factices, car elle montre que les conditions de test reflétaient bien la réalité.

Pour les équipes qui ont déjà connu des incidents en production dus à des données non couvertes par les fixtures, ça élimine une source d’incertitude qui se trouve actuellement entre le déploiement et la confiance.

Tu utilises déjà des fixtures et des mocks ?

Garde-les. Les fixtures sont l’outil idéal pour les tests unitaires, les scénarios isolés et les boucles de rétroaction rapides. Le clonage de données de production vient s’ajouter à ça, il ne les remplace pas : les fixtures servent à tester comment ton code devrait se comporter, tandis que les données de production permettent de tester comment il se comporte réellement à grande échelle. Ces deux approches répondent à des questions différentes, et une infrastructure de test aboutie utilise les deux.

Foire aux questions (FAQ)

Le clonage des données de production est-il sûr du point de vue du RGPD ou de la loi HIPAA ?

Le clone lui-même est une copie des données de production et est soumis aux mêmes obligations que celles-ci jusqu’à ce qu’il soit anonymisé. Le hook d’anonymisation s’exécute dans le cadre du processus de création de l’environnement et doit être considéré comme une étape obligatoire pour toute application soumise à une réglementation. Une fois anonymisé, l’environnement ne contient plus de données personnelles réelles et est accessible aux développeurs et à l’équipe d’assurance qualité sans obligations supplémentaires en matière de traitement des données.

À quel point les données clonées sont-elles à jour ?

Le clone reflète les données de production au moment où la branche a été créée. C’est un instantané, pas une synchronisation en temps réel. Pour la plupart des besoins de développement et d’assurance qualité, cela suffit, puisque l’objectif est d’avoir une complexité équivalente à celle de la production plutôt que des données en temps réel. Pour les tests qui nécessitent spécifiquement des données récentes, les branches peuvent être recréées à partir du dernier instantané de production.

Est-ce que le clonage d’une grosse base de données de production ralentit la création de l’environnement ?

Pas vraiment. Le clonage s’effectue au niveau de la couche de stockage sous forme d’opération sur le système de fichiers, ce qui signifie que le temps nécessaire dépend très peu de la taille de la base de données. La création d’un environnement issu d’une base de données de production contenant 80 Go de données prend à peu près le même temps que celle d’un environnement issu d’une base de 1 Go.

Et si notre base de données de production contenait des données qu’on ne peut pas transférer dans un environnement hors production, même après les avoir anonymisées ?

Le hook de nettoyage peut être configuré pour exclure complètement certaines tables plutôt que de les masquer. Pour les données qui ne peuvent en aucun cas quitter l’environnement de production, la méthode consiste à exclure ces tables du clone et à les remplir avec des données synthétiques à la place. Le reste de la base de données conserve toute sa complexité de production.

Peut-on appliquer le hook de anonymisation à des types de données spécifiques plutôt qu’à toute la base de données ?

Oui. Les hooks de masquage ont un accès complet à la base de données et peuvent appliquer différents traitements à différentes tables : masquer les adresses e-mail dans une table, remplacer les noms dans une autre, et laisser les tables non sensibles telles quelles. La configuration est aussi fine que l’application l’exige.