> For the complete documentation index, see [llms.txt](https://docs.ipcheck.ing/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ipcheck.ing/developer/fr/contributing/reporting-issues.md).
# Signaler des issues
Tous les signalements de bugs et les demandes de fonctionnalités doivent être adressés à [GitHub Issues](https://github.com/jason5ng32/MyIP/issues). Le dépôt fournit deux modèles — un rapport de bug et une demande de fonctionnalité — et choisir le bon fait gagner un aller-retour à tout le monde.
## Avant de soumettre
{% hint style="info" %}
La plupart des rapports concernant des déploiements auto-hébergés s'avèrent être des problèmes de configuration, pas des bugs. Vérifiez d'abord ceux-ci.
{% endhint %}
1. **Rechercher les problèmes existants**, ouverts et fermés. Votre problème a peut-être déjà été signalé, résolu ou corrigé sur `dev`.
2. **Lisez la** [**FAQ**](/developer/fr/reference/faq.md)**.** Elle couvre les problèmes courants de déploiement et de configuration.
3. **Confirmez votre configuration.** MaxMind est requis — voir [Configuration de MaxMind](/developer/fr/getting-started/maxmind-setup.md). Plusieurs fonctionnalités dépendent de clés API facultatives ; voir [Clés API facultatives](/developer/fr/configuration/optional-api-keys.md).
4. **Essayez la dernière version.** Le bug a peut-être déjà disparu.
## Soumettre un rapport de bug
Utilisez le **Rapport de bug** modèle. Il est étiqueté `bug` automatiquement. Le modèle demande les éléments suivants.
### Environnement
* Système d'exploitation
* Navigateur, le cas échéant
* Version de Node
* Version de Vite
* Version de Vue 3
* Version de Docker, le cas échéant
* Méthode de déploiement — Vercel, Docker ou Node
* Variables d'environnement, **avec tous les secrets supprimés**
* Toutes autres versions de logiciels pertinentes
{% hint style="danger" %}
Ne collez jamais de clés API, de jetons ou d'identifiants MaxMind dans un ticket. Masquez-les. Si vous en avez déjà divulgué un, révoquez-le.
{% endhint %}
### Description et étapes de reproduction
Une description claire du bug, suivie d'étapes numérotées pour le reproduire. Les étapes de reproduction sont la partie la plus utile d'un rapport.
### Comportement attendu vs comportement réel
Ce à quoi vous vous attendiez, et ce qui s'est réellement passé. Des captures d'écran ou un court enregistrement d'écran aident pour tout ce qui est visuel.
### Journaux du terminal et de la console
Le modèle le signale comme important, et il a raison. Incluez les deux lorsqu'ils s'appliquent :
* **Journaux du terminal** depuis le backend — messages d'erreur et traces de pile.
* **Journaux de la console du navigateur** pour tout ce qui échoue dans le frontend.
Obtenir davantage de détails du backend
Le backend enregistre via un `pino` logger partagé. Augmentez le niveau pour capturer davantage avant de reproduire :
```bash
LOG_LEVEL=debug pnpm dev
```
Voir [Journalisation](/developer/fr/configuration/logging.md) pour les autres options, notamment `LOG_FORMAT` et `LOG_HTTP`.
### Compléments facultatifs
* **Contexte supplémentaire** — liens vers des tickets liés, et tout autre élément pertinent.
* **Solution possible** — si vous avez déjà une idée du correctif, décrivez-la. Si vous souhaitez l'écrire, dites-le et lisez [Comment contribuer](/developer/fr/contributing/how-to-contribute.md) d'abord.
## Soumettre une demande de fonctionnalité
Utilisez le **Demande de fonctionnalité** modèle. Il est étiqueté `amélioration` automatiquement, et il demande quatre choses :
| Champ | Que rédiger |
| -------------------------------------------------- | ----------------------------------------------------------------- |
| Est-ce lié à un problème ? | La frustration à l'origine de la demande, concrètement |
| Décrivez la solution que vous souhaitez | Ce qui devrait se passer, du point de vue de l'utilisateur |
| Décrivez les alternatives que vous avez envisagées | Autres approches, et pourquoi elles ne suffisent pas |
| Contexte supplémentaire | Captures d'écran, maquettes, liens vers des références existantes |
Expliquez le bénéfice pour l'utilisateur, pas seulement l'implémentation. Une demande qui part d'un problème réel est beaucoup plus facile à évaluer qu'une demande qui part d'une API proposée.
{% hint style="info" %}
Vous prévoyez de développer la fonctionnalité vous-même ? Ouvrez quand même le ticket et attendez qu'un mainteneur confirme l'orientation avant d'écrire du code. Voir [Comment contribuer](/developer/fr/contributing/how-to-contribute.md).
{% endhint %}
## Les problèmes de sécurité sont différents
N'ouvrez pas un rapport de bug normal pour une vulnérabilité. Suivez la [Politique de sécurité](/developer/fr/contributing/security-policy.md) à la place.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.ipcheck.ing/developer/fr/contributing/reporting-issues.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.