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

Combien de fois ai-je vu des étudiants en stage de fin de cursus me déclarer “je veux être chef” avant même d’obtenir leur diplôme ? Et chef de quoi, d’abord ? Chef de projets, avant même sa première confrontation à un vrai projet dans le monde réel – comprendre celui de l’entreprise. Permettez moi de sourire : lors de mon passage à EDF, j’ai vu des centraliens pisser du Java sans rechigner 10 heures par jour, avant de pouvoir enfin obtenir le statut tant convoité.

On tient pourtant là un des (nombreux) paradoxes de bien des informaticiens :

Jeunes développeurs, ils craignent de le rester toute leur vie et n’ont rien de plus pressé que de quitter ce statut pour rejoindre le coté obscur de la force, peuplé de tableaux Excel, de présentations Powerpoint et de plateaux repas froids apportés par un traiteur en plein milieu d’une réunion marathon.

Chefs de projets, leur première inquiétude est de perdre pied sur le plan technique, et de ne plus pouvoir suivre ce que réalisent les développeurs placés sous leur responsabilité, voire d’effectuer des choix cohérents : CGI en C ou framework en PHP5 ? J2EE ou Ruby on Rails ?

On ne peut donner tort aux premiers : dans le monde impitoyable des sociétés de services, un développeur trop expérimenté coûte bien plus cher que ce que le marché accepte de le payer, ou alors c’est qu’il il fait du COBOL et maintient des applications plus vieilles que moi.

On peut donner pareillement raison aux seconds sur lesquels plane l’ombre de ces chefs de projets ou DSI de 55 ans, confortablement installés dans leur fauteuil en attendant la retraite, incapables de prendre une décision sensée puisqu’aux antipodes de la réalité, mais refusant de se remettre en question au nom du sacro saint principe de Dilbert qu’on ne doit pas nommer mais qu’on ne se gène pas pour appliquer au jour le jour. Ceux qui pensent que j’exagère manquent probablement encore d’expérience dans les méandres des grands groupes de notre beau pays.

Aux premiers, j’aurais envie de dire “patience” : vous apprenez la gestion de projets à l’école, et c’est très bien, mais avant de réclamer des responsabilités, souvenez-vous de ces deux proverbes :

La pratique n’est rien d’autre que la mise en application de la théorie… du moins en théorie.

et :

C’est au pied du mur qu’on voit le mieux le mur.

Quand aux seconds, je ne saurais leur conseiller meilleure alternative aux coûteuses formations dispensées par des instituts renommés que l’investissement au titre de vos loisirs dans un projet open source. Pas forcément à grosse dose, chacun selon ses possibilités mais vous n’en tirerez que des bénéfices :

• La dynamique de groupe de tels projets vous encouragera à participer.
• C’est une très bonne carte de visite pour le jour où un client fera une recherche sur votre nom sur Google.
• Le monde de l’open source est généralement très au fait des derniers changements technologiques auxquels vous risquez un jour d’être confronté.
• Vous nouez de nombreux contacts à l’international

En un mot : vous continuez à apprendre tout en vous amusant et vous rendant utile.

Je démarre aujourd’hui une série d’articles sur l’accompagnement de projets dans l’univers des technologies de l’information. Je prévois d’en écrire… un certain nombre, probablement jusqu’à ce que je ne trouve plus rien d’intéressant à dire sur le sujet, ce qui devrait prendre un moment. Le but de ces billets pour lesquels j’ajoute une catégorie dédiée est de permettre aux chefs de projets – ou à ceux qui souhaitent le devenir – d’affronter des situations trop fréquentes pour ne pas être abordées comme des cas d’école. Les domaines couverts devraient aller de l’appréhension de l’équipe client à la gestion des canards boiteux en passant par la cohabitation de plusieurs équipes venues de sociétés différentes sur un même projet.

La première impression étant souvent la bonne, dit-on, mieux vaut réussir son entrée, sous peine d’hypothéquer dès le départ une relation qui s’avérait pourtant prometteuse. Il en va de même avec la conduite de projet : du déroulement de la première réunion avec le client risque fort de dépendre la suite des opérations. Les mauvais départs proviennent souvent d’une méfiance mutuelle à la rencontre de deux mondes généralement à des années lumière l’un de l’autre : “le leur”, univers métier régi par des contraintes aux antipodes de nos habitudes et de préoccupations quotidiennes, et “le notre”, marqué par ce travers récurrent chez les informaticiens qui veut que celui qui contrôle les technologies de l’information contrôle le monde et se doit de garder ce contrôle en laissant les autres dans un état d’infériorité. Sophie Januel appelle syndrome du Médecin malgré lui cette pratique qui se traduit le plus souvent par l’utilisation ad nauseam et pas toujours à bon escient de vocabulaire technique volontairement abscons et bourré d’anglicismes barbares de laquelle les gens du sérail semblent tirer une certaine légitimité. Bien que l’information fasse partie des ressources fondamentales du vingt-et-unième siècle, maintenir volontairement le client dans l’obscurantisme le plus complet serait une erreur fondamentale face à un marché très compétitif sur lequel le relationnel joue une part de plus en plus importante, nous menant à notre premier challenge : oublier l’axiome peur et ignorance, ignorance et peur, afin de rassurer le client.

Allez toujours au pas du plus faible

Il existe autant de clients que de projets, et si certains traînent une longue expérience de la mise en place de solutions liées aux NTIC au point de savoir parfaitement où aller et comment y aller, d’autres comprennent simplement l’existence d’un besoin, parfois flou, mais ignorent tout du cheminement, du temps et des coûts nécessaires à sa définition, puis sa satisfaction. Les projets les plus complexes voient même une multiplication exponentielle des intervenants, couvrant tout l’éventail du possible, d’un extrême à l’autre, et devant avancer au même rythme en faisant fi des différences technologiques et des querelles politiques. Et c’est là que les choses se gâtent.

Dès la première réunion, appréhendez le degré de compréhension du projet de chacun de vos interlocuteurs afin de vous mettre tout de suite au pas du plus faible. Cela pourrait bien pour éviter de vous réveiller un matin avec une sacré gueule de bois. Cet exercice particulièrement difficile m’avait été expliqué par une professeur de danse à la fin des années 90, et j’avais tenté pas toujours avec succès de l’intégrer à mes formations. Il s’agissait de faire avancer le cours – ou le projet dans notre cas – à un rythme raisonnable en ramenant les plus faibles à un niveau de compréhension globale du projet suffisante tout en ne ralentissant pas trop les plus rapides à comprendre.

Cette démarche aura trois impacts importants :

1. Vous assurez la cohésion de l’équipe client en intégrant vraiment les plus faibles au projet (et ils vous ouvrent parfois des portes bien utiles).
2. Vous ne donnez pas aux plus expérimentés l’impression de perdre leur temps.
3. Même si vous avancez un peu moins vite que vous ne pourriez idéalement le faire, vous ne prenez pas de retard sur le planning.

Concrètement, cela passe par une phase de définition de termes qui peuvent vous sembler naturels : le directeur de publication d’un éditeur de bandes dessinées n’est pas sensé savoir ce qu’est un serveur, ni même une base de données. Vous devrez aussi décrire des processus dont les étapes intermédiaires vous semblent aller d’elles-mêmes : la directrice marketing d’un fabriquant de shampooings ne sait pas forcément comment des pages dynamiques sont générées à partir des données stockées dans une base de données avant d’être mises en cache pour pouvoir resservir sans pour autant devoir être regnénérées à chaque visite…

En un mot, le niveau technique du client est une contrainte projet comme une autre, pouvant avoir un important impact budgétaire, et qu’on a trop souvent tendance à oublier.

Laissez venir à moi les petits clients

Celui qui débarque chez un client comme un empereur romain en pays conquis, en y imposant sa langue, ses us et ses coutumes n’a visiblement rien compris à la notion de relation au client. Vous êtes là pour offrir un service, en l’occurrence accompagner une société ou une association afin de lui permettre de mener un projet à bien, et non pour vider ses caisses. Un client qui ne se sent pas considéré finit par partir. L’idée me parait simple, mais on me souffle dans l’oreillette que de nombreux éditeurs de logiciels ne semblent pas l’avoir comprise.

Au travers des réunions de définition et de conception, intéressez vous à votre client, faites lui parler de sa manière de travailler, de ses attentes, des processus internes. Tout ceci risque d’avoir un impact réel sur le projet à venir, que ce au niveau fonctionnel ou ergonomique : vous aurez beau livrer un parfait cas d’école, s’il ne correspond pas à la réalité, personne ne l’utilisera. Vous devriez en plus rapidement comprendre les problématiques résolues par la mise en place de votre oeuvre, et surtout ses implications politiques pas toujours évidentes à première vue. En appliquant cette démarche, comprendre l’environnement du client, vous y gagnez en terme de connaissances métier tout en le faisant passer d’une position attentiste ou réceptive à une attitude participative.

Retenez bien que vous avez plus à apprendre du client que lui de vous. Il pourra utiliser votre produit au quotidien sans en connaître les rouages internes, tandis que vous n’arriverez nulle part sans lui.

Recueillir, formaliser, reformuler

Une grande partie de votre travail consistera souvent à recueillir, formaliser, puis réaliser un besoin émis de manière plus ou moins claire par un client qui ne sait pas toujours de quoi il a vraiment besoin, tout en évitant les écueils de l’application surestimée (autrement appelée usine à gaz), ou sous-estimée (donc inadaptée au besoin réel).

Votre tâche ne s’arrête pas là, et outre la documentation très formelle que vous devrez fournir (documents de conception le cas échéant, suivis de projets…), vous devrez de nouveau formuler ce que vous avez formalisé dans un langage adapté à votre interlocuteur. Il ne s’agit pas de lui redire ce qu’il vous à dit mais de lui faire comprendre où vous en êtes arrivé. Une fois de plus, cette démarche n’a rien de gratuit, elle vise à deux choses :

1. Maintenir le client à flot dans le projet et le rendre plus efficace à accomplir ses tâches.
2. Faire comprendre au client pourquoi telle ou telle partie qui lui semble simplissime prend en fait trois mois à réaliser.

Pour cela, vous disposez du début de chaque réunion durant lequel vous validerez avec le client ce qui a été décidé ou réalisé la semaine précédente. Vous pourrez aussi revenir sur les points de la réunion précédente qui pourraient rester obscurs.

“Non” n’est pas une réponse suffisante

Il existe grosso modo trois manières différentes de dire “non” à un client quand sa demande risque de trop lourdement grever le projet, deux mauvaises et une bonne.

La première consiste à dire “non”, et s’il demande des précisions à lui rétorquer que “c’est très compliqué”. Face à un client faible et peu sûr de lui, ça peut marcher. Jusqu’à ce que quelqu’un de confiance lui démontre le contraire, bien entendu, et là, les choses risquent fort de se gâter franchement.

La seconde consiste à expliquer que vous aimeriez bien, mais que cela coûterait beaucoup trop cher ou prendrait beaucoup trop de temps pour être réalisable dans des délais raisonnables. Veillez à donner un délai ou un coût à la fois suffisamment et raisonnablement élevé. Dans un cas, vous risquez de devoir développer quelque chose de vraiment infaisable dans des délais ridicules pour peu que le client tienne vraiment à son idée. Dans l’autre, vous risquez tout simplement de passer pour un incompétent et un voleur.

La troisième consiste à vous armer de patience afin d’expliquer au client avec ses mots à lui la raison pour laquelle ce n’est pas faisable. Le mieux pour lui faire oublier sa lubie est encore de lui donner les armes pour comprendre en quoi elle est déraisonnable. Et si il y tient vraiment, et qu’il peut y mettre les moyens, pourquoi ne lui feriez vous pas ce plaisir, après tout, il en a tellement envie !

Planifiez

Fournissez des plannings le plus à l’avance possible pour chacune des grandes phases du projet, quitte à les réviser à mesure que vous avancez dans le temps. Et surtout, détaillez tout point par point. Ce qui peut vous sembler évident ne l’est pas forcément pour tout le monde.

Planifiez notamment les réunions en y détaillant l’ordre du jour prévisionnel. J’utilise toujours le même modèle :

• Intitulé de la réunion.
• Date prévisionnelle.
• Récapitulatif des points abordés / livrables / taches actées lors de la réunion précédents (en dresser la liste).
• Premier point à aborder
  • Sous point 1…
  • Sous point 2…
• …
• Liste des livrables et des tâches à accomplir d’ici à la réunion suivante.

Cela peut sembler fastidieux, et pourtant…

• Vous êtes sensés avoir jeté la même chose sur un coin de cahier, de TODO ou de fichier Excel.
• Le client est rassuré car il sait où il va, et vous aussi.

Gardez toujours une trace écrite

Après chaque réunion, envoyez un compte rendu d’une à deux pages à votre client. Pas tant pour l’amour de la paperasse ou pour la postérité que pour lui donner une occasion de revenir sur ce qui s’est dit, et éventuellement comprendre, sans qu’il ait besoin de s’abaisser à vous le demander. Sauf cas exceptionnel de réunion débat un peu houleuse ou de demandes précises de fonctionnalités de la part d’un nombre important d’intervenants, il n’est pas toujours nécessaire de conserver pieusement ce que chacun a dit, et mon modèle de compte rendu ressemble à s’y méprendre à mon modèle de planning.

• Intitulé de la réunion.
• Date de la réunion.
• Intervenants projet.
• Intervenants clients.
• Récapitulatif des points abordés / livrables / taches actées lors de la réunion précédents (en dresser la liste).
• Premier point abordé
  • Sous point 1…
  • Sous point 2…
• …
• Liste des livrables et des tâches à accomplir d’ici à la réunion suivante.

SBAM !

SBAM est un acronyme bien connu des hôtesses de caisses et des démarcheurs à domicile, souvent un peu moins des préposés aux guichets des services publics – exception faite du préposé à l’accueil des ASSEDIC de Villejuif, super sympa. SBAM signifie tout simplement Sourire Bonjour Au revoir Merci.

• Sourire tout au long de la réunion, sauf quand devenir sérieux, voir contrit est de mise.
• Bonjour à chacun des intervenants, personnellement. Serrez la main de tout le monde, jamais de bise trop familière.
• Au revoir à chacun aussi.
• Merci à chacun de vos interlocuteurs, pour leur attention et le temps qu’ils vous consacrent.

Une attitude polie est accueillante – sans tomber dans la basse flagornerie – est non seulement une manière de rassurer le client qu’une simple question de savoir vivre, donc la moindre des choses.

Histoire de me changer un peu les idées et de consacrer un peu de temps à mon autre grande passion – la photographie numérique – je me suis offert Photoshop pour les photographes, de Cyril Bruneau et Bernard Richebé aux éditions Eyrolles. Pour la modique somme de 19 euros 90, cet ouvrage présenté sous la forme d’un cahier d’exercices remplacera allègrement des dizaines de didacticiels trouvés ici et là sur la toile en concentrant tout ce dont l’amateur aura besoin pour assurer une post production décente à ses oeuvres.

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.

Le mois de novembre va être particulièrement chargé en termes de rencontres consacrées au web et aux nouvelles technologies, principalement durant les quinze prochains jours. Si vous vous trouvez à Paris, je serai ravi de vous rencontrer à l’occasion des événements suivants :

• À l’apéro organisé en marge du forum PHP, le 9 novembre à partir de 20 heures au pub Kitty O’Sheas, 10 rue des Capucines, 75002 Paris.
• Au septième BarCamp Paris, le 11 novembre de 14 heures à 20 heures, 38 avenue de l’Opéra 75002 Paris, dans les locaux de Google. J’y présenterai les Microformats à travers un cas d’usage précis, bien que n’ayant pas encore décidé lequel.
• Au séminaire du W3C sur le web mobile, le 16 novembre de 9 heures à 13 heures 30 à l’Entrepot, 7-9 rue Francis de Pressensé, 75014 Paris.
• Aux rencontres Paris on Rails le 17 novembre de 9 heures à 18 heures à la Tour Descartes à la Défense.

Si avec tout ça, vous parvenez encore à m’éviter, c’est clairement que vous ne voulez pas me voir.

[edit]
À l’occasion du BarCamp 7, je parlerai à priori de l’utilisation des Microformats et de la publication des données personnelles dans le cadre de l’optimisation de l’efficacité des réseaux sociaux. On dirait un sujet de thèse, ça pète hein ?

Plus sérieusement, pour ceux que ça intéresse et qui ne pourraient pas venir, je mettrai la présentation en ligne… si je trouve le temps de la faire.

Les gens de Macromates sont de petits rigolos, et ils ont décidé de fêter halloween à leur manière.

Si vous installez la dernière mise à jour automatique, et que vous choisissez d’ouvrir un répertoire, l’habituel écran blanc est remplacé par un écran noir et une jolie toile d’araignée.

Sur ce, je me remets au boulot, j’ai un projet à boucler moi.

[edit]

En fait il semble qu’ils aient carrément mis en place un thème halloween… z’ont vraiment que ça à faire.

En testant la dernière nightly build de Flock, je me suis rendu compte que celui-ci ne supportait plus les versions de SSL inférieures à 3. Je trouve cela particulièrement stupide quand on voit le nombre de sites utilisant de vieux certificats SSL – comme des hébergeurs professionnels, d’autant que ceci concerne aussi les versions 2 et 3 de Firefox.

Le ticket 236933 ouvert chez Mozilla et intitulé Disable SSL2 and other weak ciphers explique les raisons de ce retrait :

Heya,

I would suggest to change the default security-settings … I have disabled the following myself:

SSLv2, all ciphers lower than 128 bit. And it would be even better yo disable md5 and only allow the others like sha-1, …

SSLv2 isn’t secure anymore since some time. SSLv3 and TLS are the only “secure” once to use these days as far as I know. It’s good mozilla includes them “MAYBE” for compatibility, but they shouldn’t be enabled as defaults …

I wouldn’t advise people who use their computer for internet-banking to enable SSLV2, … Ofcourse there are maybe easier ways to break get the necessary info, but disabling the things I mentionned above would help.

En cas de besoin pressant, réactiver SSL V2 reste toutefois possible :

Dans la barre d’adresse, tapez : about:config puis entree
Filtrez sur security.enable_ssl2
Mettez la valeur à true

Je ne sais évidemment pas ce qui est le plus stupide : toujours utiliser une vieille version pas sûre de SSL ou en désactiver et cacher le support. La discussion à ce sujet dans le bug sur le trop faible nombre de sites utilisant SSL V2 ne m’a pas vraiment convaincu. Désactiver le support des anciennes versions de SSL par défaut, en permettre la réactivation en cas de besoin d’une manière plus simple qu’en allant farfouiller dans le about:config, par exemple dans préférences -> avancé -> chiffrement comme c’était le cas autrefois, en l’accompagnant au besoin d’un message prévenant l’utilisateur des risques encourus m’aurait semblé beaucoup plus sensé.

Merci à Jeremy de #flock@irc.flock.com pour son aide.

Les liens hypertextes sont au coeur du web. Sans eux, rien n’existerait, et nous avons pourtant tendance à les négliger. Bien employés, ils ajoutent de la valeur aux contenus publiés ; bâclés, ils peuvent aller jusqu’à leur retirer tout intérêt. Raison de plus pour s’y intéresser et en prendre grand soin.

Combien de fois êtes vous passés à côté de documents passionnants pour cause de liens invisibles, introuvables, incompréhensibles, illisibles ou inaccessibles par bête négligence ? Ce genre de choses ne doit plus arriver, et ce billet se propose justement de vous aider à les éviter en passant en revue les erreurs les plus fréquemment rencontrées et les optimisations trop souvent méconnues. Parce qu’il n’y a que sous UNIX que les liens sont symboliques.

Malgré un emploi du temps de ministre cumulant plusieurs portefeuilles tout en honorant avec un rare zèle l’ensemble de ses mandats locaux, et des yeux à faire pâlir un lapins albinos myxomateux pour cause de fatigue excessive, j’ai tout de même pu me rendre à la grande messe de lancement de Firefox 2 organisée par la fondation Mozilla et le conseil régional d’Île de France.

J’ai pris beaucoup de plaisir à revoir des gens que je n’avais pas croisé depuis parfois plus cinq ans et l’abandon de mes activités militantes actives en faveur du logiciel libre ; ce genre de soirées détendues est le lieu idéal pour (re)nouer des contacts souvent très enrichissants. Enfin, j’ai pu voir une certaine personne avec laquelle je jouais à cache cache depuis un moment, et que je regrette de ne pas avoir rencontrée plus tôt.

En dehors de faire monter leur audience de manière un peu simpliste, je ne vois pas très bien l’intérêt qu’à eu Clubic à annoncer la mise à disposition de Firefox 2.0 la veille de la sortie officielle. D’autant que l’on trouve quelques incohérences majeures sur leur site, qui me font vraiment douter de la véracité de leurs dires.

Pour un téléchargement de quelque 5,4 Mo, cette nouvelle mouture vous permettra de découvrir gratuitement les innovations apportées à Firefox.