Top 5 des erreurs à ne pas faire avec Google Spreadsheet

Introduction

Google Spreadsheet est un outil gratuit de la suite Google Docs Editors qui permet le travail collaboratif sur des tableurs. Vu que cet outil est très utilisé en entreprise comme son homologue Excel pour la prise de décision business stratégique, il faut prévoir les différents scénarios d’investigation et de reprise en condition opérationnelle. Afin de ne pas créer un monstre, voici quelques erreurs à ne pas faire lorsqu’on travaille sur Google Spreadsheet.

Stocker des données sources importantes et changeantes

Imaginez que votre tableur dure plusieurs mois, et qu’en fin d’année vous vous apercevez qu’il y a un problème dans vos données. Imaginez encore que ces données que vous chérissez soient modifiées chaque semaine par une dizaine de personnes différentes et que vous n’ayez aucun moyen de savoir depuis quand ce problème existe et quelle est la cause de ce problème.
Ce type de problème a causé des maux de tête et des week-ends gâchés à plus d’un et si vous voulez partir serein en week-end vous n’avez pas envie que ce problème vous arrive.

Un Google Spreadsheet n’est pas l’outil que vous souhaitez avoir pour stocker des données. Spreadsheet est un outil très permissif et une suppression de ligne est vite arrivée. Pour stocker des données il vous faut une base de données. Si vous avez des données qui évoluent et que vous voulez garder la trace de tous les changements qui s’effectuent sur vos données, il vous faut une base de données événementielle.

Mais il est pratique de travailler en commun et d’écrire dans un Google Spreadsheet, personne n’a envie d’écrire dans une base de données. Et si la donnée est modifiée dans la base de données, il faut qu’elle soit synchronisée rapidement avec le Google Spreadsheet, pour la fluidité de travail et le fait de pouvoir tester sans attendre 5 minutes entre chaque test.
Si la donnée est saisie dans le google Spreadsheet, comment la récupérer et la mettre dans une base de données ? Et inversement comment synchroniser depuis une base de données vers un Spreadsheet en temps réel ?
Je n’ai pas encore les réponses à ces questions et cela fera l’objet d’un prochain article :).

Développer beaucoup de formules complexes et les utiliser à plusieurs

Imaginez que quelqu’un a conçu des formules dans un Google Spreadsheet très complexe et que cette personne ne transmette pas la connaissance et démissionne. Imaginez maintenant que les utilisateurs de ce Google Spreadsheet ont de la méfiance envers ces formules et demandent à un Data Manager de leur expliquer ces formules. Imaginez encore que ces formules qui sont compliquées utilisent des cellules contenant elles-mêmes des formules compliquées qui utilisent elles-mêmes d’autres cellules avec des formules compliquées etc..
Imaginez pour terminer que vous devez expliquer ces formules à une quinzaine de personnes en direct en réunion.

Pour éviter les maux de tête du Data Manager et pour éviter la méfiance des utilisateurs, vous ne voulez pas faire des formules compliquées dans un Google Spreadsheet.
Si vous voulez faire des calculs complexes, vous voulez les faire dans du code documenté ou dans des procédures stockées en base de données loin de la vue des utilisateurs.
Et vous voulez donner une assurance aux utilisateurs sur l’intégrité de ces calculs. Si l’utilisateur soupçonne une erreur ponctuelle alors vous pouvez le rassurer en montrant que cette valeur est restée constante sur une longue période de temps. Si l’utilisateur soupçonne une erreur globale alors il a besoin qu’on lui donne une explication détaillée, ce qui sera d’autant plus facile si le calcul est simple.

Ne mettez dans les Google Spreadsheet que des formules simples qui s’expliquent en moins de 10 secondes. Pour les formules complexes, stocker l’évolution des résultats dans une base de données temporelle, afficher dans un outil de visualisation l’évolution des résultats de ces formules avec la liste des événements associés à la variation de ces résultats. Mettre dans le Google Spreadsheet en commentaires aux différents endroits des résultats des formules complexes les liens vers les visualisations précédentes et une explication détaillée du calcul que les utilisateurs pourront refaire.

Faire des jobs d’alimentation de données dans les SpreadSheets lourds et non re-jouables

Imaginez que vous avez un job d’alimentation qui va mettre à jour des données dans votre Google Spreadsheet. Imaginez que ce job met 10 minutes à s’exécuter. Imaginez que ce job s’exécute automatiquement une seule fois par jour et que si les utilisateurs veulent un rafraîchissement alors ils doivent contacter un Data Manager pour lancer le job. Imaginez qu’on a des données par projet client, que vos utilisateurs ont besoin de rafraîchir les données d’un client en particulier mais sont obligés d’attendre le rafraîchissement des données sur l’ensemble des clients. Imaginez que vos utilisateurs modifient les données toutes les 2 minutes sur un client différent et rafraîchissent les données du Google Spreadsheet après chaque modification.

Une des forces des Google Spreadsheet est la fluidité entre la modification de données et l’affichage des résultats de calcul. Lorsque vos utilisateurs modifient des données, même en dehors de Google Spreadsheet, ils s’attendent à ce que leurs modifications soient prises en compte rapidement dans l’affichage du Google Spreadsheet.
Et aussi un Google Spreadsheet est un outil qui prête au travail collaboratif, il y a de fortes chances que vos utilisateurs effectuent des modifications en parallèle et veuillent effectuer des rafraîchissements des données du Google Spreadsheet en parallèle.

• Pour alimenter votre Google Spreadsheet depuis une base de données, vous allez devoir mettre en place un script appelé par un orchestrateur de workflow.
• Pour la rapidité et la fluidité, votre script doit être capable de rafraîchir votre Google Spreadsheet morceau par morceau au lieu de l’entièreté. Chaque morceau doit pouvoir être rafraîchi indépendamment des autres tout en gardant la cohérence du Google Spreadsheet. A vous de déterminer la granularité associée au rafraîchissement de votre Google Spreadsheet en fonction de la cohérence des données et des besoins utilisateurs.
• Pour le stockage des requêtes de rafraîchissement en parallèle, vous pouvez mettre en place une structure de donnée de type message queue pour stocker les rafraîchissements à effectuer sur le Google Spreadsheet avec les morceaux associés et dans l’ordre d’arrivée.
• Pour l’ingestion des requêtes de rafraîchissement, vous pouvez créer une fonction Google App Script qui va rajouter une icône dans le menu de votre Google Spreadsheet, qui va permettre aux utilisateurs de cliquer sur l’icône rafraîchissement du menu et de renseigner un identifiant du morceau de donnée à rafraîchir et qui va ajouter cet identifiant dans la message queue de rafraîchissement.
• Pour l’exécution de vos jobs de rafraîchissement, vous pouvez créer un ou plusieurs workers qui vont piocher régulièrement dans la message queue et qui vont rafraîchir les morceaux de données concernés.
  Vos rafraîchissements de données doivent s’exécuter en moins de 30 secondes après requête si vous voulez garantir un minimum de fluidité d’expérience utilisateur. Une solution serait que les workers piochent dans le message queue toutes les 20 secondes et mettent moins de 10 secondes pour interroger la base de données et mettre à jour le Google Spreadsheet.

Ne pas versionner la matière applicative

Imaginez que les utilisateurs souhaitent ajouter de nouvelles formules dans le Google Spreadsheet. Imaginez que des utilisateurs aient supprimé des colonnes ou des lignes ou des cellules et que les formules du Google Spreadsheet soient cassées. Imaginez que les utilisateurs vous demandent de remettre des formules comme avant.

Vous ne voulez pas ne pas versionner les formules de votre Google Spreadsheet et devoir retenir de tête les formules en cas de perte du Spreadsheet ou de rollback.

L’outil de référence pour le versionning est git. Vous pouvez mettre en place du CI-CD pour faciliter le déploiement de la matière applicative sur le Google Spreadsheet. Vous pouvez aussi mettre en place du semantic versionning et un changelog pour expliquer l’évolution des formules du Google Spreadsheet.
Une bonne pratique est aussi d’interdire les modifications sur les cellules concernant les formules de votre Google Spreadsheet.

Connecter beaucoup de Google Spreadsheet avec des importranges

Imaginez que vos utilisateurs ont beaucoup de Google Spreadsheet et souhaitent centraliser des données en provenance de ces Spreadsheet à un seul endroit. Imaginez qu’un seul Google Spreadsheet importe des données depuis plusieurs Google Spreadsheets. Imaginez qu’à chaque modification sur le Google Spreadsheet central, le document devienne indisponible pendant plusieurs minutes car les différentes formules importrange sont recalculées.
Imaginez aussi que vous voulez modifier des colonnes dans un Google Spreadsheet mais que ça a un effet de bord sur un autre Google Spreadsheet à cause d’un importrange.

Vous voulez avoir un Google Spreadsheet avec une expérience fluide et des calculs rapides ce qui est incompatible avec la présence de plusieurs importrange. Vous voulez aussi éviter les effets de bord lorsque vous développez de nouvelles formules ou vous arrangez les colonnes.

Comme expliqué précédemment, Google Spreadsheet n’est pas l’outil adapté pour stocker des données. SI vous avez besoin de données présentes dans un Google Spreadsheet alors vous devriez avoir accès à ces données dans une base de données. Mais dans le cas où vous avez des données stockées dans des Google Spreadsheets, il faut faire un export régulier des données de ces documents dans un lac de données et rendre accessible ces données . Nous ferons un article prochainement sur le lac de données.

Conclusion

Google Spreadsheet est un outil adapté pour faire du reporting et des calculs ponctuels. Si vous voulez faire un outil collaboratif et durable, alors Google Spreadsheet a des limites et on ne peut pas se passer d’autres outils de base de données et de visualisation plus avancés. Il reste des questions non répondues et qui feront l’objet de prochains articles.