Usages

Qu’est-ce qu’un développeur ?

Publié le : Auteur: vhanniet 2 commentaires
usages

Qu’est-ce qu’on attend d’un développeur ?

Commençons par un peu d’étymologie. J’aime bien l’histoire du verbe développer présentée sur le site du CNRTL : « sortir (quelque chose, quelqu’un) de ce qui l’enveloppe », « débrouiller (un auteur, une affaire) compliqué », « étendre ce qui était roulé sur soi-même »,  « parcourir une certaine distance », « prendre de l’extension », « faire prendre toute sa croissance à », « exposer dans le détail ».

Le développeur est celui qui développe. La fonction d’un développeur est de concrétiser jusque dans les moindres détails une idée initiale, laquelle est éventuellement abstraite ou absconse. En informatique, il s’agit donc pour le développeur de mettre en production un logiciel qui va résoudre l’expression d’un besoin de logiciel formulée initialement par un demandeur. Appelons ce demandeur maître d’ouvrage, usuellement abrégé en MOA. Puisqu’on en est là, la définition de développeur présentée ici est en fait très large et correspond à celle de maître d’œuvre, usuellement abrégée en MOE. Quand on parle de développeur au sein d’une MOE on s’intéresse surtout aux participants qui écrivent du code. Dans la suite de ce billet on limite l’appellation développeur à celui qui écrit du code (mais il ne fait pas forcément que ça).

How_users_see_developers

Quelques remarques à ce stade :

  • Le cas où les rôles de MOA et de développeur, ou plus largement de MOE, sont tenus par la même personne est très rare. Sans changer les divers sujets de préoccupation cette situation a comme principale caractéristique de simplifier la communication entre les participants au projet ce qui est un avantage mais de résout pas tous les problèmes 😉
  • L’expression du besoin dont on parle ici inclus un besoin de logiciel puisque sinon le développeur n’aurait pas de rôle à jouer. En pratique une « expression de besoin » par une MOA comprend rarement uniquement des besoins de logiciel. L’expression de besoin est prise en charge dans le cadre d’un projet ou d’un ensemble de projets coordonnés appelé alors programme (à ne pas confondre avec « programme informatique » !)
  • Le travail de la MOE va jusqu’à la mise en production puisqu’avant ce stade le logiciel n’est pas exploitable et ne saurait donc pas répondre concrètement, matériellement, à la part de la demande qui concerne un logiciel.

Suite à ces définitions, deux questions peuvent venir à l’esprit :

  1. Tout ça est bien compliqué, ne peut-on pas directement parler du développeur ?
    Non justement ! Tout ça est certes un peu compliqué mais c’est la vraie vie. Et ce qu’on attend d’un développeur est notamment d’être connecté sur la vraie vie. Un développeur n’est pas quelqu’un qui écrit du code juste pour la satisfaction d’écrire du code qui lui plaît et d’une façon qui lui plaît. Il lui faut comprendre complètement ce qu’on attend de lui et où s’inscrit son rôle dans un projet.
  2. Finalement, où commence et où se termine le rôle d’un développeur dans un projet ?
    C’est une très bonne question à laquelle justement la suite de ce billet essaie de répondre 😉

Le rôle de développeur

Une MOA a exprimé un besoin : quand est-ce que le développeur peut commencer à coder ?
Une assez bonne illustration de la situation est donnée par Michel Volle : entre une expression de besoin initiale et une spécification codable il peut y avoir beaucoup de chemin à parcourir. Quelle que soit la démarche de développement (en V, agile, Test Driven Development, Model Driven Development, etc.) il va falloir :

  • Challenger le besoin pour le rendre cohérent, complet et priorisé
  • Le traduire en exigences implémentables et vérifiables
  • Concevoir la solution logicielle en tenant compte notamment de l’écosystème logiciel existant et de ses contraintes, cet écosystème englobant la plateforme d’exploitation et les données déjà en production

Ces 3 étapes seront traitées en bloc ou au fil de l’eau, formalisées ou pas, contractualisées ou pas, discutées ou pas, simultanément à l’écriture du code ou pas, mais elles sont indispensables avant de pouvoir écrire une ligne de code et la mettre en production. Le rôle de développeur se situe donc selon les contextes entre deux extrêmes :

  • A minima : le développeur reçoit en entrée des spécifications fonctionnelles et techniques détaillées et il produit en sortie du code conforme à son interprétation des spécifications et qu’il aura testé unitairement (le code compile et s’exécute conformément à l’attente du développeur)
  • Au maximum : le développeur joue le rôle de MOE et, outre les tâches a minima ci-dessus, aide la MOA à challenger son besoin et décrire ses exigences, conçoit la solution logicielle à intégrer au sein du système existant, la déploie et en gère l’exploitation

Les qualités pour être développeur

Quelles qualité devrait avoir un développeur ? Bien sûr ça dépend en partie de ce qu’on attend du développeur sur l’échelle entre les deux extrêmes donnés ci-dessus. En situation de « staffing » projet les critères qui reviennent régulièrement sont :

  • Autonomie, voir expertise, sur les technologies de l’écosystème logiciel du projet
  • Expérience dans le domaine « métier » de la MOA, voir intérêt marqué pour le métier des utilisateurs
  • Capacité à travailler en équipe, à poser des questions en cas de blocage

Ces critères sont corrects, même s’ils sont plus ou moins importants selon les contextes projets. Il est cependant amusant de remarquer qu’on cite rarement deux autres critères pourtant fondamentaux :

  • Capacité et motivation à concevoir, écrire et tester du code
  • Sens de l’engagement à faire aboutir une solution répondant à un besoin

Par ailleurs une idée prévalente en ce moment est qu’un développeur devrait être avant tout un être sociable et que la principale qualité de son code devrait être de pouvoir être facilement compréhensible. C’est pas idiot mais est-ce vraiment suffisant ?

Pour conclure

Mon opinion est qu’à la fin d’un cycle projet il faut disposer d’une application qui fonctionne et réponde aux attentes. Pour cela il faut qu’à un moment donné dans la séquence de travaux un développeur écrive du code qui soit en adéquation avec toutes les exigences qui le définissent. A la limite, s’il fallait réduire toute une équipe MOE à un seul rôle ce serait à coup sûr celui de développeur puisqu’aucun des autres rôles ne produit le code nécessaire pour répondre au besoin !
Les principales qualités d’un développeur sont donc de savoir écrire du code et de savoir comprendre ce que les demandeurs attendent de ce code. Si un développeur peut en outre faire son travail rapidement, avec une bonne traçabilité et une transparence des décisions d’implémentation qu’il prend, avec une bonne qualité de code dès la première livraison, alors sa productivité est très bonne.

Il est cependant dommage, en France notamment, que la rémunération des développeurs expérimentés soit rarement à la hauteur de leur contribution effective à la réussite des projets… ce qui incite parfois les meilleurs d’entre eux à aspirer à d’autres voies professionnelles.
Tiens, tant que j’y pense, et pour finir sur une note amusante, il y a un « serpent de mer » qui revient régulièrement et que j’ai déjà eu l’occasion de croiser. Certains pensent sincèrement que l’idéal serait que les utilisateurs puissent développer eux-même leurs applications et ainsi, pensent-ils, ils feraient l’économie de développeurs dont la valeur ajoutée business leur semble nulle (pour ne pas dire négative) et de délais interminables dus aux mésententes entre les utilisateurs et la MOE. C’est en règle générale bien sûr totalement idiot… mais pour s’en rendre compte il faut comprendre ce qu’est un logiciel. C’est un peu du même niveau que de penser que la principale caractéristique importante d’une voiture est sa couleur : c’en est une certes mais ce n’est pas la seule ! Et par ailleurs, du coup, on comprend mieux pourquoi parfois les expressions de besoin sont tellement farfelues vues d’un point de vue développeur informatique ;D