Breizhogeek, le blog qu'il sent bon la bretagne

Cela fait trop longtemps que ce billet aurait du paraître mais bon, entre les examens, le travail et autres empèchements, je n'ai pas pu prendre le temps de le rédiger. Mais finalement, ce n'est peut-être pas si grave : d'un côté la sortie de la version 3 de Firefox permet de mieux faire ressortir certains éléments de l'article , du fait de certaines améliorations apportées à la gestion de la typographie dans ce dernier et d'un autre son retard important à propos des embedded fonts va contraster ce ridicule concours du serveur saturé le plus vite.
Le web a trop longtemps été limité en matière de typographie : en effet le choix des polices était jusqu'aujourd'hui très restreint puisque seules 9 polices existaient ( ou étaient émulées devrais-je plutôt dire ) sur toutes les plateformes. Le problème résidant dans le fait que les sites web associait à un texte une police présente sur l'ordinateur du visiteur. Or, on peut désormais utiliser des polices stockées sur un serveur. Enfin, "désormais", cette possibilité existait déjà au préalable mais de façon très limitée : seul Internet Explorer le proposait, et ce uniquement pour les polices au format Microsoft il me semble. Avec la sortie d'une nouvelle version du moteur webkit ( depuis quelques mois ), la propriété "@font-face" est désormais disponible aussi bien sur Safari que Konqueror. Ainsi on peut spécifier l'URL des polices à inclure pour pouvoir les réutiliser comme les polices actuelles via font-family, ex:

 @font-face {
   font-family: "Foobar";
   src: url(http://www.serveur.com/foobar.ttf) format("truetype");
 }
 h1 { font-family: "Foobar", sans-serif }

Les possibilités deviennent alors multiples, comme le prouve l'article de Håkon Wium Lie sur A List Apart :

Ca donne envie n'est-ce pas ? Enfin, quoi qu'il en soit, Firefox 3 Le Grand ne gère toujours pas cette propriété... En revanche, l'accent a été mis sur le rendu des polices et du texte tout de même, comme on peut le voir ici : http://www.dria.org/wordpress/archives/2008/06/10/651/ . On peut donc citer des améliorations :

• du crénage ( ajustement de l'espace entre les lettres d'une police à chasse variable, dixit wikipedia )
• des ligatures
• des ligatures partielles
• le rendu de tous les types de polices ( OpenType, TrueType, etc.. )
• le hinting, ce qui peut s'apparenter à un lissage de la police en fonction de la taille

Quelques exemples issus de Wikipedia; dans l'ordre, Crénage, Ligature, Ligature partielle :

Pour conclure on peut penser que bientôt, la typographie sur le web, ça sera que du bonheur ! J'en profite d'ailleurs pour vous glisser un petit outil super pratique pour visualiser et comparer des polices : http://typetester.maratz.com/.

Voici enfin la version 1.5 du plugin qui permet à vos visiteurs de se logguer une unique fois sur votre blog Dotclear 1 ( en tout cas ça n'a pas été testé sur Dotclear 2 ) via leur OpenID. Ainsi, ils n'auront plus que le champ Commentaires à remplir et non plus ceux du nom, email et URL .

CHANGELOG:

• Le formulaire de connexion se trouve maintenant dans le menu et non plus dans le formulaire de commentaires: il tient ainsi plus compte de l'unicité de l'authentification.
• Cette version corrige le bug avec la version 1.2.7.1 de Dotclear et est maintenant compatible ainsi que certains problèmes d'affichage.
• Le visiteur peut maintenant se déconnecter, dans le cas où il utiliserait un ordinateur public.
  

Des aperçus sont disponibles sur la page officielle: http://plugins.dotaddict.org/dc1/details/OpenID.

Le plugin et son archive sont disponibles sur la plateforme http://plugins.dotaddict.org à ces adresses:

• L'installeur: http://plugins.dotaddict.org/files/public/dc1/openid/plugin-openid-1.5.pkg.gz
• L'archive: http://plugins.dotaddict.org/files/public/dc1/openid/plugin-openid-1.5.tar.gz

Il est livré sous la Licence GPL 3 ( en ce qui concerne mes modifications, le reste étant sous les licences pré-établies comme la bibliothèque PHP OpenID de JanRain ).

PS : Si vous utilisez ce plugin, j'apprécierai grandement un message de retour .

Last year, OpenID grew by leaps and bounds both as a technology and as a community. At the beginning of 2006, there were fewer than 20-million OpenID enabled URLs and less than 500 websites where they could be used. Today there are over a quarter of a billion OpenIDs and well over 10,000 websites to accept them

Google, IBM, Microsoft, Yahoo et VeriSign adoptent OpenID et rejoignent donc Orange, Telegraph et bien d'autres dans le cercle des providers de compte OpenID. Du côté utilisateur, de gros projets ( louables ou non - qui a vu un clin d'oeil vers facebook ici ? - ) s'y mettent. On peut citer Blogger ainsi que Facebook. On compte aussi sur

• Wikipedia ( MediaWiki proposant déjà une extension pour OpenID )
• Digg
• AOL
• Microsoft

Il est donc important de mettre en avant vous aussi votre goût pour OpenID. Je compte donc reprendre quelque peu le plugin pour y rajouter quelques features et corrections :

• Tenir plus compte de l'unicité de l'authentification en déplaçant le champ de connexion dans le menu du blog et non pas dans le formulaire de commentaires.
• Proposer une déconnexion: j'édite cet article depuis un pc qui n'est pas chez moi et l'utilisateur suivant, s'il tombe sur mon blog, peut poster à volonter avec mon compte openid.
• Réfléchir à des possibilités de reconnaissance de l'OpenID dans les commentaires ( icônes, etc. ) et ainsi prévoir, dans une troisième version de pouvoir éditer votre commentaire.
• Vérifier et corriger qu'il n'y ait pas de bugs ( valable aussi pour la présentation : ex les parenthèses vides dans le cas où aucun mail n'est retourné ) . Pour les commentaires de retour de bugs, je suis en train de voir ça actuellement avec les personnes concernées.
• Utilisation de la dernière bibliothèque de OpenIDenabled ( actuellement 2.0.1 ).
• Vérification du fonctionnement sous les prochaines versions de: Dotclear 1.4 et Dotclear 2 RC ( oui, enfin ) ?
• Spécifier clairement dans les fichiers que le plugin respecte la licence GPL.

Si vous avez des idées de features à rajouter, postez-les ici, j'essaierai d'en tenir compte lorsque je mettrai à jour le plugin pendant les vacances prochaines, c'est à dire dans 2 semaines .

EDIT : CETTE VERSION N'EST PLUS A JOUR, VEUILLEZ SUIVRE CE LIEN : http://tonweb.naedev.org/blog/index.php/2008/04/14/37-le-plugin-openid-pour-dotclear-en-version-15

Voici, à ma connaissance, le premier plugin Dotclear ( version 1.2.7 ) qui permet à vos visiteurs de s'identifier via OpenID:

• Installeur: http://tonweb.naedev.org/plus/plugin-openid-1.0.pkg.gz
• Archive : http://tonweb.naedev.org/plus/openid.zip

C'est tout simplement un formulaire POST vers la bibliothèque de OpenID enabled, rien de plus donc tout devrait fonctionner ( j'ai bien sûr effectué des tests ) .

Tout d'abord il faut cesser de considérer le web comme un ensemble de présentations agencées mais comme un stockage de ressources.

Un web plus social.

• Le développement des réseaux sociaux ne doit pas se faire au moyens de sociétés où nous ne pouvons contrôler nos données, telles Facebook, Hi5 et bien d'autres. Puisqu'un réseau est un ensemble de liens entre personnes, il semble beaucoup plus logique d'utiliser des outils comme FOAF ^[1], d'autant plus que ce dernier, étant basé sur RDF, est sans doute plus complet .
• Rétroliens entre les blogs : Plus qu'un simple commentaire, un rétrolien ( ou trackback pour les allergiques ) permet de créer une réelle discussion, de façon développée, entre des articles hébergés sur des blogs différents.
• Frameworks : On peut ( enfin ) trouver de plus en plus d'hébergeurs Django et RoR, ce qui permettra à l'avenir de créer un site web complet de façon simple et rapide. Il sera donc plus aisé de contribuer au web.

Un web plus propre.

• Plus de rétrocompatibilité avec les navigateurs obsolètes tels Internet Explorer 6. J'entends par là que les hacks CSS pour IE 6 doivent être supprimés et les développeurs devront se focaliser sur les normes.
• La campagne de sensibilisation des webmasters rétros envers le web sémantique et une construction sémantique elle aussi des pages. Ainsi, finis les designs construits à l'aide de tableaux et de frames.

Un web 3.0.

Si nous considèrons le web 3.0 comme un export du web vers notre pc, je déplore cependant l'utilisation de certains nouveaux aspects comme les widgets ou encore des présentations faites à travers Prism. Cette espèce d'export ne devrait s'effectuer que sur certains points :

• Lecture des dernières actualités via un aggrégateur de flux ( comme RSS et ATOM )
• Accès aux données via, par exemple, des gestionnaires de collection.Ex : je répertorie mes DVD et le logiciel va chercher automatiquement les infos sur l'imdb. Autres ex: Last.fm et Radioblog.

Un web plus pratique, plus beau.

Pour cela les nouvelles technologies que seront le CSS 3, le HTML 5 ou encore le XHTML 2 sont des outils nécessaires. L'accès aux données se fera plus facilement grâce aux nouvelles possibilités que seront les balises vidéo et audio, associées à des hébergeurs gratuits -comme actuellement pour les images- pour ces médias, sans flash, et qui permettent un accès externe. L'authentification pourra se faire de manière générique grâce à des protocoles comme OpenID. La récupération de ces données sera effectuable par leurs URI ( via les ID et CLASS ) ainsi que par les frameworks de description tels RDF ou encore FOAF. Cependant ces micro-formats manquent encore de conventions et d'unification des données. C'est le même cas pour les noms des ID -même si sur ce point les nouvelles balises telles header, nav et footer limiteront ces besoins - , comme le dit si bien Eric Meyer :

"Si un ensemble de conventions de noms pour les identifiants id devaient rallier un concensus, je l'adopterais probablement ici . Mes visiteurs pourraient ainsi appliquer à mes documents des designs issus d'autres sites suivant la même nomenclature".

Un web où vous êtes le héro.

Dans ce nouveau web, nous reprenons le contrôle de nos données, via des outils tels APML que nous mettrions en ligne sur des serveurs sûrs ( pourquoi pas les notres pour les plus paranos ) via des frameworks tels MozillaWeave, qui sont encore à l'état de proof of concept. Dans un même cadre, les frameworks évoluant aujourd'hui ( Django, Erlyweb, RoR, Jelix ) seront probablement des outils nécessaires à une création facile ( et sans trop de connaissances nécessaires ) de sites web, pour les personnes lambda .

C'était le billet d'un blogueur utopiste ( oui, une fois encore ).

Histoire de patienter jusqu'en 2022 ( doh ! ), je vous résume vite fait quelques éléments intéressants de la future version du HTML, la version 5. Cette version sera plus sémantique que la précédente. En effet, des éléments dépréciés tels <center> ou <font> seront supprimés et de nouvelles balises ( ainsi que de nouveaux attributs ) prennent place.

Ainsi on peut citer quelques nouvelles balises:

• video ( avec un attribut poster qui permettra de mettre un aperçu de la vidéo )
• audio
• nav ( on peut supposer que cette balise est une réincarnation de la balise <menu>, maintenant dépréciée ? Cependant ce bloc est fait pour contenir des liens vers d'autres pages )
• header / footer
• article
• section
• figure ( qui encapsulera une balise image et une balise legend , pour plus de clareté )
  

Du côté de la balise input, on aura également une division plus sémantique de la balise puisque celle-ci comptera désormais des types de champs de formulaires pour :

• le temps avec "time"
• les mails avec "email"
• et les URL avec "url"
  
  

On pourra ainsi enfin limiter nos divisions grâce aux blocs de navigation . Du côté pratique, la vidéo et l'audio ont enfin droit à une insertion digne de ce nom, tout comme d'autres documents car nous pourrons apparament aisément insérer un texte d'un autre charset grâce au nouvel attribut correspondant "charset". Cependant il est dommage que Nokia et Apple aient fait pression pour supprimer les formats OGG des spécifications du HTML 5, qui à la base, devaient être les codecs à utiliser pour les médias vidéos et audios. Et enfin il reste un autre point à surveiller : les barres de progrès ( modifiables par exemple en JS ), chose qui selon certains ( qui a dit 'des flasheux" ) , manquait ! La syntaxe serait celle-ci : <progress value="1534602" max="4603807">33%</progress> . Cela permettrait par exemple de montrer la progression d'un téléchargement. On peut se demander si cette balise serait vraiment utile dans un site accessible ( où, donc, les documents seraient légers comme le prévoient les lois de l'accessibilité ) .

Pour conclure, on peut donc espérer un web beaucoup plus pratique mais aussi beaucoup plus sémantique, d'autant plus que le CSS 3 permettra une sélection plus avancée, ce qui limitera le besoin d'utiliser des balises génériques telles div et span !

PS : Ces remarques sont faites à partir du "Working Draft" du 20 décembre 2007 .
PS 2: il semblerait que l'image n'ait rien à voir avec le sujet mais ça fait longtemps que je voulais la sortir, alors voilà

Laurent Bloch a donné une conférence à Amiens aux 8emes RMLL du 10 au 14 juillet 2007 sur l'identité sur le web. Je n'y étais pas mais j'ai récemment regardé la vidéo de cette dernière: la vidéo de la conférence sur l'identité web . Et, puisqu'un blog peut exister pour d'autres raisons que pour l'argent, contrairement à ce que semblent penser certains ( cf. Jack Lewis ) (non je ne ferais pas de lien vers ce blog ), je poste donc cet article afin de recevoir des critiques de personnes ayant également vue cette vidéo ou même ayant participé à la conférence ( on ne sait jamais ). Je peux très bien avoir mal compris ce dont il parlait ou même, si ce n'est pas le cas, avoir une idée critiquable sur le sujet.

Premièrement, la question de l'anonymat sur wikipedia. Laurent Bloch reproche à wikipedia d'être une dictature dans le sens où l'anonymat règne. Il ajoute que dans un magazine scientifique par exemple, on accorde un certain crédit à l'article en fonction de la personne qui l'a écrit et que ceci manque à wikipedia afin d'en assurer la sûreté.

Cependant je voudrais rappeler que les participants non enregistrés voient leur adresse IP enregistrée et donc dans le cas d'une diffamation, on peut bel et bien retrouver l'auteur . Un autre point abordé par L. Bloch est la falsification des informations par des entreprises. Or Wikiscanner permet justement de contrôler cet aspect là, comme le rappelle l'anecdote : Une modification de l'article MSN Search, affirmant entre autres que MSN Search est un concurrent majeur de Google, Yahoo et autres, a été effectuée par l'agence de relations publiques de Microsoft ! ^[1]. Pour ce qui est de la "réputation" et ainsi de la crédibilité de l'auteur, la page http://fr.wikipedia.org/wiki/Utilisateur:Pseudo n'existe pas pour des prunes et permet de se présenter. Ainsi dans l'historique de chaque page on peut voir qui a créé ou modifié l'article et ainsi juger de sa qualité... Il faut tout de même avouer qu'un système d'identité plus mature serait le bienvenu sur wikipedia. On peut alors espérer dans quelque temps une connexion via OpenID, quand celui-ci sera devenu plus mature et plus sûr...

Quand à l'identité web en elle-même, si nos pseudos ou nos adresses IP ne peuvent constituer une réelle identité web, je pense vraiment que l'OpenID peut palier à ce problème.

Voilà, "lachez des comms olol" afin que je sache ce que vous en pensez .

☃

Parceque les entités HTML pour chaque mot accentué c'est moche, parceque l'heure est à l'internationalisation, UTF-8 cay bien, mangez-en !

Beaucoup de sites sont aujourd'hui concus en XHTML notamment par le fait que certains sites de tutoriels, comme le site du zéro, enseignent le XHTML. Mais on remarque souvent que les sites made in XHTML n'utilisent pas le XML . Tout ca pour arriver à la question: pourquoi utiliser le XHTML ?
Je vous propose ainsi d'étudier quelque peu la question en m'inspirant de l'article suivant: "Beware of XHTML". En effet, puisque ces sites n'ont pas utilité du XML le HTML semblerait plus indiqué! Car ok le XHTML c'est plus récent, c'est extensible toussa mais bon il en reste quand même que la version 2 ne sera pas rétrocompatible du fait de l'utilisation des XForms et des XFrames et qu'en plus il n'a pas fait fureur parmi les navigateurs:

• Mozilla (Firefox) (mai 2007):

Servir du HTML 4.01 valide en tant que text/html assure le support le plus large du navigateur et des moteurs de recherche.

• Apple (Safari) (septembre 2006):

Sur le web actuel, la meilleure chose à faire est de créer votre document en HTML4 jusqu'au bout. Un traitement full XHTML n'est pas une option, donc le meilleur choix est de coller systématiquement au HTML4.

• Håkon Wium Lie (CTO d'Opera et membre du W3C) (janvier 2007):

Je ne pense pas que le XHTML soit une option réaliste pour les masses. HTML5 l'est.

• Anne van Kesteren (d'Opera) (aout 2004):

Je préconise de n'utiliser le XHTML que dans une voie correcte, ce qui signifie en gros que tu dois utiliser le HTML. Point.

• Ian Hickson (d'Opera, Google, W3C) (février 2007):

Les auteurs ayant l'intention de présenter leur travail pour une consommation publique devraient utiliser HTML 4.01 .

Par ailleurs, si nous servons un document XHTML de façon correcte et donc en application/xhtml+xml, IE présentera à l’utilisateur une boîte de dialogue proposant de télécharger le fichier. Donc Internet Explorer (toutes versions confondues) ne supporte pas le XHTML. CQFD %%

On voit de plus en plus de sites contenant du FLASH ou même conçus entièrement en flash, or cette technologie a plusieurs défauts, qu'il me semble bon amha, de rappeler afin d'éviter quelques excès ( entendre les sites construits uniquement en FLASH ). Cet article est inspiré de l'article de Patrick Murris (qui a enseigné et faits des sites en FLASH) sur les inconvénients du FLASH .

Du côté du visiteur:

1. Cela ne permet pas l'utilisation des signets ( ou bookmarks, comme vous voudrez ) : quel que soit le stade du fichier auquel on est arrivés, l'url du site ne change pas. On ne peut donc pas mettre un signet sur le point du site auquel on est arrivé!
2. Les impressions via le navigateur ne fonctionnent pas ou alors pas correctement, or c'est au navigateur de gérer l'impression et non le site lui-même !
3. Les traductions (via google par exemple) ne sont pas possibles.
4. L'utilisateur ne sait pas vers quel page pointe un lien s'il positionne sa souris dessus (contrairement au HTML où le lien apparait dans la barre d'état ).
5. Un fichier FLASH contenant du texte est plus lourd qu'un fichier HTML contenant le même texte, du fait de son architecture! En effet, ayant testé un fichier de chaque avec le même texte, le fichier .swf a un poids de 11.3 Ko et le fichier HTML 3.8 ko ! Par ailleurs, le texte n'etant pas accessible, les développeurs créent des sites au contenu vide...
6. Le FLASH ne permet souvent pas la sélection du texte et ainsi donc rend difficile la copie de textes ou d'images, ce qui nuit à l'évolution du web.
7. Le clic droit n'est pas celui du navigateur, et est parfois même désactivé; ce qui a pour risque de perturber le visiteur une fois de plus en n'affichant pas le menu contextuel auquel il est habitué, lui permettant d'accéder à la source, à la sélection, aux informations de la page et aux autres outils (etc.. ).
8. Les galeries d'images en FLASH ne permettent pas la vision de l'image en taille originale la plupart du temps, ou alors dans un format inconfortable (sans barres de défilement ou sans mise à l'échelle de la fenêtre possible).
9. Le streaming produit par flash peut être remis en cause: si c'est au navigateur de lire les pages web, ce n'est pas à lui de lire les vidéos ou encore les sons: c'est la fonction des lecteurs médias, qui produisent, eux aussi, du streaming et vous évitent donc un téléchargement. Or il est plus confortable de regarder une vidéo avec son lecteur favori.
10. La mise en cache des medias est souvent mal utilisée en FLASH. Ainsi, si dans une page HTML une modification est apportée, seul le fichier HTML sera rechargé et non les images et les fichiers de style ou de script, en FLASH la modification d'une seule virgule nécessite le rechargement de tous les éléments dans bon nombre de sites encore (certains ont évolué). Or cela cause un ralentissement ainsi qu'une consommation inutile : certaines personnes ont une connexion limitée en taille.
11. Les liens déjà visités ne changent pas de couleur ni même de style par défaut, ce qui nuit à l'accessibilité, d'autant plus que ca supprime encore une des habitudes du visiteur. Si FLASH permet d'adapter cela et d'arriver à un même résultat, cela demande une programmation plutôt complexe. En FLASH la modification d'une seule virgule nécessite le rechargement des tous les éléments.
12. Le chargement non-progressif des fichiers FLASH vous oblige, dans le meilleur des cas à voir une barre se remplir peu à peu ou alors à charger plusieurs séquences à chaque stade, en effet contrairement au HTML où le chargement progressif permet de lire le texte pendant le chargement des images par exemple, ce n'est pas le cas du FLASH.
13. La résolution n'est pas adaptée à la fenêtre: si certains fichiers FLASH se mettent à la taille de la fenêtre proportionnellement, le texte ou autre affiché dans une petite fenêtre devient vite illisible alors qu'en HTML ce n'est pas le cas. Dans les autres cas l'affichage n'évolue pas et reste dans un cadre fixe.
14. Les polices ne peuvent pas être agrandies comme certains utilisateurs peuvent être habitués à le faire.
15. La recherche par le navigateur (et encore une fois c'est au navigateur de rechercher dans la page et pas la page elle-même ) n'est pas disponible non plus avec la technologie FLASH.
16. Cette technologie n'est pas multiplateforme. En effet aucun lecteur FLASH n'existe pour la PS3, l'utilisateur d'une PS3 souhaitant se connecter à internet se verra donc refusé la vision d'une page concue en FLASH! C'est également le cas pour les systèmes Linux x86_64 ( la version 64bits donc ).
17. FLASH est lourd: en effet son utilisation du processeur est bien plus lourd qu'une page standard (utilisant html (ou xhtml ) et CSS !
18. Un autre problème avec la non-gestion des url est que l'utilisateur utilisant les fonctions page précédente et page suivante de son navigateur, auquel il est habitué depuis qu'il navigue, se verra renvoyé au site précédement visité en utilisant la fonction page précédente et s'il souhait annuler cela et fait donc page suivante, il se verra renvoyé à l'accueil du site en FLASH qu'il visitait.
19. Risque pour l'utilisateur: Flash s'exécute en local. C'est-à-dire qu'il utilise les ressources matérielles de l'ordinateur sur lequel fonctionne le navigateur (carte graphique, carte son, webcam). Intrinséquement cela comporte un risque pour l'utilisateur. D'ailleurs il n'y a pas si longtemps on a dénoté des failles assez graves dans FLASH qui permettaient de prendre le contrôle de l'ordinateur qui exécutait le fichier.
    

Du côté du webmestre:

1. Le FLASH ne supporte pas nativement le CSS: la modification du design n'est donc pas aisée: tout le fichier doit être revu. De plus, si désormais Flash permet d'utiliser un fichier de style pour plusieurs clips ( à l'instar du css pour les pages HTML), ce n'est pas évident.
2. La modification des fichiers compressés (donc ceux lus par le lecteur, les .swf, et non les .fla ) n'est pas possible, le concepteur est donc obligé de reprendre le fichier .fla et de remettre à jour ce dernier puis de le compresser et enfin de le remettre en ligne au contraire du HTML qui est directement modifiable hors ligne et même en ligne si on utilise une technologie serveur comme le PHP.
3. Le référencement du FLASH est plus qu'insuffisant: uniquement les liens et les textes peuvent être indexés.
4. Les logs faits par les serveurs ne comprennent pas la structure interne des fichiers FLASH.
5. L'utilisation des cookies standards n'existe pas et si flash permet de créer des « objets partagés », ceux-ci ne sont pas accessibles par autre chose que flash.

Autres:

1. L'avenir de FLASH ne dépend que d'une société, Adobe, et donc des envies de ses actionnaires. Autrement dit c'est une situation plutôt précaire ! D'ailleurs le fait que la version 8 n'ait jamais été développé pour Linux le prouve!
2. D'autre part, FLASH n'est pas la seule technologie utilisant le vectoriel ou même l'animation: il existe en effet respectivement le SVG ou encore le SMIL pour ces utilisations (non je ne nommerai pas Silverlight ) . Exemples: FACE et Ghost Diagrams, ou encore un Tetris ou un début de FPS .
   

La technologie FLASH est donc, si ce n'est à éviter, à utiliser avec beaucoup de parcimonie et de réflexion (quand à l'utilité, l'accessibilité et même la légéreté).