Un portail client pour une TPE peut réunir des documents, des demandes et le suivi d’un dossier dans un espace réservé. Avant de le développer, définis un parcours utile, la version de référence des informations et les droits de chaque personne. Une page de connexion ne suffit pas à garantir que chaque client accède uniquement à ses données.

Ce guide aide à cadrer une première version : ce que le client vient faire, qui publie les documents, comment les accès évoluent et quels tests réaliser avant l’ouverture. Il complète le choix de l’application et les vérifications techniques nécessaires au projet.

Partir d’un parcours client précis

Choisis une tâche qui génère aujourd’hui des échanges difficiles à suivre. Par exemple : retrouver la version validée d’un document, déposer une pièce attendue ou consulter l’étape d’un dossier. Décris le point de départ, l’action du client et le résultat attendu pour ton équipe.

Un portail n’a pas besoin de remplacer tous les courriels dès sa première version. Il doit rendre un parcours plus clair sans créer une nouvelle source contradictoire. Note ce qui continuera à se traiter par téléphone ou par échange direct. Si le besoin reste simple, vérifie aussi si un outil existant peut répondre avant d’envisager un développement spécifique.

Notre comparaison entre application web et application mobile pour une TPE aide à choisir le mode d’accès adapté aux usages. La présence d’un espace client n’impose pas à elle seule une application à installer.

Définir les documents et leur version de référence

Fais l’inventaire des contenus réellement nécessaires : document à consulter, pièce à déposer, message ou statut. Pour chaque type, précise qui le prépare, qui le valide et à quel moment le client peut le voir. Une pièce en cours de préparation ne doit pas apparaître comme un document final par défaut.

Prévois un titre compréhensible, un rattachement au bon dossier et un état clair. Si un fichier est remplacé, le client doit pouvoir identifier la version à utiliser. Définis si les anciennes versions restent accessibles et qui peut les consulter. Ne laisse pas ce choix dépendre uniquement du nom du fichier.

Lorsque l’information existe déjà dans un outil métier, décide lequel fait référence. Une copie manuelle peut convenir à un premier périmètre si son contrôle est organisé. Une connexion automatique demande de préciser les erreurs, les délais et la responsabilité de leur reprise.

Écrire les droits avant de dessiner les écrans

Établis une matrice simple qui relie les personnes, les dossiers et les actions. La CNIL recommande de limiter les accès aux données nécessaires aux missions et de gérer les habilitations selon les responsabilités. Le tableau ci-dessous est un exemple fictif à adapter, pas un modèle de droits à copier sans examen.

Profil fictif

Accès prévu

Limite à vérifier

Contact client

Consulter les documents publiés de ses dossiers

Aucun document d’un autre client ni brouillon interne

Contact autorisé au dépôt

Ajouter une pièce aux dossiers autorisés

Aucun dépôt ou remplacement sur un autre dossier

Responsable de dossier

Préparer et publier les documents de son périmètre

Aucun droit d’administration globale par défaut

Administrateur désigné

Gérer les comptes et les habilitations prévues

Actions sensibles encadrées et accès limité aux personnes concernées

Un même client peut avoir plusieurs contacts, et un contact plusieurs dossiers. Précise si les droits sont accordés à l’entreprise entière ou dossier par dossier. Une adresse électronique professionnelle ne suffit pas à décider automatiquement de l’accès à tous les documents de cette entreprise.

Distinguer connexion et autorisation

La connexion établit l’identité d’une personne ; elle ne lui donne pas tous les droits. Les recommandations OWASP sur les autorisations rappellent notamment de contrôler les permissions à chaque requête, y compris pour les ressources comme les fichiers. Masquer un bouton dans l’interface ne remplace pas ce contrôle.

Demande comment le développeur vérifie l’accès au dossier et au document demandé. Un lien direct vers un fichier réservé doit rester protégé selon les droits prévus. Les comptes de test doivent permettre de vérifier les refus autant que les accès autorisés. Le niveau de protection à retenir dépend du contexte et des informations traitées.

La gestion des comptes, l’authentification, les sauvegardes et les autres mesures de sécurité doivent être cadrées avec les personnes compétentes. Une bonne organisation des écrans ne constitue pas un audit complet de sécurité ni une garantie de conformité.

Prévoir les invitations et les changements de personnes

Décris qui peut inviter un contact, qui vérifie son rattachement et quels dossiers lui sont ouverts. Prévois le cas d’une invitation envoyée à une mauvaise adresse, non utilisée ou devenue inutile. Le processus doit permettre de corriger l’erreur sans ouvrir plus largement les données.

Lorsqu’un interlocuteur quitte une entreprise ou change de mission, décide qui en est informé et qui révise les accès. La revue des droits ne doit pas dépendre uniquement d’une demande spontanée du client. Précise aussi la procédure pour retrouver l’accès à un compte et le point de contact en cas de difficulté.

Évite les identifiants partagés entre plusieurs personnes lorsque tu dois savoir qui agit et retirer un accès individuellement. Le fonctionnement choisi doit être expliqué à l’équipe et aux clients concernés.

Envoyer des notifications qui aident à agir

Une notification peut annoncer qu’un document est disponible et inviter à le consulter dans le portail. Évite de recopier automatiquement le contenu confidentiel ou de joindre une pièce sensible à chaque courriel : cela peut multiplier les copies en dehors de l’espace prévu.

Précise ce qui déclenche le message, qui le reçoit et comment les envois répétés sont évités. Si la notification échoue, le document doit rester retrouvable dans le portail et l’équipe doit savoir comment suivre l’incident. Ne présente pas l’envoi d’un courriel comme une preuve que le destinataire a lu ou validé le document.

Tester avec plusieurs comptes fictifs

Avant l’ouverture, prépare deux clients fictifs avec des dossiers distincts et les rôles internes prévus. Réalise les essais dans un environnement convenu, sans explorer les données d’utilisateurs réels.

  • Vérifier qu’un client retrouve la bonne version de son document.

  • Contrôler qu’un autre client ne peut ni le consulter ni le télécharger.

  • Essayer les droits prévus pour le dépôt et le remplacement d’une pièce.

  • Retirer une habilitation et vérifier le comportement attendu.

  • Tester une invitation incorrecte et un lien devenu inutilisable.

  • Vérifier les notifications, les erreurs et le contact de support.

  • Refaire le parcours sur les appareils réellement utilisés.

Conserve les résultats et les anomalies à corriger. Notre guide de recette d’une application métier avant livraison propose une manière de noter les scénarios et les preuves. Ces essais complètent les contrôles techniques ; ils ne les remplacent pas.

Organiser l’usage après la livraison

Exemple fictif : une petite entreprise souhaite partager des comptes rendus validés avec ses clients. Sa première version peut se limiter à un dossier, une publication contrôlée et une consultation réservée aux contacts autorisés. Le dépôt de fichiers et la signature peuvent être étudiés plus tard si un besoin précis les justifie. Cet exemple n’est pas un cas client Oraxya.

Prépare une procédure courte pour publier, corriger et retirer un document. Notre guide pour former l’équipe à un nouvel outil métier complète ce travail. Pour cadrer ton portail, consulte les prestations d’Oraxya et présente le parcours client à améliorer, avec des exemples fictifs plutôt que des documents confidentiels au premier échange.

Cadrons ton projet ensemble

Présente ton activité, ce que tu as déjà et la première amélioration que tu veux obtenir. On pourra définir un périmètre cohérent.

Parler de mon projet