De l’artisanat aux bases de l’industrialisation

Cet article ne parle pas de code. Il parle de mes premiers mois chez Chouettagence, où j’ai fait ce que j’ai pu pour « industrialiser » les processus qui étaient encore très artisanaux malgré une équipe comptant pas loin de 20 développeurs.

Tout commence bien

Cette année, pour moi, était vraiment celle du changement. J’ai décidé de quitter Èssèsdeuzi, une SSII de 600 personnes dans laquelle je travaillais depuis deux ans, pour une entreprise plus petite. Je ne voulais plus créer un ticket pour demander le moindre service au système ou à l’équipe d’hébergement. Je ne voulais plus de projets au forfait pour des grands comptes, qui durent des mois et des mois au détriment de la qualité du code, du site et de mes nerfs. Donc, pour la première fois de ma courte carrière, j’ai posé ma démission, et j’ai mis les voiles.

En juin, me voilà donc arrivée dans Chouettagence, une agence web de 40 personnes, soit quinze fois moins que chez Èssèsdeuzi.

Tout commença très bien : Chouettagence prenait bien mieux  soin de ses employés que Èssèsdeuzi, et favorisait beaucoup la veille technologique par les développeurs. J’étais très heureuse d’avoir changé de boîte, le ciel me semblait bleu. Je n’ai pas tardé, hélas, à remarquer de sombres nuages à l’horizon.

L’envers du décor

Je me rappelle exactement comment j’ai réalisé que quelque chose n’allait pas. À l’entretien d’embauche, DirecteurTechnique m’avait expliqué que les équipes travaillaient avec git. Le jour de mon arrivée, j’ai donc demandé à mon collègue, celui qui était assis à côté de moi, où étaient les dépôts git, histoire que je puisse cloner, configurer et bosser.

Il a pincé les lèvres et m’a regardé tristement, comme s’il n’avait pas vraiment envie de répondre. Et, d’ailleurs, il a esquivé la question !

Il y avait de quoi. Tous les développeurs travaillaient sur la même instance du code, partagée via un montage NFS. De temps en temps, quand ils y pensaient, ils commitaient leurs fichiers sur le dépôt git local. Stupeur. Premiers tremblements.

Les mises en prod, quant à elles, consistaient à envoyer manuellement les fichiers sur les serveurs de prod depuis FileZilla. Tout cela, évidemment, depuis l’instance de dev sur laquelle travaillaient plusieurs développeurs en même temps. Stupéfaction. Sueurs froides.

Voici un petit florilège de phrases que l’on entendait alors régulièrement dans l’open space.

• « Hey Georges, est-ce que tu as fini de travailler sur bidule.inc ? Il faut que je fasse mes modifs aussi… »
• « C’est bon ? Je peux envoyer le fichier toto.htm en ligne ? »
• « Je vais passer trucmuche.class.inc en prod pour que le client puisse tester. »
• « Haaaann t’as envoyé la dernière version de machin.js en ligne ? MON DIEU NON ! »
• « Oh, le site est cassé. Ah bah oui, j’ai oublié d’envoyer chose.class.inc en ligne… »
• « Oh, le site est cassé. Pourquoi ? [Recherche de deux heures…] Ah oui, la structure de la base n’est pas la même en dev et en ligne… »

Je ne sais pas ce que cela vous évoque. Personnellement, entendre cela m’inspire le plus profond désespoir.

Ce genre de phrases, à mon sens, ce n’est pas du tout ce que l’on est censé entendre dans un open space empli de développeurs professionnels. Il existe des outils et des méthodes pour éviter d’entendre cela.

Deux solutions : la fuite… ou le retroussage de manches

Ma première envie a été simple : fuir, trouver un autre boulot. J’avais deux offres de CDI qui attendaient encore dans ma boîte mail. C’était facile.

Avant de fuir, j’ai toutefois parlé à DirecteurTechnique, celui-là même qui m’avait embauchée. Il m’a dit quelque chose de très simple :
« Si tu veux lancer des projets d’industrialisation, vas‑y. C’est ça que j’attends de toi. »
C’était fou. Alors qu’on m’avait toujours dit « nous allons voir ce qu’on peut faire » chez Èssèsdeuzi, voilà qu’on me disait « fais ! ».
Sur le coup, je me suis sentie… Comment dire ? Trop libre.
J’ai pris une grande inspiration. J’ai inscrit sur un papier ce qui n’allait pas et surtout ce que je voulais à la place. Quand on veut changer les choses, il ne faut pas se contenter de dire ce qui ne va pas : il faut proposer des solutions.

Voici ce que j’ai noté sur mon papier :

Écrire ce tableau, formaliser les problèmes, m’a beaucoup aidée par la suite : il n’avait que quatre lignes. Ainsi, il n’y avait donc « que » quatre choses à faire pour arranger les choses. La deuxième colonne contenait des arguments de choix pour convaincre de la nécessité du changement : « risque d’erreur » et « perte de temps » sont des choses que j’ai beaucoup répétées.

Lancer le changement…

J’avais identifié le problème no 1, celui qui me dérangeait le plus : cette histoire d’instance de développement unique par développeur.

irecteurTechnique, qui, grâce à ses dix ans de boîte, maîtrisait beaucoup mieux que moi l’architecture du SI de Chouettagence, a mis en place les bases techniques de la solution à ce problème.

Mais l’existence de la solution technique ne suffisait pas : il fallait pousser les développeurs à l’utiliser ! C’est là que je suis intervenue. Pour communiquer.

Tout d’abord, il a fallu expliquer le principe d’un gestionnaire de versions, les commandes git de base, etc. Pour cela, les séminaires techniques (réunions hebdomadaires d’une heure, durant lesquelles les développeurs discutent de leurs trouvailles de la semaine) se sont révélés très précieux. J’ai présenté git et git flow lors d’un séminaire technique, et l’architecture proposée par DirecteurTechnique à un autre séminaire. J’ai bien insisté sur pourquoi nous voulions cette solution. Retenez ceci : expliquez pourquoi vous voulez changer. Si vos utilisateurs ne sont pas convaincus de l’utilité du changement, ils le suivront à reculons, et ça ne fonctionnera jamais !

Heureusement, mes collègues étaient, pour la plupart, déjà demandeurs de changement de ce côté-là. Les arguments de mon tableau ont rapidement convaincu les derniers.

Entre les séminaires, pour les aider à se former à git, je postais régulièrement mes trouvailles (et des arguments supplémentaires) sur le RSE (réseau social d’entreprise). Imaginez un facebook interne à l’entreprise, utilisé pour partager blagues et liens de veille techno. Le RSE s’est révélé être un excellent moyen de toucher l’ensemble des développeurs et de leur permettre de retrouver rapidement les liens utiles que je partageais.

… un pas à la fois, et en acceptant des compromis

Il a fallu accepter des compromis. L’architecture que je visais, par exemple, c’était quelque chose de très carré, avec une base par développeur, des mises en production automatisées à partir d’un dépôt git bare…

Oui, mais il y avait beaucoup de mais. À force de discussions, nous sommes arrivés à une architecture moins jolie, avec une instance de code par développeur, mais une seule base de données pour les instances de développement. Les mises en production sont toujours manuelles, mais elles se font à partir d’une instance du code que les développeurs ne modifient pas directement, une sorte de clone sacré sur lequel on n’a le droit de faire que des git pull.

Ce n’est pas parfait. Si une grosse modification de la base de données est effectuée par le développeur A, le code des développeurs B et C peut devenir instable. En pratique, sur les projets courants, ce défaut n’est pas trop dérangeant : généralement, les modifications de base sont rétrocompatibles avec l’ancien code.

De plus, le processus de développement est devenu bien plus complexe : avant, les développeurs codaient, puis envoyaient leurs fichiers en ligne et basta. Maintenant, ils git pull, ils codent, ils git commit, ils git fetch, puis ils git merge, puis ils git push, puis ils font un git pull sur le dépôt sacré, et enfin, ils peuvent envoyer leurs fichiers en ligne. Ça en fait du boulot, pour prétendument gagner du temps ! Et je ne vous parle même pas de la psychorigide un peu bizarre qui leur tape dessus pour qu’ils testent soigneusement leur code avant le git push. Pauvres, pauvres développeurs.

Surtout, puisque les mises en prod sont toujours manuelles, on risque toujours de se tromper.

Certes. Mais un petit git diff –name-status [commit1] [commitn] permet de lister les fichiers modifiés pour ne pas en oublier.

En réalité, même si ce système est imparfait, il est déjà bien meilleur que l’ancien. Même si les développeurs tapent plus de choses dans leur ligne de commande, il nous a permis de gagner du temps et d’économiser beaucoup d’énergie.

Ainsi, un changement somme toute assez simple à mettre en place a déjà supprimé pas loin de 80 % des phrases hérisse-poil que j’entendais au début de mon CDI. Ça s’appelle la loi de Pareto.

Ne pas faire trop de compromis

Autant j’ai accepté certains compromis, autant j’ai été intraitable sur d’autres points. À partir du moment où l’on a commencé à utiliser git « pour de vrai », j’ai mené une chasse sans pitié aux commits foireux et aux messages de commits non significatifs. J’ai menacé des pires souffrances ceux qui avaient modifié des choses et les avaient envoyées en prod sans les commiter sur git.

C’est très bien d’être sans pitié de la sorte, à une condition : précisez à l’avance ce que vous attendez de vos collaborateurs. Si vous leur tombez dessus à bras raccourcis pour avoir fait une chose dont ils ne savaient pas qu’elle était interdite, vous risquez d’être franchement contre-productif.

Conclusion

Pour l’instant, nous n’avons « que » mis en place l’utilisation de git. Il reste encore beaucoup à faire pour pouvoir parler d’industrialisation aux petits oignons, et pourtant nous avons déjà gagné beaucoup de temps !

Deux conclusions s’imposent : d’une part, si vous codez (ou créez) sans gestionnaire de versions, même si vous êtes tout seul, mettez-vous‑y dès maintenant ! Cela vous permettra d’expérimenter, d’avoir droit à l’erreur, et vous serez prêt quand il faudra que quelqu’un d’autre participe à votre projet (ce qui pourrait bien arriver plus tôt que prévu).

D’autre part, si vous voulez changer les choses au travail, préparez-vous à y investir beaucoup d’énergie. Prenez le temps d’expliquer les raisons du changement pour obtenir l’adhésion des personnes concernées. Prenez aussi le temps de former tout le monde aux nouvelles technologies que vous introduisez. Et aussi, soyez pragmatique, pas dogmatique : acceptez les compromis.

Voilà, c’est tout. Gitez bien. ;)