Je suis développeur depuis maintenant plus de 6 ans et je me pose des questions sur les véritables attributions d’un développeur en France. A mesure que je gagne en expérience et en nombre de postes occupés, je me rends compte que la compréhension du métier de développeur change d’une société à une autre. Laissez-moi vous raconter une histoire.

Histoire

Dave Lawper a longtemps travaillé pour le compte d’un petit éditeur, en tant que développeur. A l’apogée de cette société, le service ne comptait guère plus d’une dizaine de ses semblables. Durant cette mission, les casquettes qu’il a revêtues ont été aussi nombreuses que variées. Un jour à produire du code, le lendemain à recueillir un besoin et écrire une spécification, et le troisième jour à s’occuper de l’usine logicielle.

Un jour, Dave Lawper a décidé de changer d’air, et d’enrichir son expérience. Sereinement, il a posé sa démission et a postulé chez divers grands comptes. L’un d’eux l’a reçu en entretien, puis l’a accepté dans ses rangs. Dave Lawper s’est alors retrouvé au sein d’une DSI, dans un grand open space avec une cinquantaine de ses collègues, dans un bâtiment comptant un bon millier de collaborateurs. Il a été affecté à un projet qui lui paraissait sympathique, et s’y est mis de bon coeur au sein d’une équipe agile. Les spécifications étaients faites, il s’agissait de faire évoluer une application existante.

Alors que Dave Lawper s’attendait à produire une spécification, ou au moins à intéragir avec des experts métier, on lui a simplement confié des tâches de développement. Un peu étonné, Dave Lawper s’est mis au travail, en mettant du coeur à l’ouvrage. Même s’il était quelque peu surpris d’avoir à abandonner ce pan complet de son ancienne mission, il s’y est résolu.

Un jour vint où, durant l’implémentation d’une user story, il se rendit compte qu’une librairie très standard pourrait lui être d’une aide précieuse. Il l’ajouta au projet et en fit part autour de lui. De gros yeux le surprirent.

“Holà, malheureux ! lui rétorqua-t-on. Il faut que tu consultes d’abord les architectes pour obtenir leur feu vert, et par écrit s’il te plait !”

Dave Lawper, de plus en plus étonné, est parti en quête de ces fameux architectes, et leur fit part de son besoin. Bien qu’il produisit les justifications de son besoin, en argumentant du bienfondé de sa demande, on lui refusa d’accéder à sa requête.

“Ce n’est pas dans l’esprit de l’application, tu devras faire sans. Les risques de régressions sont trop importants.”

Dave Lawper tenta de mener un débat constructif pour déterminer les véritables raisons de ce refus. La crainte en ressortit, ainsi qu’une certaine frilosité à utiliser cette librairie. On ne pourra pourtant pas dire que jQuery soit des plus exotiques.

Dave Lawper s’est au final résolu à n’être plus qu’un codeur, dont les initiatives et les idées étaient bridées et à ne plus pouvoir sortir de cette case dans laquelle on l’avait bien soigneusement rangé.

Moralité

Comme Dave Lawper, avez-vous vous aussi eu la sensation que le métier de développeur n’avait absolument pas le même sens pour tout le monde ? Est-ce qu’un développeur est tout juste bon à produire du code, avec pour seul interlocuteur un chef de projet lui attribuant les tâches, et un analyste/concepteur lui mâchant le travail de conception ? Ou alors un développeur est-il un véritable couteau suisse capable de prendre des décisions techniques et d’intéragir avec les experts métier ?

Chez certains comptes, et surtout les plus grands, le métier de développeur pourrait être renommé en “codeur”, maillon d’une longue chaîne d’intervenants entre le recueil du besoin et la production d’un livrable. Un expert métier expose son besoin à un analyste, qui transmet le besoin technique à un architecte, qui délègue la production du code à un codeur. Un grand nombre d’intermédiaires, induisant une certaine dispersion de l’information et une réduction de la cohésion. Un véritable téléphone arabe où l’information peut être perdue, et déformée. Des choix effectués en amont que le codeur ne pourra que subir, alors même qu’il pourrait être une force de propositions pertinentes.

La situation est même pire dans le cas où le codeur est un prestataire externe, dans un centre de service externalisé où il n’aura accès à personne d’autre que l’analyste à travers des mails lacunaires et incomplets. Comment peut-il avoir la moindre chance de répondre parfaitement au besoin de l’expert métier après avoir traversé toutes ces couches ? Un tel codeur ne peut pas produire de logiciel avec une véritable valeur ajoutée. Il devient tout juste bon à traduire des algorithmes qu’on liu a transmis en langage machine.

Et si le développeur était remis au centre de tout, et récupérait toutes ses casquettes ? Et s’il discutait avec le métier pour savoir ce qu’il implémente vraiment ? Et s’il pouvait effectuer les choix techniques sans avoir à subir ceux imposés par un interlocuteur qui ne mettra même pas le nez dans le code ? Et si le développeur était à nouveau considéré comme un ingénieur, et plus comme un simple exécutant ?

Voilà ce qu’est un développeur. Un ingénieur capable de comprendre le métier, d’effectuer des choix et de les assumer, et de transformer les idées initiales en produit fini. En un mot, de faire vivre le logiciel dont il a la charge.

Et dans votre service, vous côtoyez des codeurs ou des développeurs ?