ChatGPT invente : vérifier les sources avant d’envoyer au client

Le premier remède ChatGPT vérification n’est pas un prompt miracle : c’est une règle d’équipe. Aucun fait technique, chiffre marché ou citation externe ne sort sans confirmation hors modèle. Vous formalisez cette règle dans la definition of done, comme un test de non-régression.

Deux remèdes opérationnels suffisent pour démarrer. Exigez des citations URL ou des références doc dans le prompt. Puis faites extraire la liste des claims par un relecteur (humain ou second prompt « liste uniquement les faits vérifiables »). Ce qui n’est pas sourcé reste marqué non vérifié jusqu’à preuve.

Le remède le plus fiable reste l’exécution : code lancé en local ou CI, config testée, API appelée. Une doc inventée ne survit pas à un curl. Pour le SEO et les chiffres, croisez Search Console ou un outil tiers avant de les coller dans un livrable client.

Les effets ChatGPT vérification se mesurent d’abord en risque : une API inventée en recette bloque un sprint ; une obligation légale fictive expose le client ; un volume de trafic inventé fausse une roadmap contenu. Vérifier tôt coûte moins cher que corriger après envoi.

Sur le plan éditorial, la vérification change le ton du livrable. Vous remplacez les formulations assertives sans source par des affirmations datées et tracées : « vérifié le [date] par [rôle] ». Le client lit moins de certitudes creuses, plus de preuves.

Enfin, documenter les incidents (hallucination détectée avant ou après envoi) affine prompts et formations. Chaque effet négatif évité devient un cas dans votre playbook interne, pas une anecdote oubliée.

Étape 1 : prompt exigeant citations URL ou références doc pour chaque affirmation factuelle. Étape 2 : extraction des claims par le relecteur ou un second prompt « liste uniquement les faits vérifiables ».

Étape 3 : recoupement manuel ou via script (fetch HEAD, grep doc locale). Étape 4 : marquage dans le livrable final : vérifié le [date] par [rôle]. Intégrez cette chaîne dans votre definition of done.

Classez aussi les livrables par risque : specs techniques, contenus SEO, juridique/compliance, recommandations stratégiques. Les livrables « zéro hallucination » (contrats, SLA, doc d’API publique) exigent validation expert systématique, pas seulement une relecture orthographique.

Demandez explicitement : « Si incertain, répondez “non vérifié” et proposez une méthode de vérification ». Interdisez les formulations assertives sans source. Pour le code, exécutez toujours en local ou CI.

Pour la doc framework instable, préférez `node_modules/next/dist/docs/` plutôt qu’une réponse mémorisée du modèle. Pour le SEO, croisez Search Console et outils tiers avant toute recommandation chiffrée.

Assignez un propriétaire de la vérification (dev senior, PO ou relecteur métier) selon le type de livrable. Sans propriétaire nommé, la checklist reste décorative.

Relire le style but pas les faits : erreur la plus coûteuse en agence.

Accepter des URLs 404 ou des ancres inventées sans clic.

Déléguer entièrement la spec technique à ChatGPT sans revue dev senior.

Ignorer la date des sources : API dépréciée recommandée comme standard actuel.

Absence de traçabilité : impossible de savoir qui a validé quoi avant envoi client.

ChatGPT accélère la rédaction ; la responsabilité factuelle reste humaine.

Deux sources indépendantes + exécution/test local pour tout élément critique.

Formalisez remèdes, effets et solutions dans le DoD : prompts, extraction, recoupement, archivage.

Documentez les incidents pour affiner prompts et formations internes.