prez-bnu

Anonyme, en lecture seule : git clone git://bebou.netlib.re/prez-bnu
Authentifié·e, en écriture : git clone ssh://git@bebou.netlib.re:1459/srv/git/prez-bnu

Log | Files | Refs | README | zip | tar.gz |

prez.slides (27996B)

 
 
    
 
 
 
 
                            Quelles inspirations pour créer des
 						    systèmes socio-techniques  durables ?
 
 
 
 
 
 
 › Le blabla académique
 
 Arthur Pons
 Doctorant à l'UCBL - Lyon 1
 A l'école doctorale MathInfo de Lyon
 
 › Le blabla académique
 
 Au laboratoire de l'Informatique de parallélisme
 Qui est à l'ENS
 
 › Le blabla académique
 
 Mais mon vrai labo est le CITI à l'INSA Lyon, dans l'équipe phenix
 Laboratoire avec lequel je n'ai donc pas de lien administratif
 
 › L'entreprise
 
 En CIFRE chez Commown
 
 Commown est une coopérative quit fait de la location de matériel informatique
 avec un modèle de propriété et un modèle économique visant à le faire durer le
 plus longtemps possible
 
 › L'entreprise
 
 Commown fait du lobbying d'intérêt général et veut en faire plus, il lui faut
 de l'argent
 
 › L'entreprise
 
 Par exemple en participant à l'élaboration de l'indice de réparabilité puis
 durabilité
 
 › L'entreprise
 
 Commown veut aider à la transition de ses clients institutionnels vers des
 logiciels libres
 
 Combinaison des deux -> faire de l'infogérance, gérer de l'informatique pour
 des petites entreprises
 
 › Laboratoire
 
 Le projet séduit l'équipe Phenix du CITI
 
 Laboratoire de chercheurs en info (pure et dure) mais qui redirigent leurs
 recherche et y incluent d'autres méthodes de recherche pour poser des questions
 pertinentes au sujet des liens entre env et num
 
 Y'avait une chercheuse en science politique dans l'équipe avant mais elle a été
 plus ou moins évincée (comme quoi la trans-disciplinarité tout le monde l'appel
 de ses voeux mais elle gêne encore)
 
 › Le sujet
 
 Construire un service d'infogérance durable (sobre, robuste, empouvoirant) et
 viable, et documenter la manière d'y arriver
 
 
 › D'où je viens personnellement
 
 J'ai un parcours qui dans certains milieux commence à être commun cad
 
 Ecole d'ingé, enthousiaste à propos de la technologie
 
 › D'où je viens personnellement
 
 Un peu désabusé vers la fin de mes études
 Plus vraiment d'intérêt pour l'informatique
 › D'où je viens personnellement
 
 MAIS
 
 autour de 2019, élan autour de la question environnementale me permet de
 regagner un intérêt pour l'informatique en le politisant et le confrontant à mes
 aspirations politiques, celle d'être écologiste
 
 › D'où je viens
 
 Avec des collègues et ami·es on décide de créer un collectif qui s'appelle
 Katzele qui investit l'intersection entre trois choses :
 
 › Illich
 
   - convivialité (Illich)
 
 › C'est grave et on veut faire beaucoup
 
   - une lecture radicale de l'urgence environnementale
 
 › La culture UNIX
 
 Unix est un système d'exploitation toute fin des années 60, début 70
 
 Ken Thompson est assis, Dennis Ritchie est debout, Kernighan pas sur la photo
 
 › Héritage
 
 Unix a une influence considérable sur les systèmes d'exploitation encore
 aujourd'hui
 
 › Des OS mais pas que
 
 Des petits logiciels qui font une seule chose et bien
 
 Une culture qui permet de faire émerger de la fonctionnalité par la combinaison
 de ces briques fonctionnelles qui peuvent donc rester elle même assez simples
 
 Tout un ensemble de facteurs poussent les écosystèmes informatiques qui
 héritent d'UNIX à garder au moins un coeur stable, assez fidèle à ces origines
 
 › La culture promeut la stabilité
 
 La preuve :
 
 	makewords sentence | lowercase | sort | uniq | comm -23 - dict
 
 
 laborotories
 privide
 timesharing
 unix
 
 › C'est fou !
 
 Je peux, 43 ans plus tard, continuer à écrire la même chose et faire les mêmes
 traitement
 
 › Et les performances
 
 UNIX a été construit sur un PDP-11, une machine puissante pour l'époque, que
 seule les entreprises ou les universités pouvaient s'offrir
 
 Chaîner des commandes comme on vient de le faire, avec un langage très "haut
 niveau" sur un système qui, (ici on le voit pas) mais est capable de gérer
 plusieurs utilisateurs, et leur offre un niveau d'abstraction considérable
 coûtait cher
 
 › La comparaison
 
 Le must en ordinateur personnel à l'époque de la vidéo est le commodore 64, une
 machine incapable de faire fonctionner UNIX.
 
 › Mais la loi de Moore
 
 Mais la loi de Moore est passée par là et nos ordinateurs sont devenus plus
 puissants
 
 › C'est pratique
 
 pourtant, comme je le disais, beaucoup de systèmes héritiers d'UNIX continuent à
 proposer ces commandes. C'est une forme ici pragmatiquement bénéfique de
 dépendance au sentier qui nous permet, si on le souhaite, d'inscrire du logiciel
 dans la durée pour peu que l'on se conforme à cet héritage là. Cela permet de faire
 un retour dans le passé à moindre coût.
 
 › Ok mais tout ça c'est technique
 
 D'accord la forme des outils, les valeurs que portent les cultures techniques,
 les propriétés techniques de ces outils peuvent être avantageuses pour la
 durabilité comparativement à d'autres  mais , question plus importante,
 qu'est-ce qui détermine l'adoption d'une technologie ou d'un écosystème
 technologique au détriment d'un autre ?
 
 › Question complexe
 
 Des personnes se sont posé la question pour les langages de programmation, c'est
 très intéressant. On apprend que ce sont très principalement des critères
 sociaux qui déterminent l'adoption et pas des critères techniques contrairement
 à ce que la masse de discussion autour de la performance et des fonctionnalités
 des langages pourrait laisser penser
 
 › Mais on s'intéresse pas qu'aux langages
 
 Et surtout on s'intéresse aux groupes de personnes. Et pour ça on peut se
 reposer sur les travaux de Maxigas.
 
 C'est un sociologue qui étudie principalement les milieux des hackerspaces, leur
 pratiques sociales et techniques. De toute évidence il prend également part à
 ces milieux, par exemple la conférence qu'on voit ici est une conférence de
 hackers.
 
 › Qu'est-ce que j'entends pas hackers
 
 Par hacker j'entends pas les personnes malveillantes qui s'introduisent dans des
 systèmes informatiques pour y détruire ou voler des données mais la culture
 consistant à modifier et adapter des technologies pour ses besoins
 
 › L'exemple d'IRC
 
 Maxigas fait le constat suivant :
 
 	beaucoup de communautés hackers utilisent encore IRC comme logiciel de
 	messagerie instantané alors que "le reste du monde" est passé à
 	messenger/matrix/signal/whatsapp
 
 Pour info IRC ça peut ressembler à ça (ptit alt tab)
 › Etude psycho
 
 Maxigas raconte qu'il y a une littérature en psychologie qui analyse ces usages
 à travers un prisme qui leur est propre et qui conclu que les motivations sont
 beaucoup nostalgiques ou du fait de la combinaison d'intertie technique et de
 résistance au changement
 
 Mais Maxigas critique cette approche qui cadre le choix technologique comme
 un choix
 
   individuel
   psychologique
   non politique
 
 › Alors que
 
 Maxigas montre que c'est, au moins aussi, si ce n'est plus, un choix
 socio-technique conscient et politique, en partie parce que les usages aujourd'hui
 sont largement postérieurs à l'arrivée des autres messageries (et donc elles ont
 pu comparer les technos entre elles) :
 
   * une techno qui peut se scripter
     * ci pour projet de dev
 	* utiliser pour s'interface avec l'extérieur
   * sur laquelle on peut être anonyme
   * léger, décentralisé, fonctionne sur à peu près n'importe quoi
 
 › Critical technology appropriation
 
 Critical technology appropriation : une techno n'est pas prête simplement quand
 elle fonctionne techniquement mais lorsqu'un groupe de personne plus ou moins
 divers s'en est saisi pour satisfaire avec succès son besoin. C'est un cadre qui
 propose d'étudier les technologies par la manière dont elles font la médiation
 entre les humains plutôt que par leurs caractéristiques techniques intrinsèques.
 Le "critical" est lorsque l'on remarque que les personnes du groupe adoptent la
 techno pour des raisons conscientisées de supériorité de cette techno sur
 d'autres.
 
 Petit retour en arrière sur des exemples de critical technology appropriation
   * les luddites : refus du nouveau mode de vie induit par l'industrialisation
     de leur métiers les rendant anonymes, + productifs et les forçant à migrer
     en ville
   * les amishs : refus de nouvelles technos si elles sont perçues comme
     néfastes pour les liens de la commu
 
 Trois critères pour avoir un regard critique sur l'adoption d'une techno ou pas :
 
 	1. Comparaison historique : être capable d'apprécier une techno
 	   comparativement à ce qui est venu avant
 	2. Expertise technique
 	3. Culture/(fonctionnement/organisation ?) semi-autonome (non intégrée à une
 	   insitution - université, entreprise, état) : permet de développer un avis
 	   singulier sans être influencé par les intérêts d'autres partis
 
 
 
 › Et pour notre thèse ?
 
 Il est important de se poser la question, est-ce que Commown est prête à une
 adoption critique des technologies ? Sinon la thèse risque d'être mal barrée.
 
 Il est possiblement encore plus intéressant de se poser la question pour nos
 clients mais c'est plus difficile d'obtenir cette information.
 
 Maxigas nous rappelle un élément essentiel, le choix des techniques dont on se
 saisi en commun est politique. Et ça tombe bien parce que nos objectifs dans la
 thèse étaient :
 
 › Sobriété, résilience, empouvoirement
 
 Cool
 
 › Et entre les groupes
 
 Maxigas étudie des milieux où les technologies médient (du verbe médier, faire
 de la médiation, c'est de l'ancien français) entre des individus d'un même
 groupe. Mais quand est-il si elles se situent inter-groupes (possiblement avec
 des intérêts divergents) et non pas intra-groupe.
 
 
 › L'exemple des satellites
 
 Marisa Leavitt Cohn (à gauche), une anthropologue spécialisée dans les
 intéractions humain-machine, s'est infiltrée dans une mission spatiale pendant
 plusieurs mois pour voir ce qu'il s'y passait, notamment la maintenance (étant
 donné que la mission en question était en fin de vie). C'est une recherche qui
 doit beaucoup à Susan Leigh Star, sociologue des sciences qui, entre autre,
 s'intéresse aux infrastructures numériques et à leur maintenance.
 
 Cohn raconte que dans le contexte d'une infrastructure physique et numérique
 "gériatrique", la fonction médiatrice des systèmes socio-techniques entre
 plusieurs groupes sociaux est d'autant plus évidente.
 
 Le satellite a de plus en plus de problèmes physiques, par définition impossible
 à réparer, et la ressource du temps disponible du satellite se tend entre les
 ingénieurs qui ont a coeur de le faire durer le plus longtemps possible et qui
 doivent donc faire de la maintenance et les scientifiques qui veulent en
 extraire un maximum de données. Elle parle de négociation.
 
 › Ca se matérialise comment ?
 
 Deux anecdotes :
 
   1. Les ingénieurs ont conçu un logiciel qui permet aux scientifiques d'entrer
   leurs besoins. Le logiciel calcul une sorte de calendrier qui doit contenter
   tout le monde, du temps pour la maintenance, du temps pour la science. Mais
   manque de transparence, les scientifiques se demandent si le logiciel triche
   pas un peu
   2. Les ingénieurs offrent un gâteau d'anniversaire à l'équipe scientifique du
   moment pour les 5000 jours de la mission, une manière de montrer qu'eux
   entretiennent une relation de long terme avec l'infrastructure avec que les
   scientifiques non
   3. L'outil peut peut aussi être
 une opportunité à la négociation. Elle raconte que l'émergence de bug, notamment
 dans du vieux code difficile à maintenir, déclenche des conversations qui
 aboutissent sur la décision de perpétuer, ou au contraire, renoncer (mot
 à la mode dans la redirection écologique, si vous lisez Monnin) à des
 fonctionnalités, renoncer à des besoins.
 
 L'importance des artefacts techniques dans la négociation est tellement forte
 qu'il est même arrivée qu'une membre de l'équipe d'ingé introduise
 volontairement un bug pour faire prendre conscience de la fragilité d'un
 système. Les aspérités du système technique permettent aux groupes sociaux
 d'arbitrer les besoins dans un contexte de déclin.
 
 › A Commown
 
 Dans notre cas on s'inscrit pas dans un contexte d'une infrastructure
 pré-existante en déclin mais d'une infrastructure naissante. Ce qu'on peut en
 retenir c'est d'éviter de voir systématique et uniquement les évènements
 techniques comme des problèmes à résoudre mais aussi comme quelque chose en
 capacité de réagencer les relations entre les deux groupes (en bien comme en
 mal d'ailleurs).
 
 La plupart du temps les prestataires de services informatique vendent leur
 travail comme étant presque miraculeux, apaisant, fonctionnant nécessairement
 bien. On sait que dans la pratique c'est jamais le cas. Plutôt que de tripler
 d'effort d'ingénieurie pour imaginer un service technique parfait qui
 conviendrait à tout le monde tout le temps et plutôt que de vendre du rêve au
 client, il est préférable d'accepter la fragilité du numérique, accepter les
 éventuels conflits que ça peut faire émerger (sans se taper dessus hein) et de
 préparer la négociation qui va venir qu'elle provienne des outils ou qu'elle
 soit à propos des outils.
 
 
 › Ok mais est-ce que l'on peut structurer cette négotiation ?
 
 Mais est-ce que l'on a une structure pour faire ça ?
 
 › Le jeu des dilemmes
 
 Au Danemark 95% des employés sont dans des tpe/pme
 Un rapport du ministère de la défence dit que le niveau de sécurité info est
 vraiment pas ouf
 
 Laura Koksch va passer du temps dans ces entreprises là et raconter que c'est
 pas parce que ces entreprises s'en fiche de la sécurité ou qu'elles en sont
 incapables mais qu'elles ne sont pas organisées pour gérer la sécurité
 informatique d'une manière qui soit compatible avec les recommandations
 qu'elles reçoivent de l'état (principalement parce qu'elles sont écrites pour
 des équipes IT qui ensuite font descendre les ordres dans leurs boites mais
 les entreprises danoises sont généralement très petites avec aucune équipe
 dédiée au sujet).
 
 Elle développe la théorie comme quoi la sécurité dans des petites entreprises
 se vit au gré des compromis à faire, au quotidien, entre l'activité économique
 de l'entreprise, les compétences disponibles (selon que la personne en charge de
 la sécu info soit une personne de la com ou de la compta par ex), et
 l'obsolescence plus ou moins avancé des systèmes techniques mobilisés. La
 sécurité info ne se vit pas à travers des grands principes et des
 recommandations techniques qui disent "ça c'est bien, ça c'est pas bien", elle
 se vit à travers "oui le mot de passe pour ce poste de travail il est nul mais
 c'est un poste qui opère telle machine qui est utilisée par 4 personnes
 différentes qui sont constamment en train de quitter et de revenir sur le poste
 et qui doivent donc insérer leurs mot de passe"
 
 Avec l'intuition qu'une meilleure sécu info passe par des discussions qui
 soient raccord avec cett réalité elle propose de les envisager sous l'angle des
 dilemmes. Les dilemmes sont des scénarios typique (parfois banals) de sécurité
 info très terre à terre. Elle a inventé un pretexte de jeu qui permet à des
 personnes ayant des rôles différents, y compris les pouvoirs publics, de
 discuter autour de ces dilemmes, avec pour résultat une meilleure compréhension
 des contraintes des un et des autres et une sécurité qui évite de sermonner
 et s'attelle plutôt à "vivre avec" des systèmes techniques à la sécurité
 médiocre.
 
 › Et dans la thèse
 
 On a un client qu'on fait payer pas cher, Légicoop
 
 Et c'est aussi une tpe/pme donc on pense que notre positionnement par rapport à
 Légicoop pourrait potentiellement être aussi inefficace que celui du ministère
 de la défence Danois a avec les pme danoise.
 
 On pense que l'utilisation des dilemmes, ou de manière générale ne pas avoir
 peur de problématiser l'informatique, expliquer que pour nous aussi c'est un
 problème, ça peut nous mener a avior des discussions de meilleures qualité avec
 eux et à offrir un service de meilleure qualité.
 
 On a pas encore formellement écrit de dilemme mais on ça ne devrait pas être
 trop un problème, notamment autour de la tension entre empouvoirement,
 autonomisation, simplicité technique et temps disponible.
 
 C'est un choix/dilemme qui est également économique pour le client et pour
 nous. Si l'on souhaite avoir un service qui donne un maximum de capacité d'agir
 au client et que le client joue à fond le jeu, pourquoi est-ce qu'ils
 continuerait à nous louer de l'infogérance tous les mois si à terme il est
 capable d'être entièrement autonome ? D'une certaine manière l'autonomisation
 complète du client met en danger le service la viabilité économique du service.
 
 › Un dernier exemple
 
 C'est compliqué hein ?
 
 Une question que l'on peut se poser ici est :
 
 	De quelles informations est-ce que l'on se munit pour mener la négociation.
 	Ok on a des scénarios de dilemmes mais quand il faut comparer des solutions
 	entre elles on risque d'avoir besoin de données plus précises qui nous
 	permette de dire "cette solution est mieux pour l'autonomisation", "cette
 	solution est plus sobre environnementalement", il faut du carburant pour
 	notre discussion
 
 › SUSAD
 
 On utilise un outil nommé le SUstainable Awareness Diagram qui invite à lister
 les impacts de premier ordre, de second ordre et de troisième ordre de l'outil
 ou du service que l'on veut créer puis de les catégoriser par type d'impact :
 
   * env
   * tech
   * social
   * indiv
   * eco
 
 de les placer sur un diagramme en pentagone et de tracer des liens de
 causalités des un aux autres.
 
 La prétention n'est pas de pouvoir prédire le futur mais de 
 
   1. faire émerger des idées que l'on aurait pas eu autrement, un outil de
      t'empête de cerveau
   2. avoir un support pour discuter avec le client
 
 › Exemple d'airbnb
 
 Pour la blague, un SusAD tiré du papier qui l'introduit qui prend l'exemple classique d'AirBNB.
 
 › Toute dernière inspiration
 
 On boucle la boucle en revenant sur un peu de technique
 
 Clay Shirky est un journaliste, chercheur, prof d'info qui en 2004 écrit un
 mail dont le sujet est "Situated software, Logiciel situé". Il enseigne,
 comment faire des applications (web notamment) proprement, dans les règles de
 l'art, qui puisse être commercialement viable. Ca implique une certaine
 industrialisation, des logiciels complexes, avec beaucoup de fonctionnalités
 généralement très performants etc.
 
 Les projets de ses étudiant·es ont tendance à prendre des raccourcis en se
 basant sur les spécificités du groupe. Au lieu de développer pour un ou une
 utilisatrice générique qui pourrait être n'importe qui, iels développent
 souvent pour leur groupe d'ami en particulier. Ca donne des logiciels sans
 méchanismes sophistiqué de notification pour que la personne revienne parce
 qu'elle est dispo via un kiosque présent dans la salle de classe (et donc les
 personnes sont contraint d'y revenir physiquement), un logiciel pour faciliter
 les achats de groupe qui n'a pas d'interaction complexe avec un système
 bancaire pour identifier et collecter les impayés mais qui envoie simplement
 une alerte "machin a pas encore payer sa part" et c'est le groupe qui gère le
 problème dans la vraie vie ou un logiciel qui permet de noter les profs bien
 plus populaire que celui de la fac parce que géré par des étudiants (et donc
 plus de confiance) et pré-peuplé avec les comptes personnels des étudiants
 (pas très RGPD). Les caractéristique techniques du logiciel sont informées
 directement par le contexte dans lequel il s'insère, on dit donc qu'il est
 situé.
 
 › Et à Commown ?
 
 A Commown on expérimente avec la même idée pour faire migrer des besoins de
 logiciels pas situés, et en l'occurence mal adapté et très très complexes, vers
 du logiciel situé, mieux adapté au contexte de Commown et beaucoup plus simple.
 
 L'atelier avait des protocoles écrit dans des words, qu'on ouvre dans un
 logiciel appelé onlyoffice dans le navigateur. Ca pose plein de soucis
 (maintenance, édition, hétérogénéité de la mise en page, quantité d'information
 à l'écran) et c'est une stack technique d'une complexité assez monstrueuse.
 Ce choix est assez classique, faute d'un outil spécialisé notre dévolu se jette
 souvent sur des logiciels les plus génériques possible (ici aussi, des
 logiciels avec des concepts que l'on connaît, la plupart des gens ont déjà fait
 du traitement de texte). Ces outils sont souvent fait "pour scale", ce sont
 des outils qui sont intrinsèquement pas situés.
 
 Pour y remédier on a fait une revue des besoins élémentaires et j'ai fait un
 logiciel nommé protocolium qui génère un site web avec les protocoles. Chose
 intéressante, puisque je sais que je connais le groupe social qui va utiliser
 l'outil, à savoir l'atelier de Commown, je sais qu'une seule personne ou
 presque va éditer les protocoles et que cette personne est plutôt à l'aise
 techniquement. Donc j'ai pu prendre de gros raccourcis de développement en
 proposant l'écriture en markdown et en ométtant entièrement la construction
 d'une interface d'édition, tout ce fait en ligne de commande et dans des
 fichiers texte. C'est des semaines et des semaines de dev en moins, de
 maintenance en moins. J'ai réduit la complexité de l'outil et peut-être évité
 une ou plusieurs dépendances logicielle en échange contre une dépendance
 "humaine" d'une personne qui a pas peur de lancer quelques commandes parfois et
 d'éditer des fichiers texte brut.
 
 Je sais pas si protocolium va être utilisé pendant des décennies, je pense que
 ça dépend principalement de la pérennité de Commown, mais je mets ma main à
 couper que sans avoir à en prendre soin littéralement tous les jours, il pourra
 fonctionner tel quel dans 20/30 ans.
 
 › Conclusion
 
 Wow, c'est compliqué
 Et hétérogène
 Et flou
 Est-ce qu'il est possible de lier tout ça ?
 Est-ce que ça fait sens de lier tout ça ?
 Comment on applique ces grands principes dans la vraie vie ?
 Est-ce que c'est pas un peu du bullshit ?
 
 › Wicked problems
 
 J'assistais à une présentation de Thibault Simon, un docteur en informatique
 qui a fait une thèse CIFRE comme moi. Sa thèse est technique, y'a pleins de
 jolis graph etc. A la fin de la présentation l'un des chercheurs sur place lui
 demande, et je paraphrase : "Ok on est capable d'économiser de l'énergie et le
 mesurer. Quid de la nature des usages, des aspects sociaux qui l'entoure etc."
 l'air de dire, c'est chouette mais si on éco-conceptionne un logiciel pour
 l'extraction de pétrole, à quoi bon ?
 
 Et en guise de réponse Thibault Simon s'est presque excusé d'avoir eu une
 approche purement technique. Il a pas cherché à esquiver ou à se justifier.
 
 L'un des objectifs que l'on se donne est de ne pas tomber là dedans, d'essayer
 de prendre à bras le corps le problème dans (presque) toute sa complexité.
 
 › Et c'est un sacré problème
 
 C'est vraiment difficile
 
 C'est tellement difficile qu'il y a de la littérature qui se demande "est-ce
 que notre communauté s'est pas attaquée à un peu trop gros". Ces types de
 problèmes, qui recoupent pleins de domaines différents, qui bougent avec le
 temps et présente dans notre cas un couplage non seulement fort mais complexe
 entre technique et humains ont un nom, celui des "wicked problems", en français
 "problèmes pernicieux".
 
 › Comment on les aborde
 
 Le papier fait une liste de suggestions qui pourraient permettre de mieux
 aborder cette catégorie de problèmes et dedans on trouve, et c'est sans grande
 surprise :
 
   1. plus de trans-disciplinarité
   2. plus de pensée systémique
 
 Se confronter à un problème pernicieux est pas toujours agréable et ça donne, à
 8 mois de thèse, cet inventaire à la Prévert de références mais à priori c'est
 bon signe. Si tout ça était limpide on aurait sûrement raté quelque chose.
 
 › Pas tout seul
 
 Je suis pas le seul doctorant dans cette démarche. Je pense notamment à :
 
 	Valentin Girard, ingénieur de formation, qui fait de la recherche action
 	pour la redirection écologique numérique des organisations
 
 	David Ekchajzer qui intègre les sciences humaines aux méthodologies de
 	mesures de l'impact environnemental du numérique
 
 	Eric Patrizio dont on espère que la thèse étudiera la manière dont
 	les environnements sociaux impactent l'évolution technique des langages de
 	programmation avec une double direction informatique/sociologie
 
 	Léa Mosesso dont la thèse s'inscrira dans l'équipe de recherche limites
 	numérique, un projet de recherche entre informatique et design
 
 	et d'autres...
 
 Donc déjà plein de recherche un peu hétéroclite comme ce que je vous ai
 présenté et plein d'autre à venir
 
 
 › Références
 
 git : http://git.bebou.netlib.re/prez-bnu/log.html
 
 Anceau, Éric. « Vincent Bourdeau, François Jarrige et Julien Vincent, Les
 Luddites. Bris de machines, économie politique et histoire ». Histoire,
 économie & société 25, nᵒ 4 (2006): 164‑164.
 
 Balasubramaniam, Sriram, Grace Lewis, Soumya Simanta, et Dennis Smith.
 « Situated Software: Concepts, Motivation, Technology, and the Future ». IEEE
 Software 25 (novembre 2008): 50‑55. https://doi.org/10.1109/MS.2008.159.
 
 Budapest Hackerspace, réal. Camp++ 0x7e0 // maxigas: What is critical
 technology appropriation? 2016. 1:09:56.
 https://www.youtube.com/watch?v=gOGhP08ayqw.
 
 Duboc, Leticia, Stefanie Betz, Birgit Penzenstadler, et al. « Do we Really Know
 What we are Building? Raising Awareness of Potential Sustainability Effects of
 Software Systems in Requirements Engineering ». 2019 IEEE 27th International
 Requirements Engineering Conference (RE), septembre 2019, 6‑16.
 https://doi.org/10.1109/RE.2019.00013.
 
 Hermans, Felienne, et Ari Schlesinger. « A Case for Feminism in Programming
 Language Design ». Proceedings of the 2024 ACM SIGPLAN International Symposium
 on New Ideas, New Paradigms, and Reflections on Programming and Software, ACM,
 17 octobre 2024, 205‑22. https://doi.org/10.1145/3689492.3689809.
 
 Kocksch, Laura. « Fragile computing: Directions for developing post-optimistic
 technologies ». Politiques environnementales du numérique, 30 avril 2025.
 https://cis.cnrs.fr/politiques-environnementales-du-numerique/#sem-pen.
 
 Kocksch, Laura, et Torben Elgaard Jensen. « “Good” Organizational Reasons for
 “Bad” Cybersecurity: Ethnographic Study of 30 Danish SMEs ». In « Good »
 Organizational Reasons for « Bad » Cybersecurity, Report. Aalborg Universitet,
 2023. https://doi.org/10.54337/aau513432435.
 
 Kocksch, Laura, et Estrid Sørensen. Investigating the
 Sustainability-Cybersecurity Nexus in HCI as a Practical Problem. s. d.
 
 Maxigas. « Hackers against Technology: Critique and Recuperation in
 Technological Cycles ». Social Studies of Science 47, nᵒ 6 (2017): 841‑60.
 https://doi.org/10.1177/0306312717736387.
 
 Meyerovich, Leo A., et Ariel S. Rabkin. « Empirical Analysis of Programming
 Language Adoption ». Proceedings of the 2013 ACM SIGPLAN International
 Conference on Object Oriented Programming Systems Languages & Applications,
 ACM, 29 octobre 2013, 1‑18. https://doi.org/10.1145/2509136.2509515.
 
 Meyerovich, Leo A., et Ariel S. Rabkin. « Socio-PLT: Principles for Programming
 Language Adoption ». Proceedings of the ACM International Symposium on New
 Ideas, New Paradigms, and Reflections on Programming and Software, ACM, 19
 octobre 2012, 39‑54. https://doi.org/10.1145/2384592.2384597.
 
 Nova, Nicolas, et Gauthier Roussilhe. « Du low-tech numérique aux numériques
 situés ». Sciences du Design 11, nᵒ 1 (2020): 91‑101.
 https://doi.org/10.3917/sdd.011.0091.
 
 « Schedule Camp++ 0x7e0 ». Consulté le 17 juillet 2025.
 https://camp.hsbp.org/2016/pp7e0/fahrplan/events/20.html.
 
 « Shirky: Situated Software ». Consulté le 17 juillet 2025.
 https://gwern.net/doc/technology/2004-03-30-shirky-situatedsoftware.html.