ChatGPT – Limites & Défis (et comment les contourner)

Les limites techniques viennent surtout de la généralisation du modèle : il peut “sembler juste” mais produire une API inexistante, une signature fausse ou une info périmée.

🧷 Hallucinations — Parades

• Ancrage : demande des preuves (chemins de fichiers, signatures exactes, grep), ou base-toi sur un **RAG** (docs internes indexées) pour éviter l’invention.
• Format contraint : impose “bloc par fichier”, ou **JSON** validable côté back.
• Self-check : avant le code, exige 3 risques/alternatives + étapes de vérif.

🧪 Code cassé — Parades

# Gate Django (exemple)
python -m py_compile $(git ls-files "*.py")
ruff check && ruff format --check
python manage.py check
pytest -q
# Stratégies :
# - Température 0–0.3 pour le code
# - Imports complets, versions fixées (requirements.txt/pip-compile)
# - Demander un 'diff' si modification ciblée

📅 Données obsolètes — Parades

• Retrieval : injecter les docs/versions à jour (RAG) plutôt que d’espérer la mémoire du modèle.
• Vérification : demander explicitement la mention de versions et le “pourquoi” du choix.
• Revue humaine : merge seulement après validation (tests/CI + reviewer).

🧱 Prompt “anti-hallucinations”

"Avant de donner du code :
- Cite le chemin exact des fichiers que tu modifies/ajoutes.
- Rappelle la version de la lib utilisée et la signature de l’API.
- Donne la commande grep qui prouvera que le symbole existe."

Sur la durée, le contexte “dérive”. Le modèle oublie le début, mélange les décisions, et propose des détours. Il faut instaurer des rituels simples.

📦 State Pack systématique

PROJET : <nom> — Stack & versions
OBJECTIF ACTUEL : <une seule phrase>
CONTRAINTES : fichiers autorisés, format de sortie, bornes
DERNIÈRE ÉTAPE VALIDÉE : <…>
PROCHAINE ÉTAPE DEMANDÉE : <une seule>

🧭 Découpage & resets

• Une issue = une conversation (un objectif cohérent).
• Soft reset : nouveau State Pack dans le même fil si la réponse dérive.
• Hard reset : nouveau fil avec la décision finale + State Pack.

📑 Traçabilité produit

• ADR (Architecture Decision Record) : 1 fiche par décision clé (choix A vs B, raison, date).
• PR template : checklist (DoD, tests, risques).
• Changelog orienté “user impact”.

🧱 Prompt “cadre d’itération”

"Propose un plan 3–5 étapes pour <objectif>.
Attends mon OK, puis donne UNIQUEMENT l’étape 1 (≤ 60 lignes).
Bloc par fichier, chemins exacts, tests. Si + long ➜ STOP et propose un split."

Trois familles de risques : propriété intellectuelle, données personnelles, dépendance fournisseur. On réduit l’exposition par la minimisation, la traçabilité et des garde-fous techniques.

© Copyright / licences

• Éviter d’intégrer tel quel du code “généré” s’il ressemble à une œuvre tierce identifiée.
• Garder une traçabilité : prompts, sources utilisées, décisions (ADR).
• Respecter les licences (GPL/BSD/MIT) et obligations (headers, notices, attributions).

🔒 RGPD / confidentialité

• Minimisation : ne pas coller de PII/secrets dans les prompts. Masquer/obfusquer si besoin.
• Journalisation : logs anonymisés, durée de rétention limitée, chiffrement en transit/au repos.
• DPIA / Registre : documenter les traitements ; DPA avec le fournisseur ; vérifier localisation des données.

🔗 Dépendance APIs (vendor lock-in)

• Abstraction : couche service (adapter) pour changer de modèle si nécessaire.
• Fallback : timeout, circuit-breaker, cache, retries backoff.
• Coûts : métriques par feature (tokens, latence, erreurs) + alertes.

🧱 Prompt “sécurité & conformité”

"Avant de répondre :
- Indique si des données perso ou secrets sont nécessaires (sinon, propose des placeholders).
- Donne les risques de licence éventuels.
- Propose un masque/anonymisation et des contrôles (logs, rétention)."

L’IA **assiste**, elle ne remplace pas la relecture pro. En prod, on applique les mêmes standards (revue, tests, CI/CD, sécurité).

👀 Revue humaine (checklist)

• Conformité PEP8/linters & imports ; noms/chemins corrects.
• Tests présents et pertinents (succès/erreur/edge).
• Pas de secrets/PII dans le code ou les prompts ; logs sobres.
• Docs courtes + commentaires de tête si logique non triviale.

🛡️ Sécurité (patterns)

• Prompt-injection (si RAG) : filtrage/sanitation du contexte, allow-list d’outils, pas d’instructions non fiables.
• Least privilege : tokens/clefs scope minimal, jamais commit.
• Time-box : timeouts, retries, quotas, observation.
• Isolation : exécution de code en sandbox (jamais en prod direct).

⚙️ CI/CD minimal

# Job CI (exemple) :
- lint & format (ruff/black, eslint)
- tests (pytest / vitest-rtl)
- build (Django collectstatic, npm build)
- artefacts (coverage, dist)

🧱 Prompt “pair-programmer responsable”

"Agis comme un reviewer strict :
- Liste 3 risques/alternatives, choisis et justifie.
- Donne les commandes pour prouver que ça marche.
- Si des secrets/PII seraient exposés, propose une mitigation."