Qui peut voir quoi : rôles et autorisations pour une entreprise de services en pleine croissance

Le jour où votre équipe dépasse le stade du « tout le monde voit tout » – et pourquoi de véritables droits d’accès nécessitent un serveur.

Publié en juillet 2026.

La réponse en bref

Dès que vous avez du personnel, quelqu’un doit décider qui peut consulter les tarifs et les marges, qui peut modifier une mission, qui a accès à l’ensemble du carnet de commandes et qui conserve ses droits d’accès après son départ. C’est là qu’interviennent les rôles et les autorisations. De véritables autorisations ne peuvent pas être appliquées sur un appareil contrôlé par l’utilisateur : elles nécessitent un serveur qui vérifie chaque action par rapport à une identité. ToolBerry Free ne dispose pas, de par sa conception, de rôles gérés par serveur. Il est conçu pour un seul opérateur ou une petite équipe partageant un espace de travail via un stockage partagé, où tout le monde voit tout. Les rôles et les autorisations sont désormais disponibles dans ToolBerry Pro, y compris des rôles personnalisés que vous définissez vous-même plutôt que de choisir parmi une liste fixe.

Le jour où les autorisations ont commencé à prendre toute leur importance

Renata a passé quatre ans à faire le ménage seule avant de commencer à embaucher du personnel. Il n’en a pas fallu beaucoup pour que tout change : une deuxième femme de ménage, puis une troisième, sa cousine chargée des plannings et des appels, ainsi qu’une employée à temps partiel pour les semaines chargées. Cinq personnes… et l’application qui était parfaite pour une seule personne est soudainement devenue un problème.

Quand elle était seule, le fait de gérer toute l’activité sur un seul téléphone était l’idéal. Avec cinq personnes, cette même configuration signifiait que :

• que la nouvelle femme de ménage puisse voir exactement ce que chaque client paie – et qu’elle en ait dit à l’un d’entre eux qu’elle trouvait le prix élevé.
• Sa cousine a supprimé un client dont elle avait quatre ans de notes et de codes de coffre-fort, pensant qu’il s’agissait d’un doublon.
• Une employée à temps partiel du week-end a l’adresse et le code d’accès de chaque client sur son téléphone personnel – et elle travaille également pour deux autres entreprises.
• La femme de ménage qui a démissionné en mars a toujours l’application installée, avec tout le carnet de commandes dedans.

Rien de tout cela n’est dû à un mauvais recrutement de la part de Renata. C’est simplement qu’entre deux et cinq personnes, le principe selon lequel « tout le monde peut tout voir » a cessé d’être un réglage par défaut raisonnable – et rien dans son logiciel ne l’a détecté.

Voici ce qui surprend le plus les propriétaires : la question des rôles ne se pose pas vraiment à cinquante employés, ni même à vingt. Elle commence à prendre de l’importance dès quatre ou cinq personnes – dès l’instant où les utilisateurs de l’application ne se limitent plus à vous et à quelqu’un à qui vous confieriez votre carte bancaire. Les enjeux ne cessent de croître à mesure que votre entreprise se développe, mais la ligne à ne pas franchir est atteinte très tôt.

Ce que signifient réellement les rôles et les autorisations

Deux termes sont souvent utilisés de manière interchangeable, alors qu’ils ne devraient pas l’être :

• L’authentification, c’est prouver qui vous êtes. La porte d’entrée. Une connexion.
• L’autorisation, c’est ce que vous êtes autorisé à faire une fois à l’intérieur. Dans quelles pièces vous pouvez entrer, et ce que vous pouvez y toucher.

Un rôle regroupe les autorisations en une notion compréhensible pour un être humain : technicien, répartiteur, estimateur, responsable administratif, propriétaire. Les autorisations sous-jacentes peuvent être générales (pouvez-vous ouvrir des factures ?) ou précises (pouvez-vous voir la colonne « Coût » sur la facture que vous êtes autorisé à ouvrir ?).

Les deux sont indispensables. Une connexion sans autorisation sous-jacente signifie simplement que tout le monde est identifié tout en ayant accès à tout.

Les quatre questions auxquelles toute entreprise en pleine croissance doit répondre

1. Qui a accès aux informations financières ? Tarifs, marges, ce que vous facturez, ce que vous payez. C’est généralement la première limite que les propriétaires souhaitent fixer.
2. Qui peut modifier les données ? Modification et suppression des missions, des clients et de l’historique – et s’il reste une trace de l’auteur de ces modifications.
3. Qui peut consulter l’ensemble des données ? La liste complète des clients, ou seulement la tournée du jour. C’est la question qui importe le plus le jour où quelqu’un part chez un concurrent.
4. Que se passe-t-il quand quelqu’un part ? L’accès doit pouvoir être révoqué depuis un point central, immédiatement, sans avoir à récupérer son téléphone.

Précisons-le clairement : il ne s’agit pas de partir du principe que vos collaborateurs sont des voleurs. La plupart des incidents impliquant des initiés sont de simples erreurs. L’étude « 2025 Cost of Insider Risks » du Ponemon Institute a révélé que la négligence des employés était à l’origine de 53 % des incidents impliquant des initiés, contre 27 % dus à des actes malveillants. Les autorisations protègent principalement les personnes de bonne foi contre des accidents coûteux – et vous protègent contre ce départ inattendu d’un employé indésirable.

Pourquoi les autorisations ont véritablement besoin d’un backend

Voici la partie que la plupart des services marketing des éditeurs de logiciels omettent.

Sur un appareil qui vous appartient, vous contrôlez tout ce qu’il contient. Une application fonctionnant uniquement en local peut masquer la colonne des coûts - la griser, la faire disparaître de l’écran - mais les données restent stockées sur cet appareil, et le contrôle qui les masque s’exécute sur du matériel que l’utilisateur contrôle. Toute personne suffisamment déterminée peut contourner cette protection. Un champ masqué est un rideau, pas un mur.

Une véritable application des règles doit se situer là où l’utilisateur ne peut pas accéder : un serveur qui gère les identités et vérifie chaque requête par rapport à celles-ci. « Cette personne est-elle autorisée à consulter les marges ? » : c’est une machine que vous contrôlez qui doit répondre à cette question, et non celle qui se trouve dans sa poche. Il s’agit d’une limite de confiance, pas d’un simple commutateur de fonctionnalité - et c’est pourquoi l’authentification et les autorisations ne peuvent pas se faire uniquement hors ligne.

La révocation rend cela évident. On ne peut pas « dés-envoyer » des données qui se trouvent déjà sur le téléphone de quelqu’un. Retirer l’accès nécessite un gardien qui était présent depuis le début.

Où en est ToolBerry aujourd’hui – en toute honnêteté

ToolBerry Free ne dispose d’aucun rôle imposé par le serveur, et nous n’allons pas prétendre le contraire. La version Free est conçue pour un seul utilisateur, ou une petite équipe partageant un espace de travail via un stockage commun et se faisant entièrement confiance. Celui qui détient l’appareil détient les données. Ce n’est pas une lacune que nous cachons : c’est une conséquence directe de l’architecture même qui rend la version Free gratuite, utilisable hors ligne et sans compte. Pour une seule personne et un camion, c’est parfaitement adapté.

Les rôles et les autorisations sont disponibles dans ToolBerry Pro – y compris des rôles personnalisés que vous nommez et définissez vous-même, au lieu de cantonner votre équipe à une liste figée « Admin / Utilisateur ». Une entreprise de lutte contre les nuisibles, une société de nettoyage et un atelier de plomberie n’ont pas les mêmes missions ; elles ne devraient donc pas être contraintes de se limiter aux trois mêmes rôles. Les autorisations font partie des fonctionnalités qui nécessitent de toute façon un backend - c'est cette même distinction qui sépare la version Free de la version Pro en matière de synchronisation, de prise de rendez-vous, de paiements et de notifications. (Vous trouverez plus d'informations à ce sujet dans la rubrique « Free vs Pro ».)

Si vous dirigez une véritable équipe, contactez-nous : nous pouvons vous aider à configurer des rôles adaptés au fonctionnement réel de votre entreprise.

Ce qu’il faut rechercher lorsque vous évaluez une application

Six questions à poser lors d’une démonstration, quel que soit le fournisseur :

1. La gestion des autorisations se fait-elle côté serveur ? Demandez directement : « Si un technicien accède aux données de l'application depuis son propre téléphone, peut-il voir les coûts ? » Si le masquage se fait uniquement au sein de l'application, ce n’est qu’une mesure superficielle.
2. Les rôles correspondent-ils à des métiers concrets ? « Admin » et « Utilisateur » ne constituent pas un modèle de rôles. Technicien, répartiteur, deviseur, employé administratif, propriétaire, en revanche, oui.
3. Pouvez-vous contrôler les champs, et pas seulement les écrans ? Permettre à quelqu’un de créer une mission sans voir la marge est le besoin réel le plus courant.
4. Existe-t-il une piste d’audit ? Qui a modifié le prix, et quand ? Sans cela, les autorisations ne constituent qu’un système à moitié complet.
5. Peut-on désactiver un compte en une seule action ? Révocation centralisée, partout, sans avoir à rechercher un appareil.
6. L’application de terrain fonctionne-t-elle toujours hors ligne avec un rôle restreint ? Les autorisations ne devraient pas vous faire perdre la fiabilité pour laquelle vous avez acheté l’application.

Les compromis honnêtes

Les rôles génèrent une charge de travail supplémentaire. Quelqu’un doit être responsable du modèle d’autorisations et le maintenir à jour à mesure que des personnes rejoignent l’équipe ou changent de poste. C’est un véritable travail, et une équipe de deux personnes qui se font entièrement confiance n’en a pas encore besoin – mais le tournant se situe vers la quatrième ou la cinquième personne, pas à la quarantième.

Si le modèle est trop granulaire, personne ne le gère. Commencez par trois rôles, pas onze. Un modèle d’autorisations que personne ne met à jour est pire que pas de modèle du tout, car vous vous y ferez confiance alors que vous ne devriez pas.

Le mode hors ligne et les autorisations sont véritablement incompatibles. Les autorisations mises en cache peuvent devenir obsolètes ; un appareil déconnecté ne peut pas être révoqué en temps réel. Tout fournisseur honnête vous expliquera les compromis à faire à ce sujet plutôt que de prétendre que le problème est résolu.

Vous avez une question ?

Nous aimerions sincèrement recueillir l’avis de personnes qui dirigent de véritables équipes. Quels sont les trois rôles dans votre entreprise, et quelle est la seule chose que vous ne laisseriez jamais un utilisateur sur le terrain voir ? Écrivez-nous à contact@toolberry.net.

ToolBerry Free : gratuit à vie pour les opérateurs indépendants. Pro : pour les équipes qui ont besoin d’une synchronisation en temps réel et de rôles gérés par le serveur.

Pour les curieux de technologie

La règle qui régit tout cela est ancienne et peu glamour : ne faites jamais confiance au client.

Toute décision d’autorisation exécutée sur l’appareil de l’utilisateur n’a qu’une valeur indicative. C’est lui qui contrôle le processus, le stockage et la pile réseau. Vous pouvez brouiller les pistes et compliquer la tâche, mais vous ne pouvez pas en faire une garantie. La limite doit donc se situer côté serveur : chaque requête arrive accompagnée d’une identité (un jeton ou une session), le serveur évalue la politique par rapport à cette identité et ne renvoie que ce que le rôle autorise.

Ce qui nous amène à la règle qui compte vraiment : filtrez à la source, ne vous cachez pas dans l’interface utilisateur. Si l’appareil d’un technicien reçoit l’intégralité du fichier client et que l’application se contente de refuser de l’afficher, vous n’avez pas mis en place une autorisation - vous avez créé une suggestion stockée dans la mémoire locale.

C’est ce qui rend le fonctionnement hors ligne associé au RBAC véritablement difficile, et il convient d’expliquer précisément pourquoi :

• Autorisations obsolètes. Un appareil resté hors ligne pendant deux jours applique un rôle que vous avez peut-être modifié hier.
• Délai de révocation. Vous ne pouvez pas accéder à un appareil déconnecté pour lui retirer l’accès. Le mieux que vous puissiez faire est d’expirer les identifiants mis en cache et de refuser la synchronisation.
• Écritures non fiables. Le travail créé hors ligne ne peut pas être pris pour argent comptant à son arrivée. Chaque écriture mise en file d’attente doit être revalidée côté serveur au moment de la synchronisation par rapport à ce que ce rôle était autorisé à faire - la parole de l’appareil ne constitue pas une preuve.

La solution qui résout la plupart de ces problèmes dans un système « local-first » consiste à définir précisément ce qui est synchronisé. Plutôt que d’envoyer l’intégralité du jeu de données à chaque appareil et d’en masquer certaines parties, un rôle détermine ce qu’un appareil reçoit : le téléphone d’un technicien contient l’itinéraire du jour et les clients concernés, et non l’intégralité du registre couvrant neuf ans. La protection la plus efficace n’est pas une vérification. Ce sont les données qui n’ont jamais atteint l’appareil en premier lieu.

C’est ainsi que nous avons configuré ToolBerry Pro : les lectures « local-first » restent rapides pour tout ce qu’un rôle est autorisé à contenir, la synchronisation est délimitée par rôle, et chaque écriture est validée côté serveur dès son arrivée. L’architecture sous-jacente est la même que celle décrite dans « Pourquoi ToolBerry privilégie le mode hors ligne » - avec un serveur ajouté exactement là où la confiance l’exige.

Pour en savoir plus

• Version gratuite vs version Pro : l’histoire de ToolBerry et à quoi sert chaque formule – où les rôles s’inscrivent dans une vision d’ensemble
• Pourquoi ToolBerry privilégie le mode hors ligne – l’architecture sous-jacente
• Ce dont chaque application de service sur le terrain a réellement besoin (et ce qui n’est que du superflu) – quand une fonctionnalité mérite sa place
• ToolBerry est-il vraiment gratuit pour toujours ? – pourquoi la version gratuite reste gratuite