Infogérance de serveurs : que déléguer et que garder en interne ?

L’infogérance de serveurs consiste à déléguer des tâches d’exploitation définies : surveillance, maintenance, administration ou sauvegarde selon le contrat. Pour savoir quoi confier au prestataire et quoi conserver en interne, partez des couches techniques, attribuez chaque tâche à un responsable et exigez une preuve de réalisation. Cette méthode permet à une PME de déléguer sans perdre la maîtrise de ses applications métiers.

Quels serveurs et quelles couches confier au prestataire ?

Confiez uniquement les couches identifiées dans le périmètre contractuel. Avant de déléguer l’exploitation, l’entreprise doit inventorier ses serveurs physiques, ses machines virtuelles et ses environnements hébergés. La responsabilité peut porter sur le matériel, l’hyperviseur, le système d’exploitation, les services techniques ou certaines applications. Ces couches ne relèvent pas nécessairement du même acteur.

Sur un serveur installé dans les locaux, le prestataire peut assurer la surveillance du système tandis que l’entreprise conserve la responsabilité des locaux et de l’alimentation électrique. Dans un environnement hébergé, une partie de l’infrastructure relève de l’hébergeur. L’éditeur d’un logiciel métier peut, de son côté, être seul habilité à intervenir sur l’application.

Une description précise du périmètre évite les situations où chacun pense que l’autre assure une tâche essentielle. Pour comprendre le cadre général, consultez notre guide de l’infogérance informatique.

Pour chaque serveur, ajoutez à l’inventaire son propriétaire métier, son rôle et les services dont il dépend. Une application peut fonctionner sur une machine virtuelle tout en ayant besoin d’une base de données séparée, d’un annuaire et d’un partage de fichiers. Déléguer seulement la machine applicative laisserait une partie du service sans responsable clairement désigné.

Distinguez aussi les interventions courantes des projets. Installer un correctif prévu au contrat n’équivaut pas à migrer un système devenu obsolète ni à remplacer un matériel. Faites préciser comment sont traités les équipements hors support, les licences et les changements d’architecture. Vous pourrez ainsi comparer deux offres sur un périmètre identique plutôt que sur le seul nombre de serveurs.

Quelles tâches d’exploitation inclure dans l’infogérance de serveurs ?

La prestation peut couvrir la supervision des ressources, l’analyse des alertes, l’installation des correctifs, la gestion des comptes privilégiés, le contrôle des sauvegardes et le traitement des incidents. Aucun de ces services ne doit être présumé inclus : leur fréquence, leurs horaires et leurs exclusions doivent figurer au contrat.

La supervision informatique peut, par exemple, détecter une saturation de disque. Mais qui décide d’étendre le stockage ? Qui valide le coût ? Qui contrôle que l’application fonctionne après l’opération ? La réponse dépend du partage des rôles convenu.

Transformez chaque prestation en consigne exploitable. Pour la supervision, indiquez les événements surveillés, le destinataire des alertes et l’action déclenchée. Pour les sauvegardes, précisez les volumes concernés, la conservation, la surveillance des échecs et la personne autorisée à demander une restauration. Un rapport de réussite technique ne remplace pas la vérification d’un fichier ou d’une application restaurée.

L’administration des accès mérite une ligne distincte : création des comptes, attribution des droits, revue périodique et retrait lors d’un départ. Privilégiez des accès nominatifs, des privilèges adaptés aux opérations et une traçabilité consultable. Le guide ANSSI sur les risques de l’externalisation rappelle notamment les enjeux de perte de maîtrise et d’intervention à distance. Ses principes de cadrage complètent la description technique de la prestation.

Qui valide les correctifs sur un serveur métier ?

Imaginons un serveur qui héberge un logiciel de gestion. Le prestataire identifie un correctif de sécurité du système et prépare son déploiement. L’éditeur confirme la compatibilité avec son application. Le responsable informatique de l’entreprise autorise la fenêtre de maintenance en tenant compte de l’activité. Le prestataire applique le correctif, documente l’intervention et vérifie le redémarrage des services.

Cette répartition limite les risques d’une mise à jour techniquement correcte, mais incompatible avec les usages métiers.

Avant l’intervention, consignez la version visée, les prérequis et le moyen de revenir à un état acceptable si la validation échoue. Après l’intervention, demandez au métier de tester une opération représentative, comme l’ouverture d’un dossier ou l’édition d’un document. Le simple redémarrage du serveur ne prouve pas que le logiciel rend correctement son service.

Qui exécute, qui valide et qui contrôle chaque tâche ?

Attribuez un exécutant, un valideur et une preuve à chaque opération. Une matrice simple permet de formaliser les responsabilités :

Cette matrice est un exemple à adapter, pas une répartition universelle. Pour chaque ligne, ajoutez un responsable final, une procédure d’escalade et une preuve attendue : ticket, rapport, test ou compte rendu.

Prenons un exemple fictif : une alerte signale que le disque du serveur de fichiers approche du seuil défini. Le prestataire ouvre un ticket et qualifie la cause. Le responsable interne décide si les données doivent être archivées ou si la capacité doit augmenter. Le prestataire réalise ensuite l’action autorisée et joint la mesure obtenue. La responsabilité devient vérifiable à chaque étape.

La matrice doit aussi couvrir l’absence du valideur. Désignez un suppléant et déterminez les actions conservatoires autorisées en urgence. Sans cette règle, une équipe peut détecter un problème et disposer des compétences pour agir tout en restant bloquée par une autorisation manquante. Révisez la matrice à chaque ajout d’application ou changement d’intervenant.

Comment préparer la reprise de vos serveurs ?

Préparez un dossier technique et faites valider la reprise par les utilisateurs concernés. La transition vers un nouveau prestataire commence par un inventaire fiable : versions des systèmes, machines virtuelles, dépendances réseau, certificats, comptes techniques, applications, sauvegardes et contrats associés. Les accès d’administration doivent être transférés par des moyens sécurisés, puis revus après la reprise.

Prévoyez également une période de vérification. Le prestataire doit pouvoir confirmer que les alertes remontent, que les sauvegardes prévues s’exécutent et que les procédures de restauration sont documentées. Un test de reprise ciblé permet de détecter les informations manquantes avant qu’un incident ne survienne.

La stratégie de sauvegarde cloud peut compléter cette préparation lorsque le périmètre le justifie.

Comment accepter la reprise sans laisser de zone grise ?

Ajoutez une fiche d’acceptation par service critique. Elle réunit la liste des serveurs couverts, les dépendances confirmées, les accès disponibles et les écarts encore ouverts. Pour chaque réserve, indiquez qui la corrige, à quelle date et quelle mesure provisoire protège l’activité. Évitez une validation globale qui ferait disparaître les exceptions dans un compte rendu général.

Prenons le cas fictif d’un serveur de gestion dont la supervision fonctionne, mais dont la restauration applicative reste à tester. La reprise de la surveillance et l’acceptation de la capacité de restauration sont deux décisions différentes. Consignez-les séparément. Cette précision permet de déléguer une partie opérationnelle tout en gardant un plan de traitement visible pour le risque restant.

Organisez une recette de transition avec des critères observables : inventaire accepté, accès vérifiés, destinataires d’alerte confirmés et documentation disponible. Choisissez un serveur représentatif et parcourez ensemble un incident simulé, depuis son signalement jusqu’à la clôture du ticket. Il s’agit d’un exercice de procédure, sans provoquer de panne de production.

Si le prestataire découvre une sauvegarde absente ou une version non maintenue, faites inscrire l’écart dans un registre avec son responsable et son échéance. La reprise opérationnelle peut être conditionnée au traitement des points critiques. Cette étape évite que les lacunes historiques restent implicites ou soient découvertes uniquement lors du premier incident réel.

Quels livrables demander pour garder la maîtrise ?

Demandez des documents qui permettent de comprendre l’état du parc et de reprendre son exploitation. Une infogérance efficace ne se résume pas à des interventions invisibles. L’entreprise doit recevoir un inventaire à jour, un journal des changements, un état des correctifs, des rapports d’incidents et une documentation exploitable par un tiers. Les modalités de restitution en fin de contrat doivent être définies dès le départ.

Lors d’une revue périodique, rapprochez les rapports des décisions prises : correctifs reportés, incidents répétés, capacités à augmenter et tests à programmer. Demandez un responsable et une date pour chaque action ouverte. Un tableau de bord utile explique les écarts et prépare les arbitrages ; il ne se limite pas au nombre de tickets fermés.

Préparez également la sortie du contrat : formats de restitution, transfert des procédures, devenir des outils de supervision et retrait des accès de l’ancien intervenant. La documentation doit rester compréhensible par une autre équipe. Les niveaux de disponibilité et de réactivité relèvent, eux, des SLA : ils complètent la matrice des responsabilités sans s’y substituer.

Conservez enfin un accès aux informations nécessaires pour contrôler la prestation : liste des machines couvertes, historique des changements et état des demandes en cours. Précisez la fréquence de leur actualisation et leur emplacement de stockage. Si ces documents n’existent que dans un outil du prestataire, demandez comment les exporter. La maîtrise repose autant sur la disponibilité de ces éléments que sur leur qualité. Une revue menée avec le responsable métier aide à vérifier que l’inventaire technique correspond toujours aux services réellement utilisés.

Comment décider ce que vous pouvez déléguer ?

Déléguez en priorité les tâches documentées dont l’exécution peut être contrôlée, tout en conservant un responsable interne capable de décider. Avant de signer, vérifiez l’inventaire, la matrice des rôles et les livrables de reprise. Pour cadrer votre projet, échangez avec les équipes Konica Minolta sur votre environnement et vos besoins d’exploitation.

Pour définir ce périmètre, découvrez le centre de services IT Konica Minolta et présentez votre inventaire ainsi que vos trois opérations les plus critiques. Demandez une proposition précisant les tâches couvertes, les validations et les livrables attendus.