Les besoins d’un projet Open Source

Bien démarrer

Eric Raymond, dans un article maintenant célèbre sur les processus Open Source intitulé « La Cathédrale et le Bazaar24 » décrit les étapes classiques du lancement d’un projet de logiciel libre. Il y écrit :
« Tout bon logiciel commence par gratter un développeur là où ça le démange. »
Remarquez que Raymond ne dit pas que les projets Open Source démarrent seulement quand quelques individus ont une démangeaison. Il dit plutôt que tout bon logiciel est d’abord la réponse qu’apporte un programmeur à un problème qui l’irrite personnellement. C’est exactement ce qui se passe dans le monde du logiciel libre : les besoins personnels sont les motivations les plus fréquentes pour commencer un projet. C’est aujourd’hui encore la motivation de base de la plupart des projets libres, mais moins qu’en 1997 quand Raymond écrivait ces lignes. Aujourd’hui nous voyons des entreprises, y compris à but tout à fait lucratif, qui lancent de vastes projets Open Source à gestion centralisée en partant de zéro. Le programmeur isolé, écrivant des bouts de code pour résoudre un problème local précis et qui se rend compte que le résultat obtenu peut être largement étendu, est encore à la base de nombreux nouveaux logiciels libres, mais d’autres modèles ont émergé. L’idée de Raymond demeure très pertinente. Il faut que les créateurs du programme aient un réel intérêt à le voir aboutir car ils l’utilisent eux-mêmes : c’est une condition essentielle. Si le logiciel ne fait pas ce qu’il est censé faire, la personne ou l’organisation commanditaire ne seront pas satisfaites dans leur travail au quotidien. Prenons l’exemple du projet OpenAdapter25, lancé par la banque d’investissement Dresdner Kleinwort Wasserstein. Il s’agit d’une infrastructure Open Source pour l’intégration de systèmes d’informations financières disparates : on peut difficilement dire que ce projet réponde au besoin particulier d’un quelconque développeur mais plutôt à celui d’une institution. Mais c’est bien la réponse concrète à une insatisfaction de l’institution et de ses partenaires. En conséquence, si le programme faillit à sa mission, ils le sauront. Cette configuration produit de bons logiciels parce que la boucle de rétroaction est efficace. Le programme n’est pas écrit pour être vendu à un client quelconque afin qu’il puisse résoudre son problème. C’est nous qui l’écrivons pour résoudre notre propre problème et pour partager ensuite la solution avec tous, un peu comme si le problème était une maladie et le logiciel le médicament dont la diffusion pourrait éradiquer l’épidémie. Ce chapitre traite de l’élaboration et de la publication d’un nouveau projet de logiciel libre, mais de nombreuses recommandations sembleraient familières aux organisations médicales qui diffusent des médicaments. Les buts paraissent très similaires : vous voulez expliquer de manière simple ce que le médicament fait, le mettre entre les mains des personnes concernées et vous assurer que ceux qui le reçoivent savent bien l’utiliser ; dans le cas des logiciels, vous voulez aussi inciter certains destinataires à rejoindre la recherche en cours pour améliorer le médicament. La distribution du logiciel libre comporte deux facettes : elle doit trouver des utilisateurs d’une part et des développeurs de l’autre. Ces deux besoins ne sont pas forcément antagonistes même s’ils rendent la présentation initiale du projet plus compliquée. Certaines informations sont utiles aux deux publics, d’autres le sont uniquement à l’un ou à l’autre. Les deux types d’informations devraient répondre au principe de présentation adaptée, ce qui signifie que le degré de détail présenté à chacun devrait correspondre directement à la somme de temps et d’efforts consentis par le lecteur. Un effort plus important devrait toujours être récompensé à sa juste valeur. Quand le retour sur investissement n’est pas satisfaisant, les gens peuvent rapidement perdre la foi et arrêter de s’investir. Le corollaire en est que les apparences comptent vraiment. Les programmeurs, en particulier, sont souvent sceptiques à ce sujet. Leur amour pour le fond plutôt que pour la forme est presque une source de fierté professionnelle. Ce n’est pas un hasard si tant de programmeurs montrent de l’antipathie envers le marketing et les relations publiques, ou si les graphistes de métier sont souvent horrifiés par ce que les développeurs peuvent produire. C’est dommage car il existe des situations — la présentation d’un projet en est une — où la forme fait partie du tout. Par exemple, l’une des premières choses que retient un visiteur à propos d’un projet est l’aspect de son site Web. Cette information est absorbée avant que le vrai contenu du site ne soit compris, avant que le texte ne soit lu ou que le visiteur ne clique sur les liens. Même si cela peut être injuste, les gens ne peuvent s’empêcher de se forger une première impression. L’apparence du site montre l’application apportée à la présentation du projet. Les humains ont des antennes très sensibles pour détecter le souci du détail. La plupart d’entre nous peuvent dire en un coup d’il si un site Web a été assemblé à la va-vite ou s’il a été mûrement réfléchi. C’est la première information que votre projet montre et l’impression qu’elle crée pèsera, par association, sur le reste du projet. En conséquence, alors que ce chapitre du livre porte sur le contenu à la base de votre projet, souvenez-vous que son apparence compte également. Étant donné que le site Web s’adresse à deux types de visiteurs, les utilisateurs et les développeurs, une attention particulière doit être apportée à sa clarté et sa concision. Bien que ça ne soit pas le meilleur endroit pour traiter de la conception d’une page Web, un principe est suffisamment important pour être mentionné ici, particulièrement quand le site s’adresse à plusieurs publics (qui peuvent se confondre) : les gens devraient avoir une vague idée de la direction d’un lien avant de cliquer dessus. Par exemple, il devrait être évident que les liens vers la documentation utilisateur ne renvoient pas à la documentation développeur. Diriger un projet consiste à la fois à fournir des informations mais aussi à rassurer. La simple présence de certaines offres standard, à l’endroit attendu, rassure les utilisateurs et les développeurs qui décident s’ils vont ou non s’impliquer. Cela montre que le projet a une ligne de conduite définie, qu’il a anticipé les questions des visiteurs, et qu’il a fait l’effort d’y répondre de manière simple. Quand le projet témoigne d’une préparation soignée, c’est comme s’il envoyait un message : « Vous n’allez pas perdre votre temps en nous rejoignant », ce qui est exactement ce que les gens veulent entendre.

Regardez d’abord autour de vous

Avant de commencer un projet Open Source, faites bien attention : Regardez toujours autour de vous afin de savoir s’il n’existe pas déjà un projet correspondant à ce que vous souhaitez. Il y a de bonnes chances que, quel que soit le problème à résoudre, quelqu’un ait déjà pris l’initiative avant vous. Si le problème a été résolu et son code rendu public, sous une licence libre, vous n’avez aucune raison de réinventer la roue. Il y a bien sûr des exceptions : si vous voulez débuter un projet à des fins d’expérience pédagogique, un code pré-existant ne vous aidera pas, ou encore : le projet que vous avez en tête est si spécialisé que vous savez qu’il y a peu de chance qu’un autre l’ait déjà fait. Il n’y a, en général, aucune raison de ne pas effectuer de recherche, le gain peut être énorme. Si les moteurs de recherche sur Internet ne retournent aucune réponse, tentez votre chance sur freshmeat.net26 (un site rassemblant les nouvelles à propos de projets Open Source dont je parlerai plus longuement par la suite), sur sourceforge.net27 et dans le répertoire des logiciels libres28 de la Free Software Foundation. Même si vous ne trouvez pas exactement votre bonheur, vous pourriez découvrir un projet s’en approchant suffisamment pour qu’il soit plus logique d’y ajouter une fonctionnalité en le rejoignant que de commencer à partir de rien et par vous-même.

Commencez avec ce que vous avez

Vous avez cherché mais n’avez rien trouvé correspondant à votre besoin, vous êtes donc décidé à commencer un nouveau projet. Que faire maintenant ? La partie la plus difficile du lancement d’un projet de logiciel libre est la transposition d’une vision personnelle en une vision publique. Vous, ou votre organisation, savez parfaitement ce que vous voulez, mais expliquer ce but de manière compréhensible au monde entier représente un travail important. Il est essentiel cependant de prendre le temps de le faire. Vous et les autres membres fondateurs devez décider d’une définition précise du projet (c’est-à-dire, décider de ses limites, de ce qu’il ne réalisera pas aussi bien que de ce qu’il fera) et écrire une déclaration d’objectif (ou mission). Cette partie n’est, en général, pas trop compliquée bien qu’elle puisse révéler des non-dits et même des désaccords à propos de la nature du projet, ce qui est une bonne chose : mieux vaut résoudre ces problèmes maintenant que plus tard. L’étape suivante est de préparer la présentation du projet au public ; une véritable corvée. Ce qui rend cette étape si laborieuse est qu’il s’agit ici principalement d’organiser et de documenter des choses que tout le monde connaît déjà, « tout le monde » signifiant ici ceux qui ont déjà été impliqués dans un projet. Par conséquent, pour les gens s’occupant de cette tâche, il n’y a pas de gain immédiat. Ils n’ont pas besoin de fichier « Lisez moi » décrivant le projet, ni des fiches techniques ou de la documentation utilisateur. Ils n’ont pas besoin d’une arborescence du code établie avec attention selon des standards officieux mais largement utilisés pour la distribution du code de logiciels. Peu importe comment le code source est organisé, ils s’y retrouveront, ils y sont déjà habitués, et si le code fonctionne, ils savent l’utiliser. Peu importe aussi pour eux si les bases architecturales du projet restent non documentées, ils en sont déjà familiers. Les nouveaux arrivants, d’un autre côté, ont besoin de ces informations. Heureusement, ils n’ont pas besoin de tout, tout de suite. Il n’est pas nécessaire de donner accès à toutes les sources possibles avant de rendre le projet public. Dans un monde parfait, peut-être, chaque nouveau projet Open Source commencerait avec un modèle de document exhaustif, un manuel utilisateur complet (avec des avertissements pour les fonctionnalités prévues mais pas encore implémentées), un beau code bien assemblé et portable, capable de fonctionner sur n’importe quelle plateforme, etc. En réalité, s’occuper de tous ces détails prendrait un temps considérable et serait rédhibitoire : de toute façon, c’est un travail pour lequel on peut espérer recevoir de l’aide des volontaires une fois le projet sur les rails. Il est nécessaire cependant de s’investir suffisamment dans la présentation afin que les débutants puissent surmonter les premiers obstacles dus à leur manque d’habitude. Il faut le voir comme le premier pas pour lancer le projet du bon pied en lui apportant une sorte d’énergie d’activation minimale. Certains appellent ce seuil l’énergie d’hacktivation : l’énergie qu’un débutant doit fournir avant de recevoir quelque chose en retour. Plus le niveau requis d’énergie d’hacktivation est bas, mieux ça vaut. Votre première tâche sera d’abaisser cette énergie d’hacktivation à un niveau encourageant les gens à s’engager. Chacune des sections suivantes décrit un aspect important du commencement d’un nouveau projet. Elles sont plus ou moins présentées dans l’ordre d’apparition pour un nouveau visiteur, même si, bien sûr, votre ordonnancement peut être différent. Vous pouvez vous en servir comme d’une liste de contrôle. Quand vous commencez un projet, suivez cette liste et assurez-vous que chaque point est traité, ou au moins que vous n’aurez pas de problèmes quant aux conséquences possibles si vous décidez d’en écarter un.

Choisissez un bon nom

Mettez-vous à la place de quelqu’un venant de découvrir votre projet, peut-être en le trouvant par hasard lors d’une recherche de logiciel. La première chose qu’il verra est le nom du projet. Un bon nom ne fera pas automatiquement de votre projet un succès et un mauvais ne le condamnera pas (enfin, un très mauvais nom peut le faire, mais nous partons de l’hypothèse que personne ici ne tente intentionnellement de faire échouer son projet). Quoi qu’il en soit, un mauvais nom peut ralentir l’adoption du projet parce que les gens ne le prennent pas au sérieux, ou simplement parce qu’ils ont du mal à le retenir. Un bon nom doit avoir les caractéristiques suivantes :
  • Il donne une idée de l’objectif du projet, ou présente au moins clairement son domaine : ainsi, celui qui connaît le nom et la teneur du projet l’aura plus facilement à l’esprit par la suite.
  • Il est simple à mémoriser. Ici, on ne peut ignorer que l’anglais est devenu le langage par défaut sur Internet : « simple à mémoriser » signifie « simple à mémoriser pour quelqu’un parlant anglais ». Un jeu de mots dépendant de la prononciation du locuteur dans cette langue, par exemple, sera obscur pour les nombreux lecteurs dont l’anglais n’est pas la langue maternelle. Si le jeu de mot est particulièrement bien trouvé et facile à mémoriser, cela peut tout de même fonctionner : gardez simplement à l’esprit qu’en voyant le nom, beaucoup ne l’entendront pas mentalement comme une personne de langue maternelle anglaise.
  • Il n’est pas le même que celui d’un autre projet et ne s’approche d’aucune marque déposée. Ce ne sont que des bonnes manières et du bon sens légal. Vous ne voulez pas créer une confusion d’identité. Il est déjà assez difficile de suivre tout ce qui est disponible sur le Net sans s’encombrer de problèmes d’homonymie. Les sites mentionnés précédemment dans l’introduction vous seront d’une grande aide pour savoir si un projet a déjà adopté le nom auquel vous pensiez. Une recherche gratuite de marques déposées est également possible sur les sites nameprotect.org29 et uspto.org30.
  • il est disponible comme nom de domaine en .com, .net ou .org si possible. Vous devriez en choisir un, vraisemblablement en .org, comme site officiel de présentation du projet : les deux autres devraient renvoyer à ce premier site et ne sont là que pour éviter une confusion d’identité autour du nom du projet. Même si vous avez l’intention de l’héberger sur un autre site (voir la section « Forges »), vous pouvez toujours enregistrer des noms de domaines particuliers pour le projet et les faire renvoyer vers le site d’hébergement. Cela aide beaucoup les utilisateurs d’avoir une adresse simple et facilement mémorisable.

Définissez clairement vos objectifs

Une fois le site du projet trouvé, les gens chercheront une description rapide de sa teneur, votre déclaration d’intention, afin de pouvoir décider rapidement (dans les 30 secondes) s’ils souhaitent en savoir plus ou pas. Cette description devrait avoir une place de choix sur la première page, de péférence juste en-dessous du nom du projet. Votre déclaration doit être concrète, restreinte et surtout concise. En voici un bon exemple tiré du site openoffice.org31  :
« Pour créer, en tant que communauté, la suite bureautique internationale dominante qui fonctionnera sur toutes les plateformes principales et qui donnera accès à toutes les fonctionnalités et à toutes les données au travers d’API basées sur des composants libres et des formats de fichier basés sur XML. »
En seulement quelques mots, tous les points importants sont traités, principalement en s’appuyant sur les connaissances antérieures du lecteur. En écrivant « en tant que communauté », ils annoncent qu’aucune société ne dominera le développement, « internationale » veut dire que les gens pourront utiliser le logiciel dans de nombreuses langues et dialectes, « toutes les plateformes principales » veut dire qu’il sera utilisable sous Unix, Macintosh et Windows. La suite annonce que l’utilisation d’interfaces ouvertes et de formats de fichiers compréhensibles est une part importante de l’objectif visé. Ils ne disent pas de but en blanc qu’ils essaient de proposer une alternative libre à Microsoft Office, cependant la plupart des gens peuvent le lire entre les lignes. Bien que cette déclaration d’intention puisse paraître large au premier abord, elle est assez concise : les mots « suite bureautique » signifient quelque chose de très concret aux familiers de ce genre de logiciels. Encore une fois, la présumée connaissance préalable du lecteur (dans ce cas probablement de MS Office) est utilisée pour que la déclaration reste concise. La nature de l’objectif énoncé dépend en partie de son auteur, pas uniquement du logiciel décrit. Par exemple, il est logique pour OpenOffice.org d’utiliser les mots « en tant que communauté » car le projet a été initié et est encore largement financé par Sun Microsystems. En ajoutant ces mots, Sun comprend et rassure ceux qui pourraient craindre sa domination sur le processus de développement. En montrant simplement que l’on a conscience des conséquences possibles d’un problème, un grand pas en avant est fait pour l’éviter complètement. D’un autre côté, les projets dont le soutien financier n’est pas assuré par une unique entreprise n’ont pas besoin de tenir un tel discours ; après tout, le développement communautaire est la norme : il devrait donc être normalement inutile de le lister parmi les objectifs.

Indiquez que le projet est libre

Ceux qui sont toujours intéressés, après avoir lu la déclaration d’intention, vont ensuite vouloir plus de détails, peut-être une documentation utilisateur ou développeur, et finiront par télécharger quelque chose. Mais auparavant, ils voudront s’assurer que c’est bien Open Source. La première page doit annoncer sans ambiguïté que le projet est Open Source. Cela peut paraître évident, mais vous seriez surpris de voir combien de projets oublient de le faire. J’ai vu des sites de logiciels libres où la première page, non seulement ne donnait pas la licence de distribution du logiciel, mais ne déclarait même pas non plus que le logiciel était libre. Parfois l’information cruciale était reléguée à la page Téléchargements ou à la page Développeurs, voire une autre encore, nécessitant plus d’un clic pour s’y rendre. Dans les cas extrêmes, la licence n’était pas du tout mentionnée sur le site, le seul moyen de la découvrir étant de télécharger le logiciel pour trouver cette information. Ne commettez pas cette erreur. Une telle omission peut vous faire perdre de nombreux développeurs et utilisateurs potentiels. Annoncez de manière claire, juste en-dessous de la mission, que le projet est un « logiciel libre » ou un « logiciel Open Source » et donnez la licence exacte. Un guide rapide pour choisir la licence est proposé dans la section nommée « Choisir une licence et l’appliquer » plus loin dans ce chapitre, et les problèmes relatifs aux licences sont exposés plus en détails dans le chapitre 9. À ce stade, notre visiteur a établi (probablement en une minute ou moins) s’il compte passer, disons, au moins cinq minutes de plus à s’informer sur le projet. Voyons maintenant ce qu’il devrait trouver durant ces cinq minutes.

Liste des fonctionnalités et pré-requis

Il devrait y avoir une brève liste des fonctionnalités proposées par le logiciel (si un aspect n’est pas encore finalisé, vous pouvez toujours le lister en ajoutant à côté « prévu » ou « en cours ») et l’environnement informatique requis pour l’utiliser. Pensez la liste fonctionnalités / pré-requis comme si vous vous adressiez à quelqu’un vous demandant un rapide résumé du logiciel. C’est une extension logique de la mission. Ainsi, cela pourrait être à titre d'exemple :
« Créer un outil d’indexation de textes entiers et un moteur de recherche au moyen d’une API riche, en vue de son utilisation par des programmeurs fournissant des services de recherche concernant de grandes collections de fichiers textes. »
La liste des fonctionnalités et des pré-requis devrait donner des détails en clarifiant la portée de la mission. Fonctionnalités (exemple) :
  • recherche de texte brut, HTML et XML,
  • recherche de mots ou de phrases,
  • (prévu) correspondance approximative,
  • (prévu) mise à jour incrémentale de l’index,
  • (prévu) indexation de sites Web distants.
Pré-requis :
  • python 2.2 ou plus récent,
  • suffisamment d’espace disque pour contenir l’index (approximativement 2x la taille d’origine des données).
Avec ces informations, les lecteurs peuvent rapidement se rendre compte si le logiciel leur convient et envisager une implication dans le développement.

Avancement du développement

Les gens veulent toujours connaître la situation d’un projet. Pour les nouveaux projets, ils veulent apprécier l’écart existant entre les promesses et la réalité actuelle. Pour les plus avancés, ils cherchent à savoir comment est suivi le projet, le rythme de sorties des nouvelles versions et sa réactivité aux rapports de bogues, etc. Pour répondre à ces questions vous devriez mettre en place une page d’avancement, listant les buts du projet à court terme et ses besoins (il pourrait, par exemple, être à la recherche de développeurs avec des compétences particulières). La page peut également fournir un historique des versions passées avec la liste de leurs fonctionnalités. Ainsi, les visiteurs peuvent se faire une idée de l’« avancement » du projet et sa vitesse de progression. N’ayez pas peur de paraître non-préparé et ne cédez pas à la tentation d’exagérer la progression du développement. Chacun sait qu’un logiciel évolue par étapes, il n’y a pas de honte à dire « Ceci est une version alpha du logiciel avec des bogues connus. Il tourne et fonctionne au moins quelques fois, mais utilisez-le à vos propres risques ». Un tel langage ne fera pas fuir les développeurs nécessaires à cette étape. Quant aux utilisateurs, l’une des pires choses possible est de les attirer avant que le logiciel ne soit prêt. Une image d’instabilité ou de sensibilité aux bogues est très dure à gommer une fois bien ancrée. Le conservatisme est rentable sur le long terme, mieux vaut toujours un logiciel plus stable comparé aux attentes de l’utilisateur que le contraire : les bonnes surprises contribuent à un meilleur bouche à oreille. blackgris1 Alpha et Bêta Le terme alpha fait, en général, référence à une première version, avec laquelle il est possible de travailler, qui comporte toutes les fonctionnalités prévues, mais qui contient également des bogues connus. Le but principal d’un logiciel alpha est de générer un retour, les développeurs sachant ainsi sur quoi travailler. La prochaine étape, bêta, veut dire que le logiciel a été épuré des bogues les plus sérieux mais n’a pas encore été suffisamment testé pour garantir une sortie. Le but d’un logiciel bêta est : soit de devenir la version officielle, si aucun bogue n’est trouvé, soit d’apporter des critiques détaillées aux développeurs pour qu’ils puissent aboutir à la version finale rapidement. La différence entre alpha et bêta est principalement une question de jugement.

Téléchargements

Le logiciel doit être téléchargeable sous forme de code source aux formats standards. Au commencement d’un projet, les paquets binaires (exécutables) ne sont pas nécessaires, à moins que la complexité de l’assemblage demandé ou des dépendances soit telle que le simple fait de le faire fonctionner représente un gros travail pour la plupart des gens (mais si tel est le cas, le projet aura bien du mal à attirer les développeurs !). Les mécanismes de distribution devraient être aussi pratiques, standards et transparents que possible. Pour éradiquer une maladie, vous ne distribueriez pas un médicament demandant une taille de seringue non standard pour être administré. De même, le logiciel devrait se conformer aux règles des standards de construction et d’installation : plus il s’écartera des normes, plus les utilisateurs et développeurs potentiels abandonneront et partiront ailleurs, perplexes. Cela peut sembler évident, mais de nombreux projets ne prennent pas la peine de standardiser les procédures d’installation avant un stade avancé du développement, se disant qu’ils peuvent le faire à n’importe quel moment. « On s’occupera de tout ça quand le code sera presque fini ». Ce qu’ils ne réalisent pas, c’est qu’en remettant le travail fastidieux de finition à plus tard, ils rendent en fait la finalisation du code plus longue car ils découragent les développeurs qui auraient pu autrement contribuer au code. C’est même plus insidieux que cela : ils ne savent pas qu’ils perdent tous leurs développeurs, ce processus étant l’accumulation de non-évènements. Par exemple : quelqu’un visite un site Web, télécharge le logiciel, essaye de l’assembler, échoue, abandonne et va voir ailleurs. Qui saura un jour que c’est arrivé, hormis l’individu en question ? Aucun acteur du projet ne réalisera que l’intérêt de quelqu’un et sa bonne volonté ont été silencieusement gâchés. Le travail barbant à forte rentabilité devrait toujours être réalisé tôt. Faciliter significativement l’accès au projet en créant des paquets standards est un exemple de forte rentabilité. Quand vous publiez un paquet téléchargeable, il est vital que vous lui attribuiez un numéro de version unique, ainsi les gens peuvent comparer deux versions et savoir laquelle est la plus récente. Une discussion détaillée à propos de la numérotation se trouve dans la section « Numérotation de version » et les détails à propos de la standardisation d’une construction et des procédures d’installation sont traités dans la section appelée « Création de Paquets », toutes les deux dans le chapitre 7.

Gestion de versions et accès au système de suivi de bogues

Télécharger les paquets sources est suffisant pour ceux qui veulent juste installer et utiliser un logiciel, mais c’est insatisfaisant pour ceux qui veulent le déboguer ou ajouter de nouvelles fonctionnalités. Des mises à jour chaque nuit peuvent aider, mais elles ne sont pas d’une précision assez fine pour une communauté de développeurs prospère. Les gens ont besoin d’un accès en temps réel aux dernières sources, et pour cela, on peut utiliser un programme de gestion de configuration logicielle. La présence de versions contrôlées du code source, anonymement accessibles, est un signe, à la fois pour les utilisateurs et les développeurs, que le projet fait un effort pour donner aux gens le nécessaire pour participer. Si vous ne pouvez pas proposer de gestion de versions tout de suite, alors affichez clairement votre intention de l’implanter rapidement. L’infrastructure d’une version de contrôle est discutée plus en détails dans la section nommée « Les logiciels de gestion de versions » dans le chapitre 3. Il en va de même pour le système de suivi de bogues du projet. L’importance du suivi de bogues ne réside pas uniquement dans son utilité aux développeurs, mais aussi dans la signification qu’il a aux yeux des observateurs du projet. Pour la majorité, une base de données de bogues est l’un des signes les plus forts de la prise au sérieux du projet. Surtout : plus la base de données contient de bogues, meilleure est la santé du projet. Cela peut sembler illogique, mais souvenez-vous que le nombre de bogues enregistrés dépend principalement de trois choses : du nombre total de bogues présents, du nombre de personnes utilisant le logiciel et de la facilité qu’ont ces utilisateurs à rapporter les nouveaux bogues. De ces trois facteurs, les deux derniers sont plus importants que le premier : comment le projet va-t-il gérer l’enregistrement et la gestion des priorités de ces bogues ? Un projet avec une base de données de bogues importante et développée (ce qui signifie que les bogues sont corrigés rapidement, que les bogues dupliqués sont unifiés, etc.) fait alors meilleure impression qu’un projet sans base de données de bogues ou avec une base presque vide. Bien évidemment, si vous venez de débuter votre projet, votre base de données contiendra très peu de bogues ; il est difficile d’y faire grand-chose. Mais si la page d’avancement met l’accent sur la jeunesse du projet, et si ceux qui consultent la base de données de bogues peuvent voir que la majeure partie de l’archivage a été faite récemment, ils pourront en déduire que le projet a un rythme d’archivage sain et ne seront pas indûment alarmés par le nombre relativement faible de bogues enregistrés. Remarquez que les systèmes de recherche de bogues ne sont souvent pas uniquement utilisés pour rapporter les bogues du logiciel mais aussi pour rapporter les demandes d’améliorations, de modifications de la documentation, des tâches en cours et plus encore. Les détails sur l’utilisation d’un système de suivi de bogues sont donnés dans la section « Suivi de bogues » dans le chapitre 3. S’étendre ici apparaît donc superflu mais l’aspect important, du point de vue de la présentation, est d’avoir un tel système de suivi, et de s’assurer que cela soit bien visible sur la page d’accueil du projet.

Les voies de communications

Les visiteurs veulent en général savoir comment contacter les êtres humains impliqués dans le projet. Fournissez les adresses des listes de diffusion, des canaux IRC et tout autre forum où chaque personne impliquée dans le logiciel peut être jointe. Indiquez clairement que vous-même et les autres auteurs du projets sont inscrits sur ces listes de diffusion afin que les gens puissent voir qu’il existe des moyens de donner leur avis aux développeurs. Votre présence sur les listes n’implique pas que vous êtes tenu de répondre à toutes les questions ou d’intégrer toutes les suggestions. Sur le long terme, la plupart des utilisateurs ne s’inscriront jamais aux forums de toute façon, mais ils seront rassurés de savoir qu’ils peuvent le faire si besoin est. Au cours des premières étapes du projet, il n’est nul besoin de séparer les forums utilisateurs et développeurs, mais préférable de réunir toutes les personnes concernées par le logiciel dans une même « salle » pour en discuter. La distinction entre développeurs et utilisateurs est souvent floue pour les premiers arrivants, si tant est qu’elle existe : le nombre de développeurs par rapport à celui des utilisateurs est, en général, beaucoup plus élevé dans les premiers jours du projet que par la suite. Même si vous ne pouvez partir du principe que tout nouvel arrivant est un programmeur voulant bidouiller le logiciel, vous pouvez supposer qu’il est au minimum désireux de suivre les discussions autour du développement et de comprendre l’orientation du projet. Comme ce chapitre ne traite que du lancement d’un projet, il est presque suffisant de dire que ces forums de communication doivent exister. Plus tard, dans la section appelée « Gérer la croissance » au chapitre 6, nous examinerons où et comment mettre en place de tels forums, dans quelle mesure ils peuvent avoir besoin d’une modération ou d’autres formes de surveillance, et comment séparer, le moment venu, les forums utilisateurs des forums développeurs sans creuser de fossé infranchissable.

Les directives pour développeurs

Si une personne envisage de contribuer au projet, elle cherchera les directives pour développeurs. Celles-ci ne sont pas vraiment techniques mais plutôt sociales : elles expliquent comment les développeurs interagissent entre eux et avec les utilisateurs, et finalement comment les choses se déroulent. Ce sujet est détaillé dans la section dénommée « Tout mettre par écrit » dans le chapitre 4, mais les éléments de base des directives pour les développeurs sont :
  • des liens vers les forums pour l’interaction avec d’autres développeurs,
  • des instructions pour les rapports de bogues et la soumission de correctifs,
  • des indications sur la gestion du développement : le projet est-il une dictature bénévole, une démocratie ou quelque chose d’autre encore ?
Le mot « dictature » n’est pas employé dans un sens péjoratif. Une tyrannie où un développeur particulier a le droit de veto sur tous les changements n’a rien de choquant. Beaucoup de projets réussis fonctionnent de cette manière. Il est simplement important d’annoncer la couleur. Une tyrannie faisant semblant d’être une démocratie découragera les gens, une tyrannie qui ne se déguise pas fonctionnera très bien tant que le tyran est compétent et a la confiance de tous. Voir svn.collab.net32 pour un exemple particulièrement complet de directives pour les développeurs, ou openoffice.org33 pour des directives plus larges qui se concentrent davantage sur l’administration et l’esprit de participation et moins sur les aspects techniques. Le problème différent de la présentation du logiciel aux programmeurs est abordé dans la section nommée « Documentation développeur » plus loin dans ce chapitre.

Documentation

La documentation est essentielle. Il faut quelque chose à lire, même rudimentaire et incomplet. La documentation fait vraiment partie des « corvées » mentionnées précédemment, et c’est souvent le premier élément qui peut faire s’effondrer un nouveau projet Open Source. Proposer une mission et une liste de fonctionnalités, choisir une licence, résumer l’avancement du développement sont des tâches relativement simples pouvant être accomplies une bonne fois pour toutes et dont vous n’aurez plus à vous soucier. La documentation, à l’inverse, n’est jamais vraiment terminée, ce qui peut être parfois une bonne raison pour retarder son exécution. Cependant, rédacteurs et lecteurs ne partagent pas les mêmes préoccupations. La documentation la plus importante pour les nouveaux utilisateurs concerne les bases : comment rapidement mettre le logiciel en route, une vue d’ensemble de son fonctionnement et peut-être quelques guides pour les tâches courantes. Or, c’est exactement tout ce que les auteurs de la documentation connaissent parfaitement, si parfaitement, qu’il peut être difficile pour eux de voir les choses du point de vue du lecteur, et d’énumérer laborieusement les étapes qui (aux yeux des auteurs) semblent évidentes ou inutiles à mentionner. Il n’y a pas de solution miracle à ce problème. Il faut prendre le temps d’écrire la documentation, puis de la mettre entre les mains d’un nouvel utilisateur lambda pour en tester la qualité. Utilisez un format facilement éditable comme le HTML, du texte brut, Texinfo ou une variante de XML, quelque chose de pratique en vue de retouches légères et d’améliorations à la volée. Il ne s’agit pas simplement de faciliter les choses aux contributeurs, mais aussi de permettre de travailler à ceux qui rejoindront plus tard le projet. On peut s’assurer de réaliser la documentation initiale de base en limitant par avance son étendue. Ainsi, son écriture ne semblera pas être une tâche infinie. Par expérience, la documentation devrait remplir les critères minimaux suivant :
  • Indiquer clairement au lecteur le degré d’expertise attendu de sa part.
  • Décrire clairement et de manière détaillée comment lancer le logiciel et, quelque part en début de documentation, expliquer comment faire fonctionner une sorte de diagnostic ou une commande simple confirmant que tout a été fait correctement. Les instructions de démarrage sont d’une certaine manière plus importantes que les instructions d’utilisation. Plus une personne fournit d’efforts pour installer et faire ses premiers pas avec le logiciel, plus elle découvre les fonctionnalités avancées qui ne sont pas aussi bien documentées. Les abandons sont toujours rapides. Ce sont donc les premières étapes, comme l’installation, qui demandent le plus d’assistance.
  • Présenter un exemple, ou une méthode de réalisation d’une tâche basique. Évidemment, de nombreux exemples seraient préférables, mais si vous êtes limité par le temps, sélectionnez une fonction et décrivez-la en détail. Dès qu’une personne constate que le logiciel peut servir à quelque chose, elle commence à explorer les autres possibilités voire, si vous êtes chanceux, compléter elle-même la documentation. Ce qui nous amène au point suivant…
  • Indiquer les endroits où la documentation est incomplète. En montrant au lecteur que vous en connaissez les imperfections, vous vous accordez à son point de vue. Votre empathie le rassure : il n’a pas à lutter pour convaincre le projet de ce qui est important. Ces indications ne sont pas nécessairement des promesses de remédier à ces insuffisances à une date précise ; il est également légitime de les voir comme autant d’appels à des contributeurs volontaires.
Le dernier point est réellement de la plus haute importance et s’applique au projet entier, pas uniquement à la documentation. Tenir un compte précis des lacunes connues est la norme dans le monde de l’Open Source. Inutile d’exagérer les défauts du projet, il suffit simplement de les identifier scrupuleusement et impartialement quand le besoin s’en fait sentir (que ce soit dans la documentation, dans la base de données de suivi de bogues ou dans les discussions sur la liste de diffusion). Personne ne verra cela comme du défaitisme de la part du projet, ni comme une promesse de résolution des problèmes à une date précise, à moins que le projet ne s’y engage explicitement. Étant donné que tout utilisateur du logiciel découvrira les lacunes de lui-même, il est préférable de le préparer psychologiquement, de plus, le projet donnera l’impression d’une parfaite connaissance de son état de fonctionnement. blackgris1 Entretenir une FAQ Une FAQ (« Frequently Asked Questions » ou « Foire Aux Questions ») peut être l’un des meilleurs investissements du projet pour son potentiel pédagogique. Une FAQ bien entretenue à de bonnes chances de répondre aux questions de ceux qui la consultent. La FAQ est souvent le premier document que les utilisateurs consultent lorsqu’ils ont un problème, souvent même avant le manuel officiel, et c’est sûrement le document de votre projet auquel les autres sites renverront. Malheureusement vous ne pouvez pas créer la FAQ dès le début du projet. Les bonnes FAQ ne sont pas écrites, elles se façonnent. Ce sont, par définition, des documents réactifs, évoluant avec le temps en réponse à l’usage quotidien des utilisateurs du logiciel. Puisqu’il n’est pas possible d’anticiper toutes les questions que les gens peuvent poser, il est impossible de prendre cinq minutes de son temps et écrire une FAQ utile en partant de rien. Ne gaspillez donc pas votre temps à essayer de le faire. Vous pourriez, par contre, trouver utile de mettre en place un modèle de FAQ vide, pour que les gens trouvent facilement un endroit où écrire leurs questions et réponses une fois le projet sur les rails. Pour le moment, la chose la plus importante n’est pas son exhaustivité mais sa facilité d’utilisation : s’il est facile d’ajouter des questions/réponses à la FAQ, les gens le feront (l’entretien d’une bonne FAQ est une tâche peu aisée et fascinante, j’en reparlerai dans la section intitulée « Responsable FAQ » dans le chapitre 8).

2.1.10.1  Disponibilité de la documentation

La documentation devrait être disponible en deux endroits : en ligne, directement depuis le site Web, et dans la distribution téléchargeable du logiciel (voir la section appelée « Création de paquets » dans le chapitre 7). Elle doit être en ligne sous une forme navigable car les gens lisent souvent la documentation avant de télécharger le logiciel pour la première fois. Mais elle doit aussi accompagner le téléchargement du logiciel qui devrait fournir (c’est-à-dire rendre l’accès hors ligne possible) tout ce dont on pourrait avoir besoin pour utiliser le paquet. En ce qui concerne la documentation en ligne, assurez-vous qu’elle comporte un lien vers la documentation complète sur une page au format HTML (ajoutez une note comme « monolithique », « tout en un » ou « page unique » à côté du lien, afin que les utilisateurs sachent qu’un certain temps est nécessaire pour télécharger). C’est utile car, souvent, ils cherchent un mot en particulier ou une phrase dans la documentation entière. En général, ils savent ce qu’ils veulent mais ne se souviennent pas où se trouve l’information. Pour eux, rien n’est plus frustrant que de rencontrer une page HTML pour le sommaire, puis une autre pour l’introduction, une autre encore pour les instructions d’installation, etc. Quand les pages sont séparées ainsi, la fonction de recherche du navigateur leur est inutile. Une structure éclatée est utile pour ceux qui savent à quelle partie se référer ou qui veulent lire le document du début à la fin par morceaux. Ne pas leur proposer un document complet sur une seule page leur compliquerait la vie plus qu’autre chose.

  La documentation développeur

La documentation développeur est rédigée pour aider les programmeurs à comprendre le code et pouvoir le réparer et le compléter. Elle ne fait pas double emploi avec les directives pour les développeurs dont nous avons parlé précédemment, qui sont plus un outil social que technique. Ces consignes indiquent aux programmeurs comment bien collaborer entre eux, la documentation développeur leur indique comment se débrouiller avec le code lui-même. Les deux sont en général réunies en un seul document pour des raisons pratiques (comme dans l’exemple donné plus tôt : svn.collab.net34), mais ce n’est pas une obligation. Bien que la documentation utilisateur puisse être très pratique, elle ne doit pas être la raison d’un retard de la distribution. Que les auteurs d’origine soient disponibles (et disposés à le faire) pour répondre aux questions touchant au code, est déjà suffisant pour commencer. En fait, c’est le fait de devoir répondre sans cesse aux mêmes questions qui motive souvent les gens à écrire la documentation. Mais, même avant qu’elle ne soit rédigée, les participants motivés trouveront comment fonctionne le code. En apprenant les bases du code, ils réalisent quelque chose d’utile pour eux, c’est ce qui les pousse à persévérer. Si les gens y croient vraiment, ils prendront le temps de comprendre les choses, s’ils n’ont pas cette foi, ce n’est pas la documentation, aussi complète puisse-t-elle être, qui les attirera ou les fera rester. Donc, si vous n’avez que peu de temps à lui consacrer, écrivez la documentation pour les seuls utilisateurs. Au fond, la documentation utilisateur est également une documentation développeur puisque les programmeurs qui vont travailler sur une partie du logiciel doivent être familiers avec son utilisation. Ensuite, quand vous voyez que les programmeurs posent sans cesse les mêmes questions, prenez le temps d’écrire quelques documents indépendants plus spécialement pour eux. Certains projets utilisent des wikis comme documentation de départ, voire comme documentation principale. D’après mon expérience, cela ne fonctionne vraiment que si le wiki est souvent édité par une poignée de gens en accord sur la manière d’organiser la documentation et sur le ton qu’elle devrait avoir.

Forges

Quelques sites proposent un hébergement gratuit ainsi que l’infrastructure pour des projets Open Source : une zone Web, une gestion de versions, un système de suivi de bogues, une zone de téléchargement, des forums de discussions, des sauvegardes régulières, etc. Les détails varient d’un site à l’autre, mais les services de base sont les mêmes partout. En utilisant l’un de ces sites vous obtiendrez beaucoup en échange de rien. Vous tournez par contre le dos à un contrôle précis de ce que vous offrez aux utilisateurs du site. Les services d’hébergement décident des logiciels qui fonctionnent sur le site et peuvent contrôler, ou au moins influencer, l’aspect des pages Web du projet.

Infrastructure technique

Les technologies des logiciels libres reposent sur l’acquisition et l’intégration sélectives des informations. Plus vous serez habile à employer ces technologies et à persuader les autres de les employer, plus votre projet aura de succès. Cela devient d’autant plus vrai quand votre projet prend de l’ampleur. La bonne gestion de l’information empêche des projets Open Source de s’effondrer sous l’effet de la loi40 de Brooks4142 selon laquelle ajouter de la main-d’uvre à un projet informatique en retard ne fait que le retarder plus encore. Fred Brooks a observé que la complexité d’un projet informatique augmente proportionnellement au carré du nombre de participants. Quand quelques personnes seulement sont impliquées, la communication est aisée, mais quand ce sont des centaines, comment savoir ce que chacun fait ? Pour bien gérer un projet de logiciel libre, il faut faire en sorte que chacun ait l’impression de travailler avec tous les autres dans la même pièce, mais une question s’impose : que se passe-t-il dans une pièce surpeuplée, quand tout le monde veut parler en même temps ? Ce problème n’est pas nouveau. Dans les salles surpeuplées, la solution est le procédé parlementaire : des règles formelles sur les moyens de mener des discussions en temps réel dans de larges assemblées, pour s’assurer que d’importantes divergences d’opinion ne vont pas se retrouver noyées sous des flots de « moi, je », pour former des sous-comités, pour identifier quand des décisions sont prises, etc. L’un des rôles importants de ce processus est de spécifier comment le groupe interagit avec son système d’information. Certaines remarques ont vocation d’être « enregistrées », d’autres non. Cet « enregistrement » lui-même est sujet à manipulation et n’est pas une transcription littérale de ce qui vient de se produire, mais une représentation de ce que le groupe a convenu de considérer comme résultat. Pas d’ « enregistrement » monolithique, mais à géométrie variable selon la finalité recherchée. Il comprend la totalité des comptes-rendus de toutes les réunions, les résumés, les ordres du jour et leurs annotations, les rapports de comité, les rapports des correspondants non présents, les listes d’actions à entreprendre, etc. Comme Internet n’est pas vraiment une salle, la stratégie parlementaire qui fait taire les uns pendant que les autres parlent ne nous concerne pas. Mais quand on en vient aux techniques de gestion de l’information, on voit que les projets Open Source bien dirigés utilisent ce procédé parlementaire boosté aux stéroïdes. Puisque presque toute la communication dans les projets Open Source se fait par écrit, des systèmes élaborés ont évolué pour permettre l’étiquetage, le stockage, la recherche et le cheminement des données de façon appropriée, pour minimiser les répétitions afin d’éviter des divergences inutiles, pour corriger les informations fausses ou désuètes et pour connecter des bribes d’informations disparates au fur et à mesure que de nouveaux liens se créent. Les participants actifs dans les projets Open Source ont adopté plusieurs de ces techniques et réalisent souvent de complexes opérations manuelles pour s’assurer que l’information est correctement transmise. Mais le plus gros de l’effort repose finalement sur la sophistication du logiciel sous-jacent. Les médias de communication eux-mêmes devraient assurer l’acheminement autant que faire se peut, l’étiquetage et l’enregistrement devraient mettre l’information à disposition d’une façon la plus commode possible. Dans la pratique, évidemment, l’intervention humaine reste nécessaire à de nombreuses étapes du processus, et il est important que le logiciel la rende aussi aisée que possible. En règle générale, si l’humain fait bien attention à l’étiquetage et à l’acheminement de l’information en entrée du système, le logiciel doit être configuré pour utiliser au mieux toutes ces métadonnées. Quant à la gestion de l’information, il n’existe pas de recette miracle car les paramètres sont nombreux. Vous pouvez très bien être parvenu à tout configurer de manière optimale selon vos besoins et avoir une communauté active, il arrivera sûrement un moment où la croissance du projet rendra certaines de ces pratiques inadaptées. Il se peut aussi que la croissance du projet se stabilise et que les communautés de développeurs et d’utilisateurs s’installent dans une relation satisfaisante avec l’infrastructure technique, puis que quelqu’un vienne, invente un nouveau service de gestion de l’information, et l’on vous demandera aussitôt pourquoi votre projet ne l’emploie pas. C’est, par exemple, ce qui arrive en ce moment à un certain nombre de projets Open Source antérieurs à l’invention du Wiki43. Beaucoup d’interrogations relèvent surtout d’une question de point de vue, comme la différence entre l’ergonomie pour ceux qui produisent l’information et l’ergonomie pour ceux qui la consomment, ou entre le temps requis pour configurer un logiciel de gestion de l’information et les avantages qu’il peut apporter au projet. Prenez garde à la tentation d’automatiser les choses qui exigent vraiment une attention humaine. L’infrastructure technique est importante, mais ce qui fait fonctionner un projet Open Source, c’est l’attention et l’expression intelligente de cette attention que les humains impliqués vont déployer. Le but principal de cette organisation est de fournir à l’utilisateur les instruments les plus adaptés pour agir.

Les besoins d’un projet

La plupart des projets Open Source offrent un minimum d’outils pour la gestion de l’information :
Site Web —
La vitrine de votre projet aux yeux du public (centralisé et à sens unique). Le site Web peut également servir d’interface administrative à d’autres outils du projet.
Listes de diffusion —
Traditionnellement le principal moyen de communication, et aussi le plus actif, au sein du projet. C’est une bonne ressource pour garder trace des discussions.
Contrôle de versions —
Permet aux développeurs de contrôler facilement les changements apportés au code, les régressions, et de gérer les branches de développements parallèles. Il permet à chacun d’observer les modifications du code.
Référencement de bogues —
Permet aux développeurs d’avoir à disposition l’historique de leurs travaux, de se coordonner et de planifier les correctifs. Il Permet à chacun de connaître le statut précis des bogues, et les informations liées (par exemple, les conditions de leur reproductibilité). La même méthode peut d’ailleurs être employée pour faire le suivi, non seulement des bogues, mais également des tâches, des versions, des nouvelles fonctionnalités, etc.
Messagerie instantanée ou chat en temps réel —
Un endroit pour les discussions et les échanges sur un mode de questions - réponses énoncées rapidement et simplement. N’est pas toujours archivé complètement.
Chacun de ces outils satisfait un besoin particulier, mais leurs fonctions sont étroitement liées et ils doivent être conçus pour fonctionner ensemble. Plus loin, nous verrons comment c’est possible, et surtout, comment les utiliser. Le site Web ne sera pas évoqué tout de suite, car il s’agit plus d’un ciment pour les autres composants que d’un outil à part entière. Vous pouvez éviter les prises de tête liées à leur choix et à leur configuration en optant pour une forge : un serveur qui offre, prêts à l’emploi, des modèles avec tous les outils nécessaires pour gérer un projet Open Source. Voir la section appelée « Les forges » plus loin dans ce chapitre pour une évaluation des avantages et des inconvénients de ce système.

Les listes de diffusion

Les listes de diffusion sont la base de la communication au sein d’un projet. Si un utilisateur rencontre un espace de dialogue, en dehors des pages Web, il y a de fortes chances que ce soit une des listes de diffusion du projet. Mais avant d’expérimenter la liste de diffusion elle-même, il sera en contact avec l’interface de la liste de diffusion ; c’est-à-dire le mécanisme par lequel il peut rejoindre la liste (« s’abonner »). Ceci nous amène à la règle n1 des listes de diffusion :
« N’essayez pas de gérer une liste de diffusion à la main: procurez-vous un logiciel de gestion de listes. »
Il serait tentant de repousser cela à plus tard. Le temps passé à installer un logiciel de gestion de listes peut sembler peu rentable au début. Gérer à la main de petites listes générant peu de trafic semble séduisant : établissez simplement une adresse d’abonnement qui redirige vers votre boîte mail, et quand quelqu’un l’utilise, ajoutez (ou enlevez) son adresse mail dans un fichier texte qui contient toutes les adresses de la liste. Qu’y a-t-il de plus simple ? Le hic, c’est qu’une bonne gestion de listes de diffusion, ce que les gens sont en droit d’attendre, n’est pas simple du tout. Il ne s’agit pas simplement d’abonner et de désabonner les utilisateurs quand ils le demandent. Il s’agit également de faire de la modération pour empêcher le spam, d’offrir des versions résumées, et, message par message, de fournir de l’information standard et de l’information orientée projet grâce à des messages pré-écrits, ainsi que diverses autres choses. Un être humain gérant lui-même une adresse d’abonnement ne peut assurer que le strict minimum et n’est pas aussi fiable et performant qu’un logiciel. Les logiciels modernes de gestion de liste offrent au minimum les fonctionnalités suivantes :
Inscription par e-mail et par le web —
Quand un utilisateur s’abonne à une liste, il devrait recevoir, en réponse automatique par retour, un message d’accueil lui indiquant ce à quoi il s’est abonné, quels sont les possibilités offertes par le logiciel de liste de diffusion, et (ce qui est le plus important) comment se désinscrire. Bien sûr, cette réponse automatique peut être personnalisée pour donner plus d’informations sur le projet, comme par exemple son adresse, où trouver la FAQ, etc.
L’abonnement en mode résumé ou message par message —
En mode résumé, l’abonné reçoit un courrier par jour contenant toutes les activités du jour de la liste. Pour qui suit une liste de manière détachée, sans participer, le mode résumé est souvent préférable car il permet de survoler rapidement tous les sujets et évite la distraction de recevoir des e-mails à n’importe quel moment.
Les possibilités de modération —
La modération sert à vérifier les messages pour s’assurer qu’il ne s’agit ni de spam ni d’envois hors sujet avant que d’être envoyés à la liste entière. La modération demande une intervention humaine, mais les logiciels peuvent mâcher une grosse partie du travail. Nous y reviendrons.
Interface d’administration —
L’interface d’ administration permet à l’administrateur, entre autres choses, de retirer facilement les adresses obsolètes. Cela peut devenir urgent quand l’adresse d’un destinataire commence à renvoyer automatiquement des messages du type « Je ne suis plus à cette adresse » à toute la liste pour chaque e-mail reçu (certains logiciels de listes de diffusion peuvent même les détecter seuls et désabonner ces personnes automatiquement).
Manipulation des en-têtes —
Beaucoup de gens mettent en place des filtrages sophistiqués et des règles de réponse dans leur logiciel de messagerie. Les logiciels de listes de diffusion peuvent ajouter et manipuler certains en-têtes standards pour permettre à ces personnes d’en tirer parti (nous y reviendrons).
Archivage —
Tous les messages des listes sont enregistrés et mis à disposition sur le Web, certains logiciels de listes de diffusion proposent des interfaces spéciales pour assurer leur compatibilité avec des utilitaires d’archivage tiers comme MHonArc44. Comme nous le verrons dans la section « Utilisation visible des archives » du le chapitre 6, l’archivage est crucial.
Retenez simplement ici que la gestion des listes de diffusion est un problème complexe, ayant déjà reçu beaucoup d’attention, mais en grande partie résolu. Vous n’êtes pas obligé de devenir expert sur le sujet, mais vous devriez savoir qu’il y a toujours de nouvelles choses à découvrir et que cette gestion demandera votre attention de temps à autre au cours de la vie de votre projet de logiciel libre. Nous allons désormais examiner quelques-uns des principaux problèmes rencontrés lors de la configuration des listes de diffusion.

Se prémunir du spam

Entre le moment où j’écris cette phrase et le moment où elle sera publiée, le problème du spam sur Internet aura sûrement pris des proportions beaucoup plus importantes ou, en tout cas, sera ressenti comme tel. Il fut un temps, il n’y a pas si longtemps, où l’on pouvait créer une liste de diffusion sans avoir à prendre de mesures de protection contre le spam. De temps en temps, on pouvait recevoir un e-mail égaré, mais c’était suffisamment rare pour que cela reste peu gênant. Cette âge d’or est révolu. De nos jours, une liste de diffusion qui ne se prémunit pas du spam sera rapidement noyée sous les e-mails indésirables, au point d’en devenir inutilisable. Les protections contre le spam sont indispensables. On peut séparer les protections contre le spam en deux catégories : celles qui empêchent les courriers indésirables d’apparaître sur la liste de diffusion et celles qui protègent les listes de diffusion contre les collecteurs d’adresses des spammeurs. La première étant la plus importante, c’est celle que nous allons détailler en premier.

Filtrer les messages

Il existe trois techniques de base pour éviter les messages indésirables, la plupart des logiciels de listes de diffusions les proposent toutes les trois. Il vaut mieux les utiliser de concert : 1. Autoriser automatiquement les messages uniquement envoyés par les abonnés Cette méthode remplit très bien son rôle et ne demande que peu de travail : en général, il suffit de modifier un paramètre dans les réglages du logiciel de liste de diffusion. Mais prenez garde, les messages qui ne sont pas automatiquement approuvés ne doivent pas être rejetés pour autant ; ils devraient subir une inspection pour deux raisons : d’abord, vous feriez mieux de laisser la possibilité aux non-abonnés d’envoyer des messages (une personne qui a une question, ou une idée à soumettre, ne devrait pas avoir besoin de s’inscrire à la liste de diffusion juste pour y envoyer un message), ensuite, même les abonnés envoient parfois des messages depuis d’autres adresses que celle qu’ils ont utilisée pour s’inscrire. L’adresse e-mail n’est pas une méthode sûre pour identifier les personnes, et par conséquent ne doit pas servir à cela. 2. Filtrer les messages grâce à un logiciel de filtrage Si la liste de diffusion le permet (la plupart le font), vous pouvez filtrer les messages grâce à un logiciel de filtrage de spam. Le filtrage automatique des spams n’est pas parfait (et ne le sera jamais) vu que les spammeurs et les développeurs de filtres se sont engagés dans une course à l’armement sans fin. Malgré cela, le filtre peut largement réduire le nombre de spams en attente de modération. Comme la longueur de la liste d’attente se traduit en temps de travail manuel, tout gain obtenu à ce niveau, grâce au filtrage automatique, est bon à prendre. Je ne peux pas détailler ici la mise en place des filtres à spam. Je vous renvoie donc à la documentation de votre logiciel de liste de diffusion pour en savoir plus (voir la section appelée « Les logiciels » plus loin dans ce chapitre). Les logiciels de liste de diffusion incluent souvent des fonctionnalités anti-spam, mais vous pouvez aussi choisir d’utiliser un programme de filtrage tiers. J’apprécie les programmes SpamAssassin45 et SpamProbe46 que j’ai utilisés avec une grande satisfaction. Je ne ferai pas de liste exhaustive, il existe bien d’autres logiciels Open Source de filtrage de spam, dont certains semblent très performants. 3. Modération En ce qui concerne les courriels qui ne sont pas automatiquement admis parce qu’ils n’émanent pas d’un abonné, qui passent au crible d’un éventuel logiciel anti-spam, la dernière étape est la modération : le mail est redirigé vers une adresse spéciale où une personne l’examinera et l’acceptera ou non. Accepter un message peut se faire de deux manières différentes : vous pouvez autoriser le message juste cette fois, ou encore, dire au logiciel de liste de diffusion de laisser passer dans le futur tous les messages de cet expéditeur. En général, c’est la deuxième option qui est favorisée afin de faciliter la tâche de modération à l’avenir. La manière de procéder est différente selon les systèmes, mais, en principe il faut répondre à une adresse particulière en incluant la commande « accepter » (ce qui signifie « accepter uniquement ce message ») ou « autoriser » (autoriser ce message ainsi que tous les futurs messages). Le rejet se fait simplement en ignorant le courrier de modération. Si le logiciel de la liste de diffusion ne reçoit jamais de consigne pour dire qu’un message est valide, alors, il ne fera pas suivre ce message sur la liste : laisser le message de côté aura donc l’effet désiré. Il arrivera parfois que vous ayez la possibilité de répondre avec une commande « rejeter » ou « empêcher » pour rejeter automatiquement et de façon permanente les messages de cet utilisateur sans même qu’ils ne repassent par la case « Modération ». En général, ce n’est pas très utile puisque la modération sert principalement à éviter le spam, et que les spammeurs utilisent rarement la même adresse deux fois. La modération doit servir uniquement au filtrage des spams et des messages hors sujet, ou envoyés sur la mauvaise liste de diffusion. Le système de modération devrait vous fournir un moyen de répondre directement à l’expéditeur, mais n’employez pas cette méthode pour répondre directement à une question adressée à la liste de diffusion, même si vous pouvez fournir une réponse rapidement. Fonctionner ainsi empêcherait le projet de se faire une idée précise du genre de questions que les gens se posent et enlèverait aux membres l’occasion de répondre aux questions eux-mêmes, ou de voir les réponses des autres. La modération des listes de diffusion doit se borner à l’entretien de la liste de diffusion, rien d’autre.

Masquer les adresses dans les archives

Pour éviter que vos listes de diffusion ne deviennent une mine d’adresses pour les spammeurs, une technique courante est de masquer les adresses e-mail des personnes dans les archives en remplaçant par exemple


REFERENCES:
Karl Fogel
Produire du logiciel libre
Traduction Fr. : Framalang
Publié sous licence Creative Commons
Paternité-Partage à l’identique (3.0)
Copyright 2005, 2006, 2007, 2008, 2009 : Karl Fogel
Copyright 2010 : Framasoft
2010 : traduction Framasoft (projet Framalang)
Mise en page : La Poule ou l’Œuf


Comments