Révisé · Ressources Hosmio
Avant de commencer
Rassemblez l’inventaire applicatif, le contact client, l’opérateur actuel et un remplaçant possible. Disposez d’un emplacement pour stocker la note qui reste accessible si le VPS est indisponible. Référencez un stockage protégé des secrets ; ne collez pas d’identifiants dans le document.
01
Définissez d’abord la limite du service.
Listez le travail nécessaire pour que l’application reste utile : revues d’accès, mises à jour du système d’exploitation, changements d’environnement d’exécution, maintenance de la base de données, sauvegardes, supervision et renouvellement de domaine. Séparez cela du travail que le fournisseur d’infrastructure a réellement accepté d’effectuer. Un bouton de réinitialisation, une option de sauvegarde facultative ou un contact support n’établissent pas à eux seuls un contrat de service géré.
Notez tout ce dont le responsable est encore inconnu. Pour Hosmio, les interventions finales du fournisseur et le périmètre du support nécessitent une confirmation. Planifier vos propres responsabilités dès maintenant évite de supposer qu’un incident applicatif sera diagnostiqué automatiquement par l’hébergeur.
02
Attribuez les actions et l’autorité de décision.
| Activité | Rôle responsable | Déclencheur et vérification |
|---|---|---|
| Mise en production d'application | Opérateur d'application ; suppléant nommé | Changement approuvé ; tester la connexion et une tâche représentative |
| Maintenance perturbatrice | Approbateur des changements côté client | Fenêtre d'impact connue ; go/no-go explicite |
| Exercice de reprise | Opérateur de reprise | Répétition planifiée ; enregistrements et pièces jointes restaurés vérifiés |
| Communication d'incident | Responsable actuel de l'incident | Changement à impact significatif ; passation horodatée |
| Exception de paiement | Contact achats | Résultat incohérent ou incertain ; conserver les détails factuels du paiement |
Un rôle n'est utile que lorsque l'équipe y a affecté une personne joignable. Consignez l'affectation actuelle dans vos notes opérationnelles privées. Une même personne peut occuper plusieurs rôles, mais la distinction évite qu'un technicien approuve accidentellement un risque métier au nom du client.
03
Convenez du changement et de son point d’arrêt.
Pour une mise à jour planifiée, consignez pourquoi elle est nécessaire, ce qui change, les services concernés et comment revenir à un état connu. Précisez qui peut approuver une interruption et qui peut arrêter le travail si les vérifications échouent. Utilisez une fenêtre convenue avec un fuseau horaire explicite ; « après les heures ouvrables » est ambigu pour une équipe internationale.
Avant de commencer, vérifiez les accès, la copie de reprise et la version ou configuration exacte en cours de modification. Fixez une échéance à laquelle l'équipe doit soit réussir les vérifications d'acceptation, soit déclencher son plan de reprise. Ne décrivez pas le retour arrière comme instantané si aucune répétition réelle ne soutient cette attente.
04
Choisissez des signaux qui conduisent à une action.
Commencez par la tâche utilisateur : un compte représentatif peut-il se connecter, lire l'enregistrement attendu et effectuer une opération sûre ? Ajoutez des vérifications des ressources et des dépendances pour aider à expliquer les échecs. Une application peut répondre à une requête de santé basique alors qu'une file d'attente en arrière-plan ne progresse plus.
Choisissez les seuils d'escalade selon les besoins et les observations du projet. Un portail illustratif pourrait considérer deux vérifications de tâche planifiée échouées comme un signal d'investigation, plutôt qu'une définition universelle de panne. Consignez comment la vérification s'exécute et ce que l'opérateur doit examiner ensuite. Une alerte sans destinataire responsable ne crée pas de couverture.
05
Préparez le remplacement avant un incident.
Demandez à l'opérateur remplaçant de trouver l'inventaire, la procédure d'accès protégé, le dernier enregistrement de changement et les notes de reprise sans accompagnement. Il doit pouvoir distinguer un fait connu d'une hypothèse non testée. Donnez-lui une autorité adaptée au rôle, plutôt que de partager un compte personnel simplement pour faciliter l'accès.
Gardez les horodatages d'incident sans ambiguïté. La RFC 3339 définit des représentations d'horodatage avec UTC ou un décalage explicite ; un enregistrement tel que 2026-09-12T14:00:00Z évite une valeur d'horloge locale inexpliquée. RFC 3339 : horodatages Internet ↗ Suivez le guide de passation des fuseaux horaires pour un transfert plus complet de la responsabilité en cours.
06
Répétez la note et consignez les lacunes.
Utilisez un exercice sur table avant de vous fier au document. Présentez une tâche en arrière-plan échouée hypothétique pendant que l'opérateur principal est indisponible. Demandez au remplaçant d'identifier l'impact, les actions autorisées, la voie d'approbation et la prochaine mise à jour. N'effectuez pas de vrais changements de service simplement pour démontrer que la note existe.
Consignez les permissions manquantes, les responsabilités floues et les documents inaccessibles comme des actions avec des responsables. Révisez la note lorsque le personnel, les intégrations, les objectifs de reprise ou les fournisseurs changent. L'achèvement signifie qu'une autre personne autorisée peut suivre le processus et expliquer ses limites ; cela ne signifie pas qu'une équipe de support continue a été établie.
Continuez avec une répétition de sortie de fournisseur et les modèle de note d'incident. Gardez la note opérationnelle assez concise pour être utilisée pendant un problème et renvoyez à des procédures plus détaillées si nécessaire.