Lorsque j’ai commencé à travailler en tant que développeur, la plus grosse partie de mon travail consistait à intervenir sur des sites existants ou des projets en cours de réalisation. Je ne suis pas arrivé du jour au lendemain à faire des site web de A à Z, loin de là. Au début, j’intégrais surtout du contenu dans les sites web dont nous avions la gestion, j’apportais des correctifs sur des fonctionnalités, parfois j’avais la chance d’en créer de nouvelles ! Quand un client nous envoyait un email pour nous signaler qu’il y avait un bug sur tel ou tel navigateur, je m’occupais d’identifier le problème et de le résoudre.

Tout ça pour dire que j’avais repris en main pas mal de sites internet que je n’avais pas conçus moi-même et dont je n’avais aucune idée ni de comment cela avait été fait, ni par qui.

Quand il faut modifier un site internet, il est courant de plonger dans le code d’un autre développeur et c’est normal, car un site n’est jamais réalisé par une seule et même personne (ou du moins, très rarement) et il arrive parfois de ne rien comprendre du tout au code que nous avons sous les yeux, c’est le désastre, l’apocalypse ! Il peut y avoir plusieurs raisons à cela, un raisonnement différent, pas de commentaire, des noms de variables qui ne veulent rien dire, pas d’indentation, et pour couronner le tout, plusieurs milliers de lignes de code réparties dans des dizaines de fichiers et il faut analyser et comprendre ce qui à été fait, avant même de pouvoir commencer à corriger quoi que ce soit et bien sûr, en un minimum de temps possible.

De manière générale, on est frustrés et on se dit « j’irais plus vite à refaire tout de zéro plutôt que de chercher ce qui pose problème dans ce code », on a même tendance à râler sur le développeur qui à fait le job ! (le fameux développeur malade ou en congé).

En 2013, l’agence VOUS a recruté Nicolas. Sa mission était de prendre en main tout le pole web et de superviser tout ce qui touchait de près à notre département.

À cette époque, j’étais déjà le développeur avec le plus d’ancienneté au sein de l’équipe web, j’étais dans une phase où j’intervenais sur la quasi totalité des développements et j’adorais ça ! En plus, niveau code, ça déroulait plutôt pas mal, je me sentais très à l’aise dans les différents développements qu’on entreprenait. J’avais toute liberté dans le code que je produisais et la seule contrainte que j’avais était le temps.

Nicolas a pris rapidement le lead de l’équipe et jouait très bien son rôle (l’éponge comme il le disait si bien lui-même), il apportait énormément de confort à l’équipe web en assurant la coordination avec les autres poles de l’agence et en gérant les plannings. Il nous mâchait le travail et on ne devait plus faire la « chasse aux infos ».

Le temps passe, un développeur nous quitte et on se retrouve à deux dans l’équipe. Ce n’est pas facile d’être à deux ! Surtout quand la machine est lancée et qu’il faut répondre à toutes les demandes et gérer les différents imprévus, comme c’est souvent le cas d’ailleurs. Avec Nicolas, on apprend à se connaître et on réalise ensemble quelques « beaux coups » au prix de longues soirées (les fameuses soirées pizza) ! Et moi je suis toujours dans une sorte de routine de codage (ponte de codes à gogo).

Nicolas est un énorme réservoir de connaissances, acquises, j’imagine, grâce à de nombreuses années d’expérience (ben oui il est plus tout jeune notre Nico). Il me fait profiter de tout son savoir et m’apprend à travailler de manière différente afin optimiser certaines choses. Au départ, c’était super difficile et je me rendais compte qu’il y avait plein de trucs que je ne connaissais pas et en plus j’étais toujours ancré dans mes routines (oui j’aime bien utiliser ce qui marche et ce qui a fait ses preuves). J’avais plus l’impression de perdre du temps que d’en gagner.

Le web est tellement vaste… A chaque collaboration il y a un partage naturel de connaissances qui s’opère. Mais avec Nicolas cela à été plus loin, car il m’a fait découvrir un aspect particulier du job ou plutôt, une manière de voir et d’appréhender certains développements en prenant du recul et en essayant toujours de rester humble. Au final, on ne sait jamais qui a fait le travail, ni dans quelles circonstances ce dernier a été réalisé. Le niveau de compétences, les contraintes techniques, le délai de réalisation, la méthode de travail peuvent varier, même la personnalisé de la personne entre en ligne de compte. Il y a des développeurs qui sont très rigoureux et d’autres moins mais qui apportent d’autres avantages. Bref, il y a énormément de facteurs qui peuvent intervenir en faveur ou en défaveur d’un projet.

Nicolas avait le pouvoir maximiser le potentiel d’une équipe et de s’adapter aux points forts et aux faiblesses de chacun (ouais, ça claque comme phrase hein).

Une de ses devises était « Keep it simple » (garder les choses simples), ça parait utopique dit comme ça mais il nous expliquait que dans le contexte dans lequel nous étions, c’est-à-dire en travaillant avec une équipe de plusieurs personnes sur des projets aussi bien à court terme, qu’à long terme, avec beaucoup d’allées et venues, il fallait essayer de rendre son travail le plus compréhensible et le plus simple possible pour les autres. Quelqu’un de nouveau dans le projet ne devrait pas avoir des difficultés à comprendre ce que nous avions mis en place, que ce soit en front-end ou en back-end, et ça, croyez-moi c’est beaucoup plus difficile qu’il n’y parait.

Au fil des développements, on a essayé de mettre en place des sites très simples d’utilisation, principalement avec le CMS WordPress, on réfléchissait plus au principe de comment rendre ça simple, plutôt que de comment rendre ça performant ou comment le faire avec le moins de ligne de code possible. Et au final, ça m’arrangeait très bien, car avant même d’attaquer un développement je savais déjà vers quoi j’allais aller et comment j’allais y parvenir ! Ça a été une révolution pour ma part, car ça m’a permis de gagner énormément de temps et d’avoir un autre regard sur le développement. Les présentations clients devenaient un vrai plaisir (bon OK je n’en n’ai pas fait 10.000 non plus mais bon) car c’est très facile d’expliquer quelque chose de simple.

Plus un projet (code, structure, définition) est simple et plus sa maintenance l’est aussi! En effet, on a moins de difficulté à rentrer dans le code et les projets peuvent donc être repris en main très rapidement, même si on n’est plus vraiment dedans depuis un moment, même si c’est un nouveau développeur qui intègre l’équipe. Un projet qui a bénéficié d’une « réflexion de simplicité » est plus robuste dans le sens où meilleure est la vue d’ensemble et moindre sont les effets de bord.

Pour un développeur ce n’est pas toujours évident de se mettre dans la peau du client, car le client a des objectifs et des goûts bien particuliers ainsi que des idées arrêtées sur ce qu’il veut. De plus, quelque chose de simple pour un, peut paraître compliquée pour un autre ! Mais je pense que s’efforcer de poser une base simple permet de toujours d’aboutir à un meilleur projet.

Il faut toujours essayer de rendre les choses les plus simples possible et ça ne sert à rien de se compliquer la vie. Sinon, on risque de perdre du temps et le temps c’est la seule chose qui compte dans une agence de communication.

Malgré la tournure un peu poétique de certaines phrase je te l’accorde, ces quelques lignes me tiennent vraiment à cœur et je voulais partager avec toi mon point-de-vue sur la collaboration que j’ai eue avec Nicolas.

Keep it simple !