Le service IFTTT (If This, Then That), largement utilisé pour automatiser des actions au sein d’applications, traverse une mauvaise passe. Avec IFTTT, on crée des « recettes » qui permettent à des services web et des apps d’interagir entre eux, par exemple : « si le soleil se lève, alors baisse les lumières Hue » (cette recette est disponible ici). IFTTT a décidé récemment de basculer sur une nouvelle plateforme afin d’améliorer la gestion des flux entre les services.

Plusieurs grands noms ont décidé purement et simplement d’abandonner le support d’IFTTT suite au changement de la "plateforme" du service : Readability, Last.FM, Pinboard sont de ceux là, et d’autres pourraient bien suivre. Maciej Cegłowski, créateur de Pinboard — un site de gestion de signets — explique en détails les raisons pour lesquelles il lâche IFTTT.

Il reproche principalement deux choses à IFTTT. La première, c’est de lui demander de « travailler gratuitement ». Jusqu’à présent, c’était le rôle d’IFTTT d’écrire le code qui, tel des briques de Lego, imbrique les services les uns dans les autres et apporte la compatibilité nécessaire afin que tout l’écosystème puisse se parler. « Au lieu de ça, les sites qui veulent travailler avec IFTTT vont devoir implémenter une API privée qui peut changer sans prévenir », s’alarme Cegłowski, qui ajoute : « C’est une décision parfaitement raisonnable d’un point de vue business. C’est toujours malin de laisser les autres faire tout le travail ».

Il estime qu’il vaut mieux, « pour le web », connecter des services avec des API publiques, stables et documentées, plutôt que des API personnalisées et privées. La seconde raison tient dans les termes et conditions d’utilisation d’IFTTT, qui dépouille les services partenaires d’à peu près toutes leurs prérogatives. IFTTT ne veut pas, par exemple, qu’un site qui tire parti de ses fonctions devienne un concurrent en utilisant ses outils (ce qui est un peu le cas de Pinboard).

Un autre article explique qu’IFTTT a un droit sur les contenus qui transitent par ses tuyaux ; un autre encore que le développeur doit assurer une compatibilité à 100% de ses services avec IFTTT (même si les changements proviennent d’IFTTT, du « travail gratuit », là encore) ; IFTTT se réserve aussi le droit de breveter à son propre compte les idées et améliorations que peuvent apporter les développeurs ; le service peut également transférer l’accord avec un développeur à un tiers, sans que le développeur ait son mot à dire.

Tout cela est effectivement un peu pesant et explique pourquoi Pinboard — mais aussi d’autres services — veut se séparer d’IFTTT. Pour Pinboard, la fin de service est prévue pour le 4 avril. Maciej Cegłowski propose à ceux qui le veulent de tester des services équivalents comme Zapier ou Botize. Le clash est donc sérieux et potentiellement, ces premiers départs pourraient en appeler d’autres, c’est pourquoi Linden Tibbets, le CEO d’IFTTT, a répondu sur Twitter.

Tibbets s’excuse tout d’abord pour l’« incompréhension » provoquée par la communication de l’entreprise, et il explique que c’est lui qui a construit et maintenu le canal IFTTT pour Pinboard (dont il est aussi un client). Il admet que les changements demandés demandent plus de travail, « mais nous savons que cela va apporter un meilleur IFTTT sur le long terme ». Tibbets est « heureux » de donner plus de temps à Pinboard si le service souhaite reconsidérer son départ, il est même prêt à donner un coup de main au besoin.

Pour le reste, « nous voulons faire mieux », écrit-il, c’est pourquoi IFTTT a mis en place cette nouvelle plateforme qui n’oblige plus à faire des pieds et des mains à chaque modification dans un service. Il conçoit aussi que les termes et conditions méritent des éclaircissements. « Nous le ferons avant d’ouvrir notre plateforme », promet-il.