Openweb.eu.org

Les commentaires conditionnels : passé, présent et futur

Nicolas Hoffmann — 2013-05-22T07:21:25Z

Les commentaires conditionnels ont eu une certaine évolution dans leur pratique, Nicolas Hoffmann vous propose une rapide mise en perspective de ce système autant haï qu'apprécié, et un regard sur l'avenir d'une telle possibilité.

Le système des commentaires conditionnels

Les commentaires conditionnels ont été introduits avec la version 5 d'Internet Explorer, et fonctionnent jusqu'à la version 9 de ce navigateur, la 10 ayant abandonné ce système. L'idée de base est de pouvoir cibler une version spécifique d'Internet Explorer et de lui servir une CSS spécifique.

Voici un exemple de code :

Vous pouvez trouver un article complet sur les commentaires conditionnels sur le MSDN (en anglais) : About conditional comments.

Bien qu'en contradiction avec le principe « idéal » d'un unique code pour tous, ce système a eu comme principal avantage de permettre aux intégrateurs de se sortir des problèmes causés par les vieilles versions d'Internet Explorer. Il a également contribué à diminuer l'usage de « hacks » CSS, méthodes peu pérennes et moyennement fiables.

Bien sûr, ce système n'est pas exempt de défauts, entre autres :

il force à maintenir un ou plusieurs fichier(s) CSS, ce qui implique des requêtes supplémentaires,
il peut rendre difficile la maintenance d'un site, principalement à cause de nombreuses surcharges et de l'éparpillement des propriétés entre divers fichiers.

La pratique ayant fait son chemin, le système des commentaires conditionnels a évolué.

Évolution de la pratique vers les classes conditionnelles

La technique dite des classes conditionnelles (aussi appelée « sélecteurs conditionnels ») fonctionne ainsi : des classes vont être ajoutées sur l'élément html via les commentaires conditionnels, et permettront de cibler les éléments pour Internet Explorer.

Voici un exemple de code :

(c'est un simple exemple qui n'a pas force de vérité absolue, il peut être adaptable à vos besoins ou à vos pratiques)

Ces classes permettent de cibler une ou plusieurs versions d'Internet Explorer, par exemple :

.ie8 .header {} ciblera la classe .header sous Internet Explorer 8 ;
.ie7 .nav {} ciblera la classe .nav sous Internet Explorer 7 et inférieurs ;
.oldies .header permettra par contre de cibler la classe .header sous Internet Explorer 8 et inférieurs.

Si la dernière ligne peut vous sembler bizarre, elle a son sens : Internet Explorer 10 ignorera cette ligne vu que les commentaires conditionnels ne sont plus supportés pour les versions strictement supérieures à la 9 (gt = greater than, « supérieur à »), donc tous les autres navigateurs (qui ne supportent pas ces commentaires conditionnels) et Internet Explorer 10 se contenteront de lire html lang="fr".

Note : les classes sont mises sur l'élément html pour éviter un problème de performances sous IE.

Plusieurs facteurs ont favorisé l'adoption massive de cette technique.

Déjà la meilleure connaissance des rendus légèrement « baroques » des vieilles versions d'IE permet de minimiser les problèmes : les intégrateurs connaissent les propriétés dangereuses de celles qui passent partout, ainsi que les bugs de rendu. Cela permet de diminuer la quantité de styles spécifiques aux vieux IE, ces styles pourront être directement mis dans la CSS principale, ce qui permettra en prime d'éviter de charger un fichier CSS supplémentaire sur ces vieux navigateurs peu performants.

Ensuite, ne le cachons pas : le support de ces vieux navigateurs a tendance à disparaître petit à petit, ce dont nous ne nous plaindrons pas. Le concept de dégradation gracieuse a également fait son chemin : là où un client voulait un rendu parfaitement identique sur tous les navigateurs il y a quelques années, il est désormais plus facilement accepté que le rendu sur les navigateurs plus anciens ne soit pas parfait, tant que le site reste raisonnablement utilisable.

Toutefois, cela ne veut pas dire que l'inclusion de feuilles de styles entières via commentaires conditionnels soit totalement à abandonner. Selon le cas de figure et les objectifs du projet, s'il est décidé de favoriser clairement les navigateurs modernes, les styles additionnels pour les anciennes versions d'IE seront à séparer de la CSS principale.

L'exemple typique : pour économiser les requêtes HTTP sur les navigateurs récents, on peut utiliser les Data-URI. Or, si l'on doit assurer un affichage correct sous IE7 (qui ne supporte pas du tout cette possibilité), il faudra préciser le chemin complet vers l'image.

Évidemment, dans le cas où l'on cherche à favoriser les navigateurs modernes, remettre la ligne avec l'image fait perdre tout l'avantage gagné par la Data-URI. Dans ce cas, une feuille de style séparée sera une meilleure option.

Même si le système des classes conditionnelles peut être utilisable pour d'autres buts que le ciblage d'IE et peut être réalisé via d'autres moyens, tournons-nous vers un futur très proche : à l'avenir, il ne sera plus question de cibler un navigateur et encore moins une version particulière, mais plutôt de se baser sur la détection de feature (« possibilité » en anglais).

Vers l'avenir : la détection de features

Comme les moteurs de rendu des navigateurs s'améliorent tous sans exception, le ciblage de versions particulières de navigateurs tel qu'on le pratique principalement avec les commentaires conditionnels avec IE est amené à disparaître… ce dont, rappelons-le, nous ne nous plaindrons pas.

Toutefois, il sera nécessaire de connaitre les capacités de l'agent utilisateur, afin de lui proposer des fonctionnalités en rapport avec ce qu'il peut utiliser.

À cet effet, plusieurs techniques sont envisageables.

Utilisation d'une bibliothèque de détection en JavaScript

Modernizr est la bibliothèque la plus connue en matière de détection des possibilités d'un agent utilisateur. Pour ne donner qu'un exemple, une fois chargée, Modernizr va ajouter des classes sur l'élément html.

Voici un exemple de code généré par son utilisation :

Dans notre exemple, on peut voir que la classe no-flexbox indique que l'agent utilisateur ne supporte pas le mode de positionnement flexbox.

Dans le cas où la classe .header est concernée, il est donc possible de prévoir une roue de secours dans la CSS via .no-flexbox .header {}.

Le principal avantage de cette méthode est d'être fonctionnelle dès à présent. En revanche, son principal inconvénient est d'être basée sur JavaScript, qui est potentiellement désactivable.

Note : l'article se concentre sur CSS pour d'évidentes raisons de longueur, toutefois Modernizr permet aussi de détecter d'autres possibilités de l'agent utilisateur : API JavaScript, support de certaines balises, SVG, etc.

@supports

@support fait partie du CSS3 Conditional Rules Module Level 3. À terme, cette règle permettra une détection native des possibilités CSS de l'agent utilisateur.

Voici un exemple de son utilisation :

@supports (display:flex) { section { display: flex } …
}

Cette propriété serait totalement merveilleuse… si son support actuel n'était pas très faible. Au moment de l'écriture de cet article, seuls Firefox 22 (bêta), Chrome Canary (alpha) et Opera 12.1 (version en cours) annoncent la supporter.

Toutefois, gageons que le support de @supports ne peut que vite s'améliorer !

Conclusion

Le ciblage d'une version spécifique d'un navigateur, à l'exception des vieilles versions d'Internet Explorer, est une pratique qui tend à disparaitre. Pour d'évidentes raisons de maintenabilité, l'orientation de la pratique est plutôt aux classes conditionnelles permettant de maintenir dans la mesure du possible une unique CSS pour tous les navigateurs.

L'avenir passera par la détection directe des possibilités de l'agent-utilisateur ; ainsi les projets pourront garantir une expérience utilisateur optimale avec aussi peu de code que possible.

Références, compléments

Kiwi Party 2013

Le collectif Openweb — 2013-05-04T18:22:31Z

La Kiwi Party est reconduite dans une nouvelle édition cette année, OpenWeb ne saurait trop vous recommander de vous intéresser à cet événement !

La Kiwi Party est un événement gratuit organisé par Alsacréations réunissant conférences et ateliers, autour des thèmes de la conception web et de ses bonnes pratiques : accessibilité, ergonomie, nouveautés technologiques, conformité aux standards.

La Kiwi Party édition 2013 aura lieu le 28 Juin à Strasbourg, les invités d'honneur de cette année seront Tristan Nitot (fondateur et président de Mozilla Europe, défenseur des standards du web sur l'incontournable Standblog) et Bert Bos (rien de moins que le co-créateur du langage CSS, entre autres). L'événement dure une journée.

Le programme complet est sur le site officiel : Kiwi Party 2013.

Comment construire un flux Atom ?

Karl Dubost — 2013-05-03T06:44:37Z

Les flux de sites Web (RSS, Atom) sont utilisés afin de suivre l'actualité de nombreux sites Web. Ils sont pratiques pour les personnes individuelles afin de suivre un grand nombre de sites Web à la fois et permet aux propriétaires de sites de distribuer l'information dans un format contraint. Nous allons voir comment construire un flux Atom solide.

Atom (RFC 4287) est l'un des formats XML qui permet d'avertir et de distribuer les mises à jour de votre site Web. Il a été conçu afin de réduire les ambiguïtés du format RSS 2.0. Après de longues batailles, les acteurs professionnels des outils traitant les flux RSS ont atteint un consensus à l'IETF en décembre 2005.

Si vous avez à choisir, nous vous encourageons à passer à Atom afin de rendre plus simple la maintenance ainsi que l'approche pour les utilisateurs.

Information sur le flux

Bien que le format ne soit pas nouveau, nous allons explorer comment concevoir un bon flux pour votre site Web tout en évitant quelques pièges courants. Cet article s'adresse donc aux gestionnaires de sites Web et aux développeurs de bibliothèques de code permettant de concevoir des flux.

Le format Atom est organisé selon deux axes majeurs :

L'information à propos du flux lui même désignée par feed
L'information à propos de chaque unité d'information désignée par entry

L'enveloppe fondamentale du flux sera ainsi un élément racine feed. Nous ajoutons l'espace de nom qui identifie le vocabulaire spécifique du format Atom. C'est une étiquette permettant aux outils extérieurs de bien identifier le vocabulaire.

…

Il est possible également de définir la langue générale du flux en ajoutant un attribut de langue. Considérons que ce flux sera en français. L'attribut de langue pour le français est fr.

…

Nous pouvons maintenant explorer les informations utiles et spécifiques à propos du flux.

UTF-8 pour le format et HTTP

Le flux est un format XML. Il est recommandé pour éviter tout problème de distribution dans la chaîne de traitement de fichiers XML de vous assurer que l'ensemble de votre flux soit codé en UTF-8.

Cela signifie également que vous preniez un soin particulier à servir le flux avec le Content-Type approprié.

Content-Type: application/atom+xml;charset=utf-8

L'identifiant unique du flux

Les flux de sites Web sont la plupart du temps mélangés avec de nombreux autres dans les lecteurs de flux ou les sites Web qui agrègent l'information. Il est alors important de définir un identifiant unique. Il existe quelques recettes pour définir un identifiant unique. J'utilise pour ma part le schéma d'URI tag: (RFC 4151). Dans le cas du site OpenWeb, j'adopterai le format suivant :

le nom de domaine (celui du site permettant une unification précise)
la date de création d'OpenWeb
le mot blog pour identifier le flux du blog spécifiquement

Ce qui finalement donnera le tag suivant :

tag:openweb.eu.org,2003-03-22:blog

Une fois intégré au flux, nous obtenons :


 tag:openweb.eu.org,2003-03-22:blog
 …

Nous avons maintenant un flux qui peut être identifié uniquement au sein de nombreux autres flux. Nous pouvons imaginer que si nous avions un flux spécifique pour les commentaires, nous pourrions créer :

tag:openweb.eu.org,2003-03-22:blog-comment

afin de distinguer les deux id.

Le titre et sous-titre du Flux

Le titre du flux permet de donner un nom par défaut dans le lecteur de flux des lecteurs. Il est important qu'il soit plutôt court et facile à retenir pour les lecteurs afin de le retrouver au sein des autres flux. N'oubliez pas non plus que vous pouvez avoir plus d'un flux pour un seul site Web. Le sous-titre est bien souvent une phrase permettant de donner une accroche supplémentaire au site. Elle n'est pas toujours utilisée par les lecteurs de flux.


 tag:openweb.eu.org,2003-03-22:blog
 Collectif OpenWeb - Blog
 Bien faire le Web
 …

Si nous avions un flux de commentaires, nous pourrions par exemple avoir un titre légèrement différent :

 Collectif OpenWeb - Commentaires du blog

Auto-référence au flux

Lorsque le fichier XML est distribué et donc hors-contexte du site Web original, il est intéressant de permettre à un lecteur de connaître quelle est l'origine du flux. Ceci est fait en plaçant un élément link avec une relation self. Nous pourrions appeler cette fonction ET appelle maison.


 tag:openweb.eu.org,2003-03-22:blog
 Collectif OpenWeb - Blog
 Bien faire le Web
  rel="self"
 type="application/atom+xml" />
 …

Identification de la page d'accueil

De même si votre site Web possède une page d'accueil pour l'information spécifique où se trouvent les dernières mises à jour, il est bon de pointer vers celle-ci. Un lecteur de flux pourra permettre à l'utilisateur de se rendre sur le site Web avec son navigateur.


 tag:openweb.eu.org,2003-03-22:blog
 Collectif OpenWeb - Blog
 Bien faire le Web
 
 
 …

La date de dernière mise à jour

Cette information est importante car elle permet au lecteur de flux ou à l'agrégateur d'avoir une information supplémentaire sur la fraîcheur de l'information. Le format de la date est strict et doit absolument se situer dans le fuseau horaire Zulu (le temps universel - UTC), soit Z. À chaque fois, qu'une nouvelle entrée est créée et ajoutée au flux, il est nécessaire de mettre à jour la valeur de updated. Si par exemple, vous avez créé une nouvelle entrée le 1er mai à 13h34 (heure d'été), il est en fait le 1er mai 11h34 dans le fuseau Z.


 tag:openweb.eu.org,2003-03-22:blog
 Collectif OpenWeb - Blog
 Bien faire le Web
 
 
 2013-05-01T11:34:00Z
 …

Il ne s'agit pas de donner l'heure du moment, mais bien l'heure de la dernière mise à jour du flux.

L'auteur du flux

Il peut-être utile d'avoir un point de contact pour l'auteur du flux ou l'éditeur du flux, que ce soit une organisation ou une personne individuelle.


 tag:openweb.eu.org,2003-03-22:blog
 Collectif OpenWeb - Blog
 Bien faire le Web
 
 
 2013-05-01T11:34:00Z
 
 Collectif OpenWeb
 http://openweb.eu.org/
 
 …

La licence du contenu

Selon vos circonstances d'affaires et la façon dont vous préférez que vos contenus soient utilisés, vous pouvez indiquer une licence. Il sera possible de préciser la licence pour les contenus individuels. Le contenu des articles d'OpenWeb est sous licence CreativeCommons BY-SA


 tag:openweb.eu.org,2003-03-22:blog
 Collectif OpenWeb - Blog
 Bien faire le Web
 
 
 2013-05-01T11:34:00Z
 
 Collectif OpenWeb
 http://openweb.eu.org/
 
 
 …

Voilà nous avons la structure de notre enveloppe et nous avons spécifié l'information générale à propos du flux, nous allons pouvoir passer aux informations individuelles.

Les entrées du flux

Le flux est composé d'une série d'entrées individuelles contenant une information particulière que nous allons détailler.


 …
 …
 …
 …
 …

L'identification unique de chaque billet de blog

Nous avons déjà vu comment créer un tag unique. Nous allons procéder de même cette fois ci pour les billets. Peu importe le système d'identification choisi, vous devez vous assurer que l'identificateur soit :

unique
stable (quels que soient les changements réalisés sur le billet)

Pour l'article récent Defining Breakpoints publié le 18 février 2013, nous pourrions par exemple, adopter la convention suivante :

tag:openweb.eu.org,2013-02-18:defining-breakpoints

le nom de domaine
la date de publication initiale (ne doit jamais changer)
le chemin dans l'URI (ne doit jamais changer)

Si votre CMS et votre bibliothèque de code a un couplage entre l'URI et le titre du billet, c'est une mauvaise idée de composer son identifiant unique avec. Vous devez déterminer vous-même les éléments robustes pour composer votre identifiant stable et unique. La réflexion plus large sur la stabilité de vos URI dans votre site Web est une conséquence intéressante de ce choix.


 tag:openweb.eu.org,2013-02-18:defining-breakpoints
 …

Notez que cet article est en anglais alors que l'ensemble du flux est en français, nous le précisons.

Auto-référence vers le billet

De même que pour le flux, il peut être intéressant de fournir un lien vers le contenu original sur le site. Spécifiquement si vous décidez de créer un flux avec juste une partie du contenu. Cela permet aux lecteurs de demander au lecteur de flux de se rendre vers le contenu du site Web ou d'importer le reste du contenu.


 tag:openweb.eu.org,2013-02-18:defining-breakpoints
  href="http://openweb.eu.org/articles/defining-breakpoints"/>
 …

Le titre du billet

Le titre de l'entrée est généralement le titre du billet dans votre gestionnaire de contenu. Cependant, si votre système crée des titres plutôt longs, il peut-être bon de trouver un bon titre pour le billet. Il n'est pas nécessaire d'inclure le titre du site Web puisqu'il est déjà disponible dans les informations générales de flux.


 tag:openweb.eu.org,2013-02-18:defining-breakpoints
  href="http://openweb.eu.org/articles/defining-breakpoints"/>
 Defining Breakpoints
 …

Date de publication et de mise à jour

Les dates ont le même format que pour la date générale du flux. Il existe essentiellement deux dates :

la date de publication (immuable)
la date de mise à jour

Une fois de plus, il est important de placer la date de publication dans le fuseau horaire de temps universel. Si vous avez publié et jamais mis à jour votre billet, les deux dates seront identiques.


 tag:openweb.eu.org,2013-02-18:defining-breakpoints
  href="http://openweb.eu.org/articles/defining-breakpoints"/>
 Defining Breakpoints
 2013-02-18T07:49:07Z
 2013-02-18T13:45:58Z
 …

Définir sa politique de mise à jour est une tâche intéressante. Il est possible de définir que chaque modification (correction typographique) doive faire l'objet d'une mise à jour de la date. Cependant ce n'est pas obligatoire, votre politique de mise à jour peut très bien se définir sur un changement de contenu significatif. À vous de mesurer l'enjeu de chaque choix.

Le contenu du billet

Atom permet trois formats distincts pour le contenu proprement dit de l'entrée :

text
html
xhtml

Quel que soit le format choisi, c'est bien souvent l'endroit le plus fragile de votre flux. Il y a quelques règles essentielles à retenir pour que la paix des flux soit assurée.

Si votre flux est codé en UTF-8 (ce que nous recommandons), soyez sûr que le contenu du billet soit converti en UTF-8 avant de l'injecter dans votre flux.
Si vous choisissez text ou html, vous devez absolument convertir tous le contenu afin de neutraliser les caractères réservés, <, > et &.
Si vous choisissez xhtml, vous devez être absolument sûr que votre contenu est bien formé selon les règles XML. Il est bon généralement de passer par un interpréteur XML, car celui-ci produira une erreur en amont s'il y a un problème. Si vous n'êtes pas sûr de votre contenu, vous pouvez utiliser un processeur html5 pour traiter le contenu et le convertir en XML.
Si vous choisissez xhtml, il faut indiquer l'espace de nom XHTML afin de changer le modèle de contenu.
Transformer tous les liens relatifs en liens absolus. Les flux sont lus hors contexte du site Web.

Si vous respectez ces règles, vous allez vous épargner bien des soucis. Par exemple, dans le cas où le flux serait xhtml :


 tag:openweb.eu.org,2013-02-18:defining-breakpoints
  href="http://openweb.eu.org/articles/defining-breakpoints"/>
 Defining Breakpoints
 2013-02-18T07:49:07Z
 2013-02-18T13:45:58Z
 
 
 … ici le reste de votre contenu bien formé …

Voilà, nous avons créé un flux au format Atom. Il y a de nombreuses autres propriétés utilisables afin d'être plus précis. Il est par exemple possible de spécifier les auteurs individuellement pour chaque entrée. Vous pouvez choisir de spécifier des licences différentes en fonction du contenu, etc.

L'art de HTTP et des mises à jour

Nous avons déjà vu qu'il était utile de servir le bon type de contenu pour le flux ainsi que d'indiquer le bon codage de caractères. HTTP est un protocole qui fonctionne sous forme de contrat entre le client et le serveur. Le client demande un statut à propos d'une ressource sur le Web, et le serveur donne une réponse en fonction des informations disponibles. L'en-tête HTTP Last-Modified permet de mieux régler les informations de cache. Nous avons déterminé précédemment que la dernière mise à jour sur le flux était :

2013-05-01T11:34:00Z

Ainsi les en-têtes HTTP doivent accompagner cette modification, en spécifiant par exemple :

Last-Modified: Wed, 1 May 2013 11:34:00 GMT

Attention, le format de date n'est pas le même que celui du flux, cependant le fuseau horaire est toujours GMT.

Validateur de flux Atom

Il existe deux validateurs de flux pour vous aider à comprendre les erreurs de votre flux. Un autre validateur très utile pour tout ce qui est relatif à HTTP peut vous permettre de découvrir les erreurs de vos en-têtes HTTP.

Publiciser votre flux sur votre site Web

Finalement, il est important de permettre aux outils de découvrir votre flux lorsqu'ils passent sur votre site Web. Sur toutes les pages Web qui vous semblent utiles à cette publication, vous pouvez ajoutez dans le HTML une information pour découvrir le flux sous la forme :

 type="application/atom+xml"
 href="http://openweb.eu.org/feed.atom" />

Quelques liens pour aller plus loin

Bon flux, bonne lecture.

Conférence Romande sur l'Accessibilité du Web

Nicolas Hoffmann — 2013-04-29T07:49:07Z

OpenWeb se réjouit toujours de voir que les événements se multiplient dans le Web francophone.

Celui dont nous allons parler est francophone mais a eu lieu en Suisse, cette année à Lausanne pour être précis. En effet, le mardi 16 avril 2013 était le jour de la deuxième édition de la Conférence Romande sur l'Accessibilité du Web (aussi appelée « CRAW 2013 » en abrégé), la première ayant eu lieu à Genève l'année dernière. Cet événement est organisé par la société Telono.

C'est une journée marathon entièrement consacrée à l'accessibilité du Web : ARIA, méthodes, retours d'expériences, démonstration d'aides techniques (comme des synthèses vocales), possibilités du Web mobile, etc.

De très nombreux experts francophones reconnus en accessibilité y étaient présents, tant en orateurs que dans le public.

Nous aurions bien fait un résumé… toutefois Luc Poupard s'y est déjà attelé, et en toute honnêteté, nous n'aurions pas pu faire mieux !

Donc nous vous invitons à lire ses nombreux articles sur le sujet et nous le remercions vivement pour ces compte-rendus très complets.

Si vous êtes un aficionado de Twitter, vous pouvez également suivre le hashtag #CRAW2013 pour voir ce qu'il s'est dit sur le sujet.

Surdité et Accessibilité

Gilles Chagnon — 2013-04-25T06:55:19Z

Cette rubrique est aussi l'occasion d'exhumer des pépites que l'accumulation incessante des informations a peut-être enterrées profondément dans votre mémoire…

Samuel Le Morvan a publié en 2008 (déjà !) une série de trois billets sur la surdité et l'accessibilité. Ces billets restent une référence pour qui souhaite en avoir une vue claire :

Surdité et Accessibilité : constat, sur le contexte général
Surdité et Accessibilité : les sourds sur Internet, sur les problèmes spécifiques rencontrés dans l'utilisation d'Internet
Surdité et Accessibilité : les moyens techniques enfin, signalé surtout pour des raisons « historiques » car les moyens techniques à notre disposition maintenant ont bien sûr évolué.

Des ressources donc encore très utiles pour une première sensibilisation à la situation particulière des sourds sur Internet.

La dette technique en exemple

Nicolas Hoffmann — 2013-04-16T10:13:47Z

De nombreux articles évoquent le concept de dette technique concernant les sites Web. Toutefois, plutôt qu'un long cours théorique, je vous propose… un retour d'expérience.

Le concept de dette technique peut se résumer ainsi : toute erreur de conception implique des coûts supplémentaires dans le futur. Ces coûts, par analogie avec la dette financière, sont appelés les intérêts. Toute la gestion de la dette technique se résume en une question : souhaite-t-on continuer de rembourser des intérêts ou faut-il solder sa dette une bonne fois pour toutes ?

La réponse à cette question n'est pas aussi simple que l'on pourrait croire. Entendons-nous bien : même s'il est aisé de chercher des personnes coupables ou de dire que les solutions étaient évidentes a posteriori, ces problèmes sont loin d'être manichéens. La pression pour mettre en ligne rapidement, les temps de développement, les connaissances manquantes et/ou incomplètes d'un sujet, l'emploi du temps chargé, etc. peuvent vous amener à créer de la dette technique très rapidement.

Une fois ces éléments posés, laissons de côté la théorie et venons-en à une histoire bien concrète tirée d'un cas réel. Et comme toute sombre histoire policière, nous avons des acteurs, une association de malfaiteurs, un crime… et des nettoyeurs.

Ironie du sort (en tout cas du mien), le sujet principal de cette histoire m'est bien connu, car j'ai moi-même écrit un article ici sur le sujet !

Une sombre histoire

Notre client a un site Web d'une certaine importance, ce dernier est en langue anglaise. Propulsé par un CMS de bonne facture, il gère plutôt bien son activité, peu de problèmes sont à relever. Nous sommes il y a un peu plus de huit ans.

Il y a bien quelques modules qui gèrent quelques aspects particuliers, comme de complexes formulaires, mais peu de bugs sortent. Remise en perspective, la qualité du site Web est plutôt bonne.

Trois années passent, le site a beaucoup grandi, l'activité s'est intensifiée. Le site a été connecté la première fois à un CRM avec succès, les différents modules remplissent bien leurs bases de données respectives. Il y a bien quelques curiosités quand il faut faire un export d'une base de données, mais cela se règle en deux clics sous un bon éditeur de code.

Trois années passent encore, une refonte de grande ampleur est lancée, et j'ai fait mon entrée dans cette histoire il y a quelques mois. Un existant conséquent est là, et il faut traiter avec. Les bases continuent de grandir et ne sont déjà plus manœuvrables à la main : comprenez par là qu'il n'est pas possible de patcher un par un les enregistrements si un problème est détecté, en tout cas, pas dans un temps acceptable.

De très nombreux modules sont conçus afin de rendre le client de plus en plus indépendant, et surtout pour garantir une bonne qualité : bon nombre de parties seront ainsi plus prédictibles, et ce afin d'éviter le côté « gestion à la main » de l'ancien site.

Entre temps, le site doit discuter avec un nouveau CRM. L'équipe est constamment sollicitée et – doux euphémisme – ne chôme pas. Croulant sous le travail, l'équipe développe le site de la même manière qu'il a toujours été développé.

C'est là qu'entrent en scène nos méchants.

L'association de malfaiteurs

Il y a bien toujours cette bizarrerie quand est demandé un export d'une base de données. Mais comme on arrive à le gérer à moindre frais, il n'y a aucune raison d'aller s'embêter à gratter ces points de détails.

En fait, en guise de premier malfaiteur, nous avons affaire à un problème dormant : le site étant en anglais, les erreurs de codage ne sautent pas aux yeux. Elles sont même très rares.

Ce problème technique est jugé mineur, et, au vu de la charge dantesque de travail, systématiquement remis à plus tard. Voici notre deuxième malfaiteur.

Troisième malfaiteur, le site (en tout cas ses modules) se développe de la même manière. Jamais au grand jamais, les erreurs ou étrangetés ne sont prises à la source. De toute manière, certaines bases sont devenues si lourdes qu'il n'est pas envisageable d'aller secouer l'arbre sous peine de recevoir de lourds fruits sur la tête.

Dernier malfaiteur pourtant bien innocent, le site a de nombreux modules très interdépendants. Le module « a » se base sur le « b », tel plugin agrège de nombreuses bases pour permettre des vues avancées sur les données, toute la chaîne discute avec le CRM et inversement, etc.

Le crime

L'activité de notre site a explosé, même s'il rayonnait déjà au niveau mondial, il s'implante dans divers pays très sympathiques, comme la France, l'Allemagne, la Suède ou l'Espagne (vous comprenez pourquoi j'évoque ces pays, avec des alphabets si… accentués). Des personnes dans ces pays s'impliquent. L'activité grandit et se diversifie.

Et là, les problèmes dormants commencent à se réveiller : on aperçoit de plus en plus des problèmes de codage, assez imprévisibles. Comment expliquer que parfois les caractères allemands soient bien affichés là où certains caractères français ou suédois sont rendus bizarrement par exemple ? Qui plus est, les pages sont pour la plupart rendues correctement sur PC, là où elles ne le sont pas du tout sur Mac. Et quid de ce bug bizarre : il suffit de rafraîchir la page pour que les erreurs de codage disparaissent miraculeusement sous Internet Explorer (?!).

Il est bien demandé à l'équipe de régler ce problème, toutefois elle se retrouve rapidement bloquée : comment patcher un module utilisé par un autre sans qu'il y ait de la casse dans l'un des deux à l'affichage ?

Les faux-« bons réflexes » viennent rapidement :

incriminer un copié/collé depuis Word dans une zone d'édition riche (qui apporte son lot de code non standard, il est vrai) ;
utiliser à tort et à travers des fonctions comme utf8_encode() ou utf8_decode() pour cacher la poussière sous le tapis ;
incriminer les navigateurs, vu que certains arrivent à afficher correctement les pages, etc.

Certaines tables « autonomes » sont bien patchées rapidement, mais elles sont rares. Le problème s'envenime quand certains clients du site voient leur nom mal affiché (Álexandrò von Öttø Åñdrõß). La tension monte et le site multiplie les erreurs d'affichage dans divers modules. Curieusement, le problème donne l'impression de se propager comme une épidémie, les signalements de problèmes ne font qu'augmenter au point d'entacher la crédibilité du site, et du client par la même occasion.

Le colosse se retrouve… avec des pieds d'argile.

La traque

L'équipe est sommée de régler ce problème au plus vite, tous les développements sont arrêtés : impossible de continuer dans ces conditions. Les mauvaises nouvelles ne venant jamais seules, il est impossible d'utiliser le serveur de développement pour préparer une contre-attaque : ce dernier contient trop de développements en cours, impossible de l'utiliser pour régler ces problèmes !

Dans son malheur, l'équipe a une chance : le site a un troisième serveur, normalement prévu pour faire des essais chez le client. Il est possible de le mettre à contribution. Immédiatement le serveur de production est dupliqué intégralement sur ce serveur de secours. L'équipe cherche une solution globale, toutefois elle doit vite se rendre à l'évidence : la magie n'existe pas, il faudra étudier chaque maillon de la chaîne, et il n'y a aucun moyen de résoudre tout d'un coup.

L'équipe cherche une procédure pour chaque maillon de la chaîne, les essais vont bon train. Elle constate que la fonction utilisée pour échapper les caractères dans les requêtes SQL est défaillante. La base de données a également des problèmes d'interclassement, les fonctions d'import depuis le CRM sont également prises en défaut. Toutes ces fonctions généraient des erreurs qui se compensaient plus ou moins entre elles, d'où le temps constaté pour que le problème « explose ».

Les procédures vont bon train, l'équipe a une chance, les problèmes du site ont une certaine constance. L'équipe se prend même une bonne dose d'optimisme : les solutions arrivent et certaines opérations pourront être effectuées automatiquement. La dose d'optimisme retombe aussi vite, un problème de taille arrive.

Si patcher quelques fichiers n'est pas excessivement dur à déployer, un problème monstrueux se profile : s'il peut être acceptable de dire au client que le flux de données du CRM sera fermé temporairement, que le(s) système(s) de gestion du site seront également bloqués temporairement, comment patcher des bases très lourdes en production sans couper l'accès, sans perte d'information, et surtout sans perte d'activité pour le site ? (car évidemment de nombreux modules rapportent de l'argent, il n'est pas envisageable de les couper)

Toutes les options sont envisagées : travail la nuit, le week-end, etc. L'expert en Analytics cherche même des créneaux horaires propices. Espoir vite oublié : le rayonnement international du site interdit tout créneau acceptable. Il faudra faire sans.

L'équipe cherche alors à minimiser le plus possible l'impact. Il faudra patcher vite et bien en direct sur les bases en production. Les bases les plus lourdes seront patchées en priorité, et une fois que la machine sera lancée, il ne sera pas envisageable de s'arrêter ou même de faire une pause ! Certaines parties non critiques seront fermées temporairement, d'autres seront laissées en production.

… cette stratégie risquée a fonctionné, la quasi-majorité du site a pu être rattrapée.

Les leçons à en tirer

Même si les solutions peuvent sembler évidentes a posteriori, rien n'est manichéen : la gestion d'un historique et d'un existant peut vous amener à faire de mauvais choix, et il n'y aura pas nécessairement de coupable direct : par exemple, la pression du client combinée aux erreurs (même minimes) de l'équipe au début du projet il y a huit ans peuvent dans certaines conditions créer des bombes à retardement.

Ces problèmes dormants sont les pires, ils peuvent subitement vous exploser à la figure, alors qu'ils auraient pu rester en sommeil à jamais. Idéalement, quand ce genre de monstre sort de sa tanière, n'attendez pas : tranchez-lui la tête le plus vite possible, n'attendez surtout pas que le phénomène prenne une trop grande ampleur.

Évidemment, a posteriori, il est simple de remarquer que si l'équipe avait fait une simple vérification il y a huit ans en utilisant des caractères accentués, ce problème aurait pu être résolu en amont. Toutefois, cet aspect restera dans le passé, car nous n'avons aucun moyen de connaître les conditions qui ont généré cette petite erreur aux grandes conséquences.

Dans le plus extrême des cas (et j'insiste bien sur le mot « extrême »), si vous constatez une erreur et qu'on ne vous donne pas du tout la possibilité de la corriger, documentez-la et essayez « au pire » de la garder constante, ainsi, la résoudre à l'avenir sera plus facile.

En tout cas, quand le choix est fait de rembourser la dette, dites-vous bien qu'il ne faut pas lésiner sur les moyens. Répétition générale, serveur dédié, essais, procédures, stratégie, tous les moyens sont bons.

Compléments

Prestataires Web : quelques conseils pour une relation claire et durable

Karl Dubost, Nicolas Hoffmann — 2013-04-11T06:53:54Z

La relation client/prestataire est un exercice toujours difficile. Il l'est d'autant plus quand les prestations proposées sont dans un domaine technologique mal maîtrisé ou loin de votre propre corps de métier. Nous vous proposons quelques astuces afin d'avoir une relation plus harmonieuse avec votre prestataire.

Nom de domaine

Le ou les noms de domaines nécessitent des contacts administratifs et techniques. Il faut s'assurer que vous soyez le contact administratif du nom de domaine, le prestataire pouvant rester le contact technique si vous n'avez pas la compétence ou capacité à le gérer vous-même.

Hébergement et certificats SSL

Il est bon de garantir avec votre prestataire que l'hébergement soit réalisé au nom de votre entreprise, accompagné des conditions de paiements et de renouvellement. Tout site commercial nécessite des certificats SSL, veillez à ce que ceux-ci suivent le même régime. Vous devez rester propriétaires pour être libres.

Confidentialité du contrat

Une relation commerciale est un contrat de confiance. Il est parfois bon de préciser quelles sont les parties du mandat qui sont absolument confidentielles et/ou définir avec votre prestataire quelles sont vos conditions de partage avec un tiers partenaire (sous-contrats, freelance, etc.).

Les données des utilisateurs

Tous les sites Web de transaction requièrent la manipulation de données personnelles individuelles. En établissant les règles de confidentialité et d'utilisation des données des utilisateurs de votre site, vous garantissez le contrat de confiance que vous avez établi avec vos utilisateurs ainsi qu'avec votre prestataire.

L'administration du site

De nombreux sites reposent sur une interface d'administration. Pensez au début du projet à définir les modalités d'accès à cette interface, y compris votre indépendance si vous deviez changer de prestataire. Avoir un petit document décrivant l'interface ainsi que les profils de compétences requis pour gérer le site peuvent être utiles.

Illustrations et médias

Lors de la conception du site, il est parfois nécessaire d'utiliser le travail des autres (police de caractères, photographies, etc.), s'informer des droits et conditions d'utilisation attachées vous permettra de ne pas avoir de mauvaises surprises avec les ayant-droits.

Mentions réciproques

Il n'est pas obligatoire sur votre site de mentionner qui a réalisé votre site, mais il est parfois possible que cela puisse être l'occasion de remercier votre prestataire. Votre prestataire peut également exprimer le souhait de présenter votre site sur le sien. Vous pouvez définir ces points en amont également tout en précisant quels sont les lieux où vous pensez que cela puisse se faire ou ne pas se faire (page Web spécifique, code source, etc.).

Conclusion

Ces petites astuces sont loin d'être exhaustives et ne sont pas une liste de règles de bonne conduite. Mais elles peuvent vous aider à avoir une relation plus saine avec votre prestataire Web. Si vous êtes prestataire, elles permettent aussi d'établir un climat de confiance plus important avec votre client.

10 ans d'Openweb avec… Emmanuel Clément

Emmanuel Clément, Le collectif Openweb — 2013-04-10T05:29:24Z

Aujourd'hui, le membre qui a répondu à nos trois questions n'est autre que celui qui a designé OpenWeb, à savoir… Emmanuel Clément !

OpenWeb : Quand avez-vous connu OpenWeb et dans quel contexte ?

Emmanuel Clément : Je plonge dans le web autour de 1998-99, par hasard, et commence à travailler comme intégrateur html-css en début 2000. A l'époque je découvre tout : le W3C, ALA, Pompage, les CSS qui commencent à donner un coup de pied à la mise en page avec tableaux et gifs transparents. J'aime Internet Explorer 6 qui supporte vraiment mieux les standards (en encore mieux sur Mac !) et je peste contre Netscape 4.7. C'est l'époque de mon apprentissage technique initial. Je suis un peu « boulimique » de tout ce qui peu servir à perfectionner – et *bien faire* – mon métier et servir l'expression graphique, ma formation initiale.

En 2002-2003, je laisse un commentaire chez Tristan (que je ne connais pas encore), à propos des contrastes de couleurs qu'il emploie sur son blog (le Standblog était en texte blanc sur fond noir pour des raisons de confort visuel en ce qui regarde Tristan, je l'apprends par la suite), première sensibilisation à l'accessibilité web, l'air de rien ! Quelques échanges d'e-mail plus tard, Tristan m'invite à participer à un projet francophone autour des standards du web. C'est parti…

OW : Qu'est-ce qu'un projet comme Openweb vous a apporté ?

EC : OpenWeb m'a apporté la sensation d'être « dans le bain » du métier, collectivement, en partageant des valeurs communes avec les membres du collectif. C'est un formidable accélérateur ! Il y avait au début une certaine fierté et une grande chance de faire partie de l'aventure. Aujourd'hui je vois encore OpenWeb comme une sorte de laboratoire, lieu d'échange, de réflexion, de convictions aussi, qui ne trouve pas forcément son équivalent dans le quotidien de la production professionnelle, mais qui l'alimente. Je présume qu'OpenWeb a également eu un impact sur ma vie professionnelle, mais j'ai du mal à l'évaluer.

Et puis tout simplement, ce projet commun m'a fait rencontrer des personnes (des personnages ?) avec qui j'ai sympathisé. Un projet qui fait rencontrer des gens, n'est-ce pas une raison suffisante ? Ça donne envie de lancer un grand « merci ! » à tout le monde !

OW : Et vous verriez quoi pour les 10 prochaines années ?

EC : Aucune idée ! De la même façon que si, dix ans en arrière, la même question m'avait été posée, je n'aurais pas imaginé la période qui s'est écoulée jusqu'à aujourd'hui.

J'ai l'impression que nous sommes en voyage, et comme dans tout voyage, à chaque pas, de nouveaux paysages apparaissent et se modifient.

Pour parler simplement des standards web, l'étendue que couvrent aujourd'hui HTML, CSS, SVG, me parait si importante et de plus en plus difficile à embrasser (sans compter la variété des supports) que j'imagine par exemple une diversification des profils d'intégrateurs encore plus forte et peut-être floue.

Peut-être que le dénominateur commun et « stable » dans tout ce tourbillon technologique est que chacun puisse continuer à bien faire son boulot, apprendre, et y prendre du plaisir.

10 ans d'Openweb avec… Samuel Latchman

Le collectif Openweb, Samuel Latchman — 2013-04-09T05:46:38Z

Notre série se termine bientôt, c'est aujourd'hui Samuel Latchman qui a accepté de répondre à nos trois questions.

OpenWeb : Quand avez-vous connu Openweb et dans quel contexte ?

Samuel Latchman : Je suis tombé professionnellement dans le web en 99, et j'ai tout appris en écumant les ressources anglophones, notamment celles liées aux initiatives du WASP. Mes maigres connaissances me donnaient déjà un sentiment de supériorité un peu facile par rapport à ce qui se faisait en France. Puis un jour on m'a rétorqué que je ferais mieux de partager ce que je savais avec les francophones au lieu de critiquer ! Cette pique m'a réveillé, et je me suis mis à la recherche d'initiatives françaises que je pourrais rejoindre. Je suis d'abord tombé sur Pompage.net en 2002, et ce travail de traduction a provoqué de multiples rencontres avec les autres (rares) passionnés de l'époque. C'est comme ça que je me suis retrouvé contacté par Tristan Nitot pour participer au montage d'Open Web.

OW : Qu'est-ce qu'un projet comme Openweb vous a apporté ?

SL : Un soutien moral, puis pédagogique : j'ai toujours travaillé en agence de communication, et porter en interne les bonnes pratiques s'est parfois apparenté à prêcher dans le désert, surtout pendant les heures de gloire de Flash et des sites jetables. Pouvoir se recentrer avec d'autres personnes qui partageaient les mêmes idéaux, pouvoir échanger avec des profils aux parcours différents mais aux valeurs similaires, pouvoir diriger les personnes qui découvraient le sujet vers des ressources fiables et non marchandes : les initiatives comme OpenWeb ont été un socle nécessaire et précurseur à la compétence web francophone dans les années 2000.

OW : Et vous verriez quoi pour les 10 prochaines années ?

SL : Je suis mauvais en prédictions, je prie juste pour que d'autres projets du même genre se multiplient, et s'étendent sur des domaines moins « techniques » comme l'expérience utilisateur et la gestion de projets. Maintenant que les nouveaux arrivants sur le marché du travail sortent en majorité de cursus formels, je crois que les initiatives pro bono des professionnels doivent de plus en plus s'associer aux plans pédagogiques des écoles spécialisées. Le partenariat Paris Web / CIFACOM de l'année dernière m'a beaucoup plu, par exemple.

10 ans d'Openweb avec… Coralie Mercier

Coralie Mercier, Le collectif Openweb — 2013-04-08T05:33:30Z

Le membre suivant est une membre travaillant au W3C, à savoir… Coralie Mercier !

OpenWeb : Quand avez-vous connu OpenWeb et dans quel contexte ?

Coralie Mercier : J'ai connu Openweb avant ses débuts, par le biais de Karl Dubost avec qui je travaillais au W3C. Je n'ai véritablement connu Openweb qu'après avoir établi des contacts avec « les gens » d'Openweb dans l'année 2011 ; sur freenode/##openweb et via Twitter également. À la suite de SudWeb 2012 le site a repris vie et je m'y suis intéressée sur mon temps libre, ayant à cœur de trouver un jour l'opportunité d'une collaboration avec le W3C.

OW : Qu'est-ce qu'un projet comme Openweb vous a apporté ?

CM : Je me réfère à Openweb pour des articles francophones sur des sujets pour lesquels on me consulte parfois. Certains de mes amis semblent croire qu'en travaillant aux standards du Web j'hérite un savoir et de la technique. Ce que je sais faire c'est chercher, trouver, compiler et interpréter. Et je le fais d'autant mieux que le sujet m'intéresse. Je ne développe pas de site Web (je ne développe même plus le mien par faute de temps et des techno Web qui me dépassent), mais je sais où chercher : Openweb.

La communauté Openweb est enthousiaste, dynamique, volontaire, sympathique et déterminée. Elle m'a apporté l'envie de contribuer à mon niveau. J'ai donc pu apporter à Openweb une traduction en anglais, sur un sujet qui m'est cher — celui de l'agrégation. Et j'aspire à de futures collaborations.

OW : Et vous verriez quoi pour les 10 prochaines années ?

CM : Au rythme où la plateforme Web évolue, c'est une question piège ! J'ai envie de dire « Joker » (avec l'accent, hein, « djocoeur »). Je vois pour les dix prochaines années des didacticiels, des articles qui continuent de cibler les différents niveaux, du contenu qui continue d'aider les gens à faire le Web bien.