Notes de veilleNote de veille
Logiciel libre dans les achats publics : mode d’emploi
Un logiciel libre est gratuit à l'usage, pas à l'exploitation. Le faire entrer dans un achat public demande de déplacer la question : on n'achète plus une licence, on achète un service.
Une direction des systèmes d’information veut retenir un logiciel libre pour sa gestion des courriers. Le service des marchés objecte : on ne peut pas désigner un produit dans un marché, et l’on ne peut pas non plus « acheter » un logiciel gratuit. Les deux remarques sont justes, et elles ne bloquent rien. Elles imposent simplement de bien poser la question des achats publics et du logiciel libre : ce que l’acheteur public paie, ce n’est pas le droit d’utiliser le logiciel, c’est tout ce qui permet de s’en servir.
Ce que dit le cadre
En France, l’article 16 de la loi pour une République numérique du 7 octobre 2016 demande aux administrations d’encourager l’utilisation des logiciels libres et des formats ouverts lors du développement, de l’achat ou de l’utilisation de leurs systèmes d’information. C’est un encouragement, pas une obligation ni une préférence légale. L’État publie par ailleurs le Socle interministériel de logiciels libres (SILL), qui recense des logiciels utilisés et recommandés dans les administrations, avec des référents.
Le droit de la commande publique, lui, est neutre. L’article R2111-7 du Code de la commande publique interdit de mentionner une marque, une origine ou un produit déterminé dans les spécifications techniques, sauf si l’objet du marché le justifie ou s’il n’est pas possible de le décrire autrement, avec la mention « ou équivalent ». Le Conseil d’État a admis, dans une décision de 2011 concernant un marché de services portant sur un logiciel libre désigné, que ce choix n’était pas en soi discriminatoire, dès lors que tout prestataire pouvait librement s’approprier le logiciel pour répondre. La portée de cette jurisprudence doit être appréciée au cas par cas.
On ne met pas un logiciel libre en concurrence avec des logiciels propriétaires sur le prix de la licence. On met en concurrence des prestataires sur le service : installation, adaptation, support, hébergement, formation, maintien en conditions de sécurité.
Trois manières de rédiger
Décrire le besoin fonctionnel, sans préjuger du modèle. C’est la voie la plus neutre : les candidats proposent la solution de leur choix, libre ou propriétaire, et l’on compare le coût complet sur la durée. Pour que le libre ait sa chance, il faut alors évaluer le coût sur plusieurs années, et pas seulement l’investissement initial.
Exiger des propriétés qui relèvent de vos besoins réels. Formats ouverts, réversibilité, accès au code source, droit de modifier, absence de dépendance à un fournisseur unique pour la maintenance : ce sont des exigences légitimes quand elles répondent à un besoin établi (pérennité, souveraineté, mutualisation). Elles favorisent naturellement les solutions libres, mais restent ouvertes à tout éditeur qui les satisfait.
Acheter des services autour d’un logiciel libre déjà choisi. Quand le choix du logiciel a été fait en amont, par exemple après une étude comparative documentée, le marché porte sur les prestations associées. La justification du choix doit être écrite et conservée.
Les points de vigilance
Quelques points reviennent dans tous les projets. Vérifiez la licence et sa compatibilité avec vos usages : l’EUPL, licence publiée par la Commission européenne, est conçue pour le secteur public et compatible avec plusieurs licences courantes. Évaluez la vitalité de la communauté : contributeurs actifs, fréquence des versions, gestion des failles de sécurité. Prévoyez qui reversera vos développements, et sous quelle forme : un marché qui produit du code sans organiser sa publication prive les autres administrations de son bénéfice. Enfin, ne sous-estimez pas l’exploitation : un logiciel libre mal maintenu coûte plus cher qu’un logiciel propriétaire bien supporté.
Un logiciel libre n’est pas un choix idéologique ni une économie automatique. C’est une option qui mérite d’être évaluée avec les mêmes critères que les autres, sur la durée. C’est le principe de notre expertise benchmark et appels d’offres, sans commission des éditeurs. Le cadre général est détaillé dans notre dossier sur l’achat numérique public.
- Loi n° 2016-1321 du 7 octobre 2016 pour une République numérique, article 16.
- Code de la commande publique, article R2111-7.
- Conseil d’État, 30 septembre 2011, Région Picardie, n° 350431.
- Socle interministériel de logiciels libres (SILL), publié par la DINUM.
- Commission européenne, European Union Public Licence (EUPL) v1.2.