Instagram met à jour son API (et il y a du changement !)

Consultez des articles plus récents sur Instagram ici et ici

UPDATE : Après avoir suivi à la lettre les recommandations Instagram (dont le résumé est présent dans cet article), nous avons obtenu les permissions « basic » et « public_content » du premier coup ! Si vous faites partie des heureux élus, vous verrez ces permissions dans le menu « Permissions » de votre application :

Depuis le 17 novembre 2015, Instagram a mis à jour son API. Globalement, toutes les applications crées après le 17/11/2015 sont soumises aux nouvelles règles, et celles crées avant le seront au 01/06/2016.

L’idée derrière ce changement pour Instagram est de donner plus de contrôle aux utilisateurs sur l’affichage de leur contenu. La démarche a été initiée par Facebook, propriétaire d’Instagram, il y a quelque temps déjà. Elle souhaite également limiter les applications tierces de faire « n’importe quoi » avec leurs photos. C’est aussi un moyen pour eux de reprendre la main sur le traffic web vers leurs propres plateformes et outils, que ce soit directement sur le site ou via des média intégrés (embed).

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)

Pour plus de précisions pratiques, efficaces et démystifiées, découvrons chacun des points ci-dessous !

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 :

1. se connecter sur une interface préalablement développée
2. de générer son AccessToken
3. de l’utiliser pour configurer l’application

Instagram ne spécifie pas spécialement de durée de validité pour ces AccessTokens (il n’expirent à priori pas).  Cependant, il prévient tout de même qu’ils peuvent expirer à tout moment (sic), et donc de toujours prévoir une solution de rafraîchissement d’AccessToken au cas où, ce qui pose problème dans le cadre d’applications « Event » par exemple, où il n’y a pas d’action utilisateur à proprement parler, et donc pas de possibilité de re-génération immédiate.

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.

  1. to help individuals share their own content with 3rd party apps
  2. to help brands and advertisers understand and manage their audience and digital media rights
  3. to help broadcasters and publishers discover content, get digital rights to media, and share media with proper attribution

La validation d’une application en mode « live » semble être assez drastique, selon les premiers retours de développeurs. Par exemple, faire un InstagramConnect pour récupérer des photos de son album pour un concours photo, ne satisfait pas les conditions (à priori, c’est tout de même accepté si on les affiche avec leur module « embed » Instagram dans la galerie), et juste afficher son propre flux Instagram dans une page n’est manifestement pas autorisé. Malheureusement, au dires de certains développeurs, la réponse d’Instagram suite à un rejet de review n’est pas très explicite :

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)

En termes de réactivité, pour un AccessToken dédié à une opération, on peut donc arriver à un affichage 10 secondes après le post d’un média. Ce qui est très raisonnable.

Mais la deuxième différence est un peu plus subtile :

• 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

Pour résumer, si on veut récupérer les médias sur #poivron par exemple, seuls les médias postés par l’utilisateur de l’AccessToken et qui comportent le #poivron ressortiront. Alors ça ne pose pas de problème si on veut récupérer le flux d’un utilisateur, on utilise un AccessToken généré par l’utilisateur en question (une marque par exemple), et on pourra afficher ses 20 derniers posts, ce qui est suffisant pour l’objectif. Mais si on veut afficher l’activité de la communauté de la marque, sur le #poivron, c’est impossible car ne seront affichés que les contenus postés par le compte de la marque contenant #poivron. On ne peut donc pas refléter l’activité d’une communauté en mode « sandbox« .

Et pour finir la troisième différence :

• live : n’importe quel utilisateur peut obtenir un AccessToken
• sandbox : seuls les administrateurs et les « sandbox users » d’une application peuvent en avoir un.

En conséquence, en dehors du créateur de l’application, seuls les « sandbox users » sont autorisés à faire des appels à l’API. Donc pour qu’une marque puisse générer un AccessToken, il faut d’abord lui envoyer une invitation pour être « sandbox user« , et qu’elle se rendre dans la console « developer » d’Instagram (aucun mail ni notification ne sont envoyés) pour l’accepter. C’est seulement une fois qu’il a accepté l’invitation qu’il peut se rendre sur une interface développée par le créateur de l’application pour générer son AccessToken. Et là, deux restrictions s’appliquent :

1. une application ne peut avoir que 10 « sandbox users » (créateur + 9 marques)
2. un utilisateur ne peut être « sandbox user » que de 5 applications maximum.

Si un développeur reste toujours en mode « sandbox« , il ne pourra donc pas avoir plus de 9 clients pour le produit qu’il aura développé. A moins bien sûr de multiplier les applications Instagram, ce qui n’est pas idéal.

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

1. créer une application Instagram
2. ne rien demander à qui que ce soit pour appeler l’API
3. les médias arrivent en temps réel sur l’application après un abonnement au RealTime

tl;dr (le mot de la fin)

Pour continuer à innover sur la plateforme, il faudra prendre le temps d’avoir le temps de mettre en place chaque impératif d’Instagram. Nous avons toujours autant d’idées d’opérations innovantes, simples et efficaces pour vos projets. Ces changements n’influencent pas la faisabilité technique, simplement le temps nécessaire au lancement de celles-ci.

Et si on se lançait sur un nouveau projet ensemble ?

D