path: root/talermerchantdemos/blog/articles/fr/when-free-software-isnt-practically-superior.html

<!--#set var="ENGLISH_PAGE" value="/philosophy/when-free-software-isnt-practically-superior.en.html" -->

<!--#include virtual="/server/header.fr.html" -->
<!-- Parent-Version: 1.79 -->

<!-- This file is automatically generated by GNUnited Nations! -->
<title> Quand le logiciel libre n'est pas supérieur, en pratique - Projet GNU - Free
Software Foundation</title>

<!--#include virtual="/philosophy/po/when-free-software-isnt-practically-superior.translist" -->
<!--#include virtual="/server/banner.fr.html" -->
<h2> Quand le logiciel libre n'est pas supérieur, en pratique</h2>

<p>
par <a href="https://mako.cc/writing/"><strong>Benjamin Mako
Hill</strong></a></p>

<p>Les objectifs affichés par l'<cite>Open Source Initiative</cite> sont les
suivants : « L'open source est une méthode de développement logiciel qui
exploite la puissance de l'évaluation décentralisée par les pairs et de la
transparence des processus. Les promesses de l'open source sont une
meilleure qualité, une plus grande fiabilité, davantage de flexibilité, un
moindre coût et la fin d'une situation permettant à des fournisseurs rapaces
de verrouiller leurs produits. »</p>

<p>Depuis plus de dix ans maintenant, la <cite>Free Software Foundation</cite>
ne cesse d'argumenter contre la qualification d'« open source » dont on
affuble le mouvement du logiciel libre. Si nous, les partisans du logiciel
libre, réfutons ce qualificatif d'« open source », c'est surtout parce que
nous considérons qu'il s'agit d'un effort volontaire pour réduire la portée
de notre message de liberté et masquer le rôle de notre mouvement dans le
succès du logiciel que nous avons bâti. Si nous disons que le terme « open
source » est mauvais, c'est fondamentalement parce qu'il tente d'éviter
toute discussion à propos de la liberté du logiciel. Mais il y a une autre
raison pour laquelle nous devrions nous méfier du cadre « open
source ». L'argument fondamental de l'open source, tel qu'il est défini dans
la déclaration ci-dessus, est souvent incorrect.</p>

<p>Malgré la suggestion de l'<cite>Open Source Initiative</cite>, que « la
promesse de l'open source est une meilleure qualité, une plus grande
fiabilité, plus de flexibilité », cette promesse n'est pas toujours
honorée. Bien que nous ne le mettions pas souvent en avant, tout utilisateur
d'un logiciel libre aux premiers stades de son développement peut expliquer
que ce logiciel n'est pas toujours aussi pratique, sur le plan purement
fonctionnel, que ses concurrents privateurs.<a id="TransNote1-rev"
href="#TransNote1"><sup>1</sup></a> Un logiciel libre est parfois de piètre
qualité. Il n'est pas toujours très fiable. La souplesse lui fait parfois
défaut. Si les gens prennent les arguments en faveur de l'open source au
sérieux, ils doivent expliquer pourquoi l'open source n'a pas tenu ses
« promesses » et conclure que des outils privateurs seraient un meilleur
choix. Il n'y a aucune raison pour que nous fassions de même.</p>

<p>Richard Stallman parle de cela dans son article « <a
href="/philosophy/open-source-misses-the-point.html">En quoi l'open source
perd de vue l'éthique du logiciel libre</a> » lorsqu'il explique : « L'open
source repose sur l'idée qu'en permettant aux utilisateurs de modifier et
redistribuer le logiciel, celui-ci en sortira plus puissant et plus
fiable. Mais cela n'est pas garanti. Les développeurs de logiciels
privateurs ne sont pas forcément incompétents. Parfois ils produisent un
programme qui est puissant et fiable, bien qu'il ne respecte pas la liberté
des utilisateurs. »</p>

<p>Pour l'open source, la mauvaise qualité d'un logiciel est un problème à
analyser ou une raison de fuir ce logiciel. Pour le libre, c'est un problème
à résoudre. Pour les partisans du libre, les bogues et les fonctionnalités
manquantes ne sont jamais une raison d'avoir honte. Tout logiciel qui
respecte la liberté de ses utilisateurs possède un avantage inhérent sur son
concurrent privateur. Même s'il a ses propres problèmes, un logiciel libre a
toujours la liberté.</p>

<p>Bien évidemment, tout logiciel libre doit commencer quelque part. Un nouveau
programme, par exemple, a peu de chances d'offrir plus de fonctionnalités
qu'un programme privateur déjà établi. Un projet commence avec de nombreux
bogues et s'améliore avec le temps. Alors que les partisans de l'open source
peuvent argumenter qu'un projet deviendra utile avec du temps et un peu de
chance, un projet libre représente pour les partisans du logiciel libre une
importante contribution, dès le premier jour. Chaque logiciel qui donne aux
utilisateurs le contrôle sur leur technologie est un pas en
avant. L'amélioration en qualité due à la maturation d'un projet n'est que
la cerise sur le gâteau.</p>

<p>Un second point, peut-être plus accablant encore, est que le processus de
développement collaboratif, distribué, évalué par les pairs, qui est au cœur
de la définition de l'open source, ne ressemble que de loin à la manière
dont sont développés en pratique la plupart des projets sous licence libre
(ou « open source »).</p>

<p>Plusieurs études universitaires menées sur les <a
href="/software/repo-criteria.html">sites d'hébergement de logiciels
libres</a> SourceForge et <a href="http://sv.gnu.org">Savannah</a> ont
démontré ce que beaucoup de développeurs de logiciels libres ayant mis en
ligne une base de code savent déjà : la grande majorité des projets libres
ne sont pas particulièrement collaboratifs. Le nombre médian de
contributeurs à un projet de logiciel libre sur SourceForge ? Un. Un
développeur solitaire. Les projets de SourceForge du quatre-vingt-quinzième
centile en termes de nombre de participants n'ont que cinq
contributeurs. Plus de la moitié de ces projets libres, et même la plupart
des projets qui ont fait plusieurs versions à succès et ont été téléchargés
fréquemment sont l'œuvre d'un seul développeur avec un peu d'aide de
l'extérieur.</p>

<p>En insistant sur la puissance du développement collaboratif et de
« l'évaluation décentralisée par les pairs », l'approche open source semble
ne pas avoir grand-chose à dire, dans la majorité des cas, sur les raisons
pour lesquelles on devrait contribuer à un projet libre ou se servir d'un
logiciel en développement. Puisque les avantages supposés de la
collaboration ne peuvent être constatés quand il n'y a pas de collaboration,
la grande majorité des projets libres de développement n'ont pas d'avantage
technique sur leurs concurrents privateurs.</p>

<p>Pour les partisans du logiciel libre, ces mêmes projets sont tous vus comme
des succès importants. Comme chaque logiciel libre respecte la liberté de
ses utilisateurs, les partisans du libre peuvent argumenter qu'il possède au
départ un avantage éthique intrinsèque sur les concurrents privateurs, même
sur ceux qui proposent plus de fonctionnalités. En insistant sur la liberté
plutôt que sur les avantages pratiques, la défense du logiciel libre est
ancrée dans la réalité technique d'une façon qui manque souvent à l'open
source. Quand le logiciel libre est meilleur, nous pouvons nous en
réjouir. Quand il ne l'est pas, nous n'avons pas à considérer cela comme une
attaque dirigée contre lui ni même comme un argument valable contre
l'utilisation du logiciel en question.</p>

<p>Les partisans de l'open source doivent défendre leur thèse selon laquelle le
logiciel développé librement devrait, ou devra avec le temps, être meilleur
que le logiciel privateur. Les militants du logiciel libre peuvent quant à
eux demander : « Comment peut-on rendre le logiciel libre meilleur ? » Dans
le cadre du libre, les logiciels de haute qualité existent comme un moyen
plutôt que comme une fin en soi. Les développeurs de logiciels libres
doivent s'efforcer de créer des logiciels fonctionnels, flexibles, qui
servent bien leurs utilisateurs. Mais ceci n'est pas le seul moyen de
progresser vers la réalisation d'un objectif qui est à la fois plus simple
et bien plus important : respecter et protéger leurs libertés.</p>

<p>Bien sûr, nous ne cherchons pas à nier que la collaboration joue un rôle
important dans la création de logiciels de haute qualité. Dans la plupart
des projets libres ayant réussi, ce fut d'ailleurs le cas. Il faut
comprendre, soutenir et développer la collaboration, plutôt que de
considérer dogmatiquement qu'elle va de soi, quand bien même les faits sont
là pour montrer le contraire.</p>

<div class="translators-notes">

<!--TRANSLATORS: Use space (SPC) as msgstr if you don't have notes.-->
<hr /><b>Note de traduction</b><ol>
<li><a id="TransNote1" href="#TransNote1-rev"
class="nounderline">&#8593;</a> 
Autre traduction de <cite>proprietary</cite> : propriétaire.</li></ol></div>
</div>

<!-- for id="content", starts in the include above -->
<!--#include virtual="/server/footer.fr.html" -->
<div id="footer">
<div class="unprintable">

<p>Veuillez envoyer les requêtes concernant la FSF et GNU à <a
href="mailto:gnu@gnu.org">&lt;gnu@gnu.org&gt;</a>. Il existe aussi <a
href="/contact/">d'autres moyens de contacter</a> la FSF. Les liens
orphelins et autres corrections ou suggestions peuvent être signalés à <a
href="mailto:webmasters@gnu.org">&lt;webmasters@gnu.org&gt;</a>.</p>

<p>
<!-- TRANSLATORS: Ignore the original text in this paragraph,
        replace it with the translation of these two:

        We work hard and do our best to provide accurate, good quality
        translations.  However, we are not exempt from imperfection.
        Please send your comments and general suggestions in this regard
        to <a href="mailto:web-translators@gnu.org">

        &lt;web-translators@gnu.org&gt;</a>.</p>

        <p>For information on coordinating and submitting translations of
        our web pages, see <a
        href="/server/standards/README.translations.html">Translations
        README</a>. -->
Nous faisons le maximum pour proposer des traductions fidèles et de bonne
qualité, mais nous ne sommes pas parfaits. Merci d'adresser vos commentaires
sur cette page, ainsi que vos suggestions d'ordre général sur les
traductions, à <a href="mailto:web-translators@gnu.org">
&lt;web-translators@gnu.org&gt;</a>.</p>
<p>Pour tout renseignement sur la coordination et la soumission des
traductions de nos pages web, reportez-vous au <a
href="/server/standards/README.translations.html">guide de traduction</a>.</p>
</div>

<!-- Regarding copyright, in general, standalone pages (as opposed to
     files generated as part of manuals) on the GNU web server should
     be under CC BY-ND 4.0.  Please do NOT change or remove this
     without talking with the webmasters or licensing team first.
     Please make sure the copyright date is consistent with the
     document.  For web pages, it is ok to list just the latest year the
     document was modified, or published.
     
     If you wish to list earlier years, that is ok too.
     Either "2001, 2002, 2003" or "2001-2003" are ok for specifying
     years, as long as each year in the range is in fact a copyrightable
     year, i.e., a year in which the document was published (including
     being publicly visible on the web or in a revision control system).
     
     There is more detail about copyright years in the GNU Maintainers
     Information document, www.gnu.org/prep/maintain. -->
<p>Copyright &copy; 1999-2011 Benjamin Mako Hill</p>

<p>Cette page peut être utilisée suivant les conditions de la licence <a
rel="license"
href="http://creativecommons.org/licenses/by-sa/3.0/us/deed.fr">Creative
Commons Attribution-NoDerivs 3.0 United States</a>.</p>

<!--#include virtual="/server/bottom-notes.fr.html" -->
<div class="translators-credits">

<!--TRANSLATORS: Use space (SPC) as msgstr if you don't want credits.-->
Traduction : Framalang (travail collaboratif)<br /> Révision : <a
href="mailto:trad-gnu&#64;april.org"><em>trad-gnu&#64;april.org</em></a></div>

<p class="unprintable"><!-- timestamp start -->
Dernière mise à jour :

$Date: 2019/07/15 16:28:44 $

<!-- timestamp end -->
</p>
</div>
</div>
</body>
</html>