Tutoriel Go

Semaphore buffered channel Go : Maîtriser la concurrence avancée

L’utilisation d’un semaphore buffered channel Go est une technique fondamentale et puissante en programmation concurrente Go. Ce concept permet de réguler strictement le nombre de tâches qui peuvent s’exécuter simultanément au sein d’une application. Plutôt que de laisser un nombre illimité de goroutines potentiellement saturer les ressources système, le semaphore garantit une gestion contrôlée et mesurée de votre charge de travail. Cet article s’adresse aux développeurs Go intermédiaires à avancés qui cherchent à optimiser la performance et la robustesse de leurs systèmes distribués et API haut débit.

Dans le contexte des microservices ou des traitements par lots (batch processing), le contrôle de la concurrence est crucial. Si une fonction doit interagir avec une API externe limitée par des quotas, ou si elle doit traiter des fichiers sur un cluster avec des contraintes de ressources, la gestion manuelle des accès est nécessaire. Le semaphore buffered channel Go offre une solution élégante et idiomatique en Go pour implémenter ce pattern de limitation, bien mieux que de simples mécanismes de mutex ou de simple canal non tamponné.

Nous allons décortiquer ensemble ce mécanisme de manière exhaustive. Après cette introduction, nous aborderons les prérequis techniques indispensables pour maîtriser ce sujet. Ensuite, nous explorerons les fondations théoriques du semaphore en Go, avant de plonger dans un exemple de code source commenté étape par étape. Enfin, nous couvrirons des cas d’usage avancés, les erreurs courantes à éviter, les bonnes pratiques de l’industrie, et des scénarios réels pour que vous soyez totalement opérationnel sur ce sujet pointu. Préparez-vous à transformer la manière dont vous gérez la concurrence en Go !

🛠️ Prérequis

Pour suivre ce guide expert sur le semaphore buffered channel Go, quelques bases solides sont exigées. Ne vous inquiétez pas, nous détaillerons tout, mais voici ce que vous devez maîtriser déjà pour une assimilation rapide et efficace.

Prérequis de Langage et Outils

Il est indispensable d’avoir une bonne compréhension des concepts fondamentaux de Go, notamment le système des goroutines et le fonctionnement des canaux (channels). Ces bases sont essentielles pour comprendre comment le semaphore intervient comme un régulateur de débit basé sur les canaux.

Version de Go recommandée : 1.18 ou ultérieure. Les améliorations en matière de gestion de la concurrence sont constantes, et les versions récentes offrent le meilleur support pour les patterns complexes comme celui-ci.
Outils : Un éditeur de code moderne (VS Code recommandé) et Go instalado correctement.
Installation : Assurez-vous que votre environnement est configuré en exécutant : go version et que le résultat indique au minimum Go 1.18. Si ce n’est pas le cas, téléchargez le SDK officiel depuis le site de Go.

Il est également utile de se familiariser avec le package sync de Go, car les concepts de mutex et de wait groups sont souvent utilisés en complément pour gérer le flux d’exécution global et assurer la synchronisation des résultats.

📚 Comprendre semaphore buffered channel Go

Pour comprendre le semaphore buffered channel Go, il faut d’abord visualiser le problème qu’il résout : la gestion des ressources limitées. Imaginez que vous devez faire appel à cinq imprimantes dans une usine (vos ressources limitées). Si vous demandez à 100 employés (vos goroutines) d’imprimer en même temps, le système va s’effondrer. Le semaphore agit comme un chef de chantier qui ne laisse entrer que le nombre maximum d’employés autorisés (la capacité tampon du canal) à la fois.

Techniquement, en Go, un canal est un conduit de communication sécurisé entre goroutines. Lorsqu’on utilise un canal tamponné (buffered channel) d’une capacité $N$, on crée un buffer de taille $N$. Lorsque nous utilisons ce canal comme semaphore, nous ne nous soucions pas des données qu’il transporte ; nous nous soucions uniquement de sa capacité. Chaque fois qu’une goroutine veut accéder à la ressource (l’imprimante), elle doit prendre une « place » dans le canal. C’est cette action qui bloque la goroutine si le canal est plein, simulant ainsi l’attente jusqu’à ce qu’une place se libère.

Comment fonctionne le semaphore buffered channel Go ?

Le mécanisme repose sur deux opérations clés :

L’Acquisition (Acquire) : Une goroutine envoie un signal (le fait d’effectuer un <-semaphore) dans le canal. Si la capacité tampon est pleine, cette opération bloque la goroutine. C'est l'effet de limitation.
La Libération (Release) : Une goroutine termine son travail et rend sa place (le fait d'effectuer un semaphore <- struct{}{}). Cette opération débloque potentiellement une autre goroutine en attente.

Le type struct{} est utilisé car il occupe zéro octet de mémoire, ce qui est idéal pour un compteur logique, car nous ne transportons aucune valeur utile. Un exemple ASCII :

[G1] -> Acquérir (Place disponible? OUI) -> [C=N-1]
[G2] -> Acquérir (Place disponible? OUI) -> [C=N-2]
...
[GN] -> Acquérir (Place disponible? NON) -> BLOQUE
[G1] -> Libérer (Place disponible? OUI) -> [C=N-1]
[GN] -> Réveillé -> Acquérir (Place disponible? OUI) -> [C=N-2]

En comparant cela à d'autres langages, dans Python, on utiliserait généralement un threading.Semaphore. Le principe sous-jacent reste le même : un compteur atomique et des mécanismes d'attente/notification. En Go, le canal tamponné offre une encapsulation plus idiomatique et plus sûre, car l'accès aux ressources est géré par le mécanisme de blocage natif de Go, sans nécessiter de gestion manuelle explicite des verrous mutex, ce qui réduit drastiquement le risque de deadlock.

🐹 Le code — semaphore buffered channel Go

package main

import (
	"fmt"
	"sync"
	"time"
)

// worker est la fonction qui simule une tâche gourmande en ressources.
func worker(id int, semaphore chan struct{}, wg *sync.WaitGroup) {
	defer wg.Done()
	
	// 1. ACQUISITION : Tentative d'obtenir une place dans le semaphore.
	// Si le canal est plein, cette ligne bloque la goroutine.
	signal := struct{}{}
	semaphore <- signal
	
	fmt.Printf("Goroutine %d : Place acquise. Début du traitement...")

	// Simulation d'une tâche qui prend du temps
	time.Sleep(time.Millisecond * 500)
	
	fmt.Printf(" Traitement terminé.")
	
	// 2. LIBÉRATION : Rendre la place au semaphore pour que la prochaine tâche puisse démarrer.
	semaphore <- struct{}{}
	fmt.Println(" Place libérée.")
}

func main() {
	// Définition du limitateur de concurrence (Semaphore Capacity)
	const maxConcurrentTasks = 3 

	// Le canal est notre semaphore. Sa capacité tampon (3) est le nombre maximal de tâches.
	semaphore := make(chan struct{}, maxConcurrentTasks)

	var wg sync.WaitGroup
	numWorkers := 10 // Nous lançons 10 goroutines pour forcer le blocage

	fmt.Printf("--- Démarrage de %d tâches avec un limitateur de %d ---\n", numWorkers, maxConcurrentTasks)

	// Lancement des workers
	for i := 1; i <= numWorkers; i++ {
		wg.Add(1)
		go worker(i, semaphore, &wg)
	}

	// Attendre que toutes les goroutines aient fini leur travail
	wg.Wait()

	fmt.Println("\n--- Toutes les tâches ont été traitées. Système stable. ---")
}

📖 Explication détaillée

Ce premier snippet représente l'implémentation canonique du semaphore buffered channel Go. Il montre comment utiliser la capacité limitée du canal pour synchroniser et limiter les goroutines.

Analyse détaillée du code source

Le cœur de la solution réside dans la fonction worker. Nous allons décortiquer ce mécanisme étape par étape :

1. Initialisation (dans main()) :

semaphore := make(chan struct{}, maxConcurrentTasks)

Ceci est l'étape la plus cruciale. Nous créons un canal (le semaphore) avec une capacité tampon fixe (3). Ce canal ne contient aucune donnée de valeur utile, d'où l'utilisation de struct{}, qui garantit une empreinte mémoire nulle, optimisant l'utilisation de la mémoire pour ce simple compteur logique.

2. La fonction worker (Acquisition) :

semaphore <- signal

Lorsqu'une goroutine arrive dans worker, elle tente d'envoyer un signal dans le canal. Si le canal est plein (c'est-à-dire que $N$ goroutines ont déjà acquis leurs places), cette opération de send va bloquer immédiatement la goroutine. C'est ce blocage qui constitue la limitation de concurrence. La goroutine attend passivement, respectant ainsi le quota de ressources.

3. Le Temps de Traitement :

time.Sleep(time.Millisecond * 500)

Cette ligne simule le travail réel que la goroutine doit effectuer (par exemple, un appel réseau, un calcul lourd). C'est pendant cette période que la place est considérée comme occupée.

4. La fonction worker (Libération) :

semaphore <- struct{}{}

Une fois le travail terminé, la goroutine *doit* impérativement envoyer un signal de retour (un receive pour le canal). Cette opération de send libère la place. Elle est placée juste avant le defer wg.Done() pour garantir que même en cas d'erreur dans la logique métier, la place sera toujours rendue.

5. Maîtrise des ressources (trong main()) :

L'utilisation de sync.WaitGroup est essentielle pour le main pour attendre poliment que toutes les goroutines aient terminé leur cycle (acquisition, travail, libération). L'intégration parfaite entre le WaitGroup et le semaphore buffered channel Go assure que le programme ne se termine pas avant que la dernière tâche n'ait pu libérer sa place.

Piège potentiel : Oublier la libération. Si une goroutine panique ou qu'une exception se produit sans que la ligne de libération ne soit atteinte, le canal reste plein, et toutes les goroutines futures se bloqueront définitivement (Deadlock). C'est pourquoi l'utilisation de defer sur la libération est souvent recommandée dans les systèmes critiques pour garantir la rétention des ressources.

📖 Ressource officielle : Documentation Go — semaphore buffered channel Go

🔄 Second exemple — semaphore buffered channel Go

package main

import (
	"fmt"
	"sync"
)

// processor simule un traitement de données utilisateur.
func processor(user string, semaphore chan struct{}, wg *sync.WaitGroup) {
	defer wg.Done()

	// Acquis la place (bloque si trop de requêtes en cours)
	semaphore <- struct{}{}
	fmt.Printf("[%s] TRAITEMENT DÉMARRÉ. Place acquise.")
	
	// Simulation de la logique métier
	// ... appel à une API externe critique ...

	// Libération de la place (critique de la release)
	semaphore <- struct{}{}
	fmt.Printf(" [%s] TRAITEMENT TERMINÉ. Place libérée.")
}

func main() {
	const maxConnections = 5
	semaphore := make(chan struct{}, maxConnections)
	var wg sync.WaitGroup
	users := []string{"Alice", "Bob", "Charlie", "Diana", "Ethan", "Fiona", "Gary"}

	fmt.Printf("Gestion de %d connexions avec un limitateur de %d.\n", len(users), maxConnections)

	for _, user := range users {
		wg.Add(1)
		go processor(user, semaphore, &wg)
	}

	wg.Wait()
	fmt.Println("\n--- Toutes les utilisations de la ressource sont complétées. ---")
}

▶️ Exemple d'utilisation

Imaginons un scénario réel : vous êtes en train de traiter un lot de 20 images qui doivent être envoyées sur un service de minification d'images externe qui ne supporte que 5 requêtes simultanées. Utiliser un semaphore buffered channel Go est la solution idéale pour respecter le taux de débit et éviter les erreurs 429 (Too Many Requests).

Le code que nous allons exécuter (avec le canal de capacité 5) va lancer les 20 tâches en arrière-plan. Grâce au semaphore, seulement 5 tâches pourront réellement commencer. Les 15 autres attendront, bloquées, jusqu'à ce que l'une des 5 premières ait terminé et libéré sa place. Le résultat sera un traitement fluide et régulé.

Voici le contexte de notre test et la façon dont le code est appelé :

const maxConcurrent = 5 semaphore := make(chan struct{}, maxConcurrent) var wg sync.WaitGroup for i := 1; i <= 20; i++ { wg.Add(1) go func(id int) { // ... logique worker ... }(i) } wg.Wait()

La sortie console va clairement démontrer cette régulation. Au lieu de voir 20 traitements démarrent instantanément, vous verrez des groupes de 5 traitements se lancer, puis, dès qu'un groupe se termine, les 5 suivants prendront la relève immédiatement.

--- Démarrage de 20 tâches avec un limitateur de 5 ---
Goroutine 1 : Place acquise. Début du traitement...
Goroutine 2 : Place acquise. Début du traitement...
Goroutine 3 : Place acquise. Début du traitement...
Goroutine 4 : Place acquise. Début du traitement...
Goroutine 5 : Place acquise. Début du traitement...
Goroutine 1 : Traitement terminé. Place libérée.
Goroutine 6 : Place acquise. Début du traitement...
Goroutine 2 : Traitement terminé. Place libérée.
Goroutine 7 : Place acquise. Début du traitement...
Goroutine 3 : Traitement terminé. Place libérée.
Goroutine 8 : Place acquise. Début du traitement...
Goroutine 4 : Traitement terminé. Place libérée.
Goroutine 9 : Place acquise. Début du traitement...
Goroutine 5 : Traitement terminé. Place libérée.
Goroutine 10 : Place acquise. Début du traitement...
... (etc.) ...
--- Toutes les tâches ont été traitées. Système stable. ---

Chaque bloc de 5 exécutions montre le mécanisme de régulation. Une fois que la 5ème goroutine libère sa place, la 6ème est immédiatement capable de s'acquérir et de démarrer, démontrant le fonctionnement fluide et mesuré du semaphore buffered channel Go.

🚀 Cas d'usage avancés

Le semaphore buffered channel Go est un pattern extrêmement polyvalent. Voici quatre cas d'usage avancés qui vous montreront sa puissance dans un projet réel.

1. Limiter l'accès aux API Externes (Rate Limiting)

C'est l'usage le plus courant. Si vous appelez une API tierce qui impose un taux maximal de requêtes (ex: 5 requêtes par seconde), vous utilisez le semaphore pour ne jamais dépasser ce seuil.

Exemple :const rateLimit = 5 semaphore := make(chan struct{}, rateLimit) // Pour chaque requête : // <-semaphore (attente) // requeteAPI(user) // semaphore <- struct{}{} (libération après le délai API)

2. Traitement de Workers dans un Batch Job

Lorsqu'un système reçoit un flux de centaines de fichiers (ex: images à redimensionner ou documents à analyser), vous ne devez pas lancer un worker par fichier. Vous utilisez le semaphore pour gérer la file d'attente et limiter l'utilisation du CPU/IO disque.

Exemple :const maxProcessors = 8 semaphore := make(chan struct{}, maxProcessors) // Utilisation avec un channel de tâches : tasks := make(chan string) go func() { for filename := range tasks { <-semaphore processFile(filename) semaphore <- struct{}{} } }()

3. Gestion de Connexions HTTP Pool

Lorsqu'une application doit se connecter à un pool de bases de données ou de services réseau limités, le semaphore garantit qu'un nombre maximal de connections simultanées est maintenu. Cela empêche de saturer le côté serveur distant.

Exemple :const maxDBConnections = 10 dbSemaphore := make(chan struct{}, maxDBConnections) func executeDBQuery(query string) { <-dbSemaphore // Acquisition // Exécution de la requête time.Sleep(time.Millisecond * 100) dbSemaphore <- struct{}{} // Libération } // Lancement de multiples appels de executeDBQuery

4. Modélisation de Ressources Physiques Partagées

Si vous simulez un système réel (ex: un parking, des salles de réunion, des machines industrielles), le semaphore est le modèle parfait. Sa capacité représente le nombre maximal de ressources disponibles.

Exemple :const maxParkingSpots = 50 parkingSemaphore := make(chan struct{}, maxParkingSpots) // Entrer dans un spot : // <-parkingSemaphore // Sortir du spot : // parkingSemaphore <- struct{}{}

⚠️ Erreurs courantes à éviter

Maîtriser le semaphore buffered channel Go ne signifie pas éviter les pièges. Voici les erreurs les plus fréquentes commises, même par les développeurs expérimentés, et comment les contourner.

1. Oublier la libération de la place (Deadlock potentiel)

C'est l'erreur N°1. Si une goroutine s'acquiert une place et qu'une erreur survient avant qu'elle ne la libère, le canal reste plein. Toutes les autres goroutines se bloqueront pour l'éternité. Solution : Utilisez impérativement le mot-clé defer sur le processus de libération. Placez semaphore <- struct{}{} juste avant return ou après le bloc critique pour garantir l'exécution même en cas de panique.

2. Utiliser un canal non tamponné (Unbuffered Channel)

Si vous utilisez make(chan struct{}) sans capacité, le canal n'autorisera même pas le premier envoi avant que le récepteur ne soit prêt. Pour un semaphore, nous avons besoin d'une réserve de places disponibles avant même que le premier travail ne commence. Solution : Définissez toujours la capacité du canal sur le nombre maximal de ressources autorisé : make(chan struct{}, N).

3. Ne pas utiliser de `sync.WaitGroup`

Sans sync.WaitGroup, votre fonction main risque de se terminer avant que toutes les goroutines n'aient eu le temps de travailler, ce qui entraînera un comportement chaotique et des résultats incorrects. Solution : Incrémentez le compteur du WaitGroup au lancement des tâches et appelez wg.Wait() à la fin pour attendre l'achèvement de toutes les tâches.

4. Négliger le rôle de `struct{}`

Bien que fonctionnel, envoyer des valeurs types int ou string coûte inutilement de la mémoire et obscurcit l'intention. Solution : Toujours utiliser struct{}{}, qui est le type le plus léger et le plus approprié pour représenter un simple "signal" d'acquisition ou de libération.

✔️ Bonnes pratiques

Adopter le semaphore buffered channel Go ne suffit pas ; il faut le faire de manière professionnelle. Voici plusieurs conseils pour intégrer ce pattern dans des applications Go robustes et performantes.

1. Encapsuler le Semaphore dans une Structure

Ne laissez pas le canal et sa logique de gestion se propager partout. Créez une structure (ex: RateLimiter) qui encapsule le canal et propose des méthodes claires comme Acquire() et Release(). Cela rend votre code plus modulaire et testable.

2. Gérer le Nettoyage avec `defer`

Comme mentionné, le defer est vital. Il garantit la libération de la ressource, même si le code critique lance une panique. C'est une garantie contractuelle de votre code.

3. Tester les cas limites (Edge Cases)

Testez systématiquement : 1) Un flux de travail beaucoup plus grand que la capacité du canal. 2) Un seul worker. 3) Une panne simulée (panic()) pour vérifier que la libération est toujours appelée. L'intégration de tests de concurences est un must.

4. Choisir la capacité judicieusement

La capacité du canal (N) doit être basée sur une contrainte réelle : la limite du système (API, DB, etc.) ou le maximum de ressources que vous pouvez allouer. Ne la faites pas "au hasard".

5. Journalisation (Logging)

Dans un environnement de production, intégrez un logging pour tracer les moments d'acquisition et de libération des places. Cela permet de déboguer précisément les blocages et d'analyser le débit réel de votre système.

📌 Points clés à retenir

Le semaphore buffered channel Go est une méthode idiomatique pour limiter le nombre de goroutines actives simultanément.
Il utilise la capacité tampon d'un canal (<code>make(chan struct{}, N)</code>) pour fonctionner comme un compteur de places disponibles.
Acquérir une place se fait par un envoi <code>semaphore <- struct{}{}{}</code>, bloquant si le canal est plein.
Libérer une place se fait par une réception <code><-semaphore</code> (ou un envoi si on utilise le pattern suivant la libération).
L'utilisation de <code>defer</code> est vitale pour garantir que la place est libérée même en cas d'erreur (anti-Deadlock).
Il est essentiel d'accompagner ce pattern de <code>sync.WaitGroup</code> pour attendre l'achèvement de toutes les tâches.
Le type <code>struct{}{}</code> est préféré à tout autre type pour un usage de signal, car il n'occupe aucune mémoire.

📚 Articles liés

✅ Conclusion

En résumé, la maîtrise du semaphore buffered channel Go vous propulse au niveau de développeur Go expert. Nous avons vu que ce pattern n'est pas seulement une alternative au Mutex pour la limitation de concurrence, mais une manière beaucoup plus élégante, plus sûre et profondément ancrée dans la philosophie de Go : utiliser les canaux pour synchroniser et contrôler le flux d'exécution. Le mécanisme de la capacité tampon agit comme un interrupteur intelligent, régulant le débit en fonction des contraintes de ressources, qu'elles soient matérielles (CPU, bande passante) ou logiques (limites d'API).

Pour aller plus loin, je vous recommande de mettre en pratique ce pattern en simulant des scénarios de microservices qui dépendent de bases de données partagées ou de systèmes de files d'attente externes. Vous pouvez explorer des bibliothèques de Rate Limiting plus avancées basées sur ce principe. L'approche de Go, où les canaux remplacent souvent le passage explicite de verrous mutex, est un paradigme puissant qui, une fois compris, simplifie grandement la gestion de la complexité des systèmes distribués. La documentation officielle Go elle-même aborde les canaux, et une relecture de la documentation Go officielle dans ce contexte vous éclairera davantage.

N'hésitez pas à jouer avec les durées de sommeil et les capacités pour observer le comportement de blocage. C'est par la pratique que l'on maîtrise ces outils avancés. Nous espérons que cette plongée technique dans le semaphore buffered channel Go vous aura permis d'ajouter une compétence de niveau industriel à votre arsenal de développeur.

N'oubliez jamais : la concurrence est un art, et le semaphore buffered channel Go est votre pinceau le plus précis pour le contrôler. Lancez-vous dans des projets de traitement par lots ou d'intégration API pour solidifier vos compétences !

Semaphore buffered channel Go : Maîtriser la concurrence avancée

Semaphore buffered channel Go : Maîtriser la concurrence avancée

🛠️ Prérequis

Prérequis de Langage et Outils

📚 Comprendre semaphore buffered channel Go

Comment fonctionne le semaphore buffered channel Go ?

🐹 Le code — semaphore buffered channel Go

📖 Explication détaillée

Analyse détaillée du code source

🔄 Second exemple — semaphore buffered channel Go

▶️ Exemple d'utilisation

🚀 Cas d'usage avancés

1. Limiter l'accès aux API Externes (Rate Limiting)

2. Traitement de Workers dans un Batch Job

3. Gestion de Connexions HTTP Pool

4. Modélisation de Ressources Physiques Partagées

⚠️ Erreurs courantes à éviter

1. Oublier la libération de la place (Deadlock potentiel)

2. Utiliser un canal non tamponné (Unbuffered Channel)

3. Ne pas utiliser de `sync.WaitGroup`

4. Négliger le rôle de `struct{}`

✔️ Bonnes pratiques

1. Encapsuler le Semaphore dans une Structure

2. Gérer le Nettoyage avec `defer`

3. Tester les cas limites (Edge Cases)

4. Choisir la capacité judicieusement

5. Journalisation (Logging)

✅ Conclusion

Précision temporisage Go : Maîtriser les délais et éviter les pièges

Routeur Chi Go : l’art de la modularité HTTP

framework sivchari : mesurer la qualité des skills d’agents

Architecture hexagonale Go : Ports et Adapters maîtrisés

Go parsing arguments CLI : Maîtriser flag et cobra

maps en Go tables hachage : Maîtriser les structures de données

Un commentaire

Laisser un commentaire Annuler la réponse

Semaphore buffered channel Go : Maîtriser la concurrence avancée

🛠️ Prérequis

Prérequis de Langage et Outils

📚 Comprendre semaphore buffered channel Go

Comment fonctionne le semaphore buffered channel Go ?

🐹 Le code — semaphore buffered channel Go

📖 Explication détaillée

Analyse détaillée du code source

🔄 Second exemple — semaphore buffered channel Go

▶️ Exemple d'utilisation

🚀 Cas d'usage avancés

1. Limiter l'accès aux API Externes (Rate Limiting)

2. Traitement de Workers dans un Batch Job

3. Gestion de Connexions HTTP Pool

4. Modélisation de Ressources Physiques Partagées

⚠️ Erreurs courantes à éviter

1. Oublier la libération de la place (Deadlock potentiel)

2. Utiliser un canal non tamponné (Unbuffered Channel)

3. Ne pas utiliser de sync.WaitGroup

4. Négliger le rôle de struct{}

✔️ Bonnes pratiques

1. Encapsuler le Semaphore dans une Structure

2. Gérer le Nettoyage avec defer

3. Tester les cas limites (Edge Cases)

4. Choisir la capacité judicieusement

5. Journalisation (Logging)

✅ Conclusion

Publications similaires

Un commentaire

Laisser un commentaire Annuler la réponse

3. Ne pas utiliser de `sync.WaitGroup`

4. Négliger le rôle de `struct{}`

2. Gérer le Nettoyage avec `defer`