Prestation 05 · Suivi et dépannage jour et nuit
Infogérance de vos serveurs et applications, depuis Strasbourg, jour et nuit.
Surveillance continue, correctifs de sécurité, sauvegardes relues et astreinte humaine sur incident. Quand ça casse la nuit, c'est nous qui sommes réveillés.
Premier échange gratuit.
Ce que couvre l'infogérance, et ce qu'elle ne couvre pas
Nous exploitons des serveurs et des applications : les vôtres, ou ceux que nous avons écrits. Pas les postes de bureau, pas les imprimantes, pas la bureautique. Le cadre contractuel est dans l'annexe de nos conditions générales sur le maintien en conditions opérationnelles.
- 01
Applications critiques. Une indisponibilité coûte cher, en chiffre d'affaires ou en réputation. Il vous faut une disponibilité mesurée, pas espérée.
- 02
Équipes sans astreinte. Vous n'avez personne la nuit ni le week-end. Nous prenons la veille, vos développeurs restent sur le produit.
- 03
Exigence de continuité. Vous devez prouver un plan de reprise, des sauvegardes et des délais de rétablissement. Nous les mettons en place, nous les testons, et nous vous en donnons le relevé.
Pour qui ce n'est pas
La gestion d'un parc de postes de travail, des licences bureautiques ou de la messagerie d'entreprise : un prestataire de parc informatique est mieux placé.
« Fiable », ça se mesure.
Le détail, sur le blog : ce que « fiable » veut vraiment dire.
Une application qui compte ne doit pas dépendre de la chance. Nous l'exploitons en continu : des sondes qui la testent une fois par minute, des correctifs de sécurité suivis machine par machine, des journaux centralisés et relus, et une astreinte humaine sur les incidents. Quand quelque chose dérape, quelqu'un répond, pas un répondeur.
Nous fixons ensemble des objectifs concrets : le délai de reprise acceptable, la perte de données tolérée, le délai d'intervention puis de rétablissement selon la criticité, et un plan de reprise que nous testons au lieu de le promettre.
Chaque mois, un rapport vous dit ce qui s'est passé, ce que nous avons fait et ce qu'il reste à traiter. Les chiffres de cette page en sortent : ce sont nos instruments, pas nos arguments.
Couvert par l'exploitation
- Supervision continue, une mesure par minute
- Correctifs de sécurité suivis sur chaque machine
- Sauvegardes chaque nuit, relues automatiquement
- Journaux centralisés et conservés pour l'enquête
- Astreinte humaine sur les incidents critiques
- Rapport mensuel : incidents, disponibilité, actions
Trois niveaux, un seul objectif
Trois niveaux, détaillés sur devis. Vous choisissez celui qu'appelle la criticité de chaque application ; le rapport mensuel est dans les trois.
- 01
Essentiel : supervision, sauvegardes et correctifs aux heures ouvrées. Le socle : rien ne passe inaperçu.
- 02
Standard : supervision jour et nuit, alertes qui réveillent quelqu'un, délais d'intervention et de rétablissement engagés.
- 03
Premium : astreinte renforcée, plan de reprise testé, délais de reprise courts et priorité sur les interventions.
Qui répond la nuit
Une alerte réveille l'un de nous deux, qui connaît votre application parce qu'il l'a écrite ou qu'il l'héberge. Pas un centre d'appels, pas un ticket qui attend le matin.
Nos relevés, en détail
Chaque chiffre porte son instrument, sa fenêtre de mesure et son mode de calcul. De quoi refaire la mesure, ou nous contredire. Les études de cas de notre infrastructure et de notre chaîne de livraison décrivent ce qui les produit.
- Votre applicationtourne sur nos serveurs, que nous administrons nous-mêmes
- Point d'entréeles échanges sont chiffrés, le reste est bloqué
- Réseau cloisonnéaucune machine n'est joignable directement depuis l'extérieur
- Serveurs en Francetrois centres de données distincts, à Strasbourg, Roubaix et Gravelines
- Sauvegarde chiffréeune copie chaque nuit, relue, sur un second site
- Supervision jour et nuitnous voyons la panne avant vous, et nous sommes réveillés
| Relevé | Valeur | Instrument | Méthode | Date |
|---|---|---|---|---|
| Disponibilité moyenne des sites que nous hébergeons | 99,89 % | Supervision interne Uptime Kuma (sondes HTTP, une mesure par minute) | Moyenne des 9 sondes HTTP des sites publics hébergés sur machines dédiées, sur les 30 jours glissants clos le 4 septembre 2026 à 23 h 45 UTC. Calcul : temps en état « disponible » rapporté au temps observé, par sonde, puis moyenne non pondérée. | 5 sept. 2026 |
| Disponibilité de notre propre site, www.sanfytech.com | 99,91 % | Supervision interne Uptime Kuma (sonde HTTP, une mesure par minute) | Sonde HTTP publique de www.sanfytech.com, 30 jours glissants clos le 4 septembre 2026 à 23 h 45 UTC : 43 143 relevés « disponible » pour 37 relevés « indisponible ». | 5 sept. 2026 |
| Disponibilité moyenne sur 90 jours des sites suivis depuis au moins 90 jours | 99,74 % | Supervision interne Uptime Kuma (sondes HTTP, une mesure par minute) | Moyenne des 5 sondes de sites dont l'historique couvre réellement 90 jours, fenêtre glissante close le 4 septembre 2026 à 23 h 45 UTC. Les sites mis en service plus récemment sont exclus : nous ne complétons pas une fenêtre courte par une extrapolation. | 5 sept. 2026 |
| Sondes de supervision actives sur le parc | 58 | Supervision interne Uptime Kuma | Inventaire des moniteurs au 5 septembre 2026 : 62 moniteurs actifs, dont 4 simples regroupements d'affichage, soit 58 sondes réelles (HTTP, ping, port TCP et témoins de sauvegarde). | 5 sept. 2026 |
| Machines dont les journaux partent en temps réel au SIEM | 40 | SIEM Wazuh (console d'administration interne) | Recensement des agents auprès du gestionnaire Wazuh au 5 septembre 2026 : 40 agents, tous à l'état « actif », soit 39 machines administrées plus le serveur SIEM lui-même. | 5 sept. 2026 |
| Machines suivies pour l'application des correctifs de sécurité | 39 | Gestionnaire de correctifs PatchMon (console interne) | Inventaire des hôtes enregistrés au 5 septembre 2026 : 39 hôtes, tous à l'état « actif » et tous ayant transmis un rapport dans les 24 heures précédentes. | 5 sept. 2026 |
| Fréquence des sauvegardes des machines hébergées | 1 par jour | Ordonnanceur de sauvegarde du cluster de virtualisation | Tâche quotidienne à 20 h UTC (22 h, heure de Paris) portant sur l'ensemble des invités du cluster, en mode instantané. Trois machines à profil particulier ont une tâche hebdomadaire dédiée. Relevé de la configuration en vigueur le 5 septembre 2026. | 5 sept. 2026 |
| Sauvegardes menées à bien sur les sept derniers jours | 322 sur 322 | Serveur de sauvegarde dédié (Proxmox Backup Server) | Journal des tâches du serveur de sauvegarde entre le 28 août 2026 à 23 h 48 UTC et le 4 septembre 2026 à 23 h 48 UTC : 322 tâches de sauvegarde, 322 terminées sans erreur, aucune en échec. | 5 sept. 2026 |
| Relectures d'intégrité des sauvegardes sur les sept derniers jours | 7 sur 7 | Serveur de sauvegarde dédié (Proxmox Backup Server) | Une sauvegarde jamais relue n'est pas une sauvegarde. Tâche de vérification quotidienne à 4 h UTC sur les instantanés jamais contrôlés, complétée par une relecture intégrale mensuelle au-delà de 30 jours. Sur la fenêtre du 28 août 2026 au 4 septembre 2026 : 7 vérifications, toutes sans erreur. | 5 sept. 2026 |
| Profondeur de restauration conservée pour les machines hébergées | 7 quotidiennes, 2 hebdomadaires, 1 mensuelle | Serveur de sauvegarde dédié (Proxmox Backup Server) | Règles de purge en vigueur le 5 septembre 2026 sur l'espace du parc hébergé : 7 sauvegardes quotidiennes, 2 hebdomadaires et 1 mensuelle conservées. Les machines d'infrastructure hors cluster montent jusqu'à 30 quotidiennes, 12 hebdomadaires et 12 mensuelles. | 5 sept. 2026 |
| Sites distincts détenant une copie des sauvegardes | 2 sites | Serveur de sauvegarde dédié et son miroir hors hébergeur | Copie primaire sur un serveur de sauvegarde dédié situé dans un quatrième centre de données, en Allemagne ; seconde copie recopiée chaque nuit (5 h 30 et 6 h UTC) sur un miroir situé hors de l'hébergeur, en France. Le miroir tire les données : le serveur primaire ne détient aucun accès vers lui. État vérifié le 5 septembre 2026, 1,4 To répliqués. | 5 sept. 2026 |
| Chiffrement des sauvegardes | Chiffrées à la source | Configuration de stockage du cluster de virtualisation | Les données sont chiffrées sur la machine d'origine avant d'être transmises : le serveur de sauvegarde ne reçoit que des blocs chiffrés. Présence d'une clé de chiffrement déclarée sur l'espace de stockage du parc hébergé, vérifiée le 5 septembre 2026 (empreinte relevée, clé jamais exposée). | 5 sept. 2026 |
| Centres de données OVHcloud accueillant nos hyperviseurs | 3 en France | API publique OVHcloud (fiche des serveurs dédiés) | Champ « datacenter » des trois serveurs dédiés relevé le 5 septembre 2026 : sbg3 (Strasbourg), rbx8 (Roubaix), gra2 (Gravelines). Trois sites distincts, tous en France. | 5 sept. 2026 |
| Centre de données accueillant le serveur de sauvegarde | 1 en Allemagne | API publique OVHcloud (fiche du serveur dédié de sauvegarde) | Champ « datacenter » du serveur de sauvegarde relevé le 5 septembre 2026 : lim3 (Limburg, Allemagne). Site séparé des hyperviseurs, et donnée maintenue dans l'Union européenne. | 5 sept. 2026 |
| Machines virtuelles et conteneurs hébergés sur le cluster | 37 | Cluster de virtualisation (inventaire des invités) | Recensement au 5 septembre 2026 : 37 invités actifs, dont 29 conteneurs et 8 machines virtuelles, répartis sur les trois hyperviseurs. | 5 sept. 2026 |
Disponibilité moyenne des sites que nous hébergeons99,89 %
- Instrument
- Supervision interne Uptime Kuma (sondes HTTP, une mesure par minute)
- Méthode
- Moyenne des 9 sondes HTTP des sites publics hébergés sur machines dédiées, sur les 30 jours glissants clos le 4 septembre 2026 à 23 h 45 UTC. Calcul : temps en état « disponible » rapporté au temps observé, par sonde, puis moyenne non pondérée.
- Date
- 5 septembre 2026
Disponibilité de notre propre site, www.sanfytech.com99,91 %
- Instrument
- Supervision interne Uptime Kuma (sonde HTTP, une mesure par minute)
- Méthode
- Sonde HTTP publique de www.sanfytech.com, 30 jours glissants clos le 4 septembre 2026 à 23 h 45 UTC : 43 143 relevés « disponible » pour 37 relevés « indisponible ».
- Date
- 5 septembre 2026
Disponibilité moyenne sur 90 jours des sites suivis depuis au moins 90 jours99,74 %
- Instrument
- Supervision interne Uptime Kuma (sondes HTTP, une mesure par minute)
- Méthode
- Moyenne des 5 sondes de sites dont l'historique couvre réellement 90 jours, fenêtre glissante close le 4 septembre 2026 à 23 h 45 UTC. Les sites mis en service plus récemment sont exclus : nous ne complétons pas une fenêtre courte par une extrapolation.
- Date
- 5 septembre 2026
Sondes de supervision actives sur le parc58
- Instrument
- Supervision interne Uptime Kuma
- Méthode
- Inventaire des moniteurs au 5 septembre 2026 : 62 moniteurs actifs, dont 4 simples regroupements d'affichage, soit 58 sondes réelles (HTTP, ping, port TCP et témoins de sauvegarde).
- Date
- 5 septembre 2026
Machines dont les journaux partent en temps réel au SIEM40
- Instrument
- SIEM Wazuh (console d'administration interne)
- Méthode
- Recensement des agents auprès du gestionnaire Wazuh au 5 septembre 2026 : 40 agents, tous à l'état « actif », soit 39 machines administrées plus le serveur SIEM lui-même.
- Date
- 5 septembre 2026
Machines suivies pour l'application des correctifs de sécurité39
- Instrument
- Gestionnaire de correctifs PatchMon (console interne)
- Méthode
- Inventaire des hôtes enregistrés au 5 septembre 2026 : 39 hôtes, tous à l'état « actif » et tous ayant transmis un rapport dans les 24 heures précédentes.
- Date
- 5 septembre 2026
Fréquence des sauvegardes des machines hébergées1 par jour
- Instrument
- Ordonnanceur de sauvegarde du cluster de virtualisation
- Méthode
- Tâche quotidienne à 20 h UTC (22 h, heure de Paris) portant sur l'ensemble des invités du cluster, en mode instantané. Trois machines à profil particulier ont une tâche hebdomadaire dédiée. Relevé de la configuration en vigueur le 5 septembre 2026.
- Date
- 5 septembre 2026
Sauvegardes menées à bien sur les sept derniers jours322 sur 322
- Instrument
- Serveur de sauvegarde dédié (Proxmox Backup Server)
- Méthode
- Journal des tâches du serveur de sauvegarde entre le 28 août 2026 à 23 h 48 UTC et le 4 septembre 2026 à 23 h 48 UTC : 322 tâches de sauvegarde, 322 terminées sans erreur, aucune en échec.
- Date
- 5 septembre 2026
Relectures d'intégrité des sauvegardes sur les sept derniers jours7 sur 7
- Instrument
- Serveur de sauvegarde dédié (Proxmox Backup Server)
- Méthode
- Une sauvegarde jamais relue n'est pas une sauvegarde. Tâche de vérification quotidienne à 4 h UTC sur les instantanés jamais contrôlés, complétée par une relecture intégrale mensuelle au-delà de 30 jours. Sur la fenêtre du 28 août 2026 au 4 septembre 2026 : 7 vérifications, toutes sans erreur.
- Date
- 5 septembre 2026
Profondeur de restauration conservée pour les machines hébergées7 quotidiennes, 2 hebdomadaires, 1 mensuelle
- Instrument
- Serveur de sauvegarde dédié (Proxmox Backup Server)
- Méthode
- Règles de purge en vigueur le 5 septembre 2026 sur l'espace du parc hébergé : 7 sauvegardes quotidiennes, 2 hebdomadaires et 1 mensuelle conservées. Les machines d'infrastructure hors cluster montent jusqu'à 30 quotidiennes, 12 hebdomadaires et 12 mensuelles.
- Date
- 5 septembre 2026
Sites distincts détenant une copie des sauvegardes2 sites
- Instrument
- Serveur de sauvegarde dédié et son miroir hors hébergeur
- Méthode
- Copie primaire sur un serveur de sauvegarde dédié situé dans un quatrième centre de données, en Allemagne ; seconde copie recopiée chaque nuit (5 h 30 et 6 h UTC) sur un miroir situé hors de l'hébergeur, en France. Le miroir tire les données : le serveur primaire ne détient aucun accès vers lui. État vérifié le 5 septembre 2026, 1,4 To répliqués.
- Date
- 5 septembre 2026
Chiffrement des sauvegardesChiffrées à la source
- Instrument
- Configuration de stockage du cluster de virtualisation
- Méthode
- Les données sont chiffrées sur la machine d'origine avant d'être transmises : le serveur de sauvegarde ne reçoit que des blocs chiffrés. Présence d'une clé de chiffrement déclarée sur l'espace de stockage du parc hébergé, vérifiée le 5 septembre 2026 (empreinte relevée, clé jamais exposée).
- Date
- 5 septembre 2026
Centres de données OVHcloud accueillant nos hyperviseurs3 en France
- Instrument
- API publique OVHcloud (fiche des serveurs dédiés)
- Méthode
- Champ « datacenter » des trois serveurs dédiés relevé le 5 septembre 2026 : sbg3 (Strasbourg), rbx8 (Roubaix), gra2 (Gravelines). Trois sites distincts, tous en France.
- Date
- 5 septembre 2026
Centre de données accueillant le serveur de sauvegarde1 en Allemagne
- Instrument
- API publique OVHcloud (fiche du serveur dédié de sauvegarde)
- Méthode
- Champ « datacenter » du serveur de sauvegarde relevé le 5 septembre 2026 : lim3 (Limburg, Allemagne). Site séparé des hyperviseurs, et donnée maintenue dans l'Union européenne.
- Date
- 5 septembre 2026
Machines virtuelles et conteneurs hébergés sur le cluster37
- Instrument
- Cluster de virtualisation (inventaire des invités)
- Méthode
- Recensement au 5 septembre 2026 : 37 invités actifs, dont 29 conteneurs et 8 machines virtuelles, répartis sur les trois hyperviseurs.
- Date
- 5 septembre 2026
Relevés du 5 septembre 2026.
Avant le prochain incident
Pour s'y préparer, sur le blog : ce qu'un plan de reprise d'activité contient vraiment.
Que se passe-t-il quand une alerte tombe à trois heures du matin ?
La sonde nous prévient, l'un de nous se connecte, rétablit le service et vous écrit ce qui s'est passé. Selon le niveau choisi, le délai d'intervention est engagé dans le contrat.
Que contient le rapport mensuel ?
Les incidents du mois, la disponibilité mesurée par les sondes, les correctifs appliqués, les sauvegardes relues et ce que nous recommandons. Les mêmes chiffres que ceux publiés ici.
Comment choisir le niveau ?
Par la criticité : ce que coûte une heure d'arrêt, et à quelle heure. Une application interne utilisée le jour relève souvent de l'Essentiel ; un site qui encaisse la nuit, du Standard ou du Premium. Nous le décidons avec vous au cadrage.
Délais, devis, propriété du code, fin de contrat : les réponses sont dans la FAQ.
Sur devis. Les ordres de grandeur sont publiés sur la page devis, avec ce qui fait varier un budget.
Avant le prochain incident
Qui répond quand votre application tombe ?
Décrivez-nous ce que vous exploitez aujourd'hui. Nous vous dirons ce que nous surveillons, ce que nous reprenons, et à quel prix.
Réponse sous 24 h ouvrées, par l'un des deux fondateurs.