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

Intéressante discussion la semaine dernière avec le responsable du service clientèle d’un fournisseur de télécommunications sur l’emploi fait par les utilisateurs des formulaires web de demande d’aide à la hotline.

En substance, il s’avère que, concernant les menus déroulants servant à qualifier les problèmes rencontrés par ses clients, cet opérateur m’a fourni les chiffres suivants :

• 90% choisissent la première option, quelle qu’elle soit.
• 5% choisissent l’option autres si elle est présente.
• 5% choisissent une option plus ou moins en rapport avec leur problème.

Cette constatation introduit deux problèmes évidents :

Les problèmes étant répartis entre les différentes équipes en fonction de leur typologie, un travail de requalification de l’affaire doit être effectué systématiquement avant traitement, avec une retransmission à l’équipe concernée. Outre l’allongement des délais de traitement, cela implique aussi une charge de travail supplémentaire, qui passe par l’analyse de diatribes rédigées dans un français généralement douteux par Madame Michu, dont je vous reparlerai très bientôt.

Vus ces chiffres, quel crédit accorder aux données émises via un menu déroulant, et par extension, par toute zone de formulaire à choix multiples ? Dès lors, on doit classer ces données en trois catégories :

• Celles qui impliquent une dépense ou un investissement du client, par exemple la durée d’un abonnement. On peut raisonnablement tabler sur la fiabilité d’une telle donnée puisqu’elle implique une variation du paiement à l’arrivée.
• Celles qui sont absolument indispensables au traitement du formulaire et qu’une intervention humaine ne peut permettre de recouper à partir d’autres renseignements.
• Les données purement statistiques.

Quant à notre opérateur, afin de mieux répartir le travail entre les équipes chargées des différentes typologies de problèmes, il a tout simplement décidé de générer ses menus déroulants dans un ordre aléatoire.

La phrase du jour :

Ceux qui pensent que le web 2.0 a inventé l’User Generated Content se mettent autant le doigt dans l’oeil que ceux qui doutent de son modèle économique. Les Grosses Têtes font de l’UGC depuis plus de 30 ans, et ma foi, RTL ne s’en sort pas si mal.

Extrait d’une conversation sur la pérennité de l’ego comme générateur de contenu sur le web.

Toute l’équipe de développement a le plaisir de vous annoncer la sortie de Typo 4.1.1. Cette version mineure fait partie de notre volonté de raccourcir le cycle de développement de l’application. Bien qu’elle s’attache surtout à corriger les bugs relevés dans la version 4.1, elle apporte aussi son lot de nouveautés.

Prévisualisation des billet

Nombreux sont les utilisateurs de Typo en environnement mutualisé à nous avoir fait part de problèmes liés à la prévisualisation des articles en AJAX. Bien que sympathique, cette fonctionnalité est particulièrement gourmande en ressources processeur. Vous pouvez maintenant la désactiver totalement ou utiliser l’éditeur visuel riche TinyMCE.

Statistiques

Nous avons intégré l’outil de statistiques Sitealizer à l’administration. Il s’agit pour l’instant d’un test, et tout retour de votre part sera grandement apprécié. Nous prévoyons d’y ajouter quelques options de configuration – notamment la possibilité d’activer ou non ce greffon – dans une version à venir.

Traduction en Allemand et Roumain

Le processus de traduction de Typo initié dans la version 4.0 suit son cours. Merci à Alex Deva pour la version roumaine et à Frithjof Eckhardt pour la version allemande.

Sidebars multiples

Il vous est maintenant possible d’appeler des éléments de sidebar depuis n’importe où dans votre code :

Nous espérons que cela vous permettra de créer des layouts à 3 colonnes plus facilement.

Suppression des greffons de l’application principale

Si vous utilisez la version de développement de l’application, vous avez du constater que certains des greffons ont été retirés de l’application et vivent maintenant leur vie. Nous ne souhaitons laisser que les principaux greffons dans l’application. Un message d’obsolescence vous signale ce fait lors de la migration en 4.1.1. La suppression définitive est prévue pour Typo 4.2.

Documentation

Sprewell, un des contributeurs les plus actifs du canal de discussion #typo@freenode.net a rédigé une importamt documentation orientée utilisateurs. C’est, avec l’intégration de TinyMCE et la refonte progressive de l’administration, un pas de plus vers l’ouverture de Typo au grand public. La balle est maintenant dans le camp des hébergeurs.

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.

Dans le cadre de la refonte de ce blog, je suis obligé de supprimer un des blocs se trouvant dans le footer de celui-ci, mais je n’arrive pas à choisir lequel.

Et comme nous sommes un week-end d’élections, j’ai décidé de donner la parole au peuple aux lecteurs de ce blog, dans une attitude de bonne feignasse qui me caractérise toute web 2.0. C’est donc à vous de me dire qui Marianne James va éliminer entre :

• Les vignettes des photos de mon Flickr.
• Les derniers commentaires, sachant qu’ils disposent de leur propre flux RSS par ailleurs.
• Mes liens del.icio.us, sachant qu’ils pourront très bien revenir dans mon flux RSS, j’en reparlerai un peu plus tard.

Voilà, et comme je n’ai pas eu le temps de développer de greffon “sondage” pour Typo, merci de vous exprimer dans les commentaires.

Le monde du travail – et peut-être plus particulièrement le web – est un environnements ultra concurrentiel dans lequel rapidité, qualité et efficacité sont devenus les maîtres mots. Si un environnement motivant et agréable est bien sûr nécessaire pour trouver ses marques, cela passe surtout par un apprentissage constant afin de ne jamais rester à la traîne. Facile à dire, mais pas forcément à faire, surtout quand on enchaîne les journées de 14 heures, encore plus avec une vie de famille. C’est pour cette raison que je vais tenter de vous donner trois clés fondamentales, simples, et non chronophages à appliquer au quotidien afin de progresser professionnellement.

Si vous passez de temps en temps sur ce blog, vous aurez remarqué le remplacement dans la navigation de l’icône par un lien vers une page s’abonner. Il y a deux raisons à cela.

La première est purement utilitaire : elle me permet de multiplier les méthodes d’abonnement au blog, en y ajoutant l’émail. En remplissant le formulaire idoine, vous pouvez désormais recevoir toutes les mises à jour du site par courrier électronique. Cette nouveauté est une conséquence directe de mon second point.

La seconde raison d’être de cette page est purement didactique. Je me suis rendu compte avec le temps que dans mon métier, les gens connaissaient globalement l’existence du flux RSS, nombre d’entre eux n’en savaient pas la définition. En fait, seule une faible proportion de mes collègues – au sens large du terme – utilisent quotidiennement l’agrégation qui est beaucoup moins rentrée dans les usages que je l’imaginais jusqu’à encore récemment.

Cette nouvelle page me permet donc

• D’expliquer ce qu’est un flux RSS et à quoi sert l’agrégation, là où l’icône seule n’était pas des plus parlante.
• Offrir l’abonnement par email à ceux que le site intéresse, mais qui n’ont pas encore adopté l’agrégation.

En attendant un changement de thème qui devrait voir l’arrivée d’une zone d’abonnement sur l’ensemble des pages du site, entre autres nouveautés.

Après Google, c’est au tour de Yahoo d’accueillir le Barcamp Paris, dont la onzième édition se tiendra le 12 mai prochain, de 14 heures à tard dans la nuit autour du thème de l’identité numérique.

Le onzième Barcamp Paris se tiendra le 12 mai prochain de 14 heures à tard dans la nuit dans les locaux de Yahoo France, 17 rue Guillaume Tell autour du thème très vaste de l’identité numérique.

Les Barcamp sont des séries de non conférences organisées à l’improviste dans lesquelles sont abolies les barrières intervenants / spectateurs. Tous les participants sont conviés à participer afin d’enrichir le dialogue. Il n’y a pas de sujets préparés à l’avance, chacun inscrivant le sujet dont il a envie de parler sur la grille de programme après le début du barcamp, et les intéressés rejoignant la table correspondante.

Je suis intervenu à plusieurs reprises dans les Barcamps parisiens sur le thème des Microformats, et il n’est pas exclu que j’intervienne à nouveau cette fois ci, ayant deux ou trois angles d’attaques pouvant conduire à des discussions intéressantes. L’identité numérique est en effet un sujet brûlant, et concerne :

• L’ubiquité : disposer d’une identité unique quels que soient les services et la plate-forme utilisée (Internet, téléphonie mobile…).
• La confiance : comment valider les informations affichées.
• La sécurité : comment éviter les vols et l’altération d’identité ?
• L’interopérabilité : besoin d’un système unique et largement adopté pour être crédible, mais reposant sur des standards ouverts et régis par une entité indépendante.

Barcamp Paris 11.
Le 12 mai de 14 heures à tard dans la nuit
17 rue Guillaume Tell
75017 Paris.

La première fois que j’ai du organiser le planning d’un projet web, personne ne m’avait jamais dit comment faire. J’ai tenté de faire fonctionner mon bon sens. J’ai pris les différentes étapes du projet en évaluant bon an mal an combien de temps chacune d’entre elles allait prendre. À l’arrivée, je dépassais la date de livraison d’un bon mois, aussi ai-je tenté de compresser les délais comme je pouvais pour tenir dans la fourchette temporelle impartie. Je me suis évidemment planté dans les grandes largeurs. Certes, j’étais fautif, mais pas entièrement. En alignant les taches les unes à la suite des autres, il me manquait clairement une vision d’ensemble du projet qui m’a mené droit dans le mur. À ma décharge, l’entreprise avait vendu un nombre conséquents de jours / homme pour un projet complexe, en fournissant un tiers des ressources nécessaires – et vendues – pour le réaliser. À la fin de ce billet, vous devriez pouvoir établir un planning de projet sensé, la seule condition étant de pouvoir disposer des ressources nécessaires au bon moment.

Un bon planning commence toujours par la fin, et on appelle d’ailleurs cela un rétroplanning. Une fois fixée la date de mise en production du projet, il ne vous reste plus qu’à remonter le temps jusqu’au jour présent. On a étonnamment une bien meilleure vue d’ensemble du planning en remontant le temps, et les délais semblent tout de suite beaucoup plus serrés. Faites vous un rétroplanning relativement général, reprenant les grandes étapes du projet, c’est à dire :

• Mise en production finale.
• Recette du projet (c’est à dire phase de tests).
• Réalisation. À cette étape, n’hésitez pas déjà à diviser les développements en grandes étapes fonctionnelles : front office et back office, par exemple. Vous gagnerez du temps et de la visibilité.
• Conception.

Durant la planification de ces quatre étapes, énumérez dans un coin toutes les taches qu’elles englobent. Même si vous ne les planifiez pas immédiatement, elles vous permettront d’en oublier un peu moins durant la seconde étape de la mise en place de votre planning.

Une fois votre rétroplanning fini, on prends les mêmes, et on recommence, mais dans le sens inverse en partant d’aujourd’hui pour aboutir à la livraison du projet. Si vous avez préparé votre chiffrage correctement, vous devriez avoir affecté des jours aux différentes taches du projet, et la suite devrait donc être facilitée.

Divisez chacune des grandes étapes citées plus haut en unités les plus petites possibles, principalement pour la phase de développement. En effet, faire de petites unités permet de poser des jalons de validation intermédiaires. Si ces derniers sont recommandés dans un projet de courte durée, ils deviennent indispensables pour tout projet un tant soit peu sérieux. Une fois ces unités définies, il ne vous reste qu’à leur attribuer les ressources nécessaires en vous basant sur votre chiffrage.

Dans la pratique, j’utilise généralement une feuille de calcul de ce style :

Étape	Début	Fin	Ressources affectées	Intervenants
Conception	01/01/2007	05/01/2007	15 j/h	Le concepteur chez nous
Développements	08/01/2007	31/01/2007	75 j/h	Les développeurs
…	…	…	…	…

Pour vous aider, vous pouvez vous appuyer sur les quelques trucs suivants, toujours pratiques.

• Pour chacune des étapes de validation par le client, prévoyez toujours au moins une itération pour les projets les plus serrés, deux pour les autres.
• Le client mettra généralement deux à trois fois plus de temps pour les validations que vous ne le feriez vous-même. Intégrez cette donnée dans votre planning, surtout si vous devez traiter avec le service juridique.
• Quand les délais exigés par le client sont vraiment serrés, spécifiez bien que le non respect des dates de validation décalera le planning d’autant, et que ce retard est imputable au seul client. Cela vous évitera de nombreuses nuits blanches, et des pénalités financières aussi.
• N’hésitez pas à donner une heure maximum de validation et à l’inclure dans le contrat pour ne pas être décalé de 24 heures par une autorisation qui n’arrive pas.
• Refusez les projets “impossibles”
• N’oubliez pas les étapes de validation. Elles sont vraiment importantes à toute les étapes du projet.

Une fois terminé ce planning somme toutes relativement général, il est temps pour vous de réaliser le micro planning qui sera remis à vos développeurs. Pour cela, vous allez créer une nouvelle feuille de calcul dans votre tableur préféré.

• En abscisse, détaillez au maximum toutes les étapes fonctionnelles du projet : écran de login, mot de passe perdu, page d’accueil… le tout dans un ordre logique. On ne construit pas une maison en commençant par le toit.
• En ordonnée, toutes les dates affectées au projet, jour par jour.

Il ne vous reste plus qu’à colorier en rose les jours et semaines qui correspondent à ces étapes. Ce la sorte, en arrivant le matin, vos développeurs sauront immédiatement sur quoi ils devront travailler ce jour là. Quant à vous, vous aurez une vue des plus précises sur les éventuels risques de glissements de planning.

Il est 19 heures 30, vous rentrez tranquillement chez vous quand un partenaire vous appelle sur votre portable. Votre mission si vous décidez de l’accepter – avez vous vraiment le choix ? – chiffrer dans l’urgence le tout nouveau projet web ultra stratégique de Megaclient© Inc. Et là, castastrophe, tous vos commerciaux sont intouchables, il vous faut le faire de A à Z. Par où commencer, et où finir, pour être certain de ne rien oublier, mais aussi pour éviter de perdre un marché fructueux en surestimant les coûts ?

Avez-vous bien compris le projet ?

Commencez donc par vous demander si vous avez bien compris les tenants et les aboutissants du projet. Il s’agit là d’objectifs et non de fonctionnalités, celles-ci viennent après. Si l’on vous dit qu’il vous faut réaliser un site pour la banque Root, vous n’êtes pas bien avancé. Si l’on vous parle de site événementiel, vous en savez déjà un peu plus. N’hésitez donc surtout pas à poser des questions à votre interlocuteur : ce n’est pas parce qu’il est dans la mouise avec son projet qu’il doit vous y mettre aussi avec un chiffrage bancal qui vous fera perdre de l’argent. L’avantage, c’est qu’une fois que vous savez où vous allez, vous avez répondu à presque la moitié des questions qui ne manqueront pas de surgir dans la suite de ce billet. Restent cependant les deux plus importantes : quoi, et surtout comment ?

Quel est votre domaine d’intervention ?

À quel stade du projet devrez-vous intervenir ? Votre mission couvrira-t-elle l’ensemble du projet, ou bien un travail a-t-il déjà été effectué en amont ? Partez-vous de zéro où s’agit-il de reprendre une application existante ? Vous ne pouvez pas commencer votre chiffrage si votre rôle n’est pas clairement borné : conception, réalisation, assistance à maîtrise d’ouvrage ? Devez-vous prévoir des réunions avec le client ? Une fois trouvées les réponses à ces questions, vous devriez en savoir assez pour sortir votre tableur favori et commencer à affecter les différents postes qui interviendront durant le projet.

Quelles sont vos libertés technologiques ?

Les choix technologiques auront un impact important sur votre budget, aussi ne les négligez surtout pas. Un site web en PHP et une application en J2EE ne demanderont pas les mêmes ressources ni les mêmes temps de développements. De même, à périmètre fonctionnel égal, le nombre de jours / homme à affecter à votre développement variera s’il vous faut reprendre des CGI en C ou créer une application en Ruby on Rails.

Si vous n’avez pas le choix des technologies employées, et que vous les connaissez peu ou mal, une seule solution, demandez à ceux qui savent. Et c’est là qu’un carnet d’adresses bien rempli est utile : non seulement y puiserez-vous certainement les réponses aux questions que vous vous posez mais encore devriez-vous y dénicher les compétences propres à intervenir sur le projet.

Si vous disposez d’une très grande liberté de choix, n’hésitez pas à vous faire plaisir, après tout, cela n’arrive pas tous les jours. Mais avant de vendre un site web entièrement développé en fortran 77, vérifiez que vous disposez bien des ressources en interne, ou de ressources externes disponibles.

Quel est le périmètre du projet ?

Dans le meilleur des mondes, Megaclient© Inc. vous ferait parvenir un dossier de spécifications fonctionnelles générales, à moins de devoir assurer la conception de l’application. Ce dernier énumère de manière exhaustive l’ensemble des fonctionnalités que devra posséder l’application et leurs interactions. Bien évidemment, les choses ne se passent jamais comme ça, et dans le meilleur des cas recevrez-vous un document d’une quarantaine de pages pompeusement intitulé expression des besoins. Sous ce nom pompeux se cache généralement un cahier des charges pas toujours très bien ficelé, et majoritairement à des années lumières des besoins réels du client. Mais s’il a envie de se faire plaisir et qu’il alloue le budget nécessaire à son caprice, pourquoi le contrarier ? Malheureusement, là non plus ça n’arrivera pas tous les jours, et vous recevrez le plus souvent une liste de fonctionnalités vague sous la forme d’une listes à puce du genre :

• Ça doit faire ça.
• Et puis ça.
• Et ça ce serait pas mal.
• Et si ça faisait le café, ça le ferait bien.
• Sans oublier ça.

Et maintenant, c’est comme avec la Twingo : à vous d’inventer la vie qui va avec.

Et mon chiffrage, il arrive ?

Maintenant que vous vous êtes posé les bonnes questions, vous allez – enfin – pouvoir faire votre chiffrage. Ressortez votre tableur, il va vous être utile.

Commencez par séparer le projet en grandes phases :

1. Conception.
2. Réalisation.
3. Recette.
4. Mise en production.

Conception

La conception se divise généralement en trois phases :

1. Les réunions avec le client.
2. La rédaction des documents de spécifications.
3. La prise en compte des retours du client.

En ce qui concerne les réunions avec le client, j’ai tendance à prévoir une journée et demi deux journées travail par réunion, divisés tels quel :

• Préparation de la réunion + réunion : une demi journée, pour des réunions de 2 à 3 heures.
• Rédaction du compte-rendu de la réunion : variable.
• Mise à jour des documents de conception : variable selon le projet.

En fonction des projets, les postes que j’attribue à cette phase sont généralement :

• Chef de projets.
• Directeur artistique.
• Concepteur fonctionnel.
• Concepteur technique.
• Ergonome.

Il peut également arriver que des profils spécialisés interviennent à ce stade du projet : DBA, architecte…

Réalisation

Pour chiffrer la réalisation, je pars des fonctionnalités attendues que je divises en unités fonctionnelles les plus petites possibles. Pour chacune d’entre elle, j’évalue le temps passé par les postes suivants :

• Développeur web.
• Intégrateur.

Je rajoute ensuite les jours de chef de projet, plus un à deux jours de mise en place et de prise en main de l’environnement de développement et du projet par les intervenants techniques.

La recette

J’ai tendance à diviser la recette en quatre phases :

1. Rédaction des cahiers de recette.
2. Recette interne.
3. Accompagnement du client durant sa recette.
4. Corrections et retours sur recette.

Il est particulièrement difficile de quantifier ce quatrième poste. En effet, s’il est possible de chiffrer le nombre de jours assignés à la correction des hypothétiques bugs de l’application, il est pratiquement impossible de deviner quelles seront les demandes du client après avoir testé l’application.

La mise en production

Il est facile de penser qu’une mise en production revient à déposer un PHPBB sur un compte free. Les exigences des applications d’entreprise sont bien plus importantes, et je n’ai encore jamais vu de mise en production qui ne se heurte pas à l’un ou l’autre obstacle :

• Mauvaise version du langage.
• Problèmes de droits.
• Librairies manquantes.
• Problèmes de chemins d’accès…

Je compte donc généralement une journée de mise en production, et une journée destinée à tester la prod’ à fond. Cette estimation varie évidemment en fonction du projet.

Et maintenant ?

Eh bien maintenant, il ne me reste plus qu’à chiffrer. Pour cela, j’additionne le nombre de jours / homme prévu sur chaque poste : chef de projets, développeur, intégrateur, concepteur… et je multiplie par le tarif journalier de chacun de ces postes, et j’applique les grands principes du chiffrage :

1. Tout se calcule hors taxe.
2. Dans le cadre d’une prestation sur la durée, le récurrent s’impute autant de fois que nécessaire. Pas juste une seule.

Durée de l’opération : une heure, itérations et rédaction du document compris.

Les petits plus qui cassent tout

Certains postes spécifiques font généralement l’objet d’un chiffrage à part tant ils relèvent d’un coeur de métier différent du mien. Même si l’habitude me permet d’évaluer à la louche ce qu’ils vont coûter, je suis cependant régulièrement dans la nuit. Parmi ces postes, on trouve notamment :

• L’hébergement. C’est pour moi le poste le plus facile à évaluer en fonction des besoins : serveur mutualisé ou dédié, nombre de machines, architecture logicielle ou matérielle, plate-forme infogérée ou low cost, bande passante… Le fait d’avoir travaillé dans l’hébergement y est peut-être pour quelque chose.
• Importation / exportation de données. Délicat, principalement si la reprise se fait à partir d’un outil propriétaire. Le devis du spécialiste est nécessaire.
• Direction artistique.
• Film, musique créée à l’occasion. Autant vous dire que pour ce poste là, le chiffrage à la louche est des plus oiseux.

Et vous, comment vous y prenez-vous pour chiffrer vos projets ?