ChatGPT – Bonnes pratiques pour le développement web

Un livrable exploitable = **tout ce qu’il faut** pour coller-exécuter : imports, chemins de fichiers exacts, commandes, et tests.

✅ Check-list livrable “copier/coller”

• Noms & chemins exacts (ex : blog/models.py).
• Imports complets et versions compatibles.
• Code par fichier (sections séparées) et/ou diff unifié si modif.
• Commandes à exécuter (manage.py, npm, migrations).
• Tests (succès/erreur/edge) pour prouver le résultat.

🧱 Patron “bloc par fichier”

FICHIER: blog/models.py
<code complet>

FICHIER: blog/admin.py
<code complet>

FICHIER: blog/views.py
<code complet>

COMMANDES:
python manage.py makemigrations
python manage.py migrate
pytest -q

🧪 Demander un **diff** (modification ciblée)

--- a/blog/views.py
+++ b/blog/views.py
@@ -10,6 +10,11 @@
+class ArticleListView(ListView):
+    model = Article
+    paginate_by = 10
+    template_name = "blog/article_list.html"

📦 Exemples par stack

• Django : modèle + admin + CBV + url + template + tests pytest.
• Flask : blueprint, routes, schema pydantic/marshmallow, tests.
• React : composant contrôlé, props typées, exemple d’usage, test RTL.

On **ne pousse pas en prod** sans contrôle. Même un bon bloc “copier/coller” doit passer une **gate technique** minimale.

🧪 Gate technique — Django

python -m py_compile $(git ls-files "*.py")          # compilation bytecode
ruff check && ruff format --check                    # lint/format (ou flake8/black)
python manage.py check                               # checks Django
python manage.py makemigrations --check              # détecte modèles en delta
python manage.py migrate --plan                      # plan de migration OK ?
pytest -q                                            # tests passent
grep -R "ArticleListView" blog/                      # symbole réellement défini

🧪 Gate technique — React

npm run typecheck               # TS types OK (si TS)
npm run lint && npm run build   # lint + build
npm run test -s                 # tests passent
grep -R "<ContactForm" src/    # composant bien utilisé

📋 Demander au modèle la **preuve** (avant/après)

"Donne les commandes de vérification (Django/React) et 
explique ce qui doit s’afficher si tout est correct."

🧯 Pièges

• Imports manquants, conflits de versions.
• Fichiers non autorisés modifiés par erreur.
• Tests absents → pas de preuve rapide.

Le découpage évite les **effets de bord** et rend chaque étape **vérifiable**. On préfère la **valeur livrable** par petites tranches.

🪚 Découpes courantes (Django)

• Étape 1 : modèle + admin + migration (+ test modèle simple).
• Étape 2 : vue (CBV) + URL + template minimal (+ test liste/detail).
• Étape 3 : formulaires (Create/Update) + validations + tests.
• Étape 4 : JS/CSS front, seulement après back validé.

🧭 Patron “Plan 3–5 étapes”

"Propose un plan 3–5 étapes pour <objectif>.
Attends mon OK, puis donne uniquement l’étape 1 (≤ 60 lignes)."

📌 Exemple mini-plan (Blog)

1) Modèle Article + admin + migration (+ test modèle)
2) ListView + URL + template minimal (+ test liste)
3) CreateView + Form + tests (ok/erreur/permission)

🧯 Anti-patterns

• Faire “modèles + vues + templates + tests” d’un coup.
• Changer de stack au milieu (Django 4.2 → 5.x) sans raison.
• Mélanger UX/JS lourds avant d’avoir la base back valide.

Chaque étape doit avoir une Definition of Done et une preuve (tests/commandes/screens). On n’avance pas sans validation.

✅ Definition of Done (gabarit)

DoD :
- Code linté (PEP8) + imports OK
- Tests : 1 succès + 1 erreur + 1 edge
- Commandes d’exécution fournies et passantes
- Diff minimal si modif + commentaire de tête

🧪 Demande de “self-check” au modèle

"Avant de livrer, rappelle contraintes, risques, contrôles/tests à exécuter.
Propose 1 alternative et justifie le choix."

📎 Exemple test (Django)

def test_article_list_view(client, django_db_setup):
    resp = client.get("/blog/")
    assert resp.status_code == 200
    assert b"<h1>Articles</h1>" in resp.content

🧯 Pièges

• Valider “à l’œil” sans test ni commande.
• Laisser passer des warnings critiques.
• Accepter des chemins/noms imprécis.

Demande de la pensée critique, des alternatives, et des preuves. Le but n’est pas de “copier”, mais d’itérer vite et bien.

🧠 Rôles utiles à donner

• Code reviewer : “fais une revue stricte (PEP8, sécurité, perfs). Diff & suggestions.”
• Architecte : “propose 2 architectures, compare trade-offs, choisis & justifie.”
• Test engineer : “écris tests (ok/erreur/edge) + comment les exécuter.”

🧪 Prompts de critique

"Donne 3 risques/alternatives pour <solution>.
Évalue complexité, maintenabilité, coût.
Propose la meilleure option pour notre contexte."

📌 Preuves demandées

• Commandes exécutables (pytest, manage.py, npm).
• Chemins/symboles vérifiables (grep / tree).
• Captures ou sortie console attendue.

🧯 Anti-patterns

• Accepter une solution sans tests ni preuves.
• Laisser le modèle modifier des fichiers non autorisés.
• Réponses trop “génériques” → faire un **reset** (page 3).