Un bouquin écrit par François Elie (agrégé de philosophie, ancien conseiller municipal orienté NTIC d'Angoulême ;) ) qui nous présente l'économie du logiciel libre en insistant très lourdement sur ce qu'il considère être la prochaine vague c'est-à-dire la mutualisation par la demande afin que les clients de logiciels réalisent des économies et de faire émerger des logiciels métier en logiciel libre.

Ce livre date de 2009. Je l'ai acheté fin 2010 mais je ne l'avais pas encore lu jusqu'à aujourd'hui : des déménagements successifs l'avaient fait prisonnier dans des cartons durant de longues années. :D

Mon avis

Ce livre est intéressant pour quiconque ne s'est jamais vraiment intéressé au financement des logiciels libres (comme moi) et qui croit que le logiciel libre peut être financé uniquement par de l'assistance payante / double licence.

Le militantisme de l'auteur en faveur de l'émergence de la mutualisation par la demande afin de faire émerger des logiciels métier est très intéressante. Le livre explique très bien les blocages : problème d'image, problème d'intérêt à agir, etc. Je nuancerai en disant que l'auteur en attend à mon avis beaucoup trop de la puissance publique qui pourrait jouer le jeu, faisant ainsi des économies, ce qui ferait apparaître cette mutualisation par la demande.

Au-delà de ça, ce livre, qui mélange économie et parfois philosophie, est parfois un peu difficile à suivre par son côté très abstrait. Beaucoup de répétitions sont également à signaler.

Informations et analyses intéressantes :

• Dans le numérique, on confond le coût de production et celui d'une copie supplémentaire pour en arriver au mythe du tout gratuit. Si le deuxième est quasi nul (copier un PDF ne coûte rien, par exemple), la production initiale d'un livre, d'un journal, d'un film, etc. a un coût. Le numérique ne permet pas d'échapper à la question du financement de ce coût de production.
  
  

• Bonne comparaison avec les maths : Pythagore voulait des maths privatrices, ses élèves ne devaient rien dire de leur apprentissage. Aujourd'hui, on a de la R&D ouverte (universités), de la R&D privée puis publique (ingénieurs), des profs de maths et l'évidence même que les maths ne peuvent être brevetés.
  
  

• Logiciel libre : innovation, accumulation de la connaissance, recombinaison des savoirs pour produire quelque chose de neuf, résistance aux chocs par rapport aux oligopoles, possiblement renouvelé plus souvent, éviter les coûts cachés des logiciels sur mesure (passer à la caisse auprès du même prestataire qui fera chauffer la CB à la moindre demande de nouvelle fonctionnalité). Le logiciel libre sépare la solution de la prestation de service potentiellement nécessaire à son installation, intégration, paramétrage, assistance. Cela permet donc une double mise en concurrence. Le logiciel libre est un bien pérenne pour les administrateurs : l'assurance de pouvoir piloter les nouvelles fonctionnalités désirées.
  
  

• Pouvoir de demain : qui détient les moyens de production ? Est-ce que le codeur est exploité au sens marxiste du terme ? Quand on vend du service au-dessus d'un logiciel libre, on ne rémunère pas la production du code en elle-même et c'est un problème.
  
  

• François Elie analyse le "marché" du logiciel libre en trois acteurs : le développeur amateur (que l'auteur nomme hacker… … …), le marchand et le client. Tous trois poursuivent des intérêts forts différents : le premier cherche la reconnaissance, le deuxième espère un gain, le troisième espère faire des économies. Le développeur amateur et le marchand des alliés quand il faut dire au client que libre ne signifie pas gratuit. Marchand et client sont de mèche quand il s'agit de dire que bénévolat, ce n'est pas assez sérieux, qu'il faut de l'assurance, de la garantie, de la maintenance. Le développeur amateur et le client sont d'accord quand il s'agit de rappeler au marchand qu'il ne sert à rien d'être un crocodile ou un ogre. C'est de là que viennent les tensions.

  • L'auteur conceptualise 3 étapes dans la vie du logiciel libre. 3 écosystèmes différents organisés en vases communicants : au début était le libre pour le fun ensuite est apparu l'open source pour casser la barrière idéologique et ainsi atteindre les consommateurs et l'industrie puis apparaîtront les logiciels métiers pour casser les problèmes de gouvernance induits par l'externalisation de la production du code. Il n'y a pas de retour en arrière possible (l'open source ne disparaîtra pas au profit du seul logiciel libre, par exemple).
    
    
  • Derrière ces 3 étapes, on retrouve 4 formes génériques de financement dont 1 sera temporaire espère l'auteur : bénévolat, détournement du bénévolat par des marchands (temporaire), investissement classique, investissement coopératif (plusieurs clients autour de la table).
    
    
  • Plus précisément, quels modèles économiques ?
    • Bénévolat. Auquel je rajoute les dons que l'auteur passe sous silence. Pour l'auteur, ce modèle ne résiste pas au détournement, à l'appropriation par des sociétés commerciales qui ne reversent pas leur travail. L'auteur signale également que tout le monde ne veut pas bosser bénévolement (mais qu'à l'inverse, d'autres personnes ne veulent pas être payées afin de ne pas transformer une passion en quelque chose de sans intérêt si elle devient astreignante) et que la rémunération de la production de code demeure un problème.
      
      
    • Modèle de service : édition/intégration c'est-à-dire rencontre entre un client et un produit et on brode autour pour fournir des fonctionnalités supplémentaires (exemple : un logiciel comme WordPress ou SPIP est simple à installer (et livrer un installeur simple ne ruine pas l'espoir de monter un business orienté support) mais il faut un thème et des plugins pour qu'il fasse totalement ce qu'on veut) ; modèle de valeur ajoutée : on vend de la garantie ; modèle de la double licence (édition communautaire et édition corporate) qui discrimine les utilisateurs ou modèle n-1 (on livre à la communauté la dernière version qui n'est plus utilisée) ; formation, etc.
      
      
    • Mutualisation par l'offre (investissement classiques) : plusieurs acteurs mutualisent leurs efforts de R&D dans un modèle de coopétition. Cela engendre une baisse des coûts de la R&D assumée par chaque acteur. Exemple de mutualisation par l'offre : les progiciels de gestion. Avec eux, plus besoin que l'équipe informatique de chaque société commerciale code le même bout de soft.
      
      
    • Mutualisation par la demande (investissement coopératif et j'y ajoute le financement participatif) : les clients se regroupent en consortiums/associations/GIE/autre pour exprimer leurs besoins et développer ensemble les logiciels répondant à leurs besoins. Cela engendre des économies : la mutualisation de l'offre fait que les marchands vendent X fois les mêmes logiciels, les mêmes développements. Ce n'est plus possible avec des briques en logiciel libres avec une granularité fine. La mutualisation par la demande se frotte à un problème d'image : chaque société commerciale se croit unique sur son marché. Leur faire accepter l'idée d'utiliser le développement tout ou partiel d'une autre société, pouaaaaaaa, quelle idée, quel déshonneur !

• Coopétition : collaboration opportuniste entre des acteurs qui ont des intérêts divergents, qui sont des concurrents mais qui, pourtant, ont intérêt à bosser ensemble au moins sur une partie de l'histoire. Exemples : les formats de fichiers ouverts sont systématiquement les plus répandus dans des secteurs concurrentiels comme l'aviation et la pétrochimie car justement, il faut avoir la même procédure pour causer aux sous-traitants. Même chose pour l'interopérabilité : les géants ont intérêt à la prévoir dès la conception plutôt que de l'implémenter après-coup car ce deuxième cas coûtera plus cher.
  
  

• Le logiciel libre est partit des infrastructures (informatique générale pour l'informaticien) puis a conquis le middleware (informatique intermédiaire pour l'informaticien au service de quelqu'un genre genre un connecteur standard pour un SGBD). Pour les logiciels métier, c'est plus compliqué car personne n'a d'intérêt ce qu'ils soient libres à part le client : le marchand veut vendre du temps de travail donc il ne doit pas dire qu'il dispose de briques génériques pour développer le logiciel demandé et le bénévole ne voit rien de fun dans le développement d'un logiciel de gestion de la cantine scolaire ou de la gestion de stocks ou de celle d'un réseau de parcmètres, par exemple.

  • Je pense que l'auteur loupe tout un pan quand il associe les logiciels d'infrastructures au fun : pour faire communiquer des machines en réseau, il a forcément fallut fournir l'implémentation. À la fin des années 80, on voit bien que c'est la grouille sur la multitude de réseaux existants et que les informaticiens cherchent en permanence à écrire des passerelles de l'un à l'autre. Un besoin d'universalité s'exprimait très clairement. Or, on ne peut pas faire de la communication universelle à bas coût sans normes et sans implémentations communes. La question du fun ne s'est pas posée, àmha.

• Il est vain de forcer les administrations publiques à utiliser du logiciel libre : il faut qu'elles le produisent. Soit en interne, soit en se regroupant pour exprimer un cahier des charges commun et faire développer ça. Sans ça, on a un problème d'œuf et de poule : les administrations peuvent seulement utiliser les logiciels déjà existants et s'il n'y a pas les logiciels métiers bah lala, elles resteront en logiciel privateur (et c'était très précisément l'argument de la centrale d'achat de l'informatique hospitalière en 2015, par exemple ! Voir http://shaarli.guiguishow.info/?82JClA ). C'est pour cela que l'on a vu émerger des plateformes de mutualisation comme celle de l'ADULLACT.
  
  

• Pour voir l'émergence de logiciels métier, il faudra se regrouper par catégories d'acteur, pas par types de projets. Exemple : il y a environ 250 métiers dans une collectivité. Celle-ci ne va pas adhérer et prendre part à 250 consortiums/associations de mutualisation par la demande.
  
  

• Une des clés du succès de la migration de la gendarmerie nationale française vers le logiciel libre n'est-ellle pas qu'il y a eu une reconnaissance officielle des logiciels écrits en interne de manière bénévole ? Ces gendarmes informaticiens amateurs savaient au moins de quoi ils avaient besoin pour exercer.
  
  

• Dans le monde matériel, on achète un objet pour le posséder. Dans le monde immatériel, acheter peut signifier faire exister quelque chose pour les autres alors qu'ils n'ont rien fait pour que cela arrive. Et évidemment, ça pose un problème aux tenants de l'ancien monde.
  
  

• Éric Raymond imaginait déjà les "appels de demande" c'est-à-dire l'expression d'un savoir-faire : je peux mettre sur pied tel type d'infra pour tant d'argent, je peux développer tel type de soft pour telle somme. Cela me fait penser aux CVthèques sur lesquels les personnes à la recherche d'un emploi diffusent leur savoir-faire et où les recruteurs viennent piocher.
  
  

• En 2009, l'auteur identifiait 2 risques pour le logiciel libre :

  • Logiciel privateur 2.0 : puisque l'exclusivité du code ne procure plus de pouvoir, les sociétés commerciales seront attirées par la maîtrise de la roadmap, par l'arbitrage qui à le droit de commit et de piloter le projet ainsi que par l'architecture de la plateforme de collaboration. C'est ça qui générera du pouvoir et brassera de la thune. Les géants du logiciel privateur se positionneront là.
    
    
  • IaaS : faire oublier les logiciels et l'idée de vouloir les maîtriser, les modifier, tout ça. Faire de belles interfaces pour attirer les particuliers et proposer de l'externalisation à bas coût pour les sociétés commerciales et c'est gagné. Mais ça entraîne un pouvoir sur les données personnelles.