Évaluer les créateurs IG selon la dynamique de leurs publications : un pipeline pratique en Python

Comparer deux créateurs IG à partir d’un seul instantané de profil est facile ; déterminer qui publie régulièrement et quels posts suscitent des réactions au fil du temps est plus difficile. Les vérifications ponctuelles mélangent des publications d’âges différents, et un tableur manuel devient vite obsolète. Une solution pratique consiste à collecter régulièrement les médias publics, à conserver chaque réponse comme une observation distincte et à calculer les évolutions à partir de ses propres données.

Voici une méthode opérationnelle pour un spécialiste marketing, un analyste ou un développeur qui doit comparer chaque semaine des comptes publics d’un même secteur. La collecte des données s’appuie sur l’IG Scraper API de jsonscraper ; Python gère la planification, la normalisation et la conservation de l’historique. Cet article prolonge le sujet du suivi des profils et des publications concurrentes : il met l’accent sur un modèle d’observations unifié, adapté à la création de rapports comparatifs.

Définissez d’abord ce que vous souhaitez comparer

La tâche est souvent formulée de manière générale : « trouver des créateurs efficaces ». Pour mettre en place un suivi techniquement utile, mieux vaut la préciser à l’aide de questions mesurables : à quelle fréquence les publications paraissent-elles, quels formats sont utilisés, combien de mentions J’aime et de commentaires publics sont visibles au moment de la collecte, et comment ces chiffres évoluent-ils après la publication ? Ces indicateurs aident à sélectionner des comptes à étudier manuellement ou à préparer un bilan comparatif.

Les compteurs publics sont des instantanés pris au moment de la requête. La décision essentielle en matière d’architecture n’est donc pas de choisir un modèle complexe, mais d’enregistrer l’heure de collecte avec chaque valeur. Si vous récupérez chaque nuit les informations d’un même média et remplacez la ligne précédente, vous perdez l’historique nécessaire au calcul de l’évolution. Conservez plutôt les observations sans les modifier : une ligne par publication et par heure de collecte.

La comparaison doit porter sur des périodes identiques et des publications comparables. Vous pouvez, par exemple, examiner les publications repérées pour la première fois au cours d’un même mois civil ou tenir compte de l’âge de la publication au moment de chaque instantané. Sinon, une vidéo publiée hier paraîtra moins performante qu’un ancien post simplement parce qu’elle a eu moins de temps pour accumuler des réactions.

Le pipeline : requête, normalisation, historique

Dans sa version minimale, le processus comprend quatre étapes : récupérer la liste des médias publics des profils sélectionnés, convertir la réponse selon un schéma commun, enregistrer les lignes dans un entrepôt de données et générer un rapport selon un calendrier défini. La page de l’IG Scraper API présente l’adresse de base et la liste des points de terminaison, notamment une route utilisateur permettant de récupérer les publications par lots. Avant l’intégration, vérifiez les paramètres de chaque route et les exemples de réponse dans la collection Postman.

L’adresse de base de l’API est https://ig.jsonscraper.com. Pour la vérification initiale, la documentation montre une requête de profil par nom d’utilisateur : GET /v1/user/by/username, avec les paramètres username, license_key et cache_timeout dans l’exemple publié. Pour récupérer les publications, elle indique la route GET /v1/user/medias/chunk. Consultez la documentation de cette requête pour connaître ses arguments exacts, ses champs de continuation et la structure de sa réponse ; ne transposez pas le schéma d’une route à une autre.

import os
import requests

BASE = "https://ig.jsonscraper.com"
KEY = os.environ["JSONSCRAPER_LICENSE_KEY"]


def get_profile(username: str) -> dict:
    response = requests.get(
        f"{BASE}/v1/user/by/username",
        params={
            "username": username,
            "license_key": KEY,
            "cache_timeout": 60,
        },
        timeout=30,
    )
    response.raise_for_status()
    return response.json()


print(get_profile("example_account"))

Cet exemple concis reprend la route de profil documentée et montre comment transmettre les paramètres avec une requête HTTP GET. La valeur cache_timeout=60 figure dans l’exemple publié ; utilisez-la uniquement pour les routes qui prennent ce paramètre en charge et vérifiez les détails dans la documentation. Conservez la clé dans une variable d’environnement, et non dans le code ou une application exécutée dans le navigateur.

Ajoutez la récupération des publications

Après avoir vérifié le profil, ajoutez une requête à la liste des médias. La page de l’API répertorie GET /v1/user/medias/chunk ; pour traiter le résultat, suivez la logique de récupération par lots décrite dans la documentation. Les noms des paramètres et la condition de fin de pagination doivent provenir de la description à jour de cette requête dans Postman, plutôt que d’être déduits du nom de la route.

Le code ci-dessous est une structure de requête réseau, et non un contrat d’endpoint prêt à l’emploi : avant de l’exécuter, renseignez params avec les arguments documentés. Une fois la réponse obtenue, l’adaptateur ne doit lire que les champs confirmés par le JSON réel de la route choisie.

def fetch_media_chunk(username: str, params: dict) -> dict:
    query = {
        **params,
        "username": username,
        "license_key": KEY,
    }
    response = requests.get(
        f"{BASE}/v1/user/medias/chunk",
        params=query,
        timeout=30,
    )
    response.raise_for_status()
    return response.json()

Écrivez ensuite une fonction adaptatrice qui convertit la réponse dans votre format interne. Pour l’analyse, vous aurez peut-être besoin d’un identifiant stable pour chaque publication, de l’auteur, du lien, de la date de publication, du type de média et des compteurs publics disponibles. Vérifiez les noms et les types exacts des champs dans la documentation et dans l’exemple JSON. Si une métrique est absente, stockez une valeur vide plutôt que zéro : zéro indique qu’un compteur a été mesuré à cette valeur, tandis qu’une valeur vide signale l’absence de données.

def normalize_media(item: dict, username: str, observed_at: str) -> dict:
    # Indiquez les clés uniquement après avoir vérifié le JSON de l’endpoint choisi.
    return {
        "username": username,
        "media_id": item.get("DOCUMENTED_MEDIA_ID_KEY"),
        "media_url": item.get("DOCUMENTED_MEDIA_URL_KEY"),
        "published_at": item.get("DOCUMENTED_PUBLISHED_AT_KEY"),
        "media_type": item.get("DOCUMENTED_MEDIA_TYPE_KEY"),
        "likes": item.get("DOCUMENTED_LIKE_COUNT_KEY"),
        "comments": item.get("DOCUMENTED_COMMENT_COUNT_KEY"),
        "observed_at": observed_at,
    }

Remplacez les noms provisoires par les clés exactes de la réponse de l’endpoint concerné et verrouillez le mappage à l’aide d’un test fondé sur un exemple JSON enregistré. Vous pourrez ainsi détecter toute modification du schéma lors d’une mise à jour de l’intégration, sans présenter des noms de champs supposés comme faisant partie d’un contrat confirmé.

Conservez les observations, pas seulement les valeurs actuelles

Un fichier CSV convient pour un prototype ; pour un usage régulier, préférez PostgreSQL, Supabase ou un entrepôt analytique. Une table d’observations peut contenir les champs username, media_id, published_at, observed_at, likes, comments et le JSON brut. La paire media_id et observed_at définit un instantané unique. Une table distincte de profils conserve la liste des comptes suivis et la date à laquelle leur suivi a commencé.

Conserver la réponse brute est utile pour le débogage et la reconstruction des données normalisées. Limitez la durée de conservation en fonction des objectifs du projet et des règles de l’organisation, contrôlez l’accès aux tables et ne collectez pas d’informations inutiles à l’analyse choisie. Pour un CRM ou des actions de marketing direct, déterminez séparément la base juridique applicable : la seule disponibilité technique de données publiques ne permet pas de trancher cette question.

CREATE TABLE media_observations (
    username TEXT NOT NULL,
    media_id TEXT NOT NULL,
    media_url TEXT,
    published_at TIMESTAMPTZ,
    observed_at TIMESTAMPTZ NOT NULL,
    media_type TEXT,
    likes BIGINT,
    comments BIGINT,
    raw_json JSONB,
    PRIMARY KEY (media_id, observed_at)
);

Ajoutez les enregistrements par lots après avoir vérifié que la réponse est valide. Lors de la relance d’une même tâche, la combinaison de clés primaires empêchera la création accidentelle d’un instantané en double ; vous pouvez utiliser dans l’application une insertion qui ignore les conflits. Une nouvelle exécution à une heure différente enregistrera une ligne distincte et prolongera la série temporelle.

Calculez des métriques qui répondent à la question

Le principal indicateur de cadence de publication est le nombre de médias uniques publiés par un compte sur une période donnée. Il est facile à calculer à partir de published_at, si ce champ est présent et correctement interprété. Pour mesurer l’évolution des réactions publiques, comparez deux observations d’un même media_id : la variation absolue des mentions J’aime correspond au compteur le plus récent moins le plus ancien ; la variation relative est égale à cette différence divisée par la valeur la plus ancienne. Le même calcul s’applique aux commentaires.

Si la valeur la plus ancienne est égale à zéro ou n’est pas disponible, la croissance relative n’est pas définie ; affichez la différence absolue et indiquez clairement qu’aucune base ne permet de calculer un pourcentage. Les compteurs peuvent évoluer entre deux observations : le rapport doit donc préciser l’intervalle entre les instantanés et l’heure de la dernière collecte. Ces informations permettent au lecteur d’interpréter correctement les chiffres.

def growth(previous, current):
    if previous is None or current is None:
        return {"delta": None, "rate": None}
    delta = current - previous
    rate = None if previous == 0 else delta / previous
    return {"delta": delta, "rate": rate}

Ne réduisez pas les comptes à un classement unique sans pondérations explicites. Un rapport pratique présente généralement côte à côte le nombre de publications, la médiane des mentions J’aime et des commentaires par publication, la répartition des formats et l’évolution des réactions sur une même période de référence. La médiane limite l’influence d’un post atypique ; le nombre de publications indique la taille de l’échantillon sur lequel repose la comparaison.

Il existe deux façons de tenir compte de l’âge d’une publication. La première consiste à relever régulièrement les compteurs, par exemple à intervalles identiques après la première détection du média. La seconde consiste à comparer des publications appartenant à une même plage temporelle, en utilisant des observations d’âges similaires. Si une exécution planifiée est manquée, ne présentez pas l’évolution réelle comme une hausse exacte sur 24 heures : calculez l’intervalle à partir des horodatages.

Automatisez l’exécution et le contrôle qualité

Planifiez la collecte avec cron, GitHub Actions ou un orchestrateur ETL. Le déroulement de la tâche est simple : lire la liste des comptes, demander les lots nécessaires, vérifier le statut HTTP et la structure de la réponse, normaliser les données, enregistrer l’instantané et consigner l’exécution. Pour chaque lancement, enregistrez le nombre de comptes traités, de médias et d’erreurs, ainsi que la durée : vous pourrez ainsi distinguer une véritable évolution de l’activité d’un échec de collecte.

Pour les erreurs temporaires, prévoyez un nombre limité de tentatives espacées par une pause et, en cas de réponse erronée, conservez le contexte de la requête sans la clé secrète. Ne lancez pas de boucle infinie sur les curseurs : l’arrêt doit dépendre des conditions de fin indiquées dans la réponse de l’endpoint. Si la documentation précise des limites ou des règles d’utilisation, adaptez la fréquence et la taille de l’échantillon en conséquence.

Le paramètre cache_timeout est indiqué sur la page de l’IG API pour les routes qui le prennent en charge. Le cache est utile lorsqu’une nouvelle requête effectuée peu après la précédente n’apporte rien ; choisissez un intervalle de collecte adapté à votre question analytique. Par exemple, un instantané quotidien convient mieux à un bilan hebdomadaire que des requêtes répétées à intervalles rapprochés sur les mêmes profils, sans objectif précis.

Avant d’activer une planification régulière, testez un petit échantillon. Enregistrez un exemple de réponse, vérifiez les identifiants et les dates, comparez les champs normalisés au JSON d’origine et contrôlez manuellement quelques lignes. Ajoutez des tests couvrant les valeurs absentes, les listes vides et les formats inattendus. En cas d’évolution de l’API, ces vérifications détecteront le problème plus rapidement qu’un rapport incohérent en fin de semaine.

Quelle place pour l’IA ?

L’IA intervient utilement à la dernière étape, pour résumer brièvement les résultats déjà calculés. Transmettez au modèle des agrégats et des liens vers les publications plutôt que l’ensemble de l’archive brute : par exemple, le nombre de médias par semaine, les réactions publiques médianes et la liste des publications ayant connu la plus forte évolution pendant un intervalle donné. Demandez au modèle de formuler des observations et d’indiquer les identifiants des enregistrements sur lesquels elles reposent.

Il vaut mieux laisser le calcul des métriques à du code classique afin que les mêmes règles produisent des résultats reproductibles. Le modèle peut rédiger une synthèse, regrouper des légendes selon des thèmes prédéfinis ou suggérer des pistes à vérifier manuellement. Pour la classification thématique, stockez l’étiquette produite par le modèle séparément de la légende d’origine et indiquez la version de l’instruction ou du classificateur, afin que les changements ultérieurs ne réécrivent pas silencieusement l’historique.

Ne transformez pas un rapport automatisé en décision automatisée concernant le recrutement, un contrat ou l’évaluation d’une personne en particulier. Utilisez les données publiques pour une analyse limitée au contenu et vérifiez les conclusions manuellement, surtout lorsqu’elles ont une incidence sur des décisions commerciales. Vous préserverez ainsi l’utilité du suivi tout en distinguant les compteurs mesurables de leur interprétation.

À quoi ressemble le résultat ?

Après plusieurs cycles de collecte, vous disposerez d’un tableau indiquant quand chaque publication a été détectée, combien de réactions elle suscitait à chaque observation et comment les indicateurs ont évolué. Un bilan hebdomadaire pourra répondre à des questions concrètes : qui a publié régulièrement, quels formats ont été le plus utilisés, quelles publications ont recueilli davantage de réactions entre des instantanés comparables et où les données restent insuffisantes pour une comparaison fiable.

Ce processus permet de remplacer les vérifications manuelles ponctuelles par une analyse reproductible. Il ne se substitue pas à une analyse qualitative du contenu : les métriques décrivent la fréquence de publication et les réactions publiques disponibles, tandis que la signification, le public et l’adéquation à une marque nécessitent une évaluation distincte. En revanche, une planification cohérente, un historique conservé et des règles de calcul explicites rendent ces évaluations vérifiables et utiles à toute l’équipe.

Pour commencer, consultez la page de l’IG Scraper API, vérifiez les paramètres de la route de publications dans la documentation Postman, puis mettez en œuvre l’adaptateur sur un compte de test et enregistrez un premier instantané. Une fois le schéma confirmé, ajoutez la planification, le contrôle des erreurs et un rapport fondé sur les métriques choisies.