Presque toutes les entreprises que nous rencontrons pilotent une partie de leur activité dans un tableur. Un suivi de commandes, un planning d'interventions, un stock, une facturation. Et presque toutes nous posent la même question : est-ce qu'il est temps d'en faire une vraie application ? La réponse honnête, c'est que la plupart du temps, non. Mais quand c'est oui, les signaux sont très reconnaissables.
Ce guide ne cherche pas à vous convaincre de remplacer votre tableur. Nous construisons des applications métier, donc nous avons un intérêt évident à ce que vous le fassiez : raison de plus pour commencer par les cas où il ne faut surtout pas.
Ce qu'un tableur fait très bien
Un tableur est l'outil le plus rapide au monde pour modéliser un problème qu'on ne comprend pas encore. On ouvre une feuille, on met des colonnes, on change d'avis, on ajoute une formule. Aucun logiciel sur mesure ne rivalise sur ce terrain, et aucun ne le devrait.
Tant que votre processus est encore en train de se stabiliser, le tableur est le bon outil. Le figer dans une application, c'est payer pour cimenter une organisation que vous allez changer dans trois mois. Nous avons déjà conseillé à des clients de repousser leur projet de six mois pour cette raison.
- Le processus change encore souvent : gardez le tableur.
- Une seule personne l'utilise vraiment : gardez le tableur.
- Le volume tient dans quelques centaines de lignes : gardez le tableur.
- Vous ne sauriez pas décrire les règles à quelqu'un d'autre : gardez le tableur, mais commencez à les écrire.
Les six signaux qu'un tableur a dépassé son rôle
1. Plusieurs personnes doivent l'éditer en même temps
C'est le signal le plus fréquent et le plus coûteux. Dès que deux personnes modifient le même fichier, apparaissent les copies : le fichier de Sophie, la version du mardi, la vraie version finale. Le partage en ligne atténue le symptôme mais pas la cause : un tableur n'a pas de notion d'utilisateur, de droits, ni de conflit d'édition sur une ligne précise.
2. Le fichier contient des règles que personne ne sait expliquer
Une formule imbriquée sur douze niveaux, écrite il y a quatre ans par quelqu'un qui est parti. Tout le monde s'en sert, personne n'ose y toucher. Ce n'est plus un tableur, c'est un logiciel non documenté dont vous avez perdu le code source. Le risque n'est pas théorique : le jour où la règle doit changer, vous êtes bloqué.
3. On recopie des données d'un fichier à un autre
Le copier-coller entre deux outils est un travail que personne n'a choisi de faire et que personne ne valorise. C'est aussi le premier endroit où les erreurs entrent. Si quelqu'un chez vous passe une demi-journée par semaine à faire transiter des données à la main, ce temps est mesurable, et c'est souvent le calcul le plus parlant pour arbitrer.
4. Une erreur coûte de l'argent et personne ne la voit passer
Un tableur ne vous empêche pas de saisir une quantité négative, une date incohérente, un client qui n'existe pas. Une application, si. Ce n'est pas une question de confort : c'est la différence entre une erreur détectée à la saisie et une erreur détectée dans la facturation du mois suivant.
5. Vous ne savez pas qui a modifié quoi, ni quand
Dès qu'un désaccord surgit sur un chiffre, la question devient : d'où sort cette valeur ? Un tableur partagé donne au mieux un historique global. Une application enregistre qui a changé quoi, quand, et pourquoi. Sur des sujets réglementés, de traçabilité ou de facturation, ce point cesse d'être un confort.
6. Le fichier est devenu lent, lourd ou fragile
Quelques dizaines de milliers de lignes, des formules matricielles, des liens vers d'autres classeurs : le fichier met vingt secondes à s'ouvrir et plante une fois par semaine. C'est le signal le plus tardif, et souvent celui qui déclenche la décision. Idéalement, on n'attend pas celui-là.
Le bon moment n'est pas quand le tableur devient pénible. C'est quand les règles qu'il contient sont enfin stables, et qu'elles méritent d'être écrites quelque part où elles ne se perdront pas.
Ce qu'une application change réellement
Beaucoup de projets déçoivent parce qu'on en attend la mauvaise chose. Une application métier ne rend pas votre processus meilleur : elle le rend explicite, contrôlé et partageable. Si le processus est mauvais, vous obtiendrez un mauvais processus, en plus rapide.
- Les règles deviennent explicites : elles sont écrites, testées, modifiables.
- Les droits deviennent réels : chacun voit et modifie ce qui le concerne.
- Les données deviennent fiables : ce qui est invalide n'entre pas.
- L'historique devient consultable : qui, quoi, quand.
- Les autres outils peuvent s'y brancher : facturation, comptabilité, site web.
Ce qu'elle ne change pas
Elle ne remplacera pas la souplesse d'une feuille blanche. Vos équipes continueront d'exporter vers un tableur pour faire une analyse ponctuelle, et c'est très bien. Les meilleures applications métier que nous livrons ont toutes un bouton d'export : ce n'est pas un aveu d'échec, c'est la reconnaissance que le tableur reste imbattable pour explorer.
Par où commencer sans tout casser
L'erreur classique est de vouloir remplacer le tableur en entier, d'un coup. C'est le chemin le plus sûr vers un projet long, cher et abandonné. La méthode qui fonctionne est l'inverse : isoler le morceau le plus douloureux et ne traiter que celui-là.
- Repérez l'étape où le tableur fait le plus mal : la saisie partagée, le calcul opaque, la recopie.
- Écrivez les règles de cette étape en français, sans penser à l'outil. Si vous n'y arrivez pas, le projet n'est pas encore mûr.
- Traitez cette seule étape, mettez-la entre les mains des utilisateurs, et laissez le reste dans le tableur.
- Élargissez seulement une fois que la première brique est adoptée.
Cette progression a un autre mérite : elle vous permet d'arrêter. Si la première brique ne change rien à votre quotidien, vous l'aurez appris pour une fraction du coût d'un projet complet.
Comment nous abordons ce type de projet
Chez Olidian, nous commençons systématiquement par le recueil du besoin et la spécification, avant toute ligne de code. Sur un remplacement de tableur, cette phase consiste largement à faire remonter les règles enfouies dans les formules et dans la tête des utilisateurs. C'est le travail le plus utile du projet, et celui qu'on saute le plus souvent.
Ensuite, nos ingénieurs construisent avec l'aide de nos agents IA, ce qui ramène le délai à quelques semaines plutôt qu'à plusieurs mois. Vous repartez avec le code, la documentation et les accès : si vous décidez un jour de continuer sans nous, rien ne vous retient.