# Un catalogue unique construit à partir de plusieurs fournisseurs

> Un distributeur d'objets publicitaires personnalisables travaillait avec plusieurs fournisseurs européens, chacun avec son propre format de catalogue, ses propres photos et sa propre logique de stock.

- Source canonique : [https://allaux.fr/realisations/catalogue-multifournisseurs-b2b](https://allaux.fr/realisations/catalogue-multifournisseurs-b2b)
- Langue : FR
- Dernière mise à jour : 2026-07-26

## Le contexte

La boutique vendait des objets publicitaires personnalisables à des entreprises clientes. Le catalogue réel ne venait pas d'un seul endroit : plusieurs fournisseurs européens du secteur fournissaient chacun leurs références, avec des formats d'échange différents, des nomenclatures de catégories qui ne correspondaient pas d'un fournisseur à l'autre, et des fréquences de mise à jour variables. Gérer ça à la main, fournisseur par fournisseur, aurait mobilisé une personne à temps plein rien que pour maintenir le catalogue à jour.

L'objectif était d'obtenir un catalogue unique, cohérent pour le client final, sans que la multiplicité des sources ne se voie côté boutique.

## Ce que j'ai fait

1. **Étude des sources fournisseurs** — Analyse des API et des flux disponibles chez chaque fournisseur, avec leurs particularités : authentification propre, pagination différente, champs de disponibilité pas toujours fiables.
2. **Construction d'une couche de normalisation** — Développement d'un module PrestaShop qui traduit chaque format fournisseur vers un modèle de données commun, avant import dans le catalogue.
3. **Mapping des catégories** — Mise en place d'une table de correspondance entre les catégories propres à chaque fournisseur et l'arborescence unique présentée aux clients.
4. **Déduplication des références proches** — Détection des produits identiques ou très proches proposés par plusieurs fournisseurs, pour éviter d'afficher deux fois le même article sous deux fiches distinctes.
5. **Synchronisation planifiée** — Mise en place de tâches planifiées qui reprennent les stocks et les prix à intervalle régulier, avec journalisation des écarts détectés.

## Ce qui a demandé le plus de soin

- **Fiabilité du stock** — Certains fournisseurs annoncent une disponibilité qui ne reflète pas toujours la réalité au moment de la commande : le module signale les écarts plutôt que de les masquer.
- **Cohérence des fiches produit** — Les descriptions et caractéristiques techniques arrivent dans des formats hétérogènes, avec des unités et des libellés qu'il a fallu harmoniser.
- **Résilience aux pannes fournisseur** — Un fournisseur indisponible ponctuellement ne doit pas bloquer la synchronisation des autres ni casser le catalogue existant.

## Résultat

> Le catalogue s'est mis à jour de façon autonome, sans intervention manuelle fournisseur par fournisseur, avec une cohérence de présentation maintenue côté client malgré la diversité des sources.

## FAQ

### Combien de fournisseurs peuvent être intégrés de cette façon ?

Le principe reste le même quel que soit le nombre de fournisseurs : chacun passe par sa propre couche de normalisation avant d'alimenter le catalogue commun. La complexité croît surtout avec l'hétérogénéité des formats, pas avec le nombre.

### Que se passe-t-il si un fournisseur change son format d'échange ?

Seule la couche de normalisation propre à ce fournisseur doit être adaptée. Le reste du catalogue et les autres sources ne sont pas affectés.

### Comment sont gérés les doublons entre fournisseurs ?

Une logique de rapprochement sur les références et les caractéristiques principales détecte les produits identiques ou très proches, avec un arbitrage manuel possible sur les cas ambigus.

### Le catalogue peut-il évoluer après la mise en production ?

Oui, ajouter un fournisseur supplémentaire ou retirer une source existante ne remet pas en cause l'architecture mise en place.