Une invitation, les bons accès, et une sortie propre
L’arrivée suit une checklist que personne n’a écrite. Le départ, c’est la même checklist, à l’envers, mal faite, des semaines trop tard.
Un développeur arrive un lundi. Le mercredi, il peut travailler, et y arriver a pris à quelqu’un presque une journée : une invitation dans l’organisation GitHub, puis les deux repositories qui comptent, puis les canaux Slack, puis un siège quelque part pour voir les serveurs. Rien n’est difficile. Tout est manuel, et chaque étape est une petite décision prise sous pression par quelqu’un qui voudrait retourner à son propre travail.
Il est toujours plus rapide d’accorder un peu trop que de calculer le minimum exact, alors la nouvelle personne reçoit toute l’organisation plutôt que deux repositories, et personne ne revient jamais restreindre.
Six mois plus tard, elle part, et la checklist que personne n’avait écrite doit être rejouée à l’envers, de mémoire.
Ce qui se passe entre les deux
Entre ces deux journées, les accès dérivent.
Quelqu’un a été ajouté à un repository pour un après-midi de débogage. Un prestataire a reçu un canal Slack pour un lancement terminé en mars. Une personne a changé d’équipe dans l’agence et a tout gardé de l’ancienne, parce que retirer des choses est une tâche sans échéance.
Rien de tout cela n’est visible quelque part. Chaque fournisseur connaît sa moitié de l’histoire, et aucun ne connaît ce qui vous intéresse vraiment : à quel travail client chaque personne peut accéder. Vous pouvez l’auditer, et l’auditer veut dire cinq interfaces d’administration, un tableur et une heure que vous ne passerez pas deux fois.
Organiser les accès autour du projet
La solution est d’arrêter de penser en fournisseurs pour penser en projets, parce que le projet est l’unité que le travail possède réellement.
Une personne est ajoutée aux projets sur lesquels elle travaille. À partir de là, les accès dont elle a besoin se déduisent au lieu de se rappeler : les repositories de ce projet, les canaux de ce projet, les serveurs de ce projet. Ajouter quelqu’un à un projet provisionne exactement cela. L’en retirer reprend exactement cela. Quelqu’un qui travaille sur deux de vos quarante clients finit avec l’accès à deux de vos quarante clients, sans que personne ait eu à faire attention.
Le départ cesse d’être un exercice de mémoire, puisque c’est la même opération avec le signe inversé.
Ce qu’Unolia en fait
Unolia gère les accès chez les fournisseurs où le modèle tient : GitHub et GitLab pour les repositories, Slack pour les canaux, Cloudflare pour les membres d’un compte, et Laravel Forge pour les membres d’équipe et les serveurs partagés avec eux. C’est la liste actuelle, et c’est volontairement une liste plutôt qu’une promesse. Les fournisseurs qui n’y sont pas ne sont pas touchés, et le reste de votre infrastructure continue d’être géré comme aujourd’hui.
Pour ceux qui sont couverts, vous choisissez jusqu’où aller, connexion par connexion. Unolia peut rester complètement à l’écart, ou lire ce qui existe pour que vous voyiez le tableau sans que rien ne bouge, ou appliquer réellement ce que dit le projet. Commencer par lire est le choix honnête, parce que la première chose que la plupart des équipes découvrent est un surplus plutôt qu’un manque.
Unolia compare ce que vos projets disent qu’une personne devrait atteindre avec ce que chaque fournisseur déclare qu’elle peut atteindre, et vous montre la différence : les comptes distants qui ne correspondent à personne, les accès qui ont survécu au travail pour lequel ils avaient été donnés, la personne qui devrait avoir quelque chose et ne l’a pas. Vous relisez cette liste et vous décidez. Rien n’est révoqué dans votre dos.
Pourquoi cela vaut la mise en place
Un après-midi par recrutement est agaçant, pas coûteux. Ce qui justifie la mise en place se joue à l’autre bout.
Quand quelqu’un quitte une agence, l’écart entre son dernier jour et le jour où son dernier accès disparaît vraiment se compte en semaines, parfois en jamais, et personne ne peut donner ce chiffre avec assurance. Cet écart est le risque, et il est entièrement fait de choses que personne n’a écrites.
Quand un client demande qui dans votre agence peut atteindre son site, cela devrait être une question avec une réponse plutôt que le début d’un audit.