---
title: "Conseils pour les nouveaux contributeurs"
version: 2.1
locale: fr
source: https://docs.djangoproject.com/fr/2.1/internals/contributing/new-contributors/
canonical: https://djangodocs.dev/fr/2.1/internals/contributing/new-contributors/
---
# Conseils pour les nouveaux contributeurs

Nouveau contributeur et vous ne savez pas que faire ? Vous souhaitez aider mais ne savez pas par où commencer ? Cette section est pour vous.

> **Outils de base et flux de travail**
>
> Si vous débutez dans la contribution à Django, le tutoriel [Écriture de votre premier correctif pour Django](/fr/2.1/intro/contributing/) vous donne une introduction aux outils et au flux de travail.

## Premiers pas

Commencez par ces tâches faciles pour découvrir le processus de développement de Django.

- **Signer l’accord de licence de contribution**

  Le code que vous écrivez vous appartient ou il appartient à votre employeur. Si votre contribution dépasse une ou deux lignes de code, vous devez signer le [CLA](https://www.djangoproject.com/foundation/cla/). Voir la [FAQ sur l’accord de licence de contribution](https://www.djangoproject.com/foundation/cla/faq/) pour une explication plus complète.
- **Trier des tickets**

  If an [unreviewed ticket](https://code.djangoproject.com/query?status=!closed&stage=Unreviewed) reports a bug, try and reproduce it. If you
  can reproduce it and it seems valid, make a note that you confirmed the bug
  and accept the ticket. Make sure the ticket is filed under the correct
  component area. Consider writing a patch that adds a test for the bug’s
  behavior, even if you don’t fix the bug itself. See more at
  [Commet puis-je aider à trier les tickets ?](/fr/2.1/internals/contributing/triaging-tickets/#how-can-i-help-with-triaging)
- **Look for tickets that are accepted and review patches to build familiarity
  with the codebase and the process**

  Mark the appropriate flags if a patch needs docs or tests. Look through the
  changes a patch makes, and keep an eye out for syntax that is incompatible
  with older but still supported versions of Python. [Run the tests](/fr/2.1/internals/contributing/writing-code/unit-tests/) and make sure they pass.
  Where possible and relevant, try them out on a database other than SQLite.
  Leave comments and feedback!
- **Garder les anciens correctifs à jour**

  Oftentimes the codebase will change between a patch being submitted and the
  time it gets reviewed. Make sure it still applies cleanly and functions as
  expected. Simply updating a patch is both useful and important! See more on
  [Soumission de correctifs](/fr/2.1/internals/contributing/writing-code/submitting-patches/).
- **Écrire de la documentation**

  La documentation de Django est bien faite mais elle peut toujours être améliorée. Avez-vous trouvé une faute d’orthographe ? Pensez-vous que quelque chose devrait être clarifié ? Lancez-vous et proposez un correctif de la documentation ! Voir aussi le guide sur [Écrire la documentation](/fr/2.1/internals/contributing/writing-documentation/).

  > **Note**
  >
  > La [page des rapports](https://code.djangoproject.com/wiki/Reports) contient des liens vers de nombreuses requêtes Trac utiles, y compris certaines orientées sur le triage des tickets et la relecture de correctifs comme suggéré ci-dessus.

## Lignes de conduite

En tant que nouveau venu dans un vaste projet, on peut facilement ressentir de la frustration. Voici quelques conseils pour que votre contribution à Django soit la plus utile et gratifiante possible.

- **Choisissez un thème qui vous tient à cœur, qui vous est familier ou sur lequel vous souhaitez en apprendre davantage**

  Vous n’avez pas besoin d’être déjà un expert du domaine sur lequel vous souhaitez travailler ; on le devient progressivement au fil des contributions de code.
- **Analysez le contexte et l’historique des tickets**

  Trac isn’t an absolute; the context is just as important as the words.
  When reading Trac, you need to take into account who says things, and when
  they were said. Support for an idea two years ago doesn’t necessarily mean
  that the idea will still have support. You also need to pay attention to who
  *hasn’t* spoken – for example, if an experienced contributor hasn’t been
  recently involved in a discussion, then a ticket may not have the support
  required to get into Django.
- **Commencez petit**

  Il est plus facile de recevoir des retours sur de petits problèmes que sur des sujets plus vastes. Voir les tickets marqués comme [easy pickings](https://code.djangoproject.com/query?status=!closed&easy=1) (résolution facile).
- **If you’re going to engage in a big task, make sure that your idea has
  support first**

  This means getting someone else to confirm that a bug is real before you fix
  the issue, and ensuring that there’s consensus on a proposed feature before
  you go implementing it.
- **Be bold! Leave feedback!**

  Sometimes it can be scary to put your opinion out to the world and say « this
  ticket is correct » or « this patch needs work », but it’s the only way the
  project moves forward. The contributions of the broad Django community
  ultimately have a much greater impact than that of any one person. We can’t
  do it without **you**!
- **Err on the side of caution when marking things Ready For Check-in**

  If you’re really not certain if a ticket is ready, don’t mark it as
  such. Leave a comment instead, letting others know your thoughts.  If you’re
  mostly certain, but not completely certain, you might also try asking on IRC
  to see if someone else can confirm your suspicions.
- **Wait for feedback, and respond to feedback that you receive**

  Focus on one or two tickets, see them through from start to finish, and
  repeat. The shotgun approach of taking on lots of tickets and letting some
  fall by the wayside ends up doing more harm than good.
- **Soyez rigoureux**

  When we say « [**PEP 8**](https://peps.python.org/pep-0008/), and must have docs and tests », we mean it. If a patch
  doesn’t have docs and tests, there had better be a good reason. Arguments
  like « I couldn’t find any existing tests of this feature » don’t carry much
  weight–while it may be true, that means you have the extra-important job of
  writing the very first tests for that feature, not that you get a pass from
  writing tests altogether.

## FAQ

1. **Ce ticket qui me tient à cœur a été ignoré depuis des jours/semaines/mois ! Que puis-je faire pour qu’il reçoive de l’attention ?**

   Premièrement, il n’y a rien de personnel. Django est entièrement développé par des volontaires (à l’exception du compagnon Django) et il se trouve que le temps manque parfois. La meilleure chose à faire est d’envoyer un rappel poli à la liste de diffusion [django-developers](/fr/2.1/internals/mailing-lists/#django-developers-mailing-list) en demandant une analyse du ticket ou en parler sur le canal IRC #django-dev.
2. **Je suis certain que mon ticket est absolument parfait à 100%, puis-je le marquer moi-même comme RFC (prêt pour le commit) ?**

   Réponse courte : non. Il est toujours préférable qu’une autre paire d’yeux examine un ticket. Si vous peinez à obtenir cette deuxième paire d’yeux, relisez la question 1 ci-dessus.