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

En termes de planification, la maintenance évolutive d’un projet web est toujours la plus délicate à mettre en place. D’abord parce qu’elle ne participe pas du cycle de développement normal de ce dernier, mais de son cycle d’exploitation, elle risque donc interférer avec celui-ci. Ensuite parce qu’elle fait souvent participer de nombreux intervenants de culture différente, aux intérêts parfois divergents au sein d’une même structure. Enfin parce qu’elle répond souvent à des impératifs extérieurs qui la rendent difficile, sinon impossible à planifier.

Après confier la maintenance de ses projets web et Les cycles de maintenance collective, ce troisième volet de notre série sur la mise maintenance des projets web vous invite à vous intéresser à la maintenance évolutive.

Je viens de tomber sur cet excellent billet d’Andy Hunt Stage 0 : not ready for agile dans lequel il détaille quelques points clés montrant que vous n’êtes pas prêt à passer aux méthodes agiles.

Selon Andy, vous n’êtes pas prêt à passer aux méthodes agiles si :

Il y a deux ans et demi, je vous proposais 4 pistes de réflexion destinées à augmenter l’efficacité de vos réunions. Celles-ci avaient été suivies des 10 règles d’or d’une réunion réussie, parmi lesquelles figurait en bonne place la politesse des rois : la ponctualité.

Malheureusement, il semble que celle-ci soit toujours aussi difficile à obtenir de la part de vos collaborateurs, encore plus si ces derniers viennent de services différents ou se sentent élevés dans la hiérarchie. C’est la raison pour laquelle une grande firme anglo-saxonne a mis au point une méthodologie incitative d’une efficacité sans failles, dont les résultats plus que probants devraient nous inviter à revoir nos méthodes de management sur cette partie pourtant si cruciale du travail en équipe.

La mise en place de la nouvelle version d’une application web nécessite, au moins dans les premiers temps, la mise en place de correctifs pour les bugs d’usage. Ces derniers surviennent sur des zones de l’application testées durant la recette, mais qui peuvent connaître des dysfonctionnements lors de certaines actions d’utilisateurs pourtant considérer normales.
Second volet de notre série sur la maintenance d’un site ou d’une application web, cet article vous propose de voir pourquoi il est important de mettre en place un cycle de maintenances correctives, avant d’en voir la réalisation.

La vie d’un site ou d’une application web ne commence, pas plus qu’elle ne finit le jour de sa mise en production. Faute de conseil et de culture web, nombre d’entreprises ne comprennent toujours pas qu’un site n’est pas un cube de granite voué à rester sur la toile ad vitam eternam. Il doit évoluer dans le temps, et pas seulement au gré des correctifs venant sanctionner la découverte d’un bug passé à travers les mailles du filet d’une recette trop souvent bâclée pour cause de budget.

Cet article est le premier d’une série de trois à travers lesquels je vous invite à découvrir les problèmes induits par le passage d’un projet en mode maintenance :

1. Pourquoi prévoir un budget maintenance et à qui le confier.
2. Mise en place d’un cycle de maintenance corrective.
3. Mise en place d’un plan de maintenance évolutive à long terme.

Il en va des projets web comme d’une maison, on n’arrive à rien en commençant par le toit. C’est la raison pour laquelle, qu’on soit face au client ou à ses équipes, un lancement bien ficelé est indispensable à la bonne marche du projet. Où suis-je? Où courre-je ? Dites-moi dans quel état j’erre sont quelques-unes des nombreuses questions auxquelles il vous faudra répondre sous peine de vous offrir un aller simple dans le mur à coté duquel les courses de moto de Tron passeront pour des accidents d’escargots contre des feuilles de salade.

Afin de ne rien oublier au moment de votre lancement, je vous propose une check list en 20 points à valider avant votre kick off. Que vous ayez préparé une Keynote pleine d’effets spéciaux ou que vous ayez opté pour une formule plus informelle, si elle vous répondez à l’ensemble de ces questions, vous pouvez partir l’esprit tranquille.

La controverse du week-end nous vient de John Calacanis, le fondateur Mahalo, qui donne dans une interview quelques conseils “avisés” aux entrepreneurs du web sur comment tirer le meilleur des employés de sa startup. Parmi un joli ramassis de conneries, on retiendra surtout :

Virez les personnes qui ne sont pas accros au travail. On parle de startup, si vous voulez une vie équilibrée, allez travailler à la Poste ou au Starbuck’s.

À mesure que le web gagne en maturité, les exigences des clients sur les sites et les projets livrés deviennent de plus en plus importantes. Au point d’avoir, depuis au moins deux ans, atteint sinon dépassé les exigences de design, ergonomie et stabilité autrefois réservées aux seuls éditeurs de logiciels. Dans un premier temps apparaître comme un point particulièrement positif, preuve que le web a gagné en maturité et cessé d’être un terrain de jeu pour innovateurs frappé d’un certain jeunisme, à la fois par les expérimentations parfois catastrophiques de la première bulle Internet, et par un soucis de qualité souvent au rabais. Cependant, cette exigence, venue à la fois des clients et des utilisateurs, a pour nous professionnels du web des impacts non négligeables et crée des problématiques avec lesquelles il nous faut apprendre à composer, l’imputation des problèmes étant souvent à sens unique quand les solutions à apporter sont clairement multilatérales.

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.

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