Des interfaces ouvertes. Des limites claires.

De la fonction métier à un contrat d'API stable

Une API devrait offrir une fonction métier compréhensible plutôt que d'exposer sans filtre les tables d'un système interne. Nous définissons les ressources, les actions, les champs obligatoires et les réponses d'erreur avec les équipes consommatrices. Des données d'exemple et une description lisible par machine facilitent l'intégration ; les règles métier restent explicitement documentées.

Les changements sont évalués selon leur impact. Un champ optionnel supplémentaire doit être traité différemment d'une nouvelle valeur obligatoire ou d'une signification modifiée. Nous planifions le versionnement, les délais de transition et la communication aux utilisateurs connus. Ainsi, une mise à jour interne de la base de données ne casse pas forcément toutes les applications connectées en même temps.

Sécuriser ensemble la passerelle, les identités et le back-end

Au niveau de la passerelle, des règles centrales d'authentification, de limitation de débit et de routage peuvent être mises en œuvre. L'autorisation métier doit néanmoins être vérifiée par le service compétent : un client valablement authentifié ne doit pas pour autant pouvoir lire les données d'un autre client. Nous examinons donc l'ensemble de la chaîne de la requête.

Pour l'exploitation, nous convenons de budgets de temps de réponse, de délais d'expiration et de la gestion des nouvelles tentatives. Des identifiants de corrélation relient les journaux entre plusieurs systèmes, sans enregistrer systématiquement le contenu sensible des requêtes. Un accès développeur avec des exemples et un environnement de test adapté aide les partenaires à détecter les erreurs avant la connexion en production.