Transformer un fichier Excel en application web : méthode, étapes et limites

Un classeur Excel qui sert tous les jours à plusieurs personnes finit par poser le même problème : la logique de calcul est juste, mais l’outil est fragile. Une formule écrasée, une copie qui circule, un onglet que personne n’ose toucher. Transformer un fichier Excel en application web consiste à garder cette logique intacte et à remplacer les cellules par des écrans : on saisit ce qui est demandé, on obtient le résultat, et les formules restent hors de portée.

J’ai mené ce type de transformation chez mon employeur : des classeurs complexes y sont devenus des mini-sites intranet écrits en HTML, CSS et JavaScript, qui fonctionnent en local et gardent la logique de calcul d’origine derrière une interface beaucoup plus simple. Voici la méthode, étape par étape, avec ce qu’on y gagne et ce qu’on y perd.

Classeur Excel : formules, barèmes, règles

1. 1

   Étape 1 : Cartographier le classeur

   • Saisie
   • Paramètres
   • Calculs intermédiaires
   • Sorties
2. 2

   Étape 2 : Séparer données, règles et écrans

   • Une feuille, un écran
   • Maquettes validées
3. 3

   Étape 3 : Reprendre les calculs à l’identique

   • Arrondis
   • Nombres à virgule
   • Dates
4. 4

   Étape 4 : Vérifier chaque résultat face au classeurÉtape décisive

   • Cas réels
   • Tolérance fixée
   • Chaque écart expliqué
5. 5

   Étape 5 : Choisir où l’application tourne

   • Fichiers locaux
   • Intranet
   • En ligne
6. 6

   Étape 6 : Prévoir l’import, l’export et la suite

   • Import
   • Export CSV ou Excel
   • Impression
   • Documentation

Application web : même logique, écrans guidés

Quand transformer un fichier Excel, et quand rester sur Excel

Les limites techniques d’Excel sont rarement le vrai sujet. Une feuille compte 1 048 576 lignes et 16 384 colonnes, une formule peut atteindre 8 192 caractères et imbriquer 64 niveaux de fonctions, selon les spécifications et limites d’Excel publiées par Microsoft. La plupart des classeurs métier n’en approchent jamais. Le problème vient de l’usage.

La transformation vaut la peine quand :

• le même calcul est refait souvent, avec des entrées différentes : un devis, un dimensionnement, un tarif ;
• les personnes qui l’utilisent ne sont pas celles qui l’ont construit ;
• une erreur de saisie ou une formule écrasée coûte cher ;
• la prise en main demande une formation, ou un « mode d’emploi » transmis à l’oral.

À l’inverse, restez sur Excel pour explorer des données, faire une analyse ponctuelle ou tenir un calcul dont les règles changent chaque semaine : c’est là qu’Excel est imbattable. Pour faire le point sur votre fichier, voyez les 10 signes qu’il est temps de remplacer Excel.

Étape 1 : cartographier le classeur

Avant d’écrire une ligne de code, il faut comprendre le fichier mieux que ceux qui l’utilisent. L’inventaire range chaque feuille, ou chaque zone, dans l’un de ces rôles :

• Saisie : les cellules que l’utilisateur remplit ;
• Paramètres : barèmes, coefficients, tables de référence, qui changent rarement ;
• Calculs intermédiaires : souvent masqués, ce sont eux qui portent la logique ;
• Sorties : le résultat qu’on imprime, copie ou transmet.

Pour chaque résultat, on remonte la chaîne des formules jusqu’aux saisies. Les outils d’audit d’Excel, comme « Repérer les antécédents » dans l’onglet Formules, font gagner beaucoup de temps. On note au passage ce qui posera problème : valeurs tapées en dur au milieu d’un calcul, liaisons vers d’autres fichiers, macros VBA, cellules qui ne servent plus.

Enfin, on interroge ceux qui s’en servent. Un classeur ancien contient presque toujours des onglets abandonnés et des usages que personne n’a écrits : l’application doit reprendre ce qui sert vraiment, pas tout ce qui existe.

Étape 2 : séparer les données, les règles et les écrans

Dans Excel, tout est mélangé : la donnée, la formule et la mise en forme vivent dans la même cellule. Une application les sépare en trois couches :

1. Les données : ce que l’on saisit et ce que l’on conserve, par exemple un devis ou une fiche de contrôle ;
2. Les règles : les calculs et les barèmes, regroupés à un seul endroit, lisible et documenté ;
3. Les écrans : ce que voit l’utilisateur, dans l’ordre où il réfléchit.

Cette séparation change tout pour la maintenance : mettre à jour un barème ne touche plus aux écrans, et modifier un écran ne risque plus de casser un calcul.

Pour les écrans, je pars d’un principe simple : une feuille, un écran. Chaque écran ne pose que les questions nécessaires, avec des listes plutôt que du texte libre, l’unité affichée à côté de chaque champ et un message clair quand une valeur sort des limites. Les écrans se valident sur maquette avec les utilisateurs, avant le développement.

Étape 3 : reprendre les calculs à l’identique

Chaque formule devient une fonction nommée, que l’on peut tester seule. Un SI imbriqué sur cinq niveaux devient une suite de conditions lisibles ; une RECHERCHEV devient une table de correspondance. Trois points demandent une attention particulière, car Excel et JavaScript ne se comportent pas toujours de la même façon.

Les arrondis

La documentation Microsoft de la fonction ARRONDI indique que =ARRONDI(-1,475; 2) donne -1,48. En JavaScript, Math.round arrondit les demis vers +∞ : le calcul naïf Math.round(-1.475 * 100) / 100 donne -1,47. Sur une facture, un centime d’écart suffit à faire perdre confiance dans l’outil. Il faut donc écrire une fonction d’arrondi qui reproduit celle d’Excel, et l’utiliser partout.

Les nombres à virgule

Les deux outils stockent les nombres de la même manière, en double précision selon la norme IEEE 754 (Microsoft, MDN). Mais Excel travaille sur 15 chiffres de précision et corrige certains résultats très proches de zéro. Microsoft cite l’exemple =1,333+1,225-1,333-1,225 : Excel affiche 0 depuis la version 97, alors que le même calcul en JavaScript donne -2.220446049250313e-16. La comparaison des résultats doit donc se faire avec une tolérance, sur des valeurs arrondies comme le métier les utilise.

Les dates

Excel stocke une date comme un numéro de série qui part du 1er janvier 1900 dans le système par défaut (Microsoft). Par compatibilité historique avec Lotus 1-2-3, il considère aussi que 1900 est une année bissextile, ce qu’elle n’est pas (Microsoft). Toute date importée d’un fichier Excel doit être convertie avec soin, et vérifiée.

Le détail de ces conversions, avec des exemples de code, fait l’objet d’un guide dédié : recréer des formules Excel en JavaScript sans perdre en précision.

Étape 4 : vérifier chaque résultat face au classeur

C’est l’étape qui sépare un outil adopté d’un outil abandonné. Le principe : on constitue un jeu de cas réels, on les calcule dans le classeur d’origine et dans l’application, et on compare chaque résultat. Pour que l’exercice soit probant, prévoyez :

• des cas courants, tirés de l’activité récente ;
• des cas limites : valeurs nulles, maximums, seuils de barème ;
• les cas qui ont déjà posé problème, s’il y en a ;
• une tolérance d’écart fixée à l’avance : le centime, l’unité, le dixième ;
• une explication pour chaque écart : erreur de l’application, ou erreur découverte dans le classeur.

La vérification révèle parfois des erreurs dans le classeur lui-même : une plage qui s’arrête trop tôt, une formule qui n’a pas été recopiée sur toutes les lignes. On les corrige avec le métier, en connaissance de cause, plutôt que de les reproduire fidèlement.

Ce jeu de cas ne sert pas qu’une fois. Conservé avec l’application, il est relancé à chaque évolution : si un nouveau barème modifie un résultat de façon inattendue, on le voit avant les utilisateurs.

Étape 5 : choisir où l’application tourne

Une application web n’a pas forcément besoin d’un serveur. Trois formes existent, et le choix dépend surtout d’une question : les utilisateurs partagent-ils des données, ou chacun fait-il ses propres calculs ?

La version locale est la plus simple à déployer : un dossier qui contient une page HTML, ses styles et ses scripts, posé sur un partage réseau, que chacun ouvre dans son navigateur. Elle a deux contraintes techniques à connaître :

• les modules JavaScript ne se chargent pas depuis une adresse file://, à cause des règles de sécurité du navigateur (MDN) : le code doit être livré sous forme de scripts classiques ;
• le comportement du stockage du navigateur, localStorage, n’est pas défini pour les fichiers ouverts depuis le disque et peut varier selon les navigateurs (MDN) : ce qui doit être conservé l’est dans des fichiers, pas seulement dans le navigateur.

Pour écrire directement dans un fichier du dossier partagé, l’API File System Access fonctionne dans Chrome et Edge, mais pas dans Firefox ni Safari (MDN). Le plus robuste reste un bouton « Exporter » qui enregistre un fichier, et un bouton « Importer » pour le rouvrir. Le fonctionnement complet est détaillé dans le guide un intranet local en HTML et JavaScript.

Étape 6 : prévoir l’import, l’export et la suite

Une application qui enferme les données dans ses écrans finit contournée. Elle doit dialoguer avec Excel :

• Import : reprendre un fichier existant, comme une liste de références ou un barème mis à jour, sans ressaisie ;
• Export CSV ou Excel : pour l’analyse, les tableaux croisés, l’archivage. Un détail compte : un CSV encodé en UTF-8 s’ouvre normalement dans Excel s’il est enregistré avec une marque d’ordre d’octets (BOM) ; sinon, il faut l’importer par l’onglet Données, Obtenir des données, À partir d’un fichier texte/CSV (Microsoft) ;
• Impression : une mise en page propre du résultat, s’il part chez un client ou en atelier.

Reste la passation. La documentation tient en deux parties : un mode d’emploi d’une page pour les utilisateurs, et une note technique qui dit où vivent les règles et comment changer un barème. Les demandes d’évolution passent par une seule personne, qui les regroupe : c’est ce qui évite de recréer, dans l’application, le désordre qu’on a quitté dans le classeur.

Power Apps, no-code ou sur mesure : les alternatives

Développer une application web sur mesure n’est pas la seule façon de sortir d’un classeur fragile :

• Power Apps est la plateforme de Microsoft pour créer des applications métier reliées à vos données, par exemple SharePoint ou Dataverse (Microsoft Learn). Son langage de formules, Power Fx, emprunte beaucoup à Excel, mais la logique doit être réécrite. Côté licences, certains abonnements Microsoft 365 incluent des droits limités, destinés aux connecteurs standard ; le reste demande une licence dédiée (Microsoft).
• Les outils no-code, bases de données en ligne et constructeurs de formulaires, se mettent en place vite pour des listes et des formulaires. Des calculs imbriqués sur plusieurs feuilles s’y traduisent moins facilement, et les données sont hébergées par l’éditeur.
• Une application web sur mesure reprend exactement vos calculs, sans licence par utilisateur, et peut tourner sans serveur. En contrepartie, elle demande un développement initial et quelqu’un pour la faire évoluer.
• Un classeur mieux structuré reste une option sérieuse : tableaux, validation des données, Power Query. Elle suffit quand le fichier reste entre les mains de quelques personnes à l’aise avec Excel.

Le comparatif complet, critère par critère, est dans le guide Excel, no-code ou application sur mesure.

En résumé : ce que vous gagnez, ce que vous perdez

Vous gagnez un outil qu’un nouvel arrivant prend en main sans longue formation, des formules que personne ne peut écraser, des saisies contrôlées et une seule version de référence. Vous perdez une partie de la souplesse d’Excel : un utilisateur ne peut plus ajouter une colonne ou ajuster une formule dans son coin, et chaque évolution passe par une demande.

C’est un bon échange quand le calcul est stable, répété et partagé. Commencez par cartographier votre classeur : cette étape seule montre souvent ce qui doit être transformé, et ce qui peut rester dans Excel. Pour la suite, c’est l’objet de mon accompagnement Excel en application web.