Le projet en un coup d’œil
Compte, licence, version, modules, mode d’hébergement et rôle déterminent les informations et les actions réellement utiles.
Les clients retrouvent leurs ressources et démarches ; les équipes Corim administrent les contenus, les catalogues et les accès.
Le portail interprète les données utiles à l’expérience web et isole les échanges avec l’ERP pour préserver la fluidité des parcours.
Corim Solutions édite et intègre des logiciels de GMAO et d’EAM. Pour ses clients, accéder à un service ne dépend pas seulement d’une adresse e-mail : il faut tenir compte de l’organisation, de la licence, de la version installée, des modules souscrits, du mode d’hébergement et du rôle de la personne connectée.
Dawap a développé un espace client capable de résoudre ce contexte avant de proposer une action. Le tableau de bord, la documentation, les téléchargements, les demandes de mise à jour, l’assistance et la gestion des utilisateurs s’adaptent au compte actif. Les équipes Corim disposent en parallèle d’un back-office pour administrer les contenus, les catalogues et les accès qui façonnent cette expérience.
Le projet relève autant du développement d’un portail client et extranet B2B que d’une application connectée au système d’information. Colline reste la référence pour les données contractuelles et opérationnelles qu’il maîtrise ; le portail leur donne une traduction claire, sécurisée et utile sur le web.
Cette étude raconte le produit dans son ensemble, depuis la sélection du compte jusqu’à son exploitation quotidienne. Des études complémentaires approfondissent ensuite la gestion des droits, la distribution logicielle, le back-office métier et les synchronisations avec l’ERP.
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.
Une vue d’ensemble pour piloter contenus, comptes et usages
Le back-office rassemble les indicateurs utiles pour comprendre l’activité du portail et repérer les contenus ou catalogues à compléter. Les valeurs affichées sont fictives ; la structure de l’interface correspond au produit réalisé.
Captures issues du produit réel. Identités, volumes, dates, états et données métier remplacés par un jeu de démonstration.
1. Corim Solutions, éditeur et intégrateur de logiciels de maintenance depuis 1996
Une relation client qui se poursuit bien après le déploiement de la GMAO
Depuis 1996, Corim Solutions accompagne la digitalisation des activités de maintenance avec des solutions de GMAO et d’EAM. Ses logiciels s’inscrivent dans des organisations, des équipements et des pratiques d’exploitation différents ; l’espace client devait respecter cette diversité sans la rendre visible sous la forme d’une complexité administrative.
La relation se poursuit après l’installation. Elle comprend la documentation, les installateurs, les versions de test, les notes de livraison, les modules complémentaires, l’assistance, les demandes d’intervention, les mises à jour et des services comme Corim Care. La valeur du portail dépend donc de sa capacité à présenter la bonne ressource au bon client, dans le bon contexte.
Un même utilisateur peut être rattaché à plusieurs organisations ou licences. À l’inverse, un compte peut réunir plusieurs contacts aux responsabilités différentes. Le produit devait permettre cette délégation tout en empêchant qu’un rôle valable pour un compte devienne une permission générale sur les autres.
Cette réalité a conduit à traiter le portail comme un produit métier à part entière. Les comptes, les contenus, les produits, le support et les utilisateurs possèdent des responsabilités identifiées ; les échanges avec Colline viennent les alimenter sans confondre le référentiel interne de Corim avec l’expérience proposée au client.
2. Construire le produit par parcours complets
Poser d’abord le contexte client, puis ouvrir progressivement les services
La première étape a consisté à établir le socle dont tous les services dépendent : le compte, la licence, le produit, la version et le rôle actif. La sélection du contexte et la sécurité ont ainsi précédé le tableau de bord et les fonctions plus visibles. Sans cette base, une documentation personnalisée ou un téléchargement aurait pu être juste en apparence tout en visant le mauvais périmètre.
Le produit s’est ensuite enrichi par ensembles cohérents : tableau de bord, contenus et documentation, distribution des fichiers, onboarding et invitations, support, puis administration. Chaque ajout a été relié au même contexte client afin d’éviter des raccourcis différents d’un écran à l’autre.
Les échanges avec Colline ont été introduits avec leurs propres frontières. Les lectures alimentent le portail ; les écritures prévues transmettent une demande ou une modification ; les traitements longs passent par des circuits asynchrones. Cette séparation permet de faire évoluer un parcours sans disperser les appels externes dans toute l’application.
La sécurisation et l’exploitation ont accompagné cette montée en puissance : tests unitaires, d’intégration et applicatifs, contrôles d’accès, protection des actions sensibles, pipeline de validation, environnement de sandbox, images de production et procédures de retour arrière. La mise en ligne est traitée comme une étape du produit, pas comme une opération isolée en fin de chantier.
3. Le problème n’était pas de créer une zone privée
Il fallait faire coïncider le contrat, l’installation et les droits dans chaque parcours
Une page privée classique suppose souvent qu’un utilisateur correspond à un client et qu’un client accède à un ensemble stable de contenus. Chez Corim Solutions, cette hypothèse ne tient pas. Une personne peut intervenir pour plusieurs comptes ; un compte peut porter plusieurs licences ; chaque licence possède son propre environnement, ses produits, ses versions et ses services.
Afficher trop peu d’informations aurait maintenu la dépendance au support. En afficher trop aurait exposé des ressources sans rapport avec le contrat ou créé un risque d’usage. Le produit devait donc résoudre le contexte avant d’afficher une action : qui agit, pour quelle organisation, sur quelle licence, avec quelle fonction et dans quel mode d’exploitation ?
La donnée disponible dans l’ERP ne suffisait pas à dessiner l’expérience. Elle devait être interprétée, rapprochée du catalogue administré dans le portail et transformée en décisions lisibles : montrer un fichier, proposer une demande de mise à jour, ouvrir la gestion des utilisateurs ou orienter vers un service d’assistance.
Cette difficulté explique le périmètre du projet. Authentification, synchronisation, catalogue, contenus, téléchargement et support ne sont pas des modules indépendants ; ils se rencontrent dans chaque décision visible par le client.
Un utilisateur n’est pas le contexte métier
L’identité prouve qui se connecte. Elle ne dit pas encore pour quel compte cette personne travaille aujourd’hui ni quelle licence doit gouverner l’écran. Le portail maintient donc un contexte actif explicite et permet de le changer lorsque plusieurs périmètres sont autorisés.
Cette distinction évite les écrans ambigus et protège les actions sensibles. Le changement de contexte entraîne une nouvelle résolution des droits, contenus, produits et services ; il ne se résume pas à modifier un libellé dans l’en-tête.
L’autonomie utile demande plus de règles, pas moins
Un client devient autonome lorsque le système peut lui répondre sans qu’une équipe vérifie manuellement chaque détail. Cela suppose de rendre exécutables les règles qui étaient auparavant connues par les collaborateurs : bon fichier, bon rôle, bon environnement et bonne version.
Le travail de Dawap a consisté à expliciter ces décisions, à prévoir leurs cas de bord et à garder une voie de reprise pour les situations que l’automatisation ne doit pas trancher seule.
4. Une architecture produit qui sépare les responsabilités
L’expérience web, le domaine métier et l’ERP coopèrent sans se confondre
L’application Symfony 8 est organisée autour de six contextes : Account, Contact, Content, Product, Support et User. Cette séparation reflète les responsabilités réelles. Une règle de téléchargement appartient au produit et à son contexte client ; une invitation appartient au cycle utilisateur ; une synchronisation de compte orchestre des données externes sans redéfinir toutes leurs règles.
Le domaine porte les décisions qui doivent rester stables quel que soit l’écran. La couche de présentation construit les parcours client et back-office. L’infrastructure dialogue avec Colline, la base, les files de messages, le stockage et les services d’envoi. Les contrôleurs ne deviennent pas le lieu où toutes les exceptions s’accumulent.
Cette organisation permet de conserver une frontière nette : l’ERP est référent pour les objets contractuels et opérationnels qu’il maîtrise ; le portail est référent pour ses contenus, son expérience, ses états locaux et ses preuves d’exécution. Une synchronisation relie les deux responsabilités au lieu de les mélanger.
Le résultat correspond à une application web connectée à un ERP, mais avec une nuance importante : le portail n’est pas un miroir. Il construit une expérience et des capacités que l’ERP n’a pas vocation à porter.
Comptes, licences, contacts, fonctions et demandes
Mappage, files dédiées, contrôles et traces
Droits, catalogue, contenus et règles de distribution
Espace client et back-office Corim
Tests, journaux, statistiques et reprise opérée
Pourquoi ne pas tout lire en direct dans l’ERP
Faire dépendre chaque écran d’un appel externe aurait lié la fluidité du portail à la disponibilité et au temps de réponse de Colline. Cela aurait aussi rendu plus difficile la composition de contenus propres au web avec les données contractuelles.
Le produit synchronise ce dont il a besoin, conserve les identités externes et orchestre les écritures ciblées. Cette approche donne de la souplesse sans prétendre que la copie locale remplace le référentiel.
Pourquoi ne pas recopier tout le métier dans le portail
Dupliquer les règles de Colline aurait créé deux systèmes capables de se contredire. Le portail ne réimplémente pas la gestion contractuelle ; il résout les usages web qui entourent ces données et renvoie vers l’ERP les mutations prévues.
Cette frontière rend le produit plus durable : une évolution d’interface ne change pas la source de vérité, tandis qu’une évolution ERP peut être absorbée dans l’adaptateur et les mappages plutôt que dispersée dans chaque page.
5. Une expérience qui part du compte et de la licence
Donner une vue utile sans demander au client de comprendre le modèle de données
Le tableau de bord assemble les informations qui comptent dans le contexte actif : produit, version, modules, actualités, ressources, documentation, téléchargements et accès à l’assistance. Le client ne navigue pas dans une copie de l’ERP ; il retrouve une lecture organisée autour de ce qu’il peut faire.
Lorsqu’un utilisateur intervient pour plusieurs organisations ou licences, la sélection de contexte reste visible. Le produit recharge les droits et les contenus associés, ce qui évite qu’une action commencée pour une entité soit poursuivie dans une autre sans que la personne le comprenne.
Le parcours couvre aussi le profil, les préférences de communication, le mot de passe, la sécurité multifacteur et les interfaces françaises ou anglaises. Ces fonctions ne sont pas traitées comme une annexe : elles participent à la confiance et à la capacité du client à gérer son accès sans intervention.
Le projet dédié autonomie par compte, licence et rôle détaille la résolution de contexte, les rôles clients, la navigation et les garde-fous qui rendent cette expérience possible.
6. Distribuer un logiciel, ses documents et ses mises à jour
Le bon fichier dépend du produit, de la version, du mode d’hébergement et des droits
La bibliothèque ne se contente pas de lister des fichiers. Elle relie les documentations aux produits, versions et modules concernés. Les équipes Corim peuvent publier une ressource, préciser sa portée et la rendre visible seulement lorsque le contexte client la justifie.
Les environnements exploités sur site accèdent aux installateurs prévus : MSI de production ou de test, archives ZIP, fichiers réservés à certains clients, notes de version et modules complémentaires. Les applications mobiles peuvent être distribuées par fichier, store ou QR code selon leur canal.
Pour les clients hébergés, la logique change. Le portail ne propose pas un téléchargement qui donnerait une fausse autonomie ; il ouvre une demande de mise à jour contextualisée avec la version, les modules et les informations nécessaires au traitement par Corim.
L’étude documents, téléchargements et mises à jour expose cette logique de sélection et le travail d’administration qui évite de distribuer le mauvais fichier.
7. Un back-office sur mesure pour opérer le produit
Administrer les contenus, mais aussi comprendre les comptes et l’activité
Les équipes Corim disposent d’une interface dédiée aux comptes, groupes, contacts, utilisateurs, invitations, rôles et paramètres de sécurité. Elles peuvent comprendre pourquoi une personne accède à un périmètre, suivre son onboarding et intervenir sans passer systématiquement par une correction technique.
Le catalogue administrable couvre produits, versions, modules, documentation, fichiers, médias et ressources. Les pages éditoriales sont composées de sections et d’appels à l’action localisés. Une prévisualisation permet de contrôler le résultat dans le contexte prévu avant publication.
L’administration inclut aussi le support, les FAQ, les activités, les connexions, les téléchargements, les statistiques, les logs API et les suivis de synchronisation. Elle répond ainsi à deux questions différentes : que publions-nous et que s’est-il réellement passé ?
Le projet back-office contenus, catalogues et utilisateurs montre comment cette autonomie interne a été structurée sans créer une console fourre-tout.
8. Relier Colline au portail sans ralentir l’expérience client
Des échanges ciblés, asynchrones lorsque le parcours l’exige, et visibles pour les équipes
L’intégration récupère notamment les licences, les utilisateurs associés, leurs fonctions, les informations de téléassistance et les demandes d’intervention non lues. Elle transmet aussi les modifications prévues par le produit : création ou évolution d’un contact, demande d’intervention ou de rappel, rôle, profil, préférences, désactivation et mot de passe.
Trois circuits RabbitMQ séparent la synchronisation des comptes, celle des contacts et les reprises déclenchées par les équipes. Une opération longue n’allonge donc pas inutilement la réponse affichée au client ; elle poursuit son exécution dans un traitement dédié.
Chaque exécution possède un suivi global et le détail des ressources traitées. Les équipes peuvent distinguer une réussite, une absence de changement, un échec ou un élément ignoré, puis relancer le circuit prévu lorsque la situation le demande.
L’étude consacrée à la synchronisation entre l’espace client et l’ERP Colline détaille cette architecture, son suivi opérationnel et la manière dont le portail reste disponible pendant les échanges.
9. Identités, rôles et sécurité au niveau du compte
Simplifier l’accès sans transformer un rôle en permission globale
Le cycle d’accès comprend invitation, première connexion, définition du mot de passe, récupération, multifacteur et gestion du profil. Les e-mails transactionnels sont intégrés aux parcours afin que chaque étape soit compréhensible et que les liens aient une durée et une destination maîtrisées.
Les fonctions remontées depuis Colline alimentent la compréhension du profil, tandis que les rôles applicatifs contrôlent les capacités dans le portail. Une personne autorisée à consulter de la documentation n’obtient pas implicitement le droit de gérer d’autres utilisateurs ou de demander une opération sur une licence.
Des garde-fous couvrent les situations sensibles : ne pas s’auto-désactiver, ne pas retirer le dernier administrateur actif, vérifier le compte courant, limiter les téléchargements et demandes aux profils prévus, et synchroniser proprement une désactivation avec l’ERP.
La sécurité se prolonge dans le back-office. Les équipes internes ont leurs propres autorisations ; les actions exposent le contexte concerné et les traces nécessaires. Le produit empêche les opérations interdites et rend chaque décision d’accès explicable.
10. Tester les décisions qui comptent réellement pour le client
Protéger le contexte actif, les droits, les contenus et les échanges externes
Les tests unitaires protègent les règles du domaine, par exemple le rattachement d’un utilisateur à un compte ou la décision d’autoriser une action. Les tests d’intégration exercent la persistance et les contrats avec Colline. Les tests applicatifs parcourent enfin les écrans et contrôleurs comme le ferait un utilisateur.
Les réponses utiles de l’ERP sont conservées sous forme de scénarios de test rejouables. L’équipe peut ainsi vérifier une licence, un contact, une fonction, une demande ou un fichier sans attendre qu’un système externe reproduise exactement le cas nécessaire.
La pipeline sépare les contrôles de code, les trois familles de tests et les vérifications de sécurité. Les images destinées aux environnements ne sont promues qu’après le passage de ces étapes, ce qui rapproche la version validée de celle qui sera effectivement exécutée.
Cette discipline protège surtout les enchaînements invisibles mais décisifs : changer de compte sans conserver l’ancien contexte, afficher uniquement les ressources compatibles, refuser une action hors périmètre et continuer à expliquer un échange avec l’ERP lorsqu’il échoue.
11. Préparer la production et le quotidien des équipes
Déployer, observer et reprendre font partie de la fonctionnalité
Le socle combine Docker, Nginx, PHP-FPM, Percona/MySQL, Redis, RabbitMQ, Messenger et des tâches planifiées. Les environnements de sandbox et de production reposent sur des conventions proches afin que les validations portent sur un système représentatif.
Les contenus, médias et fichiers distribués utilisent des stockages identifiés. Les workers exécutent les traitements asynchrones ; les tâches planifiées déclenchent les synchronisations prévues ; les journaux permettent de relier une action applicative à un échange externe.
Le back-office offre aux équipes une première vue opérationnelle : activité, connexions, téléchargements, appels API et exécutions de flux. Les diagnostics techniques restent disponibles lorsqu’une analyse plus profonde est nécessaire. Cette double lecture évite de transformer chaque question opérationnelle en incident développeur.
Le projet continue d’évoluer à partir des usages et des situations rencontrées. Un cas mal compris peut devenir une règle explicite, un scénario de non-régression et une amélioration de l’interface, plutôt qu’une correction ponctuelle impossible à expliquer lors de l’évolution suivante.
12. Un espace client qui transforme la complexité logicielle en parcours clairs
Davantage d’autonomie côté client, davantage de maîtrise côté Corim
Le client dispose d’un point d’entrée où le compte, la licence et le rôle déterminent les services proposés. Il peut retrouver une ressource, accéder au canal de distribution adapté, gérer son profil ou formuler une demande sans devoir rassembler lui-même toutes les informations techniques de son installation.
Pour une installation exploitée sur site, le portail peut présenter les fichiers correspondant au produit, à la version et aux modules du client. Pour une installation hébergée, il remplace ce téléchargement par une demande de mise à jour déjà contextualisée. Le parcours suit la réalité du service au lieu d’appliquer la même réponse à tous.
Les équipes Corim disposent de leur côté d’un produit administrable. Elles peuvent faire évoluer les contenus et les catalogues, accompagner les utilisateurs, suivre l’activité et examiner les synchronisations. Une actualité, une documentation ou une suggestion de téléchargement peut évoluer sans reconstruire le portail.
Le système d’information conserve enfin une responsabilité lisible : Colline reste la référence pour ses données, le portail organise leur usage web et les traitements asynchrones matérialisent la jonction. Cette frontière permet de faire évoluer l’expérience client sans créer un second système métier concurrent.
13. Conclusion : un espace client qui devient une composante du service logiciel
L’autonomie naît de la compréhension du métier, pas de l’accumulation d’écrans
Le travail mené avec Corim Solutions montre pourquoi un portail B2B exige une architecture produit complète. L’identité seule ne suffit pas ; il faut résoudre le compte, la licence, la version, l’hébergement et le rôle avant de pouvoir proposer une action honnête.
L’expérience client, la distribution logicielle, le back-office et Colline forment désormais une chaîne explicite. Les données contractuelles restent dans leur référentiel, les contenus et services web restent administrables, et les synchronisations laissent des traces suffisamment précises pour être comprises et reprises.
Pour construire un produit comparable, notre accompagnement en refonte de logiciel métier et notre offre de portail client et extranet B2B permettent de cadrer d’abord les contextes et les décisions qui conditionnent réellement l’autonomie. Ce projet montre jusqu’où cette démarche peut aller lorsqu’elle englobe aussi le back-office, l’intégration ERP, la qualité et l’exploitation.
