Installer une protection n’organise pas automatiquement son suivi. Dans un contrat d’infogérance, la sécurité quotidienne repose sur des tâches attribuées, des alertes traitées et des contrôles de reprise. Le périmètre doit rester compréhensible pour le client.
Suivre les systèmes et les accès
Attribuer le contrôle des mises à jour, des équipements hors support et des comptes devenus inutiles. Documenter les exceptions et les décisions de la direction.
Définir le traitement d’une alerte
Identifier qui reçoit l’alerte, sur quels horaires, qui analyse et qui peut isoler un appareil ou modifier un accès. Une console active n’est pas une garantie de support permanent.
Vérifier les sauvegardes
Distinguer contrôle des rapports et tests de restauration. Prévoir les clés, les accès et les applications nécessaires à une reprise réelle.
Faire une revue régulière
Présenter les écarts, les incidents et les actions non terminées. Ajuster le périmètre aux changements d’effectif, de logiciel ou de site.
Exemple et résultat attendu
Une responsabilité écrite et un compte rendu clair sont plus utiles qu’une promesse de protection maximale. Les outils réduisent des risques précis ; ils n’éliminent pas toute possibilité d’incident.
Pour approfondir
Consultez sécurité informatique, test de restauration.
Décrire la chaîne de traitement d’une alerte
Installer une protection et suivre la sécurité au quotidien sont deux activités distinctes. Un contrat doit préciser ce qui se passe entre la détection d’un événement, sa qualification, l’autorisation d’agir et la vérification du retour au travail.
Identifier les outils réellement suivis
Listez antivirus ou protection des postes, pare-feu, comptes cloud et sauvegardes concernés. Pour chacun, indiquez le périmètre de surveillance et les horaires. Une alerte reçue par courriel ne garantit pas une analyse humaine immédiate ni une intervention permanente.
Définir les décisions d’urgence
Convenez des actions pouvant être prises, des contacts et de la méthode de validation lorsque l’interlocuteur habituel est absent. Isoler un appareil, fermer un accès ou interrompre un service peut affecter l’activité : le cadre doit être préparé avant l’incident.
Suivre les écarts jusqu’à leur clôture
Une protection inactive ou une mise à jour en échec doit avoir un responsable et une échéance. Après correction, contrôlez le résultat. Faites remonter à la direction les risques qui demandent un investissement ou une décision métier, plutôt que de les laisser dans un rapport technique.
Un exemple pour une PME à Genève
Exemple illustratif. Une société de conseil à Genève reçoit une alerte concernant le portable d’un collaborateur en déplacement. Le périmètre doit préciser qui contacte cette personne, qui peut isoler le poste et comment poursuivre son travail. La présence d’un antivirus ne répond pas à ces questions d’organisation.
Demandez une explication du parcours complet d’une alerte et de ses limites. Cette discussion permet de distinguer fourniture de licences, administration des outils et réponse aux incidents.
Pour compléter ce sujet avec une démarche liée, consultez MDR : qui surveille et répond aux alertes ?. Adaptez les vérifications aux outils et aux usages de votre entreprise.
Faire le point avec Pixel IT à Genève
Vous souhaitez identifier les mesures à traiter en premier ? Pixel IT accompagne les PME genevoises en sécurité informatique. Décrivez votre environnement et vos besoins pour définir une intervention adaptée.
Sources et documentation
Documentation vérifiée le 15 octobre 2026. Les fonctions disponibles dépendent des produits, versions, licences et réglages concernés.