Les phases de correction et de validation

Après la rédaction, nous allons voir comment se servir des retours pour corriger efficacement son contenu et comment utiliser correctement les phases de bêta et de validation.

Demander des retours

Si vous avez déjà commencé la rédaction d’un contenu, vous vous êtes sans doute demandé si votre plan était pertinent, si vos propos étaient compréhensibles ou encore s’il n’y avait pas trop d’erreurs.

Pourquoi demander des retours ?

Les retours permettent à l’auteur d’obtenir des remarques sur son travail, tant sur le fond que la forme et ce, afin de lui permettre d’améliorer le contenu en obtenant de l’aide en amont. Dit autrement, ils assurent qu’un contenu soit de qualité suffisante.

Grâce à eux, un auteur peut donc obtenir des réponses à ses questions, recevoir des idées et savoir ce qui ne va pas dans son contenu, tant sur le fond que sur la forme. Par exemple, il peut s’enquérir de la qualité de son plan avant de s’attaquer à la rédaction. De plus, certains lecteurs peuvent trouver une explication trop confuse et demander une reformulation des propos. En outre, ils peuvent aussi suggérer un exercice ou l’ajout d’une illustration.

Les retours sont donc à ne jamais négliger puisqu’un auteur a rarement le recul nécessaire sur son texte. En effet, les défauts et même les qualités de son œuvre lui échappent bien souvent. Bien sûr, l’expérience permet de s’affranchir de certaines erreurs, mais il en restera toujours.

Pour améliorer la forme et le fond, il suffit donc de demander ! :)

Comment demander des retours ?

Mais où et quand demander des retours ?

Si vous vous rappelez bien, nous avons parlé de plusieurs stades dans la rédaction d’un contenu, en particulier de la bêta et de la validation. Si la validation ne s’utilise que quand un contenu est « prêt » à être publié (c’est-à-dire lorsque l’auteur pense avoir terminé et s’est assuré de corriger tout ce qu’il pouvait), la bêta peut s’utiliser lorsque l’auteur en ressent le besoin (il n’est donc pas obligatoire d’avoir un contenu en version quasi-finale). Cette dernière est donc parfaite pour demander des retours. N’hésitez donc pas à l’utiliser que vous ayez besoin d’avis ou non. Nous reviendrons plus en détails sur ces deux étapes d’ici peu .

Naturellement, cela implique que vous soyez ouvert à la critique. Vous avez demandé des retours, prenez-les en compte s’ils sont pertinents (ce qu’ils sont dans la majorité des cas), les membres qui critiquent sont là pour vous aider dans le meilleur de leurs capacités. Ils lisent et soulèvent fréquemment des points dont on n’a pas forcément conscience en tant qu’auteur. L’échange entre l’auteur et les membres aide donc vraiment à améliorer la qualité de votre contenu.

Il arrive relativement souvent que vous n’obteniez pas de retours immédiats durant la bêta. Cela peut être dû à énormément de facteurs (comme le manque de disponibilité des membres, un contenu envoyé en bêta un peu trop tôt, etc.). Dans ce cas, patientez, continuez votre rédaction et mettez votre contenu à jour lorsque vous aurez progressé significativement. N’hésitez pas non plus à demander à un membre du staff s’il est possible de donner un peu plus de visibilité à votre contenu en bêta dans l’espoir d’engranger plus de retours. :)

Bien utiliser la bêta !

Comme nous venons de le voir, la bêta est le moyen par excellence pour demander des retours auprès de la communauté !

Description de la bêta

Si le fonctionnement de la bêta est plutôt simple, c’est une étape à ne pas négliger. Ainsi, que vous en ressentiez le besoin ou non, il est fortement conseillé de l’utiliser afin d’ouvrir votre contenu aux critiques. Gardez à l’esprit qu’ayant la tête dans le guidon, votre regard vis à vis de votre contenu ne sera pas forcément objectif ou qu’il se peut que vous passiez à côté de certaines erreurs. Les retours des relecteurs ne pourront que vous permettre d’améliorer votre contenu.

Lors de la première mise en bêta d’un contenu, un sujet est créé automatiquement dans le forum adéquat. De la même façon, un message automatique sera posté sur le sujet en question à chaque mise à jour de la bêta. Les membres ont alors accès à la version bêta en cliquant sur les liens de référence. Ils peuvent ainsi la lire et même vous faire des retours. Si vous désactivez la bêta, le sujet est alors verrouillé. En définitive, chaque auteur a la mainmise sur le processus de bêta.

Au passage, rappelons que tout contenu en bêta est aussi répertorié dans la page d’aide aux auteurs.

Conseils

Si le procédé semble simple, il ne faut pas l’utiliser de n’importe quelle manière.

Tout d’abord, il n’est pas forcément bon de mettre en bêta votre contenu à un stade trop prématuré si vous n’avez pas une bonne raison de le faire. Ainsi, si vous ne souhaitez pas de retours ni sur votre plan ni sur vos idées, essayez de rédiger quelques sections complètes avant de demander des retours. De cette manière, vous aurez des commentaires plus fournis et cela accrochera sans doute plus de relecteurs qu’un contenu brouillon.

Ensuite, prenez soin de toujours préciser les retours dont vous avez besoin (si vous souhaitez des retours sur une partie en particulier ou encore si vous n’avez pas besoin de corrections orthographiques pour le moment, par exemple). Pour cela, personnalisez les messages de mise en bêta en les éditant. De même, vous pouvez ajouter un bref résumé des changements apportés par rapport à la version précédente de sorte que les relecteurs sachent où ils en sont. Cela évitera à tout le monde de perdre son temps.

Par ailleurs, évitez de faire des mises à jour de la version bêta trop fréquemment, surtout s’il n’y a pas de modifications majeures. Cela sera plus considéré comme du spam qu’autre chose (vous pouvez néanmoins masquer les messages en cliquant sur le bouton « Masquer »).

Enfin, utilisez la bêta jusqu’à avoir une version prête pour la validation. Une fois que vous aurez pris en compte les retours et corrigé tout ce que vous aurez pu corriger, vous pourrez alors songer à mettre votre contenu en validation.

En définitive, la bêta est indispensable avant la validation.

Bien utiliser la validation !

Après la bêta vient l’heure de la validation. Mais tout comme la bêta, elle ne doit pas être utilisée n’importe comment.

Description de la validation

Pour commencer, prenez en considération que le processus de validation peut parfois durer jusqu’à quelques mois. Il y a plusieurs raisons à cela. Premièrement, les personnes qui assurent son fonctionnement le font bénévolement, comme vous et moi, ce qui implique que leurs disponibilités varient d’une semaine à l’autre. Par ailleurs, les validateurs ont généralement plusieurs rôles sur la plate-forme (rédacteur, développeur, etc.) ce qui limite d’autant plus leur temps disponible. Et puis, le nombre de validateurs étant inférieur au nombre de contenus en validation, il faut souvent attendre qu’un validateur se libère. Enfin, chacun ayant son ou ses domaines de prédilections, ils ne réserveront pas votre contenu s’ils ne se sentent pas capables d’en assurer la validation. De façon plus anecdotique, il faut du temps et de l’amour pour relire et corriger soigneusement un contenu, d’autant plus s’il est conséquent ! :P

Ainsi, il faudra en général une à plusieurs semaines pour que votre contenu soit réservé par un validateur. Vous recevrez alors un message automatique. Cela fait, le validateur commencera à examiner votre contenu avec attention. À intervalles plus ou moins réguliers, il vous fera des retours sur le fond et sur la forme. S’il voit que le contenu n’est pas prêt pour la publication, la publication sera refusée le temps que vous apportiez les corrections nécessaires. Sinon, il sera publié.

Conseils relatif à la validation

La validation pouvant donc durer un moment, il ne faut surtout pas vous précipiter : faites la mise en validation uniquement lorsque vous avez fini de rédiger et de corriger l’intégralité de votre contenu ou à tout le moins, une partie auto-suffisante de votre contenu, sans quoi ce ne sera rien d’autre qu’une perte de temps pour vous et le validateur.

En effet, dans certains cas, les auteurs demandent la validation d’une partie complète et auto-suffisante de leur contenu et repassent par la validation une fois le reste rédigé. Nous reviendrons sur cette particularité dans quelques instants.

Afin de corriger au maximum avant la validation, il vous faudra lire et relire votre contenu pour en débusquer les erreurs ou les faiblesses. Profitez donc de la bêta pour engranger le plus de retours possibles. Si vous avez déjà écrit des contenus, souvenez-vous des retours que vous aviez eu pour voir si vous n’avez pas réitéré des problèmes alors soulevés.

Durant le processus de validation, soyez patient, disponible et à l’écoute. N’hésitez pas à échanger avec votre validateur et à le relancer de temps à autre s’il disparaît dans la nature. :ninja:

La validation a donc aussi ses spécificités.

Point particulier : la validation partielle

Nous mentionnons ici différentes notions liées à la structure d’un contenu sur Zeste de Savoir. Si vous souhaitez vous rafraîchir la mémoire, c’est par ici. :)

Comme nous venons de le dire, il est tout à fait possible de publier une partie auto-suffisante de votre contenu. En effet, il est possible de sélectionner la/les partie(s), chapitre(s) ou section(s) à ne pas valider. Cette option permet :

  • d’une part, d’indiquer au validateur de votre contenu que la partie, le chapitre ou la section ainsi marquée n’est pas prêt(e) à être validé. Le validateur peut toutefois, si vous le souhaitez, relire celle-ci et vous faire part de ses remarques éventuelles.
  • De même, si le validateur publie votre contenu, la partie, chapitre ou section marquée ne sera pas publiée (et ne sera donc pas visible par les lecteurs). C’est la finalité première de cette fonctionnalité qui vous permet de publier tout ce qui est finalisé ( c’est-à-dire corrigé et approuvé par le validateur) à l’exception de la partie marquée comme à ne pas valider.

Pour marquer une partie de votre contenu comme à ne pas valider, cliquez sur la partie, le chapitre ou la section désirée et cliquez sur "Marquer comme à ne pas valider." sous "Actions" dans le menu à gauche.

Marquer comme à ne pas valider
Lien "Marquer comme à ne pas valider".

Vous constaterez ensuite l’apparition d’un bandeau au dessus de l’introduction notifiant que cette partie n’est pas prête à la publication :

Bandeau à ne pas valider
Notification que cette partie n’est pas prête à la publication.

Une fois que vous avez terminé de rédiger cette partie, il suffit de re-cliquer sur le lien (qui indique d’ailleurs "Marquer comme prêt à valider") et renvoyer votre contenu en validation (en indiquant au besoin que seule cette partie doit être relue si vous n’avez pas modifié toute partie précédemment validée et publiée) pour que cette partie soit publiée et mise à la disposition des lecteurs, une fois approuvée par le validateur.

Critères de validation

Dans un premier temps, il est nécessaire de rappeler que tous les contenus ne sont pas autorisés sur Zeste de Savoir. Nous aborderons ensuite les critères généraux dont tiennent compte les validateurs quand ils s’occupent de votre contenu.

Les contenus refusés
Les contenus plagiés

Les contenus entièrement ou partiellement plagiés sont systématiquement refusés. Nous rappelons que le plagiat est un délit. En cas de plagiat, l’auteur du plagiat recevra un avertissement. En cas de récidive, une sanction plus lourde pourra être appliquée.

Les contenus contraires aux conditions générales d’utilisation

Certains contenus sont refusés car leur sujet est clairement à visée illégale et contraires aux conditions générales d’utilisation de Zeste de Savoir.

Parmi ces sujets, on peut citer :

  • l’intrusion malveillante dans un système informatique ;
  • le téléchargement d’applications piratées.

Attention, certains contenus peuvent osciller entre légalité et illégalité. Les validateurs y sont particulièrement attentifs. Citons, à titre d’exemple, un article sur le jailbreak ou un tutoriel Aircrack qui serait particulièrement maladroit dans sa forme (où il y a, par ailleurs, eu un cas de condamnation en justice). Le caractère tendancieux de ce genre de contenus amène à la plus grande prudence et un contenu pourrait se voir refusé si le validateur estime que l’auteur incite à une utilisation malveillante, si l’objet du contenu devient illégal par une évolution récente de la loi ou si l’un ou l’autre élément a fait l’objet d’une décision judiciaire.

Installation (et utilisation) de logiciels simples et trucs et astuces (TEA)

Les contenus présentant simplement l’installation de logiciels clients ou serveurs sont refusés. Par exemple, un tutoriel sur l’installation d’un éditeur de texte.

Il est de même fréquent de recevoir des contenus qui expliquent comment utiliser un logiciel et/ou une extension qui, de base, se révèle plutôt simple à prendre en main comme AdBlock Plus ou Paint, ou fournissent des astuces quant à l’utilisation d’un logiciel donné. Ce genre de tutoriel est refusé.

Nous pouvons désormais entrer dans le vif du sujet ! :)

Les critères de validation

Voici désormais les différents points sur lesquels les validateurs insistent. Certains éléments, tel que la pédagogie, sont plus généraux en raison de la grande variété des contenus et de style des auteurs. Il s’agit néanmoins d’insister sur les éléments considérés comme essentiels.

Le fond
Introduction générale (et des différents chapitres, s’il y a lieu)

L’introduction est l’un des aspects les plus importants de votre contenu. Une bonne introduction doit donner envie de lire le contenu (posez-vous la question : pourquoi le lecteur devrait lire ce contenu ? Qu’est-ce qui le motiverait ?) et donne, par ailleurs, plusieurs informations comme les prérequis nécessaires préalablement à la lecture du contenu, une explication du sujet et de l’angle abordé, le public cible, etc.

Exemples de bonne introduction

Voici un exemple d’une bonne introduction générale :

Vous aimeriez créer une application pour bureau, mais vos compétences se limitent aux technologies du Web comme HTML5, CSS3 et JavaScript ? Ça tombe bien, Electron est là !

Electron vous permettra de créer des applications parfaitement intégrées à Windows, Linux ou Mac OS X simplement avec du HTML, du CSS et un peu de JavaScript.

De nombreuses applications comme Atom, Visual Studio Code, ou encore le navigateur Brave sont basées sur Electron et permettent de créer rapidement de belles interfaces parfaitement intégrées au système d’exploitation, quel qu’il soit.

Prérequis nécessaires
Connaître un minimum HTML5, CSS3 et JavaScript.
Ne pas avoir peur d’utiliser la ligne de commande et savoir l’utiliser basiquement (ouverture, cd …).
Disposer de Node.js, ou au moins de npm.

Prérequis optionnels
Connaître les APIs de Node.js.
Connaître JavaScript dans sa version ES6.

Objectifs
Découvrir Electron, ainsi que certaines APIs qui lui sont spécifiques.
Savoir utiliser electron-packager pour distribuer ces applications.

Vos applications avec Electron - un tutoriel de Bat'

Comme vous le voyez, tous les éléments d’une bonne introduction générale sont présents :

  • Elle doit donner envie de lire, motiver le lecteur ;
  • Elle doit être relativement courte : une introduction de 10 paragraphes redondants raterait sa cible, cela ne donne pas envie de lire ;
  • Elle introduit clairement le sujet abordé par le contenu ;
  • Les prérequis et objectifs éventuels sont indiqués.

L’introduction des chapitres compte aussi beaucoup, ne la négligez pas. Ici, il suffit d’introduire les notions abordées de manière succincte et de soulever l’importance des notions qui suivront. Soyez simples, mais efficaces. Ne développez pas les notions dans l’introduction du chapitre, c’est dans le corps de celui-ci qu’il sera nécessaire de le faire.

Exemple :

Il n’est pas dans ce chapitre question de régler la succession de votre grand-tante par alliance, mais de nous intéresser à l’extension de classes.

Imaginons que nous voulions définir une classe Admin, pour gérer des administrateurs, qui réutiliserait le même code que la classe User. Tout ce que nous savons faire actuellement c’est copier/coller le code de la classe User en changeant son nom pour Admin.

Nous allons maintenant voir comment faire ça de manière plus élégante, grâce à l’héritage. Nous étudierons de plus les relations entre classes ansi créées.

Nous utiliserons donc la classe User suivante pour la suite de ce chapitre.

class User:
    def __init__(self, id, name, password):
        self.id = id
        self.name = name
        self._salt = crypt.mksalt()
        self._password = self._crypt_pwd(password)

    def _crypt_pwd(self, password):
        return crypt.crypt(password, self._salt)

    def check_pwd(self, password):
        return self._password == self._crypt_pwd(password)

Extension et héritage - La programmation orientée objet en Python - un tutoriel d’entwanne
Conclusion générale (et des différents chapitres, s’il y a lieu)

Tout comme l’introduction, la conclusion importe beaucoup. Une bonne conclusion synthétise les grandes lignes du contenu et fourni, si possible, des pistes de réflexion pour approfondir la matière apprise (par exemple, des idées pour améliorer la charte graphique de votre site web, d’optimiser les performances de votre base de données, etc.). La conclusion doit comprendre des références pour aller plus loin lorsqu’elles existent (ce qui est pratiquement toujours le cas :) ).

Exemple : Énergie solaire : du panneau photovoltaïque au réseau électrique.

Pour les conclusions de chapitres, il n’est pas inhabituel (et c’est même recommandé ;) ) d’annoncer succinctement l’objet abordé dans le chapitre suivant.

Il arrive très souvent que l’auteur remercie les membres qui l’ont aidé durant le processus de bêta, le validateur et les lecteurs d’une manière générale. Ce n’est pas obligatoire (mais ça fait plaisir) et cela se fait habituellement dans l’introduction générale ou en conclusion de votre contenu. :)

Pédagogie

Il est très difficile de donner une ligne de conduite qui fonctionne tout le temps en ce qui concerne la pédagogie. Cependant, nous l’avons déjà vu mais il est primordial de le redire, selon le sujet abordé dans votre contenu, vous devez prêter attention à divers éléments : la pertinence des exemples, la fluidité de votre texte et l’évolution logique de votre contenu (plus une lecture est aisée et l’approfondissement du sujet logique, plus le lecteur sera à l’aise pour comprendre le sujet abordé ou l’enseignement du tutoriel), des illustrations lisibles et légendées, la présence de TP, etc.

Ce sont les éléments auxquels les validateurs font inéluctablement attention lors de la validation de votre contenu. Nous vous renvoyons à ce qui a été dit précédemment sur la pédagogie pour de plus amples conseils.

La forme
La rédaction

Précisons d’emblée que votre contenu doit évidemment être rédigé en français. Eh oui, et même rédigé dans un français relativement acceptable, c’est-à-dire sans fautes d’orthographe. Evitez donc le langage SMS (et ses « dérivés »). Vous devez donc avoir une bonne orthographe (si ce n’est pas le cas, faites-vous relire par une autre personne et profitez de la bêta pour améliorer le plus possible votre texte avant de l’envoyer en validation) !

Il existe également nombre de logiciels qui favorisent la correction orthographique et typographique (pour un petit rappel typographique, vous pouvez lire cet article rédigé par qwerty) , voire qui comportent des dictionnaires. Les navigateurs disposent aussi de correcteurs. Citons, Antidote (payant) ou encore Grammalecte (gratuit). Il existe également des correcteurs en ligne, à la manière de bonpatron.com.

Comme vu au début de ce guide, Zeste de Savoir utilise un langage de formatage de texte très proche du Markdown, auquel ont été ajouté quelques extensions courantes. Ce langage est utilisé sur ZdS pour écrire les tutoriels, les articles, les messages de forums, les messages privés, etc.

Savoir l’utiliser est un impératif pour la rédaction et la publication de vos contenus.

Remarque concernant les images et leurs légendes

N’hésitez pas à utiliser des images dans vos tutoriels : c’est le meilleur moyen pour rompre un peu le rythme et illustrer vos propos.

Le formatage markdown d’une image est le suivant :

![Texte alternatif de l’image](url_vers_la_source)

Très souvent, l’auteur a tendance à confondre le texte alternatif de l’image (équivalent de l’attribut alt en HTML) avec la légende.

Dans tous les cas, le texte alternatif doit être renseigné. Il sert à apporter la même information que l’image si celle-ci ne peut être chargée ou bien ne peut être vue (notamment pour les synthétiseurs vocaux pour les non-voyants).

Exemple :

hiéroglyphes dessinés sur un papyrus
hiéroglyphes dessinés sur un papyrus

Mais ce n’est toutefois pas une légende et de ce fait, il n’est pas possible d’y ajouter un lien vers une autre source.

Il est possible d’utiliser une légende, en utilisant le mot-clé Figure:, de la même façon que pour les légendes de tableaux (Table:) ou blocs de code (Code:) :

![hiéroglyphes dessinés sur un papyrus](http://upload.wikimedia.org/wikipedia/commons/9/9d/Papyrus_Ani_curs_hiero.jpg)
Figure: Cette illustration représente des hiéroglyphes dessinés sur un papyrus. Et vous pouvez dès lors utiliser des [liens](exemple.com) !

Résultat :

hiéroglyphes dessinés sur un papyrus
Cette illustration représente des hiéroglyphes dessinés sur un papyrus. Et vous pouvez dès lors utiliser des liens !

Vous devez héberger vos images sur Zeste de Savoir, c’est impératif. Comme ça, elles resteront toujours présentes au côté de votre contenu (et pour rappel, une galerie est automatiquement créée pour chaque contenu afin d’y héberger vos images).

Qualité du code

Les extraits de code et script doivent être testés, bien commentés, structurés et indentés. Attention toutefois, trop de commentaires tue les commentaires ! Si vous mettez des commentaires, mettez le strict nécessaire, sinon la lisibilité du code ne sera pas optimale. Nous y sommes très attentifs.

Exemple de code
def attribut_optimal(self, ID3=True):
    """
        retourne un str avec le nom de l’attribut à tester
    """
    max, ret = float("-inf"), ""
    #pour chaque attribut
    for attribut in self.liste_attributs:
        if ID3:
            gain = self.gain_entropie(attribut)
        else:
            gain = self.ratio_gain(attribut)
        #si le gain d’entropie est le plus grande
        if gain >= max:
            #on le garde en mémoire
            max, ret = gain, attribut
    #et on le retourne
    return ret
Exemple tiré de ce tutoriel de Bermudes.

Pour rappel, vous pouvez (et il est souhaitable de le faire) mettre en évidence des lignes de code pour appuyer votre explication. N’hésitez pas à consulter l’aide markdown sur ce point.


Au terme de ce chapitre, vous en savez désormais plus quant aux retours et aux phases de bêta et de validation.

Nous allons maintenant voir comme faire un retour, ce qui peut aussi vous aider à développer votre œil critique si vous êtes rédacteur.