L'essentiel des notions abordées dans ce texte proviennent des travaux de Bernard Stiegler et de l'association Ars Industrialis.
Préambule: constat initial sur le modèle économique des logiciels libres
L'origine des rapports de force dans l'industrie logicielle
Contrairement au modèle industriel classique, dans le domaine des logiciels, la possession de l'outil de travail n'est pas un point majeur et déterminant (bien souvent chaque employé dispose chez lui d'un ordinateur au moins aussi performant que celui dont il dispose sur son lieu de travail).
La possession des moyens de distribution ne l'est pas non plus (on peut facilement diffuser des logiciels via internet en dehors de toute structure commerciale).
Le rapport de force dans l'industrie logicielle est bâti sur la propriété intellectuelle.
Note: pour information, le code informatique en tant qu'œuvre de l'esprit est régi par le code de la propriété intellectuelle, au même titre que toute œuvre écrite, et du seul fait de sa création, naissent automatiquement des droits d'auteur. Cependant, les droits d'auteur des salariés de sociétés informatiques sont automatiquement cédés à l'employeur (et il n'est pas nécessaire de le mentionner dans le contrat de travail pour que ce soit le cas).
Voir http://www.industrie.gouv.fr/guidepropintel/fiches_pratiques/le_logiciel.htm (3.1 A: Les droits d’auteur sur un logiciel appartiennent à son auteur, à son créateur, y compris si ce dernier a agi en exécution d’un contrat de commande. Il en va autrement lorsque le logiciel est créé par un salarié dans l’exercice de ses fonctions. Dans ce cas, l’employeur se voit automatiquement attribuer les droits patrimoniaux (c’est-à-dire le monopole d’exploitation) sur le logiciel.)
Faiblesses de la propriété intellectuelle
La propriété intellectuelle sur les logiciels est difficile à défendre: les logiciels sont par nature des objets numériques que leurs producteurs souhaitent diffuser le plus largement possible (la plupart du temps).
Cela rend leur protection particulièrement délicate : faciliter la diffusion impose de faciliter l'accès, faciliter l'accès expose le logiciel à des attaques plus nombreuses, et une fois qu'une version "crackée" est disponible, elle est très massivement distribuée (au-delà des logiciels, cela vaut bien entendu pour tous les objets numériques).
D'un point de vue purement pragmatique, un objet numérique a vocation à être a priori un bien public.
En effet, le malheur des objets numériques est que leur valeur d'échange est nulle quelque soit l'importance de leur valeur d'usage: on peut donner un objet numérique à un tiers et continuer à s'en servir soi-même, on peut même le donner 10 000 fois sans s'en trouver appauvri pour autant.
C'est ce en quoi, d'un point de vue purement pragmatique, un objet numérique a vocation à être a priori un bien public.
D'autre part, la propriété intellectuelle sur les logiciels est vaine : dans une partie de plus en plus grande de l'industrie logicielle, le principe de la barrière technologique n'est plus applicable (on nomme "barrière technologique" la protection de ses innovations par le simple fait que ses concurrents doivent faire un investissement en recherche et développement important avant d'être en mesure de produire des solutions au moins aussi bonnes que les siennes).
En effet, la puissance des technologies logicielles, la rapidité de leurs évolutions, et la quantité de personnes qui les maîtrisent créent un monde extrêmement dangereux pour qui espère vendre un logiciel sur lequel il a investi : d'une semaine à l'autre, n'importe qui dans le monde peut publier un logiciel qui rend son propre logiciel complètement inintéressant.
Ce nouveau concurrent peut apparaître n'importe quand, il est possible qu'il propose son logiciel à un prix très nettement inférieur, voire même gratuitement. Et ce nouveau concurrent peut tout aussi bien être une énorme entreprise employant des milliers de développeurs [1] qu'une équipe de deux amateurs ayant développé leur solution sur leur temps libre.
[1] comme Google dont la sortie des produits met à chaque fois sans dessus dessous le secteur concerné (il y a un avant et un après Gmail, il y a un avant et un après GoogleMaps).
Pragmatisme des logiciels libres
L'approche open source prend acte de ces faiblesses, elle consiste à ne pas protéger les logiciels (ils sont ouverts, tout le monde peut en voir le code source) et à les diffuser gratuitement.
Note sur la terminologie: le terme anglais complet est Free and Open Source Software (FOSS), alors qu'en français, on se contente de Logiciel Libre (LL), ce qui convient très bien puisque libre signifie aussi bien que le logiciel en tant qu'objet est libre, i.e. qu'on peut librement en disposer et s'en servir, mais aussi qu'en tant que sujet, le logiciel est libre, i.e. que personne ne peut se l'accaparer et le contraindre. Dans la suite du texte, on emploie indifféremment le terme opensource et libre.
L'approche open source pose en fait que la meilleure façon de protéger un investissement dans un développement logiciel est d'en libérer le résultat.
Bien sûr cela revient à renoncer à en vendre des licences, mais cela permet d'espérer que les éventuels concurrents (dont on a dit plus haut qu'ils étaient probablement nombreux et redoutablement efficaces) préféreront collaborer à cette solution open source (i.e. en devenir des contributeurs) plutôt que de créer une solution concurrente. Au-delà de cette relative maîtrise des offres concurrentes, l'autre atout de l'open source est, pour l'investisseur, la mutualisation des coûts (plutôt que d'assurer seul les tâches de maintenance, d'évolution, de mise en compatibilités avec les différents systèmes, etc, on bénéficie des efforts de tous les contributeurs).
(Brève) description du fonctionnement
Les logiciels libres sont des œuvres publiques communautaires construites de manière contributive : chaque personne participant à la réalisation du logiciel partage son code avec les autres, il est versé dans les sources publiques du logiciel, chacun peut s'en servir librement et éventuellement les modifier.
Ce qu'on nomme la communauté opensource d'un tel logiciel est l'ensemble des contributeurs du logiciel. La communauté s'agrandit par le recrutement de nouveaux contributeurs, le mot recrutement étant ici entendu plus comme adhésion à un idéal (que constitue le logiciel développé) que comme embauche par une structure de production.
Les contributeurs peuvent participer à titre privé, ou bien faire leur contribution dans le cadre de leur travail salarié (auquel cas, les sociétés qui les emploient sont identifiées comme des sociétés contributrices).
Chaque communauté suit des règles (des règles techniques vis-à-vis du logiciel mais aussi des règles sociales) et dispose d'outils de communication clairement établis (channels de discussion IRC, sites web de références, dépôts de code sources, etc.).
Déficit d'otium dans le travail
La place de l'otium dans le travail
Pour chacun, l'acceptation du travail s'effectue en comparant ce que le travail rapporte (un salaire, des contacts humains, de la satisfaction, de la fierté, etc.) et ce qu'il coûte (une aliénation d'une grande proportion de son temps, du stress, de la honte, etc.).
Si cet équilibre est correct, le travail est supportable.
Malheureusement, la pression économique (en premier lieu, mais il existe d'autres facteurs) conduit à accepter des conditions où cet équilibre n'est plus correct.
De ce fait, le travail va être vécu comme une contrainte, éventuellement comme une souffrance.
Il présente alors un déséquilibre entre otium et negotium.
L'otium, bien que son sens premier soit l'oisiveté, n'est pas une notion étrangère au travail.
L'otium, bien que son sens premier soit l'oisiveté, n'est pas une notion étrangère au travail. On peut bien sûr considérer que le travail se cantonne au champ du negotium, et que le temps libre (le reste du temps finalement) soit le temps de l'otium.
Le fait qu'on dispose de temps libre en dehors du temps de travail peut être effectivement un soulagement, mais cela ne corrige pas en soi le fait que le travail est accablant et constitue une souffrance. C'est la limite très claire et très simple du modèle dit de société des loisirs.
Relevons à titre d'exemple que les employés de France Télécom disposent de conditions très favorables en terme de congés, d'aménagement de leur temps en fin de carrière, etc., pour autant cela ne semble pas suffisant pour qu'ils se sentent tous heureux dans leur travail.
L'otium est la disponibilité intellectuelle, il est le temps de la création, le temps du soin de soi-même et du soin des autres, il peut donc tout à fait être le temps du travail bien fait, du travail dont on est fier, du travail qui sert.
C'est notamment ce que décrit Christian Fauré dans son texte sur le travail en perruque, bien que là aussi (comme pour les loisirs), on se positionne en dehors (ou disons en marge) du temps de travail. Alors qu'il paraît essentiel de donner toute sa place à l'otium dans l'exercice même du travail.
Le cas de l'industrie logicielle
Dans le cas particulier de l'industrie logicielle, on peut observer facilement le déficit d'otium.
Chacun, quel que soit son poste, perçoit que les choses pourraient être mieux faites mais continue à les faire ainsi car il y est tenu par un réseau de contraintes.
Par exemple : le développeur va développer un logiciel conformément à ce que son chef de projet lui demande, le chef de projet oriente les développements conformément à ce qui est demandé dans le dossier de spécifications, ce dossier a été établi par un assistant à la maîtrise d'ouvrage, qui lui-même s'est appuyé sur les besoins exprimés par un client.
Chaque développeur sait qu'aucun plan d'assurance qualité ne garantira jamais qu'un logiciel est de bonne qualité.
Ce réseau de contraintes mène d'ordinaire à un travail mal fait, un travail de piètre qualité. Il est d'ailleurs symptomatique que ce qu'on appelle l'assurance qualité soit si développée dans l'industrie logicielle. Mais chaque développeur sait qu'aucun plan d'assurance qualité, aucun processus de gestion, aucune norme, ne garantira jamais qu'un logiciel est de bonne qualité, car ces mécanismes sont purement formels. Un logiciel est de bonne qualité quand il est réalisé avec soin.
Or les systèmes d'assurances qualité posent en fait qu'il n'est pas nécessaire que le développeur prenne soin de son logiciel, car c'est le système lui-même qui garantit la qualité du résultat. On dé-responsabilise le développeur, on se contente de ses efforts. Il faut voir là une certaine prolétarisation, on peut aussi parler d'une infantilisation du développeur (voir plus loin: Majorité du développeur).
La réalisation du logiciel ne s'inscrivant pas dans une démarche de prise de soin, le développeur va en concevoir une certaine honte, une honte qui va entraîner des conséquences néfastes.
Tout d'abord, cette honte conduit à une baisse d'implication, le développeur ne souhaite être associé d'une manière ou d'une autre à ce logiciel, au contraire il cherchera à s'en séparer (c'est pourquoi les projets qui s'éternisent ou qui échoient en mode maintenance sont souvent vécus comme une souffrance).
D'autre part, cette honte va aussi se convertir en ressentiment à l'encontre des utilisateurs du logiciel ("ils veulent encore qu'on change tel bouton de place", "ils se plaignent encore de tel bug dérisoire").
Plus globalement, le logiciel n'étant pas le fruit d'une démarche de soin du développeur mais simplement de son labeur contraint, il n'est pas vécu comme la projection d'un idéal, il ne va pas être un objet de désir pour son auteur. Le développeur ne s'y retrouve pas, cela le mène à en rejeter la paternité (et, de fait, du point de vue légal, comme expliqué plus haut, on lui a en effet confisqué ses droits d'auteurs, on le conforte donc bien dans ce sentiment de perte de paternité).
Note: comme mentionné ci-dessus, le déficit d'otium mène au néfaste, il me semble que les notions otium/negotium sont correlées aux notions fastus/nefastus. Fastus (dans dies fasti par exemple) étant dans son sens immédiat le temps de la fête pour les Romains, mais il désigne aussi le temps de la justice, le temps de la chose juste.
Le logiciel libre, vecteur d'un ré-équilibrage du couple otium/negotium
Recentrage sur le savoir-faire
Comme expliqué plus haut, adopter la voie du logiciel libre revient (en général) à renoncer à vendre des licences.
Les entreprises du monde du libre se rabattent donc sur la prestation de services : étant identifiée comme experte du fait de ses contributions (gratuites) sur tel logiciel, une société va plus facilement s'attirer les demandes de prestations (payantes).
Ces prestations peuvent être de natures très variées : conseil, réalisations sur mesure, formation, maintenance, hébergement de services en ligne, etc.
En conséquence, la valeur de la société dépend non plus de ses brevets, de ses marques, ou de quelques autres possessions, mais de ceux qui sont identifiés comme étant à l'origine de l'expertise revendiquée (et qui sont de toute façon ceux qui produisent les prestations effectivement), c'est-à-dire des membres de l'entreprise.
C'est d'autant plus vrai que le monde du logiciel libre met avant tout en valeur les personnes.
La communauté reconnaît ses héros : ceux qui ont beaucoup apportés, ceux qui aident le plus les nouveaux arrivants, ceux qui expliquent le mieux les choses, etc.
Ce sont eux qui sont mis en lumière bien plus que les sociétés qui les emploient.
C'est également le cas pour toute société de prestation de services, mais ce qui est intéressant ici, c'est que l'employé voit grandir la considération qu'à pour lui sa société non plus seulement en fonction de sa pure capacité de production (qui ramène directement de la valeur), mais aussi en fonction de la considération qu'a pour lui la communauté.
Son statut au sein de la communauté peut d'ailleurs éventuellement renverser les liens hiérarchiques : un employé peut être un leader dans la communauté alors que son propre supérieur n'a pas un tel statut, de ce fait il sera en position de prendre des décisions sur l'avenir du logiciel alors que son supérieur n'a pas la légitimité pour le faire.
Dans une certaine mesure, libération des sources implique libération de l'employé vis-à-vis de l'employeur.
Ainsi, bien qu'employé, il est aussi reconnu en tant que contributeur. Cela constitue le point de départ d'une revalorisation du développeur.
Démarche de soin
Le contributeur ne veut pas décevoir la communauté, il cherche à être apprécié pour son travail, il souhaite également que les utilisateurs de son logiciel soient toujours satisfaits, donc il va s'attacher à réaliser ses contributions le mieux possible.
Notamment il rédigera le code le mieux possible, il fera des tests, il fournira de la documentation, il répondra aux demandes de correction, il respectera les usages établis par la communauté. Autant de choses que les sociétés d'informatiques ont relativement du mal à obtenir de leurs développeurs bien qu'ils sont leurs salariés, c'est-à-dire qu'ils sont effectivement payés pour le faire (alors qu'une communauté opensource ne rémunère pas ses contributeurs). De même, il développera une vraie curiosité (alors que la prestation marchande favorise a priori l'incuriosité).
Tout se passe comme si le développeur reconnaissait inconditionnellement qu'il avait des devoirs vis-à-vis de sa communauté, devoirs qui le conduiront à redoubler d'efforts, voire même à prendre sur son temps personnel, alors qu'il aura tendance à renâcler à satisfaire ses clients ou ses employeurs. Soulignons que cela constitue un échec flagrant en matière de gestion du personnel (et soulignons symétriquement que l'approche opensource est une stratégie de gestion du personnel particulièrement habile).
Le logiciel libre rétablit la relation de désir du développeur pour son logiciel.
Cela découle du fait élémentaire que le logiciel libre rétablit la relation de désir du développeur pour son logiciel. Un contributeur n'est jamais forcé de contribuer, s'il le fait c'est parce qu'il considère que son travail améliore le logiciel, et s'il accepte de le publier, c'est parce qu'il considère que ce qu'il a fait est correctement fait. Donc tout conduit à ce qu'il ressente et assume pleinement la paternité de son code, et qu'il s'inscrive dès lors dans une relation de soin.
Ce renversement de perception devient vite général : le soin qu'il porte à son code va naturellement être étendu à la communauté et aux utilisateurs qui se servent de ce code. Ainsi, là où le développeur se sentait accablé par les bugs rapportés par ses clients, il est au contraire heureux qu'on lui rapporte des bugs sur ses contributions, heureux parce que cela l'aide à améliorer encore son travail et heureux parce que cela prouve qu'on se sert de son travail au point même qu'on en détecte des imperfections qu'il lui avait échappées. Note: il n'y a ici aucune exagération, la réaction la plus répandue quand on reçoit un rapport de bug suite à une contribution est de dire merci (alors que je n'ai jamais constaté cela dans un rapport client/fournisseur traditionnel).
Ce renversement est parfois même viral : il arrive que les clients des sociétés de services en logiciels libres intériorisent la démarche au point qu'ils ne se considèrent plus comme les commanditaires d'une réalisation devant respecter un certain nombre d'exigences mais comme financeurs d'une évolution d'un logiciel opensource, et donc à ce titre comme contributeurs. Dès lors, ils deviennent eux-mêmes les défenseurs du logiciel auprès des utilisateurs internes, et là où ils auraient plutôt eu tendance à renvoyer les reproches des utilisateurs vers la société prestataire, ils vont au contraire argumenter et militer en faveur du logiciel dont ils se sentent désormais partie prenante au même titre que les développeurs.
Majorité du développeur
Dans Prendre soin de la jeunesse et des générations, Bernard Stiegler renvoie à la vision de Kant sur la majorité citoyenne : être un savant devant un public de savant.
De la même manière, le contributeur à un logiciel libre se voit conférer un statut de majorité.
Le développeur devient codeur devant un public qui lit son code et dont il lit le code.
En effet, il devient codeur devant un public qui lit son code et dont il lit le code (car le client, lui, en général ne lit pas le code, et cela change l'attitude du codeur).
Une communauté opensource est surtout un ensemble de codeurs qui partagent leur travail. Contribuer, c'est améliorer le logiciel, mais c'est aussi montrer son code à ceux dont on a lu le code. On se retrouve en face de ses pairs et ils jugent et apprécient le travail fait.
Conservation d'une part de negotium
Si le logiciel libre est de nature à introduire une part d'otium dans le travail (dont on vient de dire que cela avait de nombreuses conséquences bénéfiques), il n'en reste pas moins que les sociétés travaillant dans le domaine du logiciel libre s'inscrivent dans un contexte économique tout à fait traditionnel.
Autrement dit, leur impératif constant est de dégager suffisamment de valeur pour assurer leur avenir. Une société dont les salariés seraient tous d'excellents contributeurs passant 100% de leur temp à produire des logiciels distribués gratuitement ne serait pas viable.
On a parlé plus haut des différentes types de prestations payantes proposées par les sociétés de service en logiciel libre pour se garantir des revenus. Il va sans dire que ces prestations devront être produites par les salariés, qui vont se trouver confronter à des exigences de délais, des attentes des clients, des impératifs de production, etc.
Le modèle d'organisation du travail du monde opensource ne consiste pas à transformer le travail en loisir.
Il faut donc bien voir que le modèle d'organisation du travail du monde opensource ne consiste pas à remplacer le negotium par l'otium de façon idyllique (transformer le travail en loisir en quelque sorte), mais bien à articuler les deux d'une façon intelligente et efficace.
Cette articulation n'est jamais simple, et peut aboutir à des situations paradoxales : on va aider gratuitement un inconnu vivant de l'autre côté de la planète et on facture une aide similaire à ses clients dans le cadre d'une prestation de support, on produit gratuitement telle nouvelle fonctionnalité, mais on fait payer telle autre. Et il n'y a pas de solution pré-établie pour les gérer.
Mais le résultat est bien un ré-équilibrage entre negotium et otium, ré-équilibrage qui s'avère vertueux aussi bien pour les employés que pour la société.
Conclusion
Les caractéristiques de l'industrie logicielle (dont certaines ont été soulignées au début de ce texte) expliquent qu'un modèle d'économie contributive y ait trouvé sa place.
Mais cela ne prouve pas qu'il soit impossible de l'appliquer dans d'autres domaines.
On insiste souvent sur les aspects techniques qui ont rendu possible le développement opensource (facilité d'échange et de distribution du code informatique, large disponibilité de l'outil de travail, existence d'un cadre légal avec les licences opensources, etc.).
Ces avantages sont indéniables, mais il me semble que la clé du succès réside bien plus dans le ré-équilibrage entre negotium et otium tel qu'il a été décrit ici.
Seuls 16% des salariés Français recommanderaient les produits de leur société.
Selon une étude du cabinet Forrester Research, seulement 16% des salariés Français recommanderaient les produits de leur société. Ce chiffre est terrible, il est symptomatique du déséquilibre otium/negotium, il prouve l'énorme échec du monde du travail actuel, et il devrait susciter une vive inquiétude chez les dirigeants. Comment envisager que le travail puisse être correctement fait dans une telle situation ?
Alors que dans une communauté opensource, 100% des membres recommanderaient leur logiciel (à priori, sinon ils ne resteraient pas dans cette communauté). Du fait de la démarche de soin dans laquelle il s'inscrit et du fait du statut de majeur qu'on lui reconnaît, il y a une adhésion naturelle du développeur pour son logiciel.
Non seulement ce chiffre de 16% semble particulièrement dangereux pour la pérennité du système traditionnel (ce qui devrait inciter à faire évoluer ce système), mais il n'y a pas de raison (technique) pour qu'on ne sache pas améliorer ce pourcentage dans les autres secteurs économiques que le logiciel libre.