Test d’endurance

Test d’endurance : Maintien d’une charge soutenue sur une longue durée, qui met en évidence les fuites de mémoire et l’engorgement progressif.

Le mot appartient à la famille « Technique » du lexique. Cette page dit ce qu’il recouvre, comment il se formule dans un cahier des charges, et ce qu’il vaut mieux ne pas écrire.

Pourquoi Test d’endurance compte sur un projet mobile

Ce que recouvre Test d’endurance finit toujours dans une ligne de devis, sous un intitulé plus vague. Nommer le mécanisme, c’est pouvoir comparer deux propositions au lieu de comparer deux totaux.

Le sujet se présente rarement seul. Il arrive au milieu d’une décision plus large, et c’est à ce moment qu’il faut savoir de quoi on parle.

De la définition à la ligne de cahier des charges

Le chapitre des contraintes techniques est la bonne place pour « Test d’endurance », avec les volumes attendus, les pics prévus et les environnements à livrer.

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

• Les intégrations tierces, nommées, avec leur documentation et leurs limites d’appel.
• La sauvegarde des données : fréquence, durée de rétention, restauration réellement testée.
• La supervision : quelles alertes, vers qui, sous quel délai d’intervention.
• Le sort des données à la fin du contrat, format d’export compris.

Cette formulation se rédige avant la consultation, pas après réception des propositions : c’est elle qui rend deux devis comparables entre eux.

Le modèle de cahier des charges du guide reprend ces rubriques dans l’ordre attendu par une agence, et la grille de lecture des devis montre à quoi ressemble un chiffrage comparable.

Comment le vérifier à la recette

Test d’endurance ne se prouve pas par une capture d’écran. La recette doit produire une trace : un chiffre, un journal, un rapport.

• Demander une restauration de sauvegarde réellement exécutée, avec sa date.
• Relever les temps d’affichage des écrans les plus consultés, chiffres à l’appui.
• Demander la facture d’hébergement du mois, pour éviter la découverte à six mois.

Ces vérifications s’inscrivent au cahier de recette, avec un nom en face de chacune. Une case sans responsable reste vide.

Les pièges à éviter

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

• Dimensionner l’infrastructure sur le trafic du lancement et non sur celui d’une campagne.
• Considérer les sauvegardes comme faites parce qu’elles sont configurées, sans tester de restauration.
• Découvrir les coûts d’hébergement après la mise en ligne, faute de les avoir demandés au devis.
• Mesurer la performance sur un téléphone récent et l’annoncer comme celle du parc réel.
• 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 :

• Edge computing
• Stockage externe
• API REST
• Webhook
• Notification push

Questions fréquentes

Qu’est-ce que « Test d’endurance » ?

Maintien d’une charge soutenue sur une longue durée, qui met en évidence les fuites de mémoire et l’engorgement progressif. 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.

Quand faut-il en parler dans le projet ?

Au cadrage, avec les autres contraintes techniques. Une fois l’application en ligne, la même décision se paie en migration, en interruption de service et parfois en reprise des données déjà collectées.

Où placer ce point dans le cahier des charges ?

Dans le chapitre qui correspond à sa nature, jamais dans une ligne fourre-tout. Le modèle de cahier des charges propose les rubriques attendues et l’ordre dans lequel les remplir.

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