Un éditeur de logiciel m'a appelé l'an dernier, un peu paniqué : son plus gros client venait de basculer sur une alternative open source, et il ne comprenait pas pourquoi. « Ils ont payé 40 000 euros de licences pendant six ans, et là ils partent sur un truc gratuit ? » Sauf que ce n'était pas gratuit. Le client avait calculé. Et son calcul, je l'ai refait avec lui.
C'est toujours le même malentendu. On compare le prix d'une licence à zéro, on conclut que l'open source est moins cher, et on découvre dix-huit mois plus tard qu'on a simplement déplacé la facture. Parlons des logiciels open source, de leurs avantages réels et de ce qu'ils coûtent vraiment — parce que les deux existent, et que la plupart des articles vous vendent un seul côté de la pièce.
Points clés à retenir
- L'open source ne supprime pas les coûts, il les déplace : de la licence vers l'intégration, la formation et le support.
- Le code visible n'est pas automatiquement sûr. Une dépendance abandonnée depuis trois ans est un risque plus concret qu'une faille exotique.
- La vraie question n'est pas « gratuit ou payant » mais « qui maintient ce logiciel dans cinq ans, et avec quel modèle économique ».
- Pour l'infrastructure et les briques techniques, l'open source gagne presque toujours. Pour les métiers réglementés et les processus critiques, c'est plus discutable.
- La conformité de licence se gère, mais elle se gère avant la mise en production, pas après.
Les avantages et inconvénients des logiciels open source, sans le discours marketing
Commençons par ce qui est vrai et vérifiable. Un logiciel open source, c'est un logiciel dont le code source est publié sous une licence qui autorise la lecture, la modification et la redistribution. Cette définition ne dit rien de sa qualité. Elle dit seulement qui peut regarder sous le capot.
Ce que vous gagnez vraiment
Le premier gain n'est pas l'argent. C'est le contrôle. Le jour où un éditeur propriétaire décide d'augmenter ses tarifs de 30 % ou de supprimer une fonction dont vous dépendez, vous n'avez aucun recours. Avec un projet open source actif, vous pouvez — en théorie — reprendre le code et continuer seuls. En pratique, peu d'entreprises le font. Mais la possibilité change le rapport de force.
Deuxième gain : l'absence de lock-in technique. Vos données restent dans des formats que d'autres outils savent lire. Je gère une PME industrielle qui a migré sa base documentaire d'une solution propriétaire vers un équivalent libre en une semaine, précisément parce que les fichiers étaient en format ouvert. Chez un concurrent resté sur du propriétaire, la même opération a pris quatre mois et coûté une fortune en prestation.
Troisième gain, plus discret : la vitesse de correction. Quand une faille critique touche une brique très répandue, la communauté publie un correctif en général en quelques jours. Un éditeur avec un cycle de release trimestriel mettra trois mois.
Ce que personne ne vous facture (et qui coûte quand même)
Passons à la partie désagréable. Quand j'ai repris mon premier projet open source en interne, j'avais prévu deux semaines d'intégration. Il m'en a fallu sept. Pourquoi ? Parce que personne ne m'avait dit qu'il fallait former l'équipe, écrire la documentation interne, mettre en place la supervision, et surtout décider qui serait responsable des mises à jour. Cette dernière question, à elle seule, a failli faire échouer le projet : trois mois après la mise en production, tout le monde avait oublié qu'il fallait patcher.
Le coût caché numéro un, c'est le support. Chez un éditeur, vous appelez quelqu'un. En open source, vous ouvrez un ticket et vous attendez — parfois une réponse, parfois rien. Il existe des offres de support commercial (Red Hat, Canonical, et beaucoup d'autres), mais elles coûtent souvent entre 15 et 20 % du prix d'une licence propriétaire équivalente, par an. Ce n'est plus gratuit. C'est juste facturé autrement.
Numéro deux : les compétences. Trouver un développeur qui maîtrise une stack open source précise est en général plus difficile que trouver quelqu'un formé sur l'outil du leader du marché, parce que la formation est moins standardisée. Sur un profil rare, comptez 10 à 15 % de salaire en plus.
Comparaison : ce qui change concrètement
| Critère | Open source | Propriétaire |
|---|---|---|
| Coût d'entrée | Faible à nul | Licence par utilisateur ou par serveur |
| Support | Communauté, ou prestataire tiers payant | Inclus dans le contrat |
| Évolutions | Décidées par la communauté ou l'éditeur du projet | Décidées par l'éditeur, selon sa feuille de route |
| Réversibilité | Élevée si les formats sont ouverts | Variable, souvent faible |
| Responsabilité en cas de faille | À votre charge | Engagement contractuel de l'éditeur |
| Délai de correction d'une faille critique | Quelques jours à quelques semaines | Dépend du cycle de release |
Ce tableau résume l'arbitrage, mais il ne le tranche pas. La bonne colonne dépend de votre taille, de votre criticité et de vos compétences internes — on y vient.
Sécurité, conformité et maintenance : là où ça se joue réellement
Le code ouvert est-il plus sûr ?
Réponse honnête : ni plus, ni moins. Le célèbre argument « avec plus d'yeux, tous les bugs sont détectés » ne tient que si quelqu'un regarde vraiment. Sur un projet populaire, oui. Sur les milliers de petites bibliothèques qui composent une application moderne, non. Et c'est là que le bât blesse.
La faille la plus banale n'est pas dans le logiciel. Elle est dans ses dépendances. Un composant utilisé par votre outil, lui-même dépendant d'une bibliothèque que plus personne ne maintient depuis deux ans. Vous n'avez jamais choisi ce composant. Vous ne savez même pas qu'il existe.
La parade est ennuyeuse mais efficace : exiger un SBOM (une liste de tous les composants embarqués) de la part de vos fournisseurs, et vérifier chaque trimestre l'état de maintenance de chaque dépendance critique. Sur trois projets que j'ai audités, deux contenaient au moins une bibliothèque abandonnée mais toujours chargée en production. Personne ne l'avait vu.
Et la conformité réglementaire ?
Autre sujet qu'on expédie souvent trop vite. Les licences open source ne sont pas interchangeables. Certaines vous obligent à publier vos propres modifications si vous redistribuez le logiciel ; d'autres non. Si vous intégrez un composant sous licence copyleft dans un produit que vous vendez, vous pouvez contractuellement devoir ouvrir une partie de votre code. Ce n'est pas une hypothèse d'école : c'est arrivé à des entreprises qui n'avaient jamais lu la licence.
Le RGPD et les exigences sectorielles ajoutent une couche. Un logiciel libre ne vous dispense d'aucune obligation de protection des données. Au contraire : comme vous hébergez et configurez souvent vous-même, la responsabilité vous revient entièrement. Chez un éditeur, une partie du travail est faite pour vous. En open source, personne ne signe à votre place.
Ma règle, après plusieurs années à faire ce diagnostic : si le logiciel touche à votre cœur de métier et que vous n'avez pas d'équipe technique solide, prenez du propriétaire. Si c'est de l'infrastructure, du stockage, du réseau ou de l'outillage interne, prenez de l'open source. Je défendrai cette position bec et ongles.
Que se passe-t-il quand le projet est abandonné ?
C'est le risque dont on parle le moins, et c'est le plus vicieux. Un projet open source peut disparaître du jour au lendemain : le mainteneur change de travail, se fatigue, ou l'entreprise qui finançait le développement arrête. Vous vous retrouvez avec un logiciel qui fonctionne, mais qui ne sera plus corrigé.
Le signal d'alerte est simple à surveiller : regardez la date du dernier commit et le nombre de contributeurs actifs. Un projet avec un seul mainteneur et aucun commit depuis huit mois est en sursis. Un projet avec trente contributeurs réguliers et une gouvernance claire (une fondation, un comité) est beaucoup plus solide.
Comment trancher : la grille que j'utilise en mission
Il n'existe pas de bonne réponse universelle. Il existe une bonne réponse pour votre situation. Voici les quatre questions que je pose systématiquement, dans cet ordre :
- Ce logiciel touche-t-il à une fonction critique pour mon activité ? Si oui, la question du support devient prioritaire sur celle du prix.
- Ai-je en interne les compétences pour l'installer, le maintenir et le patcher ? Si la réponse est non, ajoutez un budget support externe au calcul.
- Le projet est-il activement maintenu, avec plusieurs contributeurs et une gouvernance identifiable ? Vérifiez avant de vous engager, pas après.
- Quel est mon coût de sortie si je veux changer dans trois ans ? Formats ouverts, données exportables, dépendances documentées.
Si vous répondez honnêtement à ces quatre questions, la décision se prend presque toute seule. Le piège, c'est de répondre « oui » à la deuxième par optimisme. J'ai vu une équipe de deux personnes s'engager sur une solution libre complexe en pensant que « la communauté aidera ». La communauté n'a jamais répondu. Ils ont fini par payer un prestataire, plus cher que la licence initiale.
L'open source n'est pas une idéologie, ni une religion. C'est un mode de distribution, avec des forces et des faiblesses précises. Ses forces sont réelles : contrôle, réversibilité, réactivité, coût d'entrée. Ses faiblesses aussi : support à votre charge, dépendances invisibles, responsabilité intégrale, incertitude sur la pérennité du projet.
Le meilleur choix que j'aie vu n'était ni tout libre, ni tout propriétaire. C'était un mélange assumé : open source pour les fondations techniques, propriétaire pour l'outil métier critique, avec un budget support explicite dans les deux cas. La question n'est peut-être pas « quel camp choisir », mais plutôt : dans votre système d'information, quelle brique seriez-vous capable d'assumer seul si demain son éditeur disparaissait ? La réponse à cette question vaut mieux que n'importe quel comparatif.
