DEV Community: Damien LG

Accroche philosophique dans le monde informatique.

Damien LG — Sat, 20 Dec 2025 08:00:00 +0000

Les ponts

Prenons comme définition simple de la philosophie la description suivante : "Ensemble des sciences et des disciplines ayant pour objet la connaissance rationnelle de la nature" 1.

La philosophie aujourd'hui ne se limite plus à quelques hommes barbus se demandant si la notion de vide a du sens, ni à deux trois chroniqueurs de plateau semblant pouvoir s'exprimer sur n'importe quel sujet n'importe quand.
La philosophie regroupe tout un ensemble de disciplines traitant de sujets tout aussi précis que variés. Que ça soit la philosophie de l'esprit, du langage, de la morale, politique ou encore des sciences, toutes ces branches travaillent à mettre en place des théories permettant de qualifier le plus justement possible le fonctionnement du monde et notre interaction avec.

Tout d'abord, il faut bien souligner que l'informatique se repose sur des concepts fondamentaux pour la philosophie occidentale que sont les mathématiques et la logique. Mais ce ne sont pas les deux seules disciplines que nous pouvons appréhender dans cet univers.
On peut déjà souligner qu'aujourd'hui l'informatique se déploie notamment sous formes de langages. PHP, Java, Rust, langage fonctionnel, langage objet, etc...

Mais qu'est-ce qu'un langage ? Qu'est-ce que permet et produit la notion de langage ? Quelles sont les règles qui permettent de catégoriser tel ensemble comme étant un langage ou non ? Quelles sont les typologies de langage ? Est-ce qu'il est correct de parler de "langage machine" ?

Au-delà de la terminologie, notre langage naturel et ses signifiants débordent sur le monde de l'informatique et son langage formel.
Le fait de nommer des composants "master/slave" ou "agent" n'est pas anodin: par leurs histoires, ces mots véhiculent un imaginaire et un certain ensemble de règles, de structures, de signifiants et d'organisations associés. Et si vous doutez de l'impact du langage sur nos structures, demandez-vous pourquoi nous sommes désormais tous des talents et non plus des employés ou des salariés.

Parce qu'au final la philosophie politique n'est pas très loin derrière. Quand nous soutenons l'open-source ou que nous mettons en place des licences restrictives, quand nous nous demandons qui a le droit de merger et sous quelles contraintes, quand nous définissons les responsabilités dans l'équipe, nous faisons de la politique.
L'organisation de la production informatique est effectivement politique au sens où l'on se demande qui est légitime à décider, qui est responsable de la production et comment nous nous organisons collectivement.

Bon, passons cette introduction ennuyeuse et allons chercher des cas plus concrets.

Le software craftmanship

Peut-on qualifier la production de code comme étant une forme d'art ?

Après tout, nous avons bien eu le courant du "software craftmanship" pouvant être traduit littéralement par "artisanat logiciel". Et lire le manifeste associé permet, à mon sens, de se rendre compte des réflexions à mener sur notre domaine et nos pratiques.

"Pas seulement des logiciels opérationnels, mais aussi des logiciels bien conçus"

Qu'est-ce qu'un logiciel bien conçu ? Pourquoi parle-t-on de qualité logicielle ? Est-ce que répondre aux exigences du métier est suffisant ? Est-ce qu'il faut un minimum de test ? Peut-on calculer de façon objective cette qualité ? Beaucoup de proposition existent pour rationaliser l'évaluation de la qualité logicielle et se basent sur des critères techniques et objectivables tels que la longueur des méthodes.

Dans ce cas à quoi servent les commentaires ? Pourquoi nous prenons nous la tête sur le nommage de variables ? Peut-être qu'une partie de la qualité de nos productions réside aussi dans sa qualité esthétique. Dans la manière dont nous avons rangé notre code, l'avons organisé et l'avons présenté pour que ceux qui passeront après nous (ou nous-mêmes) puissent s'y retrouver plus facilement.

Mais si on commence à parler d'esthétique est-on toujours dans l'objectivité ? On parle de beau et d'art, domaines où l'on amène souvent sa propre subjectivité. Ce qui ouvre tout un nouveau débat, mais limite pour le moment notre capacité à juger objectivement la bonne conception d'un logiciel.

Ou peut être que nos logiciels doivent être perçus comme des œuvres collectives, dont les qualités résideront dans leurs capacités à être comprises, appréhendées, transmises et à évoluer dans le temps.

"Pas seulement l'adaptation aux changements, mais aussi l'ajout constant de la valeur"

Aïe. La valeur. Vous savez calculer la valeur de votre code vous ?
Combien vaut votre commit ? Quelle est votre valeur ajoutée ? Quelle est la valeur d'un logiciel ?

Cette question ne concerne pas uniquement le code, mais est une vieille question de philosophie politique et économique. Est-ce que la valeur se détermine par l'échange ? C'est-à-dire, est-ce que la valeur de mon code réside seulement dans le prix que les gens sont prêts à payer pour ?

La notion de valeur est rapidement entendue en son sens marchand et contractuel, mais dans ce cas tout code produit dans une relation marchande aurait exclusivement la valeur qui lui est financièrement attribuée. Un code de "mauvaise qualité" pourrait donc valoir plus qu'un code de "bonne qualité".

Que faire de l'open source dans ce cas ? Que faire du code produit sur son temps libre ? N'a-t-il aucune valeur ? Où est-ce que sa valeur sera un reflet de l'effort mis dans sa production ? Un reflet de la force de travail engagé ?

Et de la valeur pour qui ? La question de la valeur de notre production technique peut et doit s'inscrire dans une réflexion plus générale sur le système de production. Nous ne pouvons pas extraire notre domaine du fonctionnement général de la société.

Pas seulement les individus et leurs interactions, mais aussi une communauté de professionnels

Alors comment définir le terme "professionnels" ? Dans le sens le plus simple, on pourrait dire que l'on est professionnel à partir du moment où l'on en tire un revenu de la pratique. En ce sens, il suffit d'être employé à produire du code pour en être un professionnel.

Mais est ce suffisant ? Nous avons souvent en tête une certaine de notion de compétence quand nous utilisons la notion de professionnel. Alors quelles sont les compétences d'un travailleur de l'informatique ? Comment pouvons-nous les qualifier ?

Cette question a été mise en exergue durant la période de fort recrutement et de très fort afflux de reconversions dans ce secteur. Les formations proposaient une reconversion dans des temps restreints et la question devient donc : quelles sont les compétences nécessaires ?

Qu'est-ce qui fait de nous des développeurs ?

Pas seulement la collaboration avec les clients, mais aussi des partenariats productifs.

Re Aïe. La productivité. Je ne vais pas m'étendre trop sur le sujet, car ça rejoint le point sur la valeur et parce que j'ai déjà eu l'occasion de m'exprimer sur ce sujet (BOUM, auto promo, je suis influenceur).

Profitons pour passer sur le sujet chaud du moment, Le sujet qui fait vibrer les foules et les porte-monnaies.

Les LLM

L'apparition et le développement rapide des LLM me semble être aujourd'hui l'exemple le plus frappant d'une incapacité collective à s'arrêter 30sc pour réfléchir aux termes que nous utilisons et aux implications de nos choix.

Les IA sont elles conscientes ? Nous avons tous un avis très tranché sur la question. "Évidemment que oui, certaines IA ont menti", "Évidemment que non, elles n'ont pas d'âme !".
Alors que nous ne savons même pas qualifier correctement la notion de conscience. Si l'on considère la conscience comme une propriété émergente de tout un ensemble de fonctions, alors, on pourrait dire que oui. On pourrait argumenter que les opérations internes effectuées par les LLM produisent des effets similaires à nos opérations internes d'humain. Dans ce cas à partir de combien d'effets identiques serions-nous capables d'attribuer la notion de conscience aux LLM ?

Ou alors, nous pouvons avoir une approche plus dualiste et proche de "l'élan de vie" qui dirait que nous, humains, avons un "p'tit truc en plus" qui fait de nous des êtres conscients, que cela est lié à la notion de vie et que l'on ne peut pas décemment attribuer de la conscience à des machines.

Alors si vous trouvez que la notion de bien-être animal est déjà compliquée parce qu'on leur attribue désormais une conscience, attendez qu'on se pose sérieusement la question pour des systèmes qui parle comme nous.

La question est similaire pour la notion d'intelligence. Ces sujets sont traités, étudiés et si ce terme peut être pertinent il est cependant nécessaire de correctement le définir au préalable. Car les termes que nous utilisons et leurs signifiants sous-jacents ne sont pas neutres et construisent notre rapport aux objets.

J'aimerais aussi évoquer le rapport à la connaissance. L'épistémologie est la branche de la philosophie s'intéressant à la connaissance et à la capacité de dire "je sais".
Jusqu'à peu, l'une des particularités de nos systèmes informatiques était leurs propriétés fortement déterministes. À savoir que pour chaque donnée entrante les opérations effectuées étaient les mêmes et que la sortie serait toujours la même ou a minima toujours prédictible. Ça ne veut pas dire que nous n'introduisons pas une forme d'aléatoire, mais que cette partie est restreinte à certains cas d'usages.

Ce que cela signifie, c'est aussi que sans savoir le fonctionnement interne de chacune de nos librairies, nous sommes en mesure de descendre dans la structure interne pour en étudier et comprendre le fonctionnement, en tout cas dans un monde tourné vers l'open-source. Ainsi, le travail et la compétence du développeur ne réside pas uniquement dans la production du code, mais aussi dans la connaissance et la compréhension du fonctionnement interne des outils qu'il manipule. Nous sommes capables de nous approprier les données entrantes, observer leurs parcours dans notre système et en comprendre la sortie produite grâce à son interaction avec ce système.

Il faut rester vigilant et ne pas idéaliser non plus le développeur comme une entité tout sachante et maîtrisant l'ensemble de la chaîne. Nous sommes faillibles, nous partageons la connaissance, prenons des raccourcis et nous organisons comme nous pouvons pour construire notre connaissance, la partager et la faire évoluer.

Les LLM transforment notre rapport à cette connaissance. Car deux fois le même appel avec les mêmes données peuvent produire deux résultats différents. Parce que nous avons des difficultés à analyser le fonctionnement interne ayant produit le résultat.

Nous nous mettons petit à petit à déléguer la connaissance aux LLM sans même interroger l'origine de leurs connaissances. Et si le LLM se trompe ? Est-ce que ça a seulement du sens de dire qu'un LLM se trompe ? Qui oriente les modèles ? Quelles sont leurs gestions ? D'où vient la donnée ?

Nous intégrons cette technologie fabuleuse à toute vitesse parce que "il n'y a pas le choix" en évacuant le processus démocratique et de réflexion nécessaire à l'intégration de ce type de technologie et leurs impacts considérables sur notre organisation sociale. Nous avons passé ces deux dernières décennies à travailler et sensibiliser sur la collecte de données, les usages et détournement qui en sont faits pour, du jour au lendemain, nous jeter collectivement dans les bras de ces mêmes entreprises et en leur offrant nos données sur un plateau d'argent quand elles ne viennent pas directement les récupérer sans poser de questions.

Si l'évolution des LLM est indéniable, si les LLM sont probablement des outils dont on commence à peine à appréhender les possibilités, il n'est pas nécessaire pour autant de tomber dans le mysticisme religieux.

Pour terminer et boucler avec le début de cet article, les Large Language Model sont, comme leur nom l'indique, des modèles de langage. Et si il vous semblait quelque peu folklorique de faire le parallèle entre langage et C++ je vous invite à reconsidérer cette pensée dans ce nouveau contexte.

Conclusion

La philosophie n'est pas qu'un moyen de se faire mousser à peu de frais et de paraître plus important que nous le sommes en citant des auteurs que nous ne comprenons pas. C'est un outil d'appréhension du réel et de mise en valeur des enjeux et implications de chaque possibilité d'interprétation.

Philosopher sur l'IA et l'informatique, c'est prendre ces sujets au sérieux. Comprendre leurs implications et la façon dont nous nous inscrivons dans cette chaîne. Que faire du travail quand le cœur de ces technologies est de nous en soulager ? Comment organiser ce système quand nous en faisons l'un des piliers du fonctionnement de notre société ?

Je ne suis pas philosophe et tout ce que je viens de dire doit être pris avec précaution, mais je suis un acteur, producteur du monde informatique et il me semble qu'il est de notre responsabilité d'utiliser notre compréhension de ces technologies pour proposer un débat public éclairé et constructif.

Si nous considérons vraiment ces technologies comme révolutionnaires, alors il nous faut penser la révolution.

Ressources diverses :

Alerte au productivisme: Trop c'est trop

Damien LG — Mon, 24 Feb 2025 17:11:32 +0000

Le productivisme est un système de pensée qui influence nos organisations depuis quelques siècles désormais. Il infuse aussi dans la production informatique et modèle nos pratiques. Nous allons voir ce qu'est le productivisme, son impact sur notre domaine et tenter d'évaluer certains risques qui peuvent y être associés.

Attention, cet article va utiliser des gros mots tel que "capitalisme", "idéologie", "décroissance" et autres mots épouvantails. L'objectif est de replacer l'informatique moderne et sa production dans un contexte socio-historique pour tenter d'en dégager une nouvelle approche. Charge à chacun d'appliquer un jugement moral, je tente de réserver le mien, celui d'un simple développeur web, pour la fin de cet article.

Comme toujours, cet article aura un prisme principalement européen et je n'ai aucune légitimité académique sur les questions historiques, politiques et philosophiques. Je traiterai essentiellement de la production informatique dans le cadre du développement web.

Lexique

Production: Bien et service valorisable issue d'une chaine de travail plus ou moins automatisé

Productivité: Rapport, en volume, entre une production et les ressources mises en œuvre pour l'obtenir.

Productivisme: Organisation centrée autour de la production et de la productivité.

Idéologie: Ensemble de représentations et interprétations du réel organisant le système de pensée.

Un peu d'histoire pour commencer

La productivité et la production ont toujours été un enjeu de nos civilisations modernes, en particulier autour des questions alimentaires et des biens essentiels. Être en mesure de produire au moins assez pour que tout le monde subvienne à ses besoins et puisse vivre dans un certain confort.

Mais produire assez pour atteindre ces objectifs était souvent suffisant et ne formait pas l'axe principal de l'organisation sociale, entre autre dû à une évolution technologique lente est un alignement de la production sur les cycles biologiques.

Pour être clair, cela ne signifie pas qu'il n'y a jamais eu de forme de productivisme dans la longue histoire. Certaines sociétés dans l'histoire ont pu très fortement valoriser la production, mais cela n'a pas été un système théorisé, généralisé et persistant comme aujourd'hui.

C'est autour du 19ᵉ siècle, de la révolution industrielle ainsi que l'essor du capitalisme que le modèle productiviste a été plus concrètement théorisé et appliqué comme matrice idéologique.

On a commencé à pouvoir aller plus vite, à créer, travailler, produire davantage, être toujours plus productif et vouloir l'être encore plus.

Les machines à vapeur deviennent plus efficientes. On stocke de plus en plus d'énergie dans moins en moins d'espace. Nous augmentons notre productivité technique et transformons notre environnement où nous nous libérons de ces contraintes. Un très bon exemple est celui de remembrement des espaces agricoles en France après la Seconde Guerre mondiale.

L'essor des tracteurs et de la mécanisation agricole ont amené à la modification des paysages et de la structure des champs.
Le paysage qui était majoritairement composé de petites parcelles multiples et multifonctions a été réorganisé, réarrangé et réassigné pour faciliter l'exploitation agricole. Transformant la terre en ensemble de grand champs plat sans bordure et sur-spécialisés. Cette méthode, dite productiviste, maximise les rendements de chaque parcelle à travers l'usage de la mécanique et de pesticides.

Cette transformation productiviste n'est pas uniquement technique, mais passe aussi par l'organisation du travail et des travailleurs. L'exemple le plus connu étant probablement le Taylorisme et son organisation scientifique du travail. Cette approche cherchant à identifier, décomposer, chronométrer l'ensemble des tâches qu'effectue un ouvrier, par exemple pour monter une voiture, afin d'optimiser autant que possible la chaine de production et maximiser la productivité.

Sujet évoqué dans le bien connu "Les temps moderne" de Chaplin où le personnage principal est un de ces ouvriers qui travaille à la chaine et dont on peut apercevoir certaines des conséquences.
L'organisation du travail a évolué depuis et pris différentes formes, mais la volonté productiviste reste bien présente. Même les méthodes actuelles de "bien être au travail" sont formulées et sont analysées sous le prisme de l'amélioration de la productivité. La question de la semaine de 4j est constamment mis en rapport des effets sur la productivité.

Tout ce que vous voulez tant que l'on ne baisse pas la productivité. Et si on l'augmente, c'est encore mieux.

La question du productivisme est donc un sujet qui se traduit autant technologiquement que socialement. Cette approche se retrouve tout au long des deux, trois derniers siècles dans différents contextes politiques comme l'Angleterre du 18ᵉ, les États-Unis du 19ᵉ, L'URSS stalinienne, la Chine Maoïste ou la France d'après-guerre.

Cette notion n'est donc pas spécifique à un courant politique, mais un rapport idéologique ayant plus ou moins d'affinité avec d'autres courants.

Il est bien de produire beaucoup, il est mieux de produire plus.

Et l'informatique dans tout ça ?

En premier lieu, on peut aborder l'aspect technique. Il est indéniable que l'informatique moderne a évolué à une vitesse absolument folle et les rendements, ne serait-ce qu'en termes de volume, ont évolué à une vitesse qui peut laisser pantois bien d'autres secteurs technologiques.

La révolution technologique de l'iPhone en 2007 qui pouvait contenir jusqu'à 16 Go de données, a été dépassé année après année avec des stockages allant jusqu'à 1 To de données aujourd'hui, soit 62 fois plus de données dans le même espace moins de 20 ans après.

Nous pouvons stocker davantage, calculer plus vite, transférer plus de donnée. De quelque 56K pour ceux qui le veulent dans les années 90, l'accès à fibre qui fait circuler des dizaine et dizaine de Gigaoctets par seconde est désormais un droit français auquel un propriétaire ne peut s'opposer.

Et nous voyons cette augmentation des flux dans notre travail.
Nous téléchargeons des dizaines et dizaines de dépendances, faisons circuler la donnée sans contraintes, faisant tourner des dizaines et des dizaines de pipelines, jobs, tests, de déploiements automatisés. Les limites sont désormais moins techniques que financières.

Ces dernières années et l'expansion de l'IA sous toutes ces formes ont mis en exergue ces questions d'efficience de nos usages, notamment énergétiques, et continueront probablement d'être les points majeurs d'attention sur les années qui arrivent.

J'aimerais tenter la comparaison entre le remembrement agricole évoqué plus haut avec la transformation du paysage informatique. À mon sens, le déplacement progressif des espaces de stockage et de calcul vers le cloud ont un effet similaire de transformation du paysage.
Les petits serveurs que l'on pouvait trouver dans un placard sont à présent tous centralisés aux seins d'immenses data-center dont le travail principal est bien la spécialisation de la gestion et la distribution de ces ressources de calcul et de stockage.

Et si on peut facilement voir ces évolutions technologiques et les gains de productions liés, il est important de regarder et de chercher les impacts dans l'organisation du travail. Existe-t-il un Taylorisme de la tech ?

Sans tomber dans la comparaison image à image, il me semble que l'on peut identifier certaines pratiques qui relèveraient d'une forme de productivisme.

Tout d'abord les cycles de productions. Le bien connu cycle en V, fonctionnant sur le temps long et où l'on retrouve déjà une découpe de l'activité productive en sous-catégories distincte. Cette pratique petit à petit remplacée par l'approche dite Scrum dont l'un des objectifs est de réduire les cycles de développement et d'apporter rapidement la valeur aux usagers.

On y retrouve le besoin d'évaluation permanente. À travers le découpage en unité fonctionnelle, que l'on va pouvoir chiffrer. Ensemble d'unités dont l'on pourra ensuite suivre le développement, tracer la vélocité et analyser son évolution dans le temps.

On pourra ensuite se retrouver en rétrospective pour identifier les points de blocage et trouver les solutions permettant de faire mieux. D'aller plus vite. De produire plus.

Et là où on pourrait m'opposer que ce sont uniquement des dérives et une perte de l'esprit Agile, il me semble pourtant que l'on peut retrouver cette approche productiviste dans le manifeste, rien que dans le premier principe : "Notre principale priorité est de satisfaire le client en livrant rapidement et régulièrement des solutions qui apportent de la valeur."

Ces changements de paysage et l'évolution des pratiques sont, tous comme le travail à la chaine et le remembrement, pas sans conséquences.

Impacts et critiques

Le productivisme est une approche que ses défenseurs justifient par l'augmentation de la production comme source principale d'une augmentation du niveau de vie et comme solution a tout un ensemble de problème.
Les enjeux énergétiques ne seraient qu'un problème d'efficience et de rendements. Plus de voitures produites, c'est plus de personnes qui peuvent y avoir accès. Une production agricole tournée autour du rendement, c'est l'accès à plus de nourriture pour plus de gens.

Une des premières critiques que l'on peut faire au productivisme est dans le calcul en lui-même.
Si l'on juge la qualité d'une organisation à sa capacité à sortir de plus en plus de voiture, on met de côté les impacts sur les ouvriers impactés.

Ne juger la qualité d'un projet informatique qu'à une notion productive va structurer l'organisation du projet en conséquence.

Si l'on ne juge la qualité d'une équipe technique qu'à sa disposition à sortir des fonctionnalités, on met probablement de côté tout un ensemble de pratiques permettant d'assurer la qualité qui me semble très bien imagée par la formule "Move fast and break things".

La façon dont nous évaluons une performance structure l'organisation permettant de répondre aux obligations de performance. Les indicateurs ne sont pas neutres et les choix des indicateurs le sont encore moins.

La deuxième critique que l'on pourrait émettre se situe au niveau de la consommation des ressources. Car une amélioration de l'efficience et de la productivité ne signifie pas mécaniquement une diminution de la consommation de ressources globale.

Illustrée par la notion d'effet rebond, l'augmentation de la productivité est majoritairement vue comme une possibilité d'augmenter la production et de produire encore davantage. À l'heure de la catastrophe climatique, l'usage des ressources est un enjeu qui devient de plus en plus présent.

Car notre production informatique a un coût. Chaque pipeline que nous faisons tourner, chaque test rejoué par manque d'attention, chaque outil et feature rajouté correspond à une consommation, à minima, de ressources énergétiques, si ce n'est de terre rare quand cela nécessite de nouveau serveurs et espaces de stockages.

La question de la production informatique est donc une question que l'on peut inscrire plus largement dans les courants idéologiques comme celui du productivisme (et ce n'est pas le seul).

Ces questions sont déjà abordées et commencent à être traitées à travers les notions d'éco-conceptions, de GreenIT ou de low-tech qui s'inscrivent dans la réflexion plus globale de décroissance. Est-on obligé de faire circuler plus de données ? Doit-on rajouter des fonctionnalités ? Peut-on en enlever ?

L'informatique est un espace social en interaction avec d'autres espaces. Ce qui veut dire que les questions actuelles, comme celle de la consommation de ressources, ne sont pas qu'une question technique. Ce sont des questions idéologiques, de rapports politiques à la production et de l'inscription du corps social dans cette production.

Et de la même façon que nous (re)découvrons les effets des transformations productivistes agricole sur la biodiversité, leurs impacts sur les sols et les risques à long terme qu'il nous reste encore à maitriser, il n'est pas sans risque que les pratiques que nous mettons en place dans notre milieu informatique entraînent des conséquences à long terme que nous avons encore du mal à évaluer.

Replacer l'informatique dans un contexte socio-historique, c'est redonner à notre production un sens sur lequel nous avons la main. C'est aborder, en tant que travailleur, notre production sous un angle potentiellement nouveau, contester des décisions et des pratiques qui nous semblent dommageables et s'organiser pour diriger notre travail dans la direction qui nous importe.

Ressources diverses

Une approche sociale de la notion de développeur

Damien LG — Wed, 18 Dec 2024 09:00:00 +0000

Une majeure partie de notre travail, à nous les développeurs, consiste à interagir et manipuler des abstractions et des représentations. Les logiciels que nous produisons sont des abstractions de tout un ensemble de portes logiques et de succession de 0 et de 1. Une partie de notre métier est passée à mettre en place des représentations (clients, paiements, utilisateurs...).

Il y a pourtant une abstraction que nous regardons assez peu, c'est le développeur. On a bien le mot, mais on ne sait jamais très bien quelle représentation se cache derrière.

J'ai déjà eu l'occasion de voir plusieurs ébauches de réponse. Majoritairement sous un angle technique. Quelles sont les technologies et les concepts à savoir ? Les nombre de lignes de code qu'on doit avoir écrit, les problèmes auxquels on a été confronté ou les patterns que l'on doit connaître ?

Je vous propose aujourd'hui une approche plus sociologique à travers la notion de groupe et d'identité sociale.

C'est-à-dire, est-ce que les développeurs forment une communauté dans laquelle les individus se reconnaissent et se sentent appartenir ? Existe-t-il un ensemble de règles et de codes définissant les interactions entre les membres de ce groupe ? Est-ce que cette identité a évolué avec le temps et quelles peuvent être les liens avec d'autres groupes ?

Disclaimer : je suis bien développeur et n'ai aucun diplôme dans les sciences sociales abordées. Qui plus est, cet article aura un prisme occidental voir européen. N'hésitez pas à consulter les sources et ressources fournies à la fin.

Un problème de mot

"Je suis développeur"

Voilà, c'est pratique. On voit à peu près tous ce que ça veut dire, même les personnes éloignées de l'informatique.

On pourrait presque appeler ça une prénotion, c'est-à-dire une notion partagée par tout un ensemble de personnes qui permet d'échanger sur une perception de la réalité sans être capable de définir exactement tout ce que ça recouvre. Un peu comme le mot travail.

On voit assez vite comme ce mot est limitant. Une fiche de poste se limite rarement à "Développeur". Dans ce milieu mouvant, on voit plein de qualificatifs et de notions parallèles apparaître et disparaître pour tenter de nous définir un peu plus précisément : Architecte, Développeur Web, Mobile, Embarqué, Sécurité, Ops, Base De Données, etc.

On connaît bien ça, les problèmes de nommages dans notre domaine. Tellement qu'on a une citation pour ça :

There are only two hard things in Computer Science: cache invalidation and naming things.

-- Phil Karlton

Mais malgré tous ces mots, le terme de "développeur" semble rester le plus largement accepté, partagé et le plus stable.

Et comme il faut bien commencer par être d'accord sur les mots, pour la suite, nous nous appuierons sur une définition de l'ONISEP:

Expert des langages informatiques, le développeur informatique traduit la demande d'un client en lignes de code informatique.

Alors, qu'est-ce donc qu'être un développeur ?

Des individus

"Je suis développeur"

"Je" est un individu avec des caractéristiques objectivables. "Je" est un homme entre 20 et 40 ans (majoritairement entre 20 et 30), dit de la "classe moyenne" avec un niveau d'éducation moyen équivalent à notre Licence française.

Quand je dis que "Je" est un homme, je veux dire à plus de 85%.

Si les développeurs forment un groupe social, alors celui-ci se superpose fortement à celui des hommes.

Le code produit est majoritairement un code d'homme. C'est-à-dire un code produit avec les biais et les projections de ce groupe social. Dont les logiciels ont déjà amené à des discriminations comme l'algorithme d'évaluation des CV d'Amazon qui sous-évaluait les profils de femmes.

La composition du groupe social et son lien avec d'autres groupes influence sa dynamique interne et ses productions. Si tous les développeurs étaient aveugles les règles d'accessibilité et le RGAA seraient peut-être mieux respectées.

À l'heure des discours sur l'inclusivité et de la diversité, c'est bien la composition de ce groupe qui est questionnée. Ce sont nos biais et nos évidences qui sont questionnées. Pas seulement pour le plaisir et par souci moral.

Mais parce que ce ne sont pas les cas nominaux qui nous posent soucis lorsque nous écrivons du code, ce sont les règles que nous n'avions pas vues. Celles qui étaient en dehors de nos regards ou de nos habitudes. Et il est bien plus difficile de voir les cas à la marge si tous ceux qui cherchent ne connaissent que les cas nominaux et ne sont jamais concernés par ces cas dit à la marge.

La question de la composition du groupe social que serait celui des développeurs est donc importante pour comprendre les dynamiques qui sont en place au sein de cet espace.

Et si aujourd'hui dire qu'un développeur est homme peut paraitre "évident", cela n'a pas toujours été le cas. Comme les mots, les profils ont évolué avec le temps. Si les premiers développeurs étaient plutôt des développeuses, l'histoire les a petit à petit remplacées.

Une histoire sociale

L'informatique moderne a un peu plus de 60 ans et en si peu de temps les "développeurs" ont déjà beaucoup changé. En premier lieu et le plus notable: les femmes ont disparu.

Initialement plutôt vu comme un domaine de secrétariat, l'informatique est désormais entrée dans le domaine de la recherche et des ingénieurs. En se légitimant et prenant une place de plus en plus cruciale dans les économies et les rapports géopolitiques, ce domaine, s'est transformé pour devenir un milieu de raison et de recherche.

Majoritaires lors de l'émergence de l'informatique, les femmes ont peu à peu disparues en même temps que l'informatique devenait une science reconnue et prestigieuse, passant de quasiment 50% des étudiant(e)s en informatique en 1978 à 10% en 2010 (on observe une légère remontée ces dernières années).

Puis avec les années 70-80 et l'intégration de l'informatique dans l'industrialisation et le business l'intérêt pour l'informatique continue d'évoluer. Ce n'est plus seulement une pratique de chercheurs ayant fait des études dans le secteur, mais cela devient une pratique de plus en plus accessible, que l'on retrouve dans les entreprises et dans les chaines de productions.

La démocratisation des ordinateurs personnels, son marketing orienté et son introduction dans les foyers va amener beaucoup de garçons à produire leurs premières lignes de code en suivant les livres dédiés à cela.

Il est d'ailleurs intéressant de voir le lien fort entre pratique du jeu vidéo et métier de développeur. Une explication historique pouvant être ces livres des années 80 qui listaient les instructions permettant d'écrire un jeu-vidéo.

L'émergence et le développement rapide d'internet a rendu abordable un nombre considérable de ressources permettant à toujours plus de monde d'écrire ses premières lignes de code sur les ordinateurs. Ordinateurs qui se retrouvent eux aussi dans plus en plus de foyer.

Moi le premier, j'ai pu m'appuyer sur des ressources comme (feu) LeSiteDuZero et autres tutoriels pour écrire mes premières lignes de C/C++ au début des années 2010.

La mise en avant récente de figure d'entrepreneur parti de rien et réussissant tout permet aussi de changer l'image du développeur, faisant reculer quelque peu l'image du nerd. Ces fluctuations de représentation sociale se traduisent aussi directement dans la pratique de notre travail et les réflexions sur notre pratique.

Car peut-être qu'avant tout, être développeur, c'est produire. Et ce dans plusieurs contextes différents.

Des pratiques et un travail

"Je suis développeur".

Cette phrase est couramment utilisée pour désigner un métier. Car c'est probablement l'effet le plus visible. La vente de notre force de travail, à savoir notre capacité à produire du code selon un ensemble d'exigence, dans un système économique qui va le valoriser et redistribuer une partie de la valeur générée.

Une partie de notre identité sociale de développeurs est liée à la notion de travail.

Plusieurs réflexions et "courants" vont naitre pour proposer des analyses et des approches. Des codes de conduite ou des pratiques de travail cherchant à définir notre rôle et notre manière d'interagir avec les autres acteurs.

Le cas du Software Craftsmanship est assez représentatif. "Artisanat du Logiciel". Ce mouvement, dont le manifeste a été publié en 2009, cherche à ramener la production de code du côté de l'art et de l'artisan et s'associer aux normes de ce domaine.

En sociologie la "Théorie de l'étiquetage" dit que les étiquettes posées sur un groupe ou un individu vont influencer la façon dont on perçoit ce groupe, mais aussi la façon dont ce groupe se perçoit lui-même et agit en conséquence.

Car ce n'est pas seulement une bataille de mot, mais bien de pratiques.

Et ces réflexions ne sont pas récentes, le livre "Le mythe du mois-homme" sorti en 1975 a fortement influencé le milieu du développement logiciel et proposait déjà une forme d'organisation du travail qui pourrait se rapprocher de celle du chirurgien dans un bloc opératoire.

Car le travail est aussi un enjeu d'image et de rapport de force. Montrer le travail et en valoriser des formes plutôt que d'autres. De trouver ce qu'est le "bon" travail et le "mauvais". Définir ce qu'est le "vrai" développeur.

Un groupe n'est pas toujours complétement homogène et des éléments peuvent se disputer pour faire prévaloir leur vision et la faire adopter par l'ensemble du groupe. Nous l'avons vu avant, l'identité d'un groupe n'est pas figée dans le temps et la construction de cette identité se fait aussi bien dans le cadre professionnel qu'en dehors.

En dehors du travail

Car être développeur semble aussi être une affaire privée. En tout cas selon le sondage IntelliJ de 2023, 70% des répondants codent le week-end pour le fun. D'ailleurs une des "exigences" de notre métier est la notion de "veille technologique".

Il est donc intéressant de voir quels sont les pratiques extra professionnelles, leurs porosités avec le monde du travail et notre perception du développeur. Car si coder c'est fun, quand est-ce que je code pour le travail, quand est-ce que je code pour moi ?

Est-ce que je dois coder chez moi pour être un développeur ?

Est-ce que le fait de rentrer chez moi et de continuer à travailler sur des projets personnels, regarder des conférences ou lire des articles est du travail ? Si ce n'est pas directement un travail, il serait malhonnête de dire que cela n'a pas d'influence. La personne qui rentre chez elle et continue de se renseigner et de coder reviendra le lendemain avec des connaissances supplémentaires qui pourront être valorisées au sein de l'entreprise ou pour se tenir à jour comme indépendant.

La personne rentrant chez elle et qui doit s'occuper de sa famille, qui est trop fatiguée ou ne veut juste pas continuer à coder sur son temps personnel pourra être désavantagé dans cette attente d'actualisation permanente de la connaissance.

Le fait qu'autant de gens continuent de coder ou de suivre l'actualité de ce domaine sur leurs temps libre rapproche notre pratique à de la "passion". À la manière de l'artisan que nous avons pu évoquer qui aime faire des poteries sur son temps libre et fini par en faire une activité économique, pour beaucoup de développeurs la frontière entre objet de travail et objet de passion ne semble pas être précise.

Une partie de l'identité sociale d'un développeur parait donc aussi se construire dans son rapport privé à la production de code. Dans la façon dont une des composantes principales de ce groupe, c'est-à-dire produire du code, peut s'exercer de façon transverse dans le domaine professionnel et le domaine privé ainsi que la façon dont on va produire ce code.

Toutes ces pratiques sont mises en avant, voire imposées par différents acteurs et contribuent à modeler la définition sociale du développeur à travers des processus que l'on pourrait qualifier de normatifs.

Un processus normatif

Nous connaissons assez bien ce processus. C'est l'ensemble des pratiques, institutions, conférences et autre stratégie qui définissent les pratiques et les manières de faire. Qui définissent ce que c'est d'être développeur et de développer.

Il existe tout un tas de conférences, de blogs et même d'influenceurs qui proposent des "bonnes pratiques". Parfois acceptées, parfois questionnées et parfois oubliées, ces propositions restent des stratégies qui ancrent une certaine forme de pratique et qui tentent de les faire accepter par l'ensemble du groupe social, comme cet article.

Comme vue plus haut, l'approche sous le prisme de l'artisanat est issue d'influenceurs de ce milieu qui ont mis en place un ensemble de règles, le manifeste, qui est diffusé et mis en avant à différents niveaux. Nous avons encore des articles et des conférences qui mettent en avant cette pratique et cette philosophie et qui veulent la diffuser et la faire accepter.

Cela passe aussi par des processus bien plus explicites et contraignants tels que les États. Car les états régulent assez directement nos pratiques de travail en imposant des contraintes comme le RGPD ou le RGAA. Ces questions qui n'ont absolument rien de technique ont un impact majeur sur notre milieu. Alors, nous ne sommes pas encore au niveau des médecins ou le fait même de pouvoir se définir comme médecin est directement cadré par un système d'ordre, mais des questions similaires pourraient émerger.

Les entreprises participent aussi à la normativité de la production. Un système valorisant la productivité et les bénéfices, dont une partie de l'organisation est centrée autour de la vitesse, impacte forcément notre travail et la manière dont nous pensons notre travail.
Nous parlons d'industrialisation du code, de déploiement continue ou d'Agile probablement pas parce que ces mots sont jolis, mais parce que les attentes et les exigences socio-économiques de ce domaine ont favorisé ce type d'évolution.

Le terme de dette technique que nous employons en permanence est né pour parler à une entreprise de la finance. Le point n'étant pas de discuter la pertinence ou l'usage de ce mot, mais de pointer que sa naissance même est issue d'un environnement social bien plus que technique.

Pour conclure ?

Il me semble donc pertinent d'approcher "les développeurs" à travers la notion de groupe social.
C'est un ensemble d'individus qui se reconnaît dans ce terme, dont une partie de l'identité sociale et travaillée par cette notion. C'est un groupe qui a sa propre histoire, ses propres dynamiques internes dont les règles et les pratiques sont issues de la promotion de certains acteurs ainsi que de processus normatifs forts et diffus.

Mais pourquoi parler de tout ça ?

En premier lieu, j'adore les sciences sociales. La philosophie et la sociologie sont deux outils très intéressants pour regarder le monde qui nous entoure et comprendre notre interaction avec lui.

Et parce que, comme dit en introduction, nous travaillons sur des abstractions et les abstractions que nous choisissons et manipulons ont désormais un impact conséquent sur le fonctionnement du monde. De l'argent peut être perdu, des retards provoqués et des vies misent en danger à cause du code que nous produisons.

Nos imaginaires sont façonnés par notre environnement et notre histoire sociale.
Nos biais et nos organisations économiques et politiques influencent directement notre travail et son évolution.

Les questions écologiques actuelles m'amènent à réfléchir sur le rapport entre l'informatique et la gestion des ressources. Comment une notion ancienne comme le productivisme peut se transposer sur notre pratique de travail et quels enjeux peuvent s'en dégager.

Car je pense que toutes ces questions sont importantes. Et que pour y répondre au mieux, il est nécessaire d'avoir une vision claire et complète sur notre milieu.

Comprendre d'où l'on vient est peut-être la meilleure façon de choisir où l'on va.

Cet article fait partie du "Advent of Tech 2024 Onepoint", une série d'articles tech publiés par Onepoint pour patienter jusqu'à Noël.
Voir tous les articles du Advent of Tech 2024 d'ici Noël.

Merci à Nicolas GAUTHIER pour la relecture.

Ressources diverses :

Autres production sur les sujets liés

onepoint au BDX/IO 2023

Damien LG — Fri, 01 Dec 2023 17:21:15 +0000

Instant promo

Pour cette édition 2023, onepoint était présent en nombre autour du plus beau stand de la journée (et ce n'est pas nous qui le disons!)

Mais en plus de ce rayonnement au sein de l'espace partagé, plusieurs collaborateurs ont pu rayonner avec leurs sujets tous plus captivant les uns que les autres.

Sylvain Métayer nous a expliqué comment automatiser l'installation de son poste de travail
Replay
Meidi Airouche est venu nous raconter le retour en force des évènements
Replay
Christophe Frézier tente de sauver la planète avec Qwik
Replay
Benjamin Legrand nous a permis de ressortir avec un nouveau clavier mécanique
Replay
Céline Mérand et Charline Humeau ont rendu accessible nos sites
Replay

Nos coups de coeur

Au dela des magnifiques conférences que nous avons pu proposer nous allons vous présenter quelques coups de coeurs de cette 8ème édition

Comment j'ai divisé le temps de calcul de mes traitements par 20 ?

Il s'agit d'un REX pédagogique sur la construction pas à pas d'une architecture répondant aux problématiques de performances, présenté par Morgan Renou.
La mise en place de chaque couche est expliquée et on comprend la finalité de chaque action, notamment grâce à des outils tels que DataFlow et Apache Beam.
Replay

Youpi dansons la Kapoeira

Je suis peu objectif sur cette conférence, car le binôme de conférenciers que sont Johanna Vauchel et Mehdi Rebiai a agrémenté sa présentation de situations liées à La cité de la peur.
J'ai apprécié la démarche de proposer un produit développé en interne à la communauté opensource. L'outil proposé permet d'implémenter les tests automatisées dans un environnement Kafka Stream, à la manière d'un Karaté.
Replay

Du Texte aux Failles : les vulnérabilités des applications avec IA Générative et LLMs

Autour de l'IA, les LLM sont à la mode ! La bonne humeur et l'histoire croustillante promis sont au rendez-vous. Paul Molin présente les différentes fonctionnalités. Les vulnérabilités et contre-mesures sont évoquées, mais cela aurait nécessité des exemples concrets pour bien comprendre le fonctionnement de ces vulnérabilités.
Replay

AGC, l'ordinateur qui a envoyé les premiers astronautes sur la lune

Magnifique présentation qui nous ramène aux années 60 et la course éffrénée entre l'URSS et les USA pour la conquête de l'espace. Durant 40mn Olivier PONCET et Romain Berthon nous font découvrir ou redécouvrir ce que fut l'informatique de l'époque, une chorégraphie de transistor, du code tressé à la main et des ressources limitées.
Replay

Kstreamplify: simplifiez vous la vie

Présenté par Clément Vacher de CGI et Sébastien Viale de Michelin, Kstreamplify permet d'accélérer et d'alléger nos développements KafkaStream. Tout cela est fait en rajoutant une couche d'abstraction sur toute les configurations classiques de DLQ et opérations de merge.
Replay

Serverless : Éviter le vendor locking en construisant sa propre plateforme FaaS avec OpenFaaS et Kubernetes

Une conférence présentée par Katia Himeur qui nous explique ce qu'est OpenFaaS: un framework open-source permettant d’implémenter une architecture serveless sur Kubernetes. On apprend à mon plus grand regret que le serverless utilise quand même des serveurs, et qu'OpenFaas peut être une alternative moins complexe que d'autres outils pour faire du FaaS, et qu'il permet de ne pas être dépendant d'un cloud provider. Replay

Nous attendons désormais avec impatience la prochaine édition pour pouvoir vous présenter de nouveaux sujets et en découvrir plein d'autres !