Je suis un développeur. Cette phrase est une évidence désormais pour moi-même et mes collègues. Mais en quoi consiste la profession qui se cache derrière ce terme ? Cet article tente une définition du développeur, d’où qu’il vienne et où qu’il soit. Il exclut ceux qui sont passés du côté managérial de la force car ils n’ont plus le même métier.
Il est évident que le développeur est à classer dans le secteur tertiaire, selon la classification communément admise. Le développeur apporte une solution technique, majoritairement sous forme de code, c’est à dire de donnée (un traitement est une donnée), à partir de matière grise et d’outils informatiques. Son métier n’a aucun lien direct avec le monde des objets physiques. Il ne peut avoir un lien avec celui-ci qu’en contrôlant des objets électromécaniques ne faisant pas partie de son domaine de compétence propre. Il ne travaille que dans le monde du logiciel.
Le travail
Le travail du développeur est en 3 parties, souvent confiées à d’autres acteurs à mesure que les équipes grandissent :
- Il doit tout d’abord analyser et comprendre un problème. Parfois le problème doit être extrait des pensées confuses d’un non-technicien ce qui n’arrange rien. Heureusement le chef de projet a été inventé pour le dialogue client ! Si l’équipe ne travaille pas avec les méthodes agiles, un cahier des charges est produit puis validé par le client.
- Le développeur doit ensuite trouver une solution technique à un besoin et la traduire en code. Dans les équipes de taille réduite c’est le développeur qui découpe son travail lui-même. Plus la taille augmente, plus il est cantonné à une partie infime du tout.
Cette partie est le cœur nucléaire du développement (ou l’usine à gaz, c’est selon), l’analyse et la programmation sont la définition même du métier. Ici le développeur utilise son intelligence pour reproduire sous forme de traitements informatiques le comportement attendu dans les spécifications de la tâche qui lui est attribuée. Il utilise pour cela, des notions théoriques, son expérience mais aussi sa vision des choses et sa manière de penser.
- La troisième partie est la livraison : la solution technique doit être rendue disponible au client. Cette partie comprend l’installation, la documentation et la démonstration. Dans les équipes de taille supérieure, des personnes sont attribuées spécifiquement à cette tâche. Le débogage éventuel, qui suit cette phase, entre dans la même catégorie que la production technique initiale. Le bug est la conséquence d’une malfaçon (humainement normale ou non).
La formation initiale
La formation d’un développeur est assez hybride, entre une formation d’ingénierie et une formation artisanale. Très souvent, surtout en école privée, le développeur est également formé au management, en vue d’une évolution future vers des postes de ce type. Dès son premier jour de formation, souvent même avant, le futur développeur pratique la programmation. La conception n’est pas encore une préoccupation pour lui mais rapidement, par l’échec pratique et la formation théorique, l’apprenant va commencer à concevoir des systèmes de plus en plus complexes, réutilisables, interopérables et maintenables.
La virtualité du code détermine le mode de formation. C’est parce que coder n’a pas d’autre conséquence sur le monde réel que de consommer de l’énergie, que le développeur peut échouer et recommencer tant qu’il le souhaite, avant de rentrer dans le monde professionnel où son temps devient de l’argent.
Deux grands courants s’affrontent concernant l’instruction des développeurs : l’approche projet et l’approche magistrale.
Pour les tenants de l’approche projet, l’apprenant doit au cours de son cursus, mettre en application ses compétences dans des projets encadrés. Il sera noté à la fois sur ces projets et sur des compétences théoriques dispensées pendant des cours. Cette approche a l’avantage d’harmoniser le niveau technique d’une promotion, mais au prix de la créativité des plus entreprenants.
L’approche magistrale, elle, ne note que sur les compétences théoriques. Elle laisse à la curiosité des apprenants l’apprentissage pratique. Son inconvénient principal est d’avoir en sortie des niveaux assez disparates de compétences pratiques, variant selon la curiosité de chacun. Pour cela, elle se retrouve plus dans les facultés que dans le privé, qui souhaite maintenir une « cote » homogène à son diplôme.
La profession n’exclut pas les autodidactes, bien qu’ils puissent avoir plus de difficultés à entrer et à progresser dans l’univers de la grande entreprise.
La formation continue
La formation d’un développeur n’est jamais terminée. A moins qu’il ne travaille dans le seul entretien d’un existant sénescent (COBOL, vieux mainframes …), le développeur a le devoir de se tenir informé des nouvelles technologies du numérique en général. Le développeur étant souvent technophile (technocritique à minima) cette partie ne lui pose en général aucun problème.
La seconde obligation du développeur est de ne jamais arrêter son entraînement. A l’image des maîtres des anciens Métiers, il doit toujours être en recherche de l’amélioration. Le développeur est un véritable artisan : le seul moyen qu’il possède d’augmenter sa productivité est de s’améliorer lui-même, nulle machine ne peut remplacer l’essence de son métier qui est de concevoir (lorsque ce jour sera venu, il faudra sérieusement s’inquiéter).
Si le développeur doit tendre à la perfection individuelle, la même chose vaut pour l’équipe. La méthode utilisée, en revanche, diffère fondamentalement selon que l’on se trouve dans une petite équipe ou dans une équipe plus grande. Dans une petite équipe, l’amélioration se fera principalement par la discussion et la découverte de synergies entre les membres. Dans une équipe plus grande, il est impensable qu’un développeur connaisse bien tous ses collègues ! L’amélioration des performances devient une question organisationnelle dépendant de la hiérarchie. Elle passe souvent par une division du travail et une standardisation des environnements et méthodes. Le développeur a moins son mot à dire.
Les outils
Pour son travail le développeur utilise un ordinateur. Cela paraît idiot à dire mais mérite d’être dit car cela inclut deux choses : l’ordinateur comme interface physique (clavier, souris, écran(s)) et l’ordinateur comme plateforme logicielle. L’efficacité des deux influe sur la productivité du développeur.
Le développeur accomplit sa mission en utilisant un ou plusieurs langages de programmation. Ils sont traduits en langage machine par un compilateur ou un interpréteur. Très souvent, le développeur entoure cet outil fondamental d’une suite d’autres outils, qui constituent son environnement de développement. Dans les faits, la multitude des options de configuration permet de ne jamais trouver deux développeurs avec exactement le même environnement. Si, pour garantir la cohérence d’une équipe, certains outils doivent être partagés, la majeure partie est entièrement personnalisable. Même dans les équipes massives le développeur ne sera jamais complètement standardisé.
La productivité de l’environnement est un facteur majeur de productivité du développeur. Avec cet environnement il va produire du code de deux types : applications et modules. Les applications sont destinées à un usage précis et sont un agrégat de modules, cimentés par du code. Les modules sont, eux, destinés à être réutilisés dans plusieurs applications, ils peuvent être considérés comme des outils et comme des sous-produits.
Les modules sont un facteur crucial de la productivité d’une équipe de développeurs. Ils permettent de ne pas réinventer la roue à chaque fois, en posant des interfaces simples sur des procédures plus complexes. Ils ont également l’intérêt de factoriser le code : un module crée une fois peut être appelé dans plusieurs parties d’un code. Enfin, ils le remplacement aisé de parties d’un programme, en minimisant les changements à opérer sur le tout.
Rapport au travail et à l’emploi
Le développeur est un employé de bureau, qu’il travaille dans des locaux d’entreprise, chez lui ou bien en nomade. Son rapport à l’emploi est exactement le même que pour un employé de bureau classique et dépend fortement de la structure dans laquelle il choisit de travailler. Le poste et la mentalité d’un développeur change radicalement selon qu’il soit dans une PME ou une grosse structure. Son appréciation de son travail dépend principalement de la taille de l’équipe à laquelle il est intégré.
Un point cependant change fondamentalement par rapport à l’employé de bureau, point qu’il peut partager avec l’ingénieur ou le chercheur : Le rapport du développeur à son travail est essentiellement d’ordre artisanal. Le développeur s’identifie plus volontiers par ce qu’il fait, que par où il le fait. Chez le col blanc « classique » c’est l’entreprise et la position hiérarchique qui identifient la personne. Ce penchant artisanal se retrouve également dans les projets personnels, plus ou moins nombreux et achevés, que le développeur réalise en extra-professionnel, caractéristique que l’on retrouve chez certains artisans.
Un développeur travaillant en grande entreprise a tendance à faire partie d’équipes plus grandes, tenant souvent plus de la chaîne de montage que de l’équipe humaine. Cela n’est pas toujours vrai mais ça change le rapport qu’il peut avoir à son travail : en grande équipe il s’identifie plus par sa position, tel l’employé de bureau, que par ses réalisations. Le développeur qui ne travaille que sur une petite partie d’un tout sans en avoir forcément une vision d’ensemble, aura bien plus de mal à s’y reconnaître.
Le pouvoir
Le développeur est un technicien : c’est-à-dire qu’il est formé à des techniques auquel le commun des mortels ne comprend rien. Il a donc un ascendant sur l’utilisateur final non-technicien. Dans beaucoup de situations, le conseil est une obligation légale. Dans le reste des cas, c’est au développeur en son âme et conscience de décider quel degré de transparence, d’honnêteté et de pédagogie il appliquera.
Le technicien-développeur produit du code. Ce code n’est pas neutre : il impose à l’utilisateur la vision du commanditaire, déformée par le développeur. Lorsque les traitements dans l’entreprise sont entièrement manuels, l’empirisme et le ressenti produisent des méthodes de travail relativement souples, sauf ordres stricts de la direction. Lorsque l’on remplace l’humain par l’ordinateur il se produit une réduction de la créativité. L’ordinateur est aussi créatif que drôle. La créativité d’une équipe humaine est bridée par la rigidité de la machine. Si le développeur à le pouvoir d’assouplir et de rendre ergonomiques ses solutions, jamais il ne pourra s’empêcher d’imposer de la rigidité.
Le code n’est pas non plus sans conséquences économiques. En particulier le code de mauvaise qualité. La gravité économique de la sous-qualité dépend de deux facteurs : la criticité de l’application et l’ampleur des défauts. Le principe de Peter est fondamental lorsqu’il s’agit de manager des développeurs. Un mauvais développeur placé à un endroit stratégique peut couler, ou gravement handicaper, une entreprise. Mieux vaut pas d’outil informatique du tout, qu’un outil qui représente une perte de productivité à un poste donné. D’autant que le développement à un coût non-négligeable.
Conclusion
Le développeur est une sorte d’hybride entre deux tendances : l’artisan-codeur et le salarié du tertiaire. Le poids de chaque tendance varie selon le contexte de travail. Armé d’un ordinateur et de son cerveau, le développeur va, seul ou en équipe, bâtir les briques de la société de l’information, colonne vertébrale de nos sociétés post-industrielles. Tout, aujourd’hui, est informatisé. Si la technique informatique n’est pas neutre en elle-même, les traitements informatiques le sont encore moins car elles sont des œuvres humaines. L’humain derrière chaque application se trouve être un développeur, avec ses compétences, son éthique, sa vision du monde, sa manière de travailler et ses idées. Si ce qu’il réalise est soumis à des contraintes (contractuelles, physiques, informatiques), il joue néanmoins un rôle majeur dans la manière dont se dessine la société de demain, rôle proportionnel à la place qu’occupe l’informatique dans celle-ci.
