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

Le massacre des saints innocents

Perry the Platypus wants you to subscribe now! Even if you don't visit my site on a regular basis, you can get the latest posts delivered to you for free via Email: