Le projet en un coup d’œil
Le même utilisateur pouvait dépendre de plusieurs comptes, licences, fonctions et environnements logiciels.
Compte, licence, rôle et hébergement gouvernent le tableau de bord, les ressources et les actions disponibles.
Le client accède à ce qui lui appartient, comprend son périmètre et peut gérer son accès sans ouvrir des droits trop larges.
Dans beaucoup d’espaces clients, l’authentification est traitée comme la fin du problème : la personne est reconnue, l’application peut afficher son contenu. Chez Corim Solutions, ce n’était que le début. Une identité pouvait être associée à plusieurs organisations et licences, chacune avec ses produits, ses versions, ses modules, son hébergement et ses administrateurs.
Dawap a donc conçu le portail autour d’un contexte actif explicite. Avant de proposer une documentation, un téléchargement, une demande ou une action sur un utilisateur, l’application sait pour quel compte et quelle licence la personne agit. Le changement de contexte recompose l’expérience au lieu de laisser subsister un mélange d’informations.
Cette logique transforme le portail en véritable extranet B2B multi-compte. L’autonomie ne vient pas d’un menu plus rempli ; elle vient d’une résolution fiable des droits et d’une interface qui explique suffisamment le périmètre courant pour éviter les erreurs.
L’étude se concentre sur cette expérience client. La distribution détaillée des artefacts, l’administration interne et les échanges avec Colline disposent de leurs propres projets reliés afin de ne pas diluer le problème principal : donner accès à la bonne capacité, dans le bon contexte, à la bonne personne.
Un produit métier raconté en cinq projets complémentaires
Chaque projet part d’un problème réellement rencontré : ouvrir les bons services au bon compte, distribuer la bonne version, rendre les équipes Corim autonomes et garder l’ERP comme référentiel. Ensemble, ils montrent comment l’espace client fonctionne de bout en bout sans répéter cinq fois le même récit.
1. Des clients équipés d’un logiciel, pas de simples abonnés à un site
Chaque compte porte une réalité contractuelle, technique et humaine différente
Corim Solutions accompagne des organisations équipées de son ERP métier Colline. Selon les clients, le logiciel est hébergé ou exploité sur leur propre infrastructure. Les versions installées, produits sous licence, modules complémentaires et contacts de référence diffèrent d’un compte à l’autre.
Plusieurs personnes peuvent utiliser le portail pour une même organisation, avec des responsabilités distinctes. Certaines ont besoin de consulter des ressources ; d’autres administrent les utilisateurs, récupèrent des installateurs ou initient des demandes. À l’inverse, une même personne peut intervenir pour plusieurs entités du groupe.
Le portail devait respecter cette variété sans exposer le modèle interne de Corim. Un client n’a pas à comprendre comment les identifiants de licence, fonctions ERP, rôles applicatifs et objets de catalogue sont reliés. Il doit comprendre où il se trouve, ce qui lui est proposé et pourquoi une action lui est ouverte ou non.
Le produit répond à ce besoin en faisant du contexte un élément de navigation et de sécurité. Ce choix guide le tableau de bord, les contrôles d’accès, les liens rapides, les demandes et les messages affichés tout au long du parcours.
2. Concevoir le parcours depuis les décisions d’accès
Modéliser les rôles et cas de bord avant de multiplier les écrans
Les ateliers ont commencé par des scénarios nommés : un utilisateur avec un seul compte, une personne rattachée à plusieurs licences, un administrateur qui invite un collègue, un contact sans adresse exploitable, un dernier administrateur qu’il ne faut pas désactiver et un client dont le mode d’hébergement change le service proposé.
Chaque scénario a été traduit en user stories Jira, critères d’acceptation et règles de domaine. Le backlog a priorisé les chemins qui conditionnaient tout le reste : invitation, première connexion, résolution des rattachements, sélection du contexte et contrôle des rôles. Le tableau de bord a ensuite été enrichi à partir de cette base vérifiable.
Les sprints alternaient implémentation, démonstration et arbitrage métier. Les validations ne portaient pas uniquement sur la conformité visuelle ; elles vérifiaient que le même utilisateur obtenait des résultats différents lorsque le compte, la licence ou la fonction changeait, et que l’interface rendait cette différence compréhensible.
Les tests unitaires protègent les décisions d’accès, les tests d’intégration exercent les rattachements et la persistance, et les tests applicatifs parcourent les écrans. La sandbox a permis de valider les parcours et les communications avant leur ouverture en production, puis les activités et statistiques ont fourni une lecture du fonctionnement réel.
3. Avant : des informations disponibles, mais un contexte à reconstruire
Le client pouvait être connu sans que son périmètre d’action soit immédiatement évident
Les données utiles existaient dans les outils Corim : comptes, licences, contacts, fonctions, versions et services. Mais leur disponibilité interne ne créait pas automatiquement une expérience autonome. Pour répondre à une demande, une équipe devait encore rapprocher plusieurs éléments et vérifier que la personne intervenait bien sur le bon environnement.
Cette reconstruction manuelle est coûteuse pour les demandes simples et risquée pour les opérations sensibles. Deux licences d’une même organisation peuvent utiliser des versions différentes. Deux collègues du même compte peuvent avoir des responsabilités distinctes. Un document valable pour l’un ne l’est pas nécessairement pour l’autre.
Une zone privée générique aurait seulement déplacé le problème. Elle aurait demandé au client de filtrer lui-même un catalogue trop large, ou aux équipes de maintenir des listes d’accès déconnectées de la réalité contractuelle. Le portail devait au contraire résoudre la correspondance à chaque entrée.
La cible a été formulée simplement : toute action doit pouvoir répondre à quatre questions — qui, pour quel compte, sur quelle licence et avec quel droit — avant d’être proposée ou exécutée.
La différence entre appartenance et autorisation
Être rattaché à une organisation autorise l’accès à son périmètre général ; cela n’accorde pas toutes les capacités disponibles. Les rôles applicatifs complètent la relation contractuelle avec des permissions adaptées aux parcours du portail.
Cette distinction évite qu’un contact visible dans l’ERP devienne automatiquement administrateur web et permet de faire évoluer la délégation sans altérer le modèle contractuel.
La différence entre compte et licence
Le compte représente l’organisation ; la licence représente un contexte logiciel concret. Les documents, versions, modules et demandes opérationnelles se rattachent souvent à la seconde, même lorsque la navigation commence par la première.
Le portail matérialise ce passage afin que l’utilisateur ne pense pas agir globalement lorsqu’une action concerne en réalité une installation précise.
4. Un contexte actif qui pilote tout le parcours
Sélectionner une licence n’est pas un filtre visuel, mais une décision applicative
Après connexion, l’application détermine les comptes et licences accessibles. Si un seul contexte est possible, elle évite une étape inutile. Lorsque plusieurs choix existent, elle les présente clairement et conserve la sélection active pendant le parcours.
Le contexte sélectionné gouverne les requêtes suivantes. Le tableau de bord, les produits, les versions, les documentations, les téléchargements et les demandes utilisent le même périmètre. Les contrôleurs ne se contentent pas d’un identifiant reçu depuis l’URL : ils vérifient l’appartenance et les capacités de l’utilisateur.
Changer de compte ou de licence provoque une recomposition cohérente. Les liens qui n’ont plus de sens disparaissent, les contenus sont rechargés et les actions en cours ne sont pas silencieusement transférées. Cette discipline protège l’utilisateur des erreurs liées à un ancien contexte conservé en mémoire.
Le choix reste visible dans l’interface. Cette transparence est importante dans un environnement multi-compte : le client n’a pas à deviner quelle organisation gouverne un téléchargement ou une demande qu’il s’apprête à envoyer.
Connexion, invitation et sécurité du compte
Comptes et licences accessibles depuis Colline
Organisation et installation choisies explicitement
Capacités applicatives et garde-fous associés
Contenu ou action calculé pour ce périmètre
5. Invitation et première connexion sans rupture de contexte
Faire entrer la personne dans le bon compte avant de lui demander de se repérer
Le parcours d’invitation relie l’adresse, l’organisation et le rôle attendu avant l’activation. Le message reçu ne dirige pas vers un formulaire générique : il poursuit une intention connue et conduit la personne vers la création de son accès.
La première connexion accompagne la définition du mot de passe, les informations de profil et les étapes de sécurité nécessaires. Les écrans et communications existent en français et en anglais pour que le parcours ne perde pas sa précision au moment où l’utilisateur doit comprendre une action sensible.
Les états d’invitation restent consultables par les personnes habilitées. Une invitation envoyée, utilisée, expirée ou à reprendre ne doit pas devenir une zone grise qui oblige à recréer un utilisateur au hasard.
Cette continuité entre l’administration et le portail réduit les incohérences d’onboarding. La personne arrive dans le contexte prévu ; l’équipe peut vérifier le chemin parcouru ; les règles de rôle commencent avant le premier affichage du tableau de bord.
6. Un tableau de bord composé à partir du contexte réel
Montrer les prochaines actions utiles plutôt qu’un catalogue de fonctions
Le tableau de bord rassemble les informations qui donnent immédiatement du sens à la session : licence active, produit, version, ressources importantes, actualités, accès aux documentations, canaux d’assistance et actions disponibles. Il réduit la distance entre la connexion et le besoin concret.
Les appels à l’action sont administrables et contextualisés. Une équipe Corim peut mettre en avant une ressource ou un message pour un périmètre donné sans redéployer l’application. Le portail conserve néanmoins la responsabilité de vérifier qu’un lien sensible reste autorisé.
Les contenus éditoriaux et données contractuelles sont assemblés sans être confondus. Le nom d’un produit ou la version installée proviennent du contexte synchronisé ; le texte d’accompagnement, l’actualité et les ressources relèvent du contenu piloté dans le back-office.
Cette composition permet d’accompagner le client sans figer le parcours. Le tableau de bord peut évoluer avec les services de Corim, tandis que les règles d’accès restent testées dans le domaine.
Informer sans créer une seconde source de vérité
Le portail peut expliquer une version, recommander une documentation ou mettre en avant une action. Il ne réécrit pas pour autant la situation contractuelle du client dans un champ éditorial libre.
Cette frontière garantit que l’expérience reste riche sans permettre à une publication de contredire les données qui gouvernent réellement l’accès.
Conserver une sortie claire lorsque le service n’est pas ouvert
Masquer une action évite l’erreur, mais ne suffit pas toujours à orienter. Selon le cas, le portail propose un autre canal, explique la condition attendue ou dirige vers le contact approprié.
Le client n’est pas laissé face à une interface vide ; le produit reste honnête sur ce qu’il peut exécuter et utile pour la prochaine étape.
7. Rôles clients et délégation encadrée
Donner de l’autonomie aux administrateurs sans ouvrir le compte entier
Les administrateurs de compte disposent de capacités supplémentaires pour gérer les utilisateurs et accéder à certains services. Ces droits sont définis au niveau applicatif et vérifiés dans le contexte courant ; ils ne sont pas une simple variation de menu côté navigateur.
Une invitation peut associer une personne au périmètre prévu. Une désactivation retire l’accès selon un workflow contrôlé et se répercute dans les systèmes concernés. Les actions tiennent compte des utilisateurs déjà présents et de leur état afin d’éviter les doublons ou les comptes orphelins.
Le produit interdit des situations dangereuses comme l’auto-désactivation ou la suppression du dernier administrateur actif. Ces règles protègent la continuité du compte et évitent qu’une organisation perde toute capacité de gestion autonome à la suite d’une action pourtant autorisée individuellement.
La délégation reste donc utile sans devenir irréversible. Les équipes Corim gardent une capacité d’observation et d’intervention depuis le back-office métier sur mesure lorsque le contexte exige une reprise.
8. Profil, préférences et sécurité comme parcours produit
Permettre à chacun de maintenir son accès sans fragiliser la donnée partagée
L’utilisateur peut consulter et modifier les informations prévues de son profil, gérer ses préférences de communication et sécuriser son accès. Chaque champ n’est pas nécessairement une donnée locale : certaines modifications doivent être transmises à Colline pour rester cohérentes avec le référentiel.
Le changement d’adresse électronique mérite un traitement spécifique, car l’e-mail sert à la fois de coordonnée, d’identifiant de communication et parfois de point de connexion. Le parcours valide l’intention, évite les collisions et conserve la cohérence entre le portail et l’ERP.
La sécurité multifacteur s’intègre au compte au lieu d’être ajoutée dans une page isolée. L’activation, la vérification et la récupération doivent rester compréhensibles pour des utilisateurs qui ne manipulent pas quotidiennement ce type de mécanisme.
Les mots de passe et liens de récupération suivent eux aussi des parcours dédiés. Les messages transactionnels précisent l’action et sa destination ; le produit évite de mélanger une demande de support avec une opération de sécurité.
9. Des services contextualisés sans surcharger la navigation
Documentation, assistance et Corim Care apparaissent lorsqu’ils ont du sens
Le portail relie les ressources aux produits, versions et modules du contexte actif. Cette association évite la bibliothèque universelle dans laquelle le client doit identifier seul la documentation compatible avec son installation.
Les entrées de support, contact, assistance et FAQ sont organisées selon l’intention. Un besoin de documentation, une demande d’intervention et une question de compte ne suivent pas le même chemin ; les distinguer améliore la qualification sans imposer un formulaire interminable.
Corim Care et certaines actions restent réservés aux profils et contextes concernés. Le portail vérifie la capacité au moment de l’accès et conserve le compte et la licence utiles au traitement, ce qui donne aux équipes une demande déjà située.
La distribution des installateurs et les demandes de mise à jour appliquent une matrice encore plus spécifique. Elles sont détaillées dans le projet documents, téléchargements et mises à jour d’un logiciel métier.
10. Traiter les cas de bord qui décident de la confiance
Un portail B2B est jugé lorsque la donnée est incomplète ou la situation inhabituelle
Certains contacts existent sans adresse électronique exploitable, certains rattachements ont besoin d’être corrigés et certaines personnes possèdent plusieurs fonctions. Le produit ne peut pas supposer que chaque donnée externe correspond immédiatement à un compte web activable.
Lorsqu’un contexte ne peut pas être résolu, le portail privilégie un état explicite et une voie de reprise. Il évite d’ouvrir un périmètre par défaut ou de choisir silencieusement une licence plausible. Cette prudence protège mieux le client qu’une expérience artificiellement fluide.
Les changements de rôle, d’e-mail ou d’état doivent aussi tenir compte du décalage possible entre l’écriture locale et l’écriture ERP. Les actions sont orchestrées pour que l’échec soit détectable et que l’équipe puisse comprendre ce qui reste à reprendre.
Ces cas de bord ont nourri le backlog et les tests. Ils ne sont pas considérés comme du nettoyage après le développement principal : dans un produit multi-compte, ils définissent la robustesse réelle de l’expérience.
11. Valider les droits avec des parcours et des données représentatives
Tester les combinaisons qui changent réellement le résultat
Les règles d’accès sont testées au niveau du domaine afin de vérifier les décisions indépendamment de l’interface. Les tests applicatifs complètent cette preuve en parcourant les routes, formulaires et redirections avec des utilisateurs dont les rattachements diffèrent.
Les fixtures JSON de l’ERP reproduisent des licences, contacts et fonctions représentatifs. Elles permettent de vérifier qu’une évolution de mapping ne transforme pas un profil ou un rattachement sans que la suite de tests le détecte.
Les démonstrations en sandbox ont confronté les règles aux usages des équipes Corim. Cette étape a permis d’ajuster les libellés, l’ordre des choix et les messages d’indisponibilité, des détails déterminants pour que la sécurité soit comprise plutôt que subie.
Après mise en production, les activités de connexion et d’usage fournissent des signaux opérationnels. Elles aident à distinguer un problème d’accès, une invitation inaboutie ou une navigation peu claire sans prétendre mesurer automatiquement la satisfaction du client.
12. Une autonomie définie par le contexte, pas par la quantité de fonctionnalités
Le client sait où il agit ; Corim conserve les moyens de comprendre et reprendre
La personne connectée dispose d’un parcours cohérent avec son organisation et son installation. Elle n’a pas à reconstituer la différence entre plusieurs licences pour trouver une ressource ou lancer une action : le produit garde cette différence active tout au long de la navigation.
Les administrateurs de compte peuvent accompagner leurs collègues dans un cadre contrôlé. Les garde-fous protègent les rôles indispensables et les équipes Corim conservent une lecture de l’onboarding et des accès depuis leur administration.
Les contenus et services deviennent plus précis. Un tableau de bord peut mettre en avant ce qui concerne réellement le compte sans exposer l’intégralité du catalogue Corim. Cette précision crée une expérience plus simple parce que la complexité a été modélisée en amont.
Aucun gain chiffré de support ou d’adoption n’est avancé sans mesure consolidée. La réussite documentée réside dans les capacités livrées : contexte multi-compte, règles d’accès, délégation, sécurité, personnalisation et tests qui rendent ces parcours durables.
13. Conclusion : l’autonomie commence par une identité située
Un bon portail ne montre pas tout ; il comprend ce qui appartient à la personne
Le portail Corim Solutions répond à une difficulté fréquente dans les entreprises B2B : une personne peut être connue de l’organisation sans que son périmètre d’action soit simple. Le compte, la licence, la fonction et le rôle doivent être résolus ensemble avant de proposer une capacité.
En rendant ce contexte explicite et en le partageant entre le tableau de bord, les ressources, l’assistance et la gestion des utilisateurs, Dawap a transformé un ensemble de règles en expérience lisible. Les garde-fous et les chemins de reprise évitent que cette simplicité apparente repose sur des permissions fragiles.
Notre expertise en portail client et extranet B2B part précisément de cette question : quelle réalité métier faut-il comprendre pour que l’utilisateur devienne autonome sans obtenir plus de droits que nécessaire ? Le projet Corim apporte une réponse concrète, testée et exploitable.
