Transformer les profils IG en journal quotidien des changements

Lorsqu’un spécialiste du marketing vérifie manuellement des dizaines de profils IG publics, la principale perte ne vient pas du temps passé à ouvrir les pages, mais de l’absence d’un historique comparable. Un instantané indique le nombre d’abonnés aujourd’hui ; deux instantanés permettent de calculer la différence sur une période donnée. Pour surveiller simplement des profils, il est possible d’automatiser la requête, de ne conserver que les champs nécessaires et d’obtenir un tableau des variations.

Voici un exemple minimal fonctionnel en Python : il récupère les informations d’un profil à partir de son nom d’utilisateur via l’API IG Scraper et écrit une ligne JSONL horodatée. Le résultat constitue une petite source d’historique que vous pouvez connecter à cron, n8n ou à votre propre système de stockage. La documentation de l’API IG décrit officiellement la route et ses paramètres.

À quoi sert un instantané quotidien ?

Supposons qu’une équipe suive les comptes publics de marques ou de partenaires et souhaite repérer les changements du nombre d’abonnés, de publications ou du statut de vérification. La consultation d’une page affiche les valeurs actuelles, mais ne conserve pas à elle seule l’état de la semaine précédente. Il faut donc d’abord déterminer les champs importants, puis les enregistrer avec la date de l’observation.

La route /v1/user/by/username accepte le paramètre obligatoire username. La réponse comprend notamment les champs follower_count, following_count, media_count, is_verified, is_private et biography. Cet ensemble convient à un instantané de profil ; il ne contient pas l’historique des publications et n’explique pas, à lui seul, la raison des variations des indicateurs.

Le script a volontairement une portée limitée : récupérer un ensemble de champs observables à un moment donné et le comparer aux enregistrements précédents. L’analyste peut ainsi voir, par exemple, que le nombre d’abonnés a changé entre les dates enregistrées, puis procéder à des vérifications supplémentaires indépendamment de la collecte automatisée.

Préparer la clé et la liste de comptes

Installez la bibliothèque de requêtes et définissez la clé API dans une variable d’environnement. Ne placez pas le secret dans le fichier source, le dépôt ou la sortie du programme. L’API utilise le paramètre de requête license_key ; la bibliothèque ci-dessous construit elle-même la chaîne de paramètres.

python -m pip install requests
export JSONSCRAPER_INSTAGRAM_LICENSE_KEY="votre_clé"

Vous pouvez conserver la liste des profils dans un fichier de configuration ou une variable de projet. Pour le premier lancement, un seul nom d’utilisateur suffit pour vérifier la réponse, l’accès et l’enregistrement dans le stockage. Dans l’exemple, le champ username est défini comme paramètre de l’API et la clé est lue uniquement depuis l’environnement.

Requête et enregistrement d’un instantané en Python

Le script vérifie la réponse HTTP, le statut externe de l’API et la présence de l’objet ig. Il n’enregistre ensuite que les valeurs explicitement disponibles. Si un champ est absent, l’enregistrement conserve null : mettre zéro à la place reviendrait à confondre une valeur inconnue avec un véritable zéro.

import json
import os
from datetime import datetime, timezone
from pathlib import Path

import requests

API_URL = "https://ig.jsonscraper.com/v1/user/by/username"
LICENSE_KEY = os.environ["JSONSCRAPER_INSTAGRAM_LICENSE_KEY"]
USERNAME = "apple"  # remplacez par un profil de votre liste
OUTPUT = Path("instagram-profile-snapshots.jsonl")

response = requests.get(
    API_URL,
    params={"username": USERNAME, "license_key": LICENSE_KEY},
    timeout=30,
)
response.raise_for_status()
payload = response.json()

if payload.get("status") != "ok" or not isinstance(payload.get("ig"), dict):
    raise RuntimeError("L’API a renvoyé un statut ou une structure inattendus")

profile = payload["ig"]
record = {
    "observed_at": datetime.now(timezone.utc).isoformat(),
    "username": profile.get("username", USERNAME),
    "pk": profile.get("pk"),
    "follower_count": profile.get("follower_count"),
    "following_count": profile.get("following_count"),
    "media_count": profile.get("media_count"),
    "is_verified": profile.get("is_verified"),
    "is_private": profile.get("is_private"),
}

with OUTPUT.open("a", encoding="utf-8") as file:
    file.write(json.dumps(record, ensure_ascii=False) + "\n")

print("Instantané enregistré :", record["username"], record["observed_at"])

Les champs et la structure de l’exemple correspondent aux informations de profil décrites pour cette route. Une requête réussie renvoie une observation au moment de l’appel ; pour analyser l’évolution, le script doit être exécuté à nouveau et chaque instantané doit être conservé. La page de l’API IG Scraper présente une requête de base et une réponse de démonstration au format JSON.

Calculer la variation entre deux instantanés

JSONL stocke un enregistrement par ligne et peut donc être lu avec le module standard de Python. Le fragment suivant sélectionne les deux derniers enregistrements d’un profil et calcule la différence du nombre d’abonnés. Il n’affiche le résultat que si les deux enregistrements contiennent une valeur numérique.

import json
from pathlib import Path

rows = [
    json.loads(line)
    for line in Path("instagram-profile-snapshots.jsonl").read_text(encoding="utf-8").splitlines()
]

username = "apple"
profile_rows = [row for row in rows if row.get("username") == username]
profile_rows.sort(key=lambda row: row["observed_at"])

if len(profile_rows) >= 2:
    previous, current = profile_rows[-2:]
    old = previous.get("follower_count")
    new = current.get("follower_count")
    if isinstance(old, int) and isinstance(new, int):
        print({
            "username": username,
            "from": previous["observed_at"],
            "to": current["observed_at"],
            "follower_delta": new - old,
        })

La différence porte strictement sur les deux observations sélectionnées. Si des exécutions sont manquées, l’intervalle s’allonge ; le rapport doit donc afficher les deux dates au lieu de qualifier automatiquement la variation de « quotidienne ». Pour un fonctionnement régulier, planifiez l’exécution avec cron ou le planificateur d’une plateforme cloud. Dans n8n, vous pouvez assembler le même processus avec des nœuds de planification, de requête HTTP et d’enregistrement du résultat dans une base de données ou un tableau ; les noms des nœuds et la connexion au stockage dépendent de votre installation.

Étendre la collecte à plusieurs profils

Pour une liste de comptes, placez les noms dans un fichier distinct et parcourez-le avec une boucle. Enregistrez séparément le statut de chaque requête : ainsi, l’échec concernant un profil n’effacera pas les données obtenues avec succès pour les autres. Ajoutez un délai d’attente maximal, un journal des erreurs et une nouvelle tentative uniquement pour les comptes dont la requête a échoué.

Vous pouvez utiliser pk comme clé d’enregistrement si l’API l’a renvoyé, tout en conservant le nom d’utilisateur pour faciliter la lecture. L’identifiant aide à distinguer le profil d’une étiquette textuelle dans le rapport ; s’il est absent, il ne faut ni l’inventer ni le remplacer par un autre champ. Pour l’analyse, il est utile de conserver l’heure de collecte d’origine en UTC et de définir explicitement la période de comparaison.

Si votre tâche consiste à obtenir les informations à une fréquence donnée, le paramètre documenté cache_timeout permet de définir une durée de mise en cache en secondes ; pour IG, la mise en cache est désactivée par défaut. Choisissez cette durée en fonction de l’intervalle de surveillance et conservez-la avec les paramètres de collecte afin de tenir compte de la configuration des requêtes lors de l’interprétation des résultats.

Résultat obtenu

Après plusieurs exécutions, vous disposerez d’un fichier contenant des instantanés horodatés d’indicateurs publics et d’une différence simple à calculer entre les dates choisies. Vous pourrez le charger dans Google Sheets, PostgreSQL ou un système d’analyse ; une couche de traitement distincte pourra générer une notification lorsque la variation dépassera un seuil défini par l’équipe. Ce seuil relève de votre règle métier, et non d’une fonctionnalité intégrée à l’API.

La route de profil fournit des champs relatifs au compte. Pour auditer les nouvelles publications, il faut donc collecter les médias correspondants plutôt que tirer des conclusions à partir de media_count. La documentation de l’API IG répertorie une route distincte pour récupérer les publications, avec une pagination utilisant user_id et le paramètre end_cursor ; utilisez-la si votre tâche nécessite d’étudier les publications elles-mêmes. Pour le résultat décrit ici — un tableau historique des indicateurs de profil — une requête par utilisateur et l’enregistrement répété des instantanés suffisent.

Commencez par un profil et deux exécutions : vérifiez que le statut de la réponse est correct, que les dates sont enregistrées et que les données absentes restent explicitement inconnues. Ajoutez ensuite une liste de comptes et une planification. Vous obtiendrez ainsi des observations reproductibles, assorties d’un intervalle clair et de valeurs d’origine, que vous pourrez vérifier et transmettre à un processus d’analyse.