Par Thomas Cohen, fondateur de Maestro
Créer un portail client sans coder : documents, demandes et accès par dossier
Un exemple de studio indépendant pour organiser les livrables, les demandes et les accès de deux clients. Avec un brief à adapter et des essais croisés avant toute ouverture.
Un client demande où se trouve la dernière version de son document. Vous lui renvoyez un lien, puis cherchez dans vos messages ce qu’il avait validé. Un portail client devient utile lorsqu’il permet de retrouver trois choses sans vous solliciter : ce qui est disponible, ce qui attend une réponse et la prochaine action à effectuer.
Nous suivrons le studio fictif Traverse, qui prépare des dossiers de présentation pour deux clients inventés, Atelier Rivage et Maison Silex. Les noms, documents et demandes sont des exemples pédagogiques. Le guide fournit une organisation à construire et à vérifier ; il ne décrit ni un portail effectivement livré ni une fonction native de Maestro.
Choisir le passage de relais à améliorer
Commencez par une livraison précise. Dans notre exemple, Traverse remet une première proposition, reçoit des remarques, livre une nouvelle version et attend une validation. Le problème principal est la dispersion des informations entre les pièces jointes, les messages et le dossier partagé. Une page qui regroupe tous ces éléments peut aider, à condition de rendre la prochaine action évidente.
Écrivez la phrase que le client devrait pouvoir prononcer après sa visite : « J’ai retrouvé la proposition actuelle et envoyé mes remarques sur le bon dossier. » Elle est plus utile pour concevoir la première version que « je veux un espace moderne ». Elle permet également de distinguer les fonctions indispensables des idées agréables mais secondaires.
Observez aussi la fréquence réelle des échanges. Pour un document livré une fois par an, un dossier partagé bien nommé peut suffire. Une application personnalisée devient plus intéressante quand plusieurs projets se succèdent, que les interlocuteurs changent ou que chaque demande doit être suivie jusqu’à une réponse. Relevez quelques situations vécues avant de choisir.
Le modèle de portail client de Zapier rassemble notamment projets, documents et formulaire d’aide. Cette page officielle illustre un type d’organisation possible. Elle ne prouve pas qu’un modèle satisfait vos règles d’accès, ni qu’il convient à tous vos clients. Notre exemple se concentre sur les décisions à prendre avant la construction.
Organiser les dossiers et les personnes
Un client est une organisation ; un utilisateur est une personne qui se connecte. Gardez cette distinction. Atelier Rivage peut avoir deux interlocuteurs et plusieurs projets. Si vous attachez tous les documents à une seule adresse électronique, le départ de cette personne devient une difficulté inutile : il faut retrouver ce qui appartient au client et ce qui appartient au compte.
Le modèle de départ peut rester très simple. Une fiche client contient son nom et son responsable interne. Une fiche projet appartient à ce client. Un document appartient à un projet. Une demande appartient également à un projet, avec son auteur et la personne qui doit répondre. Chaque élément reçoit une référence stable, indépendante de son titre.
- Client C01 : Atelier Rivage ; projets P01 et P02.
- Client C02 : Maison Silex ; projet P03.
- Compte Léa : accès aux projets autorisés d’Atelier Rivage.
- Compte Sami : accès au seul projet P03 de Maison Silex.
- Compte Nora : responsable interne des trois projets.
Précisez si chaque interlocuteur voit tous les projets de son organisation ou seulement certains dossiers. Dans l’exemple, Léa voit P01 et P02. Un second compte invité pour relire P02 ne voit pas P01. Cette petite décision doit exister dans le brief : elle ne se déduit pas du simple mot « client ».
Dessiner un accueil qui indique quoi faire
L’accueil doit répondre à la situation du visiteur. Léa se connecte pour relire une proposition. Elle devrait voir le nom du projet, le document à examiner, la date souhaitée pour son retour et le bouton permettant de répondre. Une liste de tous les fichiers depuis le début de la mission l’oblige à reconstituer elle-même cette priorité.
Dans notre exemple, chaque projet présente trois zones : « À votre attention », « Documents disponibles » et « Vos demandes ». La première ne contient que les actions attendues du client. La deuxième donne accès aux versions publiées. La troisième affiche les demandes ouvertes et leurs réponses. Une courte phrase explique ce qui a changé depuis la dernière publication.
Évitez de faire dépendre la compréhension d’une couleur. « Réponse attendue avant le 12 octobre » est plus clair qu’un point orange. Si aucune action n’est nécessaire, dites-le explicitement. Un espace vide peut donner l’impression que le chargement a échoué ou que des documents ont disparu.
Préparez aussi le premier accès : invitation identifiable, nom du studio, projet concerné et contact en cas de difficulté. Une personne qui n’a jamais utilisé votre outil doit pouvoir comprendre pourquoi elle reçoit ce message. L’essai se fera avec une adresse de test que vous contrôlez ; aucune invitation réelle n’est nécessaire pour vérifier le parcours.
Séparer brouillon, publication et validation
Un document en préparation ne doit pas devenir visible parce qu’un membre du studio vient de le déposer. Prévoyez une action de publication distincte, avec une personne autorisée à l’effectuer. Nora peut ainsi préparer une proposition, vérifier le fichier et son destinataire, puis la rendre accessible au client concerné.
La version est une information métier. « Proposition 2 » doit rester rattachée au même projet que « Proposition 1 », sans écraser les remarques qui portaient sur cette dernière. Affichez une version actuelle et conservez les anciennes selon votre organisation. Un client qui ouvre un ancien lien doit comprendre qu’il existe une version plus récente.
Distinguez lecture et validation. Le téléchargement d’un fichier ne signifie pas que le client l’accepte. Si vous avez besoin d’un accord explicite, demandez une action compréhensible portant sur une version précise. Dans notre exemple, le bouton indique « Valider la proposition 2 ». Cette trace de décision ne constitue pas, à elle seule, un dispositif de signature juridique.
Donner une fin identifiable à chaque demande
Une demande doit avoir un objet, une réponse attendue et un état. « Modifier la couverture de la proposition 2 » est plus exploitable qu’un commentaire isolé disant « à revoir ». Laissez le client choisir le projet, décrire le besoin et joindre un document lorsque c’est utile, sans lui imposer de connaître votre organisation interne.
Traverse retient quatre états : reçue, en cours, réponse disponible et terminée. « Reçue » confirme l’enregistrement. « En cours » indique qu’une personne s’en occupe. « Réponse disponible » invite le client à examiner le résultat. « Terminée » clôt la demande selon une règle annoncée, par exemple après confirmation du client ou après une clôture expliquée par le studio.
Évitez les changements silencieux. Si Nora regroupe deux demandes identiques, elle conserve un lien vers celle qui poursuit le traitement. Si elle refuse une modification hors périmètre, elle explique la décision et le contact à utiliser pour discuter d’un autre devis. Le portail sert à retrouver cet échange, sans remplacer une discussion nécessaire.
Prévoyez le retour d’une demande terminée. Le client découvre un problème sur la version livrée : une nouvelle demande peut être reliée à la précédente. Cette organisation préserve le premier échange et permet de distinguer une erreur à corriger d’un nouveau besoin. Elle évite de rouvrir tous les dossiers sans contexte.
Écrire les accès sous forme de situations
Décrivez les permissions avec des verbes ordinaires : consulter, déposer, répondre, publier, inviter et retirer un accès. Pour chacun, nommez qui peut agir et sur quels dossiers. La fiche de la CNIL sur les habilitations recommande de limiter les accès aux données nécessaires et de les retirer quand ils ne sont plus justifiés.
Dans Traverse, Léa consulte les documents publiés d’Atelier Rivage et crée des demandes sur ses projets. Elle ne voit ni les brouillons ni les notes internes. Sami possède les mêmes possibilités pour Maison Silex. Nora prépare et publie les documents. Le rôle qui invite de nouveaux interlocuteurs doit être prévu séparément : inviter quelqu’un lui ouvre une partie du dossier.
Les pièces jointes méritent le même soin que les pages. Masquer un nom dans la navigation ne suffit pas si le fichier reste accessible par son adresse directe. Demandez à la personne chargée de la réalisation de vérifier l’accès aux documents, aux aperçus et aux résultats de recherche, pas seulement à l’écran d’accueil.
Consignez la fin de mission et le départ d’un contact. Qui retire son accès ? Que reste-t-il disponible pour les autres interlocuteurs ? Comment le client récupère-t-il les livrables convenus ? Ces décisions doivent suivre votre organisation et vos obligations propres ; un simple bouton « archiver » ne répond pas à toutes ces questions.
Préparer deux comptes et des essais croisés
Créez deux clients entièrement fictifs, avec des fichiers qui portent clairement leur nom. Le but est de repérer une confusion immédiatement. Évitez d’utiliser des documents réels maquillés à la hâte : une information peut rester dans un nom de fichier, une image ou les propriétés du document.
Pour chaque essai, notez le compte utilisé, l’action et le résultat attendu avant de cliquer. Léa doit retrouver P01 et P02 ; Sami doit retrouver P03. Essayez ensuite un lien de P03 avec le compte de Léa, puis un lien de P01 avec celui de Sami. Le résultat attendu est un refus d’accès compréhensible, sans dévoiler le contenu du dossier.
- Un brouillon ajouté par Nora demeure invisible au client.
- Un fichier publié apparaît uniquement dans le projet autorisé.
- Une demande conserve son auteur et la version concernée.
- Un compte retiré ne peut plus ouvrir un ancien lien protégé.
- Une réponse enregistrée reste présente après fermeture puis réouverture.
Ces scénarios sont proposés, pas exécutés dans cet article. Ils complètent une vérification technique des accès ; ils ne constituent pas un audit de sécurité. Conservez les résultats observés et reprenez les essais concernés après une correction. Si un document traverse la frontière entre deux clients, arrêtez l’ouverture du pilote.
Prévoir les messages et les incidents ordinaires
Un portail qui enregistre correctement une demande peut malgré tout laisser son utilisateur dans le doute. Décrivez les messages après chaque action : demande reçue, fichier en cours d’envoi, échec du dépôt ou session expirée. L’utilisateur doit savoir s’il peut fermer la page, recommencer ou contacter quelqu’un.
Une notification doit aider à revenir au dossier sans exposer inutilement son contenu. Un message court peut annoncer qu’une réponse est disponible avec un lien vers l’espace protégé. Décidez si les notifications partent immédiatement ou après une publication volontaire. Pendant l’essai, utilisez des destinataires de test pour éviter les envois intempestifs.
Prévoyez le fonctionnement en cas de double clic ou de connexion interrompue. Deux clics sur « Envoyer » ne devraient pas produire deux demandes identiques. Après un échec, le texte déjà saisi devrait pouvoir être récupéré selon les possibilités retenues. Vérifiez ce comportement sur un téléphone, où les interruptions sont faciles à provoquer.
Désignez enfin la personne qui répond aux problèmes d’accès. Le client ne devrait pas avoir à créer une demande dans un portail auquel il ne peut plus se connecter. Une adresse de contact visible en dehors de l’espace protégé permet de traiter ce cas, avec une procédure de vérification d’identité adaptée.
Utiliser le brief pour une première version limitée
Le brief de portail client à télécharger contient les deux clients fictifs, les relations entre dossiers, les droits proposés et une fiche d’essai. Remplacez d’abord les noms et les règles de publication. Ajoutez ensuite les contraintes propres à votre activité, en conservant une version fictive pour les démonstrations.
Le premier périmètre peut se limiter à trois parcours : publier un document, transmettre une demande et retrouver la réponse. Les paiements, la messagerie instantanée et les multiples formes de validation peuvent attendre tant qu’ils ne sont pas nécessaires à ces parcours. Demandez une estimation de la construction et de l’exploitation sur ce périmètre explicite.
Ce brief peut servir avec un prestataire, un outil de construction visuelle ou un projet dirigé avec Maestro. Le portail reste une application à concevoir, héberger, vérifier et entretenir. Le guide sur les applications internes d’une petite équipe aide à répartir les responsabilités du projet ; celui sur les accès par dossier approfondit les règles de visibilité.
Avant d’inviter un premier client, faites parcourir la version d’essai à une personne qui n’a pas participé à sa conception. Demandez-lui de retrouver le document courant et d’envoyer une remarque. Notez où elle hésite, ce qu’elle comprend sans aide et les explications que vous devez encore lui donner. Ces observations guideront les dernières corrections.