---
title: "L’application de gestion des fichiers statiques (staticfiles)"
version: 1.11
locale: fr
source: https://docs.djangoproject.com/fr/1.11/ref/contrib/staticfiles/
canonical: https://djangodocs.dev/fr/1.11/ref/contrib/staticfiles/
---
# L’application de gestion des fichiers statiques (`staticfiles`)

`django.contrib.staticfiles` recueille les fichiers statiques à partir de chacune des applications (et de tous les autres endroits que vous spécifiez) en un seul endroit qui peut facilement être utilisé en production.

> **See also**
>
> Pour une introduction à l’application et quelques exemples d’utilisation des fichiers statiques, voir  [Gestion des fichiers statiques (par ex. images, JavaScript, CSS)](/fr/1.11/howto/static-files/). Pour obtenir des instructions sur le déploiement des fichiers statiques, voir [Déploiement des fichiers statiques](/fr/1.11/howto/static-files/deployment/).

## Réglages

Voir [réglages de staticfiles](/fr/1.11/ref/settings/#settings-staticfiles) pour plus de détails sur les réglages suivants :

- [`STATIC_ROOT`](/fr/1.11/ref/settings/#std-setting-STATIC_ROOT)
- [`STATIC_URL`](/fr/1.11/ref/settings/#std-setting-STATIC_URL)
- [`STATICFILES_DIRS`](/fr/1.11/ref/settings/#std-setting-STATICFILES_DIRS)
- [`STATICFILES_STORAGE`](/fr/1.11/ref/settings/#std-setting-STATICFILES_STORAGE)
- [`STATICFILES_FINDERS`](/fr/1.11/ref/settings/#std-setting-STATICFILES_FINDERS)

## Commandes d’administration

`django.contrib.staticfiles` propose trois commandes d’administration.

### `collectstatic`

#### `django-admin collectstatic`

Recueille les fichiers statiques dans le répertoire [`STATIC_ROOT`](/fr/1.11/ref/settings/#std-setting-STATIC_ROOT).

Lorsque deux fichiers ont le même nom, le problème est résolu par défaut d’une façon similaire à la façon dont fonctionne la résolution des gabarits : le premier fichier trouvé est utilisé. En cas d’incertitude, la commande [`findstatic`](#django-admin-findstatic) peut vous montrer quels sont les fichiers trouvés.

Lors des prochains lancements de `collectstatic` (si `STATIC_ROOT` n’est pas vide), les fichiers ne sont copiés que si leur date de modification est plus récente que la date de modification du fichier dans `STATIC_ROOT`. Ainsi, si vous supprimez une application de [`INSTALLED_APPS`](/fr/1.11/ref/settings/#std-setting-INSTALLED_APPS), il est recommandé d’utiliser l’option [`collectstatic --clear`](#cmdoption-collectstatic-clear) afin de supprimer les fichiers statiques obsolètes.

La recherche des fichiers utilise le réglage [`STATICFILES_FINDERS`](/fr/1.11/ref/settings/#std-setting-STATICFILES_FINDERS). Par défaut, Django parcourt tous les emplacements définis dans [`STATICFILES_DIRS`](/fr/1.11/ref/settings/#std-setting-STATICFILES_DIRS) et dans le répertoire `'static'` des applications figurant dans le réglage [`INSTALLED_APPS`](/fr/1.11/ref/settings/#std-setting-INSTALLED_APPS) .

La commande d’administration [`collectstatic`](#django-admin-collectstatic) appelle la méthode [`post_process()`](#django.contrib.staticfiles.storage.StaticFilesStorage.post_process) du système de stockage [`STATICFILES_STORAGE`](/fr/1.11/ref/settings/#std-setting-STATICFILES_STORAGE) après chacune de ses exécutions et lui passe une liste des chemins qu’elle a trouvés. La méthode reçoit également toutes les options de ligne de commande de [`collectstatic`](#django-admin-collectstatic). C’est utilisé par la classe [`CachedStaticFilesStorage`](#django.contrib.staticfiles.storage.CachedStaticFilesStorage) par défaut.

Par défaut, les fichiers collectés reçoivent les autorisations du réglage [`FILE_UPLOAD_PERMISSIONS`](/fr/1.11/ref/settings/#std-setting-FILE_UPLOAD_PERMISSIONS)  et les répertoires reçoivent les autorisations de [`FILE_UPLOAD_DIRECTORY_PERMISSIONS`](/fr/1.11/ref/settings/#std-setting-FILE_UPLOAD_DIRECTORY_PERMISSIONS). Si vous souhaitez des autorisations différentes pour ces fichiers ou répertoires, vous pouvez créer une sous-classe des [classes de stockage des fichiers statiques](#staticfiles-storages) et spécifier les paramètres `file_permissions_mode` ou `directory_permissions_mode`. Par exemple :

```
from django.contrib.staticfiles import storage

class MyStaticFilesStorage(storage.StaticFilesStorage):
    def __init__(self, *args, **kwargs):
        kwargs['file_permissions_mode'] = 0o640
        kwargs['directory_permissions_mode'] = 0o760
        super(MyStaticFilesStorage, self).__init__(*args, **kwargs)
```

Définissez ensuite le réglage [`STATICFILES_STORAGE`](/fr/1.11/ref/settings/#std-setting-STATICFILES_STORAGE) à `'chemin.vers.MyStaticFilesStorage'`.

Certaines options couramment utilisées sont :

#### `--noinput, --no-input`

Ne pose AUCUNE question à l’utilisateur.

#### `--ignore PATTERN, -i PATTERN`

Ignore les fichiers ou les répertoires correspondant à ce motif de style « glob ». Peut être utilisé plusieurs fois pour ignorer plusieurs chemins.

#### `--dry-run, -n`

Exécute la commande normalement, mais sans toucher réellement au système de fichiers.

#### `--clear, -c`

Efface les fichiers existants avant d’essayer de copier ou de lier le fichier d’origine.

#### `--link, -l`

Crée un lien symbolique vers chaque fichier au lieu de copier.

#### `--no-post-process`

N’appelle pas la méthode [`post_process()`](#django.contrib.staticfiles.storage.StaticFilesStorage.post_process) du moteur de stockage configuré dans [`STATICFILES_STORAGE`](/fr/1.11/ref/settings/#std-setting-STATICFILES_STORAGE).

#### `--no-default-ignore`

N’ignore pas les motifs de style « glob » \`\` “CVS”```, ``'.*'``` et `'*~'` qui sont normalement toujours ignorés.

Pour une liste complète des options, reportez-vous à l’aide des commandes elles-mêmes en exécutant :

```console
$ python manage.py collectstatic --help
```

#### Personnalisation de la liste des motifs ignorés

> **New in Django 1.10**

La liste des motifs ignorés par défaut, `['CVS', '.*', '*~']`, peut être personnalisée de manière plus permanente que de fournir l’option en ligne de commande `--ignore` lors de chaque invocation de `collectstatic`. Ajoutez une classe [`AppConfig`](/fr/1.11/ref/applications/#django.apps.AppConfig) personnalisée, surchargez l’attribut `ignore_patterns` de la classe et remplacez `'django.contrib.staticfiles'` dans le réglage [`INSTALLED_APPS`](/fr/1.11/ref/settings/#std-setting-INSTALLED_APPS) par le chemin de cette classe :

```python
from django.contrib.staticfiles.apps import StaticFilesConfig

class MyStaticFilesConfig(StaticFilesConfig):
    ignore_patterns = [...]  # your custom ignore list
```

### `findstatic`

#### `django-admin findstatic staticfile [staticfile ...]`

Recherche un ou plusieurs chemins relatifs en fonction des chercheurs activés.

Par exemple :

```console
$ python manage.py findstatic css/base.css admin/js/core.js
Found 'css/base.css' here:
  /home/special.polls.com/core/static/css/base.css
  /home/polls.com/core/static/css/base.css
Found 'admin/js/core.js' here:
  /home/polls.com/src/django/contrib/admin/media/js/core.js
```

#### `findstatic --first`

Par défaut, tous les emplacements trouvés sont utilisés. Pour ne renvoyer que le premier chemin relatif trouvé, utilisez l’option `--first`:

```console
$ python manage.py findstatic css/base.css --first
Found 'css/base.css' here:
  /home/special.polls.com/core/static/css/base.css
```

Il s’agit d’une outil de débogage ; vous verrez exactement quel fichier statique sera trouvé pour un chemin donné.

En mettant le drapeau `--verbosity` à 0, vous pouvez supprimer les explications complémentaires et obtenir uniquement les noms de chemins :

```console
$ python manage.py findstatic css/base.css --verbosity 0
/home/special.polls.com/core/static/css/base.css
/home/polls.com/core/static/css/base.css
```

D’autre part, en mettant l’option `--verbosity` à 2, vous pouvez obtenir la liste de tous les répertoires qui ont été recherchés :

```console
$ python manage.py findstatic css/base.css --verbosity 2
Found 'css/base.css' here:
  /home/special.polls.com/core/static/css/base.css
  /home/polls.com/core/static/css/base.css
Looking in the following locations:
  /home/special.polls.com/core/static
  /home/polls.com/core/static
  /some/other/path/static
```

### `runserver`

#### `django-admin runserver [addrport]`

Remplace la commande de base [`runserver`](/fr/1.11/ref/django-admin/#django-admin-runserver) si l’application `staticfiles` est [`installée`](/fr/1.11/ref/settings/#std-setting-INSTALLED_APPS), et ajoute automatiquement le service des fichiers statiques. Le service des fichiers n’utilise pas le réglage [`MIDDLEWARE`](/fr/1.11/ref/settings/#std-setting-MIDDLEWARE).

La commande ajoute ces options :

#### `--nostatic`

Utilisez l’option `--nostatic` pour désactiver entièrement le service des fichiers statiques avec  l’application [staticfiles](/fr/1.11/ref/contrib/staticfiles/). Cette option n’est disponible que si l’application [staticfiles](/fr/1.11/ref/contrib/staticfiles/) fait partie du réglage [`INSTALLED_APPS`](/fr/1.11/ref/settings/#std-setting-INSTALLED_APPS) de votre projet.

Exemple d’utilisation :

```console
django-admin runserver --nostatic
```

#### `--insecure`

Utilisez l’option `--insecure` pour forcer le service des fichiers statiques avec l’application [staticfiles](/fr/1.11/ref/contrib/staticfiles/) même quand le réglage [`DEBUG`](/fr/1.11/ref/settings/#std-setting-DEBUG) est à `False`. En utilisant cette option, vous reconnaissez le fait que c’est **totalement inefficace** et très probablement **non sécurisé**. Cette option est uniquement destinée au développement en local et ne devrait **jamais être utilisée en production**. Elle n’est disponible que si l’application [staticfiles](/fr/1.11/ref/contrib/staticfiles/) se trouve dans le réglage [`INSTALLED_APPS`](/fr/1.11/ref/settings/#std-setting-INSTALLED_APPS) de votre projet. [`runserver`](/fr/1.11/ref/django-admin/#django-admin-runserver) `--insecure` ne fonctionne pas avec la classe [`CachedStaticFilesStorage`](#django.contrib.staticfiles.storage.CachedStaticFilesStorage).

Exemple d’utilisation :

```console
django-admin runserver --insecure
```

## Stockages

### `StaticFilesStorage`

#### `class storage.StaticFilesStorage`

Une sous-classe du moteur de stockage [`FileSystemStorage`](/fr/1.11/ref/files/storage/#django.core.files.storage.FileSystemStorage) qui utilise le réglage [`STATIC_ROOT`](/fr/1.11/ref/settings/#std-setting-STATIC_ROOT) comme emplacement de base dans le système de fichiers et le réglage [`STATIC_URL`](/fr/1.11/ref/settings/#std-setting-STATIC_URL) comme URL de base.

#### `storage.StaticFilesStorage.post_process(paths, **options)`

Cette méthode est appelée par la commande d’administration [`collectstatic`](#django-admin-collectstatic) après chacune de ses exécutions. Elle reçoit les stockages et chemins locaux des fichiers trouvés sous la forme d’un dictionnaire, ainsi que les options de ligne de commande.

Le stockage [`CachedStaticFilesStorage`](#django.contrib.staticfiles.storage.CachedStaticFilesStorage) utilise cette classe en coulisses pour remplacer les chemins par leur équivalent « haché » et mettre à jour le cache de manière appropriée.

### `ManifestStaticFilesStorage`

#### `class storage.ManifestStaticFilesStorage`

Une sous-classe du moteur de stockage [`StaticFilesStorage`](#django.contrib.staticfiles.storage.StaticFilesStorage) qui modifie les noms des fichiers qu’elle traite en ajoutant le hachage MD5 du contenu du fichier au nom de fichier. Par exemple, le fichier `css/styles.css` serait également enregistré en tant que `css/styles.55e7cbb9ba48.css`.

Le but de ce stockage est de continuer à servir les anciens fichiers au cas où certaines pages se réfèrent encore à ces fichiers, par exemple parce qu’elles sont mises en cache par vous-même ou un serveur mandataire externe. En outre, cela est très utile si vous souhaitez appliquer des [en-têtes à date d’expiration très lointaine](https://developer.yahoo.com/performance/rules.html#expires) aux fichiers déployés pour accélérer le temps de chargement des pages lors des visites ultérieures.

Le moteur de stockage remplace automatiquement dans les fichiers enregistrés les chemins qui correspondent aux autres fichiers enregistrés par les chemins des copies en cache (en utilisant la méthode [`post_process()`](#django.contrib.staticfiles.storage.StaticFilesStorage.post_process)). Les expressions régulières utilisées pour rechercher ces chemins (`django.contrib.staticfiles.storage.HashedFilesMixin.patterns`) couvrent par défaut la règle [@import](http://www.w3.org/TR/CSS2/cascade.html#at-import) et l’instruction [url()](http://www.w3.org/TR/CSS2/syndata.html#uri) des [feuilles de style CSS](http://www.w3.org/Style/CSS/). Par exemple, le fichier `'css/styles.css'` avec le contenu

```css+django
@import url("../admin/css/base.css");
```

serait remplacé par l’appel de la méthode [`url()`](/fr/1.11/ref/files/storage/#django.core.files.storage.Storage.url) du moteur de stockage `ManifestStaticFilesStorage`, enregistrant finalement un fichier `'css/styles.55e7cbb9ba48.css'` avec le contenu suivant :

```css+django
@import url("../admin/css/base.27e20196a850.css");
```

#### `storage.ManifestStaticFilesStorage.max_post_process_passes`

Comme les fichiers statiques peuvent se référer à d’autres fichiers statiques qui ont besoin d’un remplacement de chemins, plusieurs passes de remplacements de chemins peuvent être nécessaires jusqu’à ce que les hachages de fichier convergent. Pour éviter une boucle sans fin en raison de hachages non convergeant (par exemple, si `'foo.css'` se réfère à `'bar.css'` qui référence `'foo.css'`), un nombre maximum de passes est défini avant qu’un post-traitement soit abandonné. Dans le cas d’un nombre de références élevé, il pourrait être nécessaire d’augmenter ce nombre de passes. Ceci peut se faire en créant une sous-classe de `ManifestStaticFilesStorage` et en définissant l’attribut `max_post_process_passes`. Sa valeur par défaut est 5.

> **Changed in Django 1.11**
>
> Les versions précédentes ne procédaient pas à plusieurs passes pour s’assurer que les hachages de fichiers convergent, il arrivait donc fréquemment que ces hachages soient incorrects. L’attribut `max_post_process_passes` a été ajouté.

Pour activer le stockage `ManifestStaticFilesStorage`, vous devez vous assurer que les conditions suivantes sont remplies :

- le réglage [`STATICFILES_STORAGE`](/fr/1.11/ref/settings/#std-setting-STATICFILES_STORAGE) contient `'django.contrib.staticfiles.storage.ManifestStaticFilesStorage'`
- le réglage [`DEBUG`](/fr/1.11/ref/settings/#std-setting-DEBUG)  contient `False`
- vous avez recueilli tous les fichiers statiques en utilisant la commande d’administration [`collectstatic`](#django-admin-collectstatic)

> **Changed in Django 1.10**
>
> Dans les versions précédentes, il fallait aussi ajouter `{% load static from staticfiles %}` dans le gabarit. La balise de gabarit [`static`](/fr/1.11/ref/templates/builtins/#std-templatetag-static) (`{% load static %}`) utilise dorénavant [`django.contrib.staticfiles`](#module-django.contrib.staticfiles) si cette application est installée.

Comme la création du hachage MD5 peut diminuer la performance de votre site Web, `staticfiles` stocke automatiquement la correspondance des noms hachés pour chaque fichier traité dans un fichier nommé  `staticfiles.json`. Cela se produit une seule fois au moment où vous exécutez la commande [`collectstatic`](#django-admin-collectstatic).

#### `storage.ManifestStaticFilesStorage.manifest_strict`

Si un fichier n’est pas trouvé dans le manifeste `staticfiles.json` lors de l’exécution, une exception `ValueError` est générée. Ce comportement peut être désactivé en créant une sous-classe de `ManifestStaticFilesStorage` et en définissant l’attribut `manifest_strict` à `False` – les chemins non existants seront laissés inchangés.

> **Changed in Django 1.11**
>
> L’attribut `manifest_strict` a été ajouté. Dans les versions précédentes, le comportement était le même qu’avec `manifest_strict=False`.

Comme il faut que la commande [`collectstatic`](#django-admin-collectstatic) ait été lancée, ce stockage ne doit normalement pas être utilisé lors de l’exécution des tests car `collectstatic` n’est pas exécutée dans une configuration de test normale. Lors des tests, vérifiez que le réglage [`STATICFILES_STORAGE`](/fr/1.11/ref/settings/#std-setting-STATICFILES_STORAGE) est défini sur autre chose, comme par exemple la valeur par défaut  `'django.contrib.staticfiles.storage.StaticFilesStorage'`.

#### `storage.ManifestStaticFilesStorage.file_hash(name, content=None)`

La méthode utilisée lors de la création du nom haché d’un fichier. Doit renvoyer une empreinte de hachage pour le nom de fichier donné et son contenu. Par défaut, on calcule un hachage MD5 à partir du contenu comme mentionné ci-dessus. N’hésitez pas à redéfinir cette méthode pour utiliser votre propre algorithme de hachage.

### `CachedStaticFilesStorage`

#### `class storage.CachedStaticFilesStorage`

`CachedStaticFilesStorage` est une classe semblable à la classe [`ManifestStaticFilesStorage`](#django.contrib.staticfiles.storage.ManifestStaticFilesStorage) mais utilise l”[infrastructure de cache](/fr/1.11/topics/cache/) de Django pour stocker les noms hachés des fichiers traités au lieu d’un fichier manifeste statique nommé `staticfiles.json`. C’est surtout utile dans les situations dans lesquelles vous n’avez pas accès au système de fichiers.

Si vous souhaitez remplacer certaines options du moteur de cache utilisé pour le stockage, il vous suffit de spécifier une entrée particulière dans le réglage [`CACHES`](/fr/1.11/ref/settings/#std-setting-CACHES) en la nommant `'staticfiles'`. Par défaut, c’est le moteur de cache `'default'` qui est utilisé.

> **Warning**
>
> `CachedStaticFilesStorage` n’est pas recommandé, car dans presque tous les cas, `ManifestStaticFilesStorage` est un meilleur choix. Il y a plusieurs limites de performance en utilisant `CachedStaticFilesStorage` car une absence dans le cache implique un hachage de fichier au moment de l’exécution. Les stockages de fichiers distants nécessitent plusieurs allers-retours pour hacher un fichier lors d’une absence dans le cache, car plusieurs accès de fichiers sont nécessaires pour s’assurer que le hachage de fichier est correct dans le cas de chemins de fichiers imbriqués.

## Le module `finders`

Le module `finders` (découverte des fichiers statiques) de `staticfiles` possède un attribut `searched_locations` qui est une liste de chemins de répertoires dans lesquels des fichiers statiques ont été recherchés. Exemple d’utilisation :

```console
from django.contrib.staticfiles import finders

result = finders.find('css/base.css')
searched_locations = finders.searched_locations
```

## Autres utilitaires

Il existe quelques autres utilitaires en plus de l’application [`staticfiles`](#module-django.contrib.staticfiles) pour gérer les fichiers statiques :

- Le processeur de contexte [`django.template.context_processors.static()`](/fr/1.11/ref/templates/api/#django.template.context_processors.static) qui ajoute [`STATIC_URL`](/fr/1.11/ref/settings/#std-setting-STATIC_URL) au contexte de chaque gabarit rendu avec [`RequestContext`](/fr/1.11/ref/templates/api/#django.template.RequestContext).
- La balise de gabarit [`static`](/fr/1.11/ref/templates/builtins/#std-templatetag-static) de base qui prend un chemin et le combine avec le préfixe statique [`STATIC_URL`](/fr/1.11/ref/settings/#std-setting-STATIC_URL). Si `django.contrib.staticfiles` est installée, la balise utilise plutôt la méthode `url()` de [`STATICFILES_STORAGE`](/fr/1.11/ref/settings/#std-setting-STATICFILES_STORAGE).
- La balise de gabarit [`get_static_prefix`](/fr/1.11/ref/templates/builtins/#std-templatetag-get_static_prefix) qui renseigne une variable de gabarit avec le préfixe statique [`STATIC_URL`](/fr/1.11/ref/settings/#std-setting-STATIC_URL) pour utilisation immédiate ou stockée dans une variable.
- La balise de gabarit similaire [`get_media_prefix`](/fr/1.11/ref/templates/builtins/#std-templatetag-get_media_prefix) qui fonctionne comme [`get_static_prefix`](/fr/1.11/ref/templates/builtins/#std-templatetag-get_static_prefix) mais utilise [`MEDIA_URL`](/fr/1.11/ref/settings/#std-setting-MEDIA_URL).

### Vue pour l’utilisation des fichiers statiques en développement

Les outils concernant les fichiers statiques sont principalement conçus pour aider à déployer correctement les fichiers statiques en production. Cela implique généralement de dédier un serveur distinct pour les fichiers statiques, ce qui induit de trop nombreuses actions supplémentaires lorsque l’on développe en local sur un environnement de développement. Ainsi, l’application `staticfiles` est fournie avec une **vue à la va-vite** que vous pouvez utiliser pour s’occuper du service des fichiers lors du développement local.

#### `views.serve(request, path)`

Cette fonction de vue sert les fichiers statiques lors du développement.

> **Warning**
>
> Cette vue ne fonctionne que si le réglage [`DEBUG`](/fr/1.11/ref/settings/#std-setting-DEBUG) vaut `True`.
>
> C’est parce que cette vue est **totalement inefficace** et probablement **non sécurisée**. Elle n’est destinée qu’au développement en local et ne devrait **jamais être utilisée en production**.

> **Note**
>
> Pour deviner les types de contenu des fichiers servis, cette vue exploite le module [`mimetypes`](https://docs.python.org/3/library/mimetypes.html#module-mimetypes) de la bibliothèque Python standard, qui se base elle-même sur la correspondance des types de fichiers de la plate-forme sous-jacente. Si vous trouvez que cette vue ne renvoie pas les bons types de contenu pour certains fichiers, il est plus que probable que la correspondance des types de fichiers de la plate-forme doit être mise à jour. Ceci peut par exemple être réalisé par l’installation ou la mise à jour du paquet `mailcap` sur une distribution Red Hat, ou du paquet `mime-support` sur une distribution Debian.

Cette vue est automatiquement activée par [`runserver`](/fr/1.11/ref/django-admin/#django-admin-runserver) (avec le réglage [`DEBUG`](/fr/1.11/ref/settings/#std-setting-DEBUG) à `True`). Pour utiliser la vue avec un autre serveur de développement local, ajoutez le code suivant à la fin de la configuration d’URL principale :

```python
from django.conf import settings
from django.contrib.staticfiles import views

if settings.DEBUG:
    urlpatterns += [
        url(r'^static/(?P<path>.*)$', views.serve),
    ]
```

Remarque : le début du motif (`r'^static/'`) devrait correspondre au réglage [`STATIC_URL`](/fr/1.11/ref/settings/#std-setting-STATIC_URL).

Comme c’est un peu fastidieux, il existe aussi une fonction utilitaire qui fait cela pour vous :

#### `urls.staticfiles_urlpatterns()`

Cela renvoie le motif d’URL approprié pour servir les fichiers statiques et peut être ajouté à la liste de motifs d’URL déjà définie. Utilisez-la comme ceci :

```python
from django.contrib.staticfiles.urls import staticfiles_urlpatterns

# ... the rest of your URLconf here ...

urlpatterns += staticfiles_urlpatterns()
```

Cette fonction examine le réglage [`STATIC_URL`](/fr/1.11/ref/settings/#std-setting-STATIC_URL) et connecte la vue de service des fichiers statiques en conséquence. N’oubliez pas de définir le réglage [`STATICFILES_DIRS`](/fr/1.11/ref/settings/#std-setting-STATICFILES_DIRS) approprié pour faire savoir à `django.contrib.staticfiles` où rechercher les fichiers en plus des fichiers dans les répertoires des applications.

> **Warning**
>
> Cette fonction utilitaire ne fonctionne que si [`DEBUG`](/fr/1.11/ref/settings/#std-setting-DEBUG) vaut `True` et que le réglage [`STATIC_URL`](/fr/1.11/ref/settings/#std-setting-STATIC_URL) n’est ni vide ni une URL complète comme `http://static.example.com/`.
>
> C’est parce que cette vue est **totalement inefficace** et probablement **non sécurisée**. Elle n’est destinée qu’au développement en local et ne devrait **jamais être utilisée en production**.

### Cas de test particulier pour permettre le « test en live »

#### `class testing.StaticLiveServerTestCase`

Cette sous-classe de test unitaire `TestCase` hérite de [`django.test.LiveServerTestCase`](/fr/1.11/topics/testing/tools/#django.test.LiveServerTestCase).

Tout comme sa classe parente, vous pouvez l’utiliser pour écrire des tests qui impliquent le fonctionnement du code testé et de son exploitation par des outils de test à travers HTTP (par ex. Selenium, PhantomJS, etc.), et pour lesquels il est nécessaire que les fichiers statiques soient également disponibles.

Mais étant donné qu’elle fait appel à la vue [`django.contrib.staticfiles.views.serve()`](#django.contrib.staticfiles.views.serve) présentée plus haut, elle peut servir de manière transparente au moment de l’exécution des tests les ressources statiques mises à disposition par le moteur de découverte de `staticfiles`. Cela signifie que vous n’avez pas besoin de lancer [`collectstatic`](#django-admin-collectstatic) préalablement ou dans le cadre de la configuration des tests.
