Pour retirer les accès d’un employé sans interrompre les automatisations, il faut repérer séparément le propriétaire du traitement, l’identité utilisée par chaque connexion et les droits sur les données. Préparez une relève, testez le résultat métier, puis vérifiez la révocation. Changer un nom dans la fiche du flux ne suffit pas.
Lors d’un départ planifié, préparez cette continuité avant l’heure convenue de retrait des accès. Si cette heure arrive ou qu’un retrait urgent est nécessaire, ne maintenez pas le compte actif pour sauver une automatisation : révoquez selon votre procédure et prévoyez un arrêt contrôlé ou une reprise manuelle autorisée. La continuité du service ne doit pas prolonger un accès qui doit être retiré.
Repérer les dépendances qui ne portent pas le nom du traitement
Dans une PME de services, une demande peut passer du formulaire au CRM, puis alimenter une liste de suivi et un rapport hebdomadaire. Le flux porte le nom de l’entreprise, mais sa connexion peut utiliser le compte de la personne qui l’a créé. Le dossier de sortie peut aussi lui appartenir, et les alertes d’erreur arriver seulement dans sa boîte courriel.
Avant de conclure qu’un départ a causé une panne, consultez l’historique d’exécution, les erreurs de connexion et les journaux d’accès pertinents. Une absence de message ne prouve pas l’absence d’erreur. Vérifiez également le résultat attendu dans le CRM ou le dossier cible. Notre guide sur la réception réelle d’une demande du site explique pourquoi une notification et un enregistrement métier sont deux preuves différentes.
Réunir les accès de gestion et un plan de remplacement
Désignez un responsable du retrait des accès et un responsable de la continuité des traitements. Ils peuvent être la même personne, mais les deux responsabilités doivent être explicites. Il leur faut les droits d’administration autorisés, la liste des outils concernés et un environnement d’essai lorsque la plateforme en offre un.
- Confirmez la date et l’heure de retrait avec les personnes habilitées à décider du départ.
- Préparez un nouveau responsable autorisé et les droits minimaux nécessaires sur les ressources métier.
- Conservez une version récupérable de la configuration et une méthode de reprise documentée.
- Choisissez des données fictives ou autorisées pour les essais; évitez les vrais destinataires externes.
- Vérifiez les licences, connecteurs, capacités et permissions disponibles avant de promettre un transfert.
Le coût peut comprendre le temps d’inventaire, les essais, une licence différente ou la reprise d’un flux. Aucun prix universel ne s’applique. N’utilisez pas le mot de passe de la personne qui part pour faire fonctionner sa relève et ne copiez jamais de jetons ou de secrets dans la fiche de suivi.
Faire une fiche par automatisation
Notez un identifiant, le résultat métier attendu, la fréquence ou l’événement déclencheur, le propriétaire, les copropriétaires, l’identité de chaque connexion, les ressources consultées, les destinataires et le responsable des alertes. Ajoutez la méthode de transfert, le statut de licence, le test prévu et l’action en cas d’échec. Une connexion peut desservir plusieurs flux : relevez cette relation avant de la remplacer.
Voici un inventaire illustratif pour une PME de services professionnels. Il ne décrit aucun client réel.
| Traitement | Dépendance à vérifier | Preuve attendue |
|---|---|---|
| Demande du site vers CRM | Identité de connexion au CRM | Un dossier test créé une seule fois |
| Classement de pièces jointes | Droits sur le dossier cible | Un fichier test lisible par la relève |
| Rapport hebdomadaire | Déclencheur, propriétaire et licence | Un rapport au bon emplacement et à la bonne date |
| Alerte d’échec | Destinataire et responsable de suivi | Une erreur contrôlée visible par l’équipe autorisée |
Un champ inconnu reste « à vérifier ». Le remplacer par « équipe » masque une dépendance au lieu de la résoudre. Conservez les références aux preuves sans y joindre des données personnelles inutiles.
Dans Power Automate, distinguer propriété et connexions
Les règles varient selon le type de flux. Pour un flux cloud qui appartient à une solution, Power Automate permet de changer le propriétaire. Microsoft précise que l’ancien et le nouveau propriétaire deviennent copropriétaires après ce changement : ce transfert ne retire donc pas, à lui seul, l’ancien accès. Pour un flux hors solution, le changement de propriétaire vers un autre utilisateur n’est pas disponible sur place; la documentation prévoit un passage dans une solution lorsque l’environnement le permet, ou une recréation. Vérifiez votre cas dans la procédure officielle de changement de propriétaire.
Contrôlez ensuite chaque connexion. Une connexion fournie par la personne qui part ne devient pas celle de la relève simplement parce que le flux a un autre propriétaire. Microsoft demande d’actualiser les connexions liées au propriétaire retiré pour que le flux continue à fonctionner. Voir la documentation sur le partage et les connexions des flux.
Une identité applicative administrée par l’entreprise peut convenir à certains traitements durables, si les connecteurs et le modèle de licence le permettent. Ce n’est pas un remplacement universel d’un compte utilisateur. Power Automate documente des conditions propres aux flux détenus par un principal de service, notamment pour les usages premium; faites vérifier ces conditions avant le changement. Voir le support des principaux de service. La création d’une nouvelle identité et l’octroi de droits restent des opérations d’administration à faire autoriser.
Tester la relève avant la bascule, quand le départ est planifié
- Choisissez un traitement et consignez son dernier résultat réussi. Définissez ce que signifie « réussi » dans le système métier, pas seulement dans l’outil d’automatisation.
- Appliquez la méthode de transfert documentée, remplacez les connexions concernées et accordez à la relève seulement les droits nécessaires. Vérifiez aussi les ressources sources et destinations.
- Si vous recréez le flux, maîtrisez les déclencheurs : la copie ne doit pas traiter les mêmes demandes en parallèle avec l’original. Définissez le point de bascule et la façon de reprendre les éléments en attente.
- Exécutez un cas fictif réussi et un cas d’erreur contrôlée. Confirmez le résultat, l’absence de doublon et la réception de l’alerte dans une destination interne autorisée.
- Consignez l’identifiant d’exécution, le résultat métier, l’observateur et l’heure. Retirez les copropriétés ou autorisations devenues inutiles selon le plan de retrait.
Un test manuel ne démontre pas qu’un déclencheur planifié fonctionnera. Vérifiez son prochain passage ou utilisez un déclenchement de test prévu par la plateforme, sans laisser une deuxième planification active. Pour des échanges entre systèmes, la méthode d’intégration ERP/CRM aide à cadrer les reprises et la prévention des doublons.
Retirer l’accès et vérifier ce que la révocation couvre
À l’heure convenue, l’administrateur applique la procédure de retrait de l’organisation. Pour Microsoft 365, la documentation distingue notamment blocage de connexion et déconnexion des sessions. Elle signale aussi que certains effets ne sont pas immédiats. Suivez la procédure Microsoft pour empêcher l’accès d’un ancien employé, plutôt que de considérer la simple suppression d’une licence comme une preuve suffisante.
Le contrôle doit aussi tenir compte des applications qui gèrent leurs propres sessions. Microsoft Entra explique les limites de la révocation selon les jetons et les applications; une action dans l’annuaire ne démontre pas que toutes les sessions applicatives sont fermées au même instant. Faites vérifier les applications concernées avec leurs contrôles documentés et leurs journaux. Source : révoquer l’accès dans Microsoft Entra.
Contrôlez séparément les groupes, les partages, les droits sur les ressources et les identifiants d’intégration que la personne gérait. Décidez avec l’administrateur quels secrets doivent être remplacés, sans les exposer dans le journal. Si une automatisation échoue après le retrait, corrigez son identité ou utilisez la reprise approuvée; ne réactivez pas automatiquement l’ancien compte.
Ce que notre contrôle local a réellement vérifié
Le 1er novembre 2026, nous avons exécuté un contrôle de cohérence sur huit fiches d’automatisation entièrement fictives. Une fiche ne présentait aucune anomalie déclarée. Les sept autres signalaient respectivement une connexion de la personne partante, une copropriété résiduelle, une preuve de droits manquante, un transfert sur place non adapté à un flux hors solution, une licence non vérifiée, deux déclencheurs actifs, puis un retrait urgent avec une connexion à remplacer et une preuve d’essai de continuité manquante.
Dans tous les cas, les anomalies de continuité ne reportaient pas le retrait prévu ou urgent. Ce test a vérifié des règles sur des données déclaratives : il n’a créé aucun compte, transféré aucun flux, révoqué aucune session et vérifié aucune licence réelle. Une fiche sans anomalie n’est donc pas une certification de sécurité. Les preuves de plateforme et les essais métier restent nécessaires.
Checklist de clôture
- Chaque traitement critique a un responsable et des dépendances identifiées.
- Propriété, connexions, ressources et alertes ont été examinées séparément.
- La méthode de transfert et les licences ont été vérifiées.
- Les tests réussis et les erreurs contrôlées ont des résultats consignés.
- La révocation a eu lieu selon la procédure et les applications concernées ont été contrôlées.
- Aucun ancien compte n’a été maintenu pour contourner une panne; une reprise autorisée existe.
Pour documenter et fiabiliser les dépendances entre vos outils, notre service d’applications sur mesure et d’intégrations au Québec et au Canada peut partir de vos traitements existants et de leurs critères de vérification.