Le logiciel libre, initié par et pour les utilisateurs-développeurs informatiques (individus, puis entreprises) était une réponse directe, arrivée à peu près en même temps que la protection des logiciels par le droit d'auteur. La diffusion d’Internet, en plus des qualités intrinsèques de ce modèle de développement, a fait le succès des logiciels libres. Cette pratique a d'abord été perçue comme une hérésie et un déni du droit de propriété par des acteurs clés de l’industrie informatiques tels que Microsoft. C’est aujourd'hui un élément central de leur activité et de leurs opérations, pour permettre aux « produits et services Microsoft d'apporter le choix, la technologie et la communauté à [leurs] clients ».

Pour les utilisateurs ayant des compétences informatiques avancées, la disponibilité du code source et la possibilité d'apporter des améliorations eux-mêmes est indéniablement souvent moins coûteuse que d'attendre que l'éditeur fasse les mises à jour appropriées. Partager leurs améliorations leur permet d’avoir un retour sur leur proposition, voire des innovations complémentaires et cumulatives, mais aussi de voir ces modifications, expression de leurs besoins spécifiques, intégrées et maintenues dans les versions futures. Ces utilisateurs-producteurs ne sont pas nécessairement des individus, même si ce sont des individus qui contribuent, mais souvent des entreprises qui choisissent des licences ouvertes pour trois raisons principales, pas forcément antinomiques : (1) elles peuvent rechercher des collaborations pour partager les coûts de développement et faciliter l’innovation (contributions d’utilisateurs). C’est par exemple, Google avec Tensorflow, ou Meta, avec Pytorch, qui sont les deux principales solutions d'apprentissage automatique ; (2) elles peuvent également ouvrir un logiciel trop coûteux à maintenir par rapport à leur avantage stratégique, comme le navigateur web Netscape, mais qui les intéresse toujours ; (3) plus récemment, des projets libres planifiés ont vu le jour, généralement menés par un consortium d'entreprises, comme OpenStack, afin de créer une nouvelle norme industrielle, d’outils complémentaires à leur offre et nécessitant une forte standardisation. Ces différentes approches (R&D mutualisée, essaimage, complément d'actif) correspondent aux différentes stratégies de ce qui aujourd’hui appelé « innovation ouverte », dont le logiciel libre est sans doute l’exemple le plus emblématique.

Les écosystèmes libres se situent donc à l'intersection d'une communauté de consommation (orientée vers la définition des besoins) et d'une communauté de production (développant l'innovation pour répondre à ces besoins), qui est la même quand les utilisateurs sont les développeurs.

Des offres commerciales open source ancrées dans l'industrie IT

Mais assez rapidement, sont apparues des offres commerciales open source permettant à des utilisateurs de déléguer à des tiers (les entreprises open source), le suivi des projets, l’installation, l’adaptation et la maintenance des logiciels libres. Cela peut aller jusqu’à payer des entreprises comme RedHat pour accéder à des versions spécifiques de logiciels libres. Dans ce dernier cas d'ailleurs, la différence entre un distributeur classique et un distributeur open source peut paraître ténue, car la dépendance au fournisseur semble aussi forte. La vitalité des salons professionnels, comme Open Source Experience, montre que le logiciel libre et ses offres commerciales sont aujourd’hui intégrés dans les pratiques courantes de l’industrie informatique. Dans cette chronique je souhaite rappeler quelques éléments importants à considérer pour choisir une stratégie libre (pour l’utilisateur) et éventuellement des prestataires open source.

Le choix d'une solution logicielle résulte de l'examen de son « coût total de possession » (TCO), sur l'ensemble de son cycle de vie : (1) exploration : définition du besoin, recherche, évaluation y compris les tests, (2) acquisition : éventuels droits d'utilisation, adaptation aux besoins et intégration technologique, (3) intégration dans l'entreprise et dans les routines de ses employés : migration, formation et processus, (4) utilisation quotidienne : support interne/externe, maintenance et, en particulier, le coût des défaillances, les mises à jour techniques et fonctionnelles, le passage à l'échelle, et (5) abandon, renouvellement de la solution. Plus le projet ou la fonctionnalité porte sur une ressource stratégique de l'utilisateur qui doit durer dans le temps, plus il est important pour lui de pouvoir contrôler, ou d'être assurée de l'« évolutivité » de la solution globale (phases 4 & 5). C’est dans ces cas qu’il est le plus important de ne pas se laisser enfermer dans une solution, c'est-à-dire dépendre d’une entreprise incontournable pour la maintenance ou l'évolution future. Plus le logiciel répond à des besoins clefs de l’utilisateur, plus il va devoir investir pour s'adapter au logiciel, plus le coût du changement augmente (phases 2 et 3 du TCO), et ce, qu’il décide d’acheter une solution sur étagère, de fabrique sa propre solution, ou d’adapter une solution (éventuellement libre).

Un TCO à géométrie variable

Le choix entre fabriquer ou acheter dépend du type de besoins à satisfaire, mais aussi des capacités de l'utilisateur : ses compétences (et celles des employés pour les entreprises), mais aussi capacité à accéder à des intermédiaires pour pallier un manque de compétences internes. Les utilisateurs les plus compétents ne sont pas nécessairement ceux qui externalisent le moins : s'ils peuvent le faire, ils peuvent aussi être plus disposés à externaliser/payer parce qu'ils connaissent l'importance de leur besoin, peuvent mieux le définir et sont aussi mieux à même d'évaluer la qualité du prestataire.

Le TCO d’une solution « libre » est probablement plus faible, par l’absence de coût de licence d’utilisation, mais aussi en raison de l’ouverture du code qui facilite l’adaptation du logiciel, ainsi que l'interopérabilité et donc l'intégration dans le système d'information. C’est en tout cas les explications que donnent les entreprises qui adoptent ces technologies. Mais elles n'anticipent pas toujours les coûts restants d’adaptation aux usages individuels et organisationnels, ni les coûts de suivi du projet libre. C’est pourtant un élément clé d’une intégration réussie d’une solution à base de logiciel libre. Il faudra choisir entre s'appuyer sur les versions officielles, s'impliquer un peu plus (suivi des bugs et leur correction), ou, s'il s'agit d'un logiciel central pour l'infrastructure, encore plus, en faisant appel à des spécialistes du projet-logiciel, développeurs-contributeurs, pour être capable de garantir son adéquation avec les besoins internes, dans le long terme.

Autrement dit, les projets libres sont des organisations qui spécifient les besoins et le processus d'innovation pour y répondre ; adopter leur production soulève les mêmes défis que l'activité d'externalisation: plus on externalise, plus l’élément externalisé est stratégique, plus l’investissement en termes de temps et de compétences doit être élevé. Faire appel à un prestataire open source peut être vu comme une externalisation du suivi du projet libre, pour les mêmes raisons qu’une décision classique d’externalisation : économies d'échelle, car les mêmes solutions informatiques peuvent être suivies et maintenues pour différents clients, et économies de gamme, car, pour un même client, une même relation commerciale, plusieurs logiciels peuvent être gérés. Les technologies libres peuvent être considérées comme réduisant le risque de lock-in fournisseur et en offrant une porte de sortie, bien que théorique, en cas d'insatisfaction avec le fournisseur.

De l'importance communautaire plus qu'une affaire d'entreprise

Ces modèles commerciaux d'externalisation de logiciels libres peuvent être proposés par des spécialistes des logiciels libres (les SSLL, en référence aux SSII, renommées depuis peu ENL, pour entreprises du numérique libres, en référence aux entreprises de services numériques - ESN), ou par des spécialistes de l'externalisation intégrant des logiciels libres dans la bibliothèque de technologies/logiciels qu'ils suivent (par exemple IBM qui a récemment acheté RedHat en partie pour cette raison).

L'externalisation traditionnelle est basée sur une relation étroite avec les éditeurs, qui certifient leurs fournisseurs. Les fournisseurs libres eux, doivent développer une relation avec les projets. Pour chaque modèle de ces fournisseurs, ou modèles d’affaires open source, la ressource spécifique à laquelle on doit avoir accès est un droit (de contribuer, de gérer le projet, etc.) acquis en investissant du temps et des efforts dans le projet libre. Cela permet de mieux contrôler les ressources concurrentes du projet (droit de donner son avis sur l'orientation du projet, droit de gérer un module), car les équipes sont de taille réduite, ce qui fait que n'importe qui ne peut pas y avoir accès.

Chaque niveau de droit correspond à une capacité difficilement imitable, et à une proposition de valeur tangible : accéder à la technologie permet de la tester et d'assister les utilisateurs dans son utilisation (gestion de projet, formation) : modifier les capacités d'acceptation de la version officielle permet aux coordinateurs de garantir l'intégration dans le système d'information du client dans le temps (assurance, adaptation). La gestion de modules renforce cette position et permet un avantage concurrentiel dans certains domaines (lien entre la gestion de projet de l'utilisateur et la gestion de projet du logiciel, donc services d'intégration, d'adaptation, d'assurance). La participation à l'évolution du projet, aux côtés des développeurs principaux, est importante pour garantir le bon fonctionnement du logiciel, et pour accélérer la correction des bugs pour les métiers d'intégrateur (assurance). Enfin, la capacité à contrôler l’évolution du projet, sa visibilité et les acteurs qui y participent, repose principalement sur la maîtrise d'actifs immatériels dynamiques : la marque (protégée par les droits de propriété intellectuelle, mais qui n'a de valeur que si le projet est reconnu et est dynamique) mais aussi les bases de données (de bugs, par exemple), qui doivent être constamment mises à jour, protégées par le secret. Ces dernières sont essentielles dans les modèles basés sur l'assurance.

Ce modèle d'entreprise original, organisé pour favoriser la dynamique de l'innovation, illustre paradoxalement, l'importance du contrôle des actifs pour assurer un avantage concurrentiel. En d'autres termes, il est organisé autour d'un écosystème et non d'une entreprise. De plus, il est basé sur un contrôle dynamique de la production intellectuelle et beaucoup moins sur un contrôle statique. Lorsque la dynamique du projet s'épuise, les modèles économiques open source se rapprochent des modèles classiques, et d'autres ressources clés que la participation au projet deviennent primordiales. En tant qu’utilisateur de solutions libres, et client d’offres open source, il convient donc d’être aussi attentif à la qualité du prestataire qu’à la dynamique du projet, à la variété des acteurs qui y participent réellement, si on veut diminuer les risques de lock-in technologique, et surtout fournisseur. Et plus la solution choisie est stratégique, plus l’investissement devra être important, en adaptation, mais aussi en participation à la dynamique du projet libre qui la supporte.