Le projet en un coup d’œil
Comptes, licences, contacts et fonctions ne sont pas réinventés dans le portail pour simplifier le développement.
Trois files dédiées isolent la synchronisation des comptes, la reprise manuelle et les contacts.
Suivis d’exécution, logs API et fixtures JSON donnent un chemin du symptôme vers le contrat externe.
Le portail Corim devait s’appuyer sur Colline sans devenir une façade fragile qui appelle l’ERP à chaque clic. Les comptes, licences, contacts et fonctions restent des données de référence ; pourtant, l’expérience web a besoin de les rapprocher des utilisateurs, contenus, produits et états qu’elle gère elle-même.
Dawap a construit une intégration qui sépare ces responsabilités. Des adaptateurs traduisent les contrats de Colline. Des synchronisations composent le modèle nécessaire au portail. Les écritures ciblées renvoient les changements prévus. Des files RabbitMQ sortent les traitements longs du temps de réponse et des suivis rendent leur exécution observable.
Ce travail relève de l’intégration API ERP, pas de la création d’une API publique. La valeur se trouve dans la capacité à faire coopérer deux systèmes existants, à maintenir leurs identités et à donner aux équipes un diagnostic lorsque la donnée ou la disponibilité externe ne correspond pas au scénario nominal.
L’étude détaille les données lues et écrites, le découpage des synchronisations, la gestion des états, les fixtures et les choix de run. Elle nomme aussi les points qui demandent encore du renforcement, parce qu’une intégration crédible se décrit autant par ses preuves que par ses limites.
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.
Voir un flux comme une exécution métier, pas comme une ligne de log
Chaque traitement expose son déclencheur, son état, sa progression, ses volumes, ses erreurs et sa durée. Cette lecture donne aux équipes un chemin de diagnostic avant même d’ouvrir le détail technique.
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. Colline, à la fois produit commercialisé et ERP de référence
Connecter le portail au cœur métier sans déplacer la propriété des données
Corim Solutions édite Colline pour ses clients et utilise également son environnement métier dans ses opérations. Les informations qui alimentent le portail ne proviennent donc pas d’un CRM périphérique : elles appartiennent à un système stratégique dont les contrats reflètent le métier de l’éditeur.
Une licence relie un compte à une installation, des produits, des contacts et des fonctions. Le portail ajoute les usages web : identité, contexte actif, contenus, téléchargements, demandes et administration. La synchronisation doit réunir ces lectures sans faire perdre leur origine.
Les équipes ont aussi besoin d’écrire certaines mutations depuis le portail : coordonnées, profils, préférences, désactivations et demandes. Ces actions ne peuvent pas rester seulement locales, car Colline continuerait alors à présenter une information différente.
Le problème d’intégration est donc bidirectionnel et asymétrique. Beaucoup de données sont lues depuis le référentiel ; seules les écritures explicitement prévues repartent vers lui. Le portail ne devient ni maître de tout ni simple cache passif.
2. Contractualiser les flux avant d’automatiser leur fréquence
Cartographier les responsabilités, puis livrer des synchronisations observables
Le cadrage a recensé chaque opération externe, sa direction, son déclencheur et son effet local. Les ateliers ont distingué une lecture d’information, une synchronisation de domaine et une écriture utilisateur. Cette cartographie a empêché qu’un même appel soit utilisé avec des significations différentes selon l’écran.
Les user stories Jira ont été organisées par parcours vertical. Synchroniser un compte signifiait obtenir ses licences, rapprocher les contacts, mettre à jour les rattachements, conserver les identités externes et produire un état consultable. Le backlog a priorisé les données qui conditionnaient l’accès avant les enrichissements de confort.
Les sprints ont alterné implémentation des adaptateurs, mappage du domaine, traitement asynchrone, écrans de suivi et tests sur fixtures. Les démonstrations en sandbox ont vérifié les cas nominaux mais aussi les données incomplètes, les réponses inattendues et les reprises déclenchées par les équipes.
La CI exécute les tests avec les services nécessaires et valide les fixtures. Les images Docker, les workers et les tâches planifiées rapprochent l’environnement vérifié de la production. Le run conserve des logs et suivis afin qu’une anomalie réelle puisse être reliée à un contrat, un élément et une tentative.
3. Définir la frontière avant de brancher les systèmes
Colline porte le contrat ; le portail porte l’expérience et ses états
La décision la plus importante n’a pas concerné le protocole, mais la propriété. Les comptes, licences, contacts et fonctions sont référents dans Colline. Le portail les utilise pour résoudre l’accès, mais ne permet pas qu’une modification locale silencieuse devienne une vérité concurrente.
Le portail possède en revanche ses utilisateurs web, contenus, ressources, associations de catalogue et traces d’exécution. Ces objets répondent à des besoins que l’ERP n’a pas vocation à modéliser dans le détail de l’expérience client.
Les adaptateurs constituent la frontière. Ils transforment les réponses externes en structures comprises par l’application et traduisent les commandes du portail vers les écritures prévues par Colline. Le domaine ne dépend pas directement des formats bruts de l’API.
Cette séparation limite la propagation du changement. Si un champ ou une enveloppe externe évolue, le mappage et ses tests absorbent la différence. Les contrôleurs et écrans continuent à manipuler les concepts du portail.
Pourquoi le portail ne publie pas une API générique
Le besoin du projet est de consommer Colline et de servir des parcours web. Exposer automatiquement les objets internes aurait créé un contrat public supplémentaire sans cas d’usage défini ni gouvernance associée.
Les routes HTTP du produit sont donc des parcours applicatifs. Les capacités d’intégration restent encapsulées derrière les services prévus, sans être présentées comme une plateforme API pour des tiers.
Pourquoi un cache local n’est pas une nouvelle source de vérité
Le portail conserve les données nécessaires à sa fluidité et à ses relations. Il garde aussi les identifiants externes qui permettent de rapprocher chaque objet de Colline.
Une donnée synchronisée peut servir l’expérience sans devenir propriétaire de sa définition contractuelle. Cette nuance guide les écrans de modification et les stratégies de rafraîchissement.
4. Lire les licences et services nécessaires au portail
Récupérer des contrats ciblés plutôt qu’une copie indistincte de l’ERP
L’intégration consulte les licences rattachées à un compte et les informations détaillées d’une licence. Ces réponses alimentent le contexte client : installation, produits, versions, hébergement et données nécessaires aux parcours.
Elle lit également les utilisateurs de licence et leurs fonctions. Ces informations servent à rapprocher les contacts connus de Colline des identités web et à déterminer les responsabilités qui doivent être interprétées dans le portail.
Les relevés de téléassistance et les demandes d’intervention non lues complètent les services présentés. Le portail peut ainsi donner un point d’entrée cohérent vers l’assistance sans reproduire tout le fonctionnement de Colline.
Enfin, certains contenus binaires peuvent être récupérés depuis le contrat prévu. Cette capacité reste encapsulée : le portail contrôle le contexte et la délivrance plutôt que de transmettre directement un lien ERP au navigateur.
5. Écrire seulement les mutations dont le portail est responsable
Propager une intention utilisateur sans ouvrir une écriture générale dans l’ERP
Le portail transmet la création ou mise à jour de contacts lorsque le parcours le prévoit. Les changements d’e-mail, de rôle, de profil et de préférences de communication passent par des services dédiés qui connaissent le contrat externe attendu.
Les demandes d’intervention, de rappel et de mise à jour hébergée sont également écrites dans Colline. Le contexte actif fournit le compte et la licence ; le formulaire apporte l’intention et les précisions nécessaires.
La désactivation d’un utilisateur coordonne la règle locale et l’écriture distante. Elle ne se résume pas à masquer l’accès web si le référentiel doit lui aussi refléter l’état. Les garde-fous empêchent en amont certaines actions incohérentes, comme retirer le dernier administrateur actif.
Le mot de passe peut suivre un contrat spécifique lorsque Colline intervient dans le cycle prévu. Chaque écriture reste isolée derrière son port afin qu’un changement de payload ou d’erreur ne se répande pas dans les contrôleurs.
6. Trois files dédiées pour sortir les flux longs de la requête web
Séparer la synchronisation courante, la reprise manuelle et les contacts
La synchronisation d’un compte peut déclencher plusieurs appels, mappages et écritures locales. L’exécuter intégralement dans la requête aurait rendu la page dépendante de la durée et de la disponibilité de Colline.
Messenger et RabbitMQ transportent ces traitements. Trois files spécialisées ont été identifiées dans le produit : account-sync-coline, account-sync-coline-manual et account-sync-contacts-coline. Leur nom reflète le type d’exécution au lieu de tout regrouper dans une file opaque.
La file courante traite le rafraîchissement prévu des comptes. La file manuelle isole les reprises déclenchées par une équipe. La file contacts concentre le rapprochement des personnes, domaine où les cas d’incomplétude et de changement demandent une lecture spécifique.
Les workers peuvent être opérés indépendamment et les traitements ne bloquent pas le navigateur. Cette architecture améliore la continuité, mais elle ne supprime pas la nécessité de surveiller les échecs, les délais et les tentatives.
Cron, action applicative ou reprise opérée
Commande bornée avec identités et intention
Compte, manuel ou contacts Colline
Appel, mappage et règles de domaine
FlowRun, détails, logs API et état final
7. Synchroniser un compte comme un graphe cohérent
Licences, contacts et fonctions doivent converger dans le même périmètre
Une synchronisation de compte ne consiste pas à mettre à jour une ligne. Elle récupère les licences, leur détail et les personnes associées, puis rapproche ces éléments des objets locaux nécessaires au portail.
L’ordre des opérations compte. La licence doit exister avant que ses utilisateurs et produits puissent être reliés. Les identités externes permettent de mettre à jour un objet déjà connu plutôt que d’en créer une copie à chaque passage.
Les contacts absents ou désactivés demandent une règle explicite. Le système doit distinguer une donnée momentanément incomplète, une personne retirée du référentiel et un utilisateur web qui possède encore un état local à traiter.
La reprise manuelle permet aux équipes de relancer un périmètre après correction ou diagnostic. Elle conserve son propre suivi, ce qui évite de confondre le résultat avec la prochaine exécution planifiée.
Ne pas désactiver sur une simple absence ambiguë
Une liste externe incomplète peut être un état transitoire ou une erreur de contrat. Une suppression immédiate transformerait une anomalie de lecture en perte d’accès client.
Les règles et traces doivent permettre de qualifier l’absence avant les effets irréversibles. C’est un point où la prudence métier compte autant que la performance du flux.
Rafraîchir les autres licences accessibles
Un utilisateur multi-compte ne doit pas conserver un contexte obsolète sur une autre licence après une modification importante. Le produit prévoit le rafraîchissement des périmètres accessibles selon les opérations concernées.
Cette propagation reste bornée aux identités connues ; elle ne lance pas une resynchronisation globale sans rapport avec l’action.
8. Conserver les identités et traduire les contrats
Le mappage protège le domaine des formats de Colline
Chaque objet synchronisé conserve l’identité externe nécessaire à son rapprochement. Le portail peut ainsi reconnaître une licence ou un contact déjà importé même lorsque certains attributs descriptifs changent.
Les mappers traduisent les champs, types et valeurs de Colline vers les objets compris par le domaine. Ils traitent les valeurs optionnelles et les variantes attendues à un seul endroit plutôt que dans chaque service consommateur.
Les ports d’infrastructure donnent aux cas d’usage une interface stable. Le domaine demande une information de licence ou l’écriture d’une préférence ; l’adaptateur se charge du transport, de l’authentification, du payload et de l’interprétation de la réponse.
Cette architecture rend les tests plus précis. Une fixture peut vérifier le mappage du contrat externe ; un test de domaine peut vérifier la décision métier sans démarrer une communication réseau.
9. FlowRun, détails et logs pour suivre ce qui s’est réellement passé
Passer d’une erreur globale à une exécution et un élément identifiables
FlowRun représente l’exécution d’un flux avec son statut et ses compteurs. Il donne une vue d’ensemble : démarrage, progression, résultat et volume traité selon les informations disponibles.
FlowRunDetail descend au niveau des éléments. Une licence, un contact ou une opération peut être relié à son résultat, ce qui aide à isoler un cas problématique sans considérer toute la synchronisation comme indifférenciée.
Les logs API apportent le niveau du contrat externe. Ils permettent d’examiner l’appel et la réponse avec les précautions nécessaires sur les données sensibles. Le diagnostic suit ainsi une chaîne : parcours, flux, élément, appel.
Le back-office expose une lecture adaptée aux équipes Corim. Les journaux techniques complètent cette vue lorsque l’analyse dépasse le niveau métier. Cette stratification évite d’afficher trop de détails à tous sans cacher l’information utile aux opérateurs.
10. Cinquante fixtures JSON pour rejouer les contrats ERP
Stabiliser les mappages sans dépendre de Colline pendant chaque test
Le dépôt audité contient cinquante fixtures JSON associées aux échanges ERP. Elles représentent notamment les licences, détails de licence, utilisateurs, fonctions, demandes et contenus de fichiers nécessaires aux scénarios de test.
Ces réponses rejouables ont une double valeur. Elles accélèrent la suite en supprimant la dépendance réseau et elles documentent les formes de données que l’application sait interpréter. Une évolution du contrat devient un diff visible plutôt qu’un comportement découvert en production.
Les tests d’intégration vérifient les adaptateurs et mappers avec ces données. Les tests applicatifs s’assurent ensuite que le résultat apparaît correctement dans le portail ou l’administration, ce qui relie le contrat technique à l’usage final.
Les fixtures ne remplacent pas les validations sur l’environnement de sandbox. Elles fournissent une base déterministe ; la sandbox confirme l’authentification, la disponibilité et les comportements réels du système connecté avant la production.
11. Rendre l’échec visible et organiser la reprise
Assumer qu’un système externe peut être lent, indisponible ou inattendu
Un traitement asynchrone peut échouer après que le navigateur a confirmé sa prise en compte. Le produit doit donc distinguer l’acceptation de la commande et sa réussite finale. Les états de flux permettent de retrouver cette différence.
La synchronisation manuelle offre une voie de reprise après diagnostic ou correction de la donnée. Elle ne doit pas devenir un bouton pressé sans comprendre la cause ; son exécution séparée et ses détails permettent de comparer le résultat.
Les erreurs de transport, de contrat et de métier ne demandent pas la même réponse. Un timeout peut justifier une nouvelle tentative ; une donnée invalide demande une correction ; un conflit de rôle exige une décision. Les logs et statuts aident à ne pas traiter ces situations comme un seul échec technique.
Le socle possède les files, suivis et outils nécessaires à cette exploitation, mais le durcissement reste continu. Les politiques uniformes de retry, l’idempotence de toutes les écritures et la gouvernance complète des messages définitivement échoués ne sont pas déclarées achevées sans preuve supplémentaire.
12. Une intégration qui soutient le portail sans absorber tout le métier
Les responsabilités sont lisibles et les écarts disposent d’un chemin de diagnostic
Le portail peut résoudre les comptes, licences, contacts et fonctions nécessaires à ses parcours sans appeler Colline dans chaque rendu. Les clients bénéficient d’une expérience plus fluide, tandis que le référentiel conserve la propriété de ses données.
Les mutations prévues repartent vers l’ERP au lieu de vivre dans une copie locale. Les demandes d’intervention, profils, préférences et désactivations suivent des services dédiés dont les contrats peuvent être testés.
Les files spécialisées protègent la requête web et rendent les familles de flux identifiables. FlowRun, FlowRunDetail, logs API et fixtures donnent aux développeurs et équipes Corim plusieurs niveaux de preuve pour comprendre une exécution.
La limite est elle aussi explicite : cette base observable ne signifie pas que tous les scénarios de panne sont industrialisés au même niveau. La trajectoire de run consiste à renforcer retries, idempotence et traitement des échecs à partir des risques et usages réels.
13. Conclusion : connecter l’ERP sans rendre la relation client dépendante de chaque appel
Une bonne intégration attribue les responsabilités et conserve les preuves
La synchronisation Corim relie deux systèmes qui n’ont pas le même rôle. Colline porte les objets contractuels et opérations prévues ; le portail compose une expérience web, des contenus et des états adaptés aux clients et aux équipes.
Les adaptateurs, identités externes, files spécialisées et suivis d’exécution empêchent cette relation de se réduire à quelques appels dispersés. Les cinquante fixtures donnent une base de non-régression ; les logs et reprises permettent d’examiner les écarts lorsque le réel sort du scénario nominal.
Pour un chantier d’intégration API ERP, Dawap commence par la propriété des données, les effets métier et les conditions de run. Le projet Corim prouve la valeur de cette démarche tout en gardant visibles les renforcements encore nécessaires.
