doc(contributor) Add details about commit type.

Since we defined different commit types and a generic structure, the contributor guide must explain how to write a nice commit title.

Contributor/En/Guide.xyl

@@ -392,6 +392,40 @@ $ git commit</code></pre>
   <p>Do not edit the <code>CHANGELOG.md</code> file. It is automatically
   generated.</p>
 
+  <h3 id="Commit_message_structure" for="main-toc">Commit message structure</h3>
+
+  <p>Has we already seen in the previous section, a commit title must be less
+  than 50 characters long. This title must be precise and reading it must allow
+  to identify the corresponding modifications.</p>
+
+  <p>To facilitate the writing of this title, we defined a structure:
+  <code>type(scope) title</code><p>
+
+  <p>This structure allow to describe very easily which kind of commit is it and
+  on which part. We have indeed isolated several recurring types in a
+  project:</p>
+
+  <ul>
+    <li><code>feat</code> for a new feature,</li>
+    <li><code>fix</code> for a bug fix,</li>
+    <li><code>test</code> for a test modification,</li>
+    <li><code>doc</code> for a documentation modification,</li>
+    <li><code>chore</code> to replace the “Quality” type.</li>
+  </ul>
+
+  <p>For example, we can obtain:</p>
+
+  <ul>
+    <li><code>feat(permission) Search backward bla bla.,</code></li>
+    <li><code>fix(user) `getName` is incorrectly computing its value.,</code></li>
+    <li><code>…</code></li>
+  </ul>
+
+  <p>The goal is to generate a <code>CHANGELOG</code> file as suggested by
+  <a href="http://keepachangelog.com/fr/1.0.0/">http://keepachangelog.com/fr/1.0.0/</a>,
+  so with the “Added”, “Bug fixes”, “Removed“ Sections, and the date of the
+  release.</p>
+
   <h3 id="Review_all_your_commits" for="main-toc">Review all your commits</h3>
 
   <p>Sometimes you will express the need to <strong>list</strong> all your

Contributor/Fr/Guide.xyl

@@ -425,6 +425,41 @@ $ git commit</code></pre>
   <p>Ne modifiez pas le fichier <code>CHANGELOG.md</code>. Il est
   généré automatiquement.</p>
 
+  <h3 id="Commit_message_structure" for="main-toc">Structure d'un message de commit</h3>
+
+  <p>Comme nous l'avons vu précédemment, le titre d'un commit fait 50 caractères
+  au maximum. Ce titre se doit d'être précis et sa lecture
+  doit permettre d'identifier la modification apportée.</p>
+
+  <p>Pour faciliter l'écriture de ce titre, nous avons définit une structure
+  type : <code>type(scope) title</code><p>
+
+  <p>Cette structure permet de très facilement décrire quel est le type de
+  commit et sur quoi il porte. Nous avons en effet isolé plusieurs types
+  récurents dans un projet :</p>
+
+  <ul>
+    <li><code>feat</code> pour une nouvelle fonctionnalité,</li>
+    <li><code>fix</code> pour un correctif,</li>
+    <li><code>test</code> pour une modification liée aux tests,</li>
+    <li><code>doc</code> pour tout ce qui se rapporte à la documentation,</li>
+    <li><code>chore</code> pour tout ce qui concerne la « qualité ».</li>
+  </ul>
+
+  <p>Nous obtenons par exemple :</p>
+
+  <ul>
+    <li><code>feat(permission) Search backward bla bla.,</code></li>
+    <li><code>fix(user) `getName` is incorrectly computing its value.,</code></li>
+    <li><code>…</code></li>
+  </ul>
+
+  <p>L'objectif de la normalisation des messages de commit est de permettre la
+  génération d'un fichier <code>CHANGELOG</code> tel que suggéré sur
+  <a href="http://keepachangelog.com/fr/1.0.0/">http://keepachangelog.com/fr/1.0.0/</a>,
+  avec des sections « Ajouts », « Correctifs », « Suppressions » ainsi que la date
+  de la sortie de version.</p>
+
   <h3 id="Review_all_your_commits" for="main-toc">Relire tous vos commits</h3>
 
   <p>Parfois vous pourrez exprimer le besoin de <strong>lister</strong> tous vos