Données mock et simulations résiduelles en production

L'émergence des environnements de développement assistés par l'intelligence artificielle (Cursor, Bolt, v0, Lovable, Claude Code) a accéléré le prototypage applicatif de façon spectaculaire. Pour permettre aux créateurs de visualiser immédiatement une interface utilisateur sans attendre la configuration complète d'une base de données ou d'une API tierce, ces outils recourent massivement à des données simulées (mocks, demo data, tableaux d'objets hardcodés en mémoire).

Le piège survient lors du passage en production : l'interface semble parfaitement opérationnelle en apparence, mais certaines vues ou flux métier continuent de s'alimenter sur ces fixtures factices ou basculent silencieusement dessus en cas d'incident réseau.

L'audit de santé de code GVO inspecte précisément cette frontière entre code runtime de production et artefacts de simulation.

Les quatre visages des simulations résiduelles

Dans le moteur GVO, le pack de santé du code identifie quatre formes distinctes de données résiduelles :

flowchart TD
    A[Code de production] --> B[1. Dataset factice actif en mémoire]
    A --> C[2. Métriques métier statiques sur dashboard]
    A --> D[3. Fallback silencieux vers mock sur erreur]
    A --> E[4. Import direct de fixtures de test]
    style B stroke:#f59e0b,stroke-width:1px
    style C stroke:#f59e0b,stroke-width:1px
    style D stroke:#ef4444,stroke-width:2px
    style E stroke:#f59e0b,stroke-width:1px

1. Le dataset simulé actif en production (GVO-CODE-STALE-SIMULATION-001)

Un tableau constant de données métier (const mockUsers = [...] ou const sampleOrders = [...]) déclaré ou importé directement dans un composant de page de production. Les utilisateurs réels voient des fiches de test ou des profils pré-remplis coexister avec leurs données réelles.

2. Les métriques métier littérales (GVO-CODE-STALE-SIMULATION-002)

Des indicateurs clés de performance (KPI) inscrits en dur dans les composants de tableau de bord (revenue: 48500, growth: 12.4, activeCustomers: 1250). Aucun appel API ou requête SQL n'est exécuté : le tableau de bord affiche un succès commercial artificiel et déconnecté de la réalité.

3. Le fallback silencieux vers des données simulées (GVO-CODE-STALE-SIMULATION-003)

C'est le schéma le plus pernicieux : une fonction tente légitimement d'appeler l'API de production, mais enrobe l'appel d'un bloc d'interception renvoyant un jeu de données mock en cas d'échec :

// ANTI-PATTERN : FALLBACK SILENCIEUX VERS DES MOCKS EN CAS D'ÉCHEC
export async function getWorkspaceInvoices(workspaceId: string): Promise<Invoice[]> {
  try {
    const res = await fetch(`/api/workspaces/${workspaceId}/invoices`);
    if (!res.ok) throw new Error('API indisponible');
    return await res.json();
  } catch (err) {
    // DANGER MAJEUR : MASQUAGE TOTAL DE LA PANNE
    // L'application retourne des factures fictives au lieu d'afficher un état d'erreur
    return DEMO_INVOICES;
  }
}

En cas de coupure de base de données ou de jeton API expiré, aucun signal d'incident n'apparaît dans vos outils de monitoring. Les utilisateurs visualisent des données fictives et peuvent prendre des décisions erronées.

4. L'import direct de fixtures de test (GVO-CODE-STALE-SIMULATION-004)

L'importation explicite de fichiers provenant des répertoires fixtures/, __mocks__/ ou tests/ au sein de modules situés sous src/app/ ou src/components/. Cela alourdit le bundle client de données inutiles et expose potentiellement des identifiants ou informations de test.

Pourquoi les simulations résiduelles sont critiques

1. Illusion de bon fonctionnement : Des fonctionnalités semblent achevées et testées, alors qu'aucune transaction réelle n'a jamais été enregistrée en base.
2. Fuite de données trompeuses : Affichage d'informations de clients fictifs pouvant induire en erreur les utilisateurs finaux sur la confidentialité de la plateforme.
3. Absence de résilience observable : En dissimulant les pannes d'API derrière des données de démonstration, les équipes techniques ignorent que leur backend est défaillant en production.
4. Perte de confiance utilisateur : La découverte par un client que ses statistiques ou ses factures sont statiques détruit la crédibilité du service.

Bonnes pratiques de séparation et d'assainissement

Pour maintenir une frontière imperméable entre prototypage et exploitation réelle :

1. Isoler strictement les fixtures dans les répertoires de test

Les répertoires tests/, __tests__/, fixtures/ et les fichiers *.stories.tsx sont les seuls emplacements légitimes pour déclarer des données factices. Aucun module de production ne doit importer ces chemins.

2. Préférer des états vides (Empty States) aux fausses données

Lorsqu'un compte utilisateur vient d'être créé et ne possède encore aucune donnée, affichez une interface d'intégration guidée (onboarding empty state) incitant à la première action, plutôt qu'un faux historique de commandes.

3. Propager des états d'erreur explicites

En cas d'échec d'une requête de données, présentez un composant d'erreur dédié offrant un bouton de réessai, ou retournez un verdict technique exploitable. Ne dégradez jamais une panne vers un mock en environnement de production.

Ce que GVO observe lors de l'audit

Le moteur d'audit GVO catégorise chaque fichier source selon son contexte d'exécution (PRODUCTION, TEST, FIXTURE, STORY).

1. Détection lexicale ciblée : Recherche des identifiants et variables évocatrices (mockData, demoUsers, sampleRevenue, dummyOrders).
2. Analyse d'usage : Vérification de la consommation effective de la variable simulée au sein du flux de rendu ou de la logique métier.
3. Absence de source dynamique : Le moteur constate l'absence d'appel réseau (fetch, ORM, client Supabase) alimentant la même surface.
4. Verdicts de preuve :
   • CONFIRMED : Une donnée explicitement simulée est activement consommée dans un module runtime de production.
   • TO_VERIFY : Des métriques statiques multiples sont présentes sans source dynamique évidente, nécessitant confirmation métier.
   • DISMISSED : La simulation est rigoureusement cantonnée à l'environnement de test ou de développement.