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

La vie d’un projet, de la commande client au déploiement auprès des utilisateurs finaux n’a rien du long fleuve tranquille. Les écueils à un projet “suppositoire” sont nombreux, et, dans des développements au forfait ce sont justement ces difficultés qui justifient le besoin d’un coordinateur qui fasse le lien entre le client et les équipes de production.

Si certains projets peuvent se compliquer pour des raisons techniques, (d’absence) ou de stratégie, il reste cependant possible de discerner à l’avance les signes avant-coureurs de catastrophe. Généralement pas souhaités, ils sont cependant responsables de l’échec cuisant de très nombreux projets, particulièrement en grands comptes.

L’excellent Web Worker Daily, site consacré aux freelances, passe en revue quelques trucs à prendre pour travailler de chez soi dans les meilleures conditions possibles. Ils mettent notamment en garde contre la tentation de travailler tout le temps, de n’importe où, et de ne plus savoir se fixer de limites entre espace de travail et sphère privée.
Ce billet reprend leurs conseils en les adaptant éventuellement à la France, augmenté de mon expérience en télétravail, chose bien pratique en cette période de grèves.

Comme cela avait été annoncé dans la presse, je vais rejoindre d’ici dix jours l’équipe du Groupe Reflect au sein de laquelle j’officierai en tant que project manager [1].

On se demande souvent pourquoi choisir telle société et pas telle autre, et les réponses ne sont pas toujours évidentes à trouver tant les contraintes alimentaires peuvent prendre le pas sur la passion. J’ai heureusement la chance de faire un métier que j’adore, et les raisons qui m’ont poussé à rejoindre Manuel Diaz et son équipe ne manquent pas. Citons entre autres :

À 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.

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.

Quand un développeur parvient à reproduire un bug, il est tout excité car cela signifie qu’il va pouvoir le réparer.

Quand un chef de projets parvient à reproduire un bug, il est ennuyé car cela signifie que ce dernier existe encore.

Je trouve cette réflexion d’Adrian Sutton intéressante, car elle illustre parfaitement la différence de point de vue qui doit s’installer lors du passage de développeur à chef de projets. Il faut passer d’une vision purement binaire ça marche / ça ne marche pas ou je suis à l’heure / je suis à la bourre (avec éventuellement des considérations comme c’est propre / c’est crade / c’est immonde mais ça marche et de toute manière on pouvait difficilement faire plus propre) à une vision globale projet plus nuancée. Cette vision implique une certaine prise de recul, et le regard sur l’application en est forcément changé. Même si j’avoue avoir parfois envie de mettre les mains dans le cambouis quand tel ou tel bug ou fonctionnalité non développée m’empêche de passer mes tests jusqu’au bout.

La préparation de la phase de recette est un des moments clé de la conception du projet en ce qu’il donne l’assurance de vérifier dans les meilleures conditions possibles l’adéquation du produit fini avec les spécifications. Il s’agit aussi de la phase la plus fastidieuse et rébarbative d’un projet, et, si jamais vous rencontrez quelqu’un qui vous prétend le contraire et tente de vous démontrer par tous les moyens possibles que la qualité est un domaine absolument passionnant, engagez le, et ne le laissez jamais repartir : ces gens là sont trop rares pour qu’on les laisse échapper.

Quand rédiger les plans de test ?

Idéalement, vous rédigerez vos plans de tests dès que le client aura validé la conception, histoire de ne pas les changer du tout au tout trois fois par semaine. La tentation à éviter est d’attendre la fin des développements afin de pouvoir effectuer les tests en même temps que vous les rédigez. Comme expliqué plus haut, ils doivent permettre de contrôler l’adéquation du produit fini avec les spécifications, pas du produit fini avec le produit fini et les souvenirs du concepteur.

Pour rédiger vos plans de tests, vous aurez donc soin de fermer toutes les applications en dehors de votre traitement de textes et des spécifications fonctionnelles et techniques de l’application à tester, et c’est tout.

N’oubliez pas que ces plans de tests et les données afférentes vont devoir évoluer avec votre application au fur et à mesure des évolutions. Le cahier de recette est un document vivant qui suit parfaitement le cycle de vie de votre application.

Que mettre dans les plans de tests

Tout, évidemment, et c’est long, très long, même s’il est possible d’automatiser un certain nombre de choses.

Pour être un tant soit peu complet, vous diviserez vos tests en 3 lots :

1. Les tests unitaires.
2. Les tests fonctionnels.
3. Les scénarios d’usage de l’application.

Les tests unitaires.

Les tests unitaires vont principalement vous servir à vérifier que les inputs sont bien enregistrés en base et ressortis comme ils doivent l’être. Ce n’est pas à vous de les écrire, mais à vos équipes au fur et à mesure du développement. L’idéal est d’utiliser une méthode de développement dirigée par les tests :

1. Le développeur rédige les tests.
2. Il développe son module.
3. Il lance les tests, si ça marche, il passe à la suite.

Ces tests sont terriblement longs et fastidieux à réaliser, et c’est pour cette raison que vous devrez immédiatement les automatiser. Bien que coûteuse, l’automatisation se justifie d’elle-même par le temps gagné ensuite et l’absence d’erreur due à l’interface chaise-clavier en charge d’effectuer les tests. En fonction du langage et du framework utilisés, vous aurez à votre disposition tout un tas d’outils pour ce faire : PHPUnit, JUnit, rails::test… les solutions ne manquent pas.

Les tests fonctionnels

Plus complexes que les tests unitaires, ils ont pour but de vérifier la cohérence fonctionnelle de l’application sur de très courtes séquences en fonction des spécifications fonctionnelles de l’application.

Exemple : selon les spécifications, si l’utilisateur rentre un identifiant ou un mot de passe erroné, il est renvoyé sur l’écran d’authentification et un message d’erreur est affiché. Le test consistera donc à contrôler que c’est effectivement le cas, et que le bon message est affiché à l’écran.

Là aussi, il s’agit d’une partie très longue, et pas très rigolote ni à écrire ni à effectuer. C’est un travail de fourmi titanesque et rébarbatif qui nécessite de recommencer cent fois la même chose afin de tester tous les cas possibles, sans pour autant avancer dans l’utilisation de l’application. Mais rassurez-vous, là aussi il et possible de les automatiser, au moins en partie.

Les scénarios d’usage de l’application

Les scénarios d’usage ont ceci d’intéressant qu’ils permettent de tester le produit fini dans des conditions réelles ou quasi réelles. À travers des scénarios représentant l’utilisation quotidienne de l’application, ils permettront de :

• Vérifier que l’application fait bien ce qu’elle a à faire.
• Détecter les erreurs de conception afin de pouvoir les corriger par la suite.
• Corriger toutes les erreurs typographiques, ou de nomenclature qui auraient pu être oubliées pendant la réalisation.

Il est possible d’automatiser cette phase également, mais je ne le recommanderais pas. Au delà d’une étude purement théorique de l’enchaînement des écrans sur le papier, ce sont en effet ces scénarios qui vont permettre de tester l’utilisabilité de l’application, et constater les difficultés de prise en main que pourront rencontrer les utilisateurs finaux amenés à participer aux tests.

Qui doit passer les tests ?

En ce qui concerne les tests unitaires, c’est évidemment le développeur qui doit les passer chaque fois qu’il effectue une modification de son application. Passer les tests de parties qui n’ont pas été impactées permet de détecter les régressions sur l’application ou les effets de bord imprévus. Si des parties plus anciennes sont touchées, il faut évidemment modifier les tests en conséquence.

En fonction de l’ampleur du projet et de la durée de la recette avec le client, vous pourrez faire passer les tests fonctionnels à vos équipes internes et au client, afin de valider tous les points et enchaînements dans les détails. Même si on peut raisonnablement imaginer que le client va méticuleusement vérifier l’ensemble de ces points – et on a parfois de bonnes surprises – lui fournir les scénarios de tests fonctionnels, que ceux-ci soient automatisés ou non, assure une base de connaissance que l’on peut espérer exhaustive.

Enfin, les scénarios d’usage sont à faire passer aussi bien en recette interne qu’avec le client. Il y a d’ailleurs des chances pour qu’il se cantonne uniquement à ces derniers, donc n’hésitez pas à les détailler au maximum.
Si vous en avez l’occasion, accompagnez les utilisateurs du client dans cette phase : c’est un excellent terrain d’expérimentation de l’utilisabilité de l’application sur ses destinataires quotidiens.

Comment rédiger ses plans de tests ?

J’imagine que chacun a ses propres plans de tests, personnellement, je fais comme ça :

Chacun de mes plans de tests – tests fonctionnels et scénarios d’usage – est rassemblé sous la forme de deux classeurs OpenOffice.org, et je place un scénario, ou ensemble de scénarios par feuille. La page est en mode “paysage” et comporte 5 cases :

1. Numéro d’étape.
2. Description de l’étape : quelques mots qui me permettent de savoir vers quoi je tends.
3. Actions : l’ensemble des actions à effectuer.
4. Résultat attendu : ce que je dois obtenir à cette étape du scénario.
5. Résultat obtenu : OK ou KO.

Je mets une étape par ligne, chaque étape correspondant à une fonctionnalité ou description de résultat à valider. Ensuite, ça marche ou ça ne marche pas, et l’utilisateur coche OK ou KO et remplit le rapport de bugs. On rentre maintenant dans la phase corrective, mais ceci est une autre histoire©.

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 ?

Tout projet un tant soit peu sérieux qui se respecte tombe un jour ou un autre sur le bug stupide, ultra bloquant dans certaines circonstances improbables mais fortement susceptibles de se produire par la faute de l’interface chaise / clavier, et tout simplement impossible à corriger. Et qu’il s’agisse de Trac, Bugzilla ou toute autre solution maison, tout projet quelque peu conséquent utilise un outil de rapport de bugs permettant d’en suivre le cycle de vie de l’apparition à la fermeture, et, le cas échéant, de générer de jolis rapports de résolution de bugs à destination du client qui voit ainsi la fiabilité de son application s’accroître avec le temps.

Il y a quatre ans de cela, je travaillais en tant que prestataire sur le logiciel de gestion clientèle de notre principal fournisseur d’énergie. Il s’agissait d’une gigantesque usine à gaz en J2EE dont la moindre page mettait bien 4 ou 5 bonnes secondes à s’afficher. Le changement de valeur d’un menu déroulant permettait de rafraîchir le contenu d’une de ces pages, provoquant la fameuse latence sus citée.

Un jour, j’eus la fâcheuse idée de sélectionner le menu déroulant en question, et de donner un grand coup de roulette sur ma souris. Résultat : plantage pur et simple du serveur d’application Weblogic, et obligés de redémarrer le serveur Sun – une bête de course – sur lequel était hébergé l’application. Plein de zèle, je remplissais donc un rapport de bugs détaillé et circonstancié, niveaus de criticité et d’urgence maximums. Une seule solution pour résoudre ce bug : intercepter ou désactiver la molette de la souris depuis Internet Explorer.

Retour de la fiche une petite heure plus tard au statut “clos rejeté”, avec pour raison de la clôture les postes de travail du client sont équipés de souris à 2 boutons sans molettes, bug inapplicable en grandeur réelle.

Classe, j’te dis classe