---
type: "blog"
id: 24
url: "https://prestadev.pl/fr/blog/news/catalogue-meta-prestashop-id-variantes-pixel"
markdown_url: "https://prestadev.pl/fr/markdown/blog/24.md"
title: "Le catalogue Meta ne reconnaît pas les produits de PrestaShop ? Vérifiez l’ID, les variantes et le Pixel"
description: "Vérifiez la conformité de l’ID produit dans PrestaShop, le flux Meta et l’événement Pixel. Préfixes, variantes, content_ids ainsi qu’un contrôle séparé de la déduplication de l’achat."
language: "fr"
published: "2026-09-13 20:06:03"
updated: "2026-09-13 20:06:03"
author: "Patryk Marek"
category: "News"
---

# Le catalogue Meta ne reconnaît pas les produits de PrestaShop ? Vérifiez l’ID, les variantes et le Pixel

Le produit est dans le catalogue, mais l’événement ne lui correspond pas ? Comparez le préfixe, le séparateur et le numéro de combinaison. Voir un exemple d’identifiants de flux et de Pixel correspondants.

**Si les événements de PrestaShop ne correspondent pas aux produits du catalogue Meta, comparez l’identifiant complet de l’offre avec la valeur envoyée dans `content_ids`.** Le préfixe, le séparateur et le numéro de combinaison comptent. Pour l’intégration, les identifiants `812`, `ps_812-41` et `ps_812_41` désignent des chaînes différentes, même si une personne peut les associer à la même fiche produit.

 ![Le même identifiant produit sur la fiche du catalogue et dans l’événement Pixel](https://prestadev.pl/modules/ph_simpleblog/featured/24.jpg) Ce guide aide à vérifier la coopération entre le flux produit et le Pixel. Les exemples sont démonstratifs, sans données clients. Ils ne constituent ni une capture d’écran d’un compte publicitaire ni une confirmation des résultats de campagne.

 ## Le catalogue, le Pixel et l’API Conversions remplissent des rôles différents

 Le catalogue contient les offres : identifiants, noms, photos, prix et disponibilité. Le flux est l’un des moyens de fournir ces données. Le Pixel transmet des événements depuis le navigateur, par exemple la consultation d’un produit ou l’ajout au panier. L’API Conversions permet d’envoyer des événements côté serveur.

 Un catalogue correctement récupéré ne prouve pas que les événements font référence aux bonnes offres. De même, la présence d’un événement d’achat ne prouve pas que chaque produit de cet achat a une correspondance dans le catalogue. Déterminez d’abord quelle partie de la connexion vous diagnostiquez.

 Vérifiez aussi que vous consultez le bon catalogue et la bonne source d’événements. Avec plusieurs boutiques, un ancien Pixel ou un flux de test, il est possible de comparer des données techniquement correctes provenant de configurations différentes.

 ## Exemple : un produit, deux combinaisons

 Prenons un produit avec l’ID `812` et les combinaisons `41` et `42`. Le flux exporte les variantes comme des offres distinctes avec le préfixe `ps_` et un tiret. Pour la première combinaison, l’identifiant est donc `ps_812-41`.

 | Emplacement | Combinaison 41 | Combinaison 42 | Ce que vous comparez |
| --- | --- | --- | --- |
| PrestaShop | Produit 812, combinaison 41. | Produit 812, combinaison 42. | Identité du produit et de la variante sélectionnée. |
| Flux : g:id | ps\_812-41 | ps\_812-42 | Identifiant de l’offre précise dans le catalogue. |
| Événement : content\_ids | \["ps\_812-41"\] | \["ps\_812-42"\] | S’il pointe vers l’offre correspondant à l’action de l’utilisateur. |
| Groupe dans le flux d’exemple | 812 | 812 | Le groupe commun des variantes ; il ne remplace pas automatiquement l’ID de l’offre. |

 Le contrôle le plus simple consiste à copier la valeur de l’offre traitée et celle de l’événement sur deux lignes. Comparez-les caractère par caractère. Ne supprimez pas un préfixe « inutile » avant d’avoir déterminé à quoi se réfèrent les autres intégrations.

 ## Qu’a-t-on vérifié dans les modules PrestaDev ?

 Dans le code de **Facebook Pixel Pro 1.4.5**, il est possible de choisir la manière de construire l’ID et le préfixe optionnel. L’un des chemins crée un ID produit relié à l’ID de combinaison par un tiret, un autre utilise un trait de soulignement. Il existe aussi des modes basés sur d’autres champs. C’est cette configuration qu’il faut comparer à l’export réel, et non la choisir uniquement d’après son nom.

 Le code vérifié du **flux Meta 2.9.2** enregistre, lors de l’export des combinaisons, `g:id` sous la forme préfixe + ID produit + tiret + ID combinaison. Avec ce réglage, la variante `ps_812_41` envoyée par le Pixel ne sera pas identique à `ps_812-41` dans le flux. Dans ce chemin, le flux enregistre le `g:item_group_id` commun comme ID produit sans préfixe.

 Il s’agit d’une confirmation de la manière dont les données sont construites dans les versions de code mentionnées, et non d’une preuve de correspondance sur un compte Meta précis. Après modification des paramètres, il faut toujours vérifier le fichier généré, l’import du catalogue et l’événement réel.

 ## `content_ids` et `content_type` doivent être cohérents

 `content_ids` contient les identifiants liés à l’événement. `content_type` définit la manière de faire référence aux produits ou à leurs groupes. Il ne faut pas remplacer `product` par `product_group` uniquement pour faire disparaître un message : cela change la signification des identifiants auxquels l’événement se réfère.

 Dans l’exemple présenté, nous choisissons l’offre précise de la variante et `content_type: "product"`. Un jeu de données simplifié pour la consultation d’une variante ressemble à ceci :

 ```
{
  "content_ids": ["ps_812-41"],
  "content_type": "product",
  "value": 129.00,
  "currency": "PLN"
}
```

 Il s’agit d’un extrait de données d’un événement d’exemple, et non d’un code d’implémentation complet ni d’une requête API. Les types des champs `content_ids`, `content_type`, `value` et `currency` peuvent être vérifiés dans le [SDK officiel de Meta — CustomData](https://github.com/facebook/facebook-php-business-sdk/blob/main/src/FacebookAds/Object/ServerSide/CustomData.php). Pour le diagnostic d’un compte précis, vérifiez également les messages actuels du Gestionnaire d’événements.

 ## Après avoir changé de variante, effectuez un nouveau test

 Un ID correct lors de la première ouverture de la page ne suffit pas. Le thème peut changer de variante sans recharger le document. L’intégration des événements doit utiliser les données correspondant à l’action actuelle, au lieu de rester sur la combinaison par défaut.

 1. Choisissez un produit avec au moins deux combinaisons présentes dans le flux.
2. Notez leurs identifiants complets à partir du fichier et du catalogue après import.
3. Ouvrez le produit dans une session de test contrôlée, avec les bons paramètres de consentement.
4. Vérifiez les données de l’événement concernant la première variante.
5. Changez de combinaison et ajoutez la variante sélectionnée au panier.
6. Comparez l’ID, la quantité, la valeur et la devise de l’événement avec le panier actuel.
7. Vérifiez que la même action n’est pas également envoyée par une deuxième installation du Pixel, par exemple via un autre module ou un gestionnaire de balises.

 N’interprétez pas l’absence d’événement comme une erreur du catalogue avant d’avoir vérifié les consentements, le blocage des scripts et la configuration de la source d’événements. L’envoi de données côté serveur exige également une configuration correcte de la confidentialité ; le CAPI ne doit pas être considéré comme un moyen de contourner la décision de l’utilisateur.

 ## La valeur et la devise constituent un contrôle distinct

 Des ID identiques ne confirment pas un montant correct. Pour un événement produit, vérifiez le prix de la combinaison sélectionnée, et pour un achat, la définition convenue de la valeur de la commande entière. Ne comparez pas une unité avec le total du panier ni un montant hors taxes avec un montant TTC sans avoir déterminé comment fonctionne l’implémentation.

 La devise doit correspondre à la valeur envoyée. Pour une boutique multidevise, effectuez un test distinct après son changement. Si les données proviennent d’une commande, comparez-les à la commande enregistrée, et non au prix catalogue actuel relevé plus tard.

 ## Correspondance produit et déduplication d’achat

 La déduplication reconnaît deux copies du même événement envoyées depuis le navigateur et le serveur. Elle ne sert pas à relier des variantes de produit. Dans le SDK officiel de Meta, il est indiqué que, pour les événements correspondants, le `eventID` côté navigateur doit correspondre au `event_id` côté serveur, et que le nom de l’événement est également utilisé dans le processus. Source : [Meta — description de Event et setEventId](https://github.com/facebook/facebook-php-business-sdk/blob/main/src/FacebookAds/Object/ServerSide/Event.php).

 | Identifiant | Exemple démonstratif | Ce qu’il doit reconnaître |
| --- | --- | --- |
| content\_ids | \["ps\_812-41"\] | Le produit ou la variante lié(e) à l’action. |
| eventID / event\_id | purchase\_demo\_1001 | Un événement d’achat précis envoyé par deux canaux. |

 Un `event_id` fixe égal à l’ID produit serait une mauvaise idée pour différents achats de ce produit. À l’inverse, des identifiants d’événement cohérents ne corrigeront pas un `content_ids` erroné. Vérifiez ces deux éléments séparément. Si vous analysez également GA4, utilisez le [guide existant sur la mesure des achats](https://prestadev.pl/pl/blog/baza-wiedzy/ga4-prestashop-brak-zakupow-pomiar-sprzedazy).

 ## Par quoi commencer pour corriger l’intégration ?

 Choisissez un produit et conservez trois données : l’ID dans la boutique, l’ID importé dans le catalogue et l’ID de l’événement. Déterminez le format, modifiez le bon paramètre, actualisez la source nécessaire et refaites le test. Ne modifiez pas en même temps le préfixe, le séparateur, la manière d’exporter les variantes et plusieurs installations du Pixel — cela rendra plus difficile l’identification de la correction qui a résolu le problème.

 **Vérifiez la cohérence du format d’ID dans les deux intégrations :** [Facebook Pixel Pro](https://prestadev.pl/pl/facebook-pixel-pro-modul-dla-prestashop.html) et [flux de produits XML pour Meta](https://prestadev.pl/pl/export-produktow-xml-dla-dynamicznych-reklam-facebook-do-prestashop.html). Leur configuration doit découler du même modèle de catalogue. Une correspondance correcte est un élément de la qualité des données, et non une garantie de rentabilité des publicités.

 Vérification de fond : 13 septembre 2026. Le code de Facebook Pixel Pro 1.4.5, du flux Meta 2.9.2 ainsi que les définitions publiques du SDK officiel de Meta ont été vérifiés. Aucune publication ni aucun achat test n’ont été effectués sur le compte publicitaire du client.