Le projet en un coup d’œil
Licences, versions, modules, hébergement, utilisateurs, documents et assistance formaient un contexte différent pour chaque organisation.
Les clients accèdent aux services qui leur appartiennent ; les équipes Corim pilotent contenus, catalogues, utilisateurs et activité.
Des synchronisations isolées, des traitements asynchrones et des preuves d’exécution relient Colline au portail sans dupliquer aveuglément le métier.
Un espace client destiné à un éditeur de logiciel ne peut pas se limiter à afficher un profil et quelques fichiers. Il doit comprendre à quelle organisation appartient l’utilisateur, quelles licences elle détient, quelles versions sont installées, quels modules sont actifs, si l’environnement est hébergé ou exploité sur site, et quelles actions sont autorisées pour son rôle.
Dawap a conçu pour Corim Solutions un produit web qui absorbe cette complexité sans la reporter sur le client. Le tableau de bord se recompose selon le compte et la licence sélectionnés. Les documents, téléchargements, actualités, services d’assistance et demandes de mise à jour suivent ce contexte. Le back-office donne en parallèle aux équipes Corim les moyens d’administrer l’offre, les contenus et les utilisateurs.
Le choix structurant a été de conserver Colline comme référentiel métier tout en donnant au portail sa propre responsabilité : proposer une expérience claire, sécurisée et observable. C’est précisément le type de problème traité par notre expertise en portail client et extranet B2B : construire l’autonomie autour du système existant, plutôt que fabriquer une seconde vérité.
Cette vue d’ensemble relie cinq réalisations complémentaires. Les quatre approfondissements qui suivent isolent l’expérience multi-compte, la distribution logicielle, le back-office sur mesure et la synchronisation ERP. Chacun part d’une difficulté métier autonome ; ensemble, ils rendent lisible le fonctionnement complet du produit.
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.
Un poste de pilotage pensé pour lire le produit, pas seulement ses écrans
Le tableau de bord réunit qualité technique, activité, documentation, téléchargements et typologies de comptes dans une même lecture opérable. Les valeurs ci-dessous sont fictives ; la composition de l’interface est celle du produit.
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 d’un ERP métier déployé chez ses clients
Un contexte où la licence, l’installation et le rôle conditionnent chaque service
Corim Solutions édite Colline, une solution métier utilisée par des organisations dont les contextes techniques et contractuels diffèrent. Un même client peut disposer de plusieurs licences, exploiter plusieurs versions, activer des modules distincts et associer des utilisateurs qui n’ont ni les mêmes fonctions ni les mêmes droits.
La relation ne s’arrête pas à la vente du logiciel. 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 spécifiques comme Corim Care. La valeur de l’espace client dépend donc de sa capacité à présenter le bon service au bon moment.
Dawap accompagne Corim Solutions depuis plus de treize ans. Cette connaissance du contexte a permis de questionner les règles derrière les écrans : ce qui appartient réellement à l’ERP, ce qui doit être configuré dans le portail, ce qu’un administrateur de compte peut déléguer et ce que les équipes internes doivent pouvoir reprendre.
Le projet s’inscrit dans cette continuité, mais il ne repose pas sur la seule connaissance historique. Les règles importantes sont matérialisées dans le domaine, les contrôles d’accès, les synchronisations, les fixtures et les tests afin que le produit reste compréhensible par-delà les personnes qui l’ont conçu.
2. Conduire le chantier comme un produit métier connecté
Prioriser les parcours complets, puis prouver chaque articulation avec le SI
Le cadrage a commencé par une cartographie concrète : comptes et groupes, licences, contacts, fonctions, produits, versions, modules, modes d’hébergement, documents, demandes d’intervention et contenus. Les ateliers ont servi à distinguer les règles contractuelles des choix d’expérience, puis à traduire chaque cas utile en user stories suivies dans Jira.
Le backlog a été conduit en sprints et ordonné par valeur autant que par risque. Sécuriser l’identité et résoudre le contexte du compte passaient avant l’enrichissement du tableau de bord. Fiabiliser les correspondances ERP précédait l’ouverture des actions qui écrivent dans Colline. Donner une autonomie éditoriale aux équipes exigeait d’abord de définir précisément ce qu’elles pouvaient publier et prévisualiser.
Les démonstrations régulières ont permis de valider des parcours verticaux : invitation, première connexion, choix de licence, accès au bon téléchargement, demande de mise à jour hébergée ou administration d’une ressource. Cette approche évite une livraison où le front paraît terminé alors que les droits, les données externes ou la reprise d’erreur restent implicites.
La validation s’appuie sur des tests unitaires, d’intégration et applicatifs, ainsi que sur des fixtures ERP rejouables. Les images Docker, la CI GitLab, la sandbox, la production, les workers RabbitMQ et les tâches planifiées font partie du delivery. Le run n’est pas ajouté après l’application : il est préparé en même temps que les parcours.
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, logs, 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 artefact 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 matrice de décision et le travail d’administration qui évite de distribuer le mauvais artefact.
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. Synchroniser avec Colline sans rendre le portail opaque
Des lectures et écritures métier isolées, suivies et testables
L’intégration lit les licences, leur détail, les utilisateurs associés, leurs fonctions, les informations de téléassistance, les demandes d’intervention non lues et certains fichiers. Elle écrit les mutations prévues : contact, demande d’intervention ou de rappel, e-mail, rôle, profil, préférences, désactivation et mot de passe.
Trois files RabbitMQ sont dédiées aux synchronisations Colline : compte, reprise manuelle et contacts. Cette séparation évite qu’une opération lente bloque la réponse web et permet d’identifier plus vite la nature d’un traitement qui doit être examiné.
Les exécutions sont représentées par des suivis de flux et leurs détails. Les appels API disposent de logs ; cinquante fixtures JSON reproduisent les contrats nécessaires aux tests. Le diagnostic ne dépend donc pas uniquement d’un message d’erreur affiché à l’utilisateur.
L’approfondissement synchronisation entre le portail et l’ERP Colline présente les responsabilités, les commandes de synchronisation, la reprise et les limites actuelles sans présenter cette intégration privée comme une API publique.
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. Une qualité construite autour des règles métier
Tester les décisions visibles, les contrats ERP et les chemins d’échec
Le rapport de référence audité recense 1 779 tests passants et 12 198 assertions. Les tests unitaires protègent les règles du domaine ; les tests d’intégration exercent les adaptateurs et la persistance ; les tests applicatifs vérifient les parcours via l’application.
Les cinquante fixtures ERP ont un rôle déterminant. Elles capturent des structures de réponse pour les licences, contacts, fonctions, demandes et fichiers. Un changement de mappage peut ainsi être évalué sans attendre qu’un environnement externe reproduise exactement le cas nécessaire.
La CI vérifie également les fixtures, la cohérence du code et la couverture des services d’écriture du domaine. Les images applicatives ne sont construites qu’après les contrôles prévus, ce qui rapproche la preuve testée de l’artefact réellement déployé.
Ces chiffres ne rendent pas le produit infaillible. Ils prouvent plutôt qu’un périmètre fonctionnel dense possède une base de non-régression et que les contrats les plus sensibles peuvent être rejoués lorsqu’un comportement externe ou une règle produit évolue.
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 artefacts 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 lecture du run : 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.
Dawap accompagne ensuite l’exploitation et les évolutions du produit. Le run sert aussi de boucle d’apprentissage : un cas réel mal compris peut devenir une règle explicitée, une fixture, un test et une amélioration de l’interface plutôt qu’une correction isolée.
12. Ce que le produit change, et ce qu’il ne prétend pas mesurer
Une autonomie structurée pour les clients et une maîtrise accrue pour Corim
Le client dispose d’un point d’entrée unique où le compte, la licence et le rôle déterminent les services proposés. Il peut retrouver une ressource, accéder au bon canal de distribution, gérer son profil ou formuler une demande avec un contexte que les équipes n’ont plus à reconstruire manuellement.
Les équipes Corim disposent d’un produit administrable. Elles peuvent faire évoluer les contenus et catalogues, accompagner les utilisateurs, suivre l’activité et examiner les synchronisations. Le portail n’est pas figé dans le code pour chaque changement éditorial ou produit.
Le SI conserve une cohérence claire : Colline reste référent pour les objets qui lui appartiennent ; le portail enrichit leur usage web ; les files, identités externes, logs et tests matérialisent la jonction. Cette lisibilité réduit le risque de créer un second ERP involontaire.
Aucun pourcentage de baisse des sollicitations, de hausse d’adoption ou de gain commercial n’est publié faute de mesure client consolidée. La preuve présentée ici est celle du produit livré : ses parcours, ses règles, son administration, ses intégrations et les dispositifs qui permettent de le faire évoluer.
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 disposent de preuves techniques suffisamment précises pour être comprises et reprises.
Pour construire un produit comparable, notre offre de portail client et extranet B2B permet 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 le run.
