De ce texte terrifiant de Christine Lemmer-Webber (juillet 2026), je retiens en particulier trois idées :

• lire du code, le comprendre, et y détecter des erreurs ou des failles est extrêmement difficile. Elle cite l'expérience de Ka-Ping Yee dans Building Reliable Voting Machine Software qui introduit intentionnellement des bugs dans une section de code d'une centaine de lignes et demande à des développeurs plus ou moins expérimentés de trouver les bugs dans cette section : le bug le plus subtil ne sera pas détecté, malgré de nombreuses heures passées à chercher.

• commencer à utiliser des générateurs aléatoires de code (soit-disant « IA ») pour programmer, quel que soit l'objectif initial, finit toujours dans une situation où ces générateurs empilent du code sur du code avec une supervision minimale, et où pour comprendre le code il faut faire appel pour l'expliquer à des générateurs aléatoires de texte (soit-disant « IA »). Elle cite plusieurs exemples.

• En conséquence, au vu du nombre et de la centralité des personnes qui se sont engagés dans cette direction, notre monde informatique est en train de moisir, avec une maîtrise du code et des logiciels produits qui diminue au fil du temps. On peut se réfugier dans de petites enclaves de code qu'on fait nous-même et qu'on préserve de la contagion, mais l'air du temps reste peu encourageant.

Translator's notes:

Is free software a convivial tool ? is first a talk in french by Benjamin Grassineau at a the free software congress Journées du logiciel libre in Lyon in 2024 (presentation, video). A transcription has been made by the transcription group of April, the main french organization for promotion of free software. Here is a translation of this transcription. It is somewhat hard to read, because written orality is not very readable in general, and translated written orality is worse. And also because I'm neither a professional translator nor a native english speaker.

In french, we have 2 distinct words for "free":

• gratuit, which means free as in free beer
• libre, which means free as in free speech (or free software)

The speaker uses both, so to distinguish between those meanings I use here the terms/neologisms gratis and gratisness for the quality of being free as in free beer and free/freedom for the second meaning.

This translation is licensed like the transcription, as Verbatim :

Verbatim copying and distribution of this entire article are permitted worldwide, without royalty, in any medium, provided this notice is preserved.

Reach and limits of the convivial tool concept (I. Illich) for a sociology of free software communities

Let me introduce myself. I'm Brenjamin Grassineau, sociologist. I'm currently working on a project in Paris to make a mobile gartisness zone between neighborhood in an action - research setting, and we're trying to see what impact it has on inhabitants. My thesis was about free software communities. I'm still interested and may work on this topic, but now I'm more focused on questions about gratisness zones.

I'll make a talk today to explore a question. I do not have an definitive answer, we're more on open question: is free software a convivial tool ?

First, to make it clear, we'll explore the question focusing on the convivial tool concept, which is somewhat different from the common meaning of "conviviality". Conviviality, in common sense, means friendly atmosphere, that's not the same thing.

To answer this question, I started by noticing that it may be a convivial tool, but it will depend on where we are in the broad free culture space. Let's notice first that the free software/culture space is not culturally homogeneous. There is, what we call in sociology, ideological trends that will correspond to actions and representations in which people will live. There are projects, economies that will correspond to each trend. That do not mean that these trends will fight each other, but we will be able to distinguish subcultures inside the free software movement. I made categories that seemed to me close to reality. I'll list them first, before going into the details.

1. The free software culture
2. The open source culture. These 2 are the most well-known trends.
3. The engineering culture
4. The commons culture
5. The convivialist culture

We'll first go through these 5 cultures and then we'll spend more time on the convivialist culture.

In the free software culture, we find a lot of representations, values and various political tendencies. On values, we mainly stand for individual freedom. There's a strong influence from research and university. There's this idea of permanent revolution. Obviously, one of the leading figure is Richard Stallman. There are others, but he definitely is one of them. In this culture, the enemy is the proprietary software. I tried to see which film could represent this culture. I found Star Wars: it's Republic against Empire, it's this way of thinking.

Then, there is the open source culture. Values will be to make profits, heralding economic freedom and, notably, economic competition. Politically, it will often tend towards libertarianism, but not always. If we think at a social background, it would be the Silicon Valley. On concepts, let's say that free software would be the perfect market.
A main figure of this culture is Eric Raymond, but he is not so much featured today.
As a cult fiction, I propose Dallas, do you agree with me ?

We often meet people more into a culture which is, let's say, the engineering culture. Important values are efficiency and pragmatism. Politically, we're quite close to a movement that was relatively developed in the 30s, the technocracy movement. A social background: engineering schools. On concepts, I put the pure and perfect distribution.
Among people that influenced this culture there is Norbert Wiener. As a fiction, I propose Foundation by Isaac Asimov.

Then, there is the commons culture. Values will be about equality and share. Politically, there's a strong influence from Marxism. The social background is the social and solidarity economy, with a leading intellectual which is Elinor Ostrom who worked on commons. The main enemy are the GAFAMs. As a symbolic fiction, I thought to the Smurfs, it could symbolize it well.

Then, there is the convivialist culture. Main values will be freedom and non-commercial. Politically, it's closer to trends such as convivialism or freudo-marxism with authors like Herbert Marcuse or Ivan Illich, which follows on Marcuse. On concepts, we will focus on open and horizontal network.
The main enemies will be technology, institutions and professionalization.
As a main fiction, I thought to The Year 01.

Let's say that each subculture develops an idea about what is free software as a tool. In the free software movement, what is developed is the idea of an empowering tool, while in the open source space we'll be more on a tool which, with his properties, will become a lucrative asset. In the engineering culture we'll be on a functional tool. In the commons culture we're developing shared tools. And, at last, in convivialism, we'll try to build a convivial tool.

The convivialist movement

It makes a lot of information, so now I'll present you the convivialist movement in more details.

What can we say ?

It's a movement initially influenced by three currents: the 70s counterculture, freudo-marxism - I told you earlier that there is an important author in this field, Herbert Marcuse - and political ecology. All these authors will produce a radical critic of "institutions" in a broad meaning: that could be school, medicine or tools they consider alienating, like the car.

There's also a radical critique against technology, in a broad sense, and in Ivan Illich theory there's a critic of what he calls professionalism.

More generally, in these different intellectuals works, there's a critical look on work as institution and of interiorized oppressions, that became subconscious. Then, each author will develop models about how to organize and provide trails to explore.

Ivan Illich will develop the convivial tool concept, while Herbert Marcuse will develop this idea of open society, the contrary of what he calls a closed society. And an author who goes further in action, in performance, like Jerry Rubin, will advertise dimensions like LSD consumption or living and organizing without money.

Ivan Illich

Let's now look at Ivan Illich.

He had his fame in the 70s, more specifically, we'll say, for three books:

• Tools for conviviality in which he develops his convivial tool concept ;
• The critic of mandatory schooling in his book Deschooling society ;
• and the critic of medicine in Medical Nemesis

He also introduced many concepts which are still in use, like what he calls the counter-productivity threshold, which means that past a certain threshold, institutions that were up to this point productive, improved the lives of citizens, become counter-productive and will eventually alienate people and constitute a radical monopoly.

He also developed the convivial tool concept against what he calls the radical monopoly.

Is it OK ? I put a lot of information in few sentences. I like the funnel principle: start by broadly presenting the field, then we narrow scope on convivial tool and how this concept could be useful for free software. We'll come to it.

The convivial tool concept for Ivan Illich

First, he defines the "tool" concept with a broad meaning. It's not only a material item, it's everything that can be used to reach specific goals and that persists. It can be a hammer - I believe that we are in material world here -, a legal text, a website or, more in the abstract, an institution in every sense: how someone can use an institution to make things he finds interesting.

We can summarize the way he defines the convivial tool:

1. First, the convivial tool will not create a for the user a dependency towards this tool, or a dependency towards other tools. "Dependency" is a concept which he often uses in his books: the tool will not create either a feeling of material dependency or material obligations. Counter-examples are cars and smartphones.
2. This tool can be used, produced and also destroyed by simple means, requiring minimal technology and means
3. The tool will remain under the control of whoever uses it

Let's quote his definition: « Tools foster conviviality to the extent to which they can be easily used, by anybody, as often or as seldom as desired, for the accomplishment of a purpose chosen by the user. The use of such tools by one person does not restrain another from using them equally. They do not require previous certification of the user. Their existence does not impose any obligation to use them. They allow the user to express his meaning in action.

More in details, there is mostly this dimension of freedom in the use of the tool. It's not something that will not impose constraints on the user, current of future.

There's also this matter of openness: nobody needs a diploma to use it. Here, he's thinking about the school and, implicitly, to other areas such as medicine. For example, we can't practice medicine without diploma, and it may be an extreme example, and to a certain extent teaching will be reserved by professionals and, at this point, it creates a dependency for users. It will be more clear when we'll talk about free software. He also emphasizes other aspects. The relation between the person and the organization who will manage these tools, if there is one, will be the relation of a user-producer, integrated in processes that are managed by open organizations. It relies on the idea that this openness should be enforced at the organizational level.

In other aspects, the production, the design of the tool, will be open to the involvement of everyone. He will not create entry barriers, nor barriers inside the activity, that is no division of work, and the work will not be directed by a bureaucratic and centralized authority.

We can go into details, but if we want to summarize the several points that Illich emphasizes, a tool will be convivial if, ideally:

• it is simple to use
• it is simple to produce and repair
• it is open to everyone, and notably it is not captured by a corporation ; there's freedom of access for the user ; it can easily be transformed
• we can easily have access to the production of tools
• the tool is not prescriptive ; we can connect this to concepts developed notably by Carl Rogers, that is we will use it to a goal we have, and not a goal that will reinforce itself, when at a certain point the tool is become over-efficient, deceptive, it will give more focus to the preservation of means than to the ends to which it was designed ;
• it does not create dependency, it stays under the control of the user;
• it's not over-efficient, it will not destroy other means to satisfy needs. Here, we can think to the theme of mobility: from the moment the car become an over-efficient tool, it will make walking obsolete and will create a sort of radical monopoly on the transport activity, on mobility. The convivial tool, on the opposite, is designed so that it allows different ways of doing things, to coexist next to each other ;
• an other aspect is that it will rely on forms of cooperation, and notably on the gift economy.

So let's examine these points.

Convivialist movement and free software culture

You'll tell me: "OK, nice, but what is the connection with free software ?"

It seems that this concept is well suited to certain dimensions of free software culture, at least in the convivialist part of it.

First, if we take the history of Internet, we can go back to Fred Turner's From Counterculture to Cyberculture in which he demonstrates the importance that counterculture had in the development of a certain type of computing.

We can also thing a the importance of the hacker culture.

In the free software culture, there are also elements that draws from the influence of some freudo-marxists intellectuals such as Erich Fromm. There is the revolutionary aspect we often find there, at least in words, in the fight against proprietary software.

There is the idea of spontaneous cooperation, of simplicity as a goal.

Obviously, organizations are thought in terms of communities.

And, more often than not, there's a suspicion against bureaucracy. We will focus on making, on the development, on the practical part of the job.

It connects also to a dimension of the convivial tool that I did not mentioned: this idea that the convivial tool must match an actual situation, we could say adhere to a local problem, something which is not taken out of his context, which stays within a limited scope.

On the question of free access, obviously, we're totally in. A lot of projects are open. De facto, there are a lot of projects that are also gratis: we can use the software freely - which does not mean we should not contribute by helping to develop the project.

Something we often stumble upon is the possibility to make an exit, which means we are not held hostages by the tools. We can't say this about some software which, today, are offered on smartphones and that fall under a different logic.

It seems that there is also a critic against work, which is not unanimous, with a certain form of meritocracy, this idea that everybody could equally contribute. Everyone can modify the source code.

There's also the promotion of amateur work and of volunteering.

With, I would say, a sort of rejection of constraints for work to focus more on what is called, in psychology, intrinsic motivation, that is the interest we will have, for example, to develop a software. What will be the center will be the pleasure to make things. It's important. If we're on extrinsic motivation, the idea is what we will expect as rewards, potentially on the long term. It coexists, but we'll say that the interest that we have into the activity by itself is, in my opinion, the most important.

I analyzed quite a bit, I talked a lot. We'll have the time to discuss.

Free software as convivial tool

Now, we focus more precisely on the convivial tool concept and not only on the convivialist movement.

There's the principle of open contribution, which means that everybody can contribute by developing, sharing, using it, by organizing a community or, going further, for example by creating a license which allows its distribution. All in all, it's close from the principle of open publication.

There's the principle of free access, which holds thanks to licenses, but not only, because there are also hardware constraints which are, I think, defined in the AGPL [GNU Affero General Public License].

There's the prohibition of dependencies: we always let users free to use other software or other formats and, what I said earlier, to make an kind of exit.

There's the non-discrimination principle: nobody is prevented from contributing to a software based on his diploma, and we can also use it freely. It's something important, because, we can say, it's not the case in education: without certain diplomas, you couldn't access to certain educational resources. We can be a contributor or an user, provided that this distinction matters, regardless of our motivations, our income, our status, our goals, etc. The non-discrimination principle is pushed strongly.

We often find, in some projects, the non-prescriptivism principle, that is we can act, for example develop a software, as we like it. First, we contribute and then there is moderation: was it liked or not ? It's the rule on some projects such as Wikipedia which, by itself, is not a free software but, let's say, which is strongly inspired by the free software culture. There's this idea, we could say, of de-purposing: we use it for the purpose we like. Whereas, on the opposite, on a proprietary software with a commercial vocation, the goal is imposed to the user. The user can be OK with it, it can be the subject of an "informal" negotiation who is happening through the market mechanisms and maybe it gives the expected result. Anyway, in free software the user does not fall under commercial interests, contrasting to a software that is developed in a commercial and proprietary logic.

There's also a strong emphasis on gift and share economy and a principle of community development in some free software communities.

I would say that there is an attention to the practical situation that I mentioned earlier, it's somehow the principle of primacy of facts. There's is no institutional interface that will disrupt the relation we have to the tool. The local situation will prime, taking into account some traditions inside a project, and that's also the peer community which will create meanings, rules inside the project. We could say this is a bit inductive.

Limits

In this talk, I put some limits to the convivial tool concept. Let's quickly examine these limits.

First, a visible limit today is the hypertrophy of "the digital" which leads to a kind of radical monopoly of computers on the means of communication. This hypertrophy can worsen when dependency to digital tools deepens. Illich uses the concept of destructive tool. When considering the ecological impact of digital economy, we can observe a destructive effect on climate.

With the convivial tool concept, we saw that there is this idea of open production. In some situations, a project could be more or less open to new contributors. Some communities may not always be welcoming.

Codes can also be made unintelligible in some cases. I do not have the technical skills judge by myself, but I've been told that this is something that, at a certain point, could limit the ability to grasp the code structure and to transform the tool.

Generally speaking, a question bothers me: should we continue to focus on licenses to preserve the conviviality of tools ? License are indeed a key factor, but we should also take the material aspect onto consideration.

Finally, there may be a risk in free software communities to stay apart from the rest of the world, a tendency which could actually become inhospitable. If think it's Pierre Mounier, if I recall correctly, who wrote a book on this point, who warned against free software becoming a ghetto (fr.) : will we head towards a revolution by free software or, on the contrary, to a marginalized community ? I'm not sure it was a book, I think it was an article.

So, in summary, the limits of free software as a convivial tool are all this background that tends to make a purported convivial tool less open, more exclusive or inducing dependencies.

Limits of limits

Now, let's notice that there are some limits to these limits. I think a first limit is that Free Software communities try to develop more simple tools, in the idea that technology should remain under the control of its users. We'll develop functional solutions, straight to the point and will avoid creating dependency.

I'd like to say that if there is a digital hypertrophy and a growing dependency to technology, the subject of conflict is the commercial aspect of it. And why ? Because commercial actors have an interest in creating alienating tools, what Illich would call manipulatory tool, that is a tool which produce a demand that companies will try to meet.

If we think about some projects going closed-source, I think that effectively the reproducibility of source code and the free software economy, which makes that we appreciate contributions, make this phenomenon rather unusual. More often, what will happen is the lack of contributors.

On the question of free software licenses, I think that what is fantastic is to see that there's also all a free software culture that developed around and largely exceeds the question of licenses. The JdLL [ndt: this event] are a good example, there's a complete fantasy developed around that aspect.

On the ghetto problem, i wonder if it's really a problem. Of course, comparing to 2000/2010 years, there's probably a relative weakening of free software culture, but it seems to me that subcultures take a very long time to emerge and that free software culture is, still today, fully alive and with a lot of resources indicates that, on the contrary, it is solid and can continue to grow.

I initially planned a part comparing the concept of convivial tool and the concept of common good. I think we can stop here and, if you like, we open the discussion.

Q&A

Public: We could talk about one point. Sometimes, there's this idea that free software is for a new elite.

Benjamin Grassineau : Actually, it is often perceived as such.

Public: Also because free software is mixed-up with technology. Elitism is no more about free software than about digital skills more generally. Elitism is not about free software in itself, there's a somewhat obscure image of technology.

Benjamin Grassineau : Actually, it can be perceived as such. If we'd like to develop a convivial aspect of free software, I think there are already many things made in that direction. But it also reveals how difficult it is.

When speaking of this convivial tool concept, developed by Ivan Illich, it's not something that will set up easily. It can be about some resources. Previously, we talked about walking. The fact that we can use our bodies to walk, we could say that it is a convivial tool. In some situations, it's difficult, it's not something we will spontaneously be able to do, we have to find solutions to walk.

On elitism, how to prevent that skills may become a barriers against the involvement, and how to make that everybody could, with his own skills, become also an actor and a producer of the tool ?

Public: Maybe a solution could be the creation of convivial tools for accessibility.

Benjamin Grassineau : That's an a example, for sure.

Public: So the tool can be a solution to this problem ?

Benjamin Grassineau : A convivial one. It relates to the question of technology. Indeed, a technical tool always work depending on other technical tools. Ivan Illich actually writes about this in his book, Tools for Conviviality. Nowadays, computing relies on electricity — maybe there are other means to make computers work —, but let's recognize that, globally, it mainly works with electricity. Some ways of producing electricity are not convivial. For example, would it be wise to open a nuclear plant ? Probably not.
It's true that at a certain point, the concept of a convivial tool will have a limited scope. It's about what we're looking at.

You had a question.

Public: Do you have an example of a convivial free software ?

Benjamin Grassineau : There are quite a lot. I often use a software called PmWiki, not very famous, to develop wikis. On one side, it's open, everybody can contribute easily. We can use it, obviously, for whatever goal we have. Yes, there are some examples.

Public : If my understanding is correct, when we say something is convivial, it is relatively to a need, to a situation and also to a community. In absolute terms, saying that it's convivial, it seemed to me a bit contradictory to what we said earlier, it's convivial for you. The question is to which ends this tool is convivial, it's something really tangible.

Benjamin Grassineau : That is to say, relative to the user, to the interest he can find in the tool. First, ease of access, it's a software available for use.

Public : Can a software be absolutely convivial ?

Public : Is this a relative or an absolute concept ?

Benjamin Grassineau : I think that it is actually a relative concept. What I tried to ease transmission of these ideas – by the way, I'm not sure I succeeded, maybe it's not very convivial, at least I tried – it's something which is relative to intents, to a community, and it's in this way that it's important to relate it to goals that are locals. We can say it depends on the situation.

Public : It's a goal to be convivial, for this conference !

Benjamin Grassineau : Is it a goal to be convivial ? Good question. Can means diverge from ends ? Would it be possible to use other means ?

Public: I know a very nice free software tool that is, from my point of view, really convivial, that could have helped to make this talk a bit more convivial, that is Sozi.

Benjamin Grassineau : I don't know this tool.

Public: It's an equivalent of Prezi, that we should forget. It's a tool to create dynamic presentations, put images, it's a bit like a mind map.

Benjamin Grassineau : OK. Let's say that communication is always a bit complex. Every time, it's a relation. I think that what is important is that ideas flow.

Public : I'm a computer technician and a GNU/Linux developer for individuals. There are some people who manage very well digital technologies, but there is a lack of conviviality, even in free software. It always seems complex. For those who are not used to computers, Linux is less complex than Windows, they will use it more easily, it's more intuitive, but I see nonetheless that there are some progress to make on icons, on handling. There are problems: if you're not fast enough when double-clicking, it does not work. If you move at the same time, it moves icons: these are problems that cause a lack of conviviality for software, including free software. Those developing software don't think about it. It's always created for the people who have skills and know-how and manage very well, but the majority, actually, manages quite badly. It's very difficult to approach computing when we don't have the culture, for beginners.

Benjamin Grassineau : In what I understand, there are 2 sides: the user side and and the producer side, a bit like in this talk. I think that many developers try to create affordable software, that are easy to use, but at the same time it's not always that simple. And on the user side, I do not agree with that. I think that there is a certain habituation to to Windows, to this kind of proprietary software. Maybe it's the case on some particular software, notably for professional software, but It seems to me that a distribution, for example Linux Mint, is not necessarily more complex.

Public : For people that are beginning to use computers, it's a hard step to pass.

Benjamin Grassineau : Wouldn't be lost in the same way with a Windows distribution ?

Public : Linux is more intuitive, but It seems to me that programmers don't put themselves in basic user's place enough. Everybody is mandated to have a computer to do administrative tasks at home today, and a lot of people are blocked.

Public : I'd like to pick up on this. I think that there are actually two things behind. Maybe it's something to take into account in the concept of conviviality: the representation of difficulty and obstacles. I also installed Linux for individuals. There are two types of individuals to which I installed, and even if it's the first time and even if they were not very comfortable with computers: individuals who where enthusiastic, who trusted themselves and who said « anyway, I will get through, especially if it's easier », there was no obstacle for them, it was smooth. The person started by having in mind that it wouldn't be more complicated, so he didn't invent obstacles.

Then, there is representation, because things like Windows, like a lot of proprietary tools, have a commercial strategy to make us believe that it's necessarily easy. I work in a local administration, and you have to realize that at a certain point there are people who are ashamed of not knowing how to do things on Windows or macOS and who don't dare to admit it, because marketing try to convince them that it's necessarily easy. Why ? Because it depicts competitors are necessarily more complicated and they build mental obstacles.

I think there is something to do about this, about these representations. It's a work for a long time, more generally. In politics, when we discuss about very technical topics – local heritage, buildings, town planning–, everybody can have a word to say, as if it was accessible, whereas it's extremely complex. But as soon as you say « digital », as soon as you say « technology », a lot of people invent artificial obstacles: « I don't get it », implicitly they get all the town planning principles for large and small cities, etc. There was a strong and deep marketing, for quite a long time, only about digital technologies, which corresponds to a market strategy of Microsoft.

We can take the example of cars. Initially, everybody knew how to take it apart, nobody really make up barriers, meanwhile it was complex. Today, this new marketing « don't mess with it, you must absolutely go to to the mechanic, it's complex » is approaching. It's important.

Benjamin Grassineau : That's where the convivial tool concept seems important to me.

It ends. Thanks.

Dans la conclusion de son livre Le consumérisme à travers ses objets, Jeanne Guien parle du boycott avec quelques idées utiles dans le monde d'aujourd'hui :

• attention à la récupération marchande du boycott : dans la société de consommation dans laquelle nous vivons, refuser d'acheter tel produit revient souvent à simplement privilégier tel autre, ou mettre en place un label ("éthique", "naturel", ce que vous voulez), donc toujours consommer.
• cette récupération marchande va de pair avec la vision de la société comme juxtaposition de consommateurs et producteurs libres et indépendants, sans structure sociale, c'est-à-dire avec l'idéologie libérale-individualiste.
• le refus individuel de consommer tel ou tel produit est tout de même une position éthique. Ça n'est pas une solution politique (et ça n'a pas forcément à l'être), ça n'est pas un objet de gloire personnelle, c'est juste un refus de s'engager dans des pratiques qu'on refuse moralement et c'est déjà utile, contrairement à ce que disent parfois les critiques des mouvements de boycott : "de toutes façons, ça ne change rien". Elle fait l'analogie avec le refus de violer autrui : ça ne suffira clairement pas à mettre fin à la culture du viol, mais pour autant il serait absurde d'estimer que, du coup, refuser de violer ne sert à rien.
• il est donc nécessaire de passer à la dimension collective du boycott: il faut le faire politiquement, s'organiser avec nos proches ou nos communautés (syndicats, associations, ...) pour faire disparaître les pratiques destructrices. C'est d'ailleurs historiquement comme ça que se passent les boycotts qui fonctionnent.

Les technologies IA sont d'essence fasciste, nous dit tante, militant antifasciste et technocritique.

IA, dans ce texte, signifie les algorithmes de reconnaissance de motifs et de génération aléatoires.

Plusieurs arguments.

l'IA comme violences

4 violences faites par les algorithmes d'IA :

1. Le vol des données pour l'entraînement
2. Les violences psychologiques imposées aux annotateurs pour éliminer les contenus choquants ingérés ou produits par ces algorithmes
3. La prétension à saisir tout le savoir humain, alors qu'il oublie/exclut mécaniquement les cultures non-écrites ou non-numérisées et qu'il renforce les biais de représentation
4. La violence contre les femmes et les minorités, permises par ces algorithmes (nudification...)

Utiliser l'IA, c'est accepter ces violences. Nous faire accepter une société de dominations et de violences, c'est le projet des fascistes.

Je trouve l'argument peu convaincant : le fasciste utilise la violence de façon visible et menaçante, pour en faire une composante de la société qu'il gangrène. Alors que les violences citées ici ne sont assumées que par une minorité des promoteurs de l'IA, ceux ouvertement fascistes (Thiel et Trump). En-dehors d'eux, des acteurs comme Anthropic, OpenAI ou Mistral tendent plutôt à taire ces violences ou, à défaut, à les nier ou les minorer.

J'adhère bien plus à tous les arguments suivants.

un outil contre les travailleurs

Par :

• la mise en concurrence de soi contre nos collègues (qui, eux, pourraient utilisent l'IA)
• la dévaluation du travail d'autrui (le dessinateur qu'on oublie au profit de midjourney)

... l'IA sert à détruire les solidarités ouvrières, à nous atomiser face au patron.

pour détruire la vérité et la confiance

Les chatbots s'attaquent aux institutions qui médient notre rapport au monde (journalistes, universités, ...) : en facilitant la prolifération de contenus plausibles mais faux, ils nous rendent incapables de distinguer les informations fiables de celles mensongères. Ils détruisent l'espace social dans lequel on peut débattre et vérifier l'information.

L'algorithme étant opaque par essence, on ne peut pas comprendre ou expliquer la réponse d'un chatbot, donc on ne peut pas l'accepter ou la réfuter: on ne peut qu'y croire ou pas. En ce sens, c'est un instrument de pouvoir : qui contrôle l'algorithme contrôle les croyances qui sont diffusées tout en marginalisant, en même temps, les institutions susceptibles d'établir des connaissances et permettant la confiance dans l'information.

pour détruire la bureaucratie, donc la démocratie

La bureaucratie est le mécanisme que les démocraties ont trouvé pour assurer l'application écrite et transparentes des règles par l'État, notamment des décisions qui concernent les citoyens.

En permettant de remplacer la bureaucratie par des algorithmes opaques au nom de l'efficacité, les technologies IA font primer l'arbitraire sur la transparence et rendent opaques les responsabilités dans les institutions qui exercent leur pouvoir sur et contre nous.

la volonté de restauration d'un futur glorieux, le mépris de la dignité humaine

La foi dans la singularité, et le paradis terrestre à venir grâce à l'IA fonctionne comme la nostalgie de l'ordre ancien des fascistes classiques et la volonté de restauration qui l'accompagne : un projet politique qui méprise les gens, en particulier les plus faibles, au profit d'un futur glorieux, empreint de puissance.

divers points

Utiliser l'IA, c'est intégrer une vision du monde structurée par les fascistes. C'est se faire embarquer involontairement sur un chemin qui mène au fascisme.

l'opensource, c'est merveilleux mais les tendances centrées sur l'individu et portant en étandard une "neutralité" morale et politique en font un espace qui ne s'opposera pas au fascisme. Les licences opensource ne permettent pas de s'opposer au fascisme.

conclusion : il fait détruire l'IA.

À l'occasion de la publication d'une vulnérabilité (escalade de privilèges utilisateur -> root) présente par défaut dans Omarchy, on (re-)découvre à quel point il est facile, ayant accès à la socket docker, de devenir root sur la machine qui exécute docker : il suffit de lancer un conteneur dans lequel on monte / (de l'hôte) sur un point de montage autre.

docker run --rm -v /:/hostroot alpine cat /hostroot/etc/shadow

En examinant le processus de décision ayant conduit au bombardement par erreur de l'école primaire iranienne Shajareh Tayyebeh le 28 février 2026, Kevin Backer analyse la raison d'être des processus bureaucratiques, c'est-à-dire les étapes de validation, discussion, réunions qu'une organisation s'impose via des règles internes pour aboutir à une décision puis mettre en œuvre ses actions.

Quelques idées qu'il propose :

• ces processus sont caractérisés par une certaine lenteur, et c'est une caractéristique nécessaire : cette lenteur et ces validations successives ménagent un espace permettant aux personnes de remettre les plans face à la réalité du terrain ou de la situation présente, puis faire des objections, annuler ou modifier l'action qui doit être menée (ici: la décision de bombarder telle ou telle "cible"), et ainsi éviter des erreurs.
• en conséquence, vouloir accélérer les processus et diminuer la friction du processus de décision, c'est supprimer des garde-fous qui protègent l'organisation contre des erreurs (et protègent celles et ceux sur lesquels l'organisation a du pouvoir, ici : les êtres humains qui, s'ils reçoivent une bombe américaine sur la tête, meurent - ça fait beaucoup de monde). Clausewitz le disait déjà au XIXe siècle
• par nature, l'institution a pour but d'éliminer le pouvoir discrétionnaire, celui des individus décidant seuls pour des raisons qui leur appartiennent. Pour ça, elle se dote de règles pour convaincre tout le monde (y compris elle-même) qu'elle obéit à des procédures objectives. Cependant, ces règles doivent en permanence être interprétées et adaptées à la situation rencontrée à l'instant t : c'est le rôle des humains à l'intérieur de faire ce travail d'interprétation, mais sans le reconnaître officiellement car ça contredit l'idée de processus régulier ne laissant pas de place à la subjectivité, donc ça contredit la raison d'être de l'institution. Il y a nécessairement un tension. Gros risque du coup: que quelqu'un dénonce l'arbitraire et la latence des processus puis les supprime au nom de l'efficacité.

En résumé, "les procédures formelles obscurcissent le travail qu'on est en train d'effectuer".

Il fait ainsi l'histoire du projet Maven de l'armée américaine :

• but: accélérer et automatiser la désignation des "cibles" et leur élimination (la "kill chain")
• timeline: 2017-aujourd'hui, monter à 1000 décisions par heure
• moyens employés :
  • algorithmes de machine learning (interprétation des images et données capturées par les satellites et drones, consolidation et enrichissement des informations, classification et priorisation des "cibles") de façon à automatiser toutes les étapes.
  • nouvelles interfaces pour centraliser les informations et incarner / accélérer le workflow
• Google cède devant ses ingénieurs en grève contre la participation à ce projet, c'est Palantir qui exécute le contrat
• résultat notable : le bombardement d'une école primaire en Iran par erreur le 28 février 2026.

Il inscrit cette histoire dans celle de la stratégie militaire américaine.

Note plus personnelle : l'analyse est intellectuellement stimulante. Néanmoins, le point de départ choisi (la guerre) est particulièrement horrible, et ça produit des idées moralement indéfendables, par exemple quand il est met en contrepoint des bombardements irréfléchis américains en Irak (2003) qui font régulièrement des victimes civiles ou alliées ceux, plus mesurés, des britanniques au même moment : il se dégage l'impression qu'il y aurait une "meilleure" façon de mener des bombardements. Il est nécessaire de rappeler qu'aucune guerre n'est juste, qu'aucun meurtre n'est acceptable, fût-il le produit d'une armée équilibrée laissant la place à la décision humaine.

Microsoft est une entreprise transnationale. L'expertise coûte cher. Les clients de Microsoft ont souvent besoin de l'aide de Microsoft pour résoudre des difficultés techniques qu'ils rencontrent. Les salaires étant beaucoup moins élevés en Chine ou en Inde qu'aux US, ça coûte beaucoup moins cher à Microsoft de faire appel à des ingénieurs non américains pour faire ce travail d'aide technique.

Mais pour intervenir sur des systèmes traitant d'informations classifiées, par exemple ceux du ministère de la Défense US, il faut être 1/ américain et 2/ habilité pour ça. Des ingénieurs américains, habilités et experts techniquement, ça coûte très cher. Pour proposer un tarif attractif et remporter le marché "cloud" du ministère de la Défense US autour de 2013, Microsoft a donc mis en place un système d'escorte numérique : l'ingénieur qui propose les étapes de diagnostic et réparation n'est ni habilité, ni américain, mais ces étapes sont exécutés par "l'escorte", un américain habilité. Problèmes:

• ceux qui sont recrutés comme "escorte" ne sont pas forcément compétents techniquement et ne peuvent juger de si les actions sont légitimes ou si elles piratent les systèmes
• ceux-ci sont parfois des sous-traitants, pas employés par Microsoft directement
• manifestement, Microsoft a dû décrire ce système dans le contrat cloud dans de toutes petites lignes, car personne n'est au courant au sein du ministère de la Défense US.

Margaret Mitchell répond aux objections de ceux qui aiment les LLMs et que ça débecte qu'on désigne ces systèmes comme des "perroquets stochastiques", terme qu'elle et d'autres ont proposé dans le célèbre article On the Dangers of Stochastic Parrots: Can Language Models Be Too Big? (mars 2021).

Au passage, elle signale plusieurs mécanismes qui entretiennent l'illusion d'intelligence autour des LLMs :

• l'association forte, dans nos sociétés, entre "capacité à écrire / parler" et "intelligence" :
  • Elle rappelle que les personnes sourdes (/ muettes) sont souvent perçues comme déficientes intellectuellement, encore aujourd'hui
  • alors que la génération d'images a progressé en même temps que la génération de textes, ce sont surtout les modèles de langue qui sont décrits et perçus comme"intelligents"
• les métaphores employées pour décrire ces systèmes (intelligence, raisonnement, compréhension, attention) renvoient à l'idée de cognition et fabriquent l'illusion d'intelligence. Les métaphores sont utiles et aident à comprendre le fonctionnement des algorithmes, mais dans ce cas elles participent à entretenir l'illusion d'intelligence. D'où la nécessité de proposer d'autres termes, plus précis, colle celui de "perroquet stochastique".

Margaret Mitchell rappelle aussi que tous les systèmes d'IA ne sont pas des LLMs, et que "perroquet stochastique" désigne uniquement les LLMs.

Au-delà des critiques usuelles sur les IA génératives, Pauline Harmange se demande comment ces outils ont pu "prendre" aussi rapidement dans la société : pourquoi nos pairs vont-ils si rapidement les adopter, en dépit de toutes les bonnes raisons de ne pas le faire ?

C'est parce que "la société" a réussi à nous convaincre individuellement de notre nullité, de notre impuissance, de notre incapacité à créer, à inventer. La machine fait de la merde, mais plus jolie que ce qu'on est capable de faire avec nos petites capacités limitées (certes moins jolie que si on travaillait vraiment nos créations, mais bien plus rapidement).

En réponse, l'auteure propose de faire, ensemble. Faire des trucs de nos dix doigts, dans le monde matériel. Faire et imaginer avec d'autres, peut-être mal, peut-être imparfaitement, mais ensemble. Pour rappeler que, le réel, les liens humains, c'est vachement chouette.

Le syndicat américain des auteur.e.s de science-fiction et fantasy a décidé d'interdire l'usage de générateurs automatiques pour les œuvres concourant aux Nebulas, et cette interdiction s'est faite plus ferme sous la pression de la communauté des lectrices, lecteurs et auteur.e.s. Erin Underwood, actrice, s'oppose à cette interdiction générale dans une lettre ouverte.

L'écrivaine australienne Foz Meadows (wikipedia) publie une réponse au vitriol "contre l'IA". La seconde partie répond argument par argument à la lettre d'Underwood, la première partie réaffirme que l'IA est une technologie fondamentalement nocive.

Extrait (traduit en français) :

L'IA est nocive sur tous les plans. C'est un outil de faussaire imprécis bâti sur le vol du travail de création, la destruction accélérée de l'environnement, les violations des droits humains, l'augmentation des risques psychiques, la sextorsion, l'effondrement de l'éducation et l'érosion de notre sens collectif de la vérité. Et la seule raison pour laquelle elle est partout malgré tout ces dégâts, c'est parce qu'une poignée de miliardaires sociopathes évoluant dans un domaine lourdement dérégulé ont renchéri dessus en la foutant partout.

Quelques centaines d'universitaires français appellent à l’objection de conscience face à l’IA générative en raison des dégâts environnementaux, sociaux (pour les travailleurs du Sud et l'espace informationnel du Nord) et politiques (concentration du pouvoir dans quelqued méga-firmes américaines).

En réponse, le philosophe Gregory Chatonsky défend le devoir de l'université d'explorer les techniques et refuse d'essentialiser l'IA dans sa forme actuelle définie par des intérêts privés (l’IA n’est pas même si elle existe). En réponse aussi, et dans le même esprit, une contre-tribune affirme que refuser l’IA à l’université, c’est en abandonner le contrôle au capitalisme.

À ces deux textes, le doctorant en humanités numériques Louis-Olivier Bossard répond dans refuser l’IA sous le signe de l’agnotologie que :

• tout développement technique a des conséquences matérielles et sociales
• les sujets d'étude et méthodes d'expérimentation sont contraintes par des régles et interdits (expérimentations humaines ou animales, conséquences sociales de telle ou telle expérience), c'est l'éthique scientifique qui veut ça
• en conséquence, et il se fait là presque provoquant, que l'ignorance est activement produite, délimitée, décidée collectivement et politiquement par les chercheurs et la société qui les entoure

L'idée d'une AGI est passé en 20 ans de délire mystique marginal à courant de pensée endossé par une partie de la tech américaine. L'auteur note plusieurs caractéristiques de cette idée:

• Un caractère de "foi", i.e. une irrationalité de ses arguments (impossible d'argumenter, tout discours contraire alimente la croyance)
• l'opposition entre ceux qui y croient, qui "ressentent" cette imminence, et les incrédules
• le sentiment d'importance métaphysique donnée à leur propre travail par ces croyants chez OpenAI et consorts (fabriquer Dieu, ça flatte l'égo)

Il relie ça au complotisme (le lien me semble assez mal étayé, je ferai davantage le lien avec une foi religieuse).

De façon plus intéressante, Will Douglas Heaven décrit :

• l'origine de cette notion (entreprises et personnes) : Webmind, DeepMind, OpenAI, Goertzel, Legg
• leur obstination dans un milieu tech qui les prend pour des fous
• la +/- conversion de Thiel à ces idées, les légitimant ensuite à coups de $ en finançant OpenAI (2015) tandis que Bostrom la légitime intellectuellement (SuperIntelligence, 2014)
• certains circuits de diffusion (LessWrong)
• la façon dont elles sont actuellement utilisées pour drainer des financements qui apparaitraient sans fondements sinon

Découvert via la recension qu'en fait Hubert Guillaud, Intelligence artificielle générale : le délire complotiste de la tech, dont je recommande la lecture.

Au détour d'un chouette article présentant des failles identifiées sur Pagure, le système de gestion des compilations de paquets pour Fedora, Thomas Chauchefoin constate :

We could also be overriding Python files of the application. It worked locally on a Pagure deployed from source, but when validating the finding on the staging instance, we noticed that this idea and a few other ones simply didn’t work! The instance must have been deployed from the Fedora RPM packages where application files are owned by root.

Moralité: quand on déploie une application, il faut s'assurer si possible que lors de son exécution elle n'ait pas les privilèges nécessaires pour modifier son code source ou même sa propre configuration.

Pour rassurer leurs clients sur la sécurité de leurs données, les fournisseurs cloud ont d'abord promis: "nous chiffrons les données au repos", empêchant qu'une sauvegarde égarée ou un disque décommissionné et perdu se promènent avec les données des clients.

Puis ils ont dit : "on va plus loin, on vous permet de chiffrer les données au repos avec VOTRE clé, c'est vous qui maîtrisez le stockage des données" (exemple avec Azure SQL). Et ça, c'est franchement bidon, car pour que les données soient utilisées dans le cloud, il faut leur transmettre notre clé. Que ce soit le client qui l'ait définie dans son coin ou le fournisseur cloud qui l'ait définie, à la fin c'est le fournisseur cloud qui l'a pour permettre aux systèmes de traiter les données. Donc en terme de contrôle, le client ne gagne pas grand chose.

Ce qui permet d'aller réellement plus loin, c'est la "virtualisation confidentielle", i.e. la capacité que peut avoir un système infonuagique de faire tourner du code et des calculs chiffrés, sans pouvoir connaître le contenu des données traitées. Et c'est un peu plus compliqué, notamment parce que ça nécessite une transparence totale de l'infrastructure du fournisseur cloud.

2 évolutions s'opèrent en parallèle en matière de logiciels :

• de plus en plus de logiciels promettent le chiffrement de bout en bout, rendant le fournisseur incapable d'accéder aux données de l'utilisateur (exemple: signal, réseau Matrix, Nextcloud avec chiffrement de bout en bout, etesync)
• de plus en plus de logiciels sont développés comme "applications web", servies depuis un site internet (exemple: le client Matrix element.io, Microsoft Office365, ...)

En l'état actuel des technologies, les deux objectifs ne sont pas totalement compatibles. Une application qui fait du chiffrement de bout en bout, si on y accède via le navigateur depuis un site internet tiers, sera vulnérable à une attaque sur ce site internet : un intrus peut modifier l'application de sorte à faire fuiter les clés de chiffrement de ceux qui l'exécutent dans l'intervalle, ou trouver une faille (type XSS) de façon à exfiltrer les clés de certain.e.s utilisateurs ou utilisatrices. À l'inverse, une application "desktop" sera moins rapidement attaquable : il faut que l'attaquant publie une version vérolée, puis que les utilisateurs mettent à jour, avant que l'attaque soit effective. Si la validité des mises à jour est contrôlée à l'aide d'un mécanisme de signature cryptographique (comme c'est le cas des mises à jour logicielles des distributions Linux), l'attaque est rendue encore plus compliquée.

Pour les applications web, l'équipe derrière eteSync propose une solution sous forme d'extension de navigateur qui vérifie la signature GPG des pages renvoyées par le serveur.

• github (comme gitlab, non mentionné par l'auteur) permet de lister les clés SSH publiques d'un utilisateur
• quelqu'un a compilé la table de toutes les clés, permettant de retrouver un utilisateur github à partir de n'importe laquelle de ses clés présentes sur github
• en pratique, les clients SSH annoncent la clé publique au serveur pour lui demander si elle est acceptée par celui-ci avant d'utiliser la clé privée

Tout ça mis bour à bout permet de :

• pour un serveur SSH : tenter de trouver l'identifiant github du quidam qui se connecte
• pour un curieux : en essayant toutes les clés publiques de la table (très long!), trouver l'identifiant github de personnes ayant accès à un serveur en particulier
• (non mentionné par l'auteur) établir la correspondance entre les comptes d'un même développeur sur plusieurs plateformes (savoir que HaxORR_du_91 sur github est Robert Dupont sur gitlab)

Il s'agit donc d'une belle fuite involontaire de données personnelles.

Pour se prémunir de telles attaques, il convient d'utiliser des clés SSH dédiées aux connexions sur les forges. Par exemple en générant une clé dédiée :

$ ssh-keygen -f ~/.ssh/id_git_ed25519 -t ed25519

Puis en indiquant uniquement ces clés à github/gitlab et en indiquant dans votre .ssh/config :

Host github.com gitlab.com [ou tout autre forge]
    IdentityFile ~/.ssh/id_git_ed25519.pub

Notez aussi que si vous utilisez une clé GPG publique comme back-end d'authentification SSH (ce qui est une bonne idée en soi !), on peut recalculer votre clé SSH publique avec l'option --generate-ssh-key (merci au collègue qui m'a transmis l'astuce).

L'OSINT a de beaux jours devant elle!

PyPI, le point central de distribution de paquets Python, demande aux mainteneurs des paquets les plus populaires de sécuriser leur compte avec un second facteur d'authentification, afin de limiter le risque que le compte soit compromis et tous les utilisateurs du paquet par ricochet.

Armin Ronacher s'élève vivement contre cette nouvelle exigence, trouvant gonflé de demander à celui qui a gentiment et gratuitement partagé son travail de supporter la charge de la sécurité des utilisateurs de son travail. Après tour, ça n'est pas "sa faute" si son travail devient populaire.

Dans Yes, I have opinions on your open source contributions, James Bennett lui répond que nous sommes tous et toutes utilisatrices des paquets Python (et pas seulement les grosses entreprises qui ont de l'argent), et que si la communauté propose de fixer des règles pour nous protéger tous, c'est être singulièrement asocial de les refuser.

Le premier commentateur sur Linux Weekly News remarque avec malice que les obligations qu'Armin Ronacher craint de voir imposées ensuite par PyPI (signature cryprographique, standard de qualité, traitement diligent des problèmes de sécurité, mesures en cas de défaillance du mainteneur) sont précisément les garanties apportées par les dépôts des distributions Linux. Ce sont les attentes des utilisateurs, y compris (à tort) quand ils utilisent PyPI, npm, cargo ou autre dépôt lié à un langage de programmation.

The lie marketers told us in the late 1990s and early 2000s (and that many in tech still believe as an article of faith) was that people don’t dislike ads, they only dislike irrelevant ones. [...] The problem is, to make ads ever more relevant, Big Tech firms have argued they must collect vast amounts of information about people to build dossiers on them that can predict their wants and needs.

Une faille permettait à une application confinée via flatpak de s'échapper de son confinement.

On apprend au passage qu'une application flatpak qui a accès au bus DBus org.freedesktop.Flatpak peut s'échapper en exécutant flatpak-spawn --host <commande>. C'est le cas notamment de l'IDE VSCode (et de sa version sans télémétrie VSCodium), ce trou dans la raquette étant nécessaire pour accéder à un terminal non confiné depuis l'IDE, comme documenté sur le dépôt de l'empaquetage flatpak de VSCode

• L'agent GPG stocke le mot de passe de la clé en mémoire vive.
• Ce mot de passe est lui-même chiffré : un dump de l mémoire vive ne permet pas de le retrouver en clair.
• Néanmoins, la clé de chiffrement de ce mot de passe étant aussi en mémoire, on peut la retrouver et déchiffrer le mot de passe à partir d'un tel dump : en l'état, la protection apportée par le chiffrement est illusoire (la fonctionnalité est présentée comme pouvant servir à terme avec un TPM)
• La clé privée protégée par le mot de passe est-elle aussi stockée en mémoire vive?
  • Si oui, il est inutile stocker aussi le mot de passe, c'est absurde. J'en déduis que non
  • Si non, ça fait une petite protection contre attaquant peu probable qui aurait accès à la mémoire vive (accès très difficile à obtenir) mais pas au système de fichiers (accès a priori moins difficile).