← Retour au blog

Pourquoi ToolBerry privilégie le mode hors ligne

Imaginez la scène. Vous arrivez sur un chantier situé à l’arrière d’une propriété, après avoir pris trois virages sur une allée en gravier, et votre réseau tombe à une seule barre. Vous ouvrez votre…

Par L'équipe Toolberry10 Temps de lecture :

Mise à jour de l'26 avril 2026

Imaginez la scène. Vous arrivez sur un chantier situé à l’arrière d’une propriété, après trois virages sur une allée en gravier, et votre signal tombe à une barre. Vous ouvrez votre application de planification pour vérifier quel équipement le client vous a demandé d’examiner… et vous tombez sur une icône de chargement qui tourne en boucle. Puis un écran indiquant « Vous êtes hors ligne ». Puis plus rien.

C’est précisément pour ce genre de situation que ToolBerry existe.

La plupart des applications de gestion des interventions sur le terrain considèrent que le réseau est toujours disponible, et le « mode hors ligne » comme un plan de secours pour les cas où les choses tournent mal. ToolBerry fonctionne à l’inverse. C’est le réseau qui constitue le plan de secours. Votre appareil est la source de vérité. C’est ce que nous entendons par « hors ligne d’abord », et ce n’est pas une fonctionnalité que nous avons ajoutée après coup : elle façonne presque toutes les décisions que nous prenons concernant le produit.

Voici pourquoi nous l’avons conçu ainsi, et ce que cela signifie concrètement pour vous.

Ce que signifie réellement « hors ligne d’abord »

Il convient de faire une distinction d’emblée, car ce terme est souvent utilisé à tort et à travers.

Les applications « tolérantes au mode hors ligne » partent du principe que le cloud est la source de vérité. Elles mettent certaines données en cache pour que vous puissiez continuer à travailler en cas de perte de signal, mais dès que vous perdez la connexion, l’expérience se dégrade : les fonctionnalités cessent de fonctionner, les écrans deviennent noirs et vous vous demandez avec inquiétude si ce que vous avez saisi sera conservé.

Les applications « offline-first » partent du principe que l’appareil est la source de vérité. Le cloud est une cible de synchronisation, pas une dépendance. Que vous ayez cinq barres de réseau LTE ou que vous soyez assis dans une buanderie au sous-sol sans aucun signal, l’application se comporte de la même manière.

ToolBerry appartient à cette deuxième catégorie. Vos missions, vos clients, vos chantiers, vos contacts, vos équipements et vos plannings sont stockés dans une véritable base de données sur votre téléphone – il ne s’agit ni d’un cache, ni d’une file d’attente en attente de communication avec un serveur. Nous utilisons SQLite, le même moteur de base de données qui alimente la plupart des applications déjà présentes sur votre téléphone. Si cela vous intéresse, vous trouverez plus d’informations techniques à la fin de cet article.

Les raisons évidentes : la rapidité et la fiabilité

Si vous travaillez sur le terrain depuis un certain temps, vous connaissez déjà ces situations :

Votre signal n’est pas fiable, mais le travail, lui, l’est. Sous-sols. Bâtiments industriels. Propriétés rurales. Parkings souterrains. Partout où il y a des murs métalliques. Le travail sur le terrain se déroule dans des endroits qui n’ont pas été conçus en tenant compte des antennes-relais. Une application « hors ligne d’abord » s’en moque.

La vitesse. La lecture depuis votre appareil local est environ mille fois plus rapide que d’attendre un aller-retour vers le serveur. Charger l’historique d’un client, accéder à un bon de travail, effectuer une recherche parmi des centaines de missions : tout est instantané, car aucune donnée n’est récupérée. Il n’y a pas de temps de chargement pour vos propres données. Elles s’affichent tout simplement.

Finie l’angoisse du « enregistrement… ». Chaque modification que vous effectuez est immédiatement enregistrée sur votre appareil. Pas d’état d’enregistrement partiel, pas de « Êtes-vous sûr de vouloir quitter cette page ? », pas de risque de perdre ce que vous avez saisi à cause d’une coupure de connexion.

Ce sont là les arguments incontournables. Ce sont ceux que l’on met en avant dans tout argumentaire en faveur de l’approche « hors ligne d’abord ». Les raisons les plus intéressantes sont celles qui sont moins évidentes.

Les raisons moins évidentes (qui sont sans doute les plus importantes)

Vos données vous appartiennent, elles ne nous appartiennent pas

La plupart des outils SaaS fonctionnent ainsi : vous saisissez le nom, l’adresse et le numéro de téléphone de votre client dans un formulaire, et ces informations sont transmises à un serveur situé dans le centre de données d’un tiers. Vous confiez vos relations clients à cette entreprise – et si celle-ci subit une panne, est rachetée, modifie ses tarifs ou décide d’utiliser vos données d’une manière que vous n’aviez pas prévue, vous n’avez guère de recours.

L’offre gratuite de ToolBerry inverse cette logique. Vos clients, vos sites et l’historique de vos missions sont stockés dans une base de données sur votre appareil. Nous ne les détenons pas. Nous ne pouvons ni les perdre, ni les divulguer, ni les vendre, ni les retenir en otage. Si nous disparaissions demain, vos données seraient toujours sur votre téléphone.

Pour les travailleurs indépendants et les petites équipes – en particulier dans les secteurs où la liste de clients est l’essence même de l’activité –, cela fait une différence considérable. Vous ne louez pas l’accès à vos propres informations.

« Gratuit pour toujours » est une caractéristique structurelle, pas une offre promotionnelle

Tous les outils de gestion des interventions sur site que vous avez évalués présentent un problème dont ils ne parlent pas : chaque utilisateur gratuit leur coûte de l’argent. Serveurs, bases de données, bande passante, assistance : tout cela s’additionne. Ils limitent donc strictement l’offre gratuite et vous poussent vers des formules payantes dès que vous commencez à trouver le produit utile. Heroku proposait une offre gratuite réputée pour sa générosité et a fini par la supprimer complètement en 2022, précisément pour cette raison.

Lorsque nous affirmons que ToolBerry est gratuit à vie pour les travailleurs indépendants, nous le pensons vraiment, car un utilisateur gratuit ne nous coûte pratiquement rien. Aucun serveur ne stocke vos données, aucune base de données ne nous coûte de l’argent, aucune facture d’infrastructure n’est facturée par utilisateur. C’est l’application sur votre appareil qui fait tout le travail.

Cela change la donne quant à ce que peut être l’offre gratuite. Au lieu d’une version d’essai allégée conçue pour vous pousser à passer à un forfait supérieur au bout de 30 jours, il peut s’agir en réalité du produit complet pour les personnes qui n’ont pas besoin de la synchronisation d’équipe. Vous passez à un forfait supérieur lorsque les besoins de votre entreprise évoluent réellement - lorsque vous embauchez un deuxième technicien, lorsque vous souhaitez une intégration avec QuickBooks, lorsque vous avez besoin d’une synchronisation multi-appareils - et non parce que nous vous avons artificiellement limité. Le seuil de paiement est aligné sur la croissance de votre entreprise, et non sur notre facture de serveurs.

À titre de référence : les tarifs habituels des concurrents dans le domaine de la gestion des services sur le terrain (FSM) commencent à environ 169 $ par mois et peuvent atteindre 250 à 500 $ par technicien et par mois pour les grandes entreprises. Nous pouvons proposer des tarifs nettement moins chers car notre structure de coûts est radicalement différente.

Votre disponibilité ne dépend pas de la nôtre

Lorsque votre application de planification est indisponible pendant deux heures un mardi matin, toute l’équipe se retrouve bloquée. Vous avez tous mis en place des flux de travail autour d’un outil qui, soudain, n’est plus là. Avec la formule gratuite de ToolBerry, ce type de problème n’existe pas : l’application sur votre téléphone continue de fonctionner quoi qu’il arrive de notre côté.

Même sur les formules payantes, où la synchronisation entre en jeu, le modèle « local d’abord » signifie qu’un incident au niveau du backend affecte la synchronisation, et non l’application elle-même. Vous continuez à travailler. La synchronisation se rattrape plus tard.

Économique en batterie et en données mobiles

Les applications « hors ligne d’abord » ne communiquent pas en permanence avec un serveur. Pas d’interrogation en arrière-plan, pas de connexions de maintien, pas de « vérification des mises à jour » toutes les trente secondes. Cela ménage discrètement votre batterie et votre forfait de données, surtout si vous utilisez le partage de connexion lors de vos déplacements ou si vous êtes chez un opérateur low-cost avec un plafond de données strict.

Pas d’inscription = pas de friction

Ce n’est pas strictement parce que nous sommes une application « hors ligne d’abord », mais cela n’est possible que parce que nous le sommes. Comme vos données sont stockées sur votre appareil, nous n’avons pas besoin d’un compte serveur pour vous identifier – ce qui signifie pas d’e-mail, pas de mot de passe, pas de vérification par SMS, pas d’assistant d’inscription. Ouvrez l’application, commencez à ajouter des missions.

Le nombre d’essais gratuits abandonnés à l’écran d’inscription est stupéfiant. Nous avons tout simplement supprimé cet écran.

Les compromis honnêtes

Le mode « hors ligne d’abord » a un coût. Il y a de réels compromis, et nous préférons être transparents à ce sujet plutôt que de faire comme s’ils n’existaient pas.

La synchronisation multi-appareils est une fonctionnalité payante. Si vous souhaitez disposer des mêmes données sur votre téléphone, votre tablette et votre ordinateur de bureau, vous devez soit opter pour notre sauvegarde optionnelle via Dropbox, soit souscrire à notre formule Team payante. La synchronisation multi-appareils en temps réel nécessite un backend, et les backends ont un coût. Nous n’allons pas faire semblant du contraire en intégrant ce coût dans l’abonnement mensuel de chacun.

Dans la formule gratuite, les sauvegardes relèvent de votre responsabilité. Si vous perdez votre téléphone et que vous n’avez pas connecté Dropbox ou souscrit à un abonnement supérieur, vos données disparaîtront avec lui - exactement comme si vous perdiez un carnet papier. Nous vous facilitons la tâche pour pallier ce risque (la sauvegarde Dropbox est gratuite et prend environ trente secondes à configurer), mais nous tenons à ce que vous sachiez que ce risque existe.

La taille initiale de l’application est plus importante. Le principe « offline-first » implique que nous intégrons le moteur de base de données, l’intégralité de votre schéma et une infrastructure suffisante pour fonctionner de manière autonome. L’application pèse quelques mégaoctets de plus qu’un équivalent « client léger ». Vous ne le remarquerez qu’une seule fois, lors de l’installation.

Les modes privés/incognito des navigateurs bloquent l’application. Les navigateurs empêchent intentionnellement le stockage local persistant en mode privé, ce qui signifie que ToolBerry ne peut rien enregistrer dans ces fenêtres. Nous avons abordé ce sujet séparément – il existe un article dédié à ce sujet – mais cela mérite d’être signalé ici afin de vous présenter une image honnête de la situation.

Certaines fonctionnalités avancées nécessitent véritablement un backend. La coordination d’équipe en temps réel, les vues des répartiteurs, l’acheminement des ordres de travail entre locataires, les intégrations comptables… Ce ne sont pas des fonctionnalités que nous réservons derrière un mur payant à des fins purement marketing. Elles nécessitent réellement un serveur. Le mode « hors ligne d’abord » résout une grande partie des problèmes, mais ce n’est pas une solution universelle, et nous n’allons pas vous faire croire le contraire.

Ce que cela signifie pour vous

Si vous effectuez des missions depuis un camion : ToolBerry fonctionne de la même manière, que vous soyez garé dans un parking du centre-ville ou sur une propriété rurale sans réseau. Il n’y a pas de mode en ligne ou hors ligne à prendre en compte : il y a simplement l’application, et elle fonctionne.

Si vous gérez la planification, la répartition ou les opérations depuis un bureau : le modèle « local d’abord » signifie que les personnes sur le terrain peuvent réellement compter sur l’outil que vous leur fournissez. Leurs saisies de données ne disparaissent pas dans une file d’attente de synchronisation que vous ne pouvez pas contrôler. Leur application ne se bloque pas en cas de coupure de connexion. Et lorsque vous êtes prêt à coordonner l’ensemble d’une équipe, les formules payantes reposent sur les mêmes fondements : la synchronisation est intégrée de manière organique, et non pas rajoutée à la va-vite.

Si vous comparez ToolBerry aux acteurs établis du marché : son architecture relève d’une catégorie à part, et non d’une simple amélioration progressive. Le modèle de tarification, la politique de confidentialité et la fiabilité sur le terrain découlent tous d’un même choix fondamental. Cela mérite d’être pris en compte avec soin.

Vous avez une question ?

Nous sommes toujours ravis de discuter avec vous de la manière dont cela s'applique à votre situation spécifique. Contactez-nous à l’adresse contact@toolberry.app.

Pour les curieux de technique

Si vous souhaitez comprendre comment cela est réellement conçu, voici un aperçu des rouages internes.

SQLite sur l’appareil

ToolBerry utilise SQLite comme base de données locale – le même moteur que celui intégré à iOS, Android, Chrome, Firefox, macOS et la plupart des applications grand public que vous utilisez quotidiennement. Ce n’est pas un cache. Ce n’est pas localStorage. C’est une véritable base de données relationnelle avec une prise en charge complète de SQL : jointures, transactions, index, clés étrangères, tout y est. Nous l’avons testée avec des centaines de milliers d’enregistrements sur des téléphones grand public et les performances restent stables.

Sur iOS et Android natifs, l’accès à SQLite s’effectue via les API système standard grâce à Capacitor. Dans le navigateur/PWA, nous utilisons une version de SQLite compilée en WebAssembly, stockée sur le disque via OPFS (Origin Private File System) – une API de navigateur relativement récente conçue précisément pour ce type de cas d’utilisation.

Pourquoi SQLite plutôt qu’IndexedDB ou localStorage ?

La plupart des applications web disposant d’un mode hors ligne utilisent IndexedDB ou localStorage. Ces deux solutions présentent des limites :

  • localStorage est un magasin clé-valeur soumis à une limite stricte d’environ 5 Mo et utilisant des E/S synchrones sur le thread principal. Il est inutilisable pour tout ensemble de données significatif.
  • IndexedDB est plus performant, mais son API est réputée pour être peu intuitive ; il ne prend pas en charge le SQL, présente une cohérence inter-navigateurs insuffisante et souffre de problèmes de fiabilité connus.
  • SQLite, par rapport à OPFS, nous offre un véritable SQL, de véritables transactions, un comportement prévisible sur toutes les plateformes et la même couche de requêtes que celle que nous partageons avec notre backend. C’est la seule option qui s’adapte sans compromis à un véritable ensemble de données de production.

Comment la synchronisation s’intègre (à terme)

Les utilisateurs du forfait gratuit sont, par conception, entièrement hors ligne. Les forfaits payants ajoutent la synchronisation, et l’architecture est conçue pour que l’appareil fasse autorité :

  1. Chaque écriture est d'abord enregistrée dans la base de données SQLite locale, immédiatement et sans passer par le réseau.
  2. Les écritures sont également enregistrées dans une boîte d’envoi locale.
  3. Lorsque l'appareil est en ligne et que l'utilisateur dispose d’un forfait payant, la boîte d’envoi est vidée vers notre backend.
  4. Les modifications provenant d’autres appareils arrivent sous forme de flux et sont fusionnées dans la base de données locale.

Il s'agit du même modèle général utilisé par Linear et la plupart des applications collaboratives modernes axées sur le local. Cela signifie que l'application locale ne subit jamais de blocage lié au réseau, et que la synchronisation devient une tâche en arrière-plan plutôt qu'un chemin critique.

Pourquoi la structure des coûts est-elle si différente ?

Un SaaS FSM traditionnel héberge les données de chaque client dans une base de données centrale, exécute des serveurs API à chaque requête et paie le stockage, la puissance de calcul et la bande passante à chaque interaction. Le coût marginal par utilisateur gratuit est bien réel, et à grande échelle, il devient prépondérant.

L'offre gratuite de ToolBerry est une application SPA statique servie depuis un CDN - les coûts de bande passante se mesurent en fractions de centime par utilisateur - et toutes les données résident sur les appareils des utilisateurs. Nous n’avons rien d’autre à héberger que le bundle de l’application lui-même. Les niveaux payants réintroduisent une infrastructure backend pour la synchronisation et les intégrations, mais uniquement pour les utilisateurs qui en ont réellement besoin.

C’est la raison structurelle pour laquelle le modèle « gratuit à vie » fonctionne pour nous, alors qu’il n’a pas fonctionné pour Heroku. Heroku payait de réels coûts d’infrastructure par utilisateur et tentait de les récupérer grâce à la conversion. Ce n’est pas notre cas.

Pour en savoir plus

Partager
XLinkedIn