critique d'un réformisme/ajustements de l'ensemble technologique et son monde (mathématisation du monde, rationalité capitaliste). Il s'agirait de modifier les effets délétaires des outils techniques plutôt que d'une critique générale rejetant ces ensembles des techniques formant un ensemble macro.

Mouvements libristes, portant par les techniques un idéal de transformation sociale défaisant les techniques de leurs emprises techno-capitalistes/fascistes, les retournant contre elles. Es-ce possible, oui par moments historiques fugaces que les pouvoirs tentent de réduire. (Thèse) Elles ocroient des pouvoirs opositionels effectifs. Elles ne sont pas en soi mauvaises (ou neutres) mais lieux d'une encapacitation individuelle. Tant qu'on garde cet espoire positif, l'abolition technologique semble discutable, "il y a de bons usages" chéris qui justifient l'existance et le maintient des techniques, proposant peut-être d'autres idéals technologiques viables et souhaitables, un ré-enchantement du web et autres couches executives de la numérisation du monde qui passe par elles.

Il faudrait réformer les plasticités nocives des outils retournés contre nous, nous défendre des environements qui réduisent nos capacités. C'est en soi un geste croyant dans la capacité à résoudre certains problèmes du monde par les techniques formant un ensemble technologique, une facon de faire et d'être au monde, peut-être de le hacker, de le disrutper, de le prendre de court à son propre jeu. Un technosolutionisme qui nécessite de nombreuses montées en compéthences, une veille assidue quant aux risques d'objets techniques produisant des contiunums rendant souvent indistincts les moyens complexes par lesquels il fonctionnent.

Le moment du bug ou de la défaillance, peuvent créer des sursauts réveillants l'opérateur.opératrice qui, via l'outil sur sa machine, voulais atteindre quelque chose et n'y parvient plus (comme c'était prévu). Un bug, une défaillance, qui peut prendre bien des formes, une déconnectivité, la perte de données, une erreur 404. L'attendu devant soi peut se dérober, la promesse ne pas être tennue. Ces petits moments de défaite dans une chaine technologique (d'un ensemble d'agents/briques logicielles, codées par l'intelligence conjointe d'humains). Elle relève la non imanence de l'objet informatique qui, pour fonctionner, relève du miracle bien huilé de dépendances matérielles et logicielles (dont le web par exemple n'est qu'une pénultième couche, un moment particulier, celui d'une apparition). Le bug donc, rompt la chaine d'éléments connectés entre eux pour traiter l'information. Que ce soit au niveau du système d'exploitation, ou avant lui du fonctionnement matériel, de la carte mère par exemple, de l'écran, qui pour s'allumer doivent être electrifiés, une electricité extractiviste, ou après, de l'execution logicielle qui sait activer tel composant électronique tel la mémoire ou le disque dur et y stocker/charger de l'information, ou du système d'exloitation qui affiche un espace de travail, l'activité sur ordinateur est un long enchainement logique miticuleusement agencé pour fonctionner comme par magie. Nous n'en comprenons qu'une infime partie, celle qui nous est accessible. Si le système d'exploitation est fermé/propriétaire, cette opacité auggmente, nous gardant à distance, nous reffusant des acces et actions réservées au "système administrateur" pouvant lui activer ou désactiver des fonctions, modifier des fichiers de fonctionnement. Quand l'ordinateur est "malade", il faut le donner à réparer à un.e expert.e. On peut suivre des tutoriels sur Internets ou autre source d'enseignement, mais d'un coup, le contiunum fonctionel vol en éclat, nous rapelle à nos limites techniques qui rendent l'objet ou logiciel obsolète (et donc nous-même).

Le bug arrive comme une épiphanie ou plutôt un découvrement extraoridnaire, défaisant la convenance, défaisant le respect indut de la machine commandée par l'humain. L'humain qui peut être le bug, à l'origine du dysfonctionnement à moins que ce soit une feature, une fonctionalité nouvelle qui ait, en cascade, défait la magie. Le bug est synonyme d'inconnu de la source du problème qui se cache quelque part, qui nous échappe. On peut le re.connaitre pour l'avoir déja subit et peut-être avoir appris comment remettre les choses en place pour que ca refonctionne, retrouver l'ascendant, la maitrise.

Le code n'est pas neutre et ce qui nous semble être un bug peut être bien autre chose. Volontaire il peut s'agir d'une nouvelle fonctionalité désirée, implémentées par les developeurs.euses/programeur.euses qui, par internet, accèdent à nos espaces de travail et mettent à jour le code des applications qu'on utilise. Des fonctionalités qui nous sont imposées parfois et qui, mal testées, défont la magie, font autre chose que prévu et dégrade l'experience utilisateur.ice. D'autre fois le bug est malveillant et profite d'une vulnérabilité du système ou de l'application. Le hack malveillant tord le code pour qu'il fonctionne autrement, hors des conditions initiales qui limitent/cadrent son usage, hors des usages pensés à sa conception. Un hack tord l'espace d'execution autorisée par l'espace logiciel, que ce soit le système d'explooitation dans son ensemble (s'attaquant à une partie/endroit vulnérable) ou un site/une base de donnée, le hack subverti l'usage du code à d'autres fins que celles escomptées pour "fonctionner normalement".

Le bug bien qu'empéchant s'est glissé dans la machine et il faut le retrouver l'état normal de fonctionnement mais il n'est pas intentionel, il est d'ailleurs normal qu'il y en ait à mesure que les ensembles logiciels se complexifient ; les fases de débug/de test sont nécessaires. Le hacke exploite des bug ou en crée de nouveau pour s'ocroyer des droits sur la machine/le logiciel et ainsi nuire à l'experience utilisateur.ice et pire, voler des données personelles. Au contraire du bug qui retourne la machine sur elle-même révèlant une partie de la supercherie magique, le hackeur/la hackeuse ont souvent intéret à ce que leur intrusion ne soit pas repérée par le système (puis par son opérateur.ice). S'il est ciblé il faudra que l'intrusion laisse le temps d'agir pour extorquer ou esionner. Il ne s'agit pas seulement de rentrer sur une machine vulnérable mais bien souvent d'y installer quelque chose, un bout de code executé qui pourra par exemple envoyer des requetes servant à une attaque DDOS ou prendre des ressources pour du crypto-mining, héberger une page de pishing sur laquelle des victimes seront redirigées.

Dans ces cas de figure la nocivité est évidente pour l'entreprise ou utilisateur.ice pris.e pour cible. Cette modification du code outrepasse les droits et choix de l'utilisateur.ice pris.e pour cible. Ces modifications tentent de nuire par l'intelligence maligne/rusée. L'image du hacker tout.e puissant.e place ces individus comme hors du lot, comme catégorie sachante, au dessus de la moyenne, capable par son expertise de faire ou défaire un espace de travail/exploitation informatique, pour le meilleur comme pour le pire.

Certain.es agissant par altruisme (ou par profit rémunérateur légal), d'autres par appat du gain et capacité technique. Le reste de la population subit souvent les choix logiciels comme vennant de l'extérieur tout en espétant des améliorations, un progrés d'une version à l'autre, le plus souvent dans une consomation passive dûe à un manque de connaissance. Nous sommes ainsi tributaire de forces souvent extérieures qui ajoutent ou suppriment pour nous du code, des fonctionalités (que nous pourrons ou non désactiver). Le code limite ou encourage ensuite des usages et souvent, ce qui compte pour nous c'est que cela fonctionne, qu'on arrive à nos fins à moindre cout. L'ignorance que nous avons dans l'écriture et le fonctionnment de ces logiciels nous la payons par moment quand ça ne marche plus, quand nous ne savons pas réparer ou faire autrement, quand notre sentiment de liberté/capacité et attaqué. Aussi, le plus souvent, nous en restons au plus simple, à ce qui marche, sans vraiment oser changer ni rêver quoi que ce soit d'autre. Nous faisons/vivons avec ce qui nous est donné comme étant à la pointe, le plus à jour, qu'on nous promet comme le meilleur.

Or, quand le bug surgit il nous révèle à notre propre ignorance et incapacité tributaire de l'objet informatique. Stalman raconte que c'est la rage ressentie vis-à-vis d'une imprimante mensongère qui l'a motivé à ouvrir son capot pour comprendre d'où venait le bug (et qui s'avérait être une fonction logicielle consicente de la part des devlopeurs.euses aillant sciament voulu limiter la durée de vie des consomables, des cartouches d'encre). Ce récit originel l'aurait poussé à develloper une pensée autour de la liberté logicielle et des conditions nécessaires pour que l'utilisateur.ice ne soit pas pris.e au piège quand il/elle utilise un logiciel ou machine. Des degrés d'accès au code ou matériel qui rendent possible (et encouragent) sa modification et donc réparation, qui favorisent le hack vertueux. D'un côté l'ordinatuer/serveur/logiciel est toujours assugétissant en cela qu'il ordonne des données/infromations dans des epsaces cohérents/compréhenssibles (voire ludiques), de l'autre ces espaces peuvent nuire à l'experience escomptée. L'utilisateur.ice "fait avec", s'accomode ou non des convenances et inconvéniant, cherche ou non mieux allieur ou à modifier l'existant (cela demande du temps et des montées en compétence, du temps et un gout pour l'informatique). Il faut reconnaitre que cela n'est pas donné à tout le monde et que cela représente une première limite à la croyance dans une informatique transformatoire et émencipatrice pour toustes si elle n'est pas 'démocratisée' et rendue possible au plus grand nombre de personnes. Elle est souvent réservée à une classe apprenante, éduquée durant un parcours spécialisant, ou par nécessité face à l'adversité logicielle, la nécessité de s'émenciper par exemple de certains systèmes surveillants (contiunum technologique dans lequel les techniques numériques sont pensées, agencées).

Si le régime surveillant est majoritaire, alors il faudrait pousser vers des logiciels oppositionels à ce régime extractiviste par défaut, tournant en toile de fond et par lequel à un moment ou à un autre toute brique logicielle est pensée/concue/crée. En découle des bouts de logiciel/code produits/concus en fonction/dans le but d'absorber des donnée en vue de créer du pouvoir vectoriel, des points de force/tension agissant en sachant où tordre les affectes puis réactions de l'individu "pris.e dans cette machine". Certaines fonctionalités agissent ainsi tout à fait à l'encrontre de l'intéret de l'utiliateur.ice qui devient le produit, une source de revenu conditionné.e à l'intérieur d'un ensemble d'outils surveillants. Certaines de ces briques ne sont pas des bugs pour qui regarde la création logiciel comme la recherche de revenus capitalistes obtenus par la surveillance et absorbtion de données. Elles sont pourant là pour interagir sur les comportements ou cibler les comportements et proposer la meilleure offre publicitaire (par exemple). Cela est tout à fait naturalisé, intégré dans notre rapport d'utilisateur.ice captif.ves dans ces environements qui ne nous appartiennent pas tout à fait. Nous avons intégré que la gratuité avait un prix que nous acceptons tant que "ca fonctionne" ou que les fonctionalités nocives (qui ne sont pas des bugs) ne dégradent pas trop notre expérience ; la pub, nous avons appris à cliquer au bon endroit pour la fermer, il nous semble d'ailleurs qu'avant tout c'est à cela que sert l'accumulation de données, à nous profiler, de façon optimale, ce qui rend l'algosureillance presque "bienveillante" dans notre parcours d'acheteur.ice/consomateur.ice. Nous "faisons avec", nous nous habituons à ces environnements dont nous ne pouvons pas sortir car, de toute façon les logciels semblent tous concus pour cet environment que nous connaisons, ou encore, impossible de quitter ce réseau tant que nos ami.es/paires y sont. Des dépendances multiples qui augmentent le cout du changement de plateforme/environements. Une fois investi.es/engagé.es avec un logiciel, le quitter a un cout qu'on estime parfois mal (alors on reste).

Modifier les outils, /ou/ inventer d'autre vient certes émanciper leur usage, mais cela ne retire en rien le pouvoir du régime technologique qui les sous-tend. Changer de plateforme ou de protocole relève de la décision individuelle, certes exemplaire, mais ne défait que très partiellement l'emprise technologique générale. Pour autant, cette critique de non radicalité qui consiste à dire que les petits pas ne changent pas le régime globale — par exemple celui de la numérisation/mathématisation du monde — nient la perte de pouvoir que ces choix retirent à certaines entreprises. Cela réduit certains aspects néfastes, certains symptomatiques du régime critiqué. Si c'est celui de la surveillance, certains protocoles ou applications réduisent partiellement la prise d'entreprises des GAFAM par exemple. Elle créent d'autres interfaces et modalités d'existance numérique "à côté", grace à un degré d'autonomie variable mais effectif. Souvent c'est un aspect logiciel qui est apporté pour pallier aux fragilités d'un endroit de la production de l'information, un "patch" renforçant ce qui, avec le code d'origine (ou majoritaire), est exploité pour nuire aux individus (et profiter aux Etats-entreprises). Ceux sont des pas dde côté, jamais des retournements de tables ; plutôt des agencements défensifs que l'abolition des systèmes qui nécessitent ces aménagements/outillages ad-hoc à la situation opressante/problématique.

Il faut pour cela être au courant des pratiques de l'énemi (qui peut être un gouvernement, une entrepirse, un conjoint, un parti politique, etc). Une fois le danger repéré/conscientisé, il s'agit de mettre en place les defenses adéquates. Il faut pour cela un certain enseignement et veille quant aux moyens énemis. Si c'est l'extractivisme et l'acaparement des ressources minières qui sont critiques, alors, effectivement, le changmeent de logiciel ne résoud pas le problème qui est infrastructurel, toujours nécessaire/sous-tendant toute activité numérique par ordinateur. Les couches imbriquées de ressources s'empilent et nous choisissons d'ignorer certaines externalités négatives, de les nier, de "faire avec" comme un indépassable ou comme une négativité acceptable/tolérable au regard des bénéfices escomptés/connus. Ces arangements mmoraux avec nous-même nous autorisent à utiliser ces outils techniques que nous désolidarisons d'un ensemble technologique, comme faisant parti d'un tout. Ainsi, nous faisons comme s'il était possible de reconnaitre des usages positifs à encourager et d'autres néfastes, et comme si, les usages que l'on trouve positifs n'étaient pas dans la continuité de ceux que nous critiquons. Comme si, enfin, les moments de libération/encapacitation que permettent la techniques n'apartenaient plus au régime global de la technologie.

Cette acomodation morale nous autorise des usages que nous jugeons meilleurs et louables. Il faudrait donc modifier le code, le réformer, apporter des modifications suffisantes pour que le web, par exemple, redevienne un endroit respirable, non intoxiqué par des logiciels/scripts espions (et plus largmement un régime syntaxiale, des modalités architecturales, etc) pour retrouver le "web d'avant" ou le web du futur 3.0. Il faudrait traquer les bugs involontaires et les fonctionalités malfaisantes (codées à dessein), rebatir d'autres habitabilités numériques adjascentes ou carément hors de la porté des désirs capitalistes qui déploient une surveillance gouvernante globalisée (appliquée au web et à la gestion de l'information en temps de guerre). Nous faisons trop souvent comme si ces applications étaient distinctes, nous espérons que le régime contemporain de traitement de l'information ne servent pas à faire le mal. Notre capacité militantes est souvent réduite, boycotter des entrepises et leurs logiciels peut être un moyen de dire non, du moins d'essayer de ne pas participer à leur monde. Nous manœuvrons ethiquement à travers des complexités techniques qui semblent souvent indolores, sans effets (sinon mineurs) sur "le reste des mondes" extra-numriques. Critiquer la couche logicielle/applicative/protocolaire, peut ainsi sembler bien pauvre politiquement, n'apportant que des réponses supérficielles, s'attaquant peu aux forces énemies.

Dévelloper des protocoles alternatifs ne change pas le système, c'est d'avantage la preuve qu'il reste inchangé, nécessitant leur developement. Ce serait une preuve d'échec ou sinon l'évidence qu'en politique des forces opositionelles s'affrontent, luttant pour leur pouvoir et la diminution (voire inhilation) des pouvoirs adverses. Les outils que nous mettons en place sont d'ailleurs utilisés sans distinction par "nos énemis" (surtout s'ils tendent à la "neutralité", la non prise de partie en fonction du contenu ou de l'usage qui en est fait). Et on comprend assez facilement en quoi, par exemple pour les outils de sécurité/défense, de telles variables d'ajustements rendraient moins efficaces les outils/moyens permettant par exemple l'anonymat. S'ils devaint analyser l'usage et y attribuer un score de respectablité, alors l'outils serait faillible, bien plus tordable/hackable/vulnérable, réduissant son efficacité "radicale" recherchée (celle d'assurer avec un plus haut degré de certitude que, par exemple, une connexion et son contenu ne peuvent être lus/capturés par un tiers non solisité). La mise en place de tels leviers politiques, visant à réduire la radicalité du logiciel (ici de son efficacité à protéger l'origine des sources par leur anonymisation), produirait une crise de confiance en l'outil qui serait sans doute forké ou repris dans un état précédent ne contenant pas cette fonctionalité fragilisante. Nous pensons ici aux backdoors que certains gouvernements voudraient voir intégrés aux VPN et autres moyens de chiffrement (pour lutter contre le crime). Et il est effectivment tentant de chercher des solutions intermédiaires, permetant à la fois de la sécurité et de l'intervention politique sinon exengue de certains espaces numériques.