Author: bertrand
Date: Tue Jul 31 07:28:14 2007
New Revision: 864
Log:
Ch02 review 1
Modified:
trunk/fr/ch02.xml
Modified: trunk/fr/ch02.xml
==============================================================================
--- trunk/fr/ch02.xml (original)
+++ trunk/fr/ch02.xml Tue Jul 31 07:28:14 2007
@@ -19,68 +19,68 @@
</blockquote>
<para>Notez que Raymond n'a jamais dit qu'un projet libre n'apparaît
- que lorsque ça démange un développeur. Il dit plutôt que de
+ que lorsque qu'un développeur se démange. Il dit plutôt que de
<emphasis>bons</emphasis> logiciels sont produits lorsque
l'initiateur possède un intérêt personnel à voir son problème
- résolu; L'application de ce principe au logiciel libre est qu'une
- problématique personnelle est la motivation la plus fréquente au
- démarrage d'un projet.</para>
+ résolu; Le corollaire de ce principe appliqué au logiciel libre est
+ le fait qu'une problématique personnelle est la motivation la plus
+ fréquente au démarrage d'un projet.</para>
<para>Cette règle est toujours valable mais moins qu'en 1997,
- lorsque Raymond l'a formulée. Aujourd'hui, un phénomène se
- développe: le développement ex nihilo par d'importantes
- organisations -incluant des organismes à but lucratifs- de grands
- projets libres gérés de façon centralisée. La production de code par
- des développeurs isolés afin de répondre à un besoin précis est
- toujours un modèle très répandu mais ce n'est plus le seul.</para>
+ lorsque Raymond l'a formulée. Aujourd'hui, un phénomène se développe
+ : le développement ex nihilo par d'importantes organisations
+ -incluant des organismes à but lucratifs- de grands projets libres
+ gérés de façon centralisée. La production de code par des
+ développeurs isolés afin de répondre à un besoin précis est toujours
+ un modèle très répandu mais ce n'est plus le seul.</para>
<para>L'avis de Raymond n'est reste pas moins très clairvoyant.
- L'intérêt direct des producteurs du logiciel est la condition
+ L'intérêt direct des concepteurs du logiciel demeure la condition
essentielle de son succès car ils l'utilisent eux-mêmes. Si le
logiciel ne répond pas au besoin initial, la personne ou
- l'organisation le développant éprouveront de la frustration dans
- leurs tâches quotidiennes. Par exemple, le projet OpenAdapter
- (<ulink url="http://www.openadapter.org/"; />), à l'initiative de la
- banque d'investissement Dresdner Kleinwort Wasserstein et dont
- l'objet est le développement d'un framework d'intégration des
- systèmes financiers hétérogènes aurait difficilement pu provenir de
- la démangeaison d'un particulier. Il s'agit d'une démangeaison à un
+ l'organisation le développant éprouvera de la frustration dans ses
+ tâches quotidiennes. Par exemple, le projet OpenAdapter (<ulink
+ url="http://www.openadapter.org/"; />), à l'initiative de la banque
+ d'investissement Dresdner Kleinwort Wasserstein et dont l'objet est
+ le développement d'un framework d'intégration des systèmes
+ financiers hétérogènes aurait difficilement pu provenir de la
+ démangeaison d'un particulier. Il s'agit d'une démangeaison à un
niveau institutionnel. Mais cette démangeaison est issue directement
de l'expérience de cette institution et de ses partenaires, donc si
ce projet les soulage, ils seront les premiers à s'en rendre compte.
Ce mode de fonctionnement permet de produire un logiciel adéquat
parce que les échanges entre utilisateurs et producteurs permettent
d'alimenter un cercle vertueux. Le programme est avant tout écrit
- par eux et pour eux; ils peuvent donc répondre à
+ par eux et pour eux ; ils peuvent donc répondre à
<emphasis>leur</emphasis> problématique. Il a été écrit pour
- résoudre le problème particulier de quelqu'un, et a ensuite été
- partagé avec les autres, comme si le problème avait été une maladie
- et le programme son antidote dont la distribution aurait eu l'effet
- d'en éradiquer l'épidémie.</para>
+ résoudre un problème particulier, et a ensuite été partagé avec
+ d'autres, comme si le problème avait été une maladie et le programme
+ son antidote dont la distribution a pour effet d'en éradiquer
+ l'épidémie.</para>
<para>Ce chapitre décrit la manière de fournir au monde un nouveau
projet libre, mais la plupart de ses recommandations pourrait tout
aussi bien s'appliquer à l'industrie pharmaceutique. Les objectifs
sont très similaires : vous voulez décrire clairement ses capacités
- thérapeutiques, sa posologie et vous assurer qu'il tomberont entre
+ thérapeutiques, sa posologie et vous assurer qu'ils tomberont entre
de bonnes mains. Mais dans le cas d'un logiciel, vous désirez
également attirer certains patients afin qu'ils se joignent à
l'effort de recherche pour améliorer le principe actif au bénéfice
de tous.</para>
- <para>La production de logiciel libre est une tache bicéphale. Le
- logiciel soit acquérir de nouveau utilisateurs mais également de
+ <para>La production de logiciel libre est une tache bipolaire. Le
+ logiciel doit acquérir de nouveau utilisateurs mais également de
nouveaux développeurs. Ces deux taches ne sont pas nécessairement
- ambivalentes mais leur différence d'objectif complexifie la façon de
- présenter initialement le projet. Certaines informations sont utiles
- aux deux audiences, certaines leur sont spécifiques. Néanmoins, les
- deux types d'information doivent respecter le principe de
- présentation échelonnée; dans le sens où le niveau de détail
- présenté à chaque étage doit correspondre scrupuleusement à l'effort
- et au temps consenti par le lecteur. Une augmentation de l'effort
- doit assurer en contrepartie une récompense proportionnelle.
- Lorsqu'il y a perte de corrélation entre les deux, les gens perdent
- rapidement la foi dans le projet et stoppent leurs
+ ambivalentes mais la différence dans leurs objectifs complexifie la
+ façon de présenter initialement le projet. Certaines informations
+ sont utiles aux deux audiences, certaines leur sont spécifiques.
+ Néanmoins, les deux types d'information doivent respecter le
+ principe de présentation échelonnée, dans le sens où le niveau de
+ détail présenté à chaque étage doit correspondre scrupuleusement à
+ l'effort et au temps consenti par le lecteur. Une augmentation de
+ l'effort doit assurer en contrepartie une récompense
+ proportionnelle. Lorsqu'il y a perte de corrélation entre les deux,
+ les gens perdent rapidement la foi dans le projet et stoppent leurs
investissements.</para>
<para>Le corollaire de ce principe est le fait que
@@ -89,49 +89,48 @@
qu'à la forme est souvent brandi comme une marque de
professionnalisme. Ce n'est pas un hasard si tant de développeurs
exhibent une réelle antipathie pour le marketing et les relations
- publiques; pas plus que le fait que les graphistes professionnels
+ publiques ; pas plus que le fait que les graphistes professionnels
sont souvent horrifiés par le résultat auquel arrivent les
développeurs livrés à eux mêmes.</para>
<para>C'est déplorable car il existe des situations où la forme
<emphasis>est</emphasis> le fond et la présentation d'un produit en
- fait partie. Par exemple, l'apparence du site web d'un projet est la
+ fait partie. Par exemple, l'apparence du site Web d'un projet est la
première chose qu'un visiteur va en retenir. Cet aspect du site est
pris en compte avant le contenu en tant que tel, bien avant que tout
texte soit lu ou les liens activés. Aussi injuste que cela puisse
- paraître, les gens ne peuvent refréner leur réflexe de se former une
- opinion au premier regard. L'apparence d'un site fourni au visiteur
- le degré de soin apporté à organiser la présentation. Les humains
- possèdent une antenne particulièrement sensible pour détecter le
- niveau d'effort consenti. La plupart d'entre nous peuvent en un
- simple coup d'oeil s'avancer sur le fait qu'un site soit une simple
- concaténation d'informations ou le fruit d'une réflexion mûrie. Le
- site est le premier indicateur exposé par le projet et l'impression
- qu'il dégage s'appliquera au reste du projet par association
- mentale.</para>
+ paraître, les gens ne peuvent se refréner de former leur opinion au
+ premier regard. L'apparence d'un site fourni au visiteur le degré de
+ soin apporté à organiser la présentation. Les humains possèdent une
+ antenne particulièrement sensible pour détecter le niveau d'effort
+ consenti. La plupart d'entre nous peuvent en un simple coup d'oeil
+ s'avancer sur le fait qu'un site soit une simple concaténation
+ d'informations ou le fruit d'une réflexion mûrie. Le site est le
+ premier indicateur exposé par le projet et l'impression qu'il dégage
+ s'appliquera au reste du projet par association mentale.</para>
<para>Ainsi, bien que ce projet se concentre sur le contenu servant
au démarrage d'un projet, gardez en tête que l'apparence compte
également. Sachant qu'un site Web doit s'adresser à deux publics
-les utilisateurs et les développeurs- une attention particulière
doit être apportée à la clarté et à l'adéquation du message. Bien
- que le web design ne soit pas le sujet de ce livre, un principe est
- à retenir, en particulier si le site s'adresse à des audiences
- distinctes : les visiteurs doivent directement savoir où pointe un
- lien avant de cliquer dessus. Par exemple, il doit être évident,
- simplement en regardant les liens vers la documentation utilisateur,
- qu'ils conduisent bien à la documentation utilisateur, et non -par
- exemple- à la documentation interne des développeurs. L'un des rôles
- d'un projet est de fournir de l'information, mais également du
- confort. Le simple fait de retrouver des informations standards à un
- endroit attendu rassure les utilisateurs et les développeurs qui
- veulent décider de s'impliquer ou pas. Le projet signifie ainsi
- qu'il prend ses responsabilités, qu'il anticipe les questions, et
- qu'il a fait un effort pour y répondre avec un minimum d'exigence
- pour l'intervenant. En constituant cette atmosphère de préparation,
- le projet envoie un message clair : "Votre temps ne sera pas
- gaspillé si vous vous impliquez"; exactement ce que les gens veulent
- entendre...</para>
+ que le conception de sites Web ne soit pas le sujet de ce livre, un
+ principe est à retenir, en particulier si le site s'adresse à des
+ audiences distinctes : les visiteurs doivent directement savoir où
+ pointe un lien avant de cliquer dessus. Par exemple, il doit être
+ évident, simplement en regardant les liens vers la documentation
+ utilisateur, qu'ils conduisent bien à la documentation utilisateur,
+ et non -par exemple- à la documentation interne des développeurs.
+ L'un des rôles d'un projet est de fournir de l'information, mais
+ également du confort. Le simple fait de retrouver des informations
+ standards à un endroit attendu rassure les utilisateurs et les
+ développeurs qui veulent décider de s'impliquer ou pas. Le projet
+ signifie ainsi qu'il prend ses responsabilités, qu'il anticipe les
+ questions, et qu'il a fait un effort pour y répondre avec un minimum
+ d'exigence pour l'intervenant. En constituant cette atmosphère de
+ préparation, le projet envoie un message clair : "Votre temps ne
+ sera pas gaspillé si vous vous impliquez" : exactement ce que les
+ gens veulent entendre...</para>
<!-- ======================== subsection ============================== -->
@@ -146,7 +145,7 @@
déjà traité votre problématique. Si tel est le cas, et que le code
a été publié en licence libre, il serait peu judicieux de
réinventer la roue. Il y a bien entendu des exceptions à cette
- règle: si le but du projet est principalement didactique ou s'il
+ règle : si le but du projet est principalement didactique ou s'il
concerne un domaine de niche si réduit qu'il n'y a aucune chance
que quelqu'un ait pu le traiter avant vous. Mais en général, il ne
coûte rien de vérifier et le jeu en vaut largement la chandelle.
@@ -158,8 +157,8 @@
<para>Même si vous ne trouvez pas exactement ce que vous aviez en
tête, il est possible de détecter un projet similaire pour lequel
- une collaboration serait plus fructueuse que de partir tout seul
- de zéro.</para>
+ une collaboration serait plus fructueuse que de partir seul de
+ zéro.</para>
</sect2>
</simplesect>
@@ -182,12 +181,12 @@
le temps de le faire. Les fondateurs du projet doivent fixer ses
objectifs, ce qui implique de fixer ses limites -aussi bien les
fonctionnalités qu'il assurera que celle qu'il <emphasis>n'assurera
- pas</emphasis>- et ainsi de coucher sur papier sa finalité. Cette
+ pas</emphasis>- et ainsi de coucher ses finalités sur papier. Cette
étape se déroule en général sans difficultés majeures bien qu'elle
puisse quelque fois révéler des hypothèses cachées voire des
- désaccords sur la nature du projet, ce qui est une bonne chose:
+ désaccords sur la nature du projet, ce qui est une bonne chose :
mieux vaut résoudre les divergences en amont. L'étape suivante est
- de packager le projet à destination du grand public, ce qui s'avére
+ d'empaqueter le projet à destination du grand public, ce qui s'avère
être un travail titanesque.</para>
<para>Ce qui rend ce travail si laborieux est le fait qu'il consiste
@@ -210,31 +209,31 @@
projet libre apparaîtrait avec un dossier de conception impeccable,
un guide utilisateur exhaustif (avec le détail des fonctionnalités
restant à implémenter et déjà disponibles), un code source superbe
- et packagé de façon portable pour fonctionner sur toutes les
+ et empaqueté de façon portable pour fonctionner sur toutes les
plates-formes et ainsi de suite. En réalité, assurer tout ceci
- serait acceptablement coûteux en ressource et il s'agit de toute
+ serait inacceptablement coûteux en ressource et il s'agit de toute
façon de tâches pouvant raisonnablement être réalisées en cours de
projet par des volontaires.</para>
<para>Ce qui est <emphasis>incontournable</emphasis> néanmoins est
- que suffisamment d'investissement ait été assuré sur la présentation
- du projet pour lever l'obstacle d'inconnu auprès des nouveaux venus.
- Imaginez cet investissement comme la première étape d'un processus
- de bootstrap qui apporterait au projet le quanta minimal d'énergie
- d'activation. J'ai entendu parler de ce concept sous le nom
- d'<emphasis>énergie d'hacktivation</emphasis> , c'est à dire la
- quantité d'énergie qu'un nouveau venu consomme avant de produire à
- son tour quelque chose d'utile au projet. Le seuil d'énergie
- d'hacktivation requis doit être le plus bas possible. C'est là votre
- première tâche que de limiter au maximum ce niveau d'énergie pour
- encourager les gens à s'investir.</para>
+ que suffisamment d'investissements ait été assurés sur la
+ présentation du projet pour lever la barrière de l'inconnu auprès
+ des nouveaux venus. Imaginez cet investissement comme la première
+ étape d'un processus de bootstrap qui apporterait au projet le
+ quanta minimal d'énergie d'activation. J'ai entendu parler de ce
+ concept sous le nom d'<emphasis>énergie d'hacktivation</emphasis> ,
+ c'est à dire la quantité d'énergie qu'un nouveau venu consomme avant
+ de produire à son tour quelque chose d'utile au projet. Le seuil
+ d'énergie d'hacktivation requis doit être le plus bas possible.
+ C'est là votre première tâche que de limiter au maximum ce niveau
+ d'énergie pour encourager les gens à s'investir.</para>
<para>Chacun de ces sous-chapitres décrivent un aspect important du
démarrage d'un nouveau projet. Ils sont globalement présentés dans
l'ordre où les visiteurs les rencontrent, bien que l'ordre dans
lequel vous les avez mis en place puisse différer. Traitez les comme
- une check-list. Vérifiez quand vous démarrez un nouveau projet, pour
- chaque point, qu'il a été traité, où au moins que vous savez
+ une check-liste. Vérifiez quand vous démarrez un nouveau projet,
+ pour chaque point, qu'il a été traité, où au moins que vous savez
apprécier les conséquences si tel n'a pas été le cas.</para>
<!-- ======================== subsection ============================== -->
@@ -244,9 +243,9 @@
<para>Mettez vous à la place d'une personne qui aurait entendu
parlé de votre projet pour la première fois, peut être après
- l'avoir péniblement découvert durant une recherche de solution à
- sa problématique. Le premier contact avec le projet se fera via
- son nom.</para>
+ l'avoir découvert à l'issue d'une laborieuse recherche de solution
+ à sa problématique. Le premier contact avec le projet se fera au
+ travers de son nom.</para>
<para>Un bon nom ne fera pas systématiquement le succès d'un
projet, pas plus qu'un mauvais son échec (un <emphasis>très
@@ -287,9 +286,7 @@
idée que de créer de la confusion, il est déjà suffisamment
difficile de garder une trace de tout ce qui est déjà
disponible sur Internet pour ne pas nommer les choses de la
- même façon.</para>
-
- <para>Les liens mentionnés précédemment dans <xref
+ même façon. Les liens mentionnés précédemment dans <xref
linkend="look-around" /> sont utiles pour vérifier si un
autre projet utilise déjà le nom que vous aviez à l'esprit.
Des recherches de marques déposées sont également
@@ -344,13 +341,13 @@
<para>En quelques mots, les points principaux sont révélés tout en
s'appuyant largement sur les connaissances actuelles du lecteur.
En précisant "<emphasis>en tant que communauté</emphasis>", ils
- affirment qu'aucun organisme privé ne dominera le développement;
+ affirment qu'aucun organisme privé ne dominera le développement ;
"<emphasis>international</emphasis>" signifie que le logiciel
permettra aux utilisateurs de travailler dans différentes langues
- et données régionalisées; "<emphasis>toutes les plates-formes
+ et données régionalisées ; "<emphasis>toutes les plates-formes
majeures</emphasis>" ajoute qu'il sera portable sous Unix,
Macintosh, et Windows. Le reste signale que les architectures
- inter opérables et les formats ouverts forment une part importante
+ interopérables et les formats ouverts forment une part importante
des principes directeurs du projet. Il n'est pas explicitement dit
que ce projet est une alternative à la suite bureautique Microsoft
Office mais la plupart des visiteurs auront lu entre les lignes.
@@ -577,10 +574,10 @@
<para>Le logiciel devrait être distribué en code source dans un
format standard. Lorsqu'un projet démarre, les distributions de
binaires (exécutables) ne sont pas obligatoires à moins que le
- projet ait tant de dépendances ou de pré-requis de compilation que
- le faire fonctionner nécessite un effort considérable. (Mais dans
- ce cas, le projet aura des problèmes à recruter des développeurs
- de toute façon !)</para>
+ projet possède tant de dépendances ou de pré-requis de compilation
+ que le faire fonctionner nécessite un effort considérable. (Mais
+ dans ce cas, le projet aura des problèmes à recruter des
+ développeurs de toute manière !)</para>
<para>La procédure d'installation doit être aussi simple, standard
et peu économe en ressource que possible. Si vous tentez
@@ -588,24 +585,25 @@
de façon à qu'il nécessite une seringue de taille non-standard
pour être administré. De la même façon, les logiciels doivent se
conformer à des standards de construction et d'installation; plus
- ils dévient du standard, plus utilisateurs et développeurs
- abandonnent et s'en vont, perplexes.</para>
+ ils dévient du standard, plus d'utilisateurs et de développeurs
+ abandonnent, perplexes.</para>
- <para>Cela semble évident mais beaucoup de projets ne dégnent
+ <para>Cela semble évident mais beaucoup de projets ne daignent
standardiser leur procédure d'installation que très tard dans le
projet, se disant qu'ils auront l'occasion de le faire à tout
- moment: "<emphasis>Nous verrons le packaging lorsque le code sera
+ moment: "<emphasis>Nous verrons l'empaquetage lorsque le code sera
mieux fini</emphasis>". Ce qu'ils ne réalisent pas est qu'en
mettant de coté ce travail rébarbatif, ils allongent en réalité la
phase de réalisation du code, parce qu'il découragent les
développeurs qui -sinon- y auraient contribué. De façon plus
- insidieuse, ils ne <emphasis>savent</emphasis> pas qu'ils perdent
- tous ces développeurs car il s'agit d'une accumulation de
- non-événements : quelqu'un visite le site Web du projet,
- télécharge le logiciel, tente de le compiler, échoue dans cette
- entreprise et s'en va. Qui saura que cela s'est produit, excepté
- la personne elle-même ? Personne du projet ne réalisera que cette
- motivation et cette compétence a été gaspillée.</para>
+ insidieuse, ils ne <emphasis>savent</emphasis>
+ <emphasis>pas</emphasis> qu'ils perdent tous ces développeurs car
+ il s'agit d'une accumulation de non-événements : quelqu'un visite
+ le site Web du projet, télécharge le logiciel, tente de le
+ compiler, échoue dans cette entreprise et s'en va. Qui saura que
+ cela s'est produit, excepté la personne elle-même ? Personne du
+ projet ne réalisera que cette motivation et cette compétence a été
+ gaspillée.</para>
<para>Le travail ennuyeux avec un bon retour sur investissement
devrait toujours être réalisé tôt pour abaisser suffisamment la
@@ -614,7 +612,7 @@
<para>Lorsque vous publiez une version téléchargeable, il est
vital de lui donner un numéro de version unique pour que les gens
puissent comparer deux versions et savoir immédiatement laquelle
- précéde l'autre. La numérotation de version est discutées au
+ précède l'autre. La numérotation de version est discutées au
paragraphe <xref linkend="release-numbering" />, et les détails de
la standardisation des procédures de compilation et d'installation
sont détaillés dans <xref linkend="packaging" /><phrase
@@ -796,12 +794,12 @@
<emphasis>quelque chose</emphasis> même si c'est rudimentaire et
incomplet. Encore une tâche à classer dans la catégorie
"déplaisant" déjà évoquée plus tôt et qui est souvent le premier
- ecceuil pour les projets libres. Définir des finalités et une
- liste de fonctionnalités, choisir une licence, synthétiser un
- statut d'avancement - tout ceci constituent des tâches plutôt
- légéres et souvent faites une fois pour toutes. La documentation,
- de son coté, n'est jamais réellement achevée et c'est peut être la
- raison pour laquelle les gens rechignent quelque fois à son
+ écueil pour les projets libres. Définir des finalités et une liste
+ de fonctionnalités, choisir une licence, synthétiser un statut
+ d'avancement - tout ceci constituent des tâches plutôt légères et
+ souvent faites une fois pour toutes. La documentation, de son
+ coté, n'est jamais réellement achevée et c'est peut être la raison
+ pour laquelle les gens rechignent quelque fois à son
écriture.</para>
<para>L'effet le plus insidieux est que l'usage de celui qui écrit
@@ -1216,7 +1214,7 @@
collective difficile à saisir et qui se développe au cours du temps.
On trouve souvent des régles écrites, mais elles se bornent souvent
à une distillation de régles tacites, évoluant régulièrement et
- servant de guide effectif au projet. Les réglements écrits
+ servant de guide effectif au projet. Les règlements écrits
définissent moins la culture du projet qu'ils la décrivent, et
encore souvent de façon approximative.</para>
@@ -1649,7 +1647,7 @@
produira probablement pour tous. Non pas qu'ils soient de mauvais
programmeurs; c'est simplement qu'au dessus d'une certaine taille,
un projet a des bogues et la revue par pairs permettra de les
- détécter (voir <xref linkend="code-review" /><phrase
+ détecter (voir <xref linkend="code-review" /><phrase
output="printed"> précédemment dans ce chapitre</phrase>). Dans le
même temps, les nouveaux arrivants ne seront pas eux mêmes sujets
à la revue par pairs puisqu'ils ne peuvent produire de code tant
@@ -1796,7 +1794,7 @@
terme, vous noterez une progression constante de la participation à
la fois en nouveaux contributeurs de code et d'utilisateurs. Faire
l'annonce est seulement planter la graine : il peut falloir un temps
- concidérable pour que la nouvelle croissent et se répande. Si le
+ considérable pour que la nouvelle croissent et se répande. Si le
projet donne constamment en retour à ceux qui s'y investissent, la
nouvelle se répandra néanmoins, car les gens aiment partager
lorsqu'ils trouvent quelque chose de valable. Si les choses se
_______________________________________________
Producingoss-translators mailing list
[email protected]
http://www.red-bean.com/mailman/listinfo/producingoss-translators
