* Commentez aussi ce que vous avez essayé, ainsi je saurai que vous l'avez vérifié. 🤓

## Créer une Pull Request { #create-a-pull-request }

Vous pouvez [contribuer](contributing.md) au code source avec des Pull Requests, par exemple :

* Corriger une coquille que vous avez trouvée dans la documentation.

Reprenons ces concepts de déploiement vus précédemment :

* Sécurité - HTTPS
* Exécution au démarrage
* Redémarrages
* **Réplication (le nombre de processus en cours d'exécution)**
* Mémoire
* Étapes préalables avant le démarrage

## Une application avec des callbacks { #an-app-with-callbacks }

Voyons tout cela avec un exemple.

Imaginez que vous développiez une application qui permet de créer des factures.

Ces factures auront un `id`, un `title` (facultatif), un `customer` et un `total`.

L’utilisateur de votre API (une personne développeuse externe) créera une facture dans votre API avec une requête POST.

### Déclarer la dépendance, dans le « dependant » { #declare-the-dependency-in-the-dependant }

De la même manière que vous utilisez `Body`, `Query`, etc. avec les paramètres de votre fonction de chemin d’accès, utilisez `Depends` avec un nouveau paramètre :

{* ../../docs_src/dependencies/tutorial001_an_py310.py hl[13,18] *}

<img src="/img/tutorial/body/image03.png">

Et vous obtenez aussi des vérifications d'erreurs pour les opérations de types incorrectes :

<img src="/img/tutorial/body/image04.png">

Ce n'est pas un hasard, ce framework entier a été bâti avec ce design comme objectif.

dans une `JSONResponse`.

Si vous déclarez une `response_class` avec un media type JSON (`application/json`), comme c'est le cas avec `JSONResponse`, les données que vous renvoyez seront automatiquement converties (et filtrées) avec tout `response_model` Pydantic que vous avez déclaré dans le décorateur de *chemin d'accès*. Mais les données ne seront pas sérialisées en octets JSON avec Pydantic, elles seront converties avec le `jsonable_encoder` puis passées à la classe `JSONResponse`, qui les...

Par exemple :

* Avec **Docker Compose** sur un seul serveur
* Avec un cluster **Kubernetes**
* Avec un cluster Docker Swarm Mode
* Avec un autre outil comme Nomad
* Avec un service cloud qui prend votre image de conteneur et la déploie

## Image Docker avec `uv` { #docker-image-with-uv }

En utilisant un bloc `with`, nous nous assurons que l'objet de type fichier est fermé après l'exécution de la fonction génératrice (la fonction avec `yield`). Donc, après la fin de l'envoi de la réponse.

Ce ne serait pas si important dans cet exemple précis, car il s'agit d'un faux fichier en mémoire (avec `io.BytesIO`), mais avec un vrai fichier, il est important de s'assurer qu'il est fermé une fois le travail terminé.

Mais il est signé. Ainsi, quand vous recevez un jeton que vous avez émis, vous pouvez vérifier que vous l'avez bien émis.

De cette façon, vous pouvez créer un jeton avec une expiration d'une semaine, par exemple. Et quand l'utilisateur revient le lendemain avec ce jeton, vous savez qu'il est toujours connecté à votre système.

Et il est possible que, pour votre cas d’utilisation, la solution se trouve dans l’une d’entre elles.

///

## Lire d’abord le tutoriel { #read-the-tutorial-first }

Les sections suivantes partent du principe que vous avez déjà lu le [Tutoriel - Guide utilisateur : Sécurité](../../tutorial/security/index.md) principal.