Le projet en un coup d’œil
Le portail reprend les informations utiles aux clients sans créer une seconde vérité à maintenir.
Trois circuits asynchrones séparent la synchronisation courante, les contacts et les reprises lancées par les équipes.
L’équipe retrouve la progression, les ajouts, les mises à jour et les erreurs, puis descend jusqu’à l’élément concerné.
Lorsque Corim Solutions a fait évoluer son espace client, une difficulté structurante s’est imposée : proposer une expérience web autonome tout en conservant Colline comme référent des comptes, des licences et des contacts. Copier quelques champs ne suffisait pas. Il fallait maintenir des liens fiables entre deux systèmes qui n’ont ni le même rythme ni le même rôle.
Un appel direct à l’ERP dans chaque page aurait reporté sa latence et ses indisponibilités sur les clients. Une copie locale sans règles de synchronisation aurait, à l’inverse, multiplié les écarts : licence active d’un côté, contact modifié de l’autre, droits impossibles à expliquer. Dawap a donc conçu la relation entre les systèmes comme un produit à part entière.
Les lectures de Colline alimentent le contexte utile au portail. Les modifications autorisées repartent vers l’ERP par des contrats ciblés. Les traitements longs s’exécutent en arrière-plan et chaque passage conserve un état, une progression et un résultat. L’équipe peut ainsi distinguer un flux terminé, une donnée inchangée et un cas à reprendre.
Cette réalisation illustre une intégration API ERP menée jusqu’à son exploitation quotidienne : propriété des données, orchestration asynchrone, contrôles de contrat, visibilité pour les équipes et reprise ciblée lorsqu’un écart apparaît.
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.
Donner aux équipes une vue claire sur chaque synchronisation
L’écran réunit le déclencheur, l’état, la progression, les volumes, les erreurs et la durée. Une équipe peut repérer un écart, ouvrir l’exécution concernée et agir sans fouiller d’abord dans des journaux techniques.
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. Un portail client qui doit parler le même langage que l’ERP
Réunir les usages web et les données contractuelles sans les confondre
Corim Solutions édite Colline, une solution de gestion de maintenance. Les comptes clients, leurs licences, les produits utilisés et les personnes associées vivent dans cet environnement métier. L’espace client doit partir de ces informations pour afficher le bon contexte, les bonnes ressources et les bonnes actions à chaque utilisateur.
Une licence ne se résume pas à un numéro. Elle relie une organisation à une installation, une version de produit, des options, des contacts et des fonctions. Un même utilisateur peut aussi intervenir sur plusieurs comptes. Le portail devait reconstituer ce graphe sans demander à Colline de répondre à chaque affichage.
Dans l’autre sens, certaines actions réalisées en ligne doivent rejoindre le cœur métier : modification d’un profil, préférences de communication, désactivation d’un utilisateur ou demande d’intervention. Les conserver uniquement dans le portail aurait créé une divergence invisible pour les équipes.
L’enjeu n’était donc pas de dupliquer l’ERP, mais de construire une continuité maîtrisée. Colline fournit les données de référence. Le portail conserve ce qui lui appartient, sert rapidement les parcours clients et renvoie uniquement les changements qu’il est autorisé à porter.
2. Construire la synchronisation par parcours complets
Partir des effets attendus, stabiliser les contrats puis préparer l’exploitation
Le travail a commencé par les responsabilités : quelle donnée vient de Colline, laquelle appartient au portail, quel événement déclenche un échange et quel résultat doit voir l’utilisateur. Cette cartographie a évité qu’un même appel externe prenne plusieurs significations selon l’écran.
Chaque lot a ensuite couvert un parcours vertical. Synchroniser un compte, par exemple, signifiait récupérer la licence, retrouver le produit et sa version, rapprocher les contacts, mettre à jour les liens locaux et enregistrer le résultat de l’exécution. Le bénéfice pouvait ainsi être vérifié de bout en bout.
Les contrats de Colline ont été encapsulés derrière des services de lecture et d’écriture. Des réponses représentatives sont rejouées dans les tests pour contrôler les variantes de champs, les données facultatives et les erreurs sans dépendre de la disponibilité du réseau à chaque exécution.
Enfin, le dispositif d’exploitation a été traité avec la fonctionnalité elle-même : workers séparés, déclenchement planifié ou manuel, suivi des ressources et lecture des appels API. Cette progression explique pourquoi l’intégration reste compréhensible une fois mise entre les mains des équipes.
3. Répartir les responsabilités avant de connecter les systèmes
Colline porte le contrat client ; le portail porte l’expérience web
La première décision n’a pas concerné la technologie, mais la propriété. Comptes, licences, contacts et fonctions restent référents dans Colline. Le portail les utilise pour ouvrir les bons accès et services, sans laisser une modification locale silencieuse devenir une information concurrente.
Le portail possède en revanche ses identités web, ses contenus, ses ressources, ses associations de catalogue et ses traces d’exécution. Ces objets servent une expérience client que l’ERP n’a pas vocation à modéliser dans le même détail.
Entre les deux, une couche d’intégration traduit les réponses de Colline dans le langage du portail et transforme les actions autorisées en demandes comprises par l’ERP. Le reste de l’application travaille avec des notions métier stables plutôt qu’avec les formats bruts du système externe.
Cette séparation contient les changements. Si un champ ou une structure de réponse évolue, la traduction et ses contrôles concentrent l’adaptation. Les parcours clients continuent à manipuler les mêmes comptes, licences, produits et utilisateurs.
Ce que Colline continue de garantir
Le statut d’une licence, le rattachement d’un compte, les produits installés et les fonctions des contacts continuent d’être définis dans le système métier. Les synchronisations transportent cette information ; elles n’en changent pas l’autorité.
Lorsqu’un parcours permet une modification, celle-ci rejoint Colline par une opération dédiée. Cette circulation reste transparente pour le client, tandis que les équipes savent toujours quel système porte l’état final.
Ce que le portail peut servir en autonomie
Le portail conserve les données nécessaires à sa rapidité et aux relations entre ses contenus, produits et utilisateurs. Il garde aussi l’identifiant Colline qui permet de retrouver chaque objet au prochain passage.
Le client peut ainsi naviguer, changer de contexte et consulter ses ressources sans provoquer une chaîne d’appels à l’ERP. La synchronisation actualise le modèle local selon un processus connu et suivi.
4. Faire remonter uniquement les données utiles au portail
Des lectures ciblées pour les licences, les contacts et les services clients
L’intégration commence par les licences rattachées à un compte, puis récupère leur détail. Installation, produit, version, mode d’hébergement et options rejoignent alors le contexte client qui pilote les contenus et services disponibles dans l’espace connecté.
Les contacts de la licence et leurs fonctions sont rapprochés des identités web. Ce lien permet de savoir qui intervient pour quelle organisation et dans quel rôle, y compris lorsqu’une même personne dispose de plusieurs contextes de travail.
Les relevés de téléassistance et le nombre de demandes d’intervention non lues complètent le parcours support. Le client retrouve dans le portail les signaux qui lui sont utiles sans que l’ensemble du fonctionnement de Colline soit recopié.
Le même principe s’applique aux fichiers servis par l’ERP. Le portail vérifie le contexte, orchestre la récupération et conserve la maîtrise de la délivrance. Le navigateur n’est jamais simplement redirigé vers une ressource interne dont il ignorerait les règles d’accès.
5. Renvoyer vers Colline les changements réalisés en ligne
Une opération dédiée pour chaque intention utilisateur
Le portail transmet la création ou la mise à jour d’un contact lorsque le parcours l’autorise. Changement d’adresse e-mail, de rôle, de profil, de nom ou de préférences de communication : chaque action utilise une opération précise, avec les données attendues par Colline.
Les demandes d’intervention et de rappel rejoignent elles aussi le système métier. Le compte et la licence proviennent du contexte actif ; le formulaire apporte la demande du client. L’équipe retrouve ainsi l’action directement dans Colline.
La désactivation d’un utilisateur coordonne l’accès web et l’état distant. Elle ne se limite pas à masquer localement un compte qui resterait actif ailleurs. Des garde-fous applicatifs bloquent aussi les situations incohérentes, notamment la suppression du dernier administrateur disponible.
L’initialisation et la mise à jour du mot de passe disposent de leur propre parcours lorsque Colline intervient dans le cycle d’authentification. Cette séparation des écritures facilite les contrôles, limite l’effet d’une évolution externe et produit des erreurs compréhensibles pour l’application.
6. Découpler les synchronisations longues de la navigation
Trois circuits pour les comptes, les contacts et les reprises manuelles
Synchroniser un compte demande plusieurs lectures, rapprochements et mises à jour. Réaliser toute cette chaîne pendant le chargement d’une page aurait rendu l’expérience dépendante de la durée et de la disponibilité de Colline.
Dawap a donc confié ces traitements à Messenger et RabbitMQ. Le portail enregistre l’intention, la place dans le circuit adapté et rend la main au parcours web. Un worker prend ensuite le relais, traite le périmètre demandé et met à jour son suivi.
Trois circuits séparent les usages : le rafraîchissement courant des comptes, le rapprochement des contacts et la reprise lancée manuellement. Une anomalie sur les contacts ne vient donc pas bloquer indistinctement tous les autres travaux, et une reprise opérée garde sa propre trace.
Ce découpage permet aussi d’adapter l’exploitation à la nature du flux. Les traitements ne bloquent plus le navigateur ; les équipes disposent en parallèle d’un état pour surveiller la progression, les erreurs et la fin réelle de chaque exécution.
Planification, action applicative ou reprise manuelle
Compte ou contacts à actualiser
Traitement en arrière-plan sans bloquer la page
Lecture de Colline, rapprochement et mise à jour locale
Progression, ajouts, mises à jour et erreurs consultables
7. Reconstruire un compte complet, pas seulement copier une fiche
Licence, produit, version, options et contacts doivent converger ensemble
Une synchronisation de compte ne met pas simplement à jour une ligne. Elle récupère les informations de la licence, rattache le compte à son groupe, reconnaît le produit et la version installée, rapproche les options puis traite les contacts associés.
L’ordre des opérations est essentiel. Le compte doit être créé ou retrouvé avant de recevoir ses liens vers le produit, la version et les utilisateurs. L’identifiant externe permet de mettre à jour l’objet déjà connu plutôt que de fabriquer une nouvelle copie à chaque passage.
Le traitement recalcule aussi les informations utiles à la lecture du portail : version actuellement utilisée, dernière version disponible, état de mise à jour et compteurs associés. La synchronisation produit ainsi un contexte directement exploitable, pas un simple stockage intermédiaire.
Lorsqu’une correction est nécessaire, l’équipe peut relancer le périmètre concerné. Cette exécution manuelle conserve son déclencheur, sa progression et son résultat ; elle ne se confond ni avec la demande précédente ni avec le prochain passage planifié.
Traiter les disparitions comme des décisions métier
Une licence ou un contact qui disparaît du référentiel ne doit pas rester actif indéfiniment dans le portail. Le traitement identifie les comptes absents et synchronise l’état des contacts afin que les accès reflètent la situation connue de Colline.
Ces changements restent reliés à une exécution et à la ressource concernée. Si le résultat surprend l’équipe, elle dispose donc d’un point de départ précis avant toute nouvelle action.
Préserver le contexte des utilisateurs multi-comptes
Une personne peut intervenir pour plusieurs comptes ou licences. Les rattachements locaux permettent au portail de lui proposer les contextes qu’elle peut réellement utiliser, sans mélanger les produits, les documents ou les demandes de deux organisations.
Le rafraîchissement reste borné aux identités et licences concernées. Cette précision évite qu’une action ciblée ne provoque une synchronisation générale sans rapport avec le besoin.
8. Rapprocher durablement les objets des deux systèmes
Les identifiants externes évitent doublons et mises à jour hasardeuses
Chaque objet synchronisé conserve l’identifiant qui permet de le retrouver dans Colline. Le portail reconnaît ainsi une licence ou un contact déjà importé même si son libellé, son adresse ou une autre information descriptive a changé.
Des traducteurs dédiés convertissent les champs, les types et les valeurs externes en objets compris par l’application. Les variantes de nommage et les valeurs facultatives sont traitées à cette frontière, plutôt que dispersées dans chaque parcours.
Lorsqu’un service demande le détail d’une licence ou l’envoi d’une préférence, il exprime une intention métier stable. La couche d’intégration prend en charge l’authentification, la communication et l’interprétation de la réponse de Colline.
Ce choix rend les évolutions plus sûres. Un changement du contrat externe se corrige à l’endroit où il est traduit ; les règles du compte, de la licence et de l’utilisateur peuvent continuer à être vérifiées sans communication réseau.
9. Transformer chaque flux en exécution pilotable
De la vue d’ensemble jusqu’à la licence ou au contact concerné
Chaque lancement crée une exécution avec son origine, son statut, ses heures de début et de fin, le nombre de ressources attendues et la progression atteinte. Les ajouts, mises à jour, absences de changement et erreurs sont comptés séparément.
Un second niveau descend jusqu’à la ressource traitée. Une licence ou un contact possède son propre état, son résultat et, si nécessaire, un code d’erreur et un message. Une exception ne transforme plus tout le flux en boîte noire.
Les appels API complètent le diagnostic. L’équipe peut partir de la synchronisation visible dans le back-office, isoler la ressource qui pose question puis examiner l’échange externe correspondant avec les protections nécessaires sur les données sensibles.
Cette lecture progressive s’adresse à plusieurs niveaux d’usage. L’équipe opérationnelle voit d’abord la progression et le résultat ; les informations plus techniques restent disponibles lorsqu’une analyse approfondie devient nécessaire.
10. Sécuriser les contrats avec des réponses rejouables
Vérifier les cas réels sans dépendre de l’ERP à chaque test
Les échanges couvrent des formes de données variées : listes de licences, détail d’une installation, utilisateurs, fonctions, téléassistance, demandes et fichiers. Dawap a conservé des réponses représentatives afin de rejouer ces contrats dans un environnement de test maîtrisé.
Cette bibliothèque vérifie que l’application sait encore interpréter les champs attendus, les valeurs facultatives et les variantes déjà rencontrées. Une modification de structure devient un échec visible pendant la validation au lieu d’une surprise découverte par un client.
Les contrôles ne s’arrêtent pas à la traduction des données. Ils suivent aussi le résultat dans les règles métier puis dans les parcours applicatifs : compte créé ou mis à jour, produit et version rattachés, contact rapproché, message distribué, état de flux enregistré.
L’environnement de sandbox complète ces tests déterministes. Il confirme l’authentification, la communication et le comportement du système connecté avant le passage en production. Les deux niveaux répondent à des risques différents et se renforcent mutuellement.
Conserver la même mécanique de la sandbox à la production
Les environnements embarquent les mêmes circuits de messages et les mêmes workers supervisés. La configuration change avec l’environnement, mais le chemin fonctionnel validé en sandbox reste celui qui est exploité en production.
En production, la synchronisation planifiée déclenche le rafraîchissement des comptes, tandis que des workers supervisés consomment les circuits des comptes et des contacts. La reprise manuelle reste séparée afin qu’une intervention ciblée ne soit pas noyée dans le traitement courant.
11. Faire de la reprise un parcours d’exploitation
Comprendre la cause avant de relancer le bon périmètre
Avec un traitement en arrière-plan, la prise en compte d’une demande et sa réussite finale sont deux moments distincts. L’interface le rend explicite : un flux peut être en attente, en cours, terminé, terminé avec des erreurs ou interrompu.
La synchronisation manuelle fournit une voie de reprise après diagnostic ou correction de la donnée. Elle crée une nouvelle exécution identifiable, avec son propre résultat. L’équipe peut comparer les deux passages au lieu d’écraser la trace du premier.
Une indisponibilité réseau, une réponse dont la structure a changé et une règle métier non satisfaite n’appellent pas la même action. Les statuts, codes et messages orientent le diagnostic vers une nouvelle tentative, une adaptation du contrat ou une correction de la donnée.
Cette organisation réduit le temps perdu entre le signalement et l’action utile. L’équipe ne relance pas tous les comptes par défaut : elle retrouve l’exécution, identifie la ressource touchée et reprend le périmètre approprié.
12. Du raccordement technique à une continuité de service exploitable
Un portail plus autonome et une équipe qui garde la maîtrise des écarts
Avant cette architecture, chaque nouvelle fonctionnalité du portail risquait d’ajouter une dépendance directe à Colline ou une copie locale difficile à maintenir. Désormais, les comptes, licences, contacts et fonctions suivent des circuits identifiés, avec une propriété et un sens d’échange connus.
Côté client, les informations nécessaires sont disponibles dans un modèle adapté au web. La navigation ne dépend pas d’un appel complet à l’ERP à chaque page, et les services affichés restent reliés au compte, à la licence et au produit pertinents.
Côté Corim, les changements prévus repartent vers le système métier plutôt que de rester enfermés dans une copie. Les équipes disposent d’une vue commune sur les exécutions, les volumes traités, les modifications effectuées et les ressources en erreur.
Côté produit, chaque nouveau parcours peut s’appuyer sur des contrats déjà isolés, testés et observables. L’intégration n’est plus une succession d’appels cachés dans les écrans : elle devient un socle que l’on peut faire évoluer et exploiter.
13. Une intégration ERP pensée pour le client et pour ceux qui l’exploitent
La fluidité du portail repose sur des responsabilités nettes et des flux visibles
La synchronisation Corim relie deux systèmes qui n’ont pas le même rôle. Colline porte les objets contractuels ; le portail compose une expérience web, des contenus et des services adaptés aux clients. La couche d’intégration maintient cette frontière dans les deux sens.
Les identifiants externes, les circuits asynchrones et le suivi à deux niveaux empêchent la relation de se réduire à quelques appels dispersés. Les contrats rejouables sécurisent les évolutions ; l’interface de monitoring donne aux équipes un chemin concret entre un écart constaté et la ressource à reprendre.
Pour une intégration API ERP, Dawap part de la vie réelle des données : qui les possède, quand elles changent, ce que le client doit voir et comment l’équipe intervient si un flux s’arrête. Le projet Corim montre ce que cette approche change une fois l’intégration en exploitation.
