Dans beaucoup d’équipes, le même rituel se répète. Un collègue ouvre un tableur, cherche la bonne ligne, filtre une colonne, hésite devant une formule, puis envoie un message : « Tu peux me confirmer que c’est bien à jour ? » Le fichier contient pourtant tout : les clients, les demandes, les responsables, les échéances, les documents. Il manque seulement une chose essentielle : une porte d’entrée intelligible.
C’est précisément l’intuition derrière Stacker et, plus largement, toute une famille d’outils apparus à la frontière du no-code, de la base de données et de l’organisation du travail. Leur promesse n’est pas de rendre la feuille de calcul plus jolie. Elle consiste à transformer des données déjà présentes en une expérience d’usage : un espace où chacun voit ce qui le concerne, agit sur ce qu’il est autorisé à modifier et comprend ce qu’il doit faire ensuite.
Le sujet dépasse donc largement un logiciel particulier. Stacker est intéressant comme symptôme d’un basculement : celui où le tableur cesse d’être seulement un fichier manipulé par des experts pour devenir le moteur discret d’une interface métier.
Le tableur n’est pas un mauvais outil, il est souvent trop exposé
On a pris l’habitude de moquer les feuilles de calcul tentaculaires, leurs onglets aux noms opaques et leurs cellules colorées selon des codes que plus personne ne maîtrise vraiment. Pourtant, le tableur a de remarquables qualités. Il est souple, immédiat, peu intimidant. Il permet à une équipe de formaliser une activité sans attendre l’intervention d’un service informatique ou le lancement d’un grand projet logiciel.
Le problème commence quand ce support artisanal devient l’infrastructure de fait d’un processus important. Une équipe commerciale y suit ses opportunités. Une association y organise ses bénévoles. Un studio de création y centralise ses productions. Une entreprise de services y coordonne ses missions et ses livrables.
À ce stade, la feuille de calcul doit répondre à des demandes pour lesquelles elle n’a pas été conçue :
- permettre à des personnes différentes de ne voir que leurs informations ;
- guider une action sans exiger la maîtrise des filtres et des formules ;
- réduire les erreurs de saisie ;
- offrir une lecture claire de l’avancement ;
- relier des fiches, des documents, des demandes et des responsabilités ;
- préserver une source de vérité partagée.
Un tableur ouvert à tous est souvent un compromis entre transparence et vulnérabilité. Pour que chacun puisse travailler, chacun accède à beaucoup plus d’informations qu’il n’en a besoin. Pour éviter les erreurs, on verrouille des colonnes ; mais l'outil devient alors frustrant. Pour mieux expliquer son fonctionnement, on ajoute des onglets d’instructions ; mais leur lecture suppose déjà de savoir naviguer dans le fichier.
Le paradoxe est là : plus une feuille devient essentielle, moins elle devrait ressembler à une feuille.
La bascule décisive : séparer les données de leur mise en scène
Stacker a popularisé une idée devenue centrale dans les outils de travail contemporains : les données et l’interface ne sont pas la même chose. Les premières constituent la matière brute. La seconde organise ce que les utilisateurs peuvent voir, comprendre et faire.
Cette distinction paraît abstraite jusqu’à ce qu’on la traduise en situations concrètes. Une même base peut contenir les dossiers de tous les clients. Mais un responsable de compte n’a pas besoin d’ouvrir une grande grille pour retrouver ses dossiers : il lui faut une liste filtrée, des alertes, des étapes à valider et une fiche claire. Le client, lui, peut avoir besoin d’un portail où déposer un document et suivre l’état de sa demande, sans jamais accéder aux notes internes. La direction cherchera plutôt une vue synthétique des activités en cours.
Les données sont identiques ; les usages ne le sont pas.
Cette logique s’oppose à une vieille habitude numérique : donner accès au fichier et espérer que les utilisateurs sauront s’en servir. Une application construite au-dessus d’une base adopte l’approche inverse. Elle part des rôles, des tâches et des décisions à prendre. Elle rend visible ce qui est pertinent et dissimule ce qui ne l’est pas.
Une bonne application ne montre pas toutes les informations disponibles ; elle rend l’action suivante difficile à manquer.
Voilà pourquoi l’expression « transformer un tableur en application » est plus juste qu’elle n’en a l’air. Il ne s’agit pas seulement d’ajouter des boutons ou des couleurs. Il s’agit de passer d’un document polyvalent à un environnement orienté vers une activité précise.
Le vrai produit, ce sont les règles invisibles
Quand une équipe construit son premier outil sur une base existante, elle pense souvent aux écrans : un tableau de bord, une page client, un formulaire, peut-être un graphique. C’est naturel, mais ce n’est pas le cœur du travail. La valeur se niche dans les règles invisibles.
Qui peut créer un dossier ? Qui peut le modifier ? Que se passe-t-il lorsqu’une demande est incomplète ? À quel moment une tâche change-t-elle de responsable ? Quel statut signifie réellement qu’un projet est terminé ? Ces questions relèvent du workflow, c’est-à-dire de la circulation organisée du travail.
Les outils comme Stacker mettent cette couche en évidence. Pour fabriquer une interface utilisable, il faut expliciter les règles que l’équipe appliquait jusque-là par mémoire, par messages instantanés ou par habitude. Cette formalisation est parfois inconfortable. Elle révèle les zones grises : deux personnes pensent être responsables du même sujet ; un statut recouvre plusieurs réalités ; une information est saisie à plusieurs endroits ; une étape n’est déclenchée que parce qu’une personne vigilante y pense.
Ce n’est pas un défaut de l’outil. C’est plutôt un diagnostic. Un mauvais processus devient plus visible lorsqu’on tente de l’automatiser ou de l’habiller d’une interface. La technologie ne crée pas toujours le désordre : elle l’expose.
Les droits d’accès constituent un autre révélateur. Ils sont souvent envisagés comme une contrainte administrative, alors qu’ils définissent une forme de civilité organisationnelle. Donner à chacun la bonne vue, c’est éviter à la fois la curiosité involontaire, la surcharge d’informations et la crainte de casser quelque chose. Une interface bien conçue dit implicitement : voici votre périmètre, voici ce qui dépend de vous, voici ce que vous pouvez transmettre aux autres.
Une application légère n’est pas un petit logiciel
Il serait tentant d’opposer ces plateformes aux logiciels conçus sur mesure, comme si les premières étaient des versions simplifiées des seconds. La comparaison est trompeuse. Une application légère répond à un autre besoin : accélérer l’apprentissage d’une organisation sur elle-même.
Dans un logiciel traditionnel, il faut souvent spécifier longuement les besoins avant de développer. Dans une approche plus modulaire, l’équipe peut essayer une structure, constater que le vocabulaire est mal choisi, modifier une étape, ajouter une relation entre deux types d’objets. Cette souplesse est précieuse quand le processus évolue encore ou quand il dépend fortement du terrain.
Mais la vitesse n’est pas une garantie de pertinence. Le piège du no-code consiste à confondre facilité de fabrication et facilité de maintenance. Un outil construit rapidement peut devenir aussi opaque qu’un tableur ancien s’il est alimenté par des règles improvisées, des champs redondants et des exceptions accumulées.
La bonne question n’est donc pas : « Peut-on créer cette application sans développeur ? » Elle est plutôt : « Qui comprendra encore ses règles lorsque les personnes qui l’ont créée seront parties ? »
Avant de bâtir, dessiner la scène de travail
Pour éviter de fabriquer un portail décoratif ou une base de données déguisée, il est utile de commencer par la scène de travail réelle. Non pas par les colonnes existantes, mais par les gestes quotidiens.
- Quelle personne arrive avec une information ou une demande ?
- Quelle décision doit-elle prendre ?
- De quelles données a-t-elle besoin à cet instant précis ?
- Quelle personne prend le relais ?
- Qu’est-ce qui doit rester traçable ?
- Qu’est-ce qui doit rester invisible pour certains rôles ?
Cette enquête conduit souvent à distinguer plusieurs objets qui étaient mélangés dans un même onglet : un contact n’est pas un projet ; un projet n’est pas une tâche ; une tâche n’est pas un livrable ; un livrable n’est pas une conversation. Les séparer ne signifie pas compliquer la base. C’est au contraire rendre les relations plus lisibles.
Vient ensuite le choix d’un périmètre modeste. Une première version réussie ne cherche pas à numériser toute l’organisation. Elle améliore un passage particulièrement pénible : l’accueil d’une demande, le suivi d’un dossier, la validation d’un contenu, la coordination d’intervenants. Si ce segment devient plus clair, plus fiable et plus agréable, l’outil a déjà prouvé son utilité.
Ce que Stacker nous apprend du travail contemporain
Le cas Stacker raconte une transformation plus profonde que l’essor d’une catégorie d’outils. Les équipes ne veulent plus seulement stocker l’information ; elles veulent l’organiser autour de leurs gestes. Elles ne souhaitent pas nécessairement un énorme système d’information, mais elles ont besoin de ne plus dépendre d’un fichier incompréhensible tenu par une seule personne.
La feuille de calcul n’est pas appelée à disparaître. Elle reste un formidable atelier de réflexion, d’exploration et de calcul. Mais lorsqu’elle devient le lieu où plusieurs rôles collaborent, où des décisions sont prises et où des informations sensibles circulent, elle mérite souvent d’être dépassée.
La meilleure application née d’un tableur ne cherche pas à imiter les grandes plateformes. Elle fait quelque chose de plus humble et de plus utile : elle rend un travail collectif visible, praticable et transmissible.
