Une intégration qui attend indéfiniment peut bloquer un achat, une réservation ou une tâche interne. Mais un délai trop court risque aussi d’interrompre des opérations valides. C’est pourquoi définir les délais d’attente des intégrations ne relève pas seulement d’un réglage technique : il faut déterminer ce que l’activité peut attendre, quelle expérience sera proposée à la personne concernée et comment traiter les résultats incertains.
Un délai d’attente limite la durée pendant laquelle un composant attend une réponse. Il ne prouve pas que le système externe a interrompu son traitement ni que l’opération a échoué. Bien concevoir ces limites consiste à décider ce qui doit être attendu, quand cesser d’attendre et quoi faire ensuite.
Le délai doit répondre à un besoin métier
Commencez par repérer le processus qui dépend de la réponse externe et les conséquences d’un retard. Une autorisation nécessaire avant de confirmer un achat ne dispose pas de la même marge qu’une mise à jour de catalogue pouvant être effectuée en arrière-plan. Le critère ne devrait pas être « quelle valeur utilise-t-on habituellement ? », mais combien de temps le processus peut attendre sans nuire à l’utilisateur, à l’activité ou à la cohérence des données.
Pour chaque dépendance, précisez :
- Quelle décision est bloquée : confirmer une réservation ou afficher un résultat, par exemple.
- Qui attend : une personne devant un écran, une API cliente, un traitement nocturne ou une équipe opérationnelle.
- Ce qui se passe si aucune réponse n’arrive à temps : le processus peut être reporté, se poursuivre avec des informations partielles ou être interrompu.
- Ce que signifie « terminé » : une réponse a été reçue, le fournisseur a accepté la demande ou l’effet final a été confirmé.
Cette dernière distinction évite de confondre une réponse technique et le résultat fonctionnel. Un service peut accepter une demande sans avoir terminé l’opération. Si l’activité a besoin de connaître le résultat final, il peut être préférable de consulter l’état de l’opération ou de recevoir une notification ultérieure, plutôt que d’allonger indéfiniment le délai d’attente.
Distinguez les délais de connexion, de réponse et d’opération
Un seul délai d’attente peut masquer l’étape où le retard s’accumule. Il est utile de distinguer les limites selon le type d’attente et de définir une durée totale maximale pour l’opération. Par exemple, la tentative d’établissement d’une connexion peut avoir sa propre limite, tout comme l’attente de données après la connexion. Enfin, toute la séquence — y compris les appels dépendants — doit respecter un budget global.
Lorsque plusieurs services sont enchaînés, le temps disponible doit être réparti entre eux. Il n’est pas raisonnable que chaque dépendance utilise séparément toute la durée maximale accordée à l’utilisateur : leur cumul peut dépasser le délai du processus. Propagez une échéance commune et veillez à ce que chaque composant n’utilise que le temps restant. Ainsi, un appel tardif ne continue pas à travailler alors que l’opération à l’origine de cet appel n’est plus utile.
Les noms et le comportement des limites varient selon les bibliothèques et les plateformes. Vérifiez si la valeur configurée s’applique uniquement à la connexion, à la lecture d’une réponse, à chaque tentative ou à l’opération complète. Examinez aussi les limites définies par les mandataires, les répartiteurs de charge ou les clients intermédiaires : sur un même parcours, le délai effectif est souvent celui de la limite la plus restrictive.
Le contexte compte. Une interaction avec un utilisateur exige généralement une réponse rapide ou une transition claire vers un état en attente. Un traitement par lots peut accepter une fenêtre plus longue, à condition d’être supervisé et encadré. Dans les deux cas, établissez le délai à partir des objectifs du processus et des mesures de latence observées, plutôt que d’une valeur arbitraire.
À l’expiration du délai, choisissez entre annuler, attendre ou fonctionner en mode dégradé
L’expiration du délai doit déclencher une décision prévue, et non une exception laissée sans traitement. Trois approches sont courantes et peuvent être combinées selon l’opération :
- Annuler et cesser d’attendre : utile lorsque la réponse n’apporte plus de valeur. Propagez l’annulation aux tâches en cours si le client et le service le permettent, puis libérez les ressources locales.
- Laisser l’opération en attente : adapté si le fournisseur peut traiter le travail de manière asynchrone. Renvoyez ou enregistrez une référence de suivi et permettez de consulter l’état ultérieurement.
- Poursuivre en mode dégradé : valable lorsqu’une solution de repli sûre existe, par exemple afficher des données récentes ou reporter une mise à jour. Indiquez quelle partie n’a pas pu être achevée et ne présentez pas une information provisoire comme confirmée.
Annuler l’attente ne revient pas à annuler l’opération à distance. La demande peut être parvenue au fournisseur juste avant l’expiration du délai côté client. Le serveur peut continuer à la traiter même si la connexion est fermée. Ne marquez donc pas automatiquement l’action comme échouée et ne confirmez pas à l’utilisateur qu’aucune opération n’a eu lieu sans éléments suffisants.
Si un résultat incertain est inacceptable, prévoyez un moyen de consulter, de rapprocher ou de compenser l’opération. La possibilité d’une véritable annulation dépend des capacités du système distant et du type de travail : elle doit être vérifiée, et non présumée.
Traitez le résultat inconnu comme un état à part entière
Lorsqu’un délai expire sans réponse, le résultat peut être « inconnu » : vous ne savez pas si le fournisseur a reçu la demande, s’il l’a exécutée ou si une erreur est survenue auparavant. Distinguer cet état des états « échoué » et « terminé » aide à éviter des décisions risquées, notamment pour les paiements, les réservations, les expéditions ou les modifications de compte.
Avant de réessayer une action ayant des effets, vérifiez si le contrat d’intégration prévoit une clé d’idempotence ou un moyen de consulter l’opération à partir d’un identifiant. L’idempotence peut empêcher qu’une répétition produise deux effets, mais seulement si elle est mise en œuvre et garantie pour l’opération concernée. En l’absence de cette protection, consultez l’état ou soumettez le cas à un examen contrôlé avant de réessayer.
Les tentatives répétées consomment elles aussi du temps. Intégrez-les à la limite totale et évitez que chaque tentative bénéficie d’un délai complet et indépendant. Une nouvelle tentative sans budget défini, avec des pauses mal ajustées ou multipliée par plusieurs composants peut accroître la charge au moment même où le service est dégradé. Pour les tâches qui ne nécessitent pas de réponse immédiate, une file d’attente et un mécanisme de suivi peuvent être plus adaptés que le maintien d’une connexion ouverte.
Communiquez l’état et proposez une voie de reprise claire
Le message doit refléter le degré de certitude disponible. Si l’opération est toujours en cours, indiquez qu’elle est en attente ; si son résultat est inconnu, ne la présentez ni comme un échec ni comme une réussite. Précisez les options de la personne : patienter, consulter à nouveau l’état ou contacter l’assistance. Évitez de lui demander de répéter une action importante sans signaler le risque de doublon.
Les équipes internes ont besoin du même contexte. Enregistrez les identifiants de corrélation, la dépendance concernée, la durée, l’étape où le délai a expiré et le résultat observé. Distinguez les expirations liées à la connexion, à la réponse et à l’échéance globale. N’incluez pas de données sensibles dans des journaux lorsque ce n’est pas nécessaire. Ces informations permettent à l’assistance d’examiner un cas et aux équipes techniques de repérer l’étape qui consomme le budget.
Testez et révisez les limites à partir des signaux opérationnels
Une limite n’est pas validée simplement parce que l’intégration fonctionne dans des conditions normales. Testez les réponses lentes, les connexions interrompues, les annulations, les erreurs intermittentes ainsi que les réponses reçues après l’expiration du délai. Vérifiez l’expérience utilisateur, les effets chez le fournisseur et l’état final enregistré par votre système.
Suivez la distribution des latences, la fréquence des expirations, les opérations en attente ou de résultat inconnu, les tentatives répétées et les incidents par dépendance. Une hausse des expirations peut indiquer une limite trop stricte, mais aussi une dégradation réelle du fournisseur, une saturation locale ou un problème de réseau. N’augmentez pas automatiquement le délai : identifiez d’abord l’origine du retard et les processus exposés.
Pour chaque intégration, documentez le délai par étape, le budget total, l’action à l’expiration, la politique de nouvelles tentatives et le mécanisme de reprise. Révisez ces règles lorsque le processus métier ou la latence observée évolue. Le bon délai d’attente n’est ni le plus long ni le plus court : il protège le processus, clarifie son état et permet de reprendre sans produire d’effets en double.