-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathprincipes.twig
357 lines (345 loc) · 18.6 KB
/
principes.twig
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
{% extends './views/layout/_page.twig' %}
{% block pageTitle %}Principes — Le beau code web{% endblock %}
{% block docTitle %}BCW-0 Principes du « Beau code web »{% endblock %}
{% block docContent %}
<section id="public">
<h2>
À qui s’adresse ce guide
<a rel="bookmark" href="#public"></a>
</h2>
<p>
Ce guide a été créé par des enseignants et professionnels du web de la communauté du <a href="http://sha.univ-poitiers.fr/masterweb/">master <q>Web éditorial et stratégie UX</q></a>.
Il s’adresse aux étudiants et aux professionnels de la communication au moyen
de sites web ou, plus généralement, d’applications web.
</p>
</section>
<section id="objet">
<h2>
Objet de ce guide
<a rel="bookmark" href="#objet"></a>
</h2>
<p>
Ce guide a pour objet la conception technique d’applications web, dans son sens le plus général. Une application web peut ne proposer que de la consultation de contenu, jusqu’à la manipulation de données et de processus spécifiques (applications métier).
On entendra donc par applications web, notamment :
</p>
<ul>
<li>les sites web (statiques, dynamiques, CMS, e-commerce, etc.),</li>
<li>les applications fonctionnant sur le web (<i lang="en">dashboards</i>, applications métiers, etc.),</li>
<li>les applications web destinées aux mobiles,</li>
</ul>
<p>
dans la mesure où ces applications sont concernées :
</p>
<ul>
<li>par les langages abordés,</li>
<li>par le public visé.</li>
</ul>
</section>
<section id="principes">
<h2>
Principes et objectifs
<a rel="bookmark" href="#principes"></a>
</h2>
<section id="ppe-service">
<h3>
1. Principe de <a class="principle" href="#ppe-service">service</a> de l’utilisateur
<a rel="bookmark" href="#ppe-service"></a>
</h3>
<p>
Une application web est d’abord au service de ses utilisateurs, de ses lecteurs.
On s’attachera donc à l’expérience utilisateur également dans la façon de coder.
</p>
</section>
<section id="ppe-securite">
<h3>
2. Objectif de <a class="principle" href="#ppe-securite">sécurité</a>
<a rel="bookmark" href="#ppe-securite"></a>
</h3>
<p>
Découle du principe de <a class="principle" href="#ppe-service">service</a> : quand plusieurs façons de coder sont possibles, il faut s’efforcer de privilégier la plus sûre.
</p>
</section>
<section id="ppe-performance">
<h3>
3. Objectif de <a class="principle" href="#ppe-performance">performance</a>
<a rel="bookmark" href="#ppe-performance"></a>
</h3>
<p>
Découle du principe de <a class="principle" href="#ppe-service">service</a> : quand plusieurs façons de coder sont possibles, il faut s’efforcer de privilégier l’efficience, en temps d’exécution ou de chargement ou en ressources consommées.
</p>
</section>
<section id="ppe-maintenance">
<h3>
4. Principe de <a class="principle" href="#ppe-maintenance">maintenabilité</a>
<a rel="bookmark" href="#ppe-maintenance"></a>
</h3>
<p>
Les applications web ont vocation à durer dans le temps.
Il convient donc de prévoir que leurs professionnels y reviennent régulièrement.
La maintenabilité est le fait de pouvoir comprendre un code aisément,
s’y repérer, y modifier ce qu’il est nécessaire de modifier, pas plus.
</p>
<p>
Ce principe de <a class="principle" href="#ppe-maintenance">maintenabilité</a> et les objectifs qui
en découlent, ci-après, s’appliquent autant au code
qu’à la documentation associée, interne ou externe.
</p>
</section>
<section id="ppe-standard">
<h3>
5. Objectif de <a class="principle" href="#ppe-standard">respect des standards</a>
<a rel="bookmark" href="#ppe-standard"></a>
</h3>
<p>
Découle du principe de <a class="principle" href="#ppe-maintenance">maintenabilité</a> : on ne devrait pas avoir à revenir sur un document quand il n’y a pas besoin de modifier son contenu.
Le respect des standards permet une plus grande durabilité du code.
</p>
<p>
Ce principe facilite aussi la collaboration entre plusieurs acteurs, simultanément ou au cours de la durée de vie d’un code.
</p>
<p>
Parmi les standards reconnus, on s’attachera en particulier à respecter l’esprit des <a href="https://www.w3.org/TR/html-design-principles/"><cite>Principes de conception du HTML</cite></a> [<a href="#bibid-HTMLDP">HTMLDP</a>], notamment :
la compatibilité,
l’utilité, dont la priorité au terrain,
la modularité (<i lang="en">separation of concerns</i>),
l’interopérabilité et
l’accès universel.
La priorité au terrain impose, notamment, de s’attacher autant que possible aux usages déjà répandus, quand ils ne sont pas contraires aux grands principes retenus ici.
</p>
</section>
<section id="ppe-lisible">
<h3>
6. Objectif de <a class="principle" href="#ppe-lisible">lisibilité</a>
<a rel="bookmark" href="#ppe-lisible"></a>
</h3>
<p>
Découle du principe de <a class="principle" href="#ppe-maintenance">maintenabilité</a> :
le code doit minimiser la charge cognitive de sa lecture.
En particulier, il convient d’être régulier, d’éviter les formulations ambiguës ou techniquement ou conceptuellement complexes quand elles ne sont pas nécessaires.
</p>
</section>
<section id="ppe-coherence">
<h3>
7. Objectif de <a class="principle" href="#ppe-coherence">cohérence</a>
<a rel="bookmark" href="#ppe-coherence"></a>
</h3>
<p>
Découle de l’objectif de <a class="principle" href="#ppe-lisible">lisibilité</a> :
la cohérence est le fait d’appliquer des choix de façon homogène au sein d’un projet ou d’un collectif de travail.
Elle permet ainsi d’alléger la charge cognitive pour lire, créer ou modifier un code.
</p>
</section>
<section id="ppe-accessible">
<h3>
8. Objectif d’<a class="principle" href="#ppe-accessible">accessibilité</a>
<a rel="bookmark" href="#ppe-accessible"></a>
</h3>
<p>
Découle des principes
de <a class="principle" href="#ppe-service">service</a> et
de <a class="principle" href="#ppe-maintenance">maintenabilité</a> :
quand plusieurs façons de coder sont possibles,
il faut s’efforcer de privilégier les plus accessibles.
</p>
<p>
<q>L’accessibilité numérique consiste à rendre les services de communication au public en ligne accessibles aux personnes handicapées, c'est-à-dire :
perceptibles […] ;
utilisables […] ;
compréhensibles […]
et robustes : par exemple, optimiser la compatibilité avec les
utilisations actuelles et futures, y compris avec les technologies
d’assistance.</q>
[<a href="#bibid-RGAA">RGAA</a>]
</p>
<p>
Les méthodes d’accessibilité permettent également à certains
outils, comme les moteurs de recherche, d’être plus efficaces.
Outre la <a class="principle" href="#ppe-maintenance">maintenabilité</a> en général,
l’accessibilité peut améliorer la
<a class="principle" href="#ppe-coherence">cohérence</a>
en formalisant la structuration de la documentation
et de certaines fonctionnalités.
</p>
</section>
</section><!-- /#principes -->
<section id="glossaire" class="glossary">
<h2>
Glossaire
<a rel="bookmark" href="#glossaire"></a>
</h2>
<section>
<h3>Typographie</h3>
<dl>
<dt>alphanumérique</dt>
<dd>
Un caractère <dfn>alphanumérique</dfn> est un chiffre ou lettre latine, minuscule ou majuscule, sans accent ni diacritique. Certains langages ajoutent également le souligné (<code class="language-none">_</code>).
</dd>
<dt id="def-casse">casse</dt>
<dd>La <dfn>casse</dfn> est la différence entre minuscules et majuscules.</dd>
<dd>
Du temps des presses mécaniques, la <dfn>casse</dfn> était le casier dans lequel on rangeait les caractères. Ainsi <q>bas de casse</q>, en anglais <q lang="en">lower case</q>, est synonyme de <q>minuscule</q> et <q>haut de casse</q>, en anglais <q lang="en">upper case</q>, de <q>majuscule</q>.
[<a href="https://fr.wikipedia.org/wiki/Casse_(typographie)">Wikipedia</a>]
</dd>
<dt id="def-kebab-case" lang="en">kebab-case</dt>
<dd>
Mots écrits en minuscules, joints par des tirets.
</dd>
<dd>
Le terme <q lang="en">kebab</q> désigne de la viande rôtie, en particulier à la broche. Dans le -<dfn lang="en">kebab-case</dfn>⊸, les mots sont comme embrochés.
</dd>
<dt id="def-camel-case" lang="en">camelCase</dt>
<dd>
Mots collés entre eux, les initiales en majuscules sauf la première, les autres lettres en minuscules.
</dd>
<dd>
Le langage de programmation Camel a popularisé cette notation.
On dit parfois que les bosses sont au milieu comme pour un chameau.
En anglais, le mot <q lang="en">camel</q> désigne aussi bien un chameau 🐫 qu’un dromadaire 🐪.
</dd>
<dt id="def-pascal-case" lang="en">PascalCase</dt>
<dt id="def-studly-case" lang="en">StudlyCase</dt>
<dd>
Mots collés entre eux, les initiales en majuscules, les autres lettres en minuscules.
</dd>
<dd>
Le langage de programmation Pascal a popularisé cette notation.
Le terme <dfn lang="en">PascalCase</dfn> est univoque.
Le terme <dfn lang="en">StudlyCase</dfn>, parfois employé, <em>peut</em>, lui, désigner d’autres écritures.
</dd>
</dl>
</section>
<section>
<h3>Autres termes techniques</h3>
<dl>
<dt>version</dt>
<dd>
Versionnement sémantique [<a href="#bibid-SemVer">SemVer</a>] :<br> Premier nombre, <q>majeur</q> : changements non-rétrocompatibles.<br> Second nombre, <q>mineur</q> : ajouts rétrocompatibles aux règles.<br> Troisième nombre, <q>correctif</q> : corrections rétrocompatibles d’anomalies.
</dd>
<dd>
Pour être plus précis, un changement de numéro majeur
correspond à un renforcement d’une règle
(ajout de <q><abbr title="" class="rfc2119">doit</abbr></q>
ou <q><abbr title="" class="rfc2119">devrait</abbr></q>).
Un changement de mineur correspond à un relâchement
d’une règle, à l’ajout d’un
<q><abbr title="" class="rfc2119">peut</abbr></q>,
ou à l’ajout de clarifications ou d’exemples.
Un changement du numéro de correctif correspond à une
correction d’orthographe, de grammaire ou de style ou à un
changement de mise en forme ou d’organisation des contenus.
</dd>
<dd>
Les versions en cours de rédaction peuvent avoir également
un numéro de prélivraison :
<code>A.B.C-alpha.N</code>, de même que celles en cours
de discussion :
<code>A.B.C-beta.N</code>, <code>A.B.C-pre.N</code>.
La version peut être suivi d’une métadonnée d’étape
sur le dépôt.
</dd>
</dl>
</section>
<section>
<h3>Modalités aux termes de la [<a href="#bibid-RFC2119">RFC2119</a>]</h3>
<dl>
<dt class="rfc2119" data-glossary-variants="doivent">doit</dt>
<dt class="rfc2119" data-glossary-variants="devront">devra</dt>
<dt class="rfc2119" data-glossary-variants="obligatoires">obligatoire</dt>
<dd>Ce(s) terme(s) désigne(nt) une exigence absolue de ce guide [<a href="#bibid-RFC2119">RFC2119</a>, §1].</dd>
<dt class="rfc2119">ne doit pas</dt>
<dt class="rfc2119">ne devra pas</dt>
<dd>Ce(s) terme(s) désigne(nt) une interdiction absolue de ce guide [<a href="#bibid-RFC2119">RFC2119</a>, §2].</dd>
<dt class="rfc2119" data-glossary-variants="devraient">devrait</dt>
<dt class="rfc2119" data-glossary-variants="recommandée recommandés recommandées">recommandé</dt>
<dd>Ce(s) terme(s) signifie(nt) <q>qu’il peut exister des raisons valables dans des circonstances particulières pour ignorer un élément précis, mais toutes les implications doivent être comprises et soigneusement pesées avant de choisir une voie différente</q> [<a href="#bibid-RFC2119">RFC2119</a>, §3].</dd>
<dt class="rfc2119">ne devrait pas</dt>
<dt class="rfc2119">non recommandé</dt>
<dd>Ce(s) terme(s) signifie(nt) <q>qu’il peut exister des raisons valides dans des circonstances particulières quand le comportement spécifique est acceptable ou même utile, mais les répercussions complètent devraient être comprise et le cas soigneusement évalué avant d’implémenter [ceci]</q> [<a href="#bibid-RFC2119">RFC2119</a>, §4].</dd>
<dt class="rfc2119" data-glossary-variants="peuvent">peut</dt>
<dt class="rfc2119" data-glossary-variants="facultative facultatifs facultatives">facultatif</dt>
<dd>Ce(s) terme(s) signifie(nt) que ce choix <q>est vraiment facultatif</q> [<a href="#bibid-RFC2119">RFC2119</a>, §5].</dd>
<dd><q>Un fabricant peut choisir d’inclure l’élément parce que un secteur particulier du marché le réclame ou parce que le fabricant pense que cela améliore le produit tandis qu’un autre fabricant peut omettre le même élément. Une mise en œuvre qui n’inclut pas une option particulière <abbr title="" class="rfc2119">doit</abbr> pouvoir interopérer avec une autre mise en œuvre qui n’inclut pas l’option, peut-être au prix de fonctionnalités réduites. Dans la même veine, une mise en œuvre qui n’inclut pas une option particulière <abbr title="" class="rfc2119">doit</abbr> être préparée à interopérer avec une autre mise en œuvre qui n’inclut pas l’option (excepté, bien sûr, pour la caractéristique fournie par l’option).</q></dd>
</dl>
</section>
</section><!-- /#glossaire -->
<section id="bibliographie">
<h2>
Références
<a rel="bookmark" href="#bibliographie"></a>
</h2>
<ul class="bibliography">
<li class="hcite" id="bibid-HTMLDP">
<span class="identifier">[<a class="url" href="http://www.w3.org/TR/2007/WD-html-design-principles-20071126/">HTMLDP</a>]</span>
<span class="creator vcard"><span class="fn">van Kesteren, Anne</span> (éd.)</span>,
<span class="creator vcard"><span class="fn">Stachowiak, Maciej</span> (éd.)</span>.
(<time class="copyright date-published" datetime="2007-11-26">26 nov. 2007</time>).
<cite class="fn" lang="en">HTML Design Principles</cite>.
<span class="publisher vcard"><span class="fn org">W3C</span></span>.
<span class="format" lang="en">W3C working draft</span>.
</li>
<li class="hcite" id="bibid-RFC2119">
<span class="identifier">[<a class="url" href="https://www.ietf.org/rfc/rfc2119.txt">RFC2119</a>]</span>
<span class="creator vcard"><span class="fn">Bradner, Scott</span></span>.
(<time class="copyright date-published" datetime="1997-03">1997</time>).
<cite class="fn" lang="en">Key words for use in RFCs to Indicate Requirement Levels</cite>.
<span class="publisher vcard"><span class="fn org">IETF</span></span>.
RFC 2119 / BCP 14.
</li>
<li class="hcite" id="bibid-RGAA">
<span class="identifier">[<a class="url" href="https://www.numerique.gouv.fr/publications/rgaa-accessibilite/">RGAA</a>]</span>
<span class="creator vcard"><span class="fn org">Direction interministérielle du numérique</span></span>.
(<time class="copyright date-published" datetime="2020-12">2020</time>).
<cite class="fn">Référentiel général d’amélioration de
l’accessibilité, RGAA 4.1</cite>.
<span class="publisher vcard"><span class="fn org">gouvernement français</span></span>.
</li>
<li class="hcite" id="bibid-SemVer">
<span class="identifier">[<a class="url" href="https://semver.org/lang/fr/spec/v2.0.0.html">SemVer</a>]</span>
<span class="creator vcard"><span class="fn"> Preston-Werner, Tom</span></span>.
<cite class="fn">Gestion sémantique de version 2.0.0</cite>.
</li>
<li class="hcite" id="bibid-TechSEO">
<span class="identifier">[<a class="url" href="https://www.editions-eyrolles.com/Livre/9782212679861/techniques-de-referencement-web">TechSEO</a>]</span>
<span class="creator vcard"><span class="fn">Martin, Alexandra</span></span>,
<span class="creator vcard"><span class="fn">Chartier, Mathieu</span></span>.
(<time class="copyright date-published" datetime="2021-02-18">2021</time>).
<cite class="fn">Techniques de référencement web, Audit et suivi SEO</cite>.
<span class="publisher vcard"><span class="fn org">Eyrolles</span></span>.
4<sup>e</sup> édition.
</li>
</ul>
</section><!-- /#bibliographie -->
<section id="mentions-legales">
<h3>
Mentions légales
<a rel="bookmark" href="#mentions-legales"></a>
</h3>
<p>
<a class="bcw" href="./">Le beau code web</a> est distribué sous licence libre
<a href="LICENSE">GNU GPL, version 3</a>.
</p>
<p>
<a class="bcw" href="./">Le beau code web</a> ne conserve pas de données personnelles,
ne dépose pas de <i lang="en">cookies</i>
et ne comporte pas de publicité ni de contenu sponsorisé,
mais son hébergeur peut avoir recours à l’un de ces moyens.
</p>
<p>
<a class="bcw" href="./">Le beau code web</a> est hébergé par
<i class="fab fa-github"></i> Github à partir du dépôt Git
<a href="https://github.com/YannisDelmas/beau-code-web/"><i class="fab fa-github"></i><code class="language-none">github.com/YannisDelmas/beau-code-web</code></a>.
Il s’agit d’une œuvre collective dont les contributeurs sont listés sur ce dépôt.
Le directeur de la publication est
<a href="https://github.com/YannisDelmas/">Yannis Delmas</a>.
Il peut être contacté via les coordonnées indiquées sur
<a href="https://delmas-rigoutsos.nom.fr/" title="Yannis Delmas">son site personnel</a>.
</p>
<p>
Le thème utilisé emploie comme image de fond
« <a href="https://www.toptal.com/designers/subtlepatterns/rice-paper/">Rice Paper</a> »
de Alte Mo.
Certains exemples peuvent utiliser des images publiées par le site
<a href="http://lorempixel.com/">LoremPixel.com</a>.
</p>
</section><!-- /#mentions-legales -->
{% endblock %}