Ekadanta : hub de données EAN13 connecté aux API EANSearch, Rainforest et Amazon MWS

1. Présentation du client

Comprendre le contexte business avant la solution

Ekadanta s’inscrit dans un contexte où la qualité des décisions produit dépend directement de la fiabilité des données récupérées, comparées puis exposées à d’autres briques métier.

Le besoin côté client était de sortir d’un fonctionnement trop artisanal, où les équipes recoupaient manuellement des sources parfois contradictoires, avec peu d’historique et trop peu de garanties sur la cohérence finale.

Le projet devait donc créer un socle de donnée plus propre, plus traçable et plus simple à exploiter pour des usages métier qui exigent de décider vite sans multiplier les vérifications humaines.

2. Méthode projet Dawap

Analyse, priorisation, delivery agile et sécurisation du run

Le chantier a commencé par une phase d’analyse des sources, des divergences de structure et des points de friction rencontrés dans les usages métier. Ce cadrage a permis de définir un modèle pivot utile, des contrôles de qualité pragmatiques et un périmètre réaliste pour les premiers lots.

Le delivery a été piloté dans Jira avec des sprints itératifs. Les user stories ont été priorisées selon leur valeur : sécuriser d’abord l’ingestion et la normalisation, puis l’historisation et la restitution API, puis renforcer progressivement la qualité de donnée, la supervision et les usages aval.

Les mises en ligne ont été sécurisées par des tests, des validations sur environnements distincts, une logique CI/CD et des mécanismes de replay contrôlé. L’objectif était de bâtir une plateforme exploitable en continu, pas un pipeline fragile difficile à maintenir.

3. Contexte business et tensions opérationnelles

Une source de vérité produit pour accélérer les décisions

Ekadanta est né d’un besoin concret : disposer d’une vision unifiée de la donnée produit à partir d’un identifiant EAN13, puis rendre cette vision directement exploitable par des équipes métier qui doivent arbitrer vite.

Avant projet, l’information était dispersée entre plusieurs services externes, parfois redondante, parfois contradictoire, souvent incomplète. Chaque vérification mobilisait du temps humain et la qualité de décision dépendait du niveau d’expertise de la personne qui recoupait les sources.

L’enjeu n’était donc pas seulement de récupérer plus de données, mais de produire une donnée fiable, comparable dans le temps et facilement distribuable à d’autres briques applicatives.

4. Souffrances initiales et limites du modèle legacy

Des process manuels coûteux et une visibilité insuffisante

Le mode opératoire initial reposait sur des consultations successives de sources externes, des copies partielles en tableurs et des rapprochements faits à la main. La principale douleur n’était pas l’accès à la donnée, mais l’impossibilité de garantir sa cohérence.

Une même référence pouvait afficher des signaux différents selon la source, sans mécanisme fiable pour expliquer l’écart ni mesurer son impact métier. Cette situation provoquait des retards d’arbitrage, des priorisations discutables et des cycles de vérification qui s’allongeaient à chaque nouveau besoin.

À cela s’ajoutait l’absence d’historisation robuste, qui empêchait de distinguer un bruit ponctuel d’une tendance réellement exploitable.

5. Objectifs métier et critères de succès

Fiabiliser, accélérer, industrialiser

Les objectifs du projet ont été définis en termes de résultat opérationnel : fiabiliser la donnée d’entrée et la donnée exposée, réduire le temps d’accès à une vue produit utilisable et industrialiser les traitements pour supporter la croissance du volume sans multiplier les interventions humaines.

Les critères de succès ont été associés à des preuves d’exploitation : baisse des corrections manuelles, meilleure stabilité des appels API internes, qualité de donnée mesurable par contrôles automatiques et capacité de reprise sur incident sans perte de continuité métier.

Le projet devait aussi rester extensible pour intégrer de nouvelles sources ou de nouveaux usages sans rework global.

6. Périmètre fonctionnel et gouvernance du projet

De l’ingestion à la restitution API

Le périmètre a été volontairement défini autour de la chaîne de valeur la plus critique : ingestion multi-sources, normalisation en modèle pivot, enrichissement métier, historisation, puis exposition via API REST.

Ce choix a évité de disperser l’effort sur des interfaces secondaires et a concentré le delivery sur la création d’un cœur fiable. Les consommations aval ont été traitées via des contrats d’interface clairs pour réduire les effets de couplage.

La gouvernance delivery a réuni métier et technique autour d’un backlog priorisé, de critères d’acceptation orientés usage et d’un suivi régulier des incidents de run.

7. Organisation delivery, lotissement et rythme

Des lots courts pour réduire le risque

Le projet a été découpé en lots progressifs : connectivité API et mappings minimaux, modèle pivot et contrôles de qualité, historisation et premiers indicateurs, puis restitution API et observabilité de production.

Cette séquence n’est pas seulement une méthode de gestion : c’est un mécanisme de réduction du risque, car chaque étape est testée sur un usage concret avant extension.

Les revues de lot intégraient systématiquement un volet métier et un volet exploitation pour éviter les livraisons techniquement propres mais difficilement opérables.

8. Architecture cible et choix technologiques

Symfony, services découplés et traitement asynchrone

Le cœur applicatif repose sur Symfony, avec une organisation en services spécialisés : connecteurs source, transformations, validation métier, persistance et exposition API.

Les traitements les plus sensibles sont exécutés de manière asynchrone afin d’absorber les variations de charge et d’isoler les indisponibilités temporaires des services tiers.

La persistance distingue les référentiels stables, les snapshots d’enrichissement et l’historique de signaux dynamiques, ce qui facilite la traçabilité et la maintenabilité.

9. APIs intégrées dans le projet

Collecter, enrichir et exposer sans ambiguïté

10. Conception data et qualité des flux

Normaliser sans perdre l’information utile au métier

La conception data a cherché un équilibre entre standardisation et richesse fonctionnelle. Un modèle trop strict fait perdre de la nuance métier ; un modèle trop permissif détruit la comparabilité.

Le travail de conception a donc défini des objets pivots clairs, enrichis de métadonnées qui conservent la provenance et le niveau de confiance.

Des contrôles automatiques ont été introduits à plusieurs niveaux : validation de schéma, cohérence inter-champs, vérification des bornes métier et détection d’anomalies temporelles.

11. Monitoring, observabilité et reprise sur incident

Rendre chaque incident diagnostiquable et rejouable

Le run a été pensé dès le cadrage avec une logique claire : un incident doit être détecté vite, compris vite et résolu sans déstabiliser le reste.

Les appels externes sont tracés avec identifiants de corrélation, les transformations critiques sont mesurées et les files asynchrones sont suivies avec des indicateurs de retard et de saturation.

La reprise sur incident est gérée par des mécanismes d’idempotence et de replay contrôlé pour éviter les duplications et sécuriser la continuité d’exploitation.

12. Résultats obtenus et KPI après mise en production

Une exploitation plus stable et des arbitrages plus rapides

13. Extrait technique de pipeline d’enrichissement

Une orchestration asynchrone orientée qualité et résilience

L’extrait ci-dessous illustre une version simplifiée du pipeline en production. Il met en évidence la logique de collecte, validation, enrichissement, persistance et exposition, avec un traitement explicite des erreurs pour éviter les blocages silencieux.

input_ean13 -> enqueue_job
job -> fetch_eansearch(ean13)
job -> fetch_amazon_context(ean13)
job -> fetch_rainforest_context(ean13)
job -> normalize_payloads()
job -> validate_business_rules()
if valid:
  persist_snapshot()
  update_history()
  publish_resource_api()
else:
  quarantine_record()
  emit_alert("data_quality_violation")

Cette logique permet de maintenir un flux principal propre tout en conservant les données en échec pour analyse.

14. Bilan projet et trajectoire d’évolution

Un socle prêt pour l’extension

Le projet Ekadanta a atteint son objectif principal : centraliser des données hétérogènes, fiabiliser leur qualité et fournir une restitution API exploitable par les métiers.

La suite naturelle consiste à élargir progressivement le nombre de connecteurs, renforcer la segmentation des usages consommateurs et enrichir les tableaux de pilotage avec de nouveaux indicateurs.

Pour les organisations qui visent une industrialisation comparable, cette étude de cas complète utilement les ressources sur l’univers Intégration API, sur les scénarios marketplace et sur l’accélération e-commerce, avec une logique de plateforme durable plutôt qu’un simple assemblage de connecteurs.

15. Témoignage client et retour terrain

Statut du témoignage pour ce projet

Aucun témoignage client publié n’est disponible à ce stade pour ce projet. Aucun verbatim n’est donc affiché volontairement.

Le retour terrain consolidé confirme néanmoins une donnée plus fiable, des arbitrages plus rapides et une exploitation beaucoup plus stable qu’avant le projet.

Pour des besoins proches, le point d’entrée recommandé reste Création d’API sur mesure.