Coder n'est pas 'amusant', c'est complexe d'un point de vue technique et éthique

Programmer est un jeu d’enfant. Ou plutôt, c’est ce que veulent nous faire croire les gourous numériques du monde entier. De l’organisation à but non lucratif Code.org promettant que "Tout le monde peut apprendre" au PDG d’Apple Tim Cook affirmant qu’écrire du code est "amusant et interactif", l’art et la science de la création de logiciel est désormais aussi accessible que l’alphabet.

Malheureusement, ce portrait optimiste n’a aucun rapport avec la réalité. Pour commencer, la disposition mentale des programmeurs est assez exceptionnelle. En plus d’être très analytiques et créatifs, les développeurs nécessitent une concentration presque surhumaine pour gérer la complexité de leurs tâches. Une attention aux détails maniaque, la négligence est interdite. Atteindre ce niveau de concentration demande un état mental qu’on appelle être "dans la zone", une relation quasi-symbiotique entre l’humain et la machine, augmentant la performance et la motivation.

Coder n’est pas le seul travail demandant une concentration intense. Mais vous n’entendrez jamais quelqu’un dire que la neurochirurgie est "amusante", ou que l’ingénierie des structure est "facile". Quand on en vient à la programmation, pourquoi les décideurs et les technologistes font mine du contraire ? D’une, cela contribue à appâter les gens vers cette discipline à une époque où (selon les mots de l’investisseur et entrepreneur Marc Andreessen) le logiciel "est en train de manger le monde" – et ainsi, en agrandissant le bassin de main-d’œuvre, la machine continue à tourner et les salaires restent sous bon contrôle. Une autre raison est que le mot lui-même, "coder", sonne routinier et répétitif, comme s’il existait une sorte de clé que les développeurs appliquent par habitude pour résoudre n’importe quel problème donné. Le fait que Hollywood ait, dans sa typologie, entériné le prototype du "codeur" en tant que mésadapté social, hacker codant avant toute réflexion, inévitablement blanc et mâle, doué du pouvoir de repousser les Nazis ou d’inflitrer la CIA, n’aide pas.

Insister sur l’aspect glamour et amusant de la programmation est le mauvais moyen de familiariser les enfants avec l’informatique. C’est une insulte à leur intelligence et cela fait germer dans leur esprit l’idée pernicieuse que la rigueur n’est pas nécessaire pour progresser. Comme toute personne ayant été un minimum exposée à la conception de logiciels le sait, derrière chaque minute passée à coder se cache une heure de recherche.

Il est mieux d’admettre que la programmation est compliquée, d’un point de vue technique et éthique. À l’heure actuelle, les ordinateurs ne peuvent qu’exécuter des ordres, à différents niveaux de sophistication. C’est donc aux développeurs d’être précis : la machine fait ce vous lui dites, pas ce que vous vous imaginez. De plus en plus de "décisions" sont confiées à des logiciels, dont certaines qui sont des questions de vie ou de mort : pensez aux voitures autonomes, pensez aux armes semi-autonomes, pensez à Facebook et Google déduisant votre état civil, votre état psychologique et physique avant de les vendre au plus offrant. De plus, nous encourager à explorer ce qui se cache sous la surface de ces procédés est rarement dans l’intérêt des entreprises et gouvernements.

Tous ces scénarios sont construits sur des fondations extrêmement techniques. Mais nous ne pouvons pas y faire face en ne répondant qu’aux questions techniques. Programmer n’est pas un détail pouvant être laissé aux "techniciens" sous le fallacieux prétexte que leurs choix seront "scientifiquement neutres". Les sociétés sont trop complexes : l’algorithmique est politique. L’automatisation a déjà porté un sérieux coup à la sécurité de l’emploi des travailleurs peu qualifiés. Les cols blancs seront les prochains. Les géants numériques d’aujourd’hui fonctionnent avec une fraction des employés des géants industriels d’hier. L’ironie est que ceux-ci, en encourageant plus de gens à travailler dans la programmation, les pousse vers leur perte.

Dans un monde de plus en plus complexe et connecté, où le rôle que jouent les logiciels dans la vie quotidienne est de plus en plus important, il est irresponsable de présenter la programmation comme une activité légère. Le logiciel n’est ni de simples lignes de code, ni platement technique. Dans quelques années seulement, comprendre la programmation sera une part indispensable d’une citoyenneté active. L’idée que la programmation propose un chemin sans obstacle vers le progrès social et personnel ne bénéficie qu’à la techno-ploutocratie grandissante qui s’isole derrière leur propre technologie.



Traduit de l’anglais. Billet original de Walter Vannini, publié sur aeon sous licence CC BY ND. Source : https://aeon.co/ideas/coding-is-not-fun-it-s-technically-and-ethically-complex

26 commentaires

Disons que je développe une solution logicielle de DPI et que mes clients sont des pays peu démocratiques. Pourrait-on dire que l’outil lui-même est neutre, mais que mon travail ne l’est pas ? Est-ce que ça dépend de qui a in/directement financé ce travail et à quelles fins ?

Qu’est-ce qui dit que le logiciel a été prévu à la base pour un pays non démocratique ? Je me souviens de ce que faisait nohar, mais il n’est pas impossible qu’un projet de ce type soit prévu pour autre chose (un opérateur privé pour d’autres cas d’usage) pour ensuite être vendu à cet État en tant que client qui est intervenu après.

C’est d’ailleurs le souhait de beaucoup d’entreprises, de revendre une solution logicielle à d’autres clients qu’au premier commanditaire à moindre frais. Et rien n’empêche que dans le lot tu aies de bons et de mauvais clients.

Typiquement le noyau Linux et le chiffrement font des choses biens (en protégeant l’honnête citoyen du gouvernement) mais probablement mal (en aidant des criminels à exercer leur activité en douce). Faut-il jeter la pierre à leurs développeurs ?

J’ai d’ailleurs à titre d’exemple travaillé pour un client civil qu’est Airbus Helicopter sur une solution de vision nocturne qui pourrait avoir des applications militaires évidentes. Est-ce que mon travail est éthique ou pas ? Car en tout cas, mon premier client, permettrait de sauver des vies. Mais les suivants, c’est moins sûr.

Cette lib étant sous une licence particulière : Crockford avait pris une MIT mais y avait ajouté cette clause : “The Software shall be used for Good, not Evil.” Rendant ainsi son logiciel non-libre et provoquant son retrait des langages et distributions en question.

Une autre anecdote de ce style est le développeur de Notepad++ qui a ajouté une directive pour que les électeurs du FN ne l’utilisent pas car contraire à ses principes.

Mais la question est délicate, qu’est-ce que le bien ou le mal ? Pour certains le nucléaire civil est proche du mal absolu alors que ce n’est pas le cas pour d’autres. Si on se fit aux discours de certains, le chiffrement est mal aussi car cela aide les terroristes (et que nous avons rien à cacher) alors que cela permet le paiement en ligne et de se protéger du gouvernement (en particulier les journalistes ou autres). Pour beaucoup de gens une solution type DPI sert à faire le bien, quelque soit le pays qui l’utilise.

Pour beaucoup de gens impliqués dans le militaire, y travailler c’est le bien car ils ont la sensation de protéger leur pays, leur semblable. On peut dire que ce type de raisonnement est absurde, mais c’est pourtant ce qu’ils ressentent.

Bref, je pense un peu comme nohar, il est plus difficile qu’on ne le croit de catégoriser un travail comme éthique ou pas, cela dépend de beaucoup de facteurs qu’on ne maitrisent pas et aussi de notre propre opinion. Chacun a ses limites.

+1 -0

Disons que je développe une solution logicielle de DPI et que mes clients sont des pays peu démocratiques. Pourrait-on dire que l’outil lui-même est neutre, mais que mon travail ne l’est pas ? Est-ce que ça dépend de qui a in/directement financé ce travail et à quelles fins 

Et de qui l’a vendu. Et de ses motivations.

Ce qui est notoire, dans mon cas, c’est qu’à l’époque où c’est devenu public, je travaillais sur un produit dont l’intention et les clients-types étaient très différents (un système de DLM, donc l’inverse d’un NIDS, à savoir un système qui lance une alarme lorsqu’un document confidentiel sort de son enceinte sécurisée, donc plutôt destiné à des entreprises), mais construit sur la même codebase. Et je n’étais dans cette entreprise que depuis quelques mois.

L’autre détail intéressant que je peux préciser, c’est que même si je savais vaguement qu’il y avait eu un jour un contrat avec tel pays craignos, j’en ai appris le plus gros des détails, des tenants et des aboutissants (qui a vendu quoi et comment et dans quel contexte) dans la presse. À l’époque je me souviens d’avoir suggéré en blaguant d’écrire au média français qui était à l’épicentre du shitstorm pour leur demander s’ils pouvaient pas me renvoyer la doc du code…

Les années qui ont suivi, j’y suis resté dans l’espoir de voir des cas légitimes et des clients non-douteux utiliser ce système parce que je m’en sentais quand même responsable (et j’ai fini par en trouver plusieurs, heureusement), puis le contexte sur Internet a beaucoup évolué (quel site, quelle appli n’est pas chiffrée aujourd’hui ?), et les besoins et les pratiques ont évolué avec ce contexte pour s’y adapter et revenir dans un climat plus avouable, où la frontière éthique est manifestée par la barrière technique du chiffrement.

Au fond, aujourd’hui, 6 ou 7 ans plus tard, je ne peux plus vraiment décider du caractère éthique de ce soft.

+1 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte