Un portail client n'est pas un outil interne
C'est la distinction qui structure toute la décision. Un outil interne mal fichu coûte du temps à vos équipes, qui s'y font. Un portail client mal fichu se voit, se compare et se raconte.
Vos clients l'utilisent en même temps que ceux de vos concurrents. S'ils y trouvent un formulaire générique aux couleurs approximatives de votre marque, ils en tirent une conclusion sur votre niveau de service. S'ils y trouvent exactement les trois informations pour lesquelles ils appelaient jusqu'ici, ils cessent d'appeler, et votre support s'allège.
Cette différence explique pourquoi l'arbitrage n'est pas le même que sur un outil de back-office.
Ce que le SaaS règle bien
Sur un besoin standard, une solution du marché est difficile à battre. Donner accès à des factures, permettre le dépôt de pièces justificatives, suivre l'avancement de tickets : ces usages sont couverts par des produits matures, disponibles en quelques semaines et exploités par l'éditeur.
Le SaaS supprime aussi une charge qu'on sous-estime toujours : la maintenance. Un portail exposé sur internet demande des mises à jour de sécurité, une supervision et un plan de sauvegarde. Confier cela à un éditeur a une valeur réelle si vous n'avez pas d'équipe pour l'assumer.
Sur ces terrains, développer revient à payer pour reproduire l'existant. Il n'y a aucune raison de le faire.
Les trois limites qui déclenchent un développement
La tarification par utilisateur externe
La plupart des solutions facturent au compte actif. Le modèle tient tant que vous avez deux cents clients. Il devient absurde quand vous en avez dix mille, dont la majorité se connecte deux fois par an. Vous financez alors des comptes dormants, et la tentation de restreindre les accès annule l'intérêt du portail.
La profondeur d'intégration
Un portail utile affiche des données à jour : un encours réel, un état d'avancement réel, un stock réel. Ces informations vivent dans votre ERP, votre outil de production ou votre base métier. Les solutions du marché s'y branchent par connecteurs, souvent par synchronisation périodique.
Tant qu'un décalage de quelques heures est acceptable, tout va bien. Dès que le client prend une décision à partir de la donnée affichée, ce décalage produit des erreurs, et des appels au support pour les corriger. C'est le point de bascule le plus fréquent.
Le parcours
Un portail générique est organisé selon la logique de l'éditeur : des menus, des listes, des filtres. Vos clients, eux, viennent faire deux ou trois choses précises. Un portail conçu à partir de ces usages met ces actions en page d'accueil et supprime le reste. Aucune personnalisation d'un produit SaaS ne permet ce niveau de simplification, parce qu'il doit rester générique pour tous ses clients.
Le coût réel d'un portail sur-mesure
Deux à quatre mois pour une première version en production sur un périmètre resserré, puis un coût de maintenance continu, hébergement compris. C'est un engagement, et il faut l'assumer comme tel.
L'erreur classique consiste à vouloir livrer d'emblée l'intégralité de ce que ferait un produit du marché. Un portail sur-mesure gagne en faisant peu de choses très bien : les trois actions que vos clients répètent, et rien d'autre au départ. Le reste s'ajoute une fois que l'usage a montré ce qui manquait vraiment.
C'est aussi la meilleure façon de sécuriser le budget : un périmètre resserré se cadre précisément, donc se contractualise sur un délai et un prix.
Le critère qui tranche : le portail fait-il partie du produit
Si le portail est un service annexe, une commodité que vos clients utilisent parce qu'il faut bien déposer des documents quelque part, prenez une solution du marché et n'y consacrez pas un projet.
S'il est le lieu où votre client constate la qualité de votre travail, s'il remplace des appels, s'il montre en temps réel ce que vous êtes en train de faire pour lui, alors il fait partie de ce que vous vendez. Et ce que vous vendez ne s'achète pas sur étagère.
