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

Billet un peu hors sujet, mais ce sont les vacances, donc je m’en absous moi-même.

Plusieurs personnes m’ayant récemment demandé une liste d’ouvrages pour s’initier à la Science Fiction, je commence à en posséder une bibliothèque honorable, je publie la liste en question ici. Peut-être pourra-t-elle sauver la fin des vacances de certains maudits de la météo.

À force de travailler sur des problématique d’utilisabilité sur le web, j’en suis venu à remarquer les initiatives destinées à nous faciliter la vie hors-ligne.

La palme de l’été revient à l’hypermarché Carrefour d’Arcachon, qui a eu l’excellente idée de placer dos à dos les rayons pizza et glaces. Mais surtout, ils ont placé un distributeur de bouteilles de 2 litres de Coca-Cola juste au dessus du congélateur des pizzas. Voilà une excellente initiative qui doit considérablement accélérer les préparatifs de bien des soirées entre geeks, sans nécessairement pousser à la consommation d’un produit qui accompagne de toute façon naturellement une bonne pizza.

Signe des temps de dynamisme et d’innovation technologique, la rentrée nous gratifie depuis 5 ans d’un ou plusieurs nouveaux termes qui se propagent à la vitesse de la lumière de la sphère des innovateurs au monde des early adopters avant de toucher les mainstream media. Un buzzword en somme.

Ces dernières années, nous avions eu :

• 2003 : AJAX.
• 2004 : Blog.
• 2005 : Web 2.0, crowdsourcing.
• 2006 : Buzz, iPhone.

Buzzword de la rentrée 2006, l’iPhone a complètement écrasé l’année 2007, tout juste distancé par Britney Spears ou Paris Hilton dans les domaines généralistes. Maintenant l’objet tant attendu sorti, disséqué et critiqué, il est temps de passer à autre-chose.

Quel sera le buzzword de cette rentrée 2007 ? Je verrais bien quelque-chose tournant autour de l’identité numérique, thématique qui prendra de plus en plus de place dans les mois à venir, entre présence en ligne, identification, authentification et relations de confiance. Et s’il ne devait pas y avoir de buzzword de la rentrée, cela signifierait-il que nous avons quitté une l’ère d’innovations pour entrer dans l’ère de la consolidation ? J’ai déjà ma petite idée sur la question, mais vous, qu’en pensez-vous ?

À mesure que le web gagne en maturité, de nombreuses missions impliquent ou concernent directement la reprise d’une application ou d’un site existant. Qu’il s’agisse d’intégrer des données provenant d’une application tierces dans un nouveau système d’informations, ou simplement de récupérer le contenu de milliers de fichiers HTML, la migration des contenus est une opération souvent dangereuse : perte ou corruption de données ou de fichiers, indisponibilité d’une application critique en production… Heureusement, la reprise ou l’intégration d’un existant peut aussi bien se passer, à la condition de bien s’y préparer et d’avoir toujours en tête ces deux principes fondamentaux des systèmes d’information : intégrité et cohérence.

Quel type de reprise ?

Globalement, vous rencontrerez trois types de reprises :

1. La reprise des contenus d’un site existant.
2. L’intégration des données d’une application existante.
3. La reprise, pour maintenance ou évolution d’un site ou d’une application existante.

La reprise des contenus d’un site existant

Reprendre les contenus d’un site existant peut s’avérer idyllique, quand, par exemple, tous les contenus peuvent être exportés sous la forme d’un flux XML et facilement réintégrés dans le nouveau système d’informations. Mais ne vous leurrez pas, il s’agit d’un cas extrême que vous n’avez (presque) aucune chance de rencontrer. Dans le meilleur des cas, le client vous fournira une extraction SQL ou CSV non documentée, mais attendez-vous à récupérer quelques milliers de pages écrites dans une immonde soupe de balises HTML 2.0 made in Frontpage, sans aucune notion de sémantique.

L’intégration des données d’une application existante

Intégrer les données d’une application existante peut à priori ne pas poser trop de problèmes, pour peu que cette dernière prévoit une quelconque méthode d’exportation dans un format ouvert : HTML, XML, CSV, ou parfois, un peu des trois à la fois. Lors d’une précédente expérience, nous avions du récupérer des données hétérogènes provenant d’une base Lotus Notes :

• Exportation des données système et utilisateur au format texte simple dans des fichiers CSV.
• Exportation des champs contenant du texte enrichi dans des fichiers au format HTML.
• Exportation des fichiers joints et des images dans des répertoires à part.
• Le chemin relatif vers les fichiers externes inclus dans les champs CSV idoines.

J’en vois déjà quelques-uns frémir d’horreur à la lecture de cette liste. Il faut bien comprendre que de nombreuses applications ne permettent pas l’exportation de leurs données vers des formats ouverts, principalement pour deux raisons :

• L’application est très ancienne (certaines gros systèmes encore en activité ont plus de 40 ans), et l’exportation des données sous d’autres formats n’était alors pas rentrée dans les moeurs, pour peu que les formats en question aient existé à l’époque.
• L’éditeur de l’application a volontairement choisi de ne pas permettre l’exportation des données sous quelque format que ce soit, afin d’enchaîner le client, par exemple en les stockant sous un format binaire non documenté. Dans ce cas, trois solutions trois solutions s’offrent à vous : il arrive que l’éditeur accepte, moyennant finances, d’exporter les données sous un format utilisable. Dans le cas contraire, vous devrez requérir à une longue et coûteuse opération d’ingénierie inverse, pour peu que celle-ci s’avère légale ou tolérée dans votre pays de résidence.

Autant dire que nous étions heureux de nous en tirer à si bon compte, malgré la saleté du HTML généré par Lotus Notes qui nécessitait un bon coup de nettoyage.

La reprise d’un site ou d’une application existante

La reprise pour maintenance d’une application ou d’un site existant pourrait faire l’objet d’un billet à part entière, et ce sera le cas tant il y a de choses à dire sur le sujet. Disons, pour faire simple, que les deux principaux obstacles sont technologiques – utilisation de technologies ou de méthode obsolètes – et humaines – absence de personnes capables de reprendre l’application. Ce dernier point a d’ailleurs posé pas mal de problèmes au moment du passage à l’an 2000, et nombreuses sont les grosses sociétés ayant du faire appel à du personnel à la retraite, faut de trouver sur le marché de compétences capables de reprendre des mastodontes développés en COBOL et autres langages antédiluviens.

La reprise est-elle possible ?

Toute proposition commerciale devrait conditionner la reprise d’un existant à une étude de faisabilité. L’étude pourra avoir été faite en préalable à la rédaction de l’appel d’offres ou de l’expression des besoins, ses conclusions ayant alors été incluses dans cette dernière. Dans le cas contraire, on prendra soin d’inclure l’audit dans le budget global du projet, et de placer la reprise de l’existant dans un budget annexe, une fois les conclusions de l’audit rendues.

Les choses ne se passent malheureusement pas toujours aussi bien. Nombreux sont les clients conditionnant l’attribution du contrat à l’acceptation de la reprise de l’existant, et nombreux sont les commerciaux peu scrupuleux acceptant ces clauses inconditionnellement sans en vérifier ni la possibilité technique, ni même la charge réelle sur le budget global. “Moi je fais du chiffre, débrouillez-vous pour le reste”.

Un client m’a un jour demandé ce qui pouvait m’empêcher de reprendre des données provenant d’une application tierce dans son nouveau système d’informations. Une douzaine de réponses me sont immédiatement venues à l’esprit parmi lesquelles “j’ai la flemme”, “je n’en ai pas envie” ou “pour que tu comprennes que tu es technologiquement en mon pouvoir”. Curieusement, ce ne sont pas celles-ci que je lui ai données, me contentant des trois plus évidentes :

• Des problèmes d’interopérabilité : l’éditeur de votre application actuelle n’a pas souhaité permettre d’exporter les données de son application sous un format ouvert, et il n’a pas souhaité me donner la possibilité de le faire moi-même.
• Des problèmes de compatibilité : la structure de données de votre ancienne application n’est pas compatible avec la nouvelle. La récupération des anciennes données nécessiterait trop de modifications sur la nouvelle application pour tenir dans une fourchette budgétaire décente.

Que faire avant la migration

Chacune des étapes préparatoires à une reprise d’existant pourrait faire l’objet d’un article consacré tant il y a à dire sur le sujet. Nous nous contenterons cependant de les passer toutes rapidement en revue, d’autres publications plus exhaustives existant certainement, et l’expérience que vous pourrez acquérir sur le sujet ne pouvant en aucun cas être remplacée par des documents théoriques ou des procédures codifiées, aussi précises soient-ils.

Les étapes à valider avant de lancer la migration sur la nouvelle plate-forme de production sont :

1. Contrôler l’intégrité et la cohérence des données.
2. Préparer les conditions de migration.
3. Lancer un premier test sur un jeu de données restreint.
4. Effectuer la migration en environnement de pré production.
5. Contrôler la cohérence des données importées.

Contrôler l’intégrité et la cohérence des données

Le contrôle de l’intégrité et de la cohérence des données reçues sont deux étapes très différentes aussi bien sur le fond que sur la forme.

Le contrôle d’intégrité permet de vérifier que le jeu de données reçu correspond exactement au jeu de données envoyées par le client : nombre d’enregistrement, données à l’intérieur des enregistrements, nombre et poids des fichiers annexes. On prendra également soin de supprimer l’ensemble des fichiers et répertoires “parasites” ajoutés par certains systèmes d’exploitation qui pourraient interférer avec les scripts d’importation. Une des méthodes permettant de contrôler l’intégrité des fichiers livrés par le client est l’utilisation d’une prise d’emprunte électronique : somme md5 ou signature de l’archive avec la clé PGP du client. La première méthode consiste en un hashage bit à bit de l’archive à contrôler. La seconde fait entrer en jeu des principes de signature électronique, et donc d’authentification. Il en existe d’autres, mais celles-ci sont parmi les plus simples à mettre en oeuvre et les plus répandues.

Côté client, le contrôle d’intégrité consiste en une vérification systématique et obsessionnelle de l’isométrie des données migrées avec les données à migrer, notamment le nombre d’enregistrement ou de fichiers externes, le nombre de champs dans les enregistrements… Il s’agit d’un travail sensiblement semblable à celui que doit effectuer le prestataire à une différence près : en fonction du format d’exportation, il est très difficile, voire impossible de contrôler automatiquement la bonne exportation des données.

Le contrôle de cohérence est lui du domaine fonctionnel et métier. Il s’agit à la fois de vérifier que

1. Le contenu des données exportées est bien le bon, et qu’il se trouve bien à sa place (imaginez si le champs “âge” se retrouvait à la place du champs “poids” dans un catalogue de vêtements pour femmes…)
2. L’ensemble des enregistrement ne brise pas la cohérence du nouveau système d’informations, notamment en termes de contraintes qui auraient pu être ajoutées au schéma de données. Il arrive très (trop) souvent qu’une migration plante parce qu’en principe, selon les réglements et les processus internes, telle données est obligatoire, ou d’un certain type, mais qu’aucun mécanisme ne permet de contrôler sa présence effective ou sa cohérence.

Préparer les conditions de migration

Le jour où vous devrez mettre en place les conditions d’une migration réussie, vous passerez obligatoirement par ces trois étapes, et sans doutes d’autres :

1. Écriture des scripts de migration.
2. Écriture d’un plan de récupération sur erreur.
3. Mise en place de l’environnement de migration.

L’écriture des scripts de migration peut se faire dès le début des développements. En effet, l’étude du schémas des données à importer, qu’il s’agisse de pages HTML statiques provenant d’un site “old school” ou de la base de données d’une autre application et la conception du schémas de données du nouveau système d’informations font tous deux partie de la conception du système d’informations. Il est conseillé de s’y prendre tôt, afin de pouvoir effectuer autant de tests que possible et détecter toutes les erreurs qui pourraient survenir durant la migration avant le grand saut sous le contrôle du client. Outre l’importation des données elles-mêmes, les scripts de migration doivent prévoir le contrôle des données insérées, et effectuer un rapport d’erreurs aussi précis qu’exhaustif.

Si l’écriture d’un plan de récupération sur erreur ne s’impose pas de lui-même lors de l’importation de données sur une base vide, il devient en revanche crucial lors de l’intégration de données sur une application existante, en production, et ce sans interruption de service. Dans la mesure du possible, le plan devra permettre une reprise sur erreur partielle : on isole les enregistrements ayant posé problème, et après analyse, on ne réimporte que ces derniers. Il faudra également envisager une reprise totale, c’est à dire une remise en place du système de données tel qu’il était avant la tentative de migration, aussi bien en termes de structure (ajout de colonnes), que de contenu (suppression des contenus ajoutés, et rollback des identifiants automatiques de colonnes quand ils existent). L’utilisation d’un SGBD transactionnel est évidemment un plus appréciable.

Afin de permettre un contrôle d’erreurs optimal, on aura pris soin de faire des tests exhaustifs sur la migration des données, et notamment :

• Récupération et enregistrement des messages d’erreur de la base de données.
• Contrôle de la présence des données après l’insertion avec les données à insérer.

La mise en place de l’environnement de migration se fait globalement selon 4 trois :

• La mise en place du schémas du système d’information.
• L’insertion des données nécessaires à la cohérence du système d’informations, telles les clés étrangères, qui n’existaient pas forcément sur ce modèle dans le schémas existant.
• L’upload de l’ensemble des fichiers nécessaires à la migration, et un contrôle de leur intégrité.

Lancer un premier test sur un jeu de données restreint

Dans un premier temps, on va lancer les scripts de migration et d’importation sur un jeu de données restreint, quelques dizaines à quelques centaines d’enregistrements choisis au hasard. Cela permettra à la fois de tester les scripts, de contrôler la cohérence des données importées, et de bénéficier d’un jeu de données en grandeur réelle pour les tests internes. Pourquoi ne pas importer l’intégralité des données lors de ces tests ? Entre autres raisons parce que trop de données tuent l’analyse, et que les problèmes dans les scripts et le schémas de données se repèrent plus facilement sur un jeu restreint. Il s’agit avant tout de tester vos développements, pas d’une répétition générale avant la mise en production.

Comment choisir ses données ?

C’est toujours une question délicate. Les données doivent à la fois être sélectionnées au hasard, afin de ne pas biaiser le fonctionnement des scripts d’importation en choisissant des exemples complets, refléter la réalité de l’application en production et permettre tous les scénarios de tests possibles. Il faut donc du hasard, mais un hasard soigneusement circonscrit, donc pas si aléatoire que ça, finalement.

Effectuer la migration sur un environnement de pré production

Si votre projet a été bien vendu, que votre client n’est pas trop radin, et que son hébergeur est un tant soit peu compétent, vous devriez avoir à votre disposition un environnement d’intégration, ou environnement de pré production. Pour ceux qui n’en auraient jamais rencontré, un environnement est une copie parfaitement isométrique de la plate-forme de production sur laquelle la nouvelle application est appelée à tourner.

Quand je parle d’isométrie complète, c’est vraiment complète :

• Version (mineure) du système d’exploitation.
• Version des différents services installés.
• Version des langages installés.
• Version de l’application (sauf dans le cas d’une mise à jour de l’application, évidemment : dans ce cas, la plate-forme de migration est appelée à être parfaitement dupliquée sur la plate-forme de production).
• Données présentes dans la base.
• Matériel présent sur les machines.
• …

Évidemment, on aura soin, dans la limite des correctifs de sécurité, d’installer les mêmes versions des langages et des serveurs de base de données en développement, en intégration et en production. Cela pourra par exemple éviter de chercher 3 semaines des erreurs de timeout dans les requêtes de Symfonny vers une base de données Oracle dès qu’une jointure se présente à l’horizon pour un changement de version mineure de PHP. Toute ressemblance avec des faits existants ou ayant existé serait évidemment fortuit.

J’attire là votre attention sur l’importance de transmettre les numéros de version des outils utilisés en développement à votre hébergeur avant la mise en place de sa plate-forme. Non seulement vous évitez les incompréhensions avec le client parce que “chez moi ça marche”, mais en plus, vous éliminez un tiers des problèmes qui pourraient surgir au moment de la migration.

Lancer la migration

Les changements de masse sont toujours une étape délicate, qu’il s’agisse de modification du schémas d’une base de données, de la mise à jour d’un grand nombre d’enregistrements (opérations de ventilation par exemple), ou de l’intégration des données provenant d’une application tierce. Une simple erreur de mise à jour peut compromettre l’intégrité ou la cohérence de données stratégiques, voire, à moins de fonctionner en mode transactionnel, gravement endommager un système de données.

Dans la mesure du possible, on préférera bloquer l’accès de l’application aux utilisateurs le temps d’effectuer les opérations critiques. Planifiez une opération de maintenance avec votre client, ou avec votre service IT, si possible au moins trois jours à l’avance afin de lui donner le temps de prévenir toutes les personnes susceptibles d’utiliser l’application, à commencer par ses équipes de support. Donnez-lui la date, l’heure de début et l’heure de fin des opérations, ainsi que le fuseau horaire concerné. Choisissez de préférence des horaires durant laquelle l’application sera peu utilisée : aux heures de repas, ou aux heures creuses (3 à 6 heures du matin) de la nuit. Tout dépendra de ce sur quoi vous travaillez : site web grand public, application interne à une entreprise… Enfin, n’oubliez pas de créer une page “en maintenance” qui s’affichera à la place de l’application ou du site, en rappelant la date et les heures de maintenance. C’est toujours mieux qu’une erreur 500 ou un plantage en règles, jamais très bons pour l’image d’un site. Le “Plombier Bloglines” est un modèle du genre.

Malheureusement, pour toutes un tas de raisons, immobiliser l’application n’est pas forcément possible. Il faut donc faire avec. Si vous avez la chance d’avoir des bases jour / nuit, pensez à faire vos migrations sur la base inutilisée avant la rotation, cela permet de conserver une marge d’erreur la plus faible possible. Dans le cas contraire, il ne vous reste plus qu’à prier pour que tout se passe bien.

Et maintenant, que vais-je faire ?

La migration semble s’être déroulée correctement, les logs d’erreur sont vides, et le nombre d’enregistrements en sortie est bien le même que celui passé en entrée. Tout semble donc s’être parfaitement déroulé. Avant de rentrer chez vous, le sourire aux lèvres et le coeur léger, heureux du travail bien fait, utilisez donc un peu l’application histoire de vérifier que tout va effectivement pour le mieux dans le meilleur des mondes possibles. Cela pourra vous éviter quelques déconvenues comme :

• Des problèmes d’encodage sur les données migrées quand les bases source et destination n’utilisent pas le même.
• L’ensemble des pièces jointes d’un trac qui disparaissent pendant la migration d’un hôte vers un autre.
• …

Et si, finalement, tout va vraiment bien, vous pouvez effectivement aller déjeuner.

Dans son article Reviving Anorexic Web Writing publié sur A List Apart et dont je vous recommande chaudement la lecture en entier, Amber Simmons s’intéresse au pied de page, ce parent pauvre, mal aimé, du design web. Elle y dénoncer le peu d’attention qui leur est accordé avant de terminer sur la qualité de l’expérience utilisateur connue avec le “big footer”.

Les pieds de page sont une insulte au visiteur. La grande majorité d’entre eux est totalement inutile : ils contiennent généralement quelques liens en vrac, parfois des mentions légales, ou des informations de contact, mais rien d’autre. Personne ne les lit jamais pour la simple raison qu’il n’y a rien à y lire.

[…]

Un de mes pieds de pages favori est celui du blog d’Emily Gordon, un vrai pied de page d’écrivain. Il contient des informations vraiment intéressantes. Elle y parle d’elle-même, de ce qu’elle écrit et de ce qu’elle a écrit. Elle s’adresse directement à son lecteur. Quand j’arrive sur son pied de page et que je vois tout ce qu’elle y offre, j’ai le sentiment qu’elle s’attendait à ce que je vienne jusque là, et qu’elle y approuve ma visite. J’adore le fait qu’elle ait choisi de m’offrir bien plus d’informations que je n’imaginais à priori en trouver, à un endroit généralement laissé pour mort. Je me sens récompensée chaque fois que je finis de lire son blog, et je trouve que c’est une merveilleuse expérience utilisateur.

Je suis un grand adepte du “big footer” depuis la première fois que je l’ai vu, à l’époque où je servais de cobaye au thème Hemingway, et j’ai tendance à le placer dès que son utilisation semble s’imposer. Contrairement à ce qu’on pourrait croire, il n’est pas réservé aux seuls blogs, puisque le journal Le Monde l’utilise également.

En termes d’usages, le “big footer” introduit deux choses particulièrement intéressantes.

Comme le fait remarquer Amber Simmons, il redonne ses lettres de noblesse au pied de page, en y introduisant, enfin, des informations utiles. Après la lecture de son article, ou de sa page, l’utilisateur ne tombe plus sur un mur de liens qui ne lui seront d’aucune utilité. Je ne veux pas dire par là que ces liens sont inutiles, au contraire, mais plutôt qu’ils ne sont pas utiles à l’utilisateur, à qui est véritablement destiné le site.

Il permet surtout de regrouper en un seul lieu un nombre important d’informations pertinentes, autrefois placées dans le menu avec les éléments de navigation, tout en n’en faisant pas partie. Dans un monde idéal (sic), on trouverait en effet :

• Sur un layout à 2 colonnes : une colonne pour le contenu, et une colonne pour les éléments de navigation, et uniquement de la navigation. À titre d’exemple, la liste des catégories d’un site fait partie des éléments de navigation, pas les derniers commentaires ou les billets les plus populaires.
• Sur un layout à 3 colonnes : une colonne pour la navigation, une colonne pour le contenu et une colonne pour du contenu contextuel au contenu affiché.

Des variantes de ces deux principes existent bien sûr, et ils ne sont pas exhaustifs, évidemment. Ils permettent cependant de comprendre l’intérêt d’un “big footer”, ainsi que la typologie des éléments qu’on peut y trouver.

Et vous, qu’en pensez-vous ? Pour ou contre le big footer sur les sites qui le justifient ?

Je ne sais pas si la tendance est propre aux NTIC, à Paris, ou aux NTIC à Paris, mais ces deux derniers mois passés à naviguer d’entretien en entretien à la recherche du job idéal me laissent avec le sentiment que les entretiens d’embauche subissent aujourd’hui une intéressante et profonde mutation.

À peine rentré d’un week-end des plus agréables dans un endroit paradisiaque, n’ayons pas peur des mots, je repars pour quatre semaines de vacances, quelque-chose d’inimaginable pour moi puisque cela représente le cumul de toutes mes vacances depuis 1998.

Des accès à Internet limités devraient forcer ce site à tourner au ralenti, même si ces quatre semaines devraient également me permettre de terminer la quarantaine de billets en souffrance qui traînent sur mon disque dur depuis des mois. Le mois de septembre devrait aussi voir l’aboutissement d’une refonte ergonomique du site à laquelle je réfléchis depuis plusieurs semaines, mon arrivée dans une nouvelle société…

Alors, pour vous faire patienter, je vous laisse avec quelques photos de mon week-end de rêve, et vous souhaite à tous de très bonnes vacances !

[edit]
Je ne pourrai pas relever mes mails tous les jours, aussi, dans le cas où vous auriez besoin de me joindre en urgence (proposition d’emploi, plan de domination du monde, les deux à la fois…), vous pourriez le faire au +33 6 62 19 1337.

À mesure que le haut débit se démocratise et que les machines disposent de suffisamment de RAM pour faire tourner de grosses quantité de Javascript, nombreuses sont les sociétés décidant de migrer qui une partie de leurs applications métier, qui une partie de leurs applications éditées, sur une plate-forme web. Difficile de ne pas être tentés par le Saint Graal des applications instantanément déployées sur des milliers de postes pour les premières, et des applications impossibles à pirater pour les secondes. Encore faut-il faire les choses correctement : bien que le web ne soit finalement qu’un vecteur de transmission et de présentation des informations, les applications web sont très différente des applications de bureau, et le portage ne manque pas de pièges.

L’envie d’écrire un billet sur le sujet me travaille depuis mon expérience sur le projet Optimia / Niveau 1 en 2003. Optimia était l’outil de gestion des dossiers clients d’EDF/GDF. J’avais rejoint l’équipe de développement au moment où ils passaient d’un outil client lourd développé en Power Builder connecté à une base Sybase vers une plate-forme web en J2EE. Toute la difficulté résidait dans une contrainte de 99% d’isométrie ergonomique et fonctionnelle avec la version précédente. Ces contraintes étaient dictées par des impératifs économiques et pratiques – difficile de former des milliers d’utilisateurs en un temps record – et un contexte politique et social hyper tendu avec l’ouverture des marchés de l’énergie à la concurrence dans lequel les changements devaient être limités au maximum. Incidemment, cela coïncidait avec les premières utilisations sérieuses d’AJAX et un regain d’intérêt de ma part pour le web après des années de dédain.

Ce billet tente de mettre l’accent sur des erreurs à éviter et des points clés du portage. Il ne cherche en aucun cas à être exhaustif, bien qu’il ne soit pas exclu que j’aborde un certain nombre d’autres points dans des articles à venir. Les difficultés envisagées sont d’ordre techniques et humaines :

1. La bande passante.
2. Les habitudes des utilisateurs du web.
3. Les habitudes des utilisateurs d’applications desktop.
4. La résistance au changement.

Tout le monde ne dispose pas d’une bande passante illimitée

Bien qu’en France, le haut débit se soit très largement démocratisé, la majorité de la planète utilise encore de vieux modems 56k, et de très nombreuses entreprises utilisent encore en interne des liaisons RNIS 128k.

Afin de permettre à tous de pouvoir utiliser les applications, tâchez de ne rafraîchir que le minimum d’une page tant qu’il ne s’agit pas de valider des informations. L’AJAX est maintenant une technologie éprouvée, disponible par défaut de manière simple dans la plupart des framework web, et son utilisation à bon escient permet d’éviter bien du trafic inutile.

Cependant, afin de rester accessible au plus grand nombre, n’oubliez pas de développer en progressive enhancement, qui veut que l’on développe des applications fonctionnant de la manière la plus simple possible – c’est à dire sur des navigateurs ne disposant pas de Javascript – avant d’ajouter les améliorations clica convi. Les aveugles et les déficients visuels vous en remercieront.

Dans les esprits, une application web doit se comporter comme un site web

Il y a 3 ans maintenant, j’ai été amené à assurer la formation des futurs utilisateurs d’une application utilisant massivement de l’AJAX afin d’utiliser au minimum une liaison RNIS ridicule et par ailleurs déjà saturée. S’agissant du premier portage d’une application desktop sur un environnement de ce type, le retour des testeurs était très important afin d’assurer le portage d’un grand nombre d’autres applications du même genre. Le retour avait été unanime : quand on valide un formulaire et que la page ne se recharge pas, on n’a pas l’impression que les données ont été effectivement transmises au serveur.

Les utilisateurs s’attendent naturellement à ce qu’une application web agisse comme un site web traditionnel. Cela implique particulièrement que tout changement d’état des données manipulées à l’écran doit passer par un rechargement complet de la page, quand bien mêmes les données seraient-elles envoyées en AJAX. Ce point représentait plus qu’une gène pour les utilisateurs qui cliquaient frénétiquement sur leur souris tout en remplissant fiches de bugs sur fiches de bugs, se plaignant qu’aucune des pages ne marchait.

Afin de pallier ce problème, nous avons du provoquer artificiellement le rechargement de la page à chaque validation de formulaire, quand bien même ce rechargement n’entraînait systématiquement aucun changement sur les données manipulées.

Le clic droit n’est pas une fatalité

Une des problématiques auxquelles vous devrez faire face lors du portage d’une application vers le web portera sur l’utilisation du clic droit sur l’application d’origine. En effet, nombreuses sont les applications qui l’utilisent afin de proposer des actions contextuelles qu’il faudra reproduire d’une manière ou d’une autre.

Il est certes possible de récupérer le clic droit en javascript, et de déclencher une action, par exemple l’affichage d’un petit menu déroulant, mais ce n’est clairement pas une bonne idée :

1. Ce n’est absolument pas accessible.
2. Ce n’est pas “web”.
3. Cela supprime des fonctionnalités utiles du navigateur.

Il est donc nécessaire de repenser l’accès aux fonctionnalités contextuelles apportées par le clic droit à l’aune du médium web. Pour cela, plusieurs méthodes existent. La plus simple est encore de créer une barre d’icônes, toujours au même endroit, donnant accès aux fonctionnalités contextuelles généralement offertes par le clic droit. N’oubliez pas de reproduire les raccourcis clavier de l’application originale en récupérant les séquences de touches. Si le portage ne diffère pas trop de l’originale, ses utilisateurs habituels vous remercieront largement de les avoir conservés.

Une refonte ergonomique n’est pas toujours un mal

J’aime à croire que tout n’est pas immuable en ce bas monde, et la conduite du changement est une chose aussi risquée qu’excitante. Tenter un portage à l’identique de l’existant afin de ne pas dépayser l’utilisateur n’est pas toujours une bonne idée. Bien souvent, la refonte ergonomique de l’existant et la formation des utilisateurs vous coûteront moins cher et vous fera perdre moins de temps que de tenter de plaquer un existant sur un média pour lequel il n’est pas fait. Ajoutez-y les économies réalisées par le gain de productivité engendré par l’optimisation des processus au sein de la nouvelle application, et la nécessité d’une réflexion de fond s’impose d’elle-même. Aussi, avant d’exiger une application 100% isométrique à l’existant, penchez vous sur l’équation suivante :

Coût du portage iso - (coût de la refonte ergonomique + communication sur le changement + formation des utilisateurs - économies après la hausse de productivité due à la refonte étalée sur 3 ans)

Si le résultat vous semble largement supérieur à 0, n’hésitez plus : repartez de zéro, ou presque, et à vos utilisateurs une application neuve, mieux adaptée à l’environnement web, plus belle et plus facilement utilisable. Ils vous en remercieront.

Une refonte de processus non plus d’ailleurs

On oublie trop souvent qu’une refonte ergonomique ne se limite pas à inscrire des interfaces à Relooking Extrême. Les applications web, et plus généralement les applications centralisant les données sur une unique plate-forme déportée – serveur de fichiers, serveur de base de données – et non sur le poste client permettent de dématérialiser et d’optimiser de nombreux processus.

Toute la difficulté réside alors dans une très bonne conduite du changement : évangéliser afin de créer une dynamique de groupe qui entraînera l’adoption des nouveaux processus par l’ensemble des acteurs concernés. Mais ceci est une autre histoire.

Histoire de fêter la version 0.9 de son navigateur social dont j’avais déjà parlé ici, Flock a également remis son site à neuf, et le moins que l’on puisse dire, c’est que le résultat est tout simplement catastrophique.

Pour ceux qui ne le connaîtraient pas, Flock est un navigateur dérivé de Mozilla Firefox, et intégrant directement de nombreux services du web 2.0 : Flickr, Youtube, un outil de blog… Il est disponible sous Mac OS X, Linux et Windows, et compatible avec la très grande majorité des extensions Firefox. Il semble malheureusement que Flock, la société derrière cet excellent outil ait oublié quelques uns des éléments fondamentaux qui ont fait le succès de son prédécesseur : open source, standards du web et accessibilité.

• Une première page toute en Flash, sans qu’un contenu alternatif autre qu’un bête message marketing ne soit proposé. C’est bien dommage pour les technologies open source, mais surtout pour les personnes ne pouvant utiliser ce site (notamment les déficients visuels) : il s’agit tout simplement d’une présentation des principales fonctionnalités du navigateur.
• Une construction en tableaux, pas un poil de sémantique, on se croirait revenu en 2001.
• Des menus déroulants entièrement en javascript, bonjour l’accessibilité. Quand je désactive ce dernier, je n’ai accès qu’aux liens de premier niveau, ce qui signifie que le contenu du menu est ENTIÈREMENT en javascript. Il aurait été beaucoup plus simple, pratique et accessible de mettre les liens dans des listes en display: none, avec un peu de javascript pour les faire apparaître ou disparaître. D’ailleurs, ajouter un espace insécable entre les liens du menu n’aurait pas été du luxe, il est inutilisables sans les images de fond.
• Des balises pas ou mal fermées, invalides… au total pas moins de 42 (sic) erreurs de validation.
• Et même la hCard de la page de contact n’est pas valide…

On ne le répétera jamais assez, ceux qui croient que les standards sont aujourd’hui largement adoptés vivent dans un petit monde idéal loin des véritables réalités du web, même si de nombreux progrès ont été faits depuis 4 ans.

Il est de la responsabilité des éditeurs de navigateurs de promouvoir l’adoption massive des standards, de l’accessibilité, et, dans une certaine mesure, des technologies ouvertes, aussi bien dans leur produit que dans leur communication. Le leitmotiv de la Mobile Initiative du W3C “développer pour un web” devrait aussi pouvoir s’appliquer aux navigateurs traditionnels, et ces derniers devraient être les premiers à montrer l’exemple.

Je suis tombé un peu par hasard ce matin sur un excellent article – un peu ancien – de Scott Manning intitulé If architects had to work like web designers. L’auteur y transpose ce que nous, chefs de projets en contact direct avec le client, subissons au quotidien à l’aune des architectes, dont le travail produit des résultats beaucoup plus “concrets”. Vous en trouverez ci-dessous la traduction augmentée de mes réflexions sur le sujet.

La traduction

Cher architecte,

Je souhaite vous confier la conception et la construction de ma nouvelle maison. Je ne sais pas encore vraiment de quoi j’ai réellement besoin, aussi vous fais-je entièrement confiance pour élaborer ce qui me conviendra le mieux. La maison devra héberger entre 2 et 45 chambres. Établissez donc les plans de telle sorte qu’on puisse facilement en ajouter ou en retrancher une. Les plans que vous me fournirez me permettront de voir de quoi j’ai vraiment besoin. Aussi, pensez à indiquer les impacts budgétaires de chacune des options de telle sorte que je puisse choisir sur ce seul critère.

Entendons-nous : la maison de mes rêves devra me coûter moins cher que mon habitation actuelle. Assurez-vous cependant d’en corriger toutes les imperfections : le plancher de la cuisine vibre quand je la traverse, et les murs sont insuffisamment insonorisés.

Tant que vous y êtes, diminuez au maximum les coûts de maintenance annuelle, quitte à utiliser dans un premier temps des matériaux plus coûteux comme l’aluminium, le vinyle ou des matériaux composites. Sachez que si vous vous décidez de ne pas utiliser d’aluminium vous devrez justifier ce choix de manière plus que convaincante.

Soyez certain d’utiliser des méthodes de conception de pointe et des matériaux d’avant-garde, je veux en effet que cette maison soit un exemple de ce qui se fait de plus innovant dans le métier. N’oubliez cependant pas que la cuisine hébergera – entre autres choses – mon réfrigérateur Gibson de 1952 sans dépareiller du reste de la maison.

La maison devra convenir à ma famille. Dans ce but, prenez contact avec chacun de mes enfants et de mes gendres. Contactez également ma belle-mère : ses visites annuelles lui donnent une opinion très juste et très précise de la manière dont cette maison doit être conçue.

Pesez attentivement tous les éléments afin de prendre la bonne décision, que je me réserve le droit de contester et modifier sans justification ni préavis.

Vous serez gentil de ne pas m’ennuyez avec les détails pour l’instant. Vous devez concevoir les plans généraux de cette maison, ce n’est donc pas encore le moment de choisir la couleur des tapis. Ceci dit, n’oubliez pas que ma femme aime le bleu.

Pas la peine de mobiliser les ressources pour la construction elle-même. Votre priorité absolue est de créer des plans détaillés. Je compte cependant voir la maison sur pieds 48 heures après les avoir validés.

Bien que vous conceviez cette maison à ma seule intention, dites vous bien que je la vendrai tôt ou tard. Elle devra donc plaire au plus grand nombre d’acheteurs potentiels possible.

Avant de terminer les plans, assurez-vous que le consensus se fasse dans le voisinage. Je vous conseille d’aller vois la maison que mes voisins ont fait construire l’an dernier, nous l’aimons beaucoup. Elle présente beaucoup d’agréments que nous souhaitons voir figurer dans notre nouvelle maison, particulièrement la piscine de 25 mètres. Je suis certain qu’une réflexion poussée permettra de l’ajouter à notre nouvelle maison sans modifications budgétaires.

Préparez un jeu de plans complet. Ce n’est pas encore la peine de faire le design définitif, nous les utiliserons uniquement pour négocier les coûts de construction avec d’autres entrepreneurs. Veuillez toutefois noter que vous nous serez redevable de tous les surcoûts liés à des changement de design postérieurs.

Vous devez être particulièrement excité de travailler sur un projet aussi intéressant ! Disposer d’une telle liberté créatrice dans l’utilisation de techniques et de matériaux d’avant-garde ne doit pas arriver tous les jours.

Revenez vers moi avec vos idées et vos plans aussi vite que possible.

PS : ma femme vient juste de me dire qu’elle est en désaccord total avec la majorité des instructions que je viens de vous transmettre. Il est de votre devoir d’architecte de résoudre ce différend. J’ai tenté de le faire par le passé, mais sans parvenir à un quelconque résultats satisfaisant. Si vous ne pouvez pas prendre cette responsabilité, je me verrai dans l’obligation de m’adresser à un autre architecte plus compétent.

PPS : peut-être n’ai-je finalement pas besoin d’une maison, mais d’un camping car. Si c’est le cas, merci de me le dire le plus rapidement possible.

Signé : le client

Le commentaire

Saisissant, n’est-ce pas ? Pour un peu on pourrait presque croire qu’il s’agit d’une situation vécue, et nombreux sont ceux d’entre vous qui se retrouveront dans ce texte.

À mon sens, le problème vient clairement d’une méconnaissance flagrante du travail nécessaire à la réalisation d’un site ou d’une application web de la commande à la livraison. Autant pour une maison, il est possible de s’imaginer la quantité de travaux nécessaires pour telle ou telle amélioration, ne serait-ce que parce que la pierre est “réelle”. À cette réalité vient s’opposer le “virtuel” du web – le travail pour y parvenir est lui, bien réel – donc une fausse idée de rapidité et de facilité, que ce soient dans la réalisation ou dans des “modifications mineures” de dernière minute.

Outre l’opposition entre le concret et le virtuel, on peut attribuer cette méconnaissance du métier à plusieurs autres facteurs :

1. La grande majorité des équipes projet côté client sont composées exclusivement de personnes issues du marketing, ou, dans le cas d’applications web, de spécialistes métier sans aucune connaissance technique, sans pour autant qu’il soit fait appel aux équipes IT – ce qui n’est souvent pas plus mal – ni à une assistance à maîtrise d’ouvrage. Ce point fera d’ailleurs l’objet d’un billet dédié.
   Quelles que soient les raisons de cet ostracisme de la technique – incompatibilités culturelles, guerres de prérogatives en interne – ce dernier est souvent la cause de nombreux problèmes dans un projet web, charge au prestataire de démêler, puis de gérer à l’avantage du projet les querelles politiques de son client.
2. Enfin, le web se remet à peine de la première bulle, et il doit maintenant conquérir, si ce ne sont ses lettres de noblesse, au moins une certaine crédibilité aux yeux des décideurs, face aux applications clients lourds et aux coûteux systèmes d’informations propriétaires qui semblent nettement plus “rassurants” et “crédibles” qu’un site ou une application web, lesquels gardant une réputation de logiciels futiles et jetables.

Dans tous les cas, la méconnaissance est telle qu’une relation de travail, peut-être un futur collaborateur, me confiait récemment qu’un client lui avait demandé combien de “pages” il lui avait vendu. En 2007.