Une plateforme métier sert rarement une seule population. Il y a ceux qui pilotent, ceux qui exécutent sur le terrain, ceux qui possèdent, et parfois le client final. Quatre métiers, quatre façons de travailler, quatre niveaux d’aisance avec un écran.
Le réflexe est d’écrire une application et d’y masquer ce que chacun n’a pas le droit de voir. C’est le chemin le plus court, et c’est presque toujours celui qui coûte le plus cher — pas en développement, en adoption.
Nous faisons l’inverse. Voici pourquoi, et ce que ça implique.
Le problème d’une application unique n’est pas technique
Il est humain, et il se voit dès la première semaine d’utilisation.
Chacun n’utilise qu’une fraction de ce qu’il voit. Une personne à qui l’on montre huit menus dont un la concerne passe son temps à chercher le sien. Elle finira par y arriver, mais elle aura d’abord conclu que l’outil est compliqué — et cette conclusion-là ne se rattrape pas.
La formation devient une condition de démarrage. Un outil qui exige une demi-journée d’explication pour être utilisable ne sera jamais adopté par une équipe qui tourne. Sur le terrain, les gens changent, les intérimaires arrivent, les saisonniers partent. Il faut que ça se prenne en main seul, sur le téléphone, sans personne à côté.
Le poids se paie sur les appareils les plus modestes. L’application unique embarque tout : les écrans de direction, les tableaux de bord, les graphiques. Celui qui n’a besoin que de trois boutons télécharge et exécute quand même l’ensemble. Sur un téléphone d’entrée de gamme et une connexion irrégulière, c’est la différence entre un outil utilisé et un outil contourné.
Ce que nous livrons à la place
Une application par métier, chacune ne montrant que ce que son utilisateur fait réellement. Pas un sous-ensemble de menus : un produit à part entière, dont l’écran d’accueil est déjà la tâche du jour.
Le fond, lui, reste unique. Une seule base, une seule API, un seul jeu de règles métier. Ce qui se décline, c’est la surface. Le surcoût réel se situe entre dix et vingt pour cent — et il se rembourse au premier trimestre, en formation qu’on n’a pas à faire et en support qu’on ne reçoit pas.
C’est un principe d’architecture qui tient dans la durée : ce qui est commun est écrit une fois, ce qui est propre à un métier vit séparément et évolue sans risquer de casser les autres.
C’est exactement ce que montre l’image en tête de cet article : elle vient d’une plateforme d’exploitation pour conciergerie que nous avons livrée, où l’agence, les équipes de ménage, les propriétaires et les voyageurs ouvrent chacun leur propre application.
Le piège : croire que masquer, c’est protéger
C’est l’erreur que nous voyons le plus souvent dans les plateformes que l’on nous demande de reprendre.
Une interface qui cache un bouton selon le rôle continue d’appeler l’API. Les données arrivent au navigateur ; seule leur affichage est supprimé. Il suffit d’ouvrir les outils de développement pour lire ce que l’écran ne montrait pas.
Le contrôle doit donc vivre au plus près des données, pas dans la vue. Sur nos projets, l’isolation est posée dans la couche d’accès aux données elle-même : une requête écrite sans filtre ne peut pas ramener ce qui appartient à un autre. On transforme une discipline — penser à filtrer — en garantie. C’est la même logique que celle qui rend une fuite entre clients impossible par oubli plutôt qu’improbable.
Découper par métier améliore l’expérience. Ce n’est pas ce qui sécurise.
Installable, sans passer par un magasin
Pour les applications destinées aux équipes, nous livrons le plus souvent une application web installable plutôt qu’une application publiée sur l’App Store et Google Play.
Elle s’installe depuis un lien, elle se met à jour sans attendre la validation d’un magasin, et elle n’oblige personne à posséder un compte Apple ou Google — ce qui, pour du personnel de terrain, n’est pas un détail administratif mais un mur.
Le magasin garde tout son sens quand l’application s’adresse au grand public : c’est là que les gens cherchent. Mais la validation est une étape à part entière, avec ses règles et ses refus, et elle se chiffre au devis. Nous publions sur les deux magasins quand le projet le demande ; nous ne l’imposons pas quand il ne le demande pas.
L’identifiant que les gens possèdent vraiment
Dernier point, et c’est celui qui surprend le plus en réunion de cadrage.
Pour les métiers de terrain, nous ouvrons l’accès par numéro de téléphone et code à usage unique, pas par adresse e-mail professionnelle. Cette adresse est souvent une fiction administrative : elle existe dans l’organigramme, personne ne la relève.
Exiger l’e-mail produit une séquence prévisible — un mot de passe oublié la deuxième semaine, un compte partagé entre trois personnes la troisième, et plus aucune traçabilité de qui a validé quoi. Le numéro, lui, est dans la poche, il sert toute la journée, et il identifie une personne.
Sur nos projets marocains, cette question se double d’une seconde : l’interface doit exister en arabe, et l’arabe ne se traduit pas, il retourne la mise en page entière. Direction du document, marges, alignements, icônes directionnelles. Une application par métier rend d’ailleurs ce travail plus simple : on adapte l’interface qui en a besoin, pas les huit écrans d’un produit unique.
La question à poser au cadrage
Une seule, et elle décide de l’architecture :
Combien de métiers différents vont ouvrir cet outil, et lequel d’entre eux a le moins de temps et le moins bon téléphone ?
Si la réponse au premier est « un », l’application unique est le bon choix, et personne ne devrait vous vendre autre chose. Si elle est « trois » ou « quatre », le découpage se paie une fois, à la conception — et ne se rattrape presque jamais après coup.
Ce n’est pas une préférence esthétique. C’est le genre de décision qui sépare un outil qu’on utilise d’un outil qu’on contourne, et on ne s’en aperçoit qu’après la mise en ligne.
