Durée de test

Durée de test : Période pendant laquelle l’expérience reste active, choisie pour couvrir des cycles d’usage complets et non pour arriver à un résultat.

Ce terme appartient à la famille « Analytics ». La page reprend l’essentiel : à quoi ça sert, comment l’écrire, ce qui se passe quand on l’oublie.

Ce que recouvre Durée de test, concrètement

Sur une application, Durée de test sert à décider quoi construire ensuite. C’est la seule alternative sérieuse à l’avis du dernier utilisateur croisé en réunion.

Sur un projet réel, la question ne se pose jamais en théorie : elle arrive dans un devis, dans une réunion de cadrage ou dans un rapport de recette.

La traduction en exigences

Un cahier des charges complet relie « Durée de test » au consentement : ce qui est mesuré avec accord, ce qui ne l’est pas, et ce que devient le rapport dans ce cas.

À écrire noir sur blanc, dans le chapitre qui correspond :

• Le plan de marquage : liste des événements, de leurs propriétés et de leurs déclencheurs.
• L’outil de mesure retenu, et qui en paie l’abonnement.
• La recette du marquage, distincte de la recette fonctionnelle.
• L’accès aux données brutes, et leur format d’export.

Reste à désigner qui écrit cette ligne et qui la valide. Sans nom en face, la rubrique se remplit la veille de la signature, avec les mots du prestataire.

Pour le cadre général, le guide des prix donne les fourchettes constatées en France et le modèle de cahier des charges la structure qui les rend opposables.

Ce que ça change au moment de la recette

Le contrôle de « Durée de test » est une recette à part entière, distincte de la recette fonctionnelle, et régulièrement oubliée des plannings.

• Déclencher chaque événement à la main et le retrouver dans l’outil de mesure.
• Vérifier que les propriétés attendues sont remplies, pas seulement présentes.
• Relire le tableau de bord avec la personne censée décider à partir de lui.

Un prestataire sérieux propose ces contrôles de lui-même. Quand ce n’est pas le cas, c’est au client de les inscrire au cahier de recette.

Erreurs fréquentes

Sur ce point précis, voici ce qui coûte le plus cher aux porteurs de projet, dans l’ordre où on le rencontre.

• Suivre des indicateurs flatteurs qui ne déclenchent aucune décision.
• Comparer deux périodes sans tenir compte de la saisonnalité ni des campagnes en cours.
• Ne confier la recette du marquage à personne, et découvrir des événements vides des mois plus tard.
• Prendre une corrélation lue dans un tableau de bord pour une cause.
• Ne relier le sujet à aucun critère de recette : ce qui ne se vérifie pas ne se livre pas.

Termes liés

Les entrées du glossaire déjà publiées sur des sujets voisins :

• Taille d’échantillon
• Profondeur de session
• Rétention exacte
• Support
• Métrique garde-fou

Questions fréquentes

Qu’est-ce que « Durée de test » ?

Période pendant laquelle l’expérience reste active, choisie pour couvrir des cycles d’usage complets et non pour arriver à un résultat. Cette définition suffit pour une discussion de cadrage. Pour un contrat, il faut y ajouter ce que le terme recouvre exactement sur votre application.

À quel moment mettre la mesure en place ?

Pendant le développement, avec le reste. Une donnée non collectée ne se reconstitue pas : la mesure ajoutée après le lancement fait perdre la période la plus instructive, celle des tout premiers utilisateurs.

Est-ce que ça se retrouve dans le devis ?

Un devis lisible sépare conception, design, développement, tests, publication et suivi. La grille de lecture des devis détaille poste par poste ce qui doit y apparaître.

Toutes les définitions publiées sont rassemblées dans l’index du glossaire, classées de A à Z et par famille.