thtioxine

Suite logique du billet précédent qui s'attaquait à la dorsale, on se penche maintenant sur le frontal.
Les questions/phases sont quasi identiques et cela commence par la pertinence. Est ce que ça vaut le coup ?

Les raisons évoquées pour quitter Ms Access sont :
A) Un déploiement compliqué : Il faut copier le frontal sur chaque poste client ou trouver une astuce pour le faire en automatique
B) Une mise à niveaux risquée : Si un pb survient après la mise à niveau de Ms office, la correction est souvent hors de portée d'un non expert
Même si ces raisons sont "entendables", l'évaluation de la pertinence doit être faite car une migration n'est jamais "le bord du trait".

Phase 1 : Pertinence
Autant, pour migrer vers SQL, cette phase est complexe, autant ici, celle-ci se révèle simple. En gros, on étudie la migration si l'une des deux conditions suivantes est remplie.
A) Beaucoup d'utilisateurs
B) La répartition des utilisateurs est multi-sites.

Dans les autres cas, c'est rarement une bonne idée de lancer une migration. (Ceci dit, il existe d'autres cas pour lesquels la réponse est difficile à donner : Une reprise par la DSI, la personne qui connaissait la techno s'en va et personne ne peut le remplacer, ..)

Normalement l'IT n'est pas la pour dire si c'est pertinent ou pas, elle est la pour donner l'ensemble des billes au client qui fera son choix. Mais dans ce type de migration, elle doit se faire entendre , voire refuser si il est évident que le jeu n'en vaut pas la chandelle.

Phase 2 : Le choix de la techno
La phase 1 ayant montré un intérêt évident à se passer de Ms Access, il faut choisir la techno qui sera utilisée.
Ce choix est restreint par 2 axes : qui fait,qui maintient
Si le service qui s'occupera de la migration et de la maintenance est un service informatique (DSI, SSII, Prestataire) et que le budget est assez conséquent, on choisira une techno dite "moderne".
Si, au contraire, c'est l'informatique "informelle" qui va faire, on préférera une techno plus ancienne mais plus simple qui sera ASP (Pourquoi ASP ? : Le code ASP est très proche du VB et un dev utilisant ce langage n'aura pratiquement aucune difficulté pour coder. D'autre part, le déploiement dans un serveur IIS est très simple puisque il suffit de copier les pages asp dans le répertoire voulue du serveur)

A la fin de cette phase, on a choisi la techno MAIS on ne sait toujours pas si migrer sera possible.
En effet, ACCESS est local alors que ASP est serveur. Cela provoque des problèmes très difficiles à résoudre. L'exemple le plus courant étant l’accès à l’imprimante locale du client. Il va donc falloir creuser pour être quasi sur que l'on ne va pas se heurter à une impossibilité.C'est la phase d'analyse et de chiffrage.

Phase 3 : Analyse et chiffrage
Une application ACCESS est composée de formulaires ou/et rapports, de tables , de requêtes et de modules.
Les tables , donc la dorsale, a fait l'objet d'un billet précédent, je n'y reviens donc pas (Ceci dit, on peut vouloir migrer le frontal sans toucher à la dorsale)
La 1ere chose qui doit être recherchée, c'est la partie locale. Cela peut être un accès imprimante, l’accès à un fichier, l'appel à une appli tierce.. Cette recherche doit être minutieuse et chaque cas remonté doit avoir une solution possible. (On peut décider de mettre à dispo un fichier que le client imprimera pour résoudre le pb de l'imprimante locale par exemple). Si un cas rencontré n'a pas de solution (ce qui est tout à fait possible dans le cas d'une appli tiers), soit le client se passe de la fonctionnalité, soit celle ci est traitée extérieurement, soit la migration est impossible.
Une fois cet exercice fait, il s'agit de passer au calcul de la charge. Celle ci sera composée des charges liées aux solutions local/serveur, aux formulaires à passer en HTML/CSS/JSCRIPT, aux différentes requêtes et, enfin, aux code des modules.

Les formulaires sont assez simples à migrer car
A) La position des éléments est indiquée dans le formulaire.
B) Les événements ont leur pendants dans HTML
C) Les contrôles automatiques (Date,..) peuvent facilement être reconduits en Java Script
D) De même pour le code associé aux formulaires.

Pour les rapports, ça se complique, et pas seulement pour le pb de l'impression. En effet, il vous faudra refaire la mise en page et coder vers un PDF (C'est le type de fichier le plus simple à mettre en oeuvre si la mise en page est riche)

Les requêtes nommées seront transformés en fichier et appelée par un include la ou c'est nécessaire, les autres requêtes étant copiées quasiment telle quelle.

Enfin, le code des modules sera repris quasiment à l'identique.

Il est difficile de donner une recette ici, chaque cas/personne étant différent mais je peux indiquer ce que je fais.
Pour les pb spécifiques, c'est au coup par coup
Pour les formulaires, je compte 3 jours pour les 2 premiers, puis 1 jour par formulaire.
Pour les rapports, 2 jours par rapport.
Pour le reste, je compte 2 jours par module et 1 jour pour 5 requêtes.
J'ajoute en final 15% pour les impondérables.

Quoiqu'il en soit, cette phase doit donner lieu à une documentation détaillée , documentation qui sera fournie au client qui devra fournir un GO/NOGO. Pour rappel, même si l'IT n'est pas censée être juge et partie, dans ce cas la, un chiffrage visiblement hors de proportion avec le résultat attendu doit faire l'objet d'un NOGO de l'IT.

Je ne détaillerais pas ici le développement car cela n'a pas d’intérêt. Simplement, ne pas oublier la documentation et les réunions d'avancement avec les différents acteurs.