Partager les droits d’accès

par Pierre de La Morinerie, le 2 décembre 2016 | 3 commentaires

Picture of crossed keys, inspired by the film "The Grand Budapest Hotel" by Wes Anderson

Les clés du serveur / crédits

Chez Trainline Europe, nous avons vite décidé de faire confiance aux gens que nous recrutons. Une fois que vous rejoignez le wagon, vous ne restez pas sur le marchepied. Vous n’obtiendrez pas un accès progressif au code, une vue partielle de nos systèmes d’exploitation ou des droits au cas par cas : tout employé a accès à tout, autant que possible, dès le début de son aventure chez nous.

Cette décision accorde beaucoup d’avantages concrets. Elle permet de libérer la créativité de chacun : quand vous n’avez pas à requérir une permission d’accès, vous êtes libre d’expérimenter pour arriver à des solutions. Elle évite les moments de flottement et la paperasse supplémentaire : quand l’administrateur système part en vacances, le travail sera fait sans attendre son retour pour valider les changements. Elle rend tout le monde plus responsable : quand vous obtenez les droits d’accès à un système, vous avez tendance à prendre cette responsabilité plus à cœur.

Étudions ensemble quelques exemples.

Par ici, le nouveau. Suis-moi.

Bienvenue chez Trainline Europe. C’est votre premier jour, et en quelques heures, vous aurez accès à tous nos outils.

Vous êtes un WOW Engineer (aussi connu chez nous sous le nom de « spécialiste expérience client »), avec pour mission d’aider nos clients en cas de pépin ? Vous aurez bien entendu accès à OTRS, notre outil de gestion du support par mail. Mais vous pourrez aussi explorer GitLab, l’outil utilisé par nos développeurs pour écrire et héberger le code-source de tous nos programmes. Vous y trouverez notre carnet de suivi de problèmes, et pourrez laisser des commentaires sur notre code ou nos ébauches d’interfaces. Mieux, on vous formera même à le faire. Vous utiliserez ces connaissances pour répondre plus précisément à nos clients (« Oui, nous sommes bien en train de travailler sur l’intégration des billets pour Eu-La-Mouillette »), mais aussi pour remonter les problèmes aux développeurs.

Vous êtes développeur ? Vous aurez accès à GitLab, mais aussi à OTRS, notre plateforme de support client. Vous pourrez l’utiliser pour administrer les candidatures reçues, mais aussi pour répondre à de vraies questions posées par nos vrais clients. Mieux, on vous formera même à le faire. Prendre connaissance des problèmes que rencontrent nos clients sans passer par un intermédiaire vous donnera une meilleure idée de comment faire progresser notre produit, ou les outils qu’utilisent nos WOW engineers. Vous aurez les droits pour les mises en production, dès le premier jour. Nous n’avons pas encore trouvé de meilleure façon d’accueillir nos nouveaux développeurs que de les faire déployer leurs propres améliorations.

Vous aurez aussi accès à notre blog. Vous pouvez y écrire ce que vous voulez, et vous pourrez appuyer vous-même sur le bouton « Publier ». Vous souhaitez parler d’un sujet qui vous tient à coeur ? Connectez-vous et commencez à écrire. Bien sûr, on vous conseille de vous faire relire par quelqu’un d’autre, et de demander à la personne responsable du calendrier éditorial le bon moment pour publier votre article. Mais vous n’entendrez jamais un « Désolé, l’administrateur est en Antarctique pour 3 semaines ».

Nous utilisons Slack pour discuter entre nous. Il s’y passe beaucoup de choses : du travail, des notifications, des conversations à propos de sujets plus ou moins sérieux… Il vous manque un emoji pour vous exprimer pleinement ? Ajoutez-le, c’est permis. C’est comme cela que le rituel de mise en production prit forme de façon spontanée, en attribuant à chaque projet un emoji personnalisé. Vous souhaitez coordonner le travail de chacun sur une nouvelle fonctionnalité ? Il vous suffit de créer un nouveau channel (autrement dit, fil de discussion) public, visible et joignable par tous. Personne n’en restreindra l’accès – et si le channel s’avère inactif, il sera toujours possible de l’archiver.

Quelque chose manque sur un de nos serveurs ? Vous avez besoin d’un nouveau paquet, ou de changer un paramètre ? Les recettes Ansible qui configurent nos serveurs sont toutes accessibles, pour que chacun puisse les lire, les comprendre et les améliorer.

La preuve par l’exemple

Il y a quelques années, nous avons migré de GitHub (un outil de gestion de code-source) vers GitLab, une alternative gratuite. Même si GitLab est désormais indispensable dans notre processus de développement, les débuts ont été difficiles, notamment car certaines fonctionnalités ne marchaient pas aussi bien qu’on ne l’espérait.

Après avoir passé quelques heures à me plaindre, j’ai commencé à modifier le code source de GitLab pour corriger les éléments qui nous posaient problème. Une fois les modifications prêtes, j’ai demandé à notre CTO s’il pouvait les déployer. Réponse de sa part : il m’a nommé administrateur du serveur faisant fonctionner GitLab. Wow, c’était bien plus que ce que j’avais demandé.

J’ai déployé le code, qui a bien fonctionné, a résolu nos problèmes et a même été intégré au projet officiel. Super ! En ayant les droits d’accès, je me suis senti plus concerné. J’ai commencé à mettre à jour GitLab régulièrement, en suivant l’évolution de nouvelles fonctionnalités et en faisant d’autres corrections. Je suis devenu l’agent de maintenance de GitLab par défaut – uniquement parce que quelqu’un, un jour, m’a donné les droits d’accès.

Ce n’était pas prévu, mais ouvrir les accès nous a aidé à être plus productifs. Et ça a marché de la même manière pour d’autres sur des sujets différents : un jour, quelqu’un leur a donné les droits d’accès.

Améliorer nos outils de développement

Un peu plus tôt cette année, nous vous avons parlé de Comment nous déployons notre application web avec GitLab-CI. Cela a eu un impact positif considérable sur notre productivité : nos tests sont lancés plus tôt et s’exécutent plus rapidement, les changements sont pris en compte plus vite, le cycle de passage de l’idée à la production est réduit. On a lancé ce projet en partie parce que la transition vers ce nouveau système ne nécessitait aucune requête d’accès. Notre ancien système n’était pas configuré pour accorder des accès à tout le monde – ce qui sous-entendait que seulement quelques personnes savaient le configurer et pouvaient y soumettre des changements. Le nouveau système peut être utilisé en toute sécurité par chacun d’entre nous, et ne demande pas de permissions spécifiques – et c’est ainsi que tout a commencé.

Sécurité !

Cela ne veut pas dire que nous abandonnons toute forme de sécurité ; c’est plutôt le contraire. Les accès aux serveurs de production sont restreints à un nombre limité d’entre nous. On utilise des modèles de configuration, pour séparer les mots de passe d’un côté, et les fichiers de configuration de l’autre. On est toujours plusieurs à revoir tout changement de code ou de configuration. Et comme nos configurations sont versionnées, on peut donc toujours retrouver qui a fait quoi.

Mis à part cela, une fois que vous rejoignez l’équipe, on vous fait confiance. Pas seulement pour faire de belles choses, mais pour utiliser ces droits d’accès et faire les meilleurs choses possibles.

Conclusion

Voilà pourquoi quand on installe un nouvel outil, on s’efforce de donner les accès à autant de personnes que possible.

  • Chacun peut résoudre de vrais problèmes d’organisation avec un œil nouveau.
  • Les points uniques de défaillance sont supprimés, pour que nous puissions travailler même quand l’administrateur du système est absent.
  • Chacun se voit attribuer plus de responsabilité, qu’il pourra utiliser pour créer de nouvelles choses incroyables auxquelles nous (et vous !) n’avions jamais pensé.

Ouvrez les accès, et vous verrez enfin ce dont les gens sont capables.


3 commentaires

Hello Trainline !

merci pour cette article, preuve que la confiance peut être synonyme de succès. Donner les accès c’est bien, mais comment gérer vous lorsqu’un collaborateur quitte l’entreprise ? Je pense aux stagiaires notamment.

par Maxence, le 3 décembre 2016 à 22h39. Répondre #

Bonjour Maxence,

C’est assez simple : à chaque départ, nous révoquons les accès et formatons les machines, que ce soit un stagiaire ou un collaborateur en CDI.

par Margaux Souvignet, le 9 décembre 2016 à 14h04. Répondre #

Une raison de plus pour postuler chez vous!
D’ailleurs, je vous ai envoyé un e-mail dimanche à ce propos. J’espère avoir un retour positif parce que je suis tombé amoureux (intellectuellement).

par Luca VEZZOLI, le 24 janvier 2017 à 11h12. Répondre #

Ajoutez votre commentaire

Requis

Requis (caché)

Facebook

Twitter