Quand remplacer ses tableurs par une application ?

Le tableur n'est pas un mauvais outil. Il est parfait pour explorer des chiffres, faire un calcul ponctuel ou démarrer une activité. Il devient un risque quand il sert de logiciel de gestion partagé, alimenté par plusieurs personnes et dont dépend une partie du travail. Voici les signes à surveiller, les options possibles et la méthode pour migrer.

Quels signes montrent qu'un tableur a atteint ses limites ?

• Plusieurs versions circulent : « suivi_v3_final_bis » envoyé par courriel, et personne ne sait laquelle fait foi.
• Les mêmes informations sont saisies deux fois, dans le fichier puis dans un autre logiciel.
• Des formules se cassent quand quelqu'un insère une ligne ou colle une valeur, sans que personne ne s'en aperçoive.
• Aucun historique : impossible de savoir qui a modifié une valeur et quand.
• Des droits impossibles à régler : tout le monde voit tout, y compris des données personnelles ou des tarifs.
• Le fichier dépend d'une seule personne qui en connaît les règles cachées.
• Le fichier ralentit ou devient difficile à ouvrir à mesure qu'il grossit.
• Des étapes de validation se gèrent avec des couleurs de cellules et des relances.

Un seul de ces signes ne justifie pas un projet. Plusieurs à la fois, sur un fichier dont dépend l'activité, méritent une réflexion.

Quelles sont les options ?

Ces options ne s'excluent pas. Un tableur mieux structuré peut servir de transition pendant la conception de l'application, à condition de figer ses règles pour ne pas multiplier les exceptions à reprendre ensuite.

Pour trancher entre les deux dernières options, voyez l'article logiciel du marché ou développement sur mesure.

Qu'apporte une application par rapport au tableur ?

• Des contrôles à la saisie : champs obligatoires, formats vérifiés, doublons signalés.
• Une base de données unique : tout le monde travaille sur la même information, en même temps.
• Un historique des modifications, avec leur auteur.
• Des droits par rôle : chacun ne voit et ne modifie que ce qui le concerne.
• Des étapes et des statuts : une demande passe de « reçue » à « validée » selon des règles définies.
• Des calculs protégés : les formules sont dans le code, pas dans une cellule que l'on peut écraser.
• L'export reste possible : vous pouvez toujours extraire les données vers un tableur pour une analyse ponctuelle.

Comment migrer sans rien perdre ?

1. Inventorier les fichiers concernés, leurs utilisateurs et ce qu'ils en font.
2. Extraire les règles cachées : chaque formule, mise en forme conditionnelle ou colonne masquée traduit une règle métier. Notez-les en phrases simples.
3. Nettoyer les données : doublons, cellules fusionnées, dates saisies comme du texte, valeurs « à voir ».
4. Décrire les écrans nécessaires, souvent sous forme de wireframe, c'est-à-dire un schéma simple de l'écran sans graphisme.
5. Importer les données et les faire vérifier par les utilisateurs habituels du fichier.
6. Faire tourner les deux en parallèle sur une période courte, puis archiver le tableur en lecture seule.

Les pièges à éviter

• Reproduire à l'identique le tableur, avec ses défauts, au lieu de repartir du besoin.
• Oublier les usages annexes : un collègue qui exporte le fichier chaque mois pour un autre service.
• Lancer l'outil sans former les utilisateurs ni désigner un référent.
• Confier le nettoyage des données à des personnes qui ne connaissent pas le fichier : elles ne savent pas distinguer une erreur d'une exception volontaire.

Pour cadrer le projet, les rubriques de l'article rédiger un cahier des charges s'appliquent aussi à une application. NexSecure transforme des tableurs critiques en applications web sur mesure, hébergées en France.