Qui n’a pas utilisé Excel pour suivre un projet, un budget, ou une liste de tâches ? Ça semble facile à concevoir, et même pratique à utiliser et à diffuser. Mais les limites sont très vite atteintes quand on veut en faire une application accessible par plusieurs utilisateurs..
Alors comment s’y prendre quand on atteint les limites de ce que peut faire un tableur aussi puissant qu’Excel ?
Nous abordons dans cet article les différents scénarios pour y parvenir.
Excel est un tableur initialement prévu pour manipuler des tableaux. Et comme il est assez naturel de présenter des données dans des cases, ce logiciel est vite devenu un assistant pratique pour dessiner des formulaires de saisie, et faire des calculs sur les données saisies.
On peut utiliser Excel pour presque tout : créer des formulaires de saisie, stocker les données comme dans une base de données, créer des analyses, produire des rapports imprimables, et tout ça en très peu de temps, et sans avoir besoin d’aligner des lignes de code. Les plus ingénieux peuvent ajouter des lignes de Visual Basic (VBA) pour enrichir ces classeurs Excel.
Mais … dès qu’il s’agit d’agréger / compiler des grands volumes de données, ou diffuser les classeurs parmi une population d’utilisateurs de manière sécurisée, ça commence à se compliquer. De même lorsque les classeurs Excel servent de simulateurs avec des paramètres qui doivent évoluer, la gestion des versions devient vite un casse-tête.
La première idée, la plus facile à mettre en œuvre, est de compléter Excel avec d’autres applications qui combleront les manques d’Excel.
On peut citer par exemple Access qui est un cousin naturel d’Excel. MS Access est une base de données bureautique (installable sur des ordinateurs de bureau) qui permettra d’étendre les capacités d’Excel en intégrant un environnement de développement simple et léger et un moteur de base de données local (MS Jet).
Couplé à Excel, MS Access permet d’automatiser le traitement de données en liaison avec Excel. Il peut s’agir par exemple :
- De la production automatique en masse de centaines ou même de milliers de classeurs Excel.
- De l’intégration en base de données du contenu de centaines de fichiers Excel dans un format de base de données structurées pour des analyses globales.
- De la réalisation de simulateurs utilisant des calculs.
Ce scénario, bien que simple et très facile à mettre en œuvre, ne permet pas l’accès par le web. En effet, Excel, comme Access, restent des applications à installer localement.
Pour s’affranchir des contraintes d’installation des applications métier localement (i.e. sur le PC de l’utilisateur), la seconde solution consiste à développer une application web qui est installée sur un serveur et utilise Excel en arrière-plan.
L’idée est de présenter à l’utilisateur une application web ordinaire et sécurisée par login / password avec des écrans qui peuvent ressembler à des tableaux (comme Excel) ou des écrans plus personnalisés qui s’appuient sur les données d’Excel en arrière-plan.
Dans cette configuration, l’application web sert d’intermédiaire entre l’utilisateur et Excel sans avoir besoin d’Excel installé sur le poste de l’utilisateur : elle affiche des valeurs issues du classeur Excel et écrit dans le classeur les valeurs renseignées par l’utilisateur.
Ainsi, l’application est une couche de présentation qui permet de créer une application plus riche en termes d’UX / UI et qui bénéficie de la puissance calculatoire d’Excel.
L’avantage instantané de cette solution est qu’elle laisse aux concepteurs Excel la pleine maîtrise des classeurs utilisés. Ceux-ci peuvent ainsi facilement être mis à jour, sans devoir modifier une ligne de code.
Cette solution est rarement proposée car elle nécessite de faire face à des défis techniques. En effet, le serveur doit être capable d’instancier des classeurs Excel pour chaque utilisateur connecté et piloter les classeurs Excel. Ce scénario est pourtant, dans la majorité des cas, le plus pertinent au regard des contraintes de maintenance des modèles Excel.
Enfin, la solution la plus proposée est sans doute la création d’une application à partir de zéro qui doit remplacer intégralement Excel.
Cette solution est souvent proposée car elle rentre dans un cadre plus traditionnel de développement. Les Directions informatiques privilégient souvent cette option car elle permet de supprimer totalement Excel, qui est considéré comme un outil de bureautique.
Dans ce cas, le développement complet d’une application capable de reproduire toutes les facettes calculatoires d’Excel se révèle être un vrai défi. En effet, de simples calculs en chaîne doivent être recodés intégralement. De plus un projet de ce type est extrêmement chronophage en ce qu’il nécessite de devoir « décortiquer » tous les calculs pour les expliquer aux développeurs.
A titre d’exemple, le développement d’un simple tableau de calcul d’amortissement financier prendra plusieurs jours de développement alors qu’il ne prend que quelques minutes à un utilisateur aguerri sur Excel.
Évidemment, dans ce schéma, toute modification des calculs, ou des formats de restitution implique l’intervention de développeurs qui doivent modifier l’application. Il peut être le scénario à privilégier quand Excel n’est utilisé que comme simple liste de données à mettre à jour, sans calcul. Excel, par sa facilité de manipulation de données en masse, reste utilisé pour les imports et les exports.
En synthèse, ce scénario sera toujours le plus coûteux et le plus long à mettre en place. Par ailleurs, il suppose une refonte complète du fonctionnement des classeurs Excel au profit d’un projet de développement traditionnel.
Dans tous les scénarios, Excel conserve une partie de son usage ; pour la saisie de données, les imports & exports, les calculs complexes en chaîne. Bien sûr, il existe d’autres variantes de ces scénarios, mais chaque besoin étant différent, il nécessite une approche personnalisée.
Excel reste donc un très bon point de départ pour prototyper une application et reste incontournable pour les applications permettant de saisir et traiter des données numériques. Le choix de son remplacement ou son encapsulation dépendra de plusieurs facteurs tels que :
- la population d’utilisateurs destinés à accéder à l’outil
- les besoins de mise à jour des calculs sous-jacents
- la disponibilité d’une équipe de développement
- la stratégie de la Direction informatique.
Envie d’être accompagné pour faire les bons choix et optimiser vos outils ? Parlons en ensemble !
