- Dans un environnement business en phase de démarrage, où les changements sont fréquents, il est plus judicieux de résoudre rapidement les problèmes avec la solution la plus simple, puis de réévaluer les besoins pour remplacer ou renforcer l’outil lorsque ses limites apparaissent
- Google Sheets est un moyen efficace de résoudre des problèmes dans un contexte qui évolue vite, et présente, par rapport au développement d’outils complexes, de meilleurs avantages en matière d’usage réel et de réduction du gaspillage
- L’auteur revient sur le fait qu’en pratique, il a perdu du temps à créer trop vite des systèmes dédiés plutôt qu’à utiliser des outils génériques, en négligeant l’incertitude sur le périmètre
- L’approche clé consiste à suivre une stratégie démarrer petit et itérer : commencer par la solution la plus petite et la plus simple → comprendre le périmètre à travers le travail réel → améliorer progressivement si nécessaire
- Cela ne veut pas dire que tous les problèmes peuvent être résolus avec un tableur ; il s’agit plutôt d’un usage temporaire jusqu’à ce que le périmètre devienne clair, avec une sélection réfléchie adaptée au contexte de l’organisation
Le choix le plus simple pour résoudre un problème
- Quel que soit le problème, il est important de choisir d’abord la solution la plus facile à mettre en œuvre
- Quand cette méthode cesse d’être adaptée au business, il faut améliorer la solution existante ou chercher une alternative en fonction des nouveaux besoins
- Dans l’environnement de l’auteur, créer une nouvelle Google Sheet était dans la plupart des cas la meilleure approche
Un environnement startup en évolution rapide et l’utilité des outils
- En rejoignant son entreprise il y a environ neuf mois, l’auteur a vite perdu son enthousiasme à l’idée de créer de nouveaux outils et services pour une petite entreprise encore au tout début
- Dans un contexte où l’orientation du business change tous les deux mois, de nombreux projets ont été lancés puis abandonnés
- Dans bien des cas, il aurait été possible de résoudre le problème facilement avec Google Sheet, mais du temps et des efforts ont été investis dans des projets inutilement complexes
Exemples de temps perdu
-
Panneau d’administration pour la gestion du fret
- 2 mois ont été consacrés à la conception et au développement d’un panneau d’administration pour gérer et suivre les cargaisons entrantes de l’entreprise
- L’objectif était d’aider à classer les colis et les données clients pour mieux les gérer
- Ce panneau d’administration a été utilisé deux fois, puis plus jamais
- Il aurait facilement pu être remplacé par un Google Sheet, qui est d’ailleurs utilisé aujourd’hui pour cette tâche
-
MVP de calcul automatique des droits de douane
- 3 semaines ont été consacrées à créer un MVP de système de devis capable de calculer automatiquement les droits de douane et taxes pour certaines commandes
- Les taxes et droits de douane au Zimbabwe étant très complexes, connaître à l’avance le montant exact à payer permettait d’offrir un meilleur parcours client et d’accélérer le processus sans attendre les réponses à toutes les demandes adressées à un prestataire tiers chargé des formalités douanières
- Au final, il a suffi de consulter le tableau de classification des taxes et droits de douane d’un concurrent et de le copier dans Google Sheet
-
Le processus de choix d’un CRM
- 2 mois ont été consacrés à des recherches, des réunions de plus d’une heure et des comparaisons pour trouver un bon CRM pour l’entreprise
- L’auteur a longuement comparé les fonctionnalités et les tarifs de différents CRM
- Au final, l’entreprise a choisi la version gratuite d’Oddo, mais elle a été peu utilisée en interne
- Plus surprenant encore, il a découvert il y a quelques semaines qu’un modèle CRM est intégré à Google Sheets
Les principes de l’approche Google Sheets
- Créer un Google Sheet n’est pas toujours la meilleure solution à tous les problèmes, mais dans la situation de l’auteur, c’est souvent le cas
- Il se retrouve fréquemment dans des situations où il est impossible de connaître l’étendue complète du problème avant de commencer réellement le travail
- Cela ne signifie pas qu’il ne faut pas planifier les projets
- L’équipe doit discuter du workflow et des informations nécessaires, mais il est impossible de connaître tout le périmètre du problème avant de commencer réellement
- Une fois le périmètre complet identifié, on peut commencer à construire ou à améliorer la solution dont on dispose
- Dans le meilleur des cas, cette méthode évite le surcroît de travail lié à l’ajout de fonctionnalités inutiles ; dans le pire des cas, elle évite de passer du temps sur un projet voué à l’échec
- Jusqu’ici, la meilleure manière de comprendre toute l’ampleur d’un problème a été de mettre en place la solution de base la plus petite et la plus simple, puis d’itérer si nécessaire
Limites et points de vigilance
- Cette approche a aussi ses inconvénients : dans certaines organisations, par exemple, des tableurs de plusieurs milliers de lignes servent à enregistrer toutes les transactions et toutes les informations
- Google Sheets n’est vraiment utile qu’avant d’avoir une vision complète du problème
- Il faut de l’expérience et du jugement pour savoir quels problèmes peuvent être résolus avec Google Sheet
- L’important est de privilégier le développement d’outils réellement utilisés, sans gaspiller de temps
- Mais ce n’est pas un conseil universel : chacun doit évaluer sa situation avec prudence
Conclusion
- Commencer par l’effort minimal et la solution la plus simple, puis n’étendre ou ne sophistiquer l’outil qu’en cas de besoin, est une stratégie particulièrement adaptée aux startups et aux environnements très changeants
- Les expérimentations de développement personnelles sont libres, mais dans le business, il est essentiel de ne construire que ce qui est vraiment nécessaire et de ne pas gaspiller du temps ni de l’énergie dans des tâches inutiles
3 commentaires
Je suis globalement d’accord moi aussi, mais à ce stade je préfère utiliser Notion Database comme base de référence initiale plutôt que Google Sheets. C’est similaire, mais de toute façon une seule personne configure le template. Si les autres gèrent ensuite les données sur cette base, on peut éviter que la situation devienne chaotique. Ce n’est pas au niveau d’Apps Script, mais l’automatisation est aussi plus facile à mettre en place. La difficulté de configuration initiale est peut-être très légèrement plus élevée, mais pas de beaucoup, et la flexibilité me semble comparable. En plus, avec la gestion récente des permissions au niveau des lignes, c’est top.
Je trouve que Notion est bien parce que sa courbe d’apprentissage est peu élevée.
Avis sur Hacker News
C’est un point qu’on sous-estime toujours. Un tableur réunit au même endroit une base de données, une UI rapide et facile à personnaliser, ainsi qu’un environnement de traitement de données itératif et facile à déboguer. C’est un outil que tous les salariés du monde comprennent et utilisent déjà, et il offre aussi aux créateurs la liberté de mettre en œuvre exactement ce qu’ils veulent. La portabilité est excellente également. Je suis convaincu que c’est un outil particulièrement créatif et puissant pour les personnes qui ne savent pas coder. Bien sûr, cette liberté a aussi ses inconvénients, mais malgré les débats sur le fait qu’il soit en ligne ou non, ou sur le meilleur fournisseur, mon attachement profond aux tableurs n’a pas diminué d’un pouce. Je pense que c’est le meilleur outil de création que nous ayons jamais conçu. Le modèle le plus proche du tableur serait HyperCard. C’était un établi flexible qui permettait de relier diverses apps, données et UX. J’aimerais qu’HyperCard soit rappelé pour toujours
Oui, les tableurs ont vraiment une barrière à l’entrée très basse. Il m’arrive même de saisir au milieu d’un champ, sur mon téléphone, les relevés de croissance des cultures dans Google Sheets. Même quand le réseau est faible, je les enregistre en mode hors ligne puis ça se synchronise quand je rentre chez moi. Même si les données sont un peu en désordre, c’est largement mieux que de ne rien avoir. L’agriculture demande énormément de données, mais c’est étonnamment un environnement qui en manque. Le cycle d’apprentissage est long, à l’échelle d’une année, et aucune année ne se ressemble
Pour les gens qui savent coder, Appscript transforme presque les tableurs en superpouvoir. Pour ceux qui ne le savent pas, on n’est pas obligé d’écrire uniquement du JS dans l’IDE web intégré à Google Sheets (même si, en vérité, c’est déjà assez utile). Avec
clasp, on peut développer en Typescript dans un IDE local, compiler en JS pendant le build, puis déployer directement dans le tableur. Une fois la toolchain en place, l’expérience de développement (DX) est franchement correcteTout à fait d’accord. La valeur d’un établi intégré où base de données + UX + logique ne font qu’un est au cœur des apps que nous recréons sans cesse. C’est aussi pour ça que Visual Basic est encore utilisé. Bien sûr, ce n’est pas la meilleure solution une fois la direction clairement définie, mais pour itérer rapidement et découvrir les vrais besoins, c’est difficile de faire mieux
J’aimerais qu’on puisse mieux utiliser les tableurs comme backend de base de données. Une grande partie de ce que la plupart des gens font avec des tableurs serait mieux gérée par une base de données. Mais les bases de données demandent plus de formation, et sans cette formation, on peut obtenir des résultats encore pires qu’avec un tableur
Je me suis toujours demandé pourquoi il n’existe pas de trajectoire de transition réaliste pour passer progressivement d’un tableur à une véritable base de données avec UI personnalisée. Le tableur est juste l’étape précédente à ce rôle, et avec quelques fonctionnalités essentielles seulement (données structurées, SQL natif, éléments d’UI personnalisés, intégration IDE, etc.), ça semblerait tout à fait possible
Cela m’a rappelé le post « Ask HN: Is the world run by badly updated Excel sheets? ». Il faut de l’expérience pour rencontrer directement les limites des tableurs. Pas de contrôle de version, pas de tests. C’est très bien pour des tâches courtes et stables, mais si ça doit évoluer en continu, ça devient problématique. Voir https://news.ycombinator.com/item?id=33611431. Il y avait ce commentaire dans ce fil : au final, dans une entreprise, tout le monde s’adapte à la manière de faire du propriétaire d’Excel. Si ça ne plaît pas, il suffit de créer son propre nouvel Excel et d’y faire un copier-coller, donc chacun gère de son côté. Un chef de projet que je connais passait son quotidien à coordonner plusieurs versions de tableurs écrites par différents auteurs
Quand j’ai commencé comme développeur aux États-Unis dans les années 2000, j’avais l’impression que mon travail consistait à transformer en webapps des tableurs sur des lecteurs réseau Windows dont quelqu’un devait toujours prendre soin. Malgré tout, beaucoup d’entreprises fonctionnent encore très bien sur des tableurs. À un moment, on finit forcément par heurter un problème de passage à l’échelle, et il faut alors migrer vers une app, mais mieux vaut faire quelque chose que ne rien livrer du tout en cherchant la perfection
On a dit « il n’y a pas de contrôle de version », mais en réalité Excel a bien des fonctions de contrôle de version. Avec le suivi des modifications, on peut approuver ou rejeter les changements des autres. Cela dit, les gens qui utilisent des automatisations de tableurs façon Rube Goldberg s’en servent rarement. Mais si on en a besoin, c’est possible
J’ai souvent vu des problèmes apparaître quand l’information était dispersée dans plusieurs tableurs. Les participants ne savent souvent pas quel tableur contient quelle information, ni lequel fait autorité. On se retrouve donc fréquemment avec quelqu’un qui met à jour uniquement le fichier A sans que les autres le sachent, pendant qu’un autre ne touche qu’au fichier B. Le vrai problème n’était pas tant le programme ou les données, mais la manière de gérer les fichiers dans le projet. Ça devient un labyrinthe de gestion entre dossiers partagés complexes et fichiers abandonnés quelque part sur le réseau
Je suis d’accord avec le conseil : « utilise toujours la méthode la plus simple pour résoudre le problème, puis quand elle ne correspond plus au besoin métier, améliore-la ou cherche une solution alternative en fonction des nouvelles exigences ». Il faut se concentrer sur la résolution du problème présent ; essayer d’anticiper à l’avance des problèmes futurs, réels ou imaginés, est très difficile à faire juste. La solution actuelle peut devenir inadaptée plus tard, mais il est difficile de prévoir de quelle manière elle le deviendra
Il est difficile de prédire comment une solution deviendra inadaptée à l’avenir, mais on peut tout de même choisir une solution actuelle qui ne bloque pas ou n’entrave pas les solutions futures. Mieux vaut garder des options ouvertes et éviter de se retrouver enfermé chez un fournisseur sans possibilité de sortie
Un cas classique et prévisible d’inadaptation, c’est lorsqu’on devient totalement dépendant d’un fournisseur et qu’on finit expulsé du service ou forcé d’accepter des tarifs de plus en plus élevés. C’est un problème tout à fait prévisible
Si l’on résout un problème d’une manière qui couvre l’ensemble du domaine, sans faire beaucoup plus de travail, on peut absorber des exigences changeantes avec seulement de petites modifications, ce qui rend la solution plus robuste. Cela permet naturellement de couvrir aussi des problèmes futurs
Je travaille dans une grande entreprise américaine très connue. Notre service dépend énormément de deux tableurs. Ils ont survécu à trois fusions-acquisitions touchant mon usine. Quand je suis arrivé il y a sept ans, c’étaient déjà de vieux formats. Il y a deux ans, un nouveau manager a essayé de migrer cela vers un système à l’échelle de l’entreprise, mais il a échoué, et ce système devrait d’ailleurs bientôt être remplacé par un autre. Mais je pense qu’en 2027, on utilisera toujours ces tableurs
Je suis un ancien employé de Google. Pendant cinq ans, j’ai géré tous mes projets avec Sheets (appelé en interne Trix) : gestion de projet, CRM, planification trimestrielle, reporting, entretiens, finance, tout. Ce n’était pas simplement parce que c’était un produit Google (on utilisait aussi largement des produits concurrents). C’était surtout parce qu’on pouvait construire quelque chose d’assez bon pour atteindre l’objectif extrêmement vite, ce qui permettait de se concentrer sur l’essentiel du travail
À propos de l’avis de quelqu’un disant « je suis en poste depuis 9 mois », je trouve qu’il faut un certain culot pour avoir une opinion aussi tranchée avec même pas un an d’expérience, qu’elle soit juste ou non. Ce que l’OP a manqué, c’est la vérité selon laquelle « rien n’est plus permanent qu’une solution temporaire ». On peut certes choisir une solution rapide et improvisée à court terme, mais seulement si l’on contrôle entièrement le cycle de vie de cette solution. Si on a bricolé quelque chose à la demande de quelqu’un, puis qu’on commence à lui ajouter de nouveaux usages de façon continue… alors je défendrai fermement un outil dont le coût initial est un peu plus élevé
J’ai presque éclaté de rire en lisant le « une fois tous les quelques mois… » de ce problème. L’auteur a bien vu que le principe de base est de faire le travail avec des outils simples. Si on peut utiliser l’outil existant tel quel et qu’il répond correctement au besoin, c’est évidemment préférable. Dans la réalité du terrain, les besoins métier changent tous les quelques mois, donc on peut effectivement ne jamais voir se produire le phénomène de la « solution temporaire devenue permanente ». Mais pour la plupart des gens, on finit quand même par payer la dette accumulée des années plus tard, et le scénario du « on le réécrira quand ce sera nécessaire » fonctionne presque jamais. Et l’auteur n’a pas encore vécu ce que ça donne au bout d’un an, ou davantage
Moi aussi, c’est surtout le passage sur « tous les quelques mois… » qui m’a marqué. Je me demande s’il parle après l’avoir vécu quatre fois environ
Pour ceux qui en ont assez des énormes tableurs, MS Access était une solution assez valable. Cela ajoutait de la structure et de la maintenabilité au tableur tout en conservant l’accessibilité et une difficulté de développement raisonnable. On pouvait créer de très bonnes UI sans grande connaissance en programmation. Vingt ans plus tard, je ne sais toujours pas vraiment quelle solution a remplacé Access
Je suis entièrement d’accord avec l’OP. J’ajouterais une chose : quand les besoins deviennent trop complexes pour Google Sheets, Google Colab (ou un notebook Jupyter) est l’étape supérieure. Avant de construire une vraie app, je me pose toujours ces questions : 1. Est-ce que ça peut être simplement un tableur ? 2. Sinon, est-ce qu’un notebook Jupyter suffit ? À noter aussi que l’intégration entre Sheets et Colab est excellente
À mon avis, un notebook Jupyter est un cran bien plus complexe que le simple fait d’écrire un script Python. On peut aussi commenter un script Python, et je ne suis pas fan de cette approche qui consiste à « laisser tourner un serveur web local et exécuter le code bloc par bloc pour voir les commentaires »
Je me demande comment on fait concrètement pour faire évoluer quelque chose qui existait dans un google sheet vers un notebook Colab. Avec le package Python
gspread, on peut lire les données brutes de la feuille, mais il semble difficile de récupérer tel quel dans un notebook Jupyter les graphiques existants ou les éléments interactifs. Il faut probablement tout reconstruireGoogle Apps Script est aussi une bonne alternative. Rien qu’avec de petits scripts simples, pour récupérer des données par exemple, on peut déjà faire beaucoup de choses
L’un des plus gros problèmes de l’automatisation métier est l’écart entre ce qu’on appelle la shadow IT, les plateformes low-code, et les projets pleinement « officiels ». Il manque un chemin de migration convenable entre « bricoler quelque chose avec un Google Form » et « monter une app React avec CI/CD, tests et CDN ». Entre les deux, il n’y a souvent que des alternatives en jardin clos, incompatibles entre elles
Je gère toute ma finance personnelle avec Google Sheets. J’ai même construit ma propre UI d’Expense Tracker et j’y ai accumulé plus de 5 000 lignes de dépenses pendant plusieurs années. Récemment, j’ai aussi créé en vibe coding un outil web UI utilisant un Google Service Account, puis je l’ai transformé en PWA pour l’utiliser sur mon téléphone. Pour des usages simples (surtout des applications à une seule personne), Google Sheets suffit largement à la place d’une DB