L’appel technique est la partie facile
Consommer une API REST demande quelques lignes de code. Ce qui prend du temps, et ce qui casse en production, ce sont les cas dégradés : le service distant qui répond en 30 secondes, le jeton expiré au milieu d’un lot, la limite de débit atteinte, le format qui change sans préavis, la synchronisation lancée deux fois.
Nous traitons ces cas dès la conception, parce qu’ils représentent la quasi-totalité des incidents d’intégration.
Trois règles appliquées systématiquement
Aucun appel externe dans une requête HTTP. Tout échange avec un tiers passe par une file d’attente. L’utilisateur reçoit sa réponse immédiatement ; l’échange se fait derrière, avec reprises.
Chaque message est idempotent. Un identifiant unique par échange, vérifié par le récepteur. Rejouer un lot après incident ne doit jamais dupliquer les données.
Chaque échec est visible. Une alerte, un tableau de bord et une file de messages morts consultable. Une intégration qui échoue en silence est pire que pas d’intégration : elle crée une confiance injustifiée dans les données.
Exposer sa propre API
Quand vous exposez une API, la documentation et le versionnage ne sont pas optionnels. Nous livrons une spécification OpenAPI générée depuis le code — donc toujours à jour —, une authentification par jeton avec quotas, et une politique de version explicite qui garantit à vos intégrateurs qu’une évolution ne cassera pas leur travail du jour au lendemain.
