Peur des robots qui nous remplacent ? Pas forcément, mais comment vivre et travailler avec les robots ?Une des craintes fort répandues à propos de la robotisation consiste à envisager qu’un grand nombre de professions, et pas seulement parmi les moins qualifiées, pourraient être à court ou moyen terme remplacées par des robots, du moins des systèmes automatisés que les progrès relatifs de l’intelligence artificielle rendraient plus performants que les humains dans l’accomplissement de leurs tâches.

Nul n’ignore pour l’instant ce qui va survenir effectivement mais une chose est d’ores et déjà établie : les systèmes robotisés sont déjà là, et plutôt qu’être remplacés, pour l’instant les travailleurs les côtoient, entrent avec eux dans des interactions déjà problématiques. On lira par exemple ce témoignage sur la gestion des livreurs à vélo où le donneur d’ordres et donc de travail est un système informatique qui piste « ses » employés autant que les clients.

À une tout autre échelle, le géant Amazon impose déjà la présence de robots dans ses immenses entrepôts au sein du travail humain, et comme le développe le texte ci-dessous, ce sont les êtres humains qui y travaillent qui doivent s’efforcer de s’adapter à leur présence ! L’anthropologue qui signe l’article que nous avons traduit pour vous analyse ce que représente pour les humains la perte de leur latitude d’action, voire de leur liberté d’initiative, dans une environnement où les robots sont omniprésents.

Les pratiques de l’entreprise Amazon, détestables pour les conditions de travail, sont par ailleurs assez révélatrices d’une dérive qui nous mène peut-être à renoncer peu à peu à notre liberté, pour nous en remettre aux systèmes automatisés dans tous les instants de notre quotidien.

 

Article original : How much are we sacrificing for automation?

Traduction Framalang : salelodenouye, goofy

Que sommes-nous prêts à sacrifier pour l’automatisation ?

Par S. A. Applin

Ce que nous apprennent les entrepôts d’Amazon sur un monde où de plus en plus, que ce soit des choses ou des personnes, tout ce qu’il est possible de mesurer finit par être mesuré.

On a l’impression que pratiquement chaque semaine apparaît dans l’actualité une polémique (sinon davantage) autour d’Amazon. Dans les seules deux semaines dernières, il a été question de conversations transcrites et enregistrées avec Echo, d’employés d’Amazon qui protestent contre la faible détermination de leur entreprise au sujet du dérèglement climatique, des efforts de ladite entreprise pour prétendre que les risques liés à la reconnaissance faciale sont « peu significatifs », sans oublier les questions posées par la sénatrice Warren sur les impôts fédéraux de 0 dollar pour un profit de 10 milliards de dollars aux U.S.A. Une entreprise aussi gigantesque qu’Amazon, avec une envergure aussi large en termes de produits et de services, est constamment dans l’actualité. Et malheureusement pour elle, la plupart de ces nouvelles lui donnent l’image d’un manque de compassion, d’intérêt et de sollicitude pour le reste du monde au sens large, en particulier pour les humains qui travaillent pour elle.

Ce qui a retenu mon attention au cours des dernières semaines c’est le témoignage paru dans Vox  d’un employé dans un entrepôt, qui s’est plaint des températures qui y régnaient. Selon ce que Rashad Long a indiqué à la publication :

Il fait si chaud dans les troisième et quatrième étages que je transpire dans mes vêtements même s’il fait très froid dehors… Nous avons demandé à l’entreprise de nous fournir de l’air conditionné, mais on nous a indiqué que les robots ne peuvent travailler à basse température.

Alors que Long et d’autres sont impliqués dans des procès avec l’entreprise, et prennent des initiatives pour former un syndicat, les plus importantes plaintes des employés semblent être concentrées sur un seul point : Amazon a la réputation de traiter ses employés comme des robots.

Dans un rapport qui m’a été envoyé après la publication de cette histoire, Amazon contestait ce compte-rendu comme « totalement faux », prétendant que des systèmes et des équipes surveillent constamment les températures dans les centres de traitement des commandes. L’entreprise a indiqué qu’à la mi-décembre, la température moyenne du local où Long travaillait était de 71.04 degrés Fahrenheit (NDT : 21.68 °C).

Le porte-parole d’Amazon a déclaré : « Les collaborateurs d’Amazon sont le cœur et l’âme de nos activités. La sécurité de nos employés est notre première priorité et la santé de chacun de nos employés est évaluée au-delà de toute notion de productivité. Nous sommes fiers de nos conditions de travail sûres, de notre communication transparente et de notre industrie de pointe. »

 

Cependant, vu de l’extérieur, on a l’impression que les entrepôts Amazon mettent en scène le « taylorisme sauvage ». Comme je l’ai déjà écrit, le taylorisme est une théorie de la gestion de l’ingénierie développée au début du XX^e siècle et largement adoptée dans les domaines de la gestion et de l’ingénierie jusqu’à présent. Alors qu’à l’origine il était utilisé pour gérer les processus de fabrication et se concentrait sur l’efficacité de l’organisation, avec le temps, le taylorisme s’est intégré dans la culture d’ingénierie et de gestion. Avec l’avènement des outils de calcul pour la mesure quantitative et les métriques et le développement de l’apprentissage machine basé sur les mégadonnées développées par ces métriques, les entreprises dont Amazon, ont abordé une nouvelle phase que j’appellerais « l’analyse extrême des données », dans laquelle tout et quiconque peut être mesuré finit par l’être.

C’est un vrai problème. L’utilisation du comptage, des mesures et de la mise en œuvre des résultats de l’analyse extrême des données destinée à éclairer les décisions pour les êtres humains constitue une menace pour notre bien-être et se traduit par les témoignages dont on nous parle dans les entrepôts et d’autres parties de nos vies, où trop souvent des êtres humains renoncent à leurs initiatives d’action au profit des machines et algorithmes.

Environ 200 travailleurs d’Amazon se sont rassemblés devant leur lieu de travail dans le Minnesota le 18 décembre 2018 pour protester contre leurs conditions de travail qui comprennent le pistage des ordinateurs et l’obligation de travailler à grande vitesse, comme scanner un article toutes les 7 secondes.
[Photo : Fibonacci Blue, CC BY 2.0]

Malheureusement, après des décennies où s’est échafaudé ce système de quantification, une entreprise comme Amazon l’a presque intégré à son infrastructure et à sa culture. Il y a des raisons au taylorisme chez Amazon, et une grande partie est liée à ses embauches aux décisions prises par ses cadres en matière de gestion et de développement, et à l’impact de ces décisions sur les personnes qui doivent faire le travail nécessaire pour que ces processus fonctionnent réellement.

Dans un article que j’ai écrit en 2013 avec Michael D. Fischer, nous avons exploré l’idée que les processus étaient une forme de surveillance dans les organisations, en nous concentrant particulièrement sur le fait que lorsque la direction des organisations dicte des processus qui ne fonctionnent pas particulièrement bien pour les employés, ces derniers profitent de l’occasion pour développer des solutions de rechange, ou « agissements cachés ».

Chaque fois que nous utilisons un ordinateur, ou tout autre appareil du même type, nous perdons du pouvoir.

Notre pouvoir en tant qu’humains réside dans notre capacité à faire des choix parmi les options qui s’offrent à nous à un moment donné. La gamme des possibilités évolue avec le temps, mais en tant qu’humains, nous avons le choix. Notre pouvoir c’est la coopération. Nous perdons un peu de notre liberté de choix, quelqu’un d’autre aussi, mais nous pouvons tous les deux parvenir à un compromis efficace.

Chaque fois que nous utilisons un ordinateur, ou tout autre appareil du même type, nous perdons du pouvoir. Nous le faisons quand nous sommes assis ou debout pour utiliser un clavier, à la saisie, ou en cliquant, en faisant défiler, en cochant des cases, en déroulant des menus et en remplissant des données d’une manière telle que la machine puisse comprendre. Si nous ne le faisons pas de la façon dont la machine est conçue pour le traiter, nous cédons notre pouvoir, encore et toujours, pour qu’elle le fasse de façon à pouvoir recueillir les données nécessaires et nous fournir l’article que nous voulons, le service dont nous avons besoin ou la réponse que nous espérons. Les humains abandonnent. Pas les machines.

Lorsque l’action humaine est confrontée à une automatisation difficile à contrôler, il y a des problèmes, et dans des cas extrêmes, ces problèmes peuvent être fatals. L’un d’eux a été mentionné dans le cadre d’enquêtes sur les écrasements de deux Boeing 737 Max, qui se sont concentrées sur les interactions des pilotes avec un système automatisé conçu pour prévenir un décrochage. Alors que le monde continue d’automatiser les choses, les processus et les services, nous les humains sommes mis dans des situations où nous devons constamment nous adapter, car à l’heure actuelle, l’automatisation ne peut et ne veut pas coopérer avec nous au-delà de son répertoire d’actions préprogrammées. Ainsi, dans de nombreux cas, nous devons céder notre initiative et nos choix aux algorithmes ou aux robots, pour atteindre les résultats communs dont nous avons besoin.

Au fil du temps, les humains ont évolué vers le commerce et le troc selon une démarche de coopération, échangeant des ressources pour acquérir ce dont nous avons besoin pour survivre. Nous le faisons par le travail. Dans l’état du marché d’aujourd’hui, si nous sommes à la recherche d’un nouvel emploi, nous devons utiliser un ordinateur pour postuler à un poste affiché sur un site web. Nous devons renoncer à notre initiative personnelle pour utiliser l’ordinateur (nous ne pouvons plus appeler personne), où nous céderons ensuite à un logiciel qui n’est pas nécessairement conçu pour gérer l’enregistrement de notre expérience vécue particulière. Une fois que nous avons fait de notre mieux avec les formulaires, nous appuyons sur un bouton et espérons obtenir une réponse. Les algorithmes en arrière-plan, informés par le système de gestion et les développeurs, vont alors « nous trier », nous transformant en série de données qui sont ensuite évaluées et traitées statistiquement.

C’est seulement si nous passons à travers les filtres qu’une réponse automatisée nous parvient par un courriel (auquel nous ne pouvons pas répondre) pour nous informer du résultat. S’il est positif pour nous, un humain finira par nous contacter, nous demandant d’utiliser une méthode automatisée pour planifier un moment pour un appel, qui utilisera des scripts/processus/lignes directives narratives, qui nous demandent à nouveau de renoncer à notre initiative – même dans une conversation avec un autre humain, où il y a généralement plus de flexibilité. C’est épuisant.

Le coût humain de la « frugalité »

Une fois que les employés des entrepôts d’Amazon ont renoncé à leur liberté pour se plier au processus d’embauche et qu’ils sont embauchés, ils sont également obligés de céder leur liberté d’action dans leur travail. Alors que les employés de bureau cèdent à des partenaires algorithmiques sous forme de logiciels ou de procédures d’entreprises, les employés d’entrepôt cèdent leur liberté d’agir en acceptant les horaires décalés et en travaillant avec des partenaires robots au lieu de partenaires algorithmiques ou à leurs côtés sous forme de logiciels. Les risques pour l’intégrité physique sont beaucoup plus élevés quand on agit dans un entrepôt sans coopérer avec un robot qu’ils ne le sont si on ne coopère pas avec un logiciel dans un travail de bureau.

Un brevet déposé par Amazon en 2013, « Système et méthode de transport du personnel dans une environnement de travail industriel. »

Dans certains entrepôts et environnements industriels, les travailleurs doivent se soumettre aux robots parce que les robots sont rapides, faits de métal, et pourraient les blesser ou les tuer. De cette façon, un travailleur qui manœuvre autour d’un robot a moins d’emprise sur son corps au travail que ceux qui, dans les bureaux, prennent les décisions sur la façon dont ces travailleurs vont travailler.

Une solution proposée par Amazon en 2013 a été le brevet U.S. 9,280,157 B2, accordé en 2016. Ce brevet a été décrit comme un « dispositif de transport humain » pour un entrepôt, constitué d’une cage humaine. Une cage, c’est un symbole brutal. Bien que l’idée ait été de protéger les travailleurs humains contre les robots, elle n’a pas été perçue comme elle était probablement prévue. À l’extrême, une cage implique une fois de plus que les humains céderont leur capacité d’agir aux robots, ce qui semble donner raison aux plaintes initiales des magasiniers selon lesquelles les robots bénéficient d’un traitement préférentiel sur le lieu de travail chez Amazon

Amazon a insisté sur le fait que l’entreprise n’avait pas l’intention de mettre en œuvre cette idée. « Parfois même de mauvaises idées sont soumises pour des brevets, m’a dit un porte-parole d’Amazon, après la publication de cette histoire. Cela n’a jamais été utilisé et nous n’avons aucun plan d’utilisation. Nous avons développé une bien meilleure solution qui est un petit gilet que les associés peuvent porter et qui impose à tous les robots à proximité de s’immobiliser. »

Qu’il s’agisse d’une cage ou d’un gilet automatique, de toutes façons, ces interventions de sécurité soulèvent la question de savoir si une installation comme un centre de traitement d’Amazon pourrait être conçue de manière à ne pas obliger les humains à faire ces sacrifices frontaliers – tout en étant encore employés de façon rémunérée.

Fondamentalement, le taylorisme n’est pas forcément une question d’efficacité pour l’efficacité, mais d’économie de temps et, par association, d’argent. Parmi les « principes de leadership » d’Amazon, il y a la frugalité, et c’est cet aspect qui semble avoir dépassé leurs autres idéaux, car « faire plus avec moins » semble être le principe dominant dans la façon dont l’entreprise interagit avec tout, et comment cette interaction affecte ses employés et ses clients à travers le monde.

Si une entreprise pratique ce taylorisme dans l’ensemble de sa culture, des êtres humains vont prendre des décisions sur la façon dont d’autres humains doivent travailler ou interagir avec les systèmes d’une manière qui sera dans l’intérêt des métriques qu’ils servent. Si Amazon récompense la frugalité dans la gestion et la collecte de données sur la façon dont la direction gère (ce qu’elle fait), alors la direction va faire ce qu’elle peut pour maximiser les formes d’automatisation afin de rester pertinente dans l’organisation.

Ce principe particulier, couplé avec le taylorisme, crée l’environnement parfait pour que l’exploration et l’analyse de données deviennent délirantes, et pour que les processus qui ont un impact sur la vie réelle des gens soient ignorés. Ceux qui sont dans les bureaux ne voient pas ceux qui sont dans les entrepôts et ne peuvent pas se rendre compte que leurs indicateurs de rendement du service à la clientèle ou de la chaîne d’approvisionnement ont un coût humain. Dans une version extrême de ce qui se passe dans tant d’entreprises, les bénéfices sont liés à des mesures imbriquées dans la chaîne des parties prenantes. Les 10 milliards de dollars de bénéfices d’Amazon proviennent en partie de millions de minuscules décisions « frugales » influencées par le taylorisme, chacune payée au prix fort : la perte de la dignité et de latitude d’action des humains (ou des autres).

Le fait de céder continuellement à cette analyse extrême des données nous réduira à l’esclavage

Le taylorisme a été conçu et mis en œuvre à une époque où la fabrication était mécanique, et bien que certaines machines aient pu fonctionner plus rapidement que les humains, la plupart des processus qui ont eu un impact sur leur travail étaient analogiques, et au rythme du traitement humain. L’ouvrier de l’entrepôt d’Amazon se trouve au bout de la ligne de l’arbre de décision du taylorisme de la frugalité, et il est soumis à des processus algorithmiques qui contrôlent les données et les machines plus rapidement que de nombreux humains ne peuvent traiter l’information et encore moins agir physiquement sur elle. Ces travailleurs sont dépassés, à un degré inimaginable, mais liés par un mécanisme d’entreprise qui exige toujours plus d’eux et, plus important encore, de la chaîne qui les précède, qu’ils « qui fassent plus avec moins ».

Ainsi, à un moment donné, le fait de céder continuellement à cette analyse extrême des données nous réduira à l’esclavage. Non pas en restreignant nos bras et nos jambes (bien que cette cage d’Amazon s’en rapproche) mais en créant une vision du monde liée par des mesures quantitatives comme seule mesure justifiable. Le taylorisme a été utile dans un contexte manufacturier au début du siècle dernier. Il n’est plus utile ni approprié aujourd’hui, près d’un siècle plus tard, et son adoption continue crée de réels problèmes pour nous en tant que société mondiale.

Finalement, même avec le désir d’accomplir « plus avec moins », il y a un tel excès de « moins » que cela oblige les humains à être en tension et faire « plus », en épuisant leurs propres réserves internes. Si chaque processus est finalement automatisé et restreint l’action humaine, tout en exigeant simultanément notre servitude pour fonctionner, nous serons cloués au mur sans aucun choix, sans rien à donner et sans aucune alternative pour y faire face.

 

S. A. Applin, PhD, est une anthropologue dont le champ de recherche couvre les domaines du comportement humain, des algorithmes, de l’IA et de l’automatisation dans le contexte des systèmes sociaux et de la sociabilité. Pour en savoir plus :  http://sally.com/wiki @anthropunk et PoSR.org.

 

sur le même sujet

• un article de Radio Canada sur les pratiques de licenciement automatisées d’Amazon
• le site d’un syndicat britannique qui répertorie les contestations contre les conditions de travail chez Amazon

Ah c’est sûr, tout le monde n’a pas la chance de pouvoir refuser une telle opportunité… Quand on est développeur de haut niveau, c’est plus que flatteur de recevoir une invitation à discuter d’un poste de responsabilité chez le mastodonte du Net. Pour les milliers de développeurs qui sont bien payés à coder pour des produits qui ont des millions (voire des milliards ?) d’utilisateurs, il est assez exaltant de travailler pour Google.

Pourtant, quand Niklas reçoit un message l’invitant à rejoindre une équipe d’ingénieurs chez Google, il a le front de décliner, dans une lettre ouverte où il explique ses raisons.

C’est cet échange de courrier que nous avons traduit pour vous. Notez que cette fois-ci c’est Google qui est sur la sellette (parce qu’il le vaut bien) mais ce pourrait être tout autant un des autres géants du Net centralisateurs et prédateurs de nos données…

source : Why I won’t work for Google sur le blog de Niklas Femerstrand

Traduction Framalang : tetrakos, goofy, Paul, Framasky + 2 anonymes

Voici pourquoi je ne travaillerai pas pour Google

par Niklas Femerstrand

Bonjour Niklas,
Je m’appelle Patrick et je travaille chez Google.
J’ai regardé vos profils Github et LinkedIn, ainsi que votre site personnel (où j’ai découvert le projet panic_bcast), et j’aimerais m’entretenir avec vous à propos d’un certain nombre de postes d’ingénieurs ici chez Google.
Vos contributions et projets open source, votre expérience des systèmes et réseaux et votre expérience de développeur semblent en phase avec ce que font chez nous certains des ingénieurs, mais je souhaite avant tout prendre contact avec vous afin d’en savoir un peu plus sur votre travail.
Si votre emploi du temps le permet, seriez-vous disponible pour un échange la semaine prochaine ?
Les postes dont j’aurais aimé m’entretenir avec vous sont à pourvoir au sein d’une équipe chargée d’un projet sensible qui combine le développement de logiciels et l’expertise en ingénierie des réseaux et systèmes, pour créer et faire fonctionner à grande échelle une infrastructure à tolérance de pannes et des systèmes logiciels massivement distribués.
Merci de m’avoir consacré du temps, je vous souhaite un bon week-end !
Cordialement,
Patrick

Bonjour Patrick,
Merci de m’avoir contacté et pour les compliments sur le projet panic_bcast, c’est toujours flatteur d’être reconnu par plus grand que soi.
Avant de répondre comme il convient à votre question, je voudrais vous donner quelques indications sur mon parcours et mes relations avec Google.
Enfant, j’ai grandi avec l’idée que Google serait toujours l’employeur le plus intéressant que puissent imaginer ceux qui travaillent dans les technologies de l’information. Que Google se conformerait comme par jeu à sa devise « ne rien faire de mal ». J’ai grandi guidé par de fortes convictions et des principes, mais j’étais avant tout curieux par nature. Comme j’étais un enfant intéressé par la sécurité de l’information et les ordinateurs en général, j’ai rapidement commencé à analyser du code en le cassant et des systèmes en m’y introduisant, animé par l’idée que l’information voulait être libre.

Mon père s’en est vite rendu compte et nous avons eu une longue discussion sur ce qui est important dans la vie. Il m’a dit de ne pas être imprudent sinon le monde de demain consisterait en une tyrannie d’une part et des gens dépourvus de pouvoir de l’autre. Il m’a dit que, dans le futur, la répartition des pouvoirs dans le monde dépendrait beaucoup de ceux que je considère aujourd’hui comme des cypherpunks ou des hackers.
J’ai l’impression que l’avenir que mon père me décrivait quand j’étais enfant est aujourd’hui notre présent. Google dit « ne rien faire de mal » d’une part, mais de l’autre Google lit aussi le contenu des messages électroniques de ses utilisateurs et piste leur comportement sur Internet — deux choses que je décrirais clairement comme « le mal ». Google lit les courriels que ma mère écrit et piste ce que mes amis achètent. À des fins publicitaires, prétend Google… mais nous n’en avons découvert les véritables conséquences que plus tard, quand Edward Snowden a lancé l’alerte.
Il s’est avéré que Google avait aidé les services de renseignement américains et européens à pratiquer l’écoute électronique illégale de leurs propres citoyens. « Nous avons essayé de nous défendre, nous avons essayé de ne pas faire de mal », répond Google, mais on n’a jamais vu Google fermer un de ses services pour protester comme l’a fait Lavabit^[1].
On n’a jamais vu Google se battre pour le bien de ses utilisateurs, c’est-à-dire la majeure partie de la population du globe.
Nous avons vu Google justifier son espionnage des données en disant que c’était super en termes de stratégie publicitaire.
Nous avons appris que Google fait en réalité des choses très mauvaises pour la majorité de la population mondiale. Nous avons appris que Google a tendance à utiliser une épée à double tranchant. Nous avons appris que le principe « open source autant que possible » de Google ne s’applique que tant qu’il ne perturbe pas le chiffre d’affaires existant.
Nous avons été témoins du fait que Google a envoyé des lettres de mise en demeure^[2] aux développeurs et mainteneurs du projet populaire CyanogenMod pour Android pour avoir violé certains brevets en modifiant certains éléments open source d’un projet sous licence open source.
Nous avons appris que l’amitié cordiale de Google n’est qu’une façade publicitaire. Nous avons appris que Google n’est pas ce que nous pensions, qu’il ne se bat pas pour le bien de l’humanité mais pour le bien de son portefeuille.
C’est en cela que je me distingue de Google. Mes principes ne sont pas compatibles avec ceux que Google suit et a suivis tout au long de son histoire.
En vertu de mes principes, j’effacerais plutôt que collecterais toutes les données que Google, lui, rassemble sur ses utilisateurs, à savoir moi, ma famille, mes amis, mes collègues et toute personne dont Google sait qu’elle se connecte et a recours à des services populaires sur l’Internet public. Il me serait difficile de trouver le sommeil si je travaillais pour une entreprise qui cible les gens que j’aime et les menace directement.

Je me vois mal développer un jour les outils tyranniques indispensables à Google pour continuer sa course. Je suis de l’autre bord. J’ai conçu le projet que vous saluez, panic_bcast, pour que les services de sécurité aient davantage de difficultés à récolter des informations sur des militants politiques au moyen d’attaques du type « démarrage à froid ». Ce qui motive ma participation à d’autres projets de ce genre est ma conviction de la nécessité d’une circulation libre et sans contraintes de l’information sur l’Internet public.
Je fais partie de ces personnes assez chanceuses pour pouvoir se permettre de choisir les projets sur lesquels elles ont envie de travailler et je choisis de ne m’impliquer que dans des projets dont j’ai la conviction qu’ils apportent une contribution positive à la population dans le monde. Google n’occupe pas une place très élevée dans ma liste à cet égard et je suis au regret d’avoir à décliner votre proposition d’emploi.

« Les gens bien élevés ne lisent pas le courrier des autres »
— Henry L. Stimson

Je vous souhaite bonne chance dans votre recherche du candidat idéal.

Cordialement,
Niklas

Le travail intellectuel des programmeurs souffrirait-il d’un manque de visibilité et de reconnaissance aux yeux d’une logique managériale qui cherche à mesurer le travail effectif avec des critères dépassés ? C’est ce que laisse entendre ce témoignage qui au détour d’une plaisante anecdote met l’accent sur un relatif malaise d’une profession qu’il est difficile de cerner de l’extérieur, et même de l’intérieur d’une entreprise.

Are Your Programmers Working Hard, Or Are They Lazy? article paru sur le blog de l’auteur

Traduction Framalang : sinma, goofy, KoS

Vos programmeurs travaillent-ils dur, ou sont-ils fainéants ?

par Mike Hadlow

Quand quelqu’un effectue une tâche physique, il est facile d’évaluer à quel point il travaille dur. Vous pouvez le voir physiquement en mouvement et en transpiration. Vous pouvez aussi voir le résultat de son travail : le mur de briques s’élève, le trou dans le sol devient plus profond. Reconnaître et récompenser un dur labeur est un instinct assez fondamental chez l’être humain, c’est l’une des raisons pour lesquelles nous trouvons les sports d’endurance si fascinants. Cette reconnaissance d’un dur travail physique devient un problème quand on l’applique à la gestion de personnes qui travaillent à des activités techniques ou créatives. Souvent, les travailleurs intellectuels efficaces n’ont pas l’air de travailler très dur.

En 2004, j’étais développeur junior dans une grande équipe qui s’occupait du système de fourniture et de facturation d’une entreprise de télévision par câble. Comme tous les grands systèmes, il était constitué de plusieurs unités relativement indépendantes dont s’occupaient des personnes ou des équipes différentes. Les départements de TV analogiques et numériques étaient presque entièrement séparés, pris en charge par des équipes différentes.

L’équipe de la TV analogique avait décidé de fonder son système autour d’une pré-version de Microsoft Biztalk. Quatre gars de chez nous et une équipe de Microsoft le développaient et le faisaient tourner en production. Ils avaient tous l’air de travailler très dur. On les voyait souvent travailler tard dans la nuit et pendant le weekend.

Chacun laissait tomber ce qu’il était en train de faire si un problème survenait en production, ils se réunissaient souvent autour du bureau d’un type, faisaient des suggestions pour régler ce qui n’allait pas, ou pour réparer quelque chose. L’activité était permanente, et tout le monde pouvait voir non seulement qu’il y avait un véritable esprit d’équipe, mais que tout le monde travaillait très très dur.

L’équipe chargée de la TV numérique était tout à fait différente. Le code avait été, en majorité, écrit par une seule personne que l’on appellera Dave. Il était développeur de maintenance junior dans l’équipe. Au départ, j’ai eu beaucoup de difficultés à comprendre le code. Au lieu d’une seule longue procédure dans un endroit précis où tout le travail se serait effectué, il y avait des tas de petites classes et méthodes avec seulement quelques lignes de code. Plusieurs collègues se plaignirent que Dave rendait les choses extrêmement compliquées. Mais Dave me prit sous son aile et me conseilla de lire quelques livres sur la programmation orientée objet. Il m’apprit les patrons de conception, les principes SOLID, et les tests unitaires. Le code commença alors à avoir du sens, et plus je travaillais dessus plus j’appréciais l’élégance de sa conception. Il ne posait pas de problème en phase de production, il ronronnait dans son coin et faisait le boulot. Il était assez facile d’opérer des modifications dans le code, du coup l’implémentation de nouvelles fonctionnalités se faisait souvent sans aucun problème. Les tests unitaires permettaient de trouver la plupart des bugs avant la mise en production.

Le résultat de tout cela est que nous n’avions pas l’air de travailler très dur du tout. Je rentrais chez moi à 18h30, je ne travaillais jamais pendant les weekends, nous ne passions pas des heures attroupés autour du bureau de quelqu’un d’autre pour deviner le problème avec un quelconque système planté en production. De l’extérieur, notre tâche devait sembler beaucoup plus facile que celle des gens de la TV analogique. En vérité, les exigences étaient très similaires, mais nous avions un logiciel mieux conçu et implémenté, et une meilleure infrastructure de développement, notamment les tests unitaires.

La direction fit savoir que des augmentations seraient accordées sur la base de nos performances. Quand ce fut mon tour de parler au directeur, il expliqua qu’il était normal que les augmentations soient accordées à ceux qui travaillaient vraiment dur, et que l’entreprise ne semblait pas importer beaucoup à notre équipe, au contraire de ces héros qui lui consacraient leurs soirées et leurs weekends.

photo par nic’s events – CC BY-SA 2.0

Cette entreprise était l’un des rares laboratoires où l’on pouvait comparer directement les effets d’une bonne ou d’une mauvaise conception logicielle et le comportement d’une équipe. La plupart des organisations ne permettent pas une telle comparaison. Il est très difficile de dire si ce type, transpirant sang et eau, travaillant tard les soirs et weekends, constamment sur la brèche, fait preuve d’une grande volonté pour faire fonctionner un système vraiment très complexe, ou s’il est simplement nul. Sauf si vous pouvez vous permettre d’avoir deux ou plusieurs équipes concurrentes travaillant à résoudre le même problème, mais bon, personne ne fait ça, on ne saura donc jamais. Et au contraire, le type assis dans son coin, travaillant de 9 heures à 17 heures et qui semble passer beaucoup de temps à lire sur internet ? Est-il très compétent pour écrire un code stable et fiable, ou son boulot est-il plus facile que celui des autres ? Pour l’observateur moyen, le premier travaille vraiment dur, pas le second. Travailler dur c’est bien, la paresse c’est mal, n’est-ce pas ?

Je dirais qu’avoir l’air de travailler dur est souvent un signe d’échec. Le développement logiciel est souvent mal fait dans un environnement sous pression et dans lequel on est souvent interrompu. Ce n’est généralement pas une bonne idée de travailler de longues heures. Quelquefois, la meilleure façon de résoudre un problème est d’arrêter d’y penser, d’aller prendre l’air, ou encore mieux, de prendre une bonne nuit de sommeil et de laisser faire notre subconscient. Un de mes livres favoris est « A Mathematician’s Apology » (traduit sous le titre L’apologie d’un mathématicien) par G. H. Hardy, un des mathématiciens anglais les plus importants du XX^e siècle. Il y décrit sa routine : quelques heures de travail le matin suivies par un après-midi à regarder le cricket. Il dit qu’il est inutile et contre-productif d’effectuer un travail mental intensif plus de quatre heures par jour.

photo par sfllaw – CC BY-SA 2.0

J’aimerais dire aux manageurs de juger les gens en regardant leurs résultats, leurs logiciels qui tournent bien, et non en regardant si les programmeurs ont l’air de travailler dur. C’est contre-intuitif, mais il est sans doute préférable de ne pas vous assoir tout près de vos développeurs, vous pourrez ainsi avoir une meilleure idée de ce qu’ils ont produit, sans être affecté par des indicateurs conventionnels ou intuitifs. Le travail à distance est particulièrement bénéfique ; vous devez apprécier vos employés pour leur travail, plutôt que par la solution de facilité qui consiste à les regarder assis à leur bureau 8 heures par jour, martelant de façon lancinante sur leur IDE, ou se pressant autour du bureau des autres pour offrir des suggestions « utiles ».