Départ d’un collaborateur : transmettre ses automatisations
Une personne quitte l’entreprise. Elle a documenté les tâches, partagé les dossiers et transmis ses contacts. Mais qui a repris les connexions qui permettent aux automatisations de fonctionner ? Une équipe peut disposer du scénario sans avoir remplacé le compte utilisé pour lire les données ou envoyer les messages.
Microsoft documente ce cas dans Power Automate : un flux sans propriétaire valide peut échouer lorsqu’il utilise des connexions liées au compte de la personne partie. Gestion des flux orphelins, Microsoft Learn.
La passation mérite donc un essai concret : une autre personne doit pouvoir comprendre le processus, le faire fonctionner avec les accès prévus et intervenir en cas de problème. Voici comment préparer ce relais, également utile lorsqu’une mission de prestataire se termine.
Partir d’un processus dont l’équipe dépend
Prenons une PME fictive qui organise des formations. Chaque semaine, une automatisation consulte les sessions confirmées, prépare les convocations dans un dossier documentaire et les envoie aux participants. Sa créatrice va quitter l’entreprise. Cette organisation et tous les exemples qui suivent sont inventés.
Le responsable de formation décrit d’abord ce qui doit continuer : chaque session confirmée doit disposer de ses documents, les destinataires doivent être corrects et l’équipe doit retrouver la trace des envois. Il précise aussi comment préparer les convocations manuellement pendant une interruption.
Avec la personne qui maintient le scénario, il identifie ensuite le déclencheur, les applications traversées, les fichiers utilisés et les notifications reçues. Le parcours inclut les modèles de documents, les dossiers de destination et les éventuelles validations humaines.
Cette revue prolonge les critères de maintenance évoqués dans notre comparatif n8n, Make et Zapier. L’objectif est ici de vérifier une transmission précise sur l’outil déjà en place.
Distinguer le scénario de ses connexions
Le propriétaire du scénario peut en modifier la logique. Une connexion, elle, autorise une application à agir avec une identité et des permissions données. Ces deux responsabilités doivent être examinées séparément.
Dans Power Automate, un propriétaire peut utiliser les connexions présentes dans un flux sans pouvoir modifier les identifiants d’une connexion créée par un autre propriétaire. Microsoft demande de mettre à jour les connexions concernées lorsqu’on retire un propriétaire dont les identifiants sont utilisés. Partage des flux et modification des connexions, Microsoft Learn.
Pour notre entreprise fictive, ajouter le successeur au scénario ne prouve donc pas que les convocations partiront avec les accès retenus après le départ. Il faut examiner chaque étape : avec quel compte consulte-t-elle les sessions, produit-elle le document et envoie-t-elle le message ?
Préparez une fiche de passation qui sépare ces éléments :
Élément à transmettre | Information à conserver |
|---|---|
Responsabilité métier | Personne qui valide le résultat attendu et arbitre les exceptions. |
Administration du scénario | Emplacement, propriétaire, personne capable de le modifier et relais. |
Connexions aux applications | Compte utilisé, permissions nécessaires et responsable de leur renouvellement. |
Ressources et suivi | Modèles, dossiers, destinataires des alertes et accès à l’historique. |
La fiche contient des références vers les accès gérés dans les outils ou le coffre prévu par l’entreprise. Elle ne doit pas devenir une copie des mots de passe ou des clés secrètes.
Choisir des accès que l’entreprise saura maintenir
Pour chaque connexion personnelle, décidez avec l’administrateur comment assurer la suite. Selon le service, cela peut demander une nouvelle autorisation par une personne habilitée ou une identité dédiée à l’application. Vérifiez les possibilités réelles du connecteur avant de choisir.
Power Automate permet par exemple à un utilisateur applicatif représentant un « principal de service », une identité non humaine, de posséder et d’exécuter des flux. Microsoft précise que ce fonctionnement comporte des conditions de licence et des limites propres. Il nécessite une configuration adaptée. Flux détenus par un principal de service, Microsoft Learn.
Pour notre PME fictive, la décision doit préciser qui administre l’identité retenue, qui renouvelle ses accès et quels dossiers elle peut consulter. Une adresse générique ne répond pas, à elle seule, à ces questions.
Vérifiez aussi les ressources utilisées : le nouveau compte peut-il ouvrir le modèle de convocation, écrire dans le dossier prévu et utiliser l’expéditeur choisi ? Conservez uniquement les permissions nécessaires au processus. Confiez les changements à une personne habilitée, sans demander au collaborateur de transmettre son compte personnel.
Préparer le transfert selon la plateforme
Les modalités de transfert diffèrent selon les outils et le type de scénario. Dans Power Automate, le changement direct de propriétaire concerne les flux intégrés à une « solution », un regroupement de composants. Pour les autres flux, Microsoft décrit l’ajout à une solution lorsque l’environnement le permet, ou la création d’un nouveau flux. Les licences du nouveau propriétaire doivent également être vérifiées. Changer le propriétaire d’un flux, Microsoft Learn.
Dans n8n, déplacer un workflow ou des identifiants entre projets modifie les partages existants. La documentation avertit que le workflow peut cesser de fonctionner si les identifiants nécessaires ne sont pas disponibles dans le projet cible. Organisation et déplacement entre projets, n8n.
Avant l’opération, notez donc ce qui sera déplacé, recréé ou réautorisé. Repérez les autres scénarios utilisant une connexion commune : sa modification peut dépasser le processus choisi pour la passation.
Si une copie du scénario est nécessaire, préparez son activation et l’arrêt de l’ancien. Dans notre exemple, deux scénarios actifs pourraient envoyer deux convocations. Définissez aussi le traitement des sessions déjà en cours pour éviter de reprendre arbitrairement tous les dossiers.
Faire réaliser un essai par le successeur
Organisez un test avec des données fictives, des destinataires contrôlés et un périmètre convenu. Le successeur utilise ses propres accès autorisés, sans reprendre la session ouverte de son collègue.
Dans notre exemple, il crée une session de formation de test, lance le parcours prévu et vérifie le document produit. Il contrôle l’expéditeur, le destinataire, le contenu et l’emplacement du fichier. Il doit ensuite retrouver l’exécution dans l’historique et expliquer ce qui s’est passé.
Testez également le déclenchement programmé : un lancement manuel réussi ne démontre pas que la prochaine échéance sera exécutée. Faites arriver une alerte de test au nouveau responsable et vérifiez qu’il peut ouvrir le détail associé.
Consignez la date, les comptes utilisés, le résultat et les points à corriger. Si la reprise suppose de déplacer des données, notre article sur les exports avant une migration d’outil métier aide à compléter les vérifications documentaires.
Clore les anciens accès et confirmer la reprise
Coordonnez la passation avec la procédure de départ. La date de retrait des accès doit être connue des personnes qui préparent le relais. Si celui-ci n’est pas prêt, prévoyez la suspension du scénario ou le traitement manuel convenu ; conserver indéfiniment le compte du collaborateur ne constitue pas une solution de reprise.
Google recommande notamment de revoir et révoquer les autorisations accordées aux applications lors d’un départ. Sa documentation précise qu’un changement de mot de passe ne révoque les jetons OAuth que pour certains produits. Ces jetons permettent aux applications d’accéder au compte. Sécurité des données après un départ, Google Workspace.
Après le retrait des anciens accès, contrôlez à nouveau le parcours et la prochaine exécution prévue. Dans notre PME fictive, le responsable vérifie les convocations attendues et leur historique. Tout écart reste attribué à une personne, avec une action de reprise identifiée.
La passation peut être close lorsque l’équipe sait exploiter le processus avec les accès restants, retrouver sa documentation et joindre le bon interlocuteur. Gardez cette fiche à jour lors des changements de connexion ou de prestataire.
Chez Studio UNIQ, nous pouvons vous aider à cartographier ces dépendances et à préparer un premier test de transmission. Parlons des automatisations dont votre équipe dépend.