Discussion :

[kevin254kl]

Bonjour à tous,

Dans l'entreprise ou je suis il va y avoir bientôt une migration vers un autre langage.
Mon objectif est de préparer et aider les équipes afin de ne rien perdre du métier code comme data.
Comment je pourrais procéder d'après vous ?
J'avais dans l'idée de déjà documenter les processus avec des logigrammes et une documentation par features.

Auriez vous des ressources à me recommander ?

Merci

[escartefigue]

Je ne sais pas ce que c'est qu'un "Legacy"...
A priori on parle d'une refonte totale du système d'information : changement de base de données et de langage de programmation ?
Dans ce cas il faut décrire les processus métier ce qui entre, ce qui sort, les événements déclencheurs, etc.
Pour ce qui concerne la base de données, il faut dépoussiérer le dictionnaire de données existant : vérifier son exhaustivité, identifier les synonymes, détecter les homonymes, vérifier les règles de gestion.

[el_slapper]

"legacy", c'est héritage, donc une vieille appli.

J'ai fait ça plusieurs fois dans ma carrière. Ca commence généralement par une analyse complète de l'existant, pour faire une rétro-doc (car la doc existante est forcément obsolète, et pire, elle ne comprend pas des milliers de petites verrues ajoutées au fil du temps qui font que ça marche). Ensuite, le métier doit décider ce qu'on en profite pour changer (si il décide avant, sans savoir, c'est un aller-simple pour l'enfer). Et on réécrit. Après, j'avais été bourrin et fait une bête documentation en mode texte, aucun logigramme, rien que du "_si le code routage est 09 ou 59 alors on passe en facturation Alsace-Moselle".

Et surtout, une fois écrit, on compare. On doit avoir des outils de comparaison pour chaque poil de fourmi qui sortait de l'ancienne application, et vérifier que c'est toujours dans la nouvelle.

un peu de littérature à ce sujet. C'est vieux, mais toujours d'actualité. Rien n'est plus dangereux qu'un big bang, dans ces cas là, une migration progressive et toujours réversible en cas de souci est essentielle. Alors ce que décrit Joel Spolsky est un peu différent parce qu'il ne change pas de langage, mais l'idée est là : on assure ses arrières. On fait des changements unitaires progressifs, et on met du test automatique partout pour vérifier que le nouveau fait pareil que l'ancien.

[kevin254kl]

Génial merci beaucoup pour vos retours
Je vais partir sur vos conseils.