Le tableau de bord charge rapidement le matin, puis affiche des erreurs quand plusieurs personnes l’ouvrent. Une intégration peut avoir atteint une limite d’API. Le fournisseur ne refuse pas forcément votre contrat ; il limite le rythme, le volume ou la concurrence des demandes.

Le quota ne se résume pas aux appels par minute

Un service peut définir une limite par seconde, par compte, par application, par ressource ou sur une période plus longue. Il peut aussi limiter les opérations simultanées. Deux intégrations utilisant le même compte peuvent donc partager une contrainte sans que leurs développeurs le sachent.

Demandez quelles limites s’appliquent au plan et aux opérations utilisés. Un chiffre relevé dans un exemple de documentation ne doit pas être transformé en garantie universelle. Les règles peuvent évoluer ; elles doivent faire partie du suivi de l’intégration.

Répéter immédiatement peut aggraver la situation

Une réponse HTTP 429 indique généralement trop de requêtes, selon l’usage du service. Le serveur peut donner une indication d’attente, par exemple dans un en-tête Retry-After. Le client doit suivre la documentation et éviter une boucle qui recommence aussitôt.

Un délai progressif entre les tentatives, éventuellement accompagné d’une variation aléatoire, peut réduire les reprises simultanées. Mais il faut aussi fixer une limite aux relances et garder une trace des demandes qui n’ont pas abouti. Recommencer indéfiniment transforme une interruption temporaire en charge durable.

Attendre est une stratégie seulement si l’on sait ce qui attend.

Les opérations qui modifient des données exigent une attention supplémentaire : une absence de réponse ne prouve pas que rien n’a été exécuté. Le traitement doit vérifier l’état ou utiliser les mécanismes d’idempotence disponibles avant de répéter une action à effet métier.

Réduire les appels qui n’apportent rien

Une page qui demande à nouveau la même liste à chaque clic consomme inutilement son quota. Une mise en cache adaptée peut aider, si l’équipe accepte un délai de fraîcheur défini. Toutes les données n’ont pas besoin d’être actualisées à la seconde.

Les requêtes groupées, la pagination bien utilisée et les notifications d’événements peuvent aussi réduire certains appels. Leur disponibilité dépend du service. Le prestataire doit expliquer le rythme de synchronisation et ce qui déclenche une actualisation, au lieu de promettre vaguement du « temps réel ».

Cette organisation rejoint la gestion des accès SaaS : inventorier les applications connectées aide à comprendre lesquelles utilisent les mêmes ressources et quels responsables contacter quand le quota est partagé.

Observer ce que l’utilisateur voit

Pendant une limitation, le tableau de bord peut afficher les dernières données disponibles avec leur date, plutôt qu’une valeur vide qui ressemble à zéro. Un outil de création de commandes doit, lui, éviter de laisser croire qu’une action a réussi si elle attend encore son traitement.

Un journal doit distinguer demande créée, en attente, exécutée et échouée. Le support pourra alors répondre sans relancer au hasard. Ajoutez une alerte quand la file vieillit ou quand les erreurs deviennent récurrentes.

Préparer le rattrapage après une interruption

Si l’intégration accumule des demandes pendant une panne, leur reprise peut atteindre le quota à son tour. Le traitement doit lisser le rattrapage et choisir un ordre pertinent. Les opérations urgentes et les actualisations de confort ne devraient pas forcément partager la même priorité.

Le responsable doit pouvoir voir combien de demandes restent en attente et quelle est la plus ancienne. Une file qui diminue n’est pas automatiquement saine si elle laisse certains objets bloqués. Les erreurs permanentes, comme un identifiant invalide, doivent être distinguées des erreurs qui peuvent disparaître après attente.

Pour un prestataire, la démonstration utile consiste à montrer une interruption contrôlée, puis la reprise sans doublon et sans afflux incontrôlé. Le compte rendu précise le délai observé pour le jeu d’essai et les limites du scénario. Une promesse de synchronisation n’est complète que si elle décrit aussi la façon de rejoindre à nouveau l’état attendu.

Un essai de charge proportionné

Dans un environnement de test autorisé, simulez plusieurs utilisateurs et observez les limites prévues. Le but n’est pas de saturer volontairement le fournisseur, mais de vérifier le comportement de votre application lorsqu’elle reçoit une réponse de limitation.

Une intégration SaaS robuste n’est pas celle qui fait le plus d’appels. C’est celle qui utilise le quota pour les besoins utiles, gère l’attente et conserve un état compréhensible lorsque le service impose une pause.