Le tableur n’est pas forcément le problème
Les tableurs sont rapides, flexibles, familiers et peu coûteux. Pour un processus évolutif géré par une ou deux personnes, ils peuvent être parfaitement adaptés. Remplacer un tableur fonctionnel par un logiciel sur mesure ajoute des coûts, de la formation et de la maintenance, sans nécessairement améliorer l’activité.
Le problème apparaît lorsque le tableur doit assumer des fonctions pour lesquelles il n’a pas été conçu : gestion des accès, mises à jour simultanées, suivi des étapes, intégrations, historique des modifications ou service fiable aux clients et aux équipes.
Sept signes qu’il faut revoir le processus
- Les équipes entretiennent plusieurs copies ou ne savent pas quelle version fait foi.
- Le processus dépend de formules, de macros ou du savoir-faire d’une seule personne.
- Le personnel recopie les mêmes informations entre le tableur et d’autres systèmes.
- Les différents rôles ne devraient pas avoir accès aux mêmes informations ni pouvoir les modifier de la même façon.
- Il est difficile de savoir qui a modifié une valeur, validé une étape ou pris en charge l’action suivante.
- Le fichier ralentit, devient fragile ou difficile à tester à mesure que les règles s’accumulent.
- Une erreur peut retarder une livraison, fausser un montant ou compromettre un engagement client.
La matrice de décision à quatre options
| Option | À privilégier lorsque | Principal compromis |
|---|---|---|
| Conserver et améliorer | Volume faible, peu d’utilisateurs, processus en évolution | Contrôle et intégration limités |
| Acheter un logiciel | Processus courant avec des flux standard adaptés | Coût de l’abonnement et adaptation au produit |
| Connecter les outils | Les systèmes existants conviennent, mais les données et les actions ne circulent pas | Responsabilité des intégrations et limites des systèmes |
| Créer un outil ciblé | Le processus est spécifique, important, stable et mal couvert par l’offre existante | Coût initial et responsabilité continue du produit |
Définissez les exigences à partir du travail, pas du tableur
- 01
Résultat
Quel résultat doit être atteint à la fin du processus ?
- 02
Utilisateurs et rôles
Qui crée, vérifie, approuve, administre ou consulte uniquement ?
- 03
Parcours habituel
Que se passe-t-il dans la plupart des cas, du déclencheur au résultat ?
- 04
Exceptions
Quelles variations doivent être prises en charge et lesquelles peuvent rester manuelles ?
- 05
Systèmes
Où se trouve la source de référence, et quelles données ou actions doivent circuler ?
- 06
Traçabilité
Quels historiques, statuts, approbations ou exports l’entreprise doit-elle conserver ?
- 07
Mesure
Quel indicateur de temps, de coût, d’erreur ou de service permettra de mesurer l’amélioration ?
Exemple anonymisé : gérer les approbations au-delà du tableur
Une équipe utilisait un tableur pour suivre des demandes financières et leurs approbations. Les calculs étaient maîtrisables, mais pas le processus autour : les droits d’accès variaient selon les rôles, les justificatifs étaient stockés ailleurs, les statuts étaient mis à jour manuellement et personne ne disposait d’un historique d’audit fiable.
Acheter une plateforme généraliste aurait obligé l’entreprise à modifier bien plus que le processus ciblé. Connecter les systèmes n’aurait résolu qu’une partie du problème. Un outil interne ciblé se justifiait, car le processus était stable et les conséquences importantes. Son périmètre est resté restreint : demandes, approbations selon les rôles, historique d’audit et intégrations requises.
Les éléments à inclure dans la décision de développement
- La découverte et la définition du processus, pas seulement le développement de l’interface.
- L’authentification, les droits d’accès, la revue de sécurité, les sauvegardes et la traçabilité.
- La migration des données et l’intégration aux systèmes existants.
- Les tests, le déploiement, la formation et une procédure manuelle de secours.
- L’hébergement, la supervision, le support, la mise à jour des dépendances et les évolutions futures.
- Le coût d’opportunité du temps des équipes internes chargées de prendre les décisions.
Quand ne pas créer d’outil interne
Ne développez pas d’outil si un produit pris en charge répond aux exigences importantes, si personne n’est responsable du processus, si les règles changent chaque mois ou si l’organisation ne peut pas assurer la maintenance. Évitez un remplacement complet lorsqu’une intégration ou une petite interface opérationnelle suffit à résoudre l’essentiel du problème.