En Français de la Tech, l'expression API as a Product est appelée un worst of : elle représente tout ce que l'on souhaite éviter en termes de communication technique.

Pour API c'est assez simple, le terme est apparu à la fin des années 60 pour désigner un contrat d'interface stable et documenté afin de pouvoir utiliser des routines communes. L'acronyme se décompose en Application Program Interface puis a dérivé en Application Programming Interface, soulignant l'importance de la documentation dans l'API. Les deux destinataires d'une API étant le programmeur, pour qu'il puisse écrire du code utilisant les routines communes, et le compilateur qui va vérifier le respect du contrat et écrire le code machine permettant l'appel aux routines. D'autres interfaces existent évidemment, les ABI, SPI, etc… la spécificité des API étant dans le AP, le programmeur d'applications, l'humain qui va être le premier consommateur de cette nourriture.

Pour Product c'est assez simple aussi : en informatique, produit s'oppose directement à service distribué. Le produit c'est ce que l'on installe sur ses propres ressources de calcul, et qu'on utilise sans avoir besoin de la présence d'un tiers (avec le bémol des contrôles de licence à distance).

API as a Product devrait donc être en toute logique… un contrat d'interface permettant de construire un produit ? Un produit permettant de construire et documenter des contrats d'interface ? Que nenni. API as a Product est en fait un raccourci de treating API as a Product c'est-à-dire, pour les fournisseurs de services distribués, de ne pas considérer l'API comme l'interface exposée une fois qu'on a mis en place le service, mais de traiter l'API comme si c'était un produit, en y apportant la même démarche d'analyse, de conception et de commercialisation. Est-ce que cela signifie que l'API devient de ce fait un produit ? Absolument pas, on se situe dans une reformulation de l'approche top-down, selon laquelle on commence par regarder ce que l'on souhaite exposer, pour finir par regarder comment on va le mettre en œuvre, et qui s'oppose à la démarche bottom-up qui est, elle, purement technique.

Jusqu'ici, à part pour l'omission en apparence dérisoire de treating, nous ne sommes pas en présence d'une affordance trompeuse. Pourtant, entre l'apparition du terme fin 2015 et son utilisation aujourd'hui, cette omission s'est avérée fatale : on parle aujourd'hui de boutiques d'API (vu que ce sont des produits), de places de marché d'API (vu que ce sont des produits), de documentation d'API (et plus de la partie documentation de l'API), de rentabilité d'API (vu que ce sont des produits), des données de l'API (vu que l'API n'est plus une interface). Le raccourci de treating API as a Product en API as a Product a fait que le message qui est diffusé est qu'on ne vend plus l'accès à un service distribué, mais à un contrat d'interface, contrat qui par définition n'a qu'une valeur secondaire, celle de faciliter le travail du programmeur pour accéder à ce qui apporte la valeur primaire : la routine mise en commun. C'est dans la perte de ce petit mot treating que l'on est entré dans la tromperie.

Vous pouvez trouver le reste de la série sous l'article d'introduction.