Le Blog du DSI
Équipe

Départ d'un administrateur : organiser la passation

Préparer le départ d'un administrateur système : choisir les savoir-faire à transmettre, tester la reprise et rendre visibles les tâches encore sans relais.

Personne prenant des notes à côté d'un ordinateur portable
Photo Unsplash
À retenir

La passation d'un administrateur système se prépare autour des tâches que l'équipe devra assurer après son départ. Pour chaque activité critique, désigner un repreneur, transmettre le contexte et vérifier une exécution encadrée. Les opérations encore non maîtrisées doivent faire l'objet d'un arbitrage explicite : renfort, report ou restriction temporaire du service. La documentation seule ne prouve pas l'autonomie.

Un administrateur annonce son départ. Le recrutement démarre, le calendrier se remplit de réunions de transfert et chacun promet de compléter la documentation. Puis arrive la dernière semaine : les dossiers sont accessibles, mais personne ne sait expliquer comment reprendre le traitement qui bloque la facturation.

Je traite cette situation comme un transfert de travail à des personnes identifiées. Le point de départ est simple : que devra faire l’équipe après le départ, et qui saura effectivement le faire ? Une liste de serveurs ne répond pas à cette question.

Choisir les activités qui doivent avoir un relais

Je commence avec le collaborateur concerné et ceux qui reprendront ses activités. Nous partons du travail réel : interventions récentes, opérations périodiques, demandes qui reviennent directement vers lui. L’inventaire technique aide à vérifier les oublis, mais il ne donne pas l’ordre des priorités.

Prenons un exemple fictif : un administrateur entretient la messagerie, prépare un export comptable et intervient sur une liaison entre deux sites. Le service le plus connu n’est pas forcément le plus exposé. Si plusieurs collègues maîtrisent la messagerie mais qu’aucun ne connaît les contrôles de l’export, la passation commence par celui-ci.

Pour chaque activité, je demande ce qui se passe si elle n’est pas réalisée, quand elle doit l’être à nouveau et qui peut déjà la prendre en charge. J’ajoute les opérations rares : un renouvellement, une clôture ou un changement de configuration peuvent tomber après le départ sans apparaître dans les tickets récents.

Cette sélection implique de laisser certains sujets de côté. Je préfère écrire qu’une activité secondaire reste sans relais plutôt que déclarer tout le périmètre transmis après une présentation générale. Le périmètre retenu doit tenir dans le temps réellement disponible des participants.

Réserver du temps aux personnes qui reprennent

Une passation échoue aussi quand le collaborateur sortant est disponible, mais que ses collègues restent absorbés par le support. Je bloque donc les créneaux des deux côtés et je précise quelles tâches courantes seront décalées ou redistribuées. Sans cet arbitrage, la transmission devient le travail que chacun doit faire entre deux urgences.

Le repreneur n’est pas nécessairement le futur titulaire du poste. Si le recrutement n’est pas terminé, une personne de l’équipe peut assurer une activité limitée, et un prestataire une autre. Il faut vérifier leur capacité à reprendre avant d’inscrire leur nom. Être volontaire ne suffit pas à maîtriser un environnement.

Je demande également au collaborateur sortant de signaler les sujets qu’il ne maîtrise que partiellement. Il doit pouvoir dire qu’une opération fonctionne sans qu’il en comprenne toutes les dépendances. Transformer la passation en examen de sa valeur professionnelle encourage les réponses rassurantes et masque précisément ce que nous cherchons.

Le recrutement reste un chantier distinct, avec ses propres délais. Les choix décrits dans l’article sur le recrutement en DSI d’ETI peuvent aider à préparer le poste. La continuité immédiate exige, elle, des personnes déjà mobilisables.

Transmettre le raisonnement derrière les gestes

Une procédure utile explique le résultat attendu, les prérequis, les étapes et la manière de constater un échec. AWS recommande également de préciser les permissions nécessaires et les conditions d’escalade dans ses consignes de rédaction des procédures d’exploitation. Cette trame peut servir hors du cloud.

Mais je demande aussi ce que la procédure ne raconte pas : pourquoi l’opération se fait dans cet ordre, quelle particularité locale impose une vérification, quel symptôme doit faire interrompre l’intervention. C’est là que se transmet une partie du jugement professionnel.

Le tableau suivant sert de guide de discussion. Les exemples sont illustratifs et doivent être remplacés par les activités du service.

Élément à transmettreTrace insuffisanteInformation exploitable
Traitement périodiqueNom du scriptDéclencheur, données attendues et contrôle du résultat
Dépendance métierNom de l’applicationActivité bloquée et interlocuteur qui confirme la reprise
Intervention inhabituelleCapture de la consoleConditions d’emploi, risque et point d’arrêt
Recours au fournisseurAdresse commercialeCanal de support vérifié et références du service concerné

Je conserve les explications près de la procédure concernée. Une longue vidéo de transfert peut aider à retrouver un contexte, mais elle se parcourt mal pendant une intervention. Elle ne dispense pas d’écrire les décisions et les étapes indispensables. Les secrets restent dans leur dispositif de stockage prévu, avec une référence dans la fiche.

Faire réaliser les tâches par le repreneur

La séance commence éventuellement par une démonstration. Elle doit ensuite changer de sens : le repreneur agit et explique son raisonnement, tandis que le sortant observe. Si ce dernier reprend constamment la main, je note les points qui nécessitent encore un apprentissage.

Une passation est vérifiée quand le repreneur sait agir, contrôler le résultat et reconnaître le moment où il doit s’arrêter.

Le chapitre de Google consacré à l’apprentissage des ingénieurs d’exploitation propose de combiner compréhension du système et exercices pratiques. J’en retiens une exigence adaptée à une petite équipe : demander au collègue d’expliquer ce qu’il observe, au lieu de vérifier seulement qu’il retrouve les boutons.

L’exercice utilise ses propres accès autorisés et un périmètre maîtrisé. Une opération risquée se prépare sur un environnement adapté ou se déroule lors d’une intervention encadrée. Si aucune exécution réaliste n’est possible, une simulation commentée reste utile, mais je la consigne comme telle. Elle ne démontre pas la même chose.

Je garde une trace courte : activité réalisée, résultat, aide nécessaire et point restant à travailler. Un blocage révèle parfois un droit manquant ou une explication ambiguë. Il ne prouve pas automatiquement un défaut de compétence. Le responsable de la passation doit distinguer ces causes avant de conclure.

Rendre visibles les tâches encore sans couverture

À l’approche du départ, le DSI doit pouvoir lire un état de reprise sans ouvrir tous les comptes rendus. Pour chaque activité prioritaire, je retiens un statut compréhensible : réalisée par le repreneur, encore accompagnée, ou sans solution confirmée. J’y associe la prochaine échéance et la décision attendue.

Si une opération indispensable reste sans couverture, les options doivent être concrètes. Un renfort confirmé peut la prendre en charge. Une intervention non urgente peut être reportée. Un service peut fonctionner temporairement avec un périmètre réduit, après accord de son responsable métier. Écrire simplement que l’équipe fera au mieux ne permet aucun arbitrage.

Il faut aussi examiner les limites du prestataire pressenti. Un contrat de support ne signifie pas qu’il connaît vos scripts locaux ni qu’il peut intervenir au créneau souhaité. Je fais préciser le périmètre repris et les informations encore nécessaires avant de le considérer comme une solution.

Le numéro personnel du salarié parti ne figure pas dans ce dispositif. Une disponibilité éventuelle doit être organisée explicitement, sans servir d’hypothèse au fonctionnement courant. Sinon, le risque reste entier et la charge devient invisible pour la direction comme pour l’équipe.

Entretenir la reprise après le départ

Je garde le suivi ouvert jusqu’au passage des premières échéances significatives. Une activité mensuelle non encore rencontrée reste à vérifier, même si les gestes quotidiens sont maîtrisés. Le responsable provisoire conserve la liste des inconnues et fait corriger les fiches au moment où elles servent.

La recommandation AWS sur la gestion des connaissances opérationnelles insiste sur l’information accessible, actualisée et archivable. Dans ce contexte, j’associe chaque fiche à une personne chargée de son maintien. Sans cette responsabilité, le dossier de départ devient rapidement une photographie ancienne du service.

Dès la semaine prochaine, le DSI peut ouvrir la liste des activités, réunir le sortant et les repreneurs, puis réserver le premier exercice sur le sujet le plus exposé. Il doit aussi demander quelle charge retirer pour permettre ce travail. La réponse conditionne la crédibilité du planning.

Enfin, je fixe avec l’équipe une date de revue après la prochaine opération importante. Nous y examinons ce qui a été exécuté sans aide, les corrections apportées et les responsabilités encore provisoires. C’est à partir de ces éléments que le DSI peut clore la passation ou maintenir un accompagnement ciblé.

Questions fréquentes

Que faut-il transmettre en priorité avant le départ d'un administrateur ?

Prioriser les activités dont l'interruption bloquerait un service et celles qu'aucun autre membre de l'équipe ne sait assurer. Inclure les opérations rares déjà inscrites au calendrier, les dépendances connues et les contacts utiles. Chaque activité doit avoir un repreneur identifié et une vérification prévue, même si toute la documentation ne peut pas être achevée avant le départ.

Comment vérifier que la passation est réellement terminée ?

Faire réaliser au repreneur une tâche représentative avec ses propres accès autorisés et la documentation disponible, sous observation. Vérifier aussi qu'il sait contrôler le résultat et reconnaître une situation où il doit s'arrêter. Les opérations non testées et les aides encore nécessaires restent consignées pour que le DSI décide de la couverture à organiser.

Comment organiser la passation si le remplaçant n'est pas encore recruté ?

Désigner un responsable provisoire pour chaque activité indispensable, dans l'équipe ou chez un prestataire dont la disponibilité a été confirmée. Ce responsable doit disposer du temps et des compétences nécessaires. Lorsque cette reprise est impossible, le DSI doit faire arbitrer un renfort ou une limitation temporaire du service, sans supposer que le salarié parti restera disponible.