Dans les architectures modernes, on ne gère pas le retry dans le contrôleur HTTP. On pousse le message dans un Message Broker (comme Redis) et on laisse un Worker s'en occuper.
En PHP (Laravel Queues)
Laravel gère l'exponential backoff de manière élégante directement dans les propriétés de vos "Jobs".
namespace App\Jobs;
use Illuminate\Bus\Queueable;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Foundation\Bus\Dispatchable;
use Illuminate\Queue\InteractsWithQueue;
use Illuminate\Queue\SerializesModels;
class SendSmsNotification implements ShouldQueue
{
use Dispatchable, InteractsWithQueue, Queueable, SerializesModels;
public $phoneNumber;
public $message;
// Nombre maximal de tentatives (ex: abandonner après 5 essais)
public $tries = 5;
// Algorithme de recul : réessayer après 2s, 10s, 30s, 60s
public function backoff()
{
return [2, 10, 30, 60];
}
public function handle()
{
$response = EnvoiSmsApi::send($this->phoneNumber, $this->message);
// Si l'API renvoie un 400 (erreur permanente), on abandonne tout de suite
if ($response->status === 400) {
$this->fail(new \Exception('Numéro invalide, abandon.'));
return;
}
// Si c'est une erreur 503, la fonction va naturellement throw une exception
// et Laravel replacera le Job dans la file d'attente avec le backoff prévu.
if (!$response->successful()) {
throw new \Exception('Erreur temporaire API.');
}
}
}
La règle de péremption de l'OTP
Si vous gérez l'envoi de codes OTP pour l'authentification 2FA, un retry peut être dangereux. Si le SMS finit par arriver 15 minutes plus tard après 4 retries réseau, le code généré dans votre base de données aura déjà expiré, générant de la frustration chez le client.
Pour les OTP critiques, limitez les tries à 2 maximum, et si cela échoue, implémentez plutôt un Fallback métier (proposer un appel vocal ou un envoi WhatsApp) directement sur l'interface de l'utilisateur, plutôt que de retenter l'envoi SMS en silence.
