La réalité derrière le quotidien d’un développeur consultant

Développeuse depuis 3 ans, je repense souvent à la façon dont je voyais le métier de développeur ou de consultant à l’école et à quel point j’étais loin de la réalité.

J’imaginais un métier scotché derrière un ordinateur, à écrire des lignes de code toute la journée pour des résultats peu visibles, tout ça avec peu d’interactions sociales. Un peu dans un style « femme de l’ombre », on sait qu’elle fait des choses mais on ne sait pas vraiment quoi.

Ça m’inquiétait car je ne voulais pas forcément d’un métier si spécifique et si technique et je pensais qu’il fallait rapidement en sortir et devenir cheffe de projet, pour qu’il devienne intéressant.

Aujourd’hui, après avoir donné des cours à des élèves ingénieurs, je me rends compte que beaucoup se posent les mêmes questions que moi. En effet, les écoles ne s’attardent pas forcément sur ce qu’il se passe après le diplôme. Que se passe-t-il une fois arrivé dans le « vrai monde de l’entreprise » ? Les stages nous préparent un peu à la suite, mais au final, on reste toujours inquiet de ne pas être à la hauteur en arrivant sur le marché du travail.

Même constat avec les « métiers non tech » de mon quotidien qui peuvent avoir du mal à comprendre ce que font les équipes techniques.

Alors spoiler : non, être développeur, c’est bien loin du mythe, bien ancré dans l’inconscient collectif, du geek qui développe dans son garage depuis ses 10 ans. Il y a tellement plus autour et on va essayer de décortiquer un peu le métier.

L’iceberg

Quand on nous explique un peu ce qu’est le métier de développeur à l’école, on nous dit globalement que le code est divisé en trois parties :

• le Front (ce que « vous voyez », la page du site que vous avez devant vous),
• le Back (la partie qui gère l’accès et le traitement des données),
• l’Ops (la partie qui sert à rendre le Front et le Back accessibles).

On nous explique que le Front a souvent besoin du Back pour exister, puisqu’il s’appuie sur ce dernier pour récupérer ou envoyer des données. On nous dit aussi que ces technos permettent de créer « des applications » (attention, ici on ne parle pas forcément d’application mobile mais aussi d’application web).

C’est la partie émergée de l’iceberg : en fait, il y en a tellement plus que ça.

Si on plonge un peu plus loin, on se rend compte qu’il existe bien plus que la partie essentiellement développement. Il faut également prendre en compte la partie conception, les déploiements, les notions de stockage de données et de performance, la mise en production et j’en passe.

Toutes ces étapes sont souvent noyées dans la simple présentation d’une démo pour présenter la nouvelle fonctionnalité à une équipe non technique qui ne durera que quelques minutes.

À l’école, on apprend la partie technique : comment je crée telle application. Mais on ne sait pas comment on passe de cette « création » à un « vrai » projet.

Finalement un vrai projet c’est :

• Comment travailler efficacement et durablement avec les autres ?
• Comment s’organiser ?
• Comment choisir les fonctionnalités utiles pour les utilisateurs ?

Le déroulement

Alors pour comprendre un peu plus en détail, on va dérouler ensemble le développement d’une fonctionnalité.

Avant d’aller plus loin, il est important de noter qu’il y a un certain nombre de types de projets et d’équipes. Sans entrer dans les détails, on peut identifier les trois typologies suivantes :

• des « gros » projets, dans lesquels on va beaucoup s’inspirer de ce qui est déjà fait, continuer un projet qui « roule » bien,
• des projets « from scratch », pour lesquels il faut tout créer de A à Z,
• des projets « legacy », pour lesquels il faut tout nettoyer et remettre au propre !

Pour chacune des ces typologies, la part relative de certaines tâches par rapport à d’autres va varier. Par exemple, dans un projet « from scratch », il est évident que la part de conception fonctionnelle sera plus importante que dans un projet « legacy ».

« Tout remettre au propre » dans un projet « legacy » va nécessiter beaucoup de compétences techniques d’anciennes technologies, mais aussi des nouvelles, beaucoup de tests pour vérifier que tout fonctionne ; là où dans un « gros projet qui roule », on peut s’attendre à être confronté à des technologies plutôt récentes, maîtrisées et une industrialisation des tests qui va limiter le risque de régression fonctionnelle.

Un travail préalable de réflexion sur les outils à utiliser au sein du projet doit également être réalisé dans les projets « from scratch » pour adresser de nombreux enjeux. Par exemple : comment partager l’information (que ce soit au sein de l’équipe ou avec les autres équipes), comment documenter le projet, quels seront les différents environnements de développement et comment seront-ils créés, de quelle manière sera géré le code, comment industrialiser les tests et les livraisons.

Il est fréquent de devoir également questionner l’organisation du projet, le rôle des différents acteurs et qui prend ces rôles. Pour simplifier, considérons qu’une méthodologie de projet est retenue, adaptée au projet et à l’environnement dans lequel il va se dérouler. Concrètement, dans la plupart des cas, il s’agira d’une méthodologie d’inspiration Agile, souvent dérivée de la méthode « Scrum ». Celle-ci permet de favoriser des développements suivant des cycles de quelques semaines, avec une implication constante et directe des personnes qui connaissent le métier associé au projet (le quoi et le pourquoi) et des personnes techniques (le comment). Cela permet d’obtenir à la fin du cycle (souvent appelé sprint) une fonctionnalité complètement terminée.

Une fois que ces éléments sont mis en place, on peut passer au développement !

Recueil du besoin

Dans un premier temps, la personne « responsable » de la définition du besoin (souvent le Product Owner — aka PO dans les équipes Agiles) recueille auprès des clients les informations et les besoins qu’ils ont.

Son travail consiste à trouver les fonctionnalités qui auront le plus de valeur métier pour le temps de développement investi. On appelle ça le ROI : retour sur investissement.

Refinement

Une fois ce besoin défini, le projet est présenté à l’équipe de dev.

L’équipe de dev va alors poser ses questions, pour bien comprendre le besoin et étudier les cas qui n’auraient pas forcément été abordés : que se passe-t-il sur mon application si je n’ai plus de réseau, par exemple ?

Si le responsable du besoin a des questions de faisabilité, c’est aussi le bon moment pour en parler. Imaginons qu’il ait une demande un peu « farfelue », comme « Je souhaite que mon produit puisse fonctionner sur la Lune », c’est le rôle de l’équipe de dev d’expliquer si oui ou non c’est possible. Elle doit alerter si le développement est trop complexe, ou ce que ça va coûter en temps de travail pour le nombre d’utilisateurs qui iront vraiment sur la Lune. L’objectif : savoir si ça vaut vraiment le coup et proposer des alternatives pertinentes.

En général, le responsable du besoin sait anticiper, lors de la phase de recueil de besoin, ce qui est vraiment « farfelu ». Il lui est en revanche particulièrement difficile, n’étant pas développeur, d’anticiper la complexité réelle de demandes en apparence simples : ajouter un bouton d’action à un endroit, ça semble toujours très simple ; et pourtant, il peut exister mille raisons technico-fonctionnelles qui rendent l’ajout de ce bouton « à cet endroit » quasiment impossible.

Ce moment, appelé « refinement » dans la terminologie Agile, permet donc de donner une estimation en termes de temps de dev. Cette dernière sera précieuse car elle permettra au PO de prioriser et de savoir s’il faut développer ou non cette fonctionnalité. Attention, il faut quand même noter que l’estimation n’est jamais juste dès le départ, même avec les meilleures développeuses et les meilleurs développeurs !

Grâce à ce refinement, l’équipe comprend mieux le produit et ce qu’il doit faire. Les fonctionnalités pourront être priorisées en fonction des retours qui auront été faits, ce qui est un point très important. En effet, ces informations et ces échanges sont primordiaux pour le ROI et donc l’avenir économique du projet.

C’est aussi ça, le métier du dev : réussir à faire comprendre les enjeux techniques à quelqu’un qui n’a pas forcément la connaissance nécessaire. C’est important de savoir être pédagogue, précis et d’aller au-delà de soi disant évidences.
Ces étapes renforcent également la confiance réciproque entre le métier et la tech : quand la confiance est installée, tout va plus vite et l’envie de réussir est encore augmentée.

Atelier de conception

Le refinement terminé, on a bien cadré le besoin fonctionnel ! On peut ensuite réaliser un petit (!) point de conception technique, pour déterminer comment on va l’implémenter.

Pendant ces points, on se challenge avec les expériences passées de chacun, avec ce qu’on a lu, ce qu’on a testé. On se pose aussi des questions sur la préférence à donner entre la performance et la maintenabilité.

On prend en compte un certain nombre de critères, il faut évidemment penser au futur et à la solution qui permettra au mieux de maintenir les anciennes fonctionnalités tout en faisant évoluer le projet avec les nouvelles.
Mais il faut aussi penser au présent : Quelle est la date de livraison souhaitée ? De quel budget dispose le projet ? Quel est le niveau de compétence de l’équipe de dev actuelle ?

Toutes ces questions permettront aux développeurs de l’équipe d’échanger sur la meilleure solution à choisir ; qui au final sera un équilibre entre « je fais très vite mais avec des raccourcis techniques voire fonctionnels qui pourront poser des problèmes ultérieurement » et « je fais le plus parfaitement possible pour ne pas avoir de problèmes/limites plus tard mais ça va prendre beaucoup plus de temps ».

Développement

Ensuite c’est parti pour le dev ! On peut travailler seul mais aussi à plusieurs. Travailler en « pair programming » permet par exemple de partager la connaissance sur le projet et les technos : dans cette pratique, un duo va travailler en même temps sur le même sujet avec la promesse que, au final, la somme du temps passé par ce duo sera au maximum égale au travail d’une personne pour faire la même chose, mais sans le partage de la compétence et avec moins de recul sur le résultat produit.

Même sans ces approches en pair, on n’est jamais vraiment tout seul devant son PC. On a toujours la possibilité de réfléchir à plusieurs et de demander de l’aide ou des conseils aux autres. Ces échanges avec les autres développeurs permettent aussi de ne pas avoir à « réinventer la roue » et de penser à récupérer des choses qui existent déjà ; les réutiliser en les améliorant.

En fonction de l’ampleur de la fonctionnalité (ou « feature »), le dev peut durer de quelques heures à plusieurs jours. Il faut penser que souvent, un développement s’accompagne d’un certain nombre de tests, aussi bien fonctionnels (c’est à dire qu’on teste « manuellement » tous les cas possibles) mais surtout techniques. Ces tests techniques sont aussi du code, dont le but est de vérifier que la feature développée se comporte comme attendu. Un des avantages d’écrire ce code de test technique (plutôt que de tester manuellement), c’est que l’on peut ensuite rejouer ces tests sans aucun effort et même automatiquement pour vérifier que le code ancien (de la semaine dernière ou de l’année précédente !) fonctionne encore malgré les évolutions. On parle ici de tests de non régression.

Ceci est un des nombreux exemples des choix que doit faire un dev : faut-il perdre du temps à coder des tests automatiques pour en gagner plus tard, ou alors considérer que l’on peut se passer de ces tests et passer à la prochaine fonctionnalité ?
Même au sein d’un projet où la règle est d’écrire systématiquement ces tests, la question sera latente : jusqu’à quel niveau de précision je pousse l’automatisation des tests pour obtenir un bon niveau de confiance ?

Ces choix constants que fait un dev rendent le métier encore plus passionnant. Ils permettent à l’équipe de partager des points de vue afin d’obtenir des choix judicieux. Et ce partage ne s’arrête pas là, il est au centre de l’étape suivante…

Review

En effet, une fois la phase de dev terminée, on entre dans la phase de Review. C’est là que d’autres développeurs vont pouvoir relire le code produit pendant le développement.

Cette phase-là est essentielle. Elle revient de fait à organiser un certain nombre d’aller-retour entre plusieurs développeurs de l’équipe sur le code produit.
Cela permet de repérer les erreurs, mais aussi et surtout de partager la connaissance et la mise en place de bonnes pratiques dans l’équipe. On n’est plus vraiment ici sur une méthode d’apprentissage académique. On souhaite au maximum apprendre en équipe, grâce à des devs plus expérimentés par exemple.

Attention aussi, parce que si d’autres devs prennent le temps de relire notre code, il faut évidemment comprendre que c’est une partie importante du travail de développeur et qu’à notre tour, il faudra que nous prenions le temps de relire et de travailler sur le code des autres.
Cela crée une forme de cercle vertueux : chacun vise à rendre le code le plus agréable à lire pour rendre ces « code reviews » les plus efficaces possible.

Ces échanges contribuent non seulement à la qualité du produit final (notre fameuse fonctionnalité), à la compétence de l’équipe projet mais aussi à la prise de recul individuelle sur sa propre compétence.

Le reste ?

Voilà, on y est, le dev est terminé, tout a été fait en respectant les règles de l’art, la fonctionnalité est prête, les utilisateurs devraient pouvoir s’en servir maintenant.

Sauf que non, il reste encore un certain nombre d’étapes (et la liste qui suit est non exhaustive) :

• créer et déployer la nouvelle version sur un environnement pour la tester,
• faire la « recette », c’est à dire tester la fonctionnalité avec des données au plus proche du réel,
• effectuer la mise en production, c’est à dire mettre la nouvelle fonctionnalité à disposition des vrais utilisateurs,
• communiquer avec le support ou les clients pour gérer des comportements anormaux communément appelés des « bugs ».

Il faut noter que ces étapes prennent du temps et impliquent, encore une fois, l’équipe de dev. Elles sont vraiment très importantes et demandent une coordination et une communication entre les équipes techniques et non techniques.

D’ailleurs, aujourd’hui on a beaucoup parlé de ce qu’il se passait « dans le meilleur des cas ».

Mais évidemment, comme partout, on peut rencontrer des problèmes dans une équipe et il faut réussir à trouver et mettre en place des solutions pour les résoudre. Cette partie est très stimulante et demande d’être force de proposition lorsque « tout va mal ».

Dans ces cas, d’autres types de compétences sont mobilisés par certains devs de l’équipe : des compétences qui s’apparentent à du management, y compris de crise, pour trouver un chemin d’amélioration qui s’appuiera au moins forcément sur les membres de l’équipe.
C’est un autre sujet, tout aussi passionnant, auquel tout dev peut être confronté s’il le décide.

Ce qu’il faut retenir ?

Un développeur dans une équipe mature ne passe pas son temps à développer, loin de là.

Je suis consultante et je passe une grande partie de mon temps à partager avec mon équipe.

Entre les réflexions concernant la création et la maintenance du projet dans le temps, la recherche et la mise en place des bonnes pratiques, l’apprentissage de nouvelles technologies pour qu’un projet soit le plus à jour possible ou juste le fait de se former sur le domaine fonctionnel, les journées sont bien remplies et très diversifiées !

Ce métier permet de prendre conscience de beaucoup de choses et nous offre la possibilité de nous former autant sur des technologies que sur des « soft skills » essentielles dans un très grand nombre de métiers.

Il permet également de tester plein de nouvelles expériences comme apprendre à faire de la veille ou participer à des discussions sur d’autres façons de faire, et même donner des cours qu’on ne pourra malheureusement pas aborder dans cet article mais qui sont très enrichissantes.

Voilà ce que j’aurais aimé savoir il y a quelques années pour m’aider à comprendre le métier de développeur.

Par Delphine Rigaud