Sur le métier de développeur de logiciels

L'activité de développement logiciel n'est pas une activité "immatérielle". Concrètement, l'activité principale du développeur de logiciels est la manipulation de bits d'information présents dans les machines auxquelles il accède. Il s'agit bien de modifier un état de la matière, donc un état du monde, de même qu'un menuisier, un écrivain, ou tout autre métier consistant à inscrire du sens ou une fonction dans la matière. Pour se convaincre de la matérialité de la matière manipulée, il suffit de penser à la consommation d'énergie par exemple de Google.

Le développeur ne fait pas ces modifications directement, à cause de l'échelle de taille d'une part, de la distance éventuelle entre lui et la matière modifiée d'autre part. Il utilise des outils, des machines, qui lui permettent de lire et écrire cette matière.

C'est en partie la complexité des machines à utiliser pour effectuer ce travail qui nécessite une formation d'"ingénieur" (encore que... cf. la conclusion). Par ailleurs, la matière manipulée, l'information, est discrète et se prête bien à la mathématisation des problèmes et procédés en jeu. Cet aspect scientifique de l'activité plaide également pour l'appellation d'"ingénieur".

Cependant, seule une petite partie de l'activité de développement relève de l'ingénierie. Une grande partie relève plutôt de l'artisanat, c'est-à-dire de traditions, de culture du développement, d'habitudes, d'expérience, d'acquisition et de transmission de savoir-faire.

Les deux aspects ne sont pas incompatibles. Dans la suite, je détaille en quoi le développeur de logiciels est ingénieur et en quoi il est artisan.

Enfin, une troisième figure sera convoquée, celle de l'amateur, pour ce qui concerne les motivations du développeur.

Un métier s'exerce toujours en adaptation à un milieu: milieu social, milieu culturel, milieu technique. Commençons donc par décrire le milieu dans lequel j'évolue.

Cette section ainsi que celle sur l'artisan sont basées principalement sur l'ouvrage de Jean-Claude Beaune, Philosophie des milieux techniques [1], chapitre 1, section 6: "Le mythe et l'utopie - L'artisan et l'ingénieur". L'auteur y compare ces deux figures des points de vue historique et culturel.

Plus loin:

Loin de son ancêtre l'"ingénieur militaire", qui menait des expérimentations scientifiques afin de tirer des règles à appliquer dans des solutions originales à des problèmes pratiques, le terme "ingénieur" aujourd'hui intègre en effet une forte dimension économique, notamment des tâches de gestion des ressources et des personnes pour mener à bien un projet. On pensera à la gestion de projet, aux planning prévisionnels découpés en tâches, toujours pour s'assurer que le travail sera fait dans le temps imparti, même si en pratique une grosse partie du travail ne peut être quantifiée à l'avance.

Le développeur, en tant qu'ingénieur, connaît aussi cette dérive économiste et gestionnaire qui tend à l'éloigner de la technique. Ainsi, l'engouement du management pour les "méthodes agiles" s'explique surtout du fait que ces méthodes sont censées permettre une meilleure gestion, une meilleure tenue des délais, une plus grande efficacité (voir à ce sujet un billet sur la prescription de rythme).

On retrouve également cette dérive dans les méthodes de génie logiciel découpant le développement d'un logiciel en plusieurs phases (comme dans le fameux cycle en V). L'ingénieur est alors un exécutant de méthodes établies sans lui. C'est lui qui s'adapte aux méthodes à appliquer, au lieu d'adopter ces méthodes en les adaptant à lui, à sa façon de travailler, à son contexte.

Pour développer un logiciel, l'aspect économiste poussera l'ingénieur non pas à réfléchir à une solution originale pour son problème et donc potentiellement à tout redévelopper, mais à d'abord s'intéresser à ce qui existe et qui peut être réutilisé rapidement, quitte à tordre un peu l'existant pour satisfaire ses contraintes fonctionnelles, ou diminuer ces dernières. Il n'est plus question de méthodes scientifiques pour trouver une solution, mais de compromis entre objectifs et moyens. Cette façon de procéder est devenue tellement naturelle qu'un ingénieur pourra être questionné sur les raisons qui l'ont fait développer une solution originale plutôt que réutiliser une "solution" existante. Au contraire, on mettra rarement en cause le choix d'un ingénieur ayant choisi d'utiliser une "solution" existante plutôt que d'en développer une nouvelle. (La pertinence de la solution choisie est une autre question.)¹

Mon propos n'est pas de condamner cette tournure économiste attachée à l'ingénieur d'aujourd'hui, mais seulement de la constater. Je ne dis pas qu'elle est à éviter, car la complexité des logiciels à développer rend nécessaire la réutilisation de solutions existantes.

On peut rapprocher cette problématique de la prolétarisation, c'est-à-dire la perte de savoir. Par exemple, en utilisant une machine à laver le linge, je gagne du temps pour faire autre chose que je n'aurais pas pu faire sans ce temps supplémentaire. En échange, j'ai perdu un savoir-faire, celui de laver le linge, c'est la machine qui le fait à ma place. Je peux accepter ce compromis si je considère que ce que j'ai à faire est plus important pour moi que continuer à savoir laver le linge à la main.

Si l'aspect économiste est utile pour développer certains logiciels, il peut également se révéler néfaste s'il est poussé trop loin, par exemple s'il en résulte des réutilisations de solutions moins coûteuses (en temps, en argent, ...) à court-terme mais non pertinentes à moyen terme, ou bien s'il entraîne une perte de maîtrise du logiciel avec pour conséquence des problèmes de maintenance.

Sur ce point, on peut remarquer que l'évolution actuelle du milieu de la recherche publique, de plus en plus organisée en projets courts, a un effet direct sur l'ingénieur en accentuant fortement sa dimension économiste. En effet, les logiciels participant de plus en plus à la recherche, soit comme moyens, soit comme résultats, leur temps de développement est de plus en plus contraint, appelant à des choix permettant un développement le plus rapide possible, rapidité qui n'est pas synonyme de qualité. Ce n'est qu'un exemple de plus des conséquences de la fameuse "compétitivité":

Enfin, dans un contexte de développement logiciel pour des équipes de recherche, les logiciels développés contiennent la plupart du temps des traitements originaux pour résoudre un problème, même si une grande partie d'un logiciel contient des aspects communs (interface graphique ou web, stockage de configuration, ...) pour lesquels des bibliothèques satisfaisantes existent. La dimension de recherche de solution originale à un problème est donc encore d'actualité dans ce type de logiciel, mais elle est souvent assurée par les chercheurs et non par les ingénieurs de développement.

C'est donc davantage l'agencement original de solutions existantes pour résoudre un problème qui occupe principalement les ingénieurs de développement. Cependant, il y a très peu de méthode scientifique dans cette activité d'agencement. Il s'agit surtout de composer avec l'existant. On pourra tout de même noter les réflexions nécessaires pour le passage à l'échelle et l'optimisation, qui, elles, peuvent relever d'une démarche scientifique, d'une modélisation pour comprendre un phénomène et trouver une solution pratique satisfaisante.

Une grande partie de l'activité de développement logiciel relève de l'artisanat, c'est-à-dire de pratiques transmises au sein d'une ou plusieurs communautés liées à des techniques ou technologies. Comme il y a des pratiques variées de la poterie, certaines distinctes et d'autres communes, il y a des pratiques variées, distinctes ou communes, de développement logiciel.

Certaines pratiques sont liées à des technologies, d'autres aux environnements culturels, ... La facilité d'échange apportée par le mouvement du logiciel libre et Internet a favorisé l'émergence d'une culture et de pratiques communes à grande échelle, parfois appelées "bonnes pratiques", telles des recommandations sur la longueur des identifiants selon leur portée. Jamais personne n'a effectué d'étude scientifique sur l'impact des longueurs d'identifiants sur la compréhension des programmes, mais cette pratique s'est installée avec le temps, en quelque sorte par sédimentation².

Des gestes deviennent habituels, comme l'utilisation de certaines structures de données dans certains cas, car plus rapides ou plus compactes, sans que le développeur ne fasse une étude scientifique de leur utilisation dans le cadre précis du logiciel développé. Ces structures sont satisfaisantes pour le traitement à effectuer. Par analogie, on pensera au couvreur qui sait choisir l'épaisseur des poutres à utiliser selon leur longueur et la charge à supporter. Il connaît et peut faire le calcul nécessaire, mais en général ce choix est dicté par l'expérience et l'habitude d'avoir fait ce choix plusieurs fois. Il en va de même des choix d'architectures logicielles par rapport aux contraintes, par exemple.

Ces automatismes sont d'ailleurs nécessaires pour progresser, en tant qu'ils permettent de se concentrer sur d'autres choses (on pourra à ce sujet lire le billet "Automatismes et cerveau"). Il serait bien difficile de développer sans tous ces automatismes: la moindre déclaration, le moindre identifiant seraient l'objet d'intenses réflexions comme si le développeur n'avait aucune expérience, sensation proche de celle que l'on éprouve lorsqu'on écrit ses premières lignes de codes dans un nouveau langage. Cette découverte est d'ailleurs un moment privilégié pour éclairer ses automatismes d'un nouveau jour, moment dont on ne profite pas assez mais que l'on peut heureusement renouveler régulièrement tant il existe de langages.

Le langage de programmation est rarement choisi en fonction de ses propriétés, bien plus souvent par rapport à la connaissance du développeur et son expérience, tant il existe de langages "généralistes". C'est l'habitude du développeur qui prime, et ce dernier travaillera mieux avec les outils qu'il connaît, surtout si l'aspect économiste de l'ingénieur lui impose des contraintes de temps.

Le développement logiciel, comme tout artisanat, possède en effet un langage technique dédié, que le débutant doit apprendre et utiliser pour comprendre et se faire comprendre. En l'occurrence, chaque technologie (et notamment chaque langage de programmation) possède également son propre langage créant des "sous-artisanats" avec leurs pratiques et leurs communautés culturelles.

La notion d'apprentissage long est présente dans tous les artisanats, et présente aussi dans le développement logiciel: Les débutants progressent au contact des "anciens", les développeurs expérimentés. Ils en copient les techniques, s'approprient et font évoluer leurs pratiques et les transmettront à leur tour. Le voyage initiatique original du compagnonnage est toujours possible, grâce à la facilité avec laquelle chacun peut contribuer à un ou plusieurs projets en utilisant Internet. On pensera par exemple à Github comme technologie permettant à l'apprenti et au compagnon d'apprendre au contact de maîtres dans plusieurs projets comme autant d'ateliers.

Cependant, encore faut-il que le développeur ait le temps et prenne le temps d'apprendre en allant voir le travail des autres.

Le "sens de la matière et de ses contraintes intimes" concernera pour le développeur la conscience des limites de la représentation d'information en temps et en espace, les possibilités de calcul et leur classe de complexité, la reconnaissance de motifs de problèmes déjà rencontrés, ...

Le développement logiciel comporte aussi sa notion de beauté, on parle notamment de "beau code". On pensera à l'esthétique fonctionnelle chez Leroy-Gourhan:

Enfin, le "secret" et l"'ésotérisme appliqués à son éducation et à son enseignement futur" font référence à la façon dont le maître enseigne à l'apprenti, en ne dévoilant son art que progressivement, en le distillant. Il y a également une notion de savoir tacite du maître qui ne se devine, parfois, qu'en observant ses gestes.

Ce point sur la transmission de savoir-faire est important car l'observation du résultat seul du travail du maître n'est pas forcément suffisante pour le comprendre. Un "travail ensemble" me semble nécessaire pour une réelle transmission de savoir-faire, pour que l'apprenti, par ses questions, permette au maître de formuler une partie de son savoir qui sinon resterait tacite. Une réflexion serait donc à mener par rapport aux pratiques de développement actuelles. Il s'agit en partie de cela dans le pair-programming.³

Egalement sur le thème de l'apprentissage, le développement logiciel n'échappe pas aux processus habituels de développement d'un savoir-faire et de mémorisation par la répétition des gestes. En effet, l'activité de développement est éminemment manuelle, par l'utilisation intensive du clavier. Il est évident que cette pratique intensive crée des automatismes et libèrent de l'attention pour la réflexion sur les problèmes à résoudre, de la même façon que l'entraînement à la lecture permet d'être attentif au fond, aux idées exprimées, plutôt qu'au déchiffrage des mots comme c'est le cas en début d'apprentissage ⁴. Sur l'importance des gestes dans le développement logiciel, on pourra lire ce billet.

La valeur de l'artisan ne se résume en effet pas à sa seule "valeur d'usage" même si cette dernière est la plus perceptible. L'artisan est également, surtout, porteur de culture, des évolutions de son métier, métier dont il hérite et qu'il transmet en y apportant des modifications. L'apport de l'artisan n'est donc pas seulement dans ce qu'il produit mais dans le rôle qu'il joue dans le processus d'élaboration continue de son métier. Ce point me semble complètement négligé actuellement.⁵

Cet oubli est flagrant notamment dans le discours et les méthodes de gestion qui résument les développeurs à des compétences techniques ou technologiques recherchées pour répondre à des besoins souvent ponctuels. C'est l'époque du développeur-outil interchangeable.

Ces quelques lignes illustrent combien le développement logiciel est une activité relevant de l'artisanat. On pourra continuer d'étudier cette activité selon différents angles: le rythme et la concentration, l'utilisation de la mètis, l'intuition et les sauts intuitifs, ...

On pourra lire cette page sur la figure de l'amateur.

L'amateur, au sens propre, n'est pas opposé au professionnel. Il n'est pas celui qui ferait du mauvais travail, celui qui ne serait pas sérieux. Au sens propre, l'amateur est celui qui aime, qui aime le savoir, qui aime apprendre:

Le développement d'un logiciel nécessite un investissement personnel. En effet, sans cet investissement de la part du développeur, le logiciel n'a pas d'avenir, pas de potentiel d'évolution. Seul l'attrait du développeur pour un horizon à atteindre et sans cesse reculant fournit au logiciel les capacités d'évolution pour tendre vers cet horizon, par des structures de données pouvant facilement s'étendre dans certaines directions, des contraintes d'architecture laissant ouvertes des chemins d'évolution choisis au détriment d'autres jugés peu intéressants. Bref, sans l'investissement personnel du développeur, ce qui devait être un logiciel ne restera qu'un programme. (sur cette distinction, lire ce billet, et sur ce que poursuit le développeur, une tentative dans ce billet)

Le développement logiciel est donc une affaire d'amateur, parce que l'investissement du développeur est nécessaire.

Cette figure est bien visible quand un développeur a envie de développer quelque chose pour le plaisir de chercher une solution a un problème, même si d'autres ont déjà apporté des solutions satisfaisantes. L'envie de se confronter à un problème, à une question, de chercher une solution, de comprendre. L'utilité, même si elle sert parfois de point de départ, n'est alors pas la seule motivation.

La motivation du développeur n'est pas très éloignée de celle du chercheur, comme on peut en avoir une idée en regardant cette vidéo:

On notera d'ailleurs que dans les deux cas, il n'est pas possible de connaître à l'avance le temps que prendra un développement ou une preuve, et pour cause: le chemin à parcoucir étant inconnu, on ignore sa longueur.

Une autre motivation, pas incompatible avec la première est le développement d'un logiciel en guise d'outil pour effectuer une autre action. Par exemple développer un logiciel permettant de gérer sa collection de photos ou autres. Dans ce cas cependant, le développeur ne s'investira pas autant dans le logiciel car ce qu'il poursuit concerne la gestion de sa collection de photos et pas le logiciel en lui-même et les problèmes à résoudre.

On peut remarquer que le principe économiste de l'ingénieur se retrouve naturellement appliqué selon l'intérêt que trouve le développeur: Si son intérêt est sur une partie précise du logiciel qu'il développe, il sera d'autant plus enclin à "économiser" du temps et des ressources en utilisant des solutions existantes pour les parties du logiciel qui l'intéressent moins.

De plus, l'impatience d'avancer vers la solution et la volonté de rester concentré, attentif, sur la recherche de la solution accentue également la délégation d'autres aspects du logiciel à des solutions existantes.

Enfin, pour en revenir au contexte du développement logiciel en support de la recherche, un partage de motivation entre l'ingénieur et le chercheur est nécessaire pour que les directions d'évolution du logiciel, découlant de l'intérêt du développeur, correspondent aux pistes de recherche futures envisagées par le chercheur. Cet intérêt partagé ne se déclare pas mais se construit au fil du travail commun de l'ingénieur et du chercheur, le travail de l'un remettant en cause le travail de l'autre, cette remise en question alimentant à son tour la motivation d'aller plus loin sur le chemin de la vérité.

Les figures de l'ingénieur, de l'artisan et de l'amateur se retrouvent toutes les trois chez le développeur de logiciels. Elles ne s'opposent pas mais doivent trouver un équilibre.

Ainsi, la tournure "économique" de l'ingénieur sert l'amateur en lui permettant de se consacrer aux parties qui l'intéresse le plus. Encore faut-il que la mission confiée à l'ingénieur soit en quelque sorte alignée sur le goût de l'amateur.

L'artisan, quant à lui, ne rechigne pas à utiliser des solutions et outils existants, tant qu'il lui reste la possibilité de les adapter à sa manière de travailler, à son rythme. Toujours l'artisan reconstruit des pratiques par dessus ses outils, et il peut faire du bon travail tant qu'il a cette lattitude et du temps, temps que lui refuse parfois l'ingénieur économiste pressé.

Une tension existe entre l'amateur, impatient d'avancer vers son horizon, et l'attrait de l'artisan pour le travail bien fait, le beau travail. Un équilibre entre ces deux figures apparaît lorsque le développeur fonctionne par passes sur son code: une première passe pour avancer vers une nouvelle fonctionnalité, en laissant de côté certains points pour rester focalisé sur le coeur du problème, une seconde passe pour corriger ces points. L'artisan aurait tort d'être idéaliste au point de trop frustrer l'amateur, même si un peu de frustration ne nuit pas.

L'amateur et l'artisan se retrouvent peut-être dans le sentiment d'avoir produit du beau, et même l'ingénieur n'en est pas loin lorsqu'il a le sentiment d'avoir accompli sa mission.

Concernant l'évolution du métier d'ingénieur de développement, on peut faire une analogie avec l'évolution d'autres activités, notamment l'évolution de métiers artisanaux remplacés par des chaînes automatisées de production. Le travail précédemment effectué par un artisan est réalisé par une machine, pilotée par un ingénieur, formé pour cela, appliquant des principes scientifiques généraux, notamment de rentabilité. L'ingénierie des modèles sera-t-elle une nouvelle forme d'automatisation d'un travail relativement artisanal actuellement, provoquant une nouvelle évolution du métier d'ingénieur, celui-ci devenant alors manipulateur de modèles et délégant à la machine une partie de l'activité actuelle des développeurs ? Le développeur actuel ne développe pas plusieurs exemplaires d'un même logiciel, puisque le numérique permet une copie à l'identique. Cependant, il réutilise plusieurs modèles d'architecture dans plusieurs logiciels.⁶

D'autre part, si l'apparition des ordinateurs a un temps nécessité de la formation pour leur usage, on peut se demander si cette formation à l'usage a évolué ou va évoluer, puisque les ordinateurs font partie du quotidien des digital natives. Il est clair qu'en terme d'usage, ces derniers auront peu de besoin en formation. Cependant, les études scientifiques préparant notamment aux capacités d'abstraction et de recherche d'algorithmes resteront nécessaires.

Par ailleurs, la question reste posée de savoir jusqu'à quel point un logiciel doit être développé par les équipes de recherche: jusqu'à sa distribution grand public ? seulement pour un usage interne ? Les situations varient d'un logiciel à l'autre, d'un domaine d'application à l'autre, d'une équipe à l'autre en fonction des motivations, du temps nécessaire, ... Cependant, la complexité grandissante des applications à développer pour appuyer une recherche de plus en plus poussée implique des temps de développement de plus en plus longs. Dans ce contexte, le développement de logiciels nécessite une vision à long terme de ces logiciels, et donc, mécaniquement, un investissement à long terme également de la part des développeurs. La seule figure de l'ingénieur n'y suffira pas, il convient donc de maintenir les conditions d'équilibre entre les figures d'ingénieur, d'artisan et d'amateur.