# Comment enregistrer les relevés d’indicateurs Instagram sans doublons à l’import

Enregistrez chaque relevé Instagram collecté une seule fois. Utilisez une clé stable qui identifie son exécution et sa ligne source. Conservez l’heure de collecte d’origine. Ajoutez les observations ultérieures sous forme de nouvelles lignes et créez une vue distincte pour les derniers relevés. Lorsqu’un import échoue, reprenez-le avec les mêmes clés. Un import répété ne doit ajouter aucune nouvelle observation. Une nouvelle exécution de collecte doit ajouter de nouvelles observations, même lorsque les nombres restent identiques.

Un relevé est une mesure enregistrée à une heure de collecte donnée. Une observation est l’enregistrement de ce relevé dans le stockage. Ce guide propose une méthode d’import aux développeurs qui collectent déjà des indicateurs Instagram publics. Cette méthode conserve l’historique et empêche un import répété de passer pour une vérification supplémentaire.

Le programme de collecte fournit les lignes source. Votre processus d’import doit fournir les clés stables, les règles de stockage et les vérifications de reprise décrites ci-dessous. Aucune collecte ni aucun test d’import n’a été effectué pour cet article.

## Définissez ce que représente chaque ligne enregistrée

Un lecteur a posé une question publique sur le fait d’« analyser les performances des publications toutes les 24 heures pour créer une courbe semblable à celle des nouveaux indicateurs Instagram ». Cette formulation exprime un besoin de mesures répétées. Elle ne précise pas comment concevoir les reprises d’import. La méthode d’import fiable présentée ici est une proposition qui prolonge cette demande. [Question du lecteur, observée le 12 août 2026 ; date de publication indisponible et aucune utilisation du produit vérifiée](https://www.reddit.com/r/n8n/comments/1iy4oco/n8n_competitor_analysis/).

Une programmation quotidienne ne suffit pas à produire un historique fiable. Vous devez aussi distinguer deux événements :

- Une nouvelle collecte : le programme vérifie à nouveau la publication. Enregistrez une nouvelle observation.
- Un import répété : votre application lit une ligne qu’elle a déjà enregistrée. Conservez l’observation existante.

Ces événements peuvent contenir des nombres identiques. Deux vérifications qui indiquent chacune 100 vues restent deux observations. Lire deux fois une même ligne collectée ne représente toujours qu’une observation.

Distinguez les nombres affichés du nombre de personnes. Un nombre public de vues ne correspond pas à un nombre de personnes uniques. Conservez `views`, `plays` et `playsInstagram` dans des champs distincts. Ne les additionnez pas et ne remplacez pas l’un par l’autre sans règle de rapport définie.

Cette méthode concerne les compteurs publics. Elle ne donne pas accès aux statistiques privées des comptes et ne récupère pas les nombres passés que vous n’avez pas enregistrés. Les données réservées au propriétaire du compte nécessitent une source autorisée distincte. Le contrat public vérifié prévoit la collecte des indicateurs publics actuels, pas la récupération des nombres passés. [Contrat d’Instagram Metrics Scraper, vérifié le 25 octobre 2026 ; inspection de la version publique uniquement, sans exécution payante](https://apify.com/chronometrica/instagram-metrics-scraper).

Si vous devez encore choisir entre rechercher des publications récentes et vérifier des URL enregistrées, consultez le [guide de collecte Instagram récurrente](/fr/articles/chronometrica-ou-webdatalabs-suivi-regulier-indicateurs-createurs-instagram/). Faites ce choix avant de concevoir l’import.

## Conservez une table d’observations et un compte rendu d’import

Utilisez deux types d’enregistrements aux fonctions distinctes. La table d’observations contient les relevés collectés. Le compte rendu d’import indique comment votre application a traité une exécution source.

Une exécution correspond à un lancement du programme de collecte. Un jeu de données est la liste enregistrée des lignes renvoyées par ce programme. Conservez les deux identifiants pour pouvoir retrouver la source d’une observation enregistrée.

Les noms suivants sont des propositions de champs de stockage. Les champs comme `run_id` et `item_position` sont des métadonnées de votre processus : des informations sur la collecte et l’import. Ce ne sont pas de nouveaux champs de sortie de l’Actor. Un Actor est un programme de collecte hébergé.

| Champ enregistré | Élément à conserver | Objectif |
| --- | --- | --- |
| `observation_key` | Clé unique de la ligne source | Empêcher une insertion répétée |
| `run_id` | Identifiant de l’exécution source terminée, sous forme de texte | Identifier l’exécution de collecte |
| `dataset_id` | Identifiant du jeu de données source, sous forme de texte | Identifier la liste source |
| `item_position` | Position absolue d’origine de la ligne | Identifier la ligne avant les modifications |
| `postId` | Identifiant d’origine de la publication, sous forme de texte | Associer le même contenu entre les exécutions |
| `postUrl` | URL d’origine du contenu | Conserver la référence du contenu |
| `scrapedAt` | Heure de collecte d’origine | Situer le relevé dans l’historique |
| Compteurs | Chaque compteur renvoyé, séparément | Préserver le sens des indicateurs |
| Champs de statut | Statut d’origine de l’indicateur et de la ligne | Expliquer les valeurs manquantes ou inutilisables |
| `original_json` | Ligne d’origine complète | Conserver les éléments de preuve source |
| `imported_at` | Heure à laquelle votre application a enregistré la ligne | Suivre le travail d’import séparément |

JSON est un format texte pour les données structurées. Enregistrez le JSON d’origine avant de renommer ou de supprimer des champs, ou de transformer une ligne source en plusieurs enregistrements.

Conservez `postMetricStatus`, `status` et `statusReason` lorsqu’ils sont fournis. Conservez les autres champs de statut renvoyés dans le JSON d’origine. N’inventez pas de valeurs de statut et ne supposez pas une structure de statut non documentée. Le contrat de sortie vérifié comprend l’identité du contenu, les compteurs, l’heure de collecte et les champs de statut. [Version publique par défaut, vérifiée le 25 octobre 2026 ; champs documentés uniquement, sans test d’exécution](https://api.apify.com/v2/acts/Y7Ib4ARpUHw5Ue8op/builds/default).

Pour chaque tentative d’import, enregistrez un compte rendu avec les détails suivants :

- L’identifiant de l’exécution, l’identifiant du jeu de données et l’état d’achèvement de la source.
- Les paramètres d’export fixes et la plage de lignes source en cours d’import.
- Les lignes acceptées, déjà enregistrées et rejetées.
- La dernière position source traitée et enregistrée de façon durable.
- L’heure de début, l’heure de fin et l’état d’achèvement de l’import.
- Les motifs de rejet des lignes.

« Acceptée » signifie qu’une nouvelle observation a été enregistrée. « Déjà enregistrée » signifie que cette même observation source était déjà stockée. « Rejetée » signifie que la ligne doit être corrigée ou examinée selon les règles que vous avez définies.

Gardez les totaux de chaque tentative d’import séparés. Additionner les comptes rendus de plusieurs reprises ne donne pas le nombre d’observations distinctes.

## Choisissez la clé d’observation avant de charger les lignes

Une clé est une valeur qui identifie un enregistrement. Votre clé d’observation doit identifier la ligne source, pas seulement la publication Instagram.

Utiliser uniquement `postId` fusionnerait toutes les vérifications ultérieures de cette publication. Utiliser l’heure d’import créerait une nouvelle observation à chaque reprise. Une légende ou une position dans la liste du profil d’un créateur ne permet pas non plus d’identifier une observation collectée.

Pour un jeu de données stable issu d’une exécution terminée, utilisez l’identifiant de l’exécution et la position d’origine de l’élément dans le jeu de données. Conservez l’identifiant du jeu de données avec cette clé. Une règle de stockage pratique impose l’unicité de la combinaison de ces trois éléments.

Une contrainte d’unicité empêche la table d’accepter deux enregistrements avec cette même combinaison. Appliquez-la dans le système de stockage. Ne vous fiez pas uniquement à une vérification dans le code de l’application avant l’insertion.

Suivez ces étapes :

1. Sélectionnez une exécution source terminée lorsque votre règle de rapport exige des données stables issues d’une exécution terminée.
2. Enregistrez son identifiant d’exécution et son identifiant de jeu de données.
3. Fixez les paramètres d’export brut et l’ordre croissant des lignes source.
4. Enregistrez la plage source que vous comptez importer.
5. Attribuez les positions absolues d’origine avant de trier, de filtrer ou de transformer les lignes en plusieurs enregistrements.
6. Conservez ces positions sans modification à chaque reprise.

La position absolue est la position dans la liste source complète. Si une page contient les positions 0 à 99, la suivante commence à 100. Elle ne recommence pas à 0. Précisez si vos positions commencent à 0 ou à 1.

Selon la documentation d’Apify, le stockage des jeux de données autorise uniquement les ajouts : vous pouvez ajouter des éléments, mais pas modifier ni supprimer les éléments existants. Cela permet de conserver les lignes source. Toutefois, un export filtré ou réordonné ne fournit pas à lui seul une identité fiable pour l’import. [Documentation des jeux de données Apify, vérifiée le 25 octobre 2026 ; faits sur le stockage par ajout uniquement et la récupération, sans garantie concernant l’import](https://docs.apify.com/storage/dataset).

Si vous ne pouvez pas conserver des positions source stables, utilisez une empreinte de hachage documentée, calculée à partir d’une représentation fixe de la ligne d’origine. Une empreinte de hachage est un identifiant calculé à partir du contenu. Utilisez les mêmes champs, la même représentation textuelle et le même calcul à chaque reprise. Conservez aussi les références de l’exécution et du jeu de données.

Cette solution demande de la prudence. Des lignes identiques peuvent produire la même empreinte, même si elles occupaient des positions source différentes. Définissez si ces lignes représentent une ou deux observations avant d’utiliser cette méthode. Préférez des positions source stables lorsque vous devez conserver chaque ligne renvoyée.

Si une clé existante renvoie à un contenu d’origine différent, arrêtez l’import et examinez le conflit. N’écrasez pas l’observation enregistrée sans le signaler et ne traitez pas ce cas comme une répétition normale.

## Enregistrez les lignes et la progression en une seule opération

Le principal risque lors d’une reprise se situe entre l’enregistrement d’une ligne et celui de la progression. Votre application peut s’arrêter après la réussite de l’un, mais avant celle de l’autre.

Une transaction enregistre des modifications liées en une seule opération. Si votre outil de stockage prend en charge les transactions, validez ensemble les observations acceptées et leur position de progression. Les modifications correspondantes du compte rendu doivent rester cohérentes avec cette validation.

Suivez cette séquence d’import :

1. Lisez les lignes source suivantes avec leurs positions d’origine.
2. Vérifiez chaque ligne selon vos règles d’acceptation.
3. Construisez sa clé d’observation.
4. Insérez une nouvelle observation lorsque la clé est absente.
5. Comptez une observation existante correspondante comme une ligne déjà enregistrée.
6. Enregistrez les lignes rejetées et leurs motifs de rejet.
7. Enregistrez la progression uniquement lorsque les lignes et les enregistrements de rejet sont stockés de façon durable.

« Durable » signifie que le système de stockage a enregistré la modification de façon à la conserver après l’arrêt du processus d’import.

Un compteur manquant ne doit pas, à lui seul, entraîner le rejet d’une ligne source valide par ailleurs. Cette ligne peut encore enregistrer une tentative de collecte et les autres compteurs disponibles. Conservez la valeur manquante et son statut.

Conservez assez d’informations source pour examiner les lignes rejetées. Une position de progression située après une ligne rejetée ne doit pas masquer cette ligne. Enregistrez son rejet avant de faire avancer la progression, ou arrêtez-vous à cette ligne jusqu’à la résolution du problème.

Si votre outil de stockage ne peut pas valider ensemble les lignes et la progression, enregistrez les lignes avant de faire avancer la progression. Après un arrêt, relancez l’import de toute plage incertaine avec la même clé unique. Cela peut produire des lignes déjà enregistrées, mais ne doit pas créer d’observations supplémentaires.

Ne créez pas de nouvelle valeur `scrapedAt` lors d’un import répété. `imported_at` peut changer entre les tentatives. L’heure de collecte ne peut pas changer.

## Suivez un import et sa reprise

L’exemple suivant est une fiction originale. Il ne s’agit ni d’une sortie d’Actor, ni d’un résultat client, ni d’un résultat de test. Toutes les heures se rapportent au même jour fictif en UTC, une norme horaire commune.

L’exécution A contient deux lignes. Dans cet exemple, les positions source commencent à 0.

| Exécution | Position d’origine | Publication | Heure de collecte | Vues |
| --- | --- | --- | --- | --- |
| A | 0 | P1 | 10:00 UTC | 100 |
| A | 1 | P2 | 10:01 UTC | Manquant |
| B | 0 | P1 | 11:00 UTC | 120 |

Importez d’abord l’exécution A. La table enregistre P1 et P2 comme deux observations. Aucun nombre de vues n’est disponible pour P2. Cette publication reste une observation enregistrée dont le nombre de vues est manquant.

Relancez maintenant l’import de l’exécution A. Les deux clés de lignes source existent déjà. L’import n’ajoute aucune observation et signale deux lignes déjà enregistrées.

Importez ensuite l’exécution B. Sa ligne P1 possède un identifiant d’exécution différent. Enregistrez-la comme une nouvelle observation, même si P1 existe déjà dans la table.

| Tentative d’import | Nouvelles observations | Lignes déjà enregistrées | Total des observations enregistrées |
| --- | --- | --- | --- |
| Premier import de A | 2 | 0 | 2 |
| Nouvel import de A | 0 | 2 | 2 |
| Premier import de B | 1 | 0 | 3 |

Le calcul est le suivant :

- Premier import : 0 observations + 2 nouvelles observations = 2 observations.
- Import répété : 2 observations + 0 nouvelles observations = 2 observations.
- Nouvelle exécution : 2 observations + 1 nouvelle observation = 3 observations.

Il y a trois observations issues de deux exécutions. Les trois tentatives ont donné lieu à cinq traitements de lignes, mais ces traitements ne représentent pas cinq observations. Le nombre de vues de P2 reste manquant. Il ne devient pas égal à zéro.

Considérez maintenant un autre scénario de reprise dans cette même fiction originale. Le premier import de A s’arrête après l’enregistrement de P1. Il n’a pas enregistré P2.

Si la progression enregistrée est fiable, reprenez à P2. Cette reprise ajoute une observation. La table contient finalement deux observations issues de A.

Si la progression est incertaine, relancez l’import de A depuis le début. P1 est comptée comme une ligne déjà enregistrée et P2 comme une nouvelle observation. La table contient toujours, à la fin, deux observations issues de A.

Après l’import de B, les deux scénarios de reprise produisent les trois mêmes observations enregistrées. Votre vérification de la reprise doit confirmer ce résultat.

## Créez l’affichage des derniers relevés sans modifier l’historique

Une vue est un résultat assemblé à partir d’enregistrements stockés. Créez une vue des derniers relevés au lieu de remplacer les anciennes observations.

Classez les observations dont l’heure est valide selon `scrapedAt`, et non selon l’heure d’import. Importer aujourd’hui l’exécution terminée d’hier ne doit pas faire paraître le nombre d’hier plus récent qu’un relevé collecté aujourd’hui.

Affichez séparément deux informations pour chaque publication :

- La dernière tentative de collecte enregistrée.
- Le dernier relevé utilisable pour chaque compteur requis, avec son heure d’origine.

Une ligne récente peut avoir un nombre de vues manquant alors qu’une ligne plus ancienne possède un nombre de vues utilisable. Vous pouvez conserver l’ancienne valeur comme référence. Affichez toutefois son heure ancienne et le résultat récent manquant. Ne présentez pas l’ancienne valeur comme une nouvelle mesure.

Le « dernier relevé utilisable » peut varier selon le compteur. La dernière ligne avec un nombre de mentions J’aime utilisable peut différer de la dernière ligne avec un nombre de vues utilisable. Conservez leurs heures séparément.

Documentez ces cas de classement avant la mise en service :

- Heures de collecte identiques : conservez les deux observations source. Signalez l’égalité ou appliquez une règle d’affichage explicite. Une règle d’affichage ne prouve pas quel relevé a eu lieu en dernier.
- Heure de collecte manquante : conservez la ligne source, mais excluez-la du classement chronologique jusqu’à son examen.
- Heure de collecte invalide : enregistrez le problème. Ne la remplacez pas par l’heure d’import sans l’indiquer clairement.
- Aucune ligne renvoyée : enregistrez séparément cette lacune de collecte. N’inventez pas d’observation ni de valeur égale à zéro.

Pour les calculs ultérieurs, consultez le [guide des rapports mensuels Instagram](/fr/articles/separer-publications-anciennes-et-nouvelles-rapport-mensuel-vues-instagram/). Cette méthode d’import conserve les observations ; elle ne fournit pas les relevés manquants aux limites des mois. Le [guide de l’historique des indicateurs](/fr/articles/evolution-metriques-publications-facebook/) explique aussi pourquoi les heures réelles d’observation comptent lorsque des vérifications manquent.

## Utilisez une entrée de collecte minimale, puis vérifiez l’import

La documentation d’Instagram Metrics Scraper de Chronometrica décrit les entrées directes de contenu et les champs nécessaires à cette méthode de stockage proposée. Cette adéquation documentée ne signifie pas que le programme crée votre table d’historique ou impose vos clés d’import.

Une Task est un ensemble de paramètres d’entrée enregistrés pour un Actor. La Task publique Instagram Post Metrics Tracker fournit un point de départ. La vérification de page fournie a seulement confirmé sa présence publique. Elle n’a pas vérifié les paramètres enregistrés après authentification ni exécuté cette configuration. [Instagram Post Metrics Tracker, vérifié le 25 octobre 2026 ; présence de la page publique uniquement, sans vérification des entrées après authentification ni exécution payante](https://apify.com/chronometrica/instagram-metrics-scraper/examples/instagram-post-metrics-tracker).

Utilisez cette configuration d’entrée minimale fournie :

```json
{"maxItems":1,"mode":"contentUrls","startUrls":["https://www.instagram.com/reel/DIwcCZgxVZP/"]}
```

Utilisez une entrée de collecte minimale, puis vérifiez l’import

`mode` choisit la façon dont l’Actor traite les entrées. `contentUrls` sélectionne les vérifications directes de contenu. `startUrls` contient les URL des contenus visés. `maxItems` limite le nombre de lignes d’indicateurs renvoyées.

Remplacez l’URL d’exemple par l’URL connue d’une publication publique ou d’un Reel public. Un Reel est un format vidéo d’Instagram. Remplacez la liste d’exemple au lieu d’y ajouter votre URL. Examinez les paramètres enregistrés avant utilisation.

Cette configuration d’entrée a passé une vérification statique du schéma. Cette vérification confirme la conformité de sa structure au schéma public fourni. Elle ne confirme ni la disponibilité actuelle du contenu ni la réussite de la collecte. [Schéma public des entrées, vérifié le 25 octobre 2026 ; validation statique uniquement, sans exécution payante](https://api.apify.com/v2/acts/Y7Ib4ARpUHw5Ue8op/builds/default).

Les vérifications suivantes sont des actions proposées au lecteur :

1. Collectez un contenu public visé et conservez les références de l’exécution terminée et du jeu de données.
2. Importez ses lignes et enregistrez les nombres de lignes acceptées, déjà enregistrées et rejetées.
3. Importez à nouveau la même source. Confirmez qu’aucune nouvelle observation n’est ajoutée.
4. Arrêtez un import en cours, puis reprenez-le. Confirmez que les clés finales des lignes source correspondent à celles d’un import complet.
5. Lancez une nouvelle exécution de collecte pour le même contenu. Confirmez qu’elle crée une nouvelle observation.
6. Confirmez que toutes les valeurs `scrapedAt` enregistrées correspondent à celles de leurs lignes source.
7. Confirmez que les compteurs manquants restent manquants et que les anciens nombres utilisables conservent leurs heures d’origine.

Une exécution terminée ne prouve pas que chaque contenu demandé possède un compteur utilisable. Comparez la liste des contenus visés aux lignes renvoyées et enregistrez les lacunes séparément.

## Fiabilisez le prochain import

Commencez par la vérification complète la plus simple : un jeu de données source issu d’une exécution terminée, une table d’observations et un compte rendu d’import. Importez ce jeu de données deux fois. Passez à la collecte répétée uniquement lorsque le deuxième import n’ajoute aucune observation et qu’une exécution ultérieure ajoute une nouvelle observation.

Utilisez [Instagram Metrics Scraper, contrat vérifié le 25 octobre 2026 ; collecte publique adaptée selon la documentation, sans test d’exécution pour ce guide](https://apify.com/chronometrica/instagram-metrics-scraper) pour collecter les lignes publiques dont votre application a besoin. Distinguez les heures de collecte, d’import et d’affichage. Si la vérification de la reprise échoue, corrigez la clé d’observation ou la gestion de la progression avant d’ajouter davantage de données collectées à intervalles programmés.

## Sources et lectures complémentaires

- [Contrat public d’Instagram Metrics Scraper, vérifié le 25 octobre 2026 ; entrées et sorties publiques documentées, sans exécution payante ni test de fonctionnement actuel](https://apify.com/chronometrica/instagram-metrics-scraper)
- [Version publique par défaut 1.0.35, vérifiée le 25 octobre 2026 ; éléments de preuve sur le schéma et les champs documentés, sans mesure du comportement à l’exécution](https://api.apify.com/v2/acts/Y7Ib4ARpUHw5Ue8op/builds/default)
- [Documentation des jeux de données Apify, vérifiée le 25 octobre 2026 ; éléments de preuve sur le stockage par ajout uniquement et la récupération, l’identité stable pour l’import exige toujours un ordre source fixe](https://docs.apify.com/storage/dataset)
- [Task Instagram Post Metrics Tracker, vérifiée le 25 octobre 2026 ; présence publique de la configuration uniquement, sans vérification des paramètres enregistrés après authentification ni exécution payante](https://apify.com/chronometrica/instagram-metrics-scraper/examples/instagram-post-metrics-tracker)
- [Question sur les mesures récurrentes, observée le 12 août 2026 ; date de publication indisponible, une question publique plutôt qu’une preuve de demande ou d’utilisation du produit](https://www.reddit.com/r/n8n/comments/1iy4oco/n8n_competitor_analysis/)