Dépendre du service de quelqu’un d’autre

Brancher une API externe est en général le moyen le plus rapide d’obtenir une capacité, et cela déplace discrètement une part de votre fiabilité dans les mains d’autrui. Le travail consiste à décider ce qui se passe quand cette main glisse.

Décidez avant la panne ce qui arrive pendant la panne

Tout service tombe un jour, à un moment que vous n’avez pas choisi. La question à trancher pendant que tout va bien : votre fonctionnalité échoue-t-elle, se dégrade-t-elle, ou attend-elle ?

Échouer convient pour de l’optionnel : une carte qui ne s’affiche pas, un enrichissement qui reste vide. Cela ne convient pas dans un parcours de paiement ou de connexion, où il faut une solution de repli ou une erreur honnête indiquant quoi faire. Un indicateur qui tourne sans jamais aboutir est le pire résultat : il apprend aux gens que c’est votre produit qui est cassé, pas celui d’un autre.

Les clés sont des identifiants, pas de la configuration

Une clé d’API est un mot de passe qui se trouve écrit dans un fichier de configuration, et on la traite comme un réglage parce qu’elle y ressemble. Elle finit ensuite dans le dépôt, dans une capture d’écran, dans un fil de messages.

Gardez les clés hors du code, utilisez une clé distincte par environnement pour qu’un test ne touche jamais des données réelles, et renouvelez-les au départ de quelqu’un qui y avait accès. Donnez aussi à chaque clé la portée la plus étroite proposée : presque toutes les API le permettent, et presque personne ne s’en sert avant l’incident qui le fait regretter.

Les limites de débit et les relances qui les aggravent

La première chose que fait la plupart des intégrations après un échec, c’est réessayer immédiatement. Si l’échec était une limite de débit, vous venez de l’aggraver, et une matinée chargée devient une panne que vous vous êtes infligée.

Réessayez avec un délai croissant, plafonnez le nombre de tentatives, puis arrêtez au lieu de boucler. Et ne relancez jamais aveuglément une écriture non idempotente : la version classique de ce bug est un client débité deux fois, parce que le premier appel avait réussi et que seule la réponse s’est perdue.

Cela changera sous vous

Les services modifient des formats de réponse, retirent des points d’entrée et ajustent des limites, annoncés le plus souvent là où vous ne lisiez pas. L’intégration qui fonctionne depuis un an n’est pas stable : elle n’est pas testée depuis son dernier changement.

Épinglez une version si le service en propose, abonnez une personne réelle aux annonces du fournisseur plutôt qu’une boîte partagée que personne ne lit, et gardez un petit appel automatique quotidien qui signale quand la réponse cesse de ressembler à ce qu’elle était. Ce dernier coûte une heure et trouve la casse avant un client.