Ergonomie, Rails et Architecture de l'information web (2.0)

Les mauvaises langues qui diront que j’ai parcouru tous les didacticiels Photoshop estampillés “web 2.0” afin de réaliser ce thème ne seront pas très loin de la vérité. Cette remise à neuf part d’une constatation évidente : difficile de parler d’ergonomie et de webdesign quand on a un design peu soigné, et surtout peu utilisable. Certes, les cordonniers sont toujours les plus mal chaussés, mais il y avait des limites.

C’est la seconde fois que je commence par coucher le résultat final sous Photoshop, avant de me lancer dans le développement, et les résultats sont visibles : c’est nettement plus propre. Ma démarche habituelle consiste à ouvrir Textmate avec une vague idée de ce que je veux faire, et à coder. La démarche inverse, même si elle est beaucoup plus fastidieuse en rajoutant un très grand nombre d’étapes nécessitant un outil que je ne maîtrise pas du tout, est aussi très intéressante, puisqu’elle m’oblige à aborder les problèmes à venir en amont.

J’imagine qu’il y a un certain nombre de bugs sous Internet Explorer, principalement dans sa version 6 à cause du manque de support de l’alpha des images au format PNG, mais je n’ai pas de machines sous Windows pour tester. Ils attendront donc lundi soir que je sois au bureau pour un recensement exhaustif.

Et pour finir, la liste de mes sources d’inspiration :

• Iris Design pour les gros boutons Aqua de la barre latérale.
• Shadowness pour les onglets de navigation.
• Simple entrepreneur pour la mise en valeur des zones de souscription.

Jeudi 5 avril 2007, c’est la CSS Naked Day, une journée durant laquelle tous les heureux possesseurs d’un site web sont invités à retirer gentiment leur feuille de style.

Pourquoi se mettre tout nu ?

L’idée derrière les CSS naked days est de promouvoir les standards du web et l’utilisation d’un XHTML propre, correct sémantiquement, et accessible. Si vous arrivez à naviguer normalement sur ce site sans sa feuille de style (il faudrait que je mette un titre à ma section thématiques), c’est gagné.

[edit]
La journée finie, il était temps de me rhabiller.

La nouvelle n’a pour l’instant fait grand bruit, mais Amazon a passé mercredi dernier un accord avec la fédération nationale des aveugles américaine (NFB) pour améliorer l’accessibilité de son site web aux aveugles et mal voyants.

Dans un accord de coopération, Amazon s’est engagé à poursuivre ses efforts afin de rendre sa plate-forme web plus accessible, tandis que la NFB apportera à Amazon son expertise dans les domaines de l’accessibilité du web

Je trouve la nouvelle excellente, et on ne peut que souhaiter que cette initiative fasse tâche d’huile et permette à d’autres sites phares du web de s’engager sur la même voie. Les entreprises qui souhaitent aujourd’hui proposer du web sans parler d’accessibilité vont se heurter de plus en plus à des impératifs et législatifs et commerciaux, et feraient bien de rapidement changer leur fusil d’épaule. Actualys, la société pour laquelle je travaille est membre du groupe de travail Accessiweb, et nous travaillons régulièrement avec les pouvoirs publics sur des problématiques liées à l’accessibilité des sites des organismes officiels.

On lit régulièrement à gauche et à droite (sic) que les standards du web gagnent du terrain, que les usages changent y compris dans le grand public, que ce soient grâce aux pionniers de l’évangélisation ou à la généralisation des plates-formes de publication générant du code conforme aux standards du web. En un mot, il parait que Monsieur Tout Le Monde produit aujourd’hui un XHTML parfaitement valide, accompagné de feuilles de style valides elles-aussi, légères et bien optimisées. Il parait aussi que l’open source et les logiciels libres gagnent du terrain, que ce soient chez les grands comptes ou dans l’administration, et que le monde entier va bientôt communier dans la liberté des outils, des formats et des idées. Seul une petite enclave américaine, dans la province de Redmond, résisterait encore à l’envahisseur…

Comme je n’avais pas grand chose d’autre à faire de ma matinée, je me suis penché sur les sites de campagnes des différents candidats à l’élection présidentielle de 2007, qu’ils détiennent ou non leurs 500 signatures, et sur leurs usages. J’en ai tiré deux tableaux récapitulatifs, le premier sur les technologies utilisées, et le second sur les standards du web, et les résultats ne sont pas bien glorieux.

La technologie

Pour cette première partie, mes critères de sélection étaient :

• Système d’exploitation.
• Serveur Web.
• Technologie utilisée.

Candidat	Parti	Système d’exploitation	Serveur Web	Technologie
François Bayrou	UDF	Linux Mandriva	Apache 2.2.23	PHP
Frédéric Nihous	CPNT	Linux	Apache 1.3.33	Frontpage (?)
Ségolène Royal	PS	Debian	Apache 1.3.33	PHP
Nicolas Sarkozy	UMP	Linux	Apache 1.3.33	PHP
Gérard Schivardi	RDL	Linux	Apache	?
Dominique Voynet	Les Verts	Linux	Apache	PHP (Dotclear)
Olivier Besancenot	LCR	Linux	Apache 2.0.54	PHP
Marie-George Buffet	PCF	Debian	Apache 2.0.54	PHP
Christian Chavrier	PF	Fedora	Apache 2.0.51	HTML
Jacques Cheminade	S et P	Debian	Apache 1.3.33	PHP
Philippe de Villier	MPF	Debian	Apache 1.3.33	HTML
Nicolas Dupont-Aignant	DLR	Debian	Apache 1.3.33	PHP (Spip)
France Gamerre	GE	Windows 2003 Server	IIS 6.0	.NET
Jean-Michel Jardy	CNI	Linux	Apache	PHP
Arlette Laguiller	LO	Linux	Apache	HTML
Jean-Marie Le Pen	FN	Linux	Apache 1.3.37	PHP
Corinne Lepage	Cap 21	Linux	Apache 2.0.58	PHP

Les systèmes d’exploitation.

Une majorité écrasante des candidats est hébergée sous Linux (94,12%) pour 5.88% de systèmes d’exploitation propriétaires.

Les distributions les plus communément rencontrées sont :

• Debian : 5 (29.41%).
• Fedora : 1 (5.88%).
• Mandriva : 1 (5.88%).

52.94% (9) des candidats n’affichent pas la version de leur système d’exploitation (et il serait particulièrement impoli d’aller à la pêche aux informations à coup de nmap sans leur demander avant).

Les serveurs webs

Là aussi, l’open source est à l’honneur, avec 94.5% d’Apaches, pour 5.88% de IIS 6.0

La répartition entre les versions donne :

• Apache 2.2 : 1 (5.88%).
• Apache 2.0 : 4 (23.52%).
• Apache 1.3 : 7 (41.17%).
• IIS 5.0 : 1 (5.88%).
• Version non communiquée : 3 (23.52%)

Langages utilisés

Curieusement, on trouve encore un certain nombre de sites n’utilisant pas de moteur de rendu, mais simplement des pages HTML statiques. PHP reste pourtant à l’honneur, et .NET arrive bon dernier.

• PHP : 11 (64,7%).
• HTML statique : 4 (23.52%).
• .NET : 1 (5.88%).

Je ne suis pas parvenu à voir ce qu’utilisait Gérard Schivardi.

Développement spécifique, solutions hébergées et open source

Une très faible majorité des candidats s’appuie sur des solutions open source (ou admettent les utiliser). Parmi elles, on trouve :

• Dotclear (Bix, on t’a reconnu) : 1 (5.88%).
• SPIP : 1 (5.88%).

La très grande majorité des candidats s’appuie sur un développement spécifique (70.58%), et seuls 17.64% utilisent des solutions hébergées :

• Blogspirit : 1 (5.8%).
• Over-Blog : 1 (5.8%).
• Haut et Fort : 1 (5.8%).

Les candidats et le standards du web

C’est là que les choses se gâtent, puisque les chiffres sont tout simplement catastrophiques : un seul site passe la validation (Nicolas Sarkozy ), une grande majorité de développements en tableaux, et beaucoup de n’importe quoi, à croire qu’un grand nombre de candidats a recyclé les sites de la campagne de 1995.

Mes critères d’étude pour cette seconde section étaient :

• Modèle de développement.
• Doctype.
• Content Type.
• (X)HTML valide
• CSS Valide

Candidat	Parti	Développement	Doctype	Content Type	(X)HTML valide	CSS valide
François Bayrou	UDF	Divs	XHTML 1.1	text/html	non	non
Frédéric Nihous	CPNT	Tableaux	Aucun	Aucun	non	Pas de CSS
Ségolène Royal	PS	Tableaux	XHTML 1.0 Transitionnal	text/html	non	oui
Nicolas Sarkozy	UMP	Tableaux	HTML 4.01 Transitionnal	text/html	oui	non
Gérard Schivardi	RDL	Tableaux	Aucun	text/html	non	non
Dominique Voynet	Les Verts	Divs	XHTML 1.0 Strict	text/html	non	oui
Olivier Besancenot	LCR	Tableaux	Aucun	text/html	non	Pas de CSS
Marie-George Buffet	PCF	Tableaux	XHTML 1.0 Transitionnal	text/html	non	non
Christian Chavrier	PF	Tableaux	Aucun	text/html	non	non
Jacques Cheminade	S et P	Tableaux	HTML 4.01 Transitionnal	text/html	non	non
Philippe de Villier	MPF	Frames	XHTML 1.0 Frameset	text/html	non	non
Nicolas Dupont-Aignant	DLR	Divs	XHTML 1.0 Transitionnal	text/html	non	non
France Gamerre	GE	Tableaux	Aucun	text/html	non	non
Jean-Michel Jardy	CNI	Tableaux	XHTML 1.0 Transitionnal	text/html	non	non
Arlette Laguiller	LO	Divs	XHTML 1.0 Transitionnal	text/html	non	non
Jean-Marie Le Pen	FN	Tableaux	HTML 4.01 Transitionnal	text/html	non	non
Corinne Lepage	Cap 21	Divs	XHTML 1.0 Transitionnal	text/html	non	non

Les modes de développement

On trouve de tout, un peu comme au bon vieux temps de la Samar’ :

• Tableaux : 11 (64.7%).
• Divs : 5 (29.41%).
• Frames : 1 (5.88%).

Une écrasante majorité de tableaux, qui commencerait presque à me faire sérieusement douter de tout ce que j’ai entendu au sujet de l’adoption des standards du web ces deux dernières années.

Les doctypes

Et vous, vous aimez ça comment ?

• XHTML 1.0 Transitionnal : 6 (35.29%).
• Pas de doctype : 5 (29.41%).
• HTML 4.01 Transitionnal : 3 (17.64%).
• XHTML 1.0 Strict : 1 (5.88%).
• XHTML 1.0 Frameset : 1 (5.88).
• XHTML 1.1 : 1 (5.88%).

Les content Types

Ça sert à quoi au juste ?

• text/html : 16 (94.11%).
• Aucun doctype : 1 (5.88%).

La validation (X)HTML

Et là… c’est le drame !

• Oui : 1 (5.88%).
• Non : 16 (94.11%).

La validation CSS

• Oui : 2 (11.76%).
• Non : 12 (70.58%).
• Pas de CSS (style intégré dans les balises) : 2 (11.76%).

Conclusion

C’est… déprimant comme un dimanche de novembre, ne me vois pas d’autre mot.

En tout cas, cela montre qu’un travail d’évangélisation urgent doit se faire auprès des professionnels, en commençant par la base, c’est à dire les développeurs et les intégrateurs. La prochaine fois, si j’ai le temps, je vous proposerai un comparatif des points d’échec de tous ces sites aux tests d’accessibilité. Et si on me paye très cher, des propositions pour une refonte ergonomique… y’a du boulot !

[edit]

Le blog de Dominique Voynet validera certainement quand son attaché de presse cessera de copier / coller des caractères non UTF-8 depuis son Word OpenOffice.org favori. Bix, si tu m’entends…

Le nombre minimum d’erreurs recensé à la validation tourne autour de 30, ceci pour faire taire ceux qui diraient “oui, mais si ça se trouve, ils ne valident pas pour 2 ou 3 erreurs”.

Note : ce billet ne concerne en rien les velléités d’installation d’une base lunaire permanente par les États-Unis, pas plus que la stratégie militaire en milieu désertique par ailleurs.

Entre la croissance de la largeur des écrans et celle des téléphones mobiles et autres PDA proposant un navigateur web, gageons que la maîtrise de l’espace sera la grande problématique de l’année 2007, et probablement de la suivante.

Si la coutume qui veut qu’on développe en 720 pixels de large pour une résolution de 800600 tend maintenant à s’estomper au profit de 950 pixels pour du 1024760, les jeux ne sont pas faits pour autant. Bien que fort séduisants, les layouts dits “liquides” – car ils s’adaptent et adaptent leur contenu à la largeur de l’écran – posent finalement plus de problèmes qu’ils n’en résolvent.

D’une part, les responsables des chartes graphiques travaillant sous Photoshop, ils sont souvent incapables de penser un espace autre que fixe, et la valeur artistique des layouts liquides tend souvent à désirer. En dehors de celui de Wikio que je trouve tout à fait réussi, je ne crois pas avoir jamais vu de layouts liquides véritablement réussis.

Ensuite parce que, les écrans d’une largeur supérieure à 19 pouces devenant particulièrement abordables dans notre monde de riches – on trouve un 22 pouces pour 400 euros, plus rien à voir avec les 1500 euros minimum de mon 19 pouces acheté il y a 4 ans et demi. Nombreux sont les écrans qui affichent maintenant des résolutions supérieures à 1280 pixels, et une ligne d’une largeur supérieure à 800 pixels est particulièrement pénible à lire, surtout sur la longueur.

Il existe toutefois une solution, qui est celle des layouts semi liquide qui s’adaptent à la taille de l’écran jusqu’à un certain point, en faisant un bon usage de min-width et de max-width, ou de solutions de contournement en Javascript quand ces deux propriétés ne sont pas supportées par le navigateur. Là encore, il s’agit d’une solution à moitié satisfaisante sur les supports de grande largeur : on se retrouve soit avec un très grand espace vide, soit avec des lignes trop longues.

Reste une solution : un layout fixe, mais plein écran.

Mon précédent thème avait pour vocation à mettre le contenu en valeur en débarrassant l’écran de toute source de pollution visuelle gênante – le menu latéral, souvent un nid à publicités – tout en cherchant à occuper l’espace sans pour autant forcer le lecteur à supporter des lignes trop longues.

En utilisant un en-tête coloré faisant toute la largeur de l’écran et offrant une navigation centrée de largeur fixe, on parvient à donner l’illusion du plein écran. Le contenu de la sidebar passe en bas de l’écran selon le même schéma. On parvient ainsi à donner l’illusion du plein écran tout en offrant aux éléments de la sidebar une largeur plus confortable qu’ils ne l’auraient eue sur le coté. L’affichage se fait de manière horizontale et non plus verticale, ce qui permet d’embrasser l’ensemble des éléments d’un seul coup d’oeil et donne une impression de “fourre tout” organisé qu’est bien souvent devenu le menu latéral aujourd’hui.

Ce dernier point prête d’ailleurs à une observation intéressante : en passant d’une disposition verticale à une disposition horizontale, le contenu de ce qui était autrefois un fourre tout dans le menu latéral prend une importance beaucoup plus importante, et on est tenté de le réduire aux informations pertinentes tout en l’ordonnant mieux.

Si j’avais parfaitement réussi à me débarrasser de la sidebar, tout en offrant un lien d’évitement bien placé, je n’avais pas résolu le problème de l’affichage du contenu livré à lui-même sur une seule colonne.

Un premier essai en 720 pixels de large laissait trop de place aux blancs latéraux sur les écrans en 1024*768 et supérieur. Un second essai en 920 pixels de large – pour adapter le contenu à la navigation et au contenu du bas – donnait des résultats catastrophiques en termes de lecture, même avec une police de caractère plus grosse que précédemment.

L’idée m’est venue en visitant Web Designs From Scratch l’autre soir, à la recherche d’une solution acceptable : remettre un menu latéral ne donnant accès qu’au contenu, et à lui-seul, c’est à dire aux différentes catégories du site, pour occuper une partie de l’espace (28% en fait), et utiliser une police de caractères confortable pour le reste du contenu.

Dans le même temps m’est revenu une réflexion que je m’étais faite il y a quelques temps quant à la disposition purement verticale des blogs : puisque je reconquérais l’espace horizontal, il me fallait aussi me réapproprier l’espace vertical. Par exemple en n’affichant plus la longue litanie des 10 derniers billets à l’écran, mais seulement le dernier, et le résumé des précédent dans l’espace du bas devenu source de contenu à part entière.

Et voilà, cela me donne un nouveau thème plus propre, plus lisible, certainement perfectible, et il sera perfectionné, mais la disposition et la mise en valeur des éléments sont là. Histoire de commencer 2007 du bon pied (d’ailleurs si il y a un gentil graphiste pour me donner un coup de main sur 2-3 trucs, je suis complètement preneur, mon sens artistique étant proche de zéro).

Grâce à David, je viens de découvrir l’excellent Web Design From Scratch, site tenu par Ben Hunt, un web designer des plus talentueux. Ben partage ses connaissances professionnelles sur le mode du shareware. Si vous aimez ce qu’il écrit, vous pouvez lui faire une donation via le toujours pratique bouton paypal. La qualité du contenu en elle-même vaut déjà largement le coup, même si le site est en anglais.

Ben prépare actuellement un livre dans lequel il détaillera en détails la refonte de 50 sites web. Rien de bien extraordinaire en soi, ce genre de livres existe déjà en pagaille.

Le livre sera publié sous deux formats :

1. Un PDF disponible gratuitement sur le site.
2. Une version papier présentant deux fois plus de contenu, plus de détails, payante, elle

Ben espère un demi million de téléchargements du PDF.

Là où son idée tient du génie, c’est que les sites refondus seront des volontaires à qui il offre, pour la somme relativement modique de 1100 euros :

1. Une refonte graphique complète.
2. Une visibilité sans précédent, entre les téléchargements du PDF et la vente du livre

Quant à lui, il gagne :

1. Les 50 sites dont il a besoin pour sortir son livre.
2. Pas loin de 55.000 euros avant même la sortie du livre.
3. Une visibilité sans précédent avec son ouvrage en libre téléchargement.

Ou comment partager le beurre, l’argent du beurre et se garder le sourire de la crémière.

Je sais bien que je n’écris pas beaucoup ces derniers temps. J’ai un peu de mal à trouver l’inspiration nécessaire pour compléter la vingtaine d’articles de fond en stockés dans mon répertoire “brouillons”, certains en cours de rédaction depuis le mois de mars. Et je code, beaucoup, en fait. Je viens de faire accepter mon premier gros patch à l’équipe de développement de Typo, et j’en ai soumis un second – près de 4Mo tout compris – cet après-midi. J’aimerais bien terminer la refonte de l’administration avant la sortie de la prochaine version stable, et le travail manque moins que le temps pour le réaliser.

Maurice Svay me demandait tout à l’heure quelles étaient mes prédictions en termes de design web pour l’années 2007. Très bonne question qui vaut largement un billet.

Une place prépondérante donnée au contenu

Il est intéressant de voir combien notre rapport au web a changé ces 5 dernières années. L’agrégation, notamment, nous a fait prendre conscience à juste titre que la valeur d’un site web réside dans l’ensemble des contenus publiés. Le web design de 2007 devrait donc encore accentuer cette tendance en mettant tout particulièrement en avant les éléments pertinents.

La taille des polices de caractères a déjà augmenté par rapport à ce qui se faisait il y a 4 ans, et on devrait voir celle-ci évoluer vers une moyenne de 13 ou 14 pixels. Pour rappel, les navigateurs considèrent la taille standard comme étant 16 pixels.

La lisibilité nécessitant un contraste fort entre le texte et le fond, gageons que les dégradés de blancs et de gris clairs ont encore de beaux jours devant eux. La tendance d’un retours à des sites en blanc sur fond noir ou blanc sur gris foncé devrait aussi se confirmer.

Une à deux colonnes maxi

Déjà en perte de vitesse ces dernières années, les layouts sur trois et quatre colonnes continueront à se raréfier au profit quasi exclusif de thèmes en une et deux colonnes.

Pourquoi cela ? Très (trop) marqués “portails” et “web des années 90”, les designs en 3 et 4 colonnes ne conviennent plus à la structure de la majorité des sites en circulation aujourd’hui, et deviennent le plus souvent des nids à publicité.

Le nombre de points d’entrée sur une page donnée et la profondeur des sites tendent à diminuer. La navigation s’en trouve grandement simplifiée, et l’utilisateur s’y retrouve plus facilement.

2007 sera widgets ou ne sera pas

Il est probable que la navigation des sites deviendra fortement personnalisable via l’utilisation adéquate des widgets. La place des différentes sections du menu des sites à deux colonnes changera au gré des envies du visiteur qui verra ses préférences conservées d’une visite à l’autre.

Peu de fluidité

Peu de layouts liquides ou semi-liquides en 2007 (un layout liquide est un layout qui s’adapte à la taille de l’écran). Je vois 3 raisons à cela :

• Les écrans deviennent de plus en plus larges, et des lignes de 1400 pixels de large sont pénibles à lire.
• Les designers ne pensent pas en termes de layouts liquides, plus difficiles à faire que des designs à taille fixe.
• Les propriétés CSS min-width et max-width ne sont pas supportées par la majorité des navigateurs du marché, ce qui rend leur utilisation plus qu’hasardeuse, et les solutions de contournement en javascript ne sont pas une solution satisfaisante en termes d’accessibilité.

Depuis quelques années, la mode est aux sites centrés sur l’écran, et cette tendance ne devrait pas vraiment changer.

Paix, luxe calme et volupté

Les sites à bords ronds resteront la règle en 2007 tant ceux-ci essaient de nous faire oublier que CSS fonctionne selon un modèle de bêtes boites carrées imbriquées les unes dans les autres. Quand il est bien utilisé, le bord rond donne une certaine impression de calme et de sérénité, idéale pour se pencher sur des contenus de qualité.

Une ergonomie incitative

Tout sera fait pour inciter le visiteur à ne pas quitter le site trop vite. Les chemins de fer, tout en donnant une indication géographique incitent à se pencher sur d’autres parties du site. Des cadres proposant des contenus semblables à celui visité seront disposés à des endroits clé afin de pousser le consommateur à acheter des produits semblables ou liés. En un mot, tout sera fait pour prolonger votre visite avant le passage à la caisse, en mettant en valeur des contenus pertinents.

À vous maintenant

Et vous, qu’en pensez-vous ?

Le 17 décembre 1996, le W3C publiait la première version de ses feuilles de style en cascade. Dix ans plus tard, CSS est entré dans les moeurs au point de profondément changer nos méthodes de développement web : plus léger, plus simple, plus beau.

J’ai découvert CSS un peu par hasard en 1998, dans un article destinés aux webmasters sur iFrance qui s’intitulait “un design au pixel près avec les feuilles de style CSS”. Je m’intéressais assez peu au web à l’époque, en tout cas certainement pas au design, et me contentais de plaquer des feuilles de style minimalistes sur mes différents sites, utilisant div identifiées et balises d’en-têtes hx et p proprement, faisant mon Monsieur Jourdain de la sémantique structurelle sans le savoir.

J’ai commencé à me détourner du développement système et de l’administration UNIX pure et dure pour le web au milieu de l’année 2003 en commençant à réaliser moi-même les thèmes de mon blog personnel. Je me suis rapidement pris au jeu de la mise en forme, du balisage propre, puis du web sémantique, au point d’en avoir fait mon métier après 8 ans de dénigrement du web comme “parent pauvre” de l’informatique.

Bon anniversaire CSS, à la santé de qui je boirai certainement une coupe de champagne… avec style évidemment.

Via 10ème anniversaire pour CSS chez Tristan Nitot.

En tant qu’utilisateur de Mac OS X, mon plus grand soucis dès que je dois tester la compatibilité d’une feuille de style entre les différents navigateurs vient de la difficulté de trouver une plate-forme Windows, disposant en plus des deux dernières versions de Microsoft Internet Explorer (5.5 et 6), et de la toute dernière version de Windows Explorer (la 7 donc).

J’utilisais jusqu’à aujourd’hui les comptes gratuits de browsercam, plutôt pratique pour tester un rendu final sur un très grand nombre de plate-formes, mais pas vraiment idéal en phase de debug. Et puis ce matin, j’ai découvert Netrenderer dans les quelques milliers de billets en retard de mon OPML.

Netrenderer est un service allemand qui permet d’afficher en temps réel les résultats d’une capture d’écran sous une des 3 versions sus-mentionnées du navigateur de Microsoft. Gratuit, sans pub et rapide, il permet de pallier relativement bien à l’absence d’Internet Explorer sur les plate-formes UNIX ou Mac OS X.

Ce billet fait suite à un certain nombre d’expériences malheureuses et conversations survenues ces deux dernières années, dont les plus récentes entre autres avec Mathieu Pillard. Rendons à César ce qui est à César, je râle suffisamment quand on ne me le fait pas.

Je ne sais pas si vous avez remarqué la quantité de gens qui se présentent à des entretiens d’embauche – ou que des sociétés de service peu scrupuleuses vous présentent comme les plus fines gâchettes de la profession – sans avoir jamais développé une ligne du langage dont ils se prétendent pourtant spécialistes. Je me souviens un jour avoir entendu un commercial tentant de vendre un stagiaire technicien réseau au CV maquillé comme une voiture volée en tant que développeur PHP expérimenté. Il clamait à qui voulait bien l’entendre : “Il a déjà fait un site perso en HTML, le PHP c’est facile, n’importe quel imbécile peut en faire, il y a suffisamment de documentation et d’exemples sur Internet, il fera l’affaire”. Deux semaines plus tard, le garçon se faisait dégager de la mission avec pertes et fracas.

C’est sans doutes à cause de ce genre d’anecdote que je crois fermement qu’un simple entretien technique ne suffit pas à déterminer le niveau réel d’un développeur. Un test pratique représente la solution à la fois la plus efficace et la plus intéressante, pour peu, évidemment, qu’il soit mené intelligemment.

Il y a deux ans, j’avais assisté à la mise en place d’une batterie de tests techniques à destination des postulants avec la philosophie de laquelle j’avais du mal à m’accorder.

Dans un premier temps, le candidat devait, en deux heures de temps, développer une petite application simple en PHP, comme un carnet d’adresses, une interface de vente de voitures, ou un annuaire simple. Il s’agissait avant tout de tester ses capacités de “machine à pisser du code”, plus que son degré de réflexion et d’abstraction. Curieusement, sur parfois une trentaine de candidats présentés par des sociétés de service, seuls deux ou trois pouvaient prétendre à passer la seconde partie du test. Seconde partie qui consistait en l’intégration d’un nouveau module dans une application effroyablement compliquée, bourrée de bugs aléatoires, codée avec les pieds par un unijambiste parkinsonien, et reposant sur un moteur de template interne non documenté. Pendant ce temps, certains membres de l’équipe passaient derrière le courageux postulant, regardaient son travail et émettaient des réflexions pas toujours très agréables à son propos. Après ma sortie, je me suis sincèrement demandé s’ils cherchaient un développeur ou un mélange entre Mac Gyver et un bonze tibétain pour les capacités de concentration en milieu particulièrement hostile.

Je trouvais cette manière de faire critiquable sur deux points :

Le premier projet était un exercice d’école basique, sans aucun lien ni dans l’esprit ni dans le domaine fonctionnel avec ce que le postulant aurait à développer par la suite. Malgré le peu de réussite, j’aurais aujourd’hui tendance à dire qu’il était trop facile, et ne correspondait pas aux contraintes techniques de la mission (php objet, javascript omniprésent, ajax partout pour des contraintes de bande passante). Le second projet était particulièrement difficile, trop même, et l’application à reprendre très loin de la moyenne des projets développés au sein de cette équipe. D’autant que l’utilisation du template maison nécessitait quelques jours de formation et d’adaptation en internet.

En un mot, le test visait à recruter des techniciens purs, capables de pondre, de lire et de reprendre du code très rapidement, mais sans aucune méthode ni réflexion, même si les développeurs rapides savent aussi souvent réfléchir à leur code. Cela va bien pour des applications simples, jetables, mais en aucun cas pour des projets complexes et destinés à évoluer dans le temps.

Plus le temps passe, et plus j’envisage le test d’embauche pour les développeurs comme un mélange intelligent de plusieurs éléments avec des coefficients différents :

• Une partie purement technique, afin d’évaluer la connaissance du langage, sur 10 points. Le candidat doit développer quelque chose de simple, mais avec des contraintes particulières, notamment en termes de sécurité, de rapidité ou d’utilisabilité, toutes ces contraintes étant clairement exprimées dans l’énoncé de l’exercice.
• Une partie méthodologie et compréhension sur 20 points. Celle-ci se traduit par une revue de code. Le code est revu avec le candidat qui explique sa démarche, et justifie ses choix.
• Une partie “freestyle”, sur 5 points, qui récompense les candidats ayant dépassé les consignes de base afin d’offrir une application plus sexy, plus agréable à utiliser, ou fonctionnellement plus riche.

L’idée derrière cela est de laisser leur chance à des éléments parfois moins bons techniquement, mais intelligents, capables de réfléchir et d’évoluer avec une bonne tournure d’esprit, pour de les mélanger à des équipes plus expérimentés et leur permettre de parfaire leur technique. Parce qu’une équipe projet n’est pas seulement un investissement pour l’immédiat.