*moment de blanc gênant*… Bonjour ! Pour mieux comprendre ce métier, je suis allé à la rencontre d’un développeur web en chair et en code.
Jean de La Banque d’image, vous me disiez qu’avant de commencer à coder, il y a tout un tas de choses à gérer…
Bonjour Jean-Michel. Tout à fait, avant même de me lancer sur un éditeur de texte et de commencer à coder, il y a tout un tas de choses à gérer.
Lorsque vous avez un projet web, par quoi commencez-vous ?
Alors, je dois d’abord définir ce qu’on appelle une roadmap, c’est une sorte de chemin sur lequel je vais placer les étapes de réalisation de mon site ou application à développer. Pour y arriver, je vais étudier soigneusement le cahier des charges qu’on m’a confié, pour en ressortir les besoins techniques qui en découlent. Pour moi, un bon développeur doit avoir un excellent esprit d’analyse !
Vous êtes souvent amené à travailler en équipe ?
Oui, constamment. Je travaille en étroite collaboration avec des graphistes, chefs de projets ou encore des chargés de contenus. Ils vont me donner des informations et éléments essentiels à mon travail. Pour beaucoup d’entre eux, le développement web est nébuleux, il est assez courant que je reçoive des demandes incomplètes, voire irréalisables.
On pourrait avoir un exemple ?
Quand un client demande un site comme YouTube, mais en jaune et pour demain matin, parce qu’il a peur qu’on lui pique son idée…
Une grande partie de mon travail consiste à écouter, échanger et proposer des alternatives à certaines demandes aussi loufoques soient-elles. Je dois être force de proposition ! Il n’y a pas que les compétences techniques qui comptent dans ce métier, vous savez.
C’est cocasse… Revenons-en maintenant à vos tâches, après tout ça, vous vous mettez à coder quand même ?
Oui, mais pas seulement. Je vais vous expliquer. Quand le plan est bouclé, là, je peux commencer à coder avec mes outils de développement. Il s’agit de mettre les mains dans le cambouis et de créer des architectures constituées de dossiers et fichiers texte dans lesquels se trouve notre code. Mais encore une fois, même s’il s’agit de coder, je ne vais pas faire “que coder”. Une grosse partie du boulot est faite de recherche.
Des recherches dites-vous ?! Quels genres de recherches ?
Vous connaissez la fameuse blague qui consiste à répondre à chacune de vos questions par : “Demande à Google” ?
Non…
Alors, “Demande à Google !” *rire malaisant*…
Bon, en gros, dès que je rencontre un problème, je vais passer du temps à chercher la bonne documentation technique, au bon endroit. Un développeur n’a jamais réellement fini de se former, même lorsqu’il n’est plus considéré comme “junior”, il doit toujours se tenir informé des dernières technos et tendances du web. Il m’arrive même d’échanger sur des plateformes de dev et de reprendre un bout de code déjà créé par un autre programmeur. C’est un peu du scrapbooking informatique le truc.
Bon, après ton “Demande à Google !”, je te tutoie Jean. Là, c’est fini, ou toujours pas ?
Pas de souci Jean-Mi ! Non, ce n’est toujours pas fini. Une fois que j’ai validé mon architecture, il faut bâtir l’empire ! Je vais coder tout ce dont le projet a besoin avec les langages de programmation adéquats. Entre le front-end (la partie visible du site) et le back-end (la partie cachée) il y a pas mal de choses à faire.
Pour la partie front-end et back-end, tu t’occupes des deux ?
Oui, je suis ce qu’on appelle un dev fullstack, mais certains développeurs ne font que le back et travaillent avec un autre développeur qui va s’occuper du front, ou inversement.
Et une fois que tu as fini de coder, tu as fini de travailler ?
Non, je dois encore envoyer le tout en production. En gros, je dois publier le site ou l’application pour que ça soit accessible aux utilisateurs. Mais avant, je dois m’assurer de proposer une expérience réussie. On ne peut pas prendre le risque de publier quelque chose que les internautes ne peuvent pas utiliser.
Comment on s’assure qu’un site ou une application fonctionne avant de le publier ?
On emprunte tous les chemins utilisateurs possibles pour repérer d’éventuels bugs ou encore vérifier l’ergonomie. Et là, seul ou en équipe, souvent en équipe, on va lister toutes les corrections qu’il faudra effectuer. C’est ce qu’on appelle un reporting !
Et là, c’est fini ?
Toujours pas, non. Une fois que le reporting est bouclé, je m’attaque aux tests unitaires et fonctionnels. En d’autres termes, je rédige des scénarios possibles pour être certain que l’ajout d’une fonctionnalité n’a pas cassé une fonctionnalité précédente, c’est un code qui va tester du code. On peut s’en occuper avant ou en même temps que l’on écrit notre code, ça dépend des façons de faire.
Et ensuite, on envoie en production, c’est bien ça ?
Une fois qu’on a testé, débuggé… je peux envoyer en production, mais mon travail n’est pas fini pour autant. On n’est jamais à l’abri d’un nouveau problème à gérer ou d’un retour utilisateur. Le client peut aussi demander un changement, un ajout ou encore une mise à jour d’informations. C’est le côté suivi, amélioration et maintenance du travail.
