Christophe Le Bot

Encore un acronyme de quatre lettres ! Voici donc CRAP !

Rien de révolutionnaire dans celui-là. Tout est déjà connu depuis bien longtemps, si longtemps même que le web n’existait pas… C’est la revanche du graphiste papier sur le web designer !

Alors que je suis en pleine période des acronymes de quatre lettres (CRUD et UDOD), je découvre ce matin un bon résumé d’ACID sur Le Journal du Net.

J’ajouterais à l’article de Xavier Borderie que ces quatre attributs d’une transaction de données (Atomicity, Consistency, Isolation, Durability) ne se limitent pas aux bases de données. Ils sont utiles dans bien d’autres contextes, comme par exemple la gestion d’un annaire LDAP ou les transactions entre un repository Subversion et ses utilisateurs. Sauf à considérer qu’il s’agit là de bases de données au sens large et théorique…

Par contre, il y a un contexte où ACID mériterait d’être strictement appliqué, c’est celui des transactions entre un serveur et un navigateur web ! Nous en sommes très loin car le socle technique n’a pas été prévu pour cela. Par exemple, on ne peut toujours pas savoir quand un utilisateur quitte un site ou une application web, ce qui est gênant quand l’application web fait des opérations par étapes successives avec confirmation de l’utilisateur pour chacune d’elles. Doit-on annuler les étapes précédentes ? Si oui, sous quel délai ? De plus, laisser une session ouverte sur le serveur représente un risque de sécurité.

On peut simuler la persistance des sessions et des objets par les cookies, mais la fiabilité n’est pas au rendez-vous (sauf en dérivant le navigateur par des extensions particulières, comme des applets Java). On peut faire un semblant d’atomicité en plaçant les pages web dans un buffer avant de les servir (pour éviter une validation d’un formulaire incomplet par exemple). On peut assurer la cohérence en contrôlant rigoureusement les requêtes HTTP. On peut gérer l’isolation par l’utilisation de « sémaphores maison ». Quant à la durabilité, je ne vois pas comment l’obtenir…

Il manque donc un maillon pour simplifier le développement et gérer la robustesse des applications web : si ACID est bien présent entre le serveur web (front office) et les entrepôts de données (SGBD, annuaires, systèmes de fichiers, échanges de données…), son absence entre le navigateur et le serveur web rend le développement et l’exploitation difficiles.

Allez, je me lance ! Ce soir, j’invente un nouveau concept : le UDOD (User documentation oriented design).

Après tout, chaque jour, les acteurs du web inventent de nouveaux « concepts », toujours révolutionnaires, avec leurs centaines de termes et abréviations à connaître par coeur pour rester « in » ! On recherche, on découvre, on apprend, on applique, on oublie et on recommence. C’est tout le charme d’internet ! En regardant de près (ou plutôt de loin si on veut prendre du recul), il y a peu de concepts réellement nouveaux, mais ça fait monter le « buzz » ! Le « web 2.0″ en est une caricature…

« Et UDOD, ça apporte quoi de neuf ? »

Evidemment, après avoir dit tout ce que je pense des « révolutionnaires du web », je vais avoir un peu de mal à vous convaincre d’utiliser UDOD… Mais comme je l’applique avec de bons résultats, je me dis qu’il y aura bien quelques intéressés !

Le principe de UDOD est simple : après avoir fait un brief rapide et fixer des objectifs assez larges pour votre nouvelle application (méthodologie Paper prototyping), vous commencez par écrire la documentation de l’utilisateur débutant (« User guide for beginners »). L’intérêt est de poser une fois pour toute une description claire, synthétique et compréhensible de votre application. On devrait donc y trouver au moins :

• une définition de l’application ;
• une présentation des notions fondamentales ;
• une description des fonctions principales et de leur utilisation ;
• une description de l’architecture et de son interaction avec d’autres sytèmes ;
• des annexes pour les détails techniques ;
• un glossaire ;
• un index.

Une architecture claire, des notions définies

Certes, cela a un coût. La rédaction est longue et doit être faite par un spécialiste. Cependant, on découvre vite l’intérêt de cette méthode :

• La définion de l’application facilite la compréhension des objectifs pour l’équipe de développement.
• Les notions fondamentales sont exhaustives et définies.
• La description des fonctions donnent l’étendue du travail (orienté tâches) de développement et de conception de l’interface.
• La description de l’architecture pose les bases du noyau de l’application.
• Les annexes précisent les contraintes pour les développeurs.
• Le glossaire définit tous les éléments de l’application.
• L’index permet de valider la cohérence des termes utilisés.

Entendons-nous bien, je n’ai pas dit qu’il fallait finir la documentation avant de faire autre chose, mais bien de commencer par elle. Les autres méthodes de conception viendront compléter UDOD sans accroc :

• Design participatif ;
• Méthodes agiles ;
• User task oriented design pour la conception de l’interfaces ;
• UML pour la modélisation de l’application ;
• Object oriented programming et Aspect oriented programming pour le développement du code ;
• Unit tests pour valider chaque brique fonctionnelle définie par UDOD ;
• et j’en passe…

Des utilisateurs impliqués

L’équipe interne a maintenant de quoi travailler sereinement. Mais il y a mieux encore : UDOD implique très vite les futurs utilisateurs de votre application. Ils peuvent la découvrir avant même qu’elle ne soit codée. Et bien sûr y apporter rapidement des remarques, des contraintes, de nouveaux besoins. Dans le cadre d’une application métier, la qualité des échanges est nettement améliorée. On applique au mieux les méthodes de design participatif !

Une documentation de qualité

Au bout du compte, vous aurez optimisé tous les cycles de développement. Et je garde le meilleur pour la fin : vous avez une documentation utilisateur claire et complète au lancement de l’application ! C’est tellement rare…

Cela peut sembler étonnant, mais je constate assez fréquemment l’absence ou la mauvaise implémentation de fonctions basiques et indispensables dans les applications web. Souvent, cette situation vient d’une conception architecturale bâclée (voire absente…) et de l’utilisation extrême et non contrôlée des méthodes agiles (« Ajoute cette fonction maintenant, le client vient de me la demander pour la démo de 14h ! »).

La détection de ces défections peut se faire à différentes étapes du projet :

• pendant la conception de l’architecture ;
• pendant l’écriture du code ;
• pendant la phase de test des briques fonctionnelles ;
• pendant la phase de finalisation de l’application (version alpha ou beta) ;
• pendant l’utilisation du produit en production.

Autant dire qu’une détection précoce sera la bienvenue…

Parmi les oublis classiques, celui de la gestion des données est le plus fréquent. « Ah ben ça alors… Je peux créer un utilisateur, mais pas le supprimer ! » Quand c’est votre client qui le dit, votre réputation en prend un coup ! Pour éviter ce genre de surprise, n’oubliez pas CRUD (Create, Read, Update, Delete) ! Et posez-vous les bonnes questions :

• Create
  Dans quelles circonstances créer la donnée ? Qui peut le faire ? Comment avertir l’utilisateur quand elle est créée automatiquement ? Comment le faire manuellement dans l’interface ? Comment gérer les erreurs de saisie ?
• Read
  Comment récupérer la valeur ? Qui peut la lire ? Doit-on la transformer pour l’afficher ? Comment vérifier que la donnée retournée est bien la bonne ? Que faire si elle n’existe pas ?
• Update
  Qui peut le faire ? Comment avertir l’utilisateur quand elle est créée automatiquement ? Comment le faire manuellement dans l’interface ? Comment gérer les erreurs de saisie ? Quelles sont les répercussions sur les autres données ? Comment vérifier le type et le format de la donnée modifiée ? Que faire si elle n’existe pas ?
• Delete
  Dans quelles circonstances supprimer la donnée ? Qui peut le faire ? Que se passe-t-il quand je supprime la donnée ? Faut-il ajouter, modifier ou supprimer d’autres données ? Que faire si elle n’existe pas ?

Ces questions (et bien d’autres !) doivent bien sûr être posées et résolues pendant la phase de conception de l’architecture car elles définissent le socle fonctionnelle de l’application, sa stabilité, sa robustesse et son évolutivité.

CRUD, CRUD, CRUD…