Quels accès un prestataire d’astreinte doit-il réellement recevoir pour surveiller un parc de serveurs, et lesquels doivent rester exclusivement du côté de l’équipe interne ? Cette question, souvent réglée dans l’urgence au moment de la signature du contrat, mérite d’être tranchée en amont, avant même le premier échange commercial avec un prestataire candidat.
Externaliser la supervision ne se limite pas à donner un accès SSH et un numéro de téléphone d’astreinte : sans seuils d’alerte définis à l’avance et sans procédure d’escalade formalisée, le prestataire externe se retrouve à interpréter, seul et dans l’urgence, ce qui constitue un incident méritant réveil de nuit ou simple ticket du lendemain.
Les accès à formaliser avant tout transfert
Le premier axe de la checklist porte sur la nature exacte des accès accordés. Un compte SSH partagé, utilisé par plusieurs techniciens du prestataire, empêche toute traçabilité en cas d’action malencontreuse sur le parc. La pratique la plus sûre consiste à créer des comptes nominatifs, chacun avec sa propre clé publique, révocables individuellement sans affecter les autres membres de l’équipe prestataire :
- Comptes SSH nominatifs par technicien, jamais un compte générique partagé.
- Accès en lecture seule aux journaux (Nginx, PHP-FPM, MySQL) pour le diagnostic, distinct des droits d’intervention.
- Accès limité au panneau de supervision existant, sans droits d’administration sur les comptes d’hébergement eux-mêmes.
- Procédure de révocation immédiate documentée, testée avant la mise en service du contrat.
Définir des seuils d’alerte avant la signature, pas après le premier faux positif
Un prestataire externe qui découvre les seuils d’alerte du parc au moment du premier incident les définira selon ses propres standards, rarement adaptés aux particularités du parc concerné. Un site associatif à faible trafic et une boutique en ligne à forte saisonnalité ne justifient pas les mêmes seuils de charge processeur ou de temps de réponse avant déclenchement d’une alerte.
| Indicateur | Seuil d’alerte proposé | Justification |
|---|---|---|
| Temps de réponse HTTP | Supérieur à 3 secondes pendant 5 minutes | Au-delà, l’expérience utilisateur se dégrade nettement |
| Charge processeur | Supérieure à 90 % pendant 10 minutes | Distingue un pic ponctuel d’une saturation réelle |
| Espace disque disponible | Inférieur à 10 % restant | Laisse une marge d’intervention avant blocage |
Ces seuils, discutés et validés conjointement avant la signature du contrat, deviennent l’annexe technique qui accompagne l’accord commercial, plutôt qu’une découverte négociée en pleine nuit lors d’un premier faux positif.
L’escalade : préciser qui décide, pas seulement qui est prévenu
Une procédure d’escalade mal définie se limite souvent à une liste de contacts à prévenir en cas d’incident, sans préciser qui détient réellement l’autorité de décision à chaque étape. Notre modèle distingue trois niveaux clairement séparés :
- Niveau 1 : le prestataire externe applique un correctif documenté par avance (redémarrage d’un service, purge d’un cache) sans validation préalable.
- Niveau 2 : le prestataire externe contacte un référent technique interne nommé, disponible par astreinte, avant toute action non documentée.
- Niveau 3 : le référent interne juge l’incident majeur et déclenche la procédure de gestion de crise du parc, distincte de cette supervision courante.
Cette gradation évite les deux écueils classiques : un prestataire qui intervient seul sur des décisions qui dépassent son mandat, ou à l’inverse un prestataire qui réveille systématiquement un référent interne pour des incidents mineurs déjà couverts par une procédure documentée.
Documenter les faux positifs déjà connus du parc
Un parc de serveurs accumule, au fil du temps, des particularités qui déclenchent des alertes sans constituer de réels incidents : une tâche de sauvegarde nocturne qui fait grimper temporairement la charge processeur, ou un pic de trafic prévisible chaque lundi matin. Transmettre cette liste de faux positifs connus au prestataire avant transfert lui évite d’escalader inutilement des situations déjà identifiées comme normales par l’équipe interne.
Un prestataire d’astreinte bien informé n’est pas celui qui reçoit le plus d’accès : c’est celui à qui l’on a expliqué, à l’avance, ce qui est normal et ce qui ne l’est pas.
Ce que cette checklist ne couvre pas
Cette liste ne traite pas du choix du prestataire lui-même, ni des critères de sélection commerciale ou de réputation à évaluer en amont : elle suppose ce choix déjà fait, et se concentre exclusivement sur la préparation technique du transfert d’astreinte.
En résumé
Confier la supervision d’un parc de serveurs à un prestataire externe se prépare avant la signature, pas après le premier incident. Des accès nominatifs et révocables, des seuils d’alerte adaptés au parc réel plutôt qu’à des standards génériques, et une escalade à trois niveaux qui précise qui décide à chaque étape : ces trois piliers transforment une externalisation risquée en un transfert maîtrisé.
