Licence CC BY-ND

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

Dernière mise à jour :
Auteur :
Catégories :
Temps de lecture estimé : 3 minutes

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

L’autre jour, avec des collègues, on réfléchissait justement à la pertinence d’un code déontologique en programmation comme il y en a (parfois plus en théorie qu’en pratique) dans certaines professions ; et de l’impact que ça pourrait avoir si c’était vraiment appliqué.

Ben c’est pas un sujet facile.

Bravo pour cet article très bien écrit, qui reflète parfaitement mon point de vue.

En tant que développeur, je suis effectivement sidéré par cette aberration à laquelle on veut faire croire le grand public. Non: ce n’est pas du tout "amusant" ni facilement abordable.

Coder est pour moi une vraie passion, qui demande toutes les qualités que tu énumères: disposition mentale, concentration, obsession du bug et aussi professionnalisme. Mais c’est tout sauf simple.

De même, est-ce amusant d’être écrivain, graphiste, architecte ou chirurgien ? Passionnant certes, mais certainement pas élémentaire et ludique.

Merci encore !

Édité par marsender

+1 -0

La difficulté exclut-elle l’amusement ? Vous avez quatre heures. Pour moi, ce n’est pas parce que c’est difficile que ce n’est pas amusant. Après, coder,comme beaucoup d’activités (neurochirurgie, plomberie, jeux vidéo…) ce n’est pas toujours amusant. Mais c’est ça qui fait l’intérêt, justement.

Édité par Olivier44

+9 -0

J’ai l’impression que marsender n’a pas compris que ce n’est pas toi l’auteur. Tu devrais mettre en haut, avant l’article dans une balise info, que ce n’est pas toi l’auteur.

Sinon, c’est vrai que aujourd’hui on fait croire à tout le monde que l’on peut programmer facilement, en fait c’est surtout que contrairement a l’ébénisterie, l’électronique, personne n’a besoin de racheter quelque chose pour commencer a programmer parce que tout le monde a un ordinateur.

Le problème c’est qu’on fait croire a ceux qui écrivent 2 lignes de code, ou un script, qu’ils savent coder.. Mais pour moi, comprendre la programmation est essentiel dans la vie de tout les jours. Et c’est un outil que tout le monde peut adapter a son échelle : script pour excel, programme pour arduino, etc..

Vive la science

+3 -0

Je suis pas d’accord avec tout: autant je confirme que programmer n’est pas aussi facile qu’une société ou un tutoriel ne le laisserai entendre (parce qu’il ne suffit pas d’apprendre les instructions, encore faut-il savoir les utiliser), autant je comprend que la rigueur est essentielle (encore que tout le monde à une définition différente de celle-ci), autant j’ai du mal à comprendre qu’on puisse dire que ce n’est pas amusant. Au delà des gens de Facebook ou Google, au delà des personnes qui programme des avions et des voitures, et qui je l’espère sont heureux de le faire, y’a des dizaines de milliers de personnes pour qui, je pense, la programmation est amusante (et j’en fait partie).

J’ai un peu l’impression que ce genre de texte est écrit par un programmeur un peu aigri qui vois débarquer les petits jeunes avec un à priori, un peu comme un critique de cinéma se sentirais outré de voir tout ces gens qui filment en portrait et postent leur vidéo sur Youtube. Je serai mauvaise langue, je dirais même qu’il se sens menacé (va savoir pourquoi) par cette jeunesse qui code "pour le plaisir" et qui ne comprend rien à ce qu’elle fait. Mais la rigueur, ça s’apprend, comme le reste. C’est pas en disant à un gosse que "lire, c’est difficile" qu’il va apprendre à lire. Au contraire, on commence par lui montrer que c’est amusant. Puis on lui montre comment le faire convenablement. Pareil dans d’autres domaines. Partir avec l’a priori que ça ne peut pas être présenté comme étant fun est pour moi une erreur.

En plus, c’est dénigrer tout les programmeurs "du dimanche", tout ces contributeurs anonymes sans spécialement de formation, mais qui essayent de contribuer aux logiciels (moi, par exemple), en leur disant que ça n’en vaut pas la peine et qu’une personne "à la disposition mentale (…) exceptionnelle" (cette phrase sonne en plus très élitiste) fera de toute façon mieux. Pour critiquer marsender, on ne peut peut être pas être chirurgien pour le plaisir, mais on peut très bien être graphiste et écrivain "pour le plaisir". Pareil, ce sont des domaines qui ont leurs propres codes, mais qui s’apprennent. Et d’ailleurs remplis de gens qui, de même, critiquent le travail des primo-arrivants, briment la créativité, et etc. Et moi, je crois sincèrement qu’avant de choisir un métier quel qu’il soit, il y a une histoire de passion, et une phase ou on fait n’importe quoi, parce que ça fait partie du processus d’apprentissage.

Ce texte n’a pas que du mauvais, en soit, il fait le constat que n’importe qui n’est pas capable de coder n’importe quoi, et heureusement. Mais ne laisse aucune chance à Kévin, 12 ans, qui code son premier "plus ou moins" parce qu’il rêve de coder un jeu vidéo. De toute façon, un script ou un programme mal codé à peu de chances de fonctionner, donc par processus de sélection, un programme va s’améliorer le cas échéant, et le programmeur apprendre de ces erreurs. Mais si on ce met à lui lâcher les spécifications du langage en mode argument d’autorité parce qu’il à utilisé des guillemets au lieux des apostrophes, ben on a rien gagné.

Édité par pierre_24

#JeSuisToujoursArius • Doctorant et assistant en chimiedev' à temps partiel (co-réalisateur ZEP-12, recherche et template LaTeX)

+16 -0

Ce que je comprends, et c’est un des points intéressants de ce billet, c’est pas que programmer n’est pas "amusant". C’est en effet très amusant. Pour d’autres personnes, aller à un stand de tir peut être très amusant.

Ce que je lis ici c’est que présenter la programmation (ou les armes à feu, d’ailleurs) comme quelque chose d’"amusant" en revanche n’est pas du tout une bonne idée.

Et ça c’est sans mentionner l’aspect éthique. Tous les gens que je connais qui travaillent sur des choses pas éthiques s’en fichent parce qu’ils s’amusent. Du genre "Oui je fais un outil permettant d’emprisonner les opposants politiques de mes clients mais techniquement c’est passionnant, je m’amuse bien."

Vous aimez le frontend ? Il y a un tas de petites tâches faciles si vous voulez contribuer à ZdS : https://github.com/zestedesavoir/zds-site/issues?q=is%3Aissue+is%3Aopen+label%3AC-Front

+5 -0

La difficulté exclut-elle l’amusement ? Vous avez quatre heures.

Olivier44

Justement, à mon sens, l’auteur nie moins l’aspect amusant de la programmation qu’il ne met en garde sur cette façon de ’vendre’ la programmation. En somme, son reproche aux "gourous numériques" (pour reprendre ses mots) est de limiter la programmation à quelque chose d’amusant, sans parler, ou sans parler assez, du reste (rigueur, concentration : ascèse en somme). C’est du moins ce que je retiens de l’article.

Après, la thèse même de l’auteur peut elle-même être discutée, comme l’indique pierre24 : n’est-ce pas simplement pédagogique d’insister sur les aspects positifs d’un chose à apprendre, pour donner justement envie d’apprendre ? Ou, reformulé : est-il possible à une personne d’embrasser les contraintes d’une discipline alors qu’elle ne les connaissait pas au moment d’aborder cette discipline ?
Après réflexion, je pense que oui. S’il est effectivement important de ne pas perdre de vue les contraintes de la programmation, qui sont inévitables, il faut également laisser le temps de les intégrer à ceux qui apprennent.

Et ça c’est sans mentionner l’aspect éthique. Tous les gens que je connais qui travaillent sur des choses pas éthiques s’en fichent parce qu’ils s’amusent. Du genre "Oui je fais un outil permettant d’emprisonner les opposants politiques de mes clients mais techniquement c’est passionnant, je m’amuse bien."

Ça ne m’amuse plus du tout.

Je suis d’accord sur le fond mais je suis assez partagé sur un point. Je pense qu’aujourd’hui il est important que les gens ai déjà une fois dans leur vie fait un petit script ou résolu un petit problème lié a la programmation. L’informatique contrôle tout aujourd’hui. Il est important, je pense, que les gens aient une idée même vague de ce qui se passe. Qu’ils comprennent que ce n’est pas de la magie noire qui affiche une photo de chat sur leur smartphone. De la même façon que dans les siècles précédents ont a cravaché pour que les gens soient alphabétisés, pour comprendre le monde, la presse, les lois, il faut aujourd’hui qu’ils aient un minimum de compréhension de comment l’informatique fonctionne. Rendre donc cet apprentissage ludique est donc je pense une bonne chose. Cela va faciliter cette compréhension. Tout comme à l’école on t’apprend l’alphabet et la lecture, au début, par les jeux alors que fondamentalement lire n’est pas amusant. C’est un moyen d’introduire à un domaine dont une connaissance minime va très vite devenir important dans nos sociétés.

+7 -0

@Kje, la moitié de ton message est ce que je comprends dans la phrase

Dans quelques années seulement, comprendre la programmation sera une part indispensable d’une citoyenneté active.

de l’auteur.

Quant à l’autre moitié, au risque d’insister, ma compréhension et mon avis rejoignant le billet est que oui, c’est amusant, non, il ne faut pas propager à tout va l’idée que c’est pas un boulot sérieux ou que c’est une discipline principalement amusante.

Je vais reprendre l’exemple que j’ai vu plus d’une fois ici : la lecture. Est-ce que d’après les médias, d’après les écrivains, d’après les profs, d’après l’avis de M. et Mme. Michu, la lecture est une activité amusante ? Ou si on leur posait la question ils répondraient à l’inverse que c’est un outil indispensable à leur vie quotidienne et que c’est quelque chose d’aussi crucial que sérieux ?

Prendre la programmation au sérieux, ne pas trop la présenter comme une "chose amusante", c’est sur ça que l’auteur insiste. Proposer de l’enseigner aux enfants de manière ludique n’est pas un contre-argument, vraiment pas.

On peut enseigner la lecture aux enfants de manière ludique sans leur dire : "Tu apprends à lire parce que c’est amusant". Je dirais plutôt à ses gosses : "La lecture est un outil extrêmement important, apprenons-la en s’amusant." Ce qui est très différent de "Voici comment faire tourner un ballon sur ton nez, c’est très amusant."


Je crois que c’est un faux débat, cette question d’enseignement et cet exemple de lecture. Ce qu’on peut apprendre en s’amusant peut être sérieux. Ce qui est amusant à apprendre n’est pas nécessairement pas sérieux. Donner l’image de "chose amusante" à un truc sérieux n’est pas une bonne idée. Donner une image sérieuse à une chose sérieuse n’empêche pas de l’enseigner de façon ludique.

Édité par cepus

Vous aimez le frontend ? Il y a un tas de petites tâches faciles si vous voulez contribuer à ZdS : https://github.com/zestedesavoir/zds-site/issues?q=is%3Aissue+is%3Aopen+label%3AC-Front

+1 -0

@victor: si ce qu’il faut en comprendre est ce que tu dis, alors on a droit à un texte d’une personne qui ne se sens pas considérée à sa juste valeur mais qui l’exprime très (très!) maladroitement. Et là (si c’est ça que l’auteur cherche, évidement), je suis à peu près d’accord pour dire que les métiers de l’informatique sont très mal considérés parce que incompris. MAIS je suis pas d’accord que la solution doit être uniquement de présenter la chose comme "d’admettre que la programmation est compliquée". Dans ma tête, ça rend la chose élitiste et inaccessible au commun des mortels, au contraire. Par contre, je ne remet absolument pas en cause la difficulté éthique que la programmation peut présenter, pour y avoir été confronté. Comme les armes à feux, d’ailleurs, pour lesquelles il y a une différence entre aller tirer sur des cibles le dimanche et se promener avec son arme en public parce qu’on est policier. Non, en effet, c’est par "marrant". Ça s’appelle avoir des responsabilités, et encore une fois, ça s’apprend.

EDIT: en fait, il faut lire le billet en remplacant le terme "programmation" par "métier de programmeur" et ça prend tout de suite plus sens.

Édité par pierre_24

#JeSuisToujoursArius • Doctorant et assistant en chimiedev' à temps partiel (co-réalisateur ZEP-12, recherche et template LaTeX)

+0 -0

J’ai l’impression que marsender n’a pas compris que ce n’est pas toi l’auteur. Tu devrais mettre en haut, avant l’article dans une balise info, que ce n’est pas toi l’auteur.

En effet ! Merci.

+1 -0

Et ça c’est sans mentionner l’aspect éthique. Tous les gens que je connais qui travaillent sur des choses pas éthiques s’en fichent parce qu’ils s’amusent. Du genre "Oui je fais un outil permettant d’emprisonner les opposants politiques de mes clients mais techniquement c’est passionnant, je m’amuse bien."

Hmm je fais partie des gens qui ont bossé pour le côté obscur de la Force et cette citation revient un peu à résumer les choses à coup de hachoir.

D’abord, je suis d’accord que ce n’est pas l’amusement lui-même qui pousse à se passionner pour le développement. Ou bien peut-être cet "amusement" désigne en réalité la satisfaction de faire quelque chose de compliqué qui fonctionne. De relever des défis techniques, architecturaux ou organisationnels, mais avant tout des défis personnels.

Cette poursuite de défis n’occulte pas l’aspect éthique, mais elle peut le contrebalancer lorsqu’un développeur examine sa situation et répond à cette question qu’il se pose, inévitablement et de façon récurrente : est-ce que mon job me coûte plus qu’il ne m’apporte ?

Est-ce que ce que je suis en train d’accomplir, techniquement, personnellement, et d’apporter au monde, vaut le coup d’avoir du mal à me regarder dans une glace le matin en pensant à la façon dont mon travail a été utilisé ?

Si la réponse est "oui", alors c’est un "oui" grave et sérieux, peu importe si la réponse publique qu’ils font est désinvolte, du style "Je travaille dans les droits de l’Homme" (c’est un mécanisme de défense : faire semblant d’en rire pour repousser la question de l’acceptation de soi).

Et il n’y a rien d’amusant là dedans. Ça peut même devenir très lourd à porter quand les années s’accumulent. Ce n’est rien d’autre que la double-pensée que décrivait Orwell, et la dissonnance cognitive qui vient avec n’est pas à prendre à la légère.

Édité par nohar

I was a llama before it was cool

+6 -0

Merci pour la traduction.

J’ai bien aimé ce tweet de Thomas Pesquet, qui parle là d’une expérience scientifique, mêlée avec "du code".

J’ai trouvé la tournure excellente.

Il n’a pas insisté sur le côté amusant de l’expérience (pourtant franchement, c’est fun d’écrire du code qui va tourner dans l’ISS, non ? ;) ) mais sur l’aspect "précieux" de cette compétence.

Je partage le point de vue de l’auteur sur beaucoup de sujets, pas tous, mais beaucoup. Surtout le fait que décrire le fait de coder comme "amusant" pour en faire un argument de vente soit assez dangereux.

Oui je prends du plaisir à coder comme beaucoup d’entre vous, je dirais même, quand je ne fabrique pas des trucs (un soft, un écran, un algo, un test qui passe au vert, un framework qui va servir à des gens) je suis malheureux. C’est un fait.

Faire des expériences scientifiques aussi ça m’a toujours beaucoup amusé. Pourtant la première chose qu’on m’a appris, même en petite section, c’est d’essayer d’y appliquer une certaine rigueur dans l’analyse des résultats. Et ce, depuis que j’ai posé la langue sur les languettes d’une pile plate.

EDIT: en fait, il faut lire le billet en remplacant le terme "programmation" par "métier de programmeur" et ça prend tout de suite plus sens.

Non, pas d’accord. Tu peux parfaitement, sur ton temps libre, créer un logiciel, une bibliothèque, un algorithme, tout à fait nuisible.

Et nuisible peut prendre énormément de sens :

  • Le plus évident, bien sûr, c’est nuisible à la société : un malware, un logiciel d’espionnage, d’attaque, etc.

  • Moins évident : un logiciel ou algorithme extrêmement inefficace, et pourtant "grande échelle". Si, par plaisir, je bricole un petit protocole d’IoT ultra-simple en apparence (et qui donc, alléluia, pourrait s’imposer comme standard de fait \o/ ) mais qui est 100 fois plus verbeux que ce que j’aurais pu faire en me creuser 10 jours la cervelle. Qu’est-ce-qui va se passer quand 30 millions de cafetières l’utiliseront ? Et si par-dessus le marché, j’y laisse par mégarde une faille béante de sécurité ?

  • Encore moins évident (encore plus tiré par les cheveux) : répandre de mauvaises pratiques. Je bricole dans mon coin, très souvent les week-ends. Et j’ai déjà croisé (une fois…) des gens qui m’ont dit "ah tiens, on s’est inspiré de ton bidule là pour ré-écrire notre implémentation de X". Franchement, combien de fois vous êtes allés lire le code d’un repo GitHub pour fouiller comment c’était implémenté ? Combien de fois vous vous êtes dits : ah ok je vois, mais c’est un peu crado. Combien de fois vous l’avez ré-écrit en mieux chez vous (professionnellement, ou pas) ? Combien de pull-requests avez-vous soumis à destination de l’auteur originel.

Bah mine de rien, les deux derniers exemples auront, (et ont, déjà) un coût dans notre société. Vous avez fait le parallèle avec la lecture ? Bien, je continue.

Si sous prétexte qu’écrire est amusant, je m’amuse à écrire n’importe quoi, que mon livre se vend bien, et que son fond influence les générations à venir ? Ai-je une part de responsabilité ? Même question si j’écris un bouquin en langage SMS, mais qu’il est tellement intéressant (dans le fond j’y apporte une vraie réponse intéressante) qu’on se doive de le lire.

Bref, cette digression pour dire que non, je ne pense pas que l’article se réserve à une population industrielle. Et je pense qu’aujourd’hui, les contributeurs passionnés doivent aussi comprendre que même si c’est une passion, et que du coup c’est amusant, toute contribution a aussi un impact.

Édité par Javier

Happiness is a warm puppy

+5 -0

Franchement, combien de fois vous êtes allés lire le code d’un repo GitHub pour fouiller comment c’était implémenté ? Combien de fois vous vous êtes dits : ah ok je vois, mais c’est un peu crado. Combien de fois vous l’avez ré-écrit en mieux chez vous (professionnellement, ou pas) ?

À chaque bibliothèque que je découvre sur le PyPI ou presque, je vais direct voir sur GitHub comment c’est codé, parfois je me dis que c’est vraiment trop crade (un module Python qui fait sys.exit(1) au lieu de lever une exception ? ORLY ?!) et je le refais au propre.

Par contre quand je décide de refaire un truc, je ne pousse quasiment jamais mes modifs upstream : je repose le problème à plat et j’implémente ma solution, parce que ça me plaît et que j’estime pouvoir faire globalement mieux from scratch.

Édité par nohar

I was a llama before it was cool

+0 -0

Je ré-implémente pas souvent ni fais de PR mais perso je vais très très souvent lire les codes sources pour comprendre ce qui se passe ou voir comment je peux résoudre mon problème. Pas plus tard qu’hier j’ai fouillé le code de Django pour résoudre un problème qui me générai des requêtes trop longues. J’y ai trouvé les infos qui manquaient à la doc.

Je sais pas si on est des cas particulier ou pas mais pour moi aller lire le code des libs qu’on utilise est normal et bien plus rapide que beaucoup d’autres méthodes.

+3 -0

Je sais pas si on est des cas particulier ou pas mais pour moi aller lire le code des libs qu’on utilise est normal et bien plus rapide que beaucoup d’autres méthodes.

Kje

Pour ma part, dans le cas de Ruby c’est même indispensable vu le vide sidéral que proposent la plupart des documentations.

Et le debug à coup de grep, ça a fait ses preuves :D

Nohar, c’est effectivement à toi que j’ai pensé en lisant cette remarque de victor, et je suis d’accord sur le fait qu’elle ne reflète pas vraiment ma compréhension de la situation. (Mon impression était que, quand les gens mettent en avant le plaisir à faire de la technique sur un projet non-éthique, c’est une forme de déni plus que de sincère justification.) En même temps, et sans vouloir en rajouter, pour le reste d’entre nous le fait que les gens qui font ça (développent des programmes non-éthiques) aient ou non des états d’âme ne change pas forcément grand chose au fait que ça a été fait, ça a été développé, et maintenant on vit avec les conséquences.

Bien comprendre l’état d’esprit des gens qui font ça est important si on veut pouvoir répondre aussi à la question, qui est posée dans ce billet : comment on peut présenter, expliquer, enseigner cet outil aux gens d’une façon qui leur fait prendre conscience des responsabilités qu’on prend dans son usage, et qui évite au maximum (ou au moins rende plus difficile, plus lente et plus coûteuse) le développement de technologies néfastes ?

Édité par gasche

+3 -0

Kje et nohar : c’est justement le message que je souhaitais faire passer : énormément de gens lisent les sources publiées, certains s’en inspirent voire les adaptent (mais beaucoup les copie colle) et encore moins contribuent en les corrigeant si besoin (vous en êtes tous deux l’exemple).

D’où la responsabilité qui nous incombe (succombe, ahem, pardon) en poussant nos sources à la vue d’autrui (pas nécessairement que le web hein, ça peut être des collègues qui débutent)

Happiness is a warm puppy

+0 -0

Nohar, c’est effectivement à toi que j’ai pensé en lisant cette remarque de victor, et je suis d’accord sur le fait qu’elle ne reflète pas vraiment ma compréhension de la situation. (Mon impression était que, quand les gens mettent en avant le plaisir à faire de la technique sur un projet non-éthique

gasche

Je visais pas nohar, je visais personne en particulier à part moi, je disais ça pour moi et vous comprendrez que j’entre pas dans les détails ici. Donc mon expérience, mon observation de première main, qui bien sûr ne pouvant la recouper suffisamment n’a que valeur d’anecdote, m’a fait écrire la remarque dont on parle ici.

Vous aimez le frontend ? Il y a un tas de petites tâches faciles si vous voulez contribuer à ZdS : https://github.com/zestedesavoir/zds-site/issues?q=is%3Aissue+is%3Aopen+label%3AC-Front

+0 -0

J’aimerais revenir sur ce terme : non-éthique. On parle de technologies et de logiciels non-éthique comme d’une évidence lorsque l’on parle de malwares, mais cela occulte aussi un pan entier de la technologie que l’on pourrait qualifier de grey zone.

C’est quelque chose que je disais déjà à l’époque où le logiciel sur lequel je bossais a connu sa triste célébrité, mais avec le recul : ce ne sont pas les technologies qui portent intrinsèquement un caractère éthique ou moral, mais l’utilisation qui en est faite.

Wireshark et tcpdump sont-ils des logiciels éthiques ou non ? Et les NIDS comme Snort le sont-ils ?

Lorsque tu développes un système automatisé de traitement de flux réseau, tu sais que tu es en train de faire une machine puissante. Mais comment savoir ce qu’il en sera fait ? Ce que je veux dire par là, c’est que jusqu’à ce qu’une utilisation déviante en soit faite et fasse scandale, ton logiciel se situe dans une grey zone morale, avant de finir catalogué comme non-éthique. Et le jour où il le devient, est-ce que tu es plutôt enclin à admettre que tu as fait fausse route tout ce temps, ou bien à penser que les gens se trompent parce que les médias les ont barratiné et leur ont présenté le DPI comme le diable en binaire ?

Édité par nohar

I was a llama before it was cool

+0 -0

C’est effectivement un débat intéressant si on s’y penche globalement. Dans mon cas je savais que le client était (par exemple) militaire et je connaissais la finalité de l’outil parce qu’il n’est pas difficile de voir au travers des use cases bidon qu’on te présente. Dans ton cas, tu me feras pas croire que tu ne voyais pas de problème éthique bien avant que ça sorte dans la presse. Je présume que tu connaissais les clients et je présume que tu leur rendais occasionnellement visite. (C’est pénible parce que je vais rien balancer, ni sur ce sur quoi j’ai pu bosser ni sur ce sur quoi tu as pu bosser.)

Donc ouais, là c’est pas intéressant de discuter de nos cas particuliers (d’autant que c’est potentiellement difficile de le faire sans trop en dire et sans être de mauvaise foi, peut-être) mais c’est intéressant globalement.

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 ?

J’ai pas de réponse définitive à ces questions, ce sont des questions que je continue de me poser. Un truc de certain, en revanche, c’est que je rejette catégoriquement l’argument de l’ingénieur travaillant sur des fusils et qui me sort "c’est comme si je travaillais sur des tournevis puisqu’on peut aussi tuer quelqu’un avec un tournevis".

Vaguement lié à ce sujet, un cas anecdotique mais qui a fait couler beaucoup d’ancre et emmerdé beaucoup de monde est Crockford, créateur du langage JavaScript et du format JSON, et auteur d’un lib JSON (en C sauf erreur) qui s’est rapidement répandue dans des langages tels que PHP et dans des distribs Linux se voulant libre. 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.

[edit]

Ce que je veux dire par là, c’est que jusqu’à ce qu’une utilisation déviante en soit faite et fasse scandale, ton logiciel se situe dans une grey zone morale, avant de finir catalogué comme non-éthique.

Je pense qu’une bonne piste pour répondre à cette question est la piste de la clientèle. Wireshark est un projet open source, il n’a pas de client direct. En revanche quand on mandate X pour construire Y pour faire Z, il devient plus difficile pour X d’argumenter que Y est "neutre" si Z est "généralement non éthique" (typiquement le déchiffrement de traffic internet, si ça se fait ?). Et je dis "mandate", mais pour le même prix c’est pas un mandat mais un achat ou un service, dans le sens où une "agence" contacte X pour leur demander les détails des produits et la liste de prix. La liste de prix qui est pas sur internet, et la liste des produits est pas la même que celle du site Internet. T’as pas bossé pour Palantir sauf erreur, du coup on peut éventuellement utiliser cette boite comme exemple, sauf que leurs services, et bien… on ne sait que ce qu’ils veulent nous en dire et ce qui fuite (et parfois difficile de croire aux fuites ?) ?

Édité par cepus

Vous aimez le frontend ? Il y a un tas de petites tâches faciles si vous voulez contribuer à ZdS : https://github.com/zestedesavoir/zds-site/issues?q=is%3Aissue+is%3Aopen+label%3AC-Front

+0 -0

Faisant de la recherche, je me pose les mêmes questions, pas seulement au niveau du logiciel que je produis, mais des choix de sujets de recherche scientifique, financement, publication etc. Par exemple j’ai des collègues qui travaillent avec des financements militaires, d’autres (plus éloignés de ma thématique) qui font de la reconnaissance de visages, d’autres qui développent un OS prouvé correct pour un robot qui a des roues, deux bras, dont l’un équippé d’un pistolet de paintball – c’est sans doute un projet pour parcs d’attractions.

Au delà de la question directe de l’intention du vendeur (ou de l’auteur de la demande de financement de recherche) et du client (ou du financeur, ou de la boîte qui interagit avec les chercheurs), à mon avis on peut trouver des outils utiles pour réfléchir à ces questions en pensant à l’asymmétrie de l’information, au rapport de force pour l’usage d’une technologie.

Mettons par exemple que je développe une analyse statique qui prouve l’absence d’erreurs de calculs en virgule flottante dans des programmes C. En soit, c’est neutre, tout le monde peut s’en servir. Mais qui va le faire vraiment ? Si je ne fais aucun effort pour entrer en contact avec les uns ou les autres, la réponse c’est "les gens qui ont l’argent et le temps de payer des ingénieurs pour utiliser ma recherche". Et je peux savoir d’avance, avant de faire le boulot, quels sont les domaines applicatifs qui demain vont investir cet effort : l’aéronautique, civile et militaire, et peut-être les fabriquants d’automobile. Bien sûr, dans 20 ans, les forces économiques seront peut-être différentes, la recherche existera toujours, et d’autres gens seront en position de s’en servir (si demain un chercheur fou invente une cryptomonnaie dont la "proof of work" repose sur des lancements Kerbal Space Program réussis, il pourrait y avoir soudain plein de gens qui s’intéressent à mon travail pour scripter leurs fusées), et je ne peux pas prévoir. Mais à court/moyen terme, je peux facilement prévoir, et faire mes choix selon ce que j’en pense.

Là c’est le scénario sans contacts préférentiels avec des gens. Si je suis financé par l’armée, ils vont aussi regarder de plus près ce qui est fait, et donc être plus à mêmes de s’en servir (que les KSPiens qui ne seront pas au courant du boulot, etc.). Si je suis financé par la NASA, ça va être plus facile pour eux de s’en servir; et peut-être que j’irai à une conférence où d’autres gens interagissent avec la NASA, on va découvrir qu’on peut combiner nos analyses et faire un outil commun dont les ingénieurs de là-bas connaissent l’existence et s’intéresseront à s’en servir, longtemps avant les militaires qui bossent avec une autre équipe de recherche aux thématiques proches.

Qui va être en position de force pour utiliser les fruits de mon travail, en rapport avec le besoin qu’ils/elles en ont ? Est-ce que je peux choisir comment orienter mon travail pour que ce groupe corresponde aux gens que j’ai envie d’aider pour rendre le monde meilleur ? Ça peut passer par des choix de sujets un peu différents (Qu’est-ce qui peut aider des journalistes d’investigation à faire leur boulot aujourd’hui ? Y a-t-il des technologies qui peuvent aider les gens à vivre un vrai débat démocratique ?), ou simplement par des façons différentes de le conduire et des choix de personnes avec qui interagir pour qu’ils s’en servent.

Enfin, essayer d’interagir avec des gens bien précis ça peut être difficile. Par exemple, aujourd’hui un des plus grands succès du langage OCaml pour la programmation d’outils de vérification c’est l’outil d’analyse statique des drivers Windows. Les utilisateurs Windows méritent d’avoir des drivers matériels qui ne crashent pas la machine, ça améliore la vie des gens, mais ce n’est peut-être pas le choix d’entreprise à soutenir que j’aurais fait en premier. Convaincre la communauté Linux ou BSD d’utiliser quotidiennement des outils de vérification de ce genre (et d’annoter leur code pour leur faciliter la tâche, etc.) est un travail titanesque, car ce n’est pas dans leur culture, et il n’y a pas un manager dictateur pour forcer un changement en bloc. Ça progresse petit à petit, mais ça demande beaucoup d’efforts, les gens des deux côtés ont des incitations à dépenser leur énergie ailleurs. Ce groupe reste en retard par rapport à d’autres parties de l’industrie sur ce sujet – et c’est un peu de notre faute à tous.

Édité par gasche

+0 -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 ?

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.

Amateur de Logiciel Libre et de la distribution GNU/Linux Fedora. #JeSuisArius

+1 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

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