Access Automation — Google Lifecycle est un modèle de projet OpenTechnologyApp pour le problème d'arrivée/mutation/départ que connaît toute équipe IT : une nouvelle recrue a besoin d'un compte, de groupes et d'un message de bienvenue dès le premier jour ; un départ nécessite que ce même accès soit retiré, vérifié et transmis — à une échéance précise, pas « un de ces jours ». Quatre files, cinq playbooks, et des automatisations qui transforment un changement de champ en le travail qu'il implique réellement.
Ce qui est suivi
Chaque arrivée ou départ commence comme un dossier de cycle de vie, et un champ — Workflow State — pilote tout ce qui suit : Intake → Ready — Onboarding (ou Ready — Offboarding) → In Progress → Complete. Faire passer un dossier à « Ready » est le déclencheur ; tout ce qui vient après est généré, pas retenu de mémoire.
Quatre files, un seul cycle de vie
| File | Ce qui s'y trouve |
|---|---|
| Onboarding | Un dossier de cycle de vie par nouvelle recrue — informations sur l'employé et le manager, unité organisationnelle cible, groupes cibles, date d'effet |
| Offboarding | Un dossier de cycle de vie par départ — même structure, priorité élevée par défaut |
| IT Tickets | Le travail d'accès interne généré par chaque dossier de cycle de vie, suivi et clos indépendamment du dossier qui l'a créé |
| New-Hire + Manager Communications | Messages de bienvenue, vérifications de préparation du premier jour, avis de départ et transmissions au manager — sous forme d'élément suivi, ou d'e-mail réel |
Des automatisations qui génèrent le travail, pas seulement des rappels
Faire passer le Workflow State d'un dossier à Ready — Onboarding déclenche automatiquement deux choses : une tâche d'intégration Google apparaît dans la file Onboarding, pré-remplie avec l'unité organisationnelle et les groupes cibles du dossier parent, et un ticket IT apparaît dans IT Tickets pour le travail d'accès interne. Le départ fonctionne de la même façon, en sens inverse — priorité urgente par défaut, car un départ avec échéance est un type d'urgence différent d'une nouvelle recrue qui n'a pas encore commencé.
Une cinquième automatisation — l'envoi d'un e-mail de préparation au manager dès qu'un élément de communication passe à « Ready » — est désactivée par défaut, la même discipline que celle du modèle jumeau d'audit des appareils : vérifier d'abord le flux avec des éléments suivis, activer l'e-mail seulement une fois qu'on lui fait confiance.
Cinq playbooks, un par type de travail
- Google onboarding — vérifier l'e-mail, la date de début, l'unité organisationnelle et les groupes de l'employé ; créer ou vérifier l'utilisateur Google ; appliquer l'unité organisationnelle et les groupes cibles ; enregistrer le statut et une note de preuve
- Google offboarding — retirer les appartenances aux groupes ; suspendre l'utilisateur et changer le mot de passe ; effacer l'e-mail et le téléphone de récupération ; déplacer vers l'unité organisationnelle archivée ; enregistrer la décision de transfert Drive ; vérifier l'état final
- IT access ticket — confirmer le dossier de cycle de vie et la date d'effet ; effectuer le travail d'accès demandé ; relier le résultat et clore
- Employee communication — vérifier le destinataire et le modèle ; envoyer ou finaliser la transmission uniquement via l'élément ; enregistrer le résultat de l'envoi
- Manager communication — vérifier le manager et le contexte du cycle de vie ; envoyer ou finaliser la transmission ; enregistrer le résultat et les décisions prises
Ce qui est suivi, pas automatisé — volontairement
C'est la partie honnête, et elle compte plus que n'importe quelle liste de fonctionnalités : les changements de compte Google sont une checklist, pas un appel API. Chaque tâche d'intégration et de départ Google de ce modèle est un playbook manuel — la personne qui effectue le travail ouvre elle-même la console d'administration Google, suit les étapes, puis enregistre ce qui s'est passé sur l'élément. Il n'existe pas encore de connecteur en direct créant ou suspendant des utilisateurs Google en votre nom.
C'est un choix délibéré, pas une fonctionnalité manquante à découvrir. Un outil qui provisionne ou supprime silencieusement des comptes dans votre fournisseur d'identité est exactement le genre de chose qui ne devrait pas être livré discrètement — manuel-jusqu'à-vérification est la même posture que ces automatisations adoptent pour l'e-mail. Si un connecteur Google en direct est livré plus tard, ce sera un ajout autorisé séparément, pas quelque chose que ce modèle fait aujourd'hui.
Une dernière précision de périmètre qui mérite d'être dite clairement : ce modèle est spécifique à Google Workspace, pas un système générique multi-fournisseurs d'identité. Si votre organisation utilise un autre fournisseur d'identité, la structure dossier de cycle de vie / ticket IT s'applique toujours — mais les champs et playbooks spécifiques à Google devraient avoir leurs propres équivalents construits pour votre fournisseur.
Comment l'obtenir
Importez Access Automation — Google Lifecycle depuis le sélecteur de modèles dans OpenTechnologyApp — il est déjà intégré, avec ses quatre files.