Pourquoi QuickBooks ne peut pas être stocké sur Google Drive pour plusieurs utilisateurs

Avant d’entrer dans les détails, il est important de comprendre qu’il s’agit d’un concept général que nous pouvons en réalité ramener à la question suivante : “pourquoi les applications client/serveur ou à fichier de base de données partagé ne peuvent-elles pas être stockées sur un stockage synchronisé (par exemple Google Drive, DropBox, NextCloud, etc.) lorsque l’accès n’est pas restreint à un seul utilisateur ?” QuickBooks utilise un mécanisme de fichier de base de données partagé propre aux applications de style années 1980, dans lequel un fichier unique ou un ensemble de fichiers est partagé via un mécanisme de partage de fichiers, et où chaque copie de l’application accède individuellement à ce fichier pour le modifier. Google Drive est un mécanisme de stockage synchronisé : cela signifie qu’il réalise des copies des données d’un emplacement vers un autre. Les personnes travaillant sur le même fichier en même temps peuvent, et le font souvent, écraser les modifications les unes des autres, en partant du principe que ces modifications seront réconciliées manuellement par la suite, ignorées, ou que les utilisateurs seront encadrés afin de les empêcher de travailler simultanément.

Pour certains types d’applications multi-utilisateurs, le stockage synchronisé peut être exploité, mais uniquement dans les cas où l’application peut être verrouillée par le système de stockage afin de n’autoriser les modifications que lorsqu’aucune autre n’existe. Cela exige un niveau d’intégration qui n’est pas réaliste avec une synchronisation de fichiers à usage général. La plupart des systèmes qui procèdent ainsi utilisent un mécanisme de synchronisation intégré soit à la couche base de données, soit à la couche applicative, et non un mécanisme à usage général qui doit fonctionner à l’aveugle. Pour que l’intégrité des données soit préservée avec un stockage synchronisé, il faut qu’une seule personne modifie un fichier à la fois, attende que tous les utilisateurs potentiels aient reçu les mises à jour effectuées après l’“enregistrement” de ce fichier, puis qu’un autre utilisateur puisse modifier ce fichier et répéter le processus. Mais un seul utilisateur à la fois peut travailler sur le fichier et doit recevoir les mises à jour des autres utilisateurs avant d’ouvrir lui-même le fichier en édition. Faute de quoi le système doit demander aux utilisateurs, dans chaque cas, quelles modifications conserver et lesquelles écarter.

Ce processus d’intégrité ne peut être appliqué à un fichier de base de données d’aucune manière réaliste. Le fichier est conçu pour être ouvert et accessible en permanence, et non simplement pour être ouvert, modifié et enregistré rapidement. L’enregistrement n’est pas non plus manuel, ni toujours prévisible. Nous supposons généralement que l’enregistrement se produit en continu pendant l’utilisation, mais la mise en cache peut rendre même ces opérations d’enregistrement impossibles à contrôler manuellement. Or cela est nécessaire pour des raisons de performance.

La confusion vient souvent du fait qu’un utilisateur unique, sans craindre qu’un autre utilisateur accède au système en même temps, peut utiliser un stockage synchronisé, comme Google Drive ou Apple iCloud, comme mécanisme de sauvegarde (il réalise simplement une copie distante de manière automatique) et/ou comme moyen de répliquer le fichier afin que cet utilisateur unique puisse l’utiliser d’abord depuis un emplacement, puis depuis un autre, sans avoir à déplacer manuellement le fichier d’un emplacement à l’autre. Tant que cet utilisateur unique prend suffisamment de temps en se déplaçant d’un emplacement à l’autre pour s’assurer que tout cache a été vidé et que les synchronisations et les verrous se sont achevés, ou qu’il s’assure de ne pas avoir laissé ouverte la première instance de l’application, il peut raisonnablement considérer son système comme sûr (mais ne peut pas le garantir totalement – le mécanisme comporte même alors un risque infime de situations de concurrence). Parce qu’il existe “un moyen” d’utiliser en toute sécurité un stockage synchronisé avec l’application en mode mono-utilisateur, de nombreux comptables ou employés de la finance peu techniques supposeront à tort que l’accès simultané multi-utilisateur, qui est tout à fait différent, fonctionnera également. Cela n’est cependant pas possible.

Ce qui se produit, c’est une situation de concurrence (race condition) entre plusieurs utilisateurs, et vous ne pouvez jamais être tout à fait certain qu’elle ne s’est pas produite. Parfois, les données seront tout simplement erronées et il ne fait aucun doute qu’une situation de concurrence s’est produite, car les chiffres seront extrêmement inexacts. Mais le plus souvent, certaines transactions seront tout simplement perdues même après avoir été vérifiées.

Prenons un exemple. L’Utilisateur 1 est chez lui et saisit un nouveau reçu dans QuickBooks. Cette modification commence à être enregistrée sur l’ordinateur local et, une fois cela terminé, le nouveau fichier commence à être transféré vers Google Drive dans le cloud (en ligne). L’Utilisateur 2 est au bureau et commence pendant ce temps à saisir un règlement client sur une facture. La copie du fichier de données QuickBooks de l’Utilisateur 2 est ouverte et ne peut pas être écrasée pendant son utilisation, de sorte que la copie en cours d’envoi vers Google Drive ne peut pas parvenir à l’Utilisateur 2. Une fois que l’Utilisateur 2 enregistre sa modification, sa copie cherche elle aussi à être envoyée vers Google Drive. Google Drive doit alors faire quelque chose de deux documents qui étaient identiques au départ mais qui comportent désormais deux modifications radicalement différentes, sans qu’aucune des deux copies ne contienne les deux. Il n’a aucun moyen possible de les fusionner ; il peut donc soit accepter l’Utilisateur 1 comme référence et écarter les modifications de l’Utilisateur 2 (par exemple, priorité au premier). Soit accepter les modifications de l’Utilisateur 2 et écarter celles de l’Utilisateur 1 (par exemple, priorité au dernier). Soit, bien entendu, écarter toutes les modifications et n’en accepter aucune. Dans aucun de ces cas les transactions financières de tous les utilisateurs ne sont conservées, même après que ceux-ci les ont enregistrées localement. Soit l’Utilisateur 1, soit l’Utilisateur 2 (voire éventuellement les deux) verront subitement disparaître des données qu’ils croyaient enregistrées. Ajoutez davantage d’utilisateurs, et le problème ne fait que s’aggraver.

Une partie du problème tient au fait que, lorsque l’on travaille au niveau de l’accès aux fichiers et que l’on synchronise et partage les données au niveau du fichier entier, il n’existe aucun moyen de verrouiller un seul enregistrement ou une seule ligne, ni de maintenir les transactions séparées ou de fusionner les modifications. Le fichier est une entité unique et il a changé. C’est tout ou rien. Les différentes applications QuickBooks ne peuvent pas communiquer directement entre elles, ni à travers le fichier de base de données, pour coordonner les écritures, les enregistrements, les lectures, etc., afin de contourner ce problème. Elles sont aveugles et ne peuvent pas savoir que d’autres applications tentent de travailler avec le fichier en même temps, car chacune possède sa propre copie unique du fichier ; il n’y a rien de “partagé” entre elles permettant la communication. Les copies ne sont pas liées les unes aux autres ; il n’y a pas d’état quantique en jeu ici. Et l’on peut alors ajouter les problèmes potentiels liés à l’utilisation d’une ou plusieurs instances de l’application lorsque la connexion Internet est lente ou défectueuse, ou pire, lorsqu’une instance est hors ligne. Il peut y avoir des heures, voire des jours de modifications qui devront en écraser d’autres, ou être écrasées, lorsque la synchronisation finit par se produire. Il est rarement question de millisecondes, mais souvent de jours de données.

La manière dont ce problème est géré, lorsqu’il l’est, par des fichiers partagés localement, comporte plusieurs facettes. Premièrement, il n’existe qu’un seul fichier, et non des copies de ce fichier. Toutes les modifications sont donc disponibles pour toutes les copies de l’application simultanément et instantanément. Lorsqu’une instance de l’application s’apprête à écrire des données dans le fichier, elle utilise un mécanisme de verrouillage et d’alerte similaire à la manière dont les systèmes de fichiers en cluster (Clustered File Systems) permettent aux SAN de fonctionner, où elle peut signaler aux autres instances de l’application qu’une modification est en cours et qu’elles doivent attendre qu’elle s’achève, puis rafraîchir leur copie des données avant de poursuivre. Une seule instance peut écrire et toutes les autres doivent attendre. Il n’y a pas de situations de concurrence, car le verrou est obtenu avant de commencer et libéré une fois terminé. Et toutes les instances ne fonctionnent que tant que les données sont actuellement accessibles ; si la connexion est perdue, elles sont alors dans l’incapacité de poursuivre. Un mécanisme essentiel de protection de l’intégrité des données. Certaines applications poussent ce mécanisme à un niveau encore supérieur et ajoutent des canaux de communication directs (plutôt qu’à travers le fichier partagé) afin de rendre ce processus plus rapide et d’améliorer les performances. Mais peu vont jusque-là car, une fois ce niveau atteint, il est généralement bien plus simple de passer tout bonnement à une application moderne plutôt que de tenter d’adapter de force des systèmes multi-utilisateurs modernes à des conceptions vieilles de plusieurs décennies.

Espérons que cela aura clarifié les raisons pour lesquelles les comptables pensent couramment que les fichiers synchronisés fonctionneront, et pourquoi ils affirment souvent que “cela a marché pour moi” alors qu’ils devraient dire “j’ai eu de la chance” ou “je l’ai utilisé dans un scénario totalement différent qui ne s’applique pas à un environnement multi-utilisateur”, et pourquoi vous pouvez tout à fait utiliser Google Drive, NextCloud, iCloud, DropBox et bien d’autres avec QuickBooks et d’autres applications de style hérité (legacy) pour des sauvegardes et des transferts de données, mais ne pouvez pas envisager de les utiliser comme moyen d’obtenir un accès multi-utilisateur, car ils sont tout simplement incapables de préserver l’intégrité des données.