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

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 !

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.

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..

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é.

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."

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.

@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.

Et ça n’empêche pas du tout de s’amuser en faisant cette chose normalement sérieuse. Pour filer la métaphore de victor, ça m’arrive très régulièrement de m’amuser en lisant ou en écrivant.

@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.

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.

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.

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.

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.

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.

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

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 ?

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)

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.

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 ?

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 ?) ?

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.

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.