Un client qui relance par téléphone pour savoir où en est sa demande est le signe d’un portail absent ou faux.
Portail client, extranet client et espace client désignent le même objet : un espace authentifié ouvert à des personnes extérieures à l’entreprise. L’extranet est le terme le plus large, il sert aussi aux fournisseurs ou aux partenaires ; l’intranet est réservé aux équipes internes. Pour un opérateur, la différence utile n’est pas le nom, c’est ce que l’espace lit et d’où il le lit.
Que doit montrer un portail client d’opérateur ?
Il doit répondre, sans appel ni courriel, aux questions qu’un client pose le plus souvent à l’exploitation. Pour un datacenter, un hébergeur ou un opérateur de réseau, ces questions se regroupent en six rubriques, chacune lue dans un outil précis :
| Rubrique | Question du client | Où vit la donnée |
|---|---|---|
| Demandes | Où en est ma demande, qui la traite, pour quand ? | Outil de tickets |
| Interventions | Qui vient, quand, pour faire quoi, et qu’a-t-on fait ? | Outil de tickets ou de planification |
| Ressources réservées | Qu’est-ce qui m’est attribué, et qu’est-ce qui reste disponible ? | Source de vérité (inventaire) |
| Incidents et maintenances | Suis-je touché, depuis quand, jusqu’à quand ? | Supervision, tickets, avis de maintenance |
| Documents | Contrats, rapports d’intervention, procédures d’accès | Gestion documentaire |
| Facturation | Qu’ai-je payé, que reste-t-il dû, à quoi correspond cette ligne ? | Outil de facturation |
La dernière colonne compte plus que la deuxième. Un portail ne crée pas d’information : il montre au client une partie de ce que l’opérateur sait déjà. Si l’opérateur ne sait pas quels clients sont touchés par un incident, le portail ne le saura pas mieux.
Pourquoi un portail client échoue-t-il ?
Il échoue quand ses données sont recopiées au lieu d’être lues. Le portail devient alors un outil de plus à tenir à jour, et il prend du retard sur les autres.
Trois symptômes reviennent :
- la copie manuelle : quelqu’un reporte dans le portail le statut d’un ticket ou la liste des ressources d’un client. Chaque report est une tâche, chaque oubli un écart ;
- les statuts faux : le ticket est clos dans l’outil de tickets, le portail affiche encore « en cours ». Le client ne sait plus quelle version croire ;
- le client qui relance : faute de pouvoir se fier au portail, il écrit ou appelle. Le portail n’a rien économisé, il a ajouté une source de questions.
Le défaut n’est pas dans l’interface : c’est d’avoir fait du portail une base à part, alimentée à la main, plutôt qu’une vue sur les outils d’exploitation.
Comment brancher le portail sur les outils existants ?
Le portail lit chaque information dans l’outil qui en est l’auteur, et n’en stocke aucune copie qui ferait foi. Quatre branchements suffisent dans la plupart des cas.
La source de vérité. Les ressources d’un client viennent de l’inventaire. Dans NetBox, le rattachement à un client s’appelle un locataire (tenant). Sa documentation liste les objets qu’on peut lui affecter, dont les sites, les baies, les réservations, les câbles, les circuits et les préfixes. Chaque objet n’a qu’un locataire ; une ressource partagée entre plusieurs clients n’en a aucun. Notre guide sur NetBox comme source de vérité détaille ce modèle.
L’outil de tickets. Les demandes et interventions viennent de l’outil de tickets. La plupart regroupent les utilisateurs d’un même client dans une organisation. Zendesk, par exemple, permet de laisser tous les utilisateurs d’une organisation voir les tickets des autres, ou seulement les leurs.
La supervision et les avis. Un incident ou une maintenance touche des équipements ; le lien vers les clients passe par l’inventaire. C’est la même déduction que pour un avis de maintenance, décrite dans notre guide sur les avis de maintenance aux clients.
Les droits par client. Le cloisonnement se fait côté serveur, jamais dans l’interface. Le portail interroge les outils avec un compte technique aux droits limités. L’API de NetBox accepte des jetons restreints à la lecture. Le portail filtre ensuite chaque réponse sur le client connecté avant de l’afficher.
Côté client, les droits portent sur une organisation, pas sur un utilisateur : celui qui commande, celui qui suit les incidents, celui qui reçoit les factures, ceux qui interviennent sur site. Le portail rattache chaque compte à une organisation et à un rôle, et filtre sur les deux. Un administrateur désigné chez le client crée et retire les comptes de ses collègues, dans les limites fixées par l’opérateur. Sans cette délégation, chaque arrivée et chaque départ deviennent une demande à l’exploitation. Chaque création et chaque retrait de compte sont journalisés.
| Branchement | Mécanisme | Ce qu’il faut décider |
|---|---|---|
| Inventaire | Lecture par l’API, jeton en lecture seule | Quel rattachement fait foi pour un client |
| Tickets | Lecture des tickets de l’organisation du client | Ce que le client voit d’un ticket : statut seul ou échanges |
| Événements | Webhook ou script déclenché par un changement | Ce qui doit apparaître tout de suite, ce qui peut attendre |
| Droits | Filtre serveur sur le client connecté | Qui, chez le client, voit quoi |
Pour la fraîcheur, NetBox propose des règles d’événement : à la création, la modification ou la suppression d’un objet, elles lancent un script, envoient un webhook ou notifient un utilisateur. Le portail peut s’en servir pour mettre à jour sa vue sans relecture complète.
Que peut faire le client depuis le portail ?
Il peut consulter et demander, pas modifier la source de vérité. Une demande déposée dans le portail devient un ticket ; l’équipe la traite et met à jour l’inventaire ; le portail affiche le nouvel état, relu dans la source. Le client ne gagne pas de droit d’écriture sur l’inventaire, et l’opérateur garde un seul circuit de validation.
Deux règles d’accessibilité méritent d’être posées dès la conception. Le critère 3.3.8 des règles WCAG 2.2 du W3C (niveau AA) porte sur la connexion. Il pose qu’« un test de fonction cognitive (comme mémoriser un mot de passe ou résoudre une énigme) n’est exigé à aucune étape d’un processus d’authentification » (traduit de l’anglais), sauf alternative ou aide. Un portail qui bloque le collage ou les gestionnaires de mots de passe ne remplit pas ce critère. Le même niveau demande que les messages d’état, comme « demande envoyée », soient annoncés aux technologies d’assistance.
Par quelle rubrique commencer ?
Par celle qui produit le plus de relances, en général les demandes. Elle ne demande qu’un branchement, l’outil de tickets, et se mesure tout de suite. Les ressources réservées viennent ensuite, quand le rattachement de chaque objet à un client est fiable dans l’inventaire. Les publier avant revient à montrer au client les écarts de la source : notre guide sur la CMDB à jour dit comment les réduire.
Que mesure-t-on pour savoir si le portail sert ?
On mesure ce que le portail devait éviter : les relances et le délai de réponse. Les chiffres viennent des outils déjà en place, sans instrumenter le navigateur des clients.
| Mesure | Comment la compter | Ce qu’elle dit |
|---|---|---|
| Relances par demande | Messages entrants sur un ticket déjà ouvert, avant et après | Si le statut affiché suffit au client |
| Délai de première réponse | Écart entre création et première réponse, dans l’outil de tickets | Si les demandes arrivent complètes |
| Écarts entre portail et source | Rapprochement périodique des deux vues | Si le portail lit, ou s’il recopie encore |
| Demandes déposées par le portail | Part des tickets créés par ce canal | Si les clients s’en servent |
Comparez sur une période fixe, avant et après la mise en service. Si les relances ne baissent pas, regardez d’abord la troisième ligne : un portail qui affiche un statut faux en produit plus qu’il n’en évite.
C’est le travail que Hopwise Labs fait sur les interfaces : un portail qui lit l’inventaire, les tickets et la supervision, avec des droits par client vérifiés côté serveur.
En résumé
Un portail client d’opérateur montre les demandes, les interventions, les ressources réservées, les incidents, les maintenances, les documents et les factures de chaque client. Il échoue quand il recopie au lieu de lire. Il tient quand il interroge la source de vérité, l’outil de tickets et la supervision, filtre côté serveur sur le client connecté et laisse les modifications passer par un ticket validé. On le juge aux relances évitées et au délai de réponse.
Questions fréquentes
Qu’est-ce qu’un portail client pour un opérateur d’infrastructure ?
Un portail client est un espace authentifié où une entreprise donne à ses clients accès à leurs demandes, documents et informations. Pour un opérateur, chaque client y voit ce qui le concerne : ses demandes, les interventions, les ressources qui lui sont réservées, les incidents et maintenances qui le touchent, ses documents. Il lit ces informations dans les outils d’exploitation au lieu de les dupliquer.
Quelle solution de portail client choisir : acheter ou construire ?
Cela dépend de l’endroit où vivent les données. Si tout tient dans l’outil de tickets, son portail intégré suffit souvent. Si le client doit voir des données issues de plusieurs outils, comme l’inventaire, la supervision et les tickets, une couche qui lit chacun d’eux évite de recopier.
Comment cloisonner les données entre clients ?
En rattachant chaque objet à un client dans la source, puis en filtrant côté serveur sur ce rattachement. Dans NetBox, ce rattachement s’appelle un locataire (tenant) et un objet ne peut en avoir qu’un ; dans les outils de tickets, l’équivalent est souvent l’organisation.
Le portail doit-il permettre au client de modifier des données ?
Il peut déposer une demande, pas modifier directement l’inventaire. La demande devient un ticket, l’équipe la traite, et la source de vérité est mise à jour par la personne qui valide. Le portail affiche ensuite le nouvel état, lu dans la source.
Comment les clients se connectent-ils au portail ?
Par un compte nominatif, jamais partagé entre collègues, avec un second facteur. Pour les clients qui le demandent, la connexion peut passer par leur propre fournisseur d’identité, par exemple avec OpenID Connect : un départ chez le client coupe alors aussi l’accès au portail. La connexion ne doit bloquer ni le collage ni les gestionnaires de mots de passe, comme l’exige le niveau AA des règles WCAG 2.2.
Sources
- Documentation NetBox : Tenancy (rattacher un objet à un client)
- Documentation NetBox : l’API de lecture et d’écriture, jetons en lecture seule
- Documentation NetBox : Event Rules (script, webhook, notification)
- Zendesk : organisations et groupes, partage des tickets au sein d’une organisation
- W3C : règles pour l’accessibilité des contenus web, version 2.2 (Recommandation du 12 décembre 2024)
- OpenID Foundation : OpenID Connect Core 1.0 (couche d’identité au-dessus d’OAuth 2.0)