« On veut quelque chose de fiable. » C'est une demande légitime, mais le mot « fiable » ne veut rien dire tant qu'on ne le traduit pas en chiffres et en engagements. Une application fiable, ce n'est pas une application qui ne tombe jamais — ça n'existe pas. C'est une application dont on connaît le comportement attendu, dont on mesure les écarts, et dont on remet le service en marche dans des délais garantis. Voici comment on décompose tout ça chez Sanfytech.
Définir la fiabilité : uptime, RTO, RPO
Trois indicateurs suffisent à cadrer une discussion sérieuse sur la fiabilité.
L'uptime (ou disponibilité) mesure le pourcentage de temps pendant lequel le service est opérationnel. Le RTO (Recovery Time Objective) est le délai maximum acceptable pour remettre le service en marche après un incident. Le RPO (Recovery Point Objective) est la quantité maximale de données qu'on accepte de perdre, exprimée en temps — un RPO d'une heure signifie qu'au pire, vous reperdez une heure de données.
Tant qu'on n'a pas mis des chiffres sur ces trois lignes, « fiable » reste un vœu pieux.
Ce qu'un SLA 99,9% veut dire concrètement
Un SLA (Service Level Agreement) à 99,9% d'uptime, c'est environ 8h45 d'indisponibilité tolérée par an, soit à peu près 43 minutes par mois. À 99,99%, on tombe sous une heure par an. La différence entre ces deux chiffres n'est pas cosmétique : elle se traduit par de l'architecture redondante, du coût et de la complexité.
Le piège classique est de promettre 99,99% sans en payer le prix technique. Notre approche est de proposer le niveau de SLA réellement adapté à votre usage — un outil interne et une plateforme de vente en ligne n'ont pas les mêmes exigences — et de l'écrire noir sur blanc, avec ce qui se passe si on ne le tient pas.
Un SLA, ce n'est pas une promesse de ne jamais tomber. C'est un engagement écrit sur la vitesse à laquelle on se relève — et sur ce qu'il vous arrive si on ne le tient pas.
Monitoring et alerting : voir avant de subir
La fiabilité commence par la visibilité. Nous supervisons en continu la disponibilité, les temps de réponse, l'usage CPU/mémoire/disque, et les erreurs applicatives. L'objectif n'est pas d'accumuler des graphiques, mais de déclencher une alerte au bon moment — idéalement avant que l'utilisateur ne remarque quoi que ce soit.
Une bonne règle d'alerting détecte la dégradation (la latence qui grimpe, le disque qui se remplit) et pas seulement la panne franche. C'est la différence entre intervenir à 3h du matin sur un incident maîtrisé et découvrir le problème à 9h avec les clients en ligne.
Sauvegardes et PRA
Une sauvegarde qu'on n'a jamais restaurée n'est pas une sauvegarde, c'est un espoir. Nous sauvegardons quotidiennement, en chiffré, et nous testons les restaurations régulièrement. Le PRA (Plan de Reprise d'Activité) documente précisément quoi restaurer, dans quel ordre, et en combien de temps — pour ne pas improviser le jour où ça compte vraiment.
Astreinte, GTI et GTR
Quand un incident critique survient hors heures ouvrées, l'astreinte prend le relais. Deux engagements la structurent : la GTI (Garantie de Temps d'Intervention), délai sous lequel quelqu'un prend l'incident en main, et la GTR (Garantie de Temps de Rétablissement), délai sous lequel le service est rétabli. Ces deux chiffres sont contractuels : ils transforment « on s'en occupera » en engagement mesurable.
Notre checklist fiabilité
- Définir uptime, RTO et RPO cibles avant de parler technique.
- Écrire le SLA, et écrire aussi ce qui se passe s'il n'est pas tenu.
- Alerter sur la dégradation, pas seulement sur la panne.
- Tester les restaurations de sauvegarde, pas seulement leur existence.
- Documenter le PRA et le rejouer périodiquement.
- Fixer GTI et GTR par écrit, avec une astreinte réelle derrière.
En résumé
« Fiable » devient utile quand on le traduit en indicateurs mesurables et en engagements écrits : un uptime cible, un RTO/RPO assumé, un monitoring qui alerte tôt, des sauvegardes testées, un PRA documenté et une astreinte avec GTI/GTR. C'est exactement ce que couvre notre infogérance — un seul responsable, pas de renvoi de balle.
Pour mettre votre application sous surveillance et vous appuyer sur des engagements clairs, découvrez notre infogérance 24/7 ou contactez-nous : premier échange gratuit, réponse sous 24h ouvrées.
