La programmation asynchrone fait partie du quotidien dans l’écosystème .NET.
Bien utilisée, elle rend ton application plus fluide, plus réactive et plus scalable.
Mal maîtrisée… elle peut générer des blocages, des deadlocks et des comportements impossibles à comprendre.

Dans cet article, je te propose une vision simple, concrète et réaliste de async/await :
👉 ce que ça fait réellement
👉 les erreurs que je vois souvent en mission
👉 les modèles à utiliser pour rester propre et efficace

---

🔥 1. Confondre asynchronisme et parallélisme

C’est l’une des confusions les plus fréquentes.

• Asynchronisme = éviter de bloquer un thread
• Parallélisme = exécuter plusieurs tâches en même temps

async/await ne crée pas du parallélisme.
Il permet simplement de ne pas bloquer le thread en attendant une opération I/O.

Mauvais réflexe :

await Task.Run(() => Service.LongProcess());

Si ton code est synchrone à la base, l’envelopper dans Task.Run ne le rend pas vraiment plus efficace.
Ça déplace juste le travail ailleurs.

---

🔥 2. Oublier un await (le “fire-and-forget” involontaire)

Exemple classique :

DoSomethingAsync(); // Oubli du await

Si tu fais ça :

• les exceptions peuvent disparaître dans la nature
• la tâche peut s’arrêter sans prévenir
• ton code devient imprévisible

Si tu veux faire du fire-and-forget, fais-le de manière explicite :

_ = Task.Run(async () => await LogAsync());

---

🔥 3. Bloquer l’asynchronisme avec .Result ou .Wait()

C’est, de loin, l’erreur la plus dangereuse.

var data = GetDataAsync().Result;

Tu risques :

• un deadlock en ASP.NET
• un thread bloqué inutilement
• des performances catastrophiques

Règle d’or :
👉 Si tu commences en async, finis en async.

---

🔥 4. Créer des tasks inutiles

L’asynchronisme n’est pas synonyme de “je crée des tasks partout”.

À éviter :

var t = Task.FromResult(_repository.Get());

Si une méthode est synchrone, laisse-la synchrone.
Forcer l’async partout complique ton code pour rien.

---

🔥 5. Ignorer le CancellationToken

.NET supporte nativement CancellationToken, mais il est souvent oublié.

Bon modèle :

public async Task ProcessAsync(CancellationToken token)
{
    token.ThrowIfCancellationRequested();
    await _service.CallAsync(token);
}

Pourquoi c’est important ?
👉 ça évite de faire tourner des opérations inutiles
👉 ça garantit un arrêt propre de tes workers / API / batchs

---

🧭 Les modèles que je recommande en production

✅ Utiliser l’asynchronisme de bout en bout

Dès qu’un service est async, toute la chaîne devrait l’être.
C’est comme une règle de cohérence.

---

✅ Utiliser les API async natives

.ReadAsync(), SaveChangesAsync(), SendAsync(), etc.

Elles existent pour éviter de bloquer les threads I/O.
Autant les utiliser.

---

✅ Protéger les zones sensibles avec SemaphoreSlim

private readonly SemaphoreSlim _lock = new(1, 1);

public async Task SafeUpdateAsync()
{
    await _lock.WaitAsync();
    try
    {
        await _repository.UpdateAsync();
    }
    finally
    {
        _lock.Release();
    }
}

Simple, efficace.

---

✅ Savoir où async/await est réellement utile

Pertinent pour :
✔ appels réseau
✔ DbContext
✔ fichiers / streams
✔ services externes

Pas pertinent pour :
✘ calcul CPU pur
✘ logique en mémoire
✘ boucles complexes

---

🎯 Conclusion

async/await est un outil incroyablement puissant.
Mais comme tout outil puissant, il demande un minimum de compréhension.

Si tu évites les pièges les plus courants :
✔ .Result / .Wait()
✔ tâches inutiles
✔ oubli du await
✔ absence de CancellationToken

… tu obtiens un code asynchrone plus propre, plus lisible et surtout plus fiable.

La clé, c’est de savoir où l’utiliser — et où ne pas l’utiliser.