Depuis quelques semaines, Instagram a mis en place un grand nombre de changements techniques pour sa plateforme. Histoire de bien comprendre les implications que cela engendre, voici un petit résumé suivi d’une longue explication.

Voici un état des lieux de ces changements.
tl;dr (le résumé)
- Pourquoi l’article : de gros changements de la plateforme depuis le 17 novembre 2015 (cf. changelog)
- RealTime : plus vraiment de temps réel en direct (oui, du temps-réel différé au final)
- Accès à l’API : des Access Token plus difficile à générer (pour éviter de transmettre un mot de passe dans un mail, c’était bien et ça le sera encore, mais moins facilement)
- Application Review : « joue-la comme Facebook » mais en plus contraignant (on oublie le fait de lancer une application du jour au lendemain sans réelle avancée pour la plateforme)
- Permissions : un mode live et un mode sandbox en place (la réactivité est bien diminuée et les contraintes sont plus fortes)
Instagram en temps réel
AccessToken
Petit rappel, un AccessToken est une sorte de clé, privée et unique par utilisateur, permettant d’ouvrir l’accès aux fonctionnalités d’une API. Cela permet à Instagram par exemple de savoir quel utilisateur demande quelle information à quel moment, et d’appliquer des restrictions d’accès, tant en fonctionnalités qu’en nombre d’appels. Les appels aux APIs Instagram nécessitent maintenant un AccessToken. Cela implique donc de systématiquement :- se connecter sur une interface préalablement développée
- de générer son AccessToken
- de l’utiliser pour configurer l’application
Mode d’application et Review
Là où ça se complique, et c’est sûrement la plus importante modification de l’API, c’est que les applications nouvellement crées sont en mode « sandbox » (et les applications crées avant le 17/11/2015 basculeront automatiquement dans ce mode au 01/06/2016). Pour sortir du mode « sandbox » et être « live« , il faut obligatoirement faire une Review de l’application (un peu comme pour Facebook, mais systématiquement). Pour faire une review il faut :- rédiger une description de l’application qui explique ce qu’elle fait
- faire une vidéo de l’application en train d’être utilisée (exemple ici et ici)
-
satisfaire une des 3 conditions suivantes, et dire dans laquelle l’application entre :Utility: The requested permissions must provide a non-automated, authentic, high-quality experience to your user and the larger Instagram community.Visibility: Data gained from the permission needs to be tied to a direct use and visibly used within your app. We do not accept permission requests for data that you may decide to use later.Validity: The requested permission needs to be tied to a valid use case. To read more about the valid use cases for each permissions, please see below.
- to help individuals share their own content with 3rd party apps
- to help brands and advertisers understand and manage their audience and digital media rights
- to help broadcasters and publishers discover content, get digital rights to media, and share media with proper attribution
Invalid Use Case: The use case described in your submission notes, screencast and website is not a valid use case that we allow on our Platform. Please see our Permissions Review and valid use cases description for more information.
Permissions
Mais ça, c’est juste pour obtenir la permission « basic » (récupérer son propre flux Instagram), car il y a une notion de permissions maintenant. Celles qui nous intéressent sont la « basic« (récupérer son propre contenu, attribuée par défaut si l’application est acceptée), et la « public_content » qui permet de récupérer les informations d’autres utilisateurs. Pour résumer, il faut la « public_content » pour récupérer un flux basé sur un #hashtag, et justifier son utilisation en plus dans la Review. Refléter l’activité de sa communauté Instagram par l’affichage d’un #hashtag créé spécialement pour une opération semble donc soumis à des règles encore plus drastiques. Mais on peut se dire que rester en « sandbox » sera suffisant pour ce que l’on veut faire. Et là on se penche sur les différences entre les modes « sandbox » et « live« . La première est assez facilement compréhensible :- live : 5000 appels d’API par heure et par AccessToken (soit un peu plus d’une par seconde)
- sandbox : 500 appels d’API par heure et par AccessToken (soit un peu plus d’une toutes les 10 secondes)
- live : pas de restriction appliquée sur la récupération de contenu
- sandbox : seuls les 20 derniers contenus appartenant à l’utilisateur dont on a utilisé l’AccessToken pour faire l’appel à l’API sont récupérables
- live : n’importe quel utilisateur peut obtenir un AccessToken
- sandbox : seuls les administrateurs et les « sandbox users » d’une application peuvent en avoir un.
- une application ne peut avoir que 10 « sandbox users » (créateur + 9 marques)
- un utilisateur ne peut être « sandbox user » que de 5 applications maximum.

Pour résumer, le avant/après
Pour bien comprendre les changements, voici les différentes étapes à suivre pour développer une application qui récupère des médias Instagram sur un #hashtag, avant et après la mise à jour de l’API.Avant
-
créer une application Instagram
-
ne rien demander à qui que ce soit pour appeler l’API
-
les médias arrivent en temps réel sur l’application après un abonnement au RealTime
Après
-
créer une application Instagram
-
envoyer une invitation « sandbox user » au client final
-
demander au client de générer des AccessTokens dans une interface spécialement développée
-
rédiger une description de l’application et justifier 1 des 3 conditions des CGU Instagram
-
faire une vidéo d’utilisation de l’application
-
avoir la validation d’Instagram
-
appeler un script toutes les 5mn pour récupérer d’éventuels nouveaux médias
Les commentaires sont désactivés