---
title: "Signalement d’anomalies ou demandes de fonctionnalités"
version: 4.1
locale: fr
source: https://docs.djangoproject.com/fr/4.1/internals/contributing/bugs-and-features/
canonical: https://djangodocs.dev/fr/4.1/internals/contributing/bugs-and-features/
---
# Signalement d’anomalies ou demandes de fonctionnalités

> **Important**
>
> Veuillez signaler les problèmes de sécurité **uniquement** à l’adresse [security@djangoproject.com](mailto:security@djangoproject.com). C’est une liste privée uniquement ouverte à des développeurs Django de longue date et extrêmement fiables, et ses archives ne sont pas publiques. Pour plus de détails, veuillez consulter nos [politiques de sécurité](/fr/4.1/internals/security/).

Sinon, avant de signaler une anomalie ou de demander une nouvelle fonctionnalité dans le [suivi des tickets](https://code.djangoproject.com/), tenez compte des point suivants :

- Vérifiez que quelqu’un n’a pas déjà signalé le problème ou demandé la fonctionnalité en [cherchant](https://code.djangoproject.com/query) ou en exécutant des [requêtes personnalisées](https://code.djangoproject.com/search) dans notre système de tickets.
- N’utilisez pas le système des tickets pour poser des questions d’aide. Utilisez la liste [django-users](/fr/4.1/internals/mailing-lists/#django-users-mailing-list) ou le canal IRC [#django](https://web.libera.chat/#django) à cet effet.
- Ne réouvrez pas des rapports qui ont été marqués comme `wontfix` sans d’abord chercher un consensus sur la liste [django-developers](/fr/4.1/internals/mailing-lists/#django-developers-mailing-list).
- N’utilisez pas le système des tickets pour de longues discussions, car elles risquent de se perdre. Si un ticket particulier est sujet à controverse, veuillez faire passer la discussion sur la liste [django-developers](/fr/4.1/internals/mailing-lists/#django-developers-mailing-list).

## Signalement d’anomalies

Des rapports d’anomalies bien écrits sont *extrêmement* utiles. Cependant, il y a toujours un certain travail à effectuer dans un système de gestion des anomalies, votre aide pour conserver notre système utilisable est donc appréciée. En particulier :

- **Lisez** la [FAQ](/fr/4.1/faq/) pour voir si votre problème n’est pas une question régulièrement posée.
- **Demandez d’abord** sur [django-users](/fr/4.1/internals/mailing-lists/#django-users-mailing-list) ou [#django](https://web.libera.chat/#django) si vous n’êtes pas sûr que ce que vous voyez est réellement une anomalie.
- **Écrivez** des rapports d’anomalies complets, reproductibles et précis. Vous devez inclure une description claire et concise du problème ainsi qu’une série d’instructions pour le reproduire. Ajoutez autant d’informations de débogage que possible : extraits de code, cas de test, traces d’exceptions, captures d’écran, etc. Un petit cas de test bien fait est la meilleure manière de signaler une anomalie, car cela permet de confirmer rapidement la validité du problème rencontré.
- **N’écrivez pas** à [django-developers](/fr/4.1/internals/mailing-lists/#django-developers-mailing-list) seulement pour annoncer que vous avez rédigé un rapport d’anomalie. Tous les tickets apparaissent dans une autre liste, [django-updates](/fr/4.1/internals/mailing-lists/#django-updates-mailing-list), qui est suivie par les développeurs et les membres intéressés de la communauté ; nous les voyons au fur et à mesure de leur création.

Pour comprendre le cycle de vie d’un ticket après sa création, consultez [Tri des tickets](/fr/4.1/internals/contributing/triaging-tickets/).

## Signalement d’anomalies ou de fonctionnalités de l’interface utilisateur

Si le problème ou la demande de fonctionnalité se rapporte à un élément visuel, voici quelques consignes supplémentaires à suivre :

- Include screenshots in your ticket which are the visual equivalent of a
  minimal test case. Show off the issue, not the crazy customizations
  you’ve made to your browser.
- Si le problème est difficile à démontrer par une image figée, envisagez de capturer une *brève* séquence vidéo. Si votre logiciel le permet, ne capturez que la partie significative de l’écran.
- If you’re offering a patch that changes the look or behavior of Django’s
  UI, you **must** attach before *and* after screenshots/screencasts.
  Tickets lacking these are difficult for triagers to assess quickly.
- Les captures d’écran ne dispensent pas des autres bonnes pratiques de signalement. Prenez soin d’inclure des URL, des extraits de code et des instructions pas à pas sur la façon de reproduire les comportements visibles dans les captures d’écran.
- Prenez soin de cocher l’option UI/UX du ticket afin que les personnes les plus concernées puissent trouver votre ticket.

## Demandes de fonctionnalités

Nous essayons de constamment améliorer Django, et vos demandes de fonctionnalités constituent un élément clé de ce processus. Voici quelques astuces pour rédiger une demande de la manière la plus efficace possible :

- Vérifiez que la fonctionnalité demande effectivement des modifications dans le cœur de Django. SI votre idée peut être développée en tant qu’application ou module indépendant, par exemple pour ajouter la prise en charge d’un nouveau moteur de base de données, on vous suggérera certainement de la développer de manière indépendante. Puis, si le projet obtient suffisamment de soutien de la communauté, il pourra être considéré comme candidat à l’inclusion dans Django.
- Parlez d’abord de la fonctionnalité sur la liste de diffusion [django-developers](/fr/4.1/internals/mailing-lists/#django-developers-mailing-list), et non dans le système des tickets. L’audience sera plus large sur la liste. C’est d’autant plus important si la demande de fonctionnalité est d’une certaine ampleur. Les développeurs de Django apprécient de discuter premièrement des changements importants sur la liste de diffusion avant de commencer à travailler concrètement sur le code.
- Décrivez clairement et courtement la fonctionnalité manquante et la manière dont vous souhaiteriez qu’elle soit implémentée. Ajoutez si possible du code d’exemple (même non fonctionnel).
- Expliquez *pourquoi* vous souhaitez cette fonctionnalité. En présentant un cas d’utilisation minimal, cela aidera d’autres à comprendre le contexte de la demande et s’il existe déjà d’autres manières d’arriver au même résultat.

If there’s a consensus agreement on the feature, then it’s appropriate to
create a ticket. Include a link to the discussion on [django-developers](/fr/4.1/internals/mailing-lists/#django-developers-mailing-list) in the
ticket description.

Comme pour la plupart des projets de logiciels libres, le code parle. Si vous êtes disposé à écrire vous-même le code de la fonctionnalité ou même mieux, si vous l’avez déjà écrit, les probabilités de son acceptation sont encore plus fortes. Créez un `fork` Django sur GitHub, ajoutez une branche de fonctionnalité et montrez-nous votre code !

Voir aussi [Documentation de nouvelles fonctionnalités](/fr/4.1/internals/contributing/writing-documentation/#documenting-new-features).

## Comment nous prenons des décisions

Whenever possible, we strive for a rough consensus. To that end, we’ll often
have informal votes on [django-developers](/fr/4.1/internals/mailing-lists/#django-developers-mailing-list) or the Django Forum about a feature.
In these votes we follow the voting style invented by Apache and used on Python
itself, where votes are given as +1, +0, -0, or -1.
Roughly translated, these votes mean:

- +1 : « J’aime bien l’idée et je l’appuie sans réserve ».
- +0 : « Ça me semble OK ».
- -0 : « Je ne suis pas convaincu, mais je n’ai pas l’intention de m’y opposer ».
- -1 : « Je désapprouve fortement et je serai contrarié de voir l’idée se concrétiser ».

Although these votes are informal, they’ll be taken very seriously. After a
suitable voting period, if an obvious consensus arises we’ll follow the votes.

However, consensus is not always possible. If consensus cannot be reached, or
if the discussion toward a consensus fizzles out without a concrete decision,
the decision may be deferred to the [steering council](/fr/4.1/internals/organization/#steering-council).

Internally, the steering council will use the same voting mechanism. A
proposition will be considered carried if:

- There are at least three « +1 » votes from members of the steering council.
- There is no « -1 » vote from any member of the steering council.

Les votes devraient être soumis en l’espace d’une semaine.

Since this process allows any steering council member to veto a proposal, a
« -1 » vote should be accompanied by an explanation of what it would take to
convert that « -1 » into at least a « +0 ».

Votes on technical matters should be announced and held in public on the
[django-developers](/fr/4.1/internals/mailing-lists/#django-developers-mailing-list) mailing list or on the Django Forum.