Point-in-time recovery

Point-in-time recovery : Capacité à restaurer la base à un instant précis, utile pour annuler une suppression accidentelle sans tout perdre.

Classé dans la famille « Technique », ce terme revient dans les échanges entre un client et son agence. Voici ce qu’il faut en comprendre avant d’en discuter le prix.

Pourquoi Point-in-time recovery compte sur un projet mobile

Ce que recouvre Point-in-time recovery 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.

Ce que le mot recouvre exactement dépend du projet. Ce qui suit vaut pour la plupart des applications mobiles françaises, et sert de point de départ à la discussion.

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

Dans un cahier des charges, Point-in-time recovery se traduit par une exigence mesurable : dans quelles conditions, avec quel volume, et à partir de quel seuil on considère que ce n’est plus tenu.

À é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.

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

À la recette, Point-in-time recovery 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.

Les pièges à éviter

Ces erreurs ne viennent presque jamais d’un manque de compétence, mais d’un point qui n’a été écrit nulle part.

• 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.
• Confier la décision au prestataire, puis la contester au moment de la recette.

Termes liés

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

• Dictionnaire de données
• API REST
• Webhook
• Notification push
• Lien profond

Questions fréquentes

Point-in-time recovery : de quoi parle-t-on exactement ?

Capacité à restaurer la base à un instant précis, utile pour annuler une suppression accidentelle sans tout perdre. Le mot est employé tel quel par les équipes francophones. C’est celui à utiliser dans les échanges avec une agence, y compris quand la traduction française existe.

Qui vérifie que c’est bien fait ?

Le client, à la recette, avec un critère écrit à l’avance. À défaut, personne : ces sujets ne se voient pas à l’écran, et un utilisateur ne signale que leurs conséquences.

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.