Fabrice : Bonjour, je m'appelle Fabrice Bernhard. Je suis le cofondateur et le directeur technique de deux boites. La première c'est allomatch.com, le site du sport dans les bars, qui permet de trouver quand il y a un match de foot le soir un bar pas trop loin de chez soi qui le diffuse. Deux ans après, j'ai créé avec mon associé, une deuxième boite qui s'appelle Theodo, une boite de service, qui fait du développement web sur mesure avec un focus fort sur l'idée d'amener la vitesse des meilleures start-up sur les projets de nos clients. Ça m'a amené au Devops, parce que d'un coté j'avais la partie éditeur d'allomatch où je devais maintenir un site sur le long terme et puis j'ai été amené à voir les problématiques plus de services, grâce à Theodo.
Fabrice : On a ce focus dès le premier contact avec le client sur la vitesse de réalisation, mais au sens vitesse business, donc plus Lean Startup. Ça fait longtemps que l'on fait du Scrum, qui permet de développer très vite, mais ça ne suffit pas à donner la vraie vélocité business parce que l'on peut très bien développer très vite et mettre en prod au bout de 2 ans. C'est pour ça que l'on va vraiment se focaliser sur plein de choses, des idées Devops, mettre en prod très rapidement, avoir le serveur de prod dès le début du projet, ce genre d'idées qui sont fortes et que l'on va vendre à nos clients, non pas par le biais du Devops, mais par le biais du Lean Startup, qui est de dire "voilà, pour que votre business réussise, il faut vraiment itérer très rapidement en production".
3. InfoQ: Quels sont les principaux points de blocage que tu rencontres généralement ?
Fabrice : C'est les points de blocage classiques quand on essaye de faire de l'agile avec des gens qui ne connaissent pas, il faut faire de la pédagogie et il y a aussi un point de blocage au niveau de l'organisation. En particulier, ce qui est intéressant au niveau Devops, c'est que ça secoue beaucoup l'idée que l'hébergement est quelque chose de séparé. On va devoir demander des accès root aux serveurs, ce qui marche très bien si la personne ne veut pas s'occuper de l'hébergement, mais qui pose problème si l'on doit s'interfacer avec une DSI qui est censée gérer l'hébergement.
Fabrice : L'idée phare de Devops, c'est toute la culture technique qui va permettre le Lean Startup. Le déploiement rapide c'est un point très important, on parle beaucoup d'outils de provisionning comme Puppet et Chef qui sont vraiment nécessaires dès que l'on commence à faire du scaling dans le cloud. Quand on n'en fait pas, c'est un peu moins nécessaire, mais ça reste très intéressant pour reproduire le même environnement en développement et en production. L'idée principale c'est avant tout d'accélérer le cycle de mise en production.
Fabrice : L'erreur que l'on retrouve tout le temps dans une équipe de développement, c'est cette idée de toujours sous-estimer le coût de la mise en production. Et donc s'il y a une chose à faire, c'est que la mise en production doit avoir lieu le premier jour. Avoir adressé les risques des mises en production dès le premier jour, ça va énormément simplifier les choses et permettre d'anticiper énormément de problèmes et se mettre dans l'idée de déployer très souvent en production.
Fabrice : Une des idées est que quand un Ops va intervenir sur le projet des développeurs, c'est de lui interdir de pouvoir le faire tout seul. Un Ops qui intervient sur un projet doit le faire en pair-devopsing avec un développeur du projet.
7. InfoQ: Quel est le principe du pair-devopsing ?
Fabrice : Le pair-devopsing est basé sur le pair-programming, qui est de dire qu'à deux personnes sur le même ordinateur, on a finalement plein de gains long terme et donc c'est rentable. L'idée du pair-devopsing, c'est d'adresser une problématique de la méthode Scrum qui est qu'est-ce qu'il se passe si on veut que l'équipe technique résolve les problèmes elle-même, mais qu'il lui manque une expertise technique. Dans ce cas, le pair-devopsing c'est l'idée de résoudre ça en ne permettant pas à l'Ops de résoudre le problème technique à leur place, mais de le faire sous forme de mentoring, de tutorat, d'un des développeurs de l'équipe et donc de le former par la même occasion et donc apporter cette nouvelle compétence dans l'équipe Scrum.
Fabrice : Je pense que c'est une question de contrat moral, c'est très difficile de demander à un développeur, à partir du moment où on s'était mis d'accord qu'il avait un rôle de développement, de passer à un rôle d'astreinte. La première solution, c'est déjà de le prévoir en amont. La notion d'astreinte, c'est la notion la plus importante parce que je ne pense pas que ce soit une question d'implication, les développeurs sont toujours fans de leurs bébés, mais c'est une question de contrat moral, on ne peut pas demander à quelqu'un de se concentrer toute la journée très fort et ensuite, la nuit, d'être d'astreinte sans l'avoir au moins prévenu en amont.
9. InfoQ: Merci d'avoir pris le temps de répondre à nos questions et à bientôt
Fabrice : Merci beaucoup.