Article sourcé

Préparer la passation d’un outil numérique à un nouveau responsable

Une méthode à outil constant pour transmettre le travail, distinguer décision et administration, tester la reprise et terminer les accès devenus inutiles sans partager de secrets.

Changer de responsable sans changer d’outil

Un outil peut continuer à fonctionner alors que sa responsabilité change : départ, nouvelle mission, remplacement ou passage d’un prestataire à une équipe interne. Les données restent au même endroit, mais les décisions, les alertes et les contacts doivent être repris. Une passation réussie ne se résume donc pas à créer un compte pour la personne suivante.

Ce dossier décrit ce changement à outil constant. Il complète les guides sur la gouvernance des accès et la migration vers un autre logiciel. Son exemple est fictif : une association utilise un outil pour suivre les demandes de mise à disposition de matériel. La responsable sortante transmet le suivi quotidien à un successeur ; le bureau conserve les décisions d’engagement et un prestataire garde une mission technique bornée.

Écrire ce qui est transmis et qui accepte la reprise

Définissez la date de changement, la période de préparation et les activités concernées. Le successeur reprend-il le traitement des demandes, la qualité des données, la relation fournisseur ou l’administration ? Une même personne peut cumuler plusieurs rôles, mais chacun doit être nommé avec son périmètre et son décideur.

Dans notre exemple, le successeur peut préparer une réponse et suivre une restitution. Il ne valide pas une dépense exceptionnelle ni une modification du contrat fournisseur. Le bureau désigne qui tranche ces questions. Le prestataire configure l’outil dans le cadre autorisé ; cette possibilité technique ne lui donne pas le droit de décider des usages de l’association.

La CNIL recommande d’adapter les habilitations aux besoins et de traiter les changements d’affectation. La passation applique ce principe en liant chaque accès au travail effectivement repris. Une désignation informelle ne remplace pas les procédures du fournisseur lorsqu’un propriétaire contractuel ou un administrateur principal doit changer.

Exemple fictif de passation dans une association
ResponsabilitéPersonne ou rôle désignéLimite à conserver
Suivi quotidien des demandesNouveau responsable métierNe valide pas les dépenses exceptionnelles
Engagement contractuelBureau ou représentant habilitéNe se déduit pas du rôle administrateur
Configuration de l’outilAdministrateur ou prestataire autoriséMission technique bornée
Fin des anciens droitsExécutant désigné et contrôleurRésultat et réserves documentés

Préparer un dossier opératoire qui ne contient aucun secret

Rassemblez les informations qui permettent d’agir : finalité de l’outil, objets suivis, source qui fait foi, tâches courantes, échéances, anomalies ouvertes et contacts compétents. Indiquez où trouver la documentation et comment demander un accès autorisé. Le dossier ne contient ni mot de passe, ni code de secours, ni clé technique, ni copie complète des données personnelles.

Une procédure décrit un déclencheur, une action autorisée, le résultat attendu et le cas où il faut arrêter puis demander une décision. « Traiter les demandes le matin » est insuffisant. « Vérifier les nouvelles demandes, repérer une pièce manquante et préparer une réponse sans confirmer un matériel encore indisponible » fournit un scénario compréhensible.

Séparez les conventions locales des fonctions du logiciel. Un statut peut signifier « préparation terminée » dans l’équipe sans constituer un accord du bureau. Décrivez cette distinction pour que le nouveau responsable ne prenne pas une couleur ou une case cochée pour une autorisation.

Rendre visibles les dossiers ouverts et les dépendances

Listez les sujets qui traversent la date de passation : demande en attente, retour de matériel, réponse fournisseur, incident technique ou contrôle de données. Pour chacun, donnez un état vérifié, le prochain geste, le responsable et la référence de preuve. Le successeur ne devrait pas devoir parcourir toute une messagerie pour retrouver pourquoi une demande est bloquée.

Ajoutez les dépendances concrètes : boîte de réception suivie, calendrier, formulaire, notification, export périodique et système qui les exécute. Notez le responsable connu sans recopier ses secrets. Un compte technique peut continuer à lancer une tâche après le départ de son ancien gestionnaire ; son bon fonctionnement ne prouve pas que sa responsabilité et ses alertes ont été reprises.

Conservez les incertitudes explicites. Si personne ne sait qui reçoit un message d’erreur, attribuez la vérification à une personne et indiquez sa prochaine action. Écrire « automatisation opérationnelle » sans destinataire d’alerte ferait disparaître le problème au moment même où il faut le transmettre.

Attribuer les accès par les mécanismes prévus

Le successeur utilise son propre compte et les habilitations validées pour son rôle. Les changements sensibles suivent les fonctions officielles du service : invitation, rôle, transfert prévu ou demande au support. Si le fournisseur ne propose pas un mécanisme adapté, clarifiez sa procédure avant de modifier une identité existante.

Ne renommez pas simplement le compte personnel du sortant en compte du successeur. Cela peut mélanger historique, moyens de récupération et responsabilité. Vérifiez séparément l’adresse de contact de l’organisation, les administrateurs, les canaux de récupération et les éventuelles autorisations du prestataire, selon les capacités réelles du service.

Le guide d’hygiène de l’ANSSI propose un cadre de mesures de sécurité pour les organisations. Il constitue une référence générale, pas une procédure universelle de transfert de compte. Ici, le résultat attendu est un accès nominatif suffisant et une responsabilité identifiable, sans diffuser des identifiants par commodité.

Faire réaliser un scénario par le successeur

Choisissez une opération représentative à faible impact, dans un environnement de test ou avec des données fictives lorsque cette possibilité existe. Le successeur suit le dossier opératoire et explique ce qu’il fait. Le sortant observe sans fournir immédiatement toutes les réponses : le but est de révéler les informations implicites manquantes.

Dans l’exemple, une demande fictive de prêt comporte une date et un matériel. Le successeur retrouve la source de disponibilité, identifie une information absente, prépare une réponse et sait vers qui orienter une décision hors de son rôle. Il ne confirme aucun prêt réel et ne déclenche aucun paiement pour démontrer qu’il sait utiliser l’outil.

Testez aussi une limite prévue : le successeur doit savoir qu’il ne peut pas autoriser une dépense et quel canal solliciter. Les vérifications techniques de refus sont réalisées par les personnes habilitées dans le cadre convenu ; la passation ne donne pas une autorisation générale de tester des données ou des comptes tiers.

Recette fictive de reprise, sans données réelles
ScénarioRésultat attenduPreuve minimale
Demande incomplèteInformation manquante identifiéeRéférence fictive et action proposée
Disponibilité incertaineAucune confirmation prématuréeSource retrouvée ou réserve ouverte
Décision hors périmètreOrientation vers le décideurRôle et canal connus
Alerte techniqueDestinataire responsable identifiéProcédure et contact vérifiés

Vérifier la continuité sans confondre export et restauration

Retrouvez la procédure de sauvegarde ou d’export effectivement utilisée, son responsable et la dernière preuve utile. Une archive présente dans un dossier ne démontre pas qu’elle peut être relue. Cybermalveillance.gouv.fr recommande de protéger les sauvegardes et d’en vérifier le fonctionnement ; l’essai doit respecter les possibilités et les risques du système.

Pour la passation, le successeur doit savoir où se trouve la procédure, qui peut l’exécuter et comment demander une reprise. Un exercice sur une copie isolée peut vérifier un point précis sans écraser l’état de production. Le guide dédié à la sauvegarde détaille cette démarche ; il n’est pas nécessaire de simuler une panne réelle lors du changement de responsable.

Si une donnée locale reste chiffrée, un profil ou un nouveau compte ne constitue pas sa clé de déchiffrement. Identifiez cette dépendance sans copier le secret dans le dossier de passation. N’annoncez ni récupération automatique ni accès universel aux données parce que le successeur peut ouvrir le portail.

Planifier la révocation selon les responsabilités qui cessent

Attribuez une date et un exécutant au retrait des anciens droits. Les accès nominatifs devenus inutiles sont retirés lorsque la mission correspondante cesse ; la CNIL recommande de ne pas conserver des permissions sans besoin. Le retrait ne doit pas être remplacé par une consigne orale de ne plus utiliser le compte.

Distinguez compte personnel, session ouverte, invitation, accès de groupe et dépendance technique. Si une automatisation repose encore sur un moyen d’accès du sortant, préparez son remplacement officiel avec le responsable compétent. Une difficulté de continuité doit être traitée comme un écart attribué, sans devenir une justification indéfinie pour laisser un compte personnel actif.

Vérifiez le résultat attendu selon les capacités du service : nouveaux droits utilisables, anciens droits retirés et absence de dépendance oubliée. Une case « compte supprimé » ne suffit pas à prouver la fin de toutes les autorisations. Le dossier conserve le périmètre vérifié et les limites de preuve.

Conserver un compte rendu utile et une suite aux réserves

Le compte rendu indique la date, les responsables, le périmètre repris, le scénario exécuté et les points encore ouverts. Une réserve reçoit une prochaine action et un responsable. La passation peut être acceptée pour un périmètre précis sans prétendre que toutes les difficultés anciennes de l’outil sont résolues.

La CNIL recommande de tracer certaines opérations sans recopier excessivement les données ni enregistrer les secrets. Appliqué au compte rendu de passation, cela invite à référencer la preuve plutôt qu’à joindre des copies générales de journaux ou des captures révélant les dossiers réels. Le compte rendu n’est pas un dispositif de surveillance du successeur.

Conservez les traces nécessaires selon leur finalité et le cadre applicable ; la date de passation ne fixe pas à elle seule une durée pour tous les documents. Préparez une revue après la première échéance réellement reprise : réponse fournisseur, suivi de demande ou opération périodique. Ce point vérifie les réserves, plutôt que de rejouer tout l’exercice sans changement.

Ce que DOHM explique et ce que chaque outil doit prouver

DOHM fournit des ressources de méthode. Cette page ne lui attribue pas un service de transfert de propriété, un coffre commun, un accès administrateur transversal ou une révocation centralisée de toutes les applications. Chaque produit conserve son périmètre de données, ses comptes et ses fonctions réellement disponibles.

Une connexion ou un profil My DOHM n’équivaut pas à la reprise de tous les droits natifs ni au déverrouillage d’un coffre local. Consultez les preuves et les procédures propres à l’outil concerné. Le dossier de passation décrit les mécanismes vérifiés et les points à confirmer, sans transformer une intention de gouvernance en fonction logicielle.

Les sources ont été consultées le 11 octobre 2026. Cette méthode générale ne remplace pas l’administrateur compétent, les conditions fournisseur ou une expertise adaptée à un système critique. Elle est aboutie lorsque le nouveau responsable peut poursuivre le travail prévu, orienter une exception et retrouver les preuves, tandis que les droits devenus inutiles ont été traités et les réserves restent visibles.

Sources

Éditeur : Rédaction DOHM · informations revues le . Signaler une correction.