Latence réseau

Latence réseau : Délai entre l’envoi d’une requête et l’arrivée de la réponse, souvent plus déterminant que le débit dans la fluidité ressentie.

Entrée de la famille « Technique » du glossaire. Elle s’adresse à un porteur de projet qui doit rédiger, comparer ou recetter, pas à un spécialiste du sujet.

Où intervient Latence réseau dans un projet

Latence réseau se manifeste quand le réseau est mauvais, quand la charge monte ou quand l’application tourne en arrière-plan. Ce sont exactement les moments qu’une recette en salle de réunion ne reproduit pas.

Dans la pratique, deux interlocuteurs qui n’ont pas la même définition en tête avancent d’accord pendant des semaines, puis découvrent le désaccord à la livraison.

Comment l’écrire dans un cahier des charges

Un cahier des charges sérieux relie « Latence réseau » à un critère de recette : une phrase que l’on peut cocher ou refuser, pas une intention.

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

• Le volume de données attendu au lancement, puis à douze mois.
• Le comportement de l’application sans réseau, et ce qui doit rester consultable.
• Les délais d’affichage acceptables sur les écrans les plus consultés.
• L’hébergement retenu, sa localisation, et qui en paie l’abonnement mensuel.

Rien n’oblige à tout figer dès le premier jour. Ce qui reste ouvert doit alors être signalé comme tel, avec la date à laquelle la décision sera prise.

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.

Les contrôles à prévoir

À la recette, Latence réseau se vérifie une fois avant la mise en ligne, puis à chaque version. Ces sujets se dégradent sans prévenir.

• Demander une restauration de sauvegarde réellement exécutée, avec sa date.
• Déclencher une alerte pour vérifier qu’elle arrive bien à quelqu’un.
• Demander la facture d’hébergement du mois, pour éviter la découverte à six mois.

Ce qui n’est pas vérifié à la recette ne sera pas vérifié du tout : le jour de la mise en ligne, plus personne n’a le temps.

Erreurs fréquentes

Aucune de ces erreurs ne se voit le jour où elle est commise. Toutes se paient plus tard, au moment le moins commode.

• 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.
• Se contenter d’une réponse orale en réunion, jamais reprise dans le document contractuel.

Termes liés

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

• Blended CAC
• Prêt pour la vente
• API REST
• Webhook
• Notification push

Questions fréquentes

Qu’est-ce que « Latence réseau » ?

Délai entre l’envoi d’une requête et l’arrivée de la réponse, souvent plus déterminant que le débit dans la fluidité ressentie. 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.

Le sujet doit-il apparaître dans le devis ?

Oui, sous un poste identifiable. Un devis qui fond conception, développement, tests et exploitation dans une ligne unique ne permet ni de comparer, ni de discuter, ni de couper.

Par où commencer quand le sujet est nouveau ?

Par les parcours et les règles de gestion, pas par les outils. Le guide du cahier des charges donne l’ordre dans lequel poser les questions à une agence.

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