Remplacer Excel et les macros VBA par une application
Remplacer un fichier Excel métier par une application, c’est déplacer les données dans une base, transformer les formules et les macros VBA en règles codées et testées, et remplacer les onglets par des écrans avec des droits par utilisateur. Excel peut rester un outil d’export ou d’analyse. Anaska, dont l’éditeur est WebGuard Agency, décrit ici la méthode. Le tarif se définit sur devis, après audit.
Les signaux qui ne trompent pas
Plusieurs versions du même fichier circulent par mail. Une macro plante et la seule personne qui sait la réparer est absente. Des erreurs de saisie passent inaperçues jusqu’à la facture. Il faut fermer le fichier pour que quelqu’un d’autre puisse l’ouvrir. Personne ne sait qui a modifié quoi. Un seul de ces signaux peut suffire à ouvrir le sujet. Plusieurs à la fois, et le fichier est déjà un processus d’entreprise déguisé.
Ce que devient chaque élément d’Excel
| Élément Excel | Équivalent dans une application |
|---|---|
| Onglets de saisie | Écrans avec des champs contrôlés |
| Lignes du tableau | Enregistrements dans une base de données |
| Formules | Calculs codés et testés |
| Macros VBA | Traitements côté serveur, déclenchés par un bouton ou automatiquement |
| Listes déroulantes | Référentiels partagés |
| Mot de passe du fichier | Comptes, rôles et historique des modifications |
| Tableaux croisés | Tableaux de bord et exports |
Trois options possibles
| Option | Pour qui | Limite |
|---|---|---|
| Outil no-code | Besoin simple, peu d’utilisateurs | Dépendance à la plateforme, règles limitées |
| Power Apps | Entreprise déjà sur Microsoft 365 | Se complique avec des règles riches |
| Application web sur mesure | Règles métier précises, intégrations, accès externes | Projet plus construit au départ |
La méthode
On commence par lire le fichier : inventaire des feuilles, des formules et des macros, et écriture des règles qu’elles appliquent. On construit ensuite le modèle de données (clients, commandes, produits, interventions : chaque notion devient une table). Les écrans partent des gestes réels des utilisateurs, pas de la forme du tableau. L’historique est nettoyé puis chargé dans la base. Pendant une courte période, on fait tourner les deux en parallèle et on compare les résultats.
L’application peut produire des exports Excel ou CSV. Vos équipes gardent leurs analyses habituelles, mais la saisie et les règles vivent dans un seul endroit. On n’est pas obligé de tout migrer d’un coup : on commence par le processus le plus critique, puis on avance par étapes. Cette bascule progressive se retrouve aussi dans une migration WinDev vers C#, où l’existant continue de tourner le temps de reprendre les règles.
Le prix se fixe sur devis après audit. Il dépend du nombre d’écrans, de la complexité des macros, des intégrations avec d’autres outils et du nombre d’utilisateurs.
Pour poser le contexte : le formulaire de contact. Décrivez ce que le fichier fait aujourd’hui et ce qui casse. N’envoyez pas le classeur complet s’il contient des données personnelles ; un échange permet de voir comment le transmettre de façon cadrée.
Quand il est raisonnable de ne pas migrer
Un classeur personnel, peu partagé, sans macro fragile, peut rester dans Excel. La question se pose quand le fichier devient un processus : plusieurs personnes saisissent, des règles métier y sont cachées, un oubli de sauvegarde ou une version perdue a déjà coûté du temps. Dans ce cas, laisser faire « encore un an » revient souvent à empiler des rustines (nouvel onglet, nouvelle macro, mot de passe sur une feuille) sans résoudre le fond : une seule copie de vérité, des droits, un historique.
Il arrive aussi que seule une partie du classeur pose problème (la saisie et les règles), alors que les tableaux d’analyse restent utiles. On migre alors la saisie, et on garde un export Excel. Ce n’est pas un échec. C’est un périmètre.
Les étapes, un peu plus en détail
L’audit commence par une lecture honnête du fichier : feuilles, formules, macros, liaisons vers d’autres classeurs, listes de validation, cellules « magiques » dont personne ne connaît l’origine. On écrit les règles en langage métier, pas en recopiant le VBA, comme on le ferait pour réussir une migration de logiciels. Le modèle de données suit ces règles (une notion, une table), pas la forme des onglets. Les écrans partent des gestes : créer, corriger, valider, exporter, pas d’une copie visuelle du tableur.
Le chargement de l’historique demande un nettoyage (doublons, dates incohérentes, codes morts). Puis vient une période où l’ancien fichier et l’application tournent ensemble, sur les mêmes cas, pour comparer les résultats. On ne coupe l’ancien outil que lorsque les écarts sont compris et acceptés. Les droits (qui voit, qui saisit, qui valide) et le journal des modifications font partie du livrable, pas d’un supplément « si on a le temps ».
Limites des options no-code et Power Apps
Un outil no-code va assez loin sur un besoin simple, avec peu d’utilisateurs. Il devient inconfortable dès que les règles s’enchaînent, qu’il faut s’intégrer à d’autres logiciels, ou que vous ne voulez pas dépendre d’une plateforme pour des processus critiques. Power Apps a du sens dans une organisation déjà ancrée sur Microsoft 365 ; ce n’est pas un jugement de valeur, c’est une condition d’existant. Dans les deux cas, on vérifie qui possède les données et comment on repart si l’outil change. On retrouve le même réflexe du côté d’une alternative à WinDev : on part de ce que le métier impose, pas de l’outil à la mode.
Le tarif se définit sur devis, après audit. Il dépend du nombre d’écrans, de la complexité des macros, des intégrations et du nombre d’utilisateurs. Aucune fourchette n’est publiée ici.
Quand les données sont déjà dans une base Access, avec formulaires et VBA, le chemin est différent : voir la migration Access vers le web.