Vos clients appellent pour savoir où en est leur commande, redemandent une facture égarée, attendent deux jours un document que vous avez déjà. Un portail client répond à ces situations en exposant, de façon contrôlée, une partie de votre application métier. La difficulté n'est pas technique : elle tient au périmètre, à ce que vous laissez sortir et pour qui.

Un portail n'est pas une seconde application : c'est une fenêtre ouverte sur des données qui existent déjà. Bien délimité, il absorbe les questions d'état, la récupération de documents et la saisie structurée d'une demande. Mais il ne répare rien : si l'état publié est faux ou en retard de trois jours, vos clients le découvrent en même temps que vous. Un projet de portail commence donc par une question de fiabilité, pas d'interface.

Étapes 1 et 2 : cadrer ce que le portail publie

Pendant deux semaines, faites noter par ceux qui reçoivent les appels et les courriels la nature de chaque sollicitation. Vous obtenez une liste courte, souvent trois ou quatre motifs qui représentent la majorité du volume : ce sont eux, et eux seuls, que le portail doit traiter en premier. Un motif est éligible à deux conditions : la réponse existe déjà dans votre système, et elle ne demande aucun arbitrage humain. « Quelle est la date de livraison prévue ? » est éligible, « pouvez-vous me faire un geste ? » ne l'est pas.

Vient ensuite le choix des champs. Pour chaque objet publié (commande, facture, dossier, ticket), tranchez champ par champ. La règle saine est l'inverse de l'intuition : par défaut rien ne sort, et vous ajoutez explicitement les champs autorisés. Masquer au cas par cas ce qui est sensible laisse toujours passer quelque chose.

Les champs qui fuient sont ceux que l'on avait oublié de regarder : marge, coût d'achat, commentaires internes, historique des remises. OWASP consacre un risque entier à ce point, sous l'intitulé Broken Object Property Level Authorization (API3:2023). Ne renvoyez donc jamais un objet métier tel quel parce qu'il est « déjà en JSON » : construisez une représentation dédiée.

Étape 3 : cloisonner par client, dans le code

C'est ici que se joue la quasi-totalité des incidents. Le scénario est toujours le même : un utilisateur légitime modifie un identifiant dans une adresse ou un appel d'interface, et obtient les données d'un autre client. OWASP classe ce défaut en tête de son référentiel des interfaces de programmation, sous le nom Broken Object Level Authorization (API1:2023).

La règle tient en une phrase : chaque lecture et chaque écriture est filtrée, côté serveur, par le client rattaché à la session en cours, jamais par un paramètre venu du navigateur. Des identifiants non devinables aident, mais ne sont pas un contrôle d'accès.

Ce contrôle se teste tôt : connectez-vous avec un compte du client A, relevez les identifiants du client B, puis rejouez les mêmes requêtes. Tout ce qui répond autre chose qu'un refus est à corriger avant l'ouverture. L'ordre de grandeur du risque : le point d'étape du ministère de l'Intérieur du 21 avril 2026, sur l'incident détecté le 15 avril au portail de l'Agence nationale des titres sécurisés, évoque 11,7 millions de comptes concernés par une divulgation de données personnelles.

Étape 4 : choisir comment vos clients s'authentifient

Premier principe : les comptes de vos clients ne vivent pas dans l'annuaire de vos salariés. Deux populations, deux cycles de vie, deux niveaux de droits. Une gestion intégrée à l'application n'a de sens que pour un portail simple ; au-delà, passez par un service d'identité dédié.

Sur l'écosystème Microsoft, vérifiez les échéances. D'après la documentation Microsoft consultée le 15 septembre 2026, Azure AD B2C n'est plus commercialisable auprès de nouveaux clients depuis le 1er mai 2025, le palier P2 a été retiré le 15 mars 2026 avec bascule automatique vers P1, et le produit reste supporté au moins jusqu'en mai 2030. Les nouveaux projets se construisent donc sur Microsoft Entra External ID.

Côté mot de passe, la référence est la délibération n° 2022-100 de la CNIL du 21 juillet 2022 : 80 bits d'entropie pour un mot de passe seul, 50 bits lorsque des mesures de restriction d'accès existent (temporisation après plusieurs échecs, blocage au bout de dix tentatives), ce second cas étant celui d'un portail client. La CNIL y abandonne le renouvellement périodique pour les comptes ordinaires et attend une fonction de type Argon2 ou scrypt.

Étape 5 : tenir le cycle de vie des comptes externes

Un portail se dégrade rarement par une faille spectaculaire, mais parce que trois ans plus tard, personne ne sait plus qui détient un compte. Quatre décisions évitent cette dérive.

  • Un point d'entrée par entreprise cliente, un contact administrateur qui invite et retire lui-même ses collègues. Les comptes créés à la main sont revus à la main, c'est-à-dire jamais.
  • Une invitation plutôt qu'une inscription libre : le rattachement à une entreprise cliente doit être prouvé, pas déclaré.
  • Une expiration automatique au bout de douze mois sans connexion, et la coupure de tous les comptes d'un client à la fin du contrat.
  • Une revue annuelle envoyée au client, la liste de ses comptes actifs à confirmer. Cinq minutes pour lui, et vous êtes protégé des salariés partis sans que personne ne vous ait prévenu.

Étape 6 : ouvrir petit, mesurer, puis élargir

N'ouvrez pas le portail à tout votre portefeuille le premier jour. Choisissez cinq à dix entreprises clientes représentatives, dont une exigeante et une peu équipée, et laissez tourner six à huit semaines en phase pilote annoncée.

Trois indicateurs suffisent à décider de la suite : la part des demandes d'état qui ne génèrent plus d'appel, le délai médian de réponse, et le taux de connexion réel des comptes ouverts. Ce dernier est le plus révélateur : un portail irréprochable dont les comptes se connectent une fois par trimestre n'a pas trouvé son usage, et il faut revenir à l'étape 1 plutôt qu'ajouter des fonctions. Prévoyez enfin qui répond quand un client n'arrive pas à se connecter, faute de quoi le portail le renvoie vers le téléphone.

Cinq erreurs fréquentes

  1. Cloisonner dans l'écran et pas dans le code : masquer un bouton n'empêche pas d'appeler l'interface qui se trouve derrière.
  2. Brancher le portail sur la base de production, au lieu d'une couche de service dédiée avec ses propres droits.
  3. Ouvrir un portail sur un processus non fiable : des statuts hebdomadaires transforment un flou interne en reproche client.
  4. Confondre volume et valeur : vingt écrans peu consultés coûtent plus cher que trois écrans utilisés chaque jour.
  5. Laisser la propriété des comptes au prestataire : service d'identité, domaine et console s'ouvrent au nom de votre entreprise.

Questions fréquentes

Combien de temps faut-il pour ouvrir un portail client ?

Sur trois motifs de sollicitation et une application métier existante, comptez six à dix semaines jusqu'à la phase pilote. Le délai dépend moins du développement que de la fiabilité des données et des décisions de périmètre, qui relèvent du métier.

Faut-il développer le portail ou utiliser celui de mon logiciel ?

Si votre logiciel propose déjà un espace client couvrant vos trois motifs principaux, utilisez-le : le coût de possession est sans comparaison. Le sur-mesure se justifie lorsque les données proviennent de plusieurs sources, lorsque le portail porte un processus propre à votre métier, ou lorsque l'éditeur facture l'utilisateur externe au tarif d'un utilisateur interne.

Mon portail client doit-il être accessible aux personnes handicapées ?

S'il s'adresse à des consommateurs, il entre dans le champ de la directive européenne 2019/882, dont les obligations s'appliquent aux services fournis au public depuis le 28 juin 2025, avec une exemption pour les microentreprises de moins de dix salariés et deux millions d'euros de chiffre d'affaires. Un portail professionnel relève d'une autre logique, mais l'accessibilité reste très coûteuse à rattraper après coup.

Peut-on ajouter la messagerie et les paiements dès le départ ?

Techniquement oui, mais cela double le périmètre et amène des sujets lourds comme la traçabilité des échanges ou la conformité des paiements. Ouvrez d'abord la consultation, mesurez l'usage un trimestre, puis décidez.

Les portails clients qui durent ne sont pas les plus riches : ce sont ceux qui répondent parfaitement à trois questions, avec des données justes et un cloisonnement vérifié. Chez Pulsar Forge, nous les construisons sur votre application métier existante, sans dupliquer vos données.

Parlons de votre projet de portail client.