Migrer les macros VBA : documenter les règles avant la réécriture

Dresser un inventaire utilisable par un repreneur

Listez les procédures lancées par un bouton, à l’ouverture du fichier ou lors d’une modification de cellule. Pour chacune, notez l’entrée, la sortie, le responsable métier et les logiciels appelés. Une macro peut dépendre d’un chemin réseau, d’un modèle Word, d’une imprimante ou d’une session Outlook. Ces dépendances doivent apparaître dans le dossier de cadrage, même si elles ne sont pas visibles à l’écran.

Repérez les références de bibliothèques, les appels au système, les tâches programmées et les éventuels identifiants intégrés au code. Ne transmettez aucun secret dans une demande de devis. La revue technique s’organise ensuite dans un environnement contrôlé. Identifiez les parties du code réellement utilisées en confrontant l’inventaire aux pratiques des utilisateurs : un ancien bouton peut rester présent sans être nécessaire au processus actuel.

Séparer calcul, action et présentation

Une règle de remise doit pouvoir être testée indépendamment du bouton qui l’exécute. Rédigez une description de ses conditions, des priorités entre exceptions et des arrondis. Les calculs qui autorisent un engagement financier doivent être vérifiés côté serveur ; un contrôle uniquement dans le navigateur peut être contourné. Une présentation de rapport, en revanche, peut être reconstruite sans reproduire toutes les manipulations de cellules.

Les actions externes demandent un choix spécifique. Une application web ne dispose pas naturellement des mêmes accès au poste local qu’une macro. L’impression, la génération de documents ou les envois doivent avoir un parcours explicite, avec leurs erreurs et leurs reprises. Demandez au prestataire de démontrer le traitement d’un fichier absent ou d’un service indisponible, pas uniquement le cas où tout fonctionne.

Constituer les preuves de résultat

Préparez un jeu de cas fictifs dont le résultat est approuvé par le métier. Il doit couvrir les valeurs limites, les cellules vides, les dates inhabituelles et les annulations. Comparez l’ancien calcul et le nouveau, puis faites arbitrer les différences : une anomalie historique ne doit pas être reproduite sans décision. Le dossier de recette conserve les hypothèses retenues et les sorties attendues.

Si une macro est mal documentée, commencez par une observation accompagnée et un audit. Ne promettez pas une réécriture exacte avant cette étape. Les utilisateurs qui connaissent les exceptions doivent être disponibles pour expliquer les écarts. Le contrat de maintenance prévoit ensuite qui modifie les règles, comment elles sont testées et comment les changements sont annoncés. Une application réécrite peut devenir aussi dépendante d’une personne que la macro initiale si sa documentation reste absente.

Exercice fictif pour préparer la recette

Choisissez une règle de calcul fictive comportant une valeur manquante, un arrondi et une exception de remise. Décrivez son résultat attendu indépendamment de toute feuille. Faites exécuter l’ancien traitement sur un jeu contrôlé et le nouveau sur les mêmes entrées. Le rapport indique chaque différence, la cause et la décision métier. Aucun résultat ne doit être accepté uniquement parce que les deux écrans affichent le même total global.

Ajoutez une action externe, comme la création d’un document dans un répertoire. Simulez l’absence du modèle ou un refus de droit. Le candidat montre ce qui est enregistré, ce qui est annulé et ce que l’utilisateur peut reprendre. Si le calcul est validé mais le document n’est pas créé, le dossier doit avoir un état explicite.

Demandez ensuite comment une future modification de la règle sera testée. Le jeu de cas doit pouvoir être rejoué par le mainteneur et compris par le référent métier. Cet exercice permet de discuter la documentation, les responsabilités et les limites du forfait avant la réécriture, sans confier au formulaire public un extrait réel de code ou des identifiants.

Une fiche de consultation à remplir avec le métier

Pour utiliser cette grille, réunissez le responsable du processus, un utilisateur qui connaît les exceptions et la personne qui suivra le budget. Préparez un exemple fictif représentatif plutôt qu’une base réelle. Pour chaque ligne, faites décrire l’état actuel, le résultat voulu et la personne habilitée à arbitrer un écart. Les éléments inconnus restent identifiés comme des investigations à mener avant l’engagement de réalisation.

Demandez au candidat de reprendre cette grille dans sa proposition, avec les livrables inclus et les exclusions. Une réponse qui ne couvre qu’un cas normal doit être précisée. Les erreurs, les annulations et les reprises après incident peuvent modifier le coût et le fonctionnement. Conservez les hypothèses acceptées avec le périmètre de recette afin que le responsable puisse vérifier la livraison.

Le rôle de Suite Métier est la mise en relation. Le prestataire confirme la faisabilité, son architecture et son devis après examen du besoin. Les modalités de reprise, les droits contractuels et les engagements de support sont à convenir avec lui. Aucun délai de réalisation ni résultat financier n’est garanti par cette fiche. Le décideur reste maître du choix et de la réception.

Questions pratiques

Préparer la suite du projet

• Migration Access vers une application web : cadrage, reprise et devis
• Demander un devis et cadrer votre besoin
• Migrer les données Access : préserver relations et historiques
• Recette d’une migration : signer des preuves de rapprochement
• Bascule d’une application métier : organiser le retour possible
• Notre méthode de sélection et de traitement des demandes
• Cadrer le remplacement d’un outil Access ou Excel