Leçons outils6 min de lecture

Projets ChatGPT : gardez les critères de révision visibles

Placez les critères stables dans les instructions du projet, les preuves actuelles dans ses sources et chaque demande ponctuelle dans un nouveau chat.

Bokili EditorialPublié le 19 octobre 2026· Vérifié le 19 octobre 2026

Trois niveaux séparent le standard de validation stable, les sources du projet et la demande ponctuelle.

Un Projet ChatGPT récurrent peut faire gagner du temps de configuration, mais la persistance crée un nouveau problème : les instructions, le matériel de référence et la demande du jour peuvent se fondre en un long contexte. Dans ce cas, un bon résultat peut dépendre d'un ancien fichier, d'une hypothèse cachée ou d'une règle de qualité introuvable.

Utilisez plutôt trois niveaux visibles. Mettez les critères de révision stables dans les instructions du projet. Conservez les preuves actuelles dans les sources du projet. Placez la tâche pour cette exécution dans un nouveau chat. La structure est simple, mais elle répond à une question de maintenance cruciale : si quelque chose change, quelle couche devez-vous modifier ?

Pourquoi les critères de révision doivent être dans leur propre couche

Les directives actuelles d'OpenAI sur les Projets indiquent qu'un projet peut regrouper les chats, les fichiers et les instructions pour un travail continu. Les fichiers fournissent du matériel de référence ; les instructions du projet s'appliquent à l'intérieur de ce projet et remplacent les instructions personnalisées globales. Cela rend les Projets utiles pour le travail récurrent, mais le produit ne décide pas quelles informations doivent rester stables.

Le contenu le plus durable est généralement la règle d'acceptation du travail. Une norme de révision peut exiger que chaque affirmation matérielle renvoie à une source, que chaque incertitude soit étiquetée et que chaque décision reste avec une personne nommée. Ces règles doivent survivre à un nouveau dossier de preuves et à une nouvelle demande hebdomadaire. Si elles ne se trouvent que dans l'invite de la semaine dernière, elles sont faciles à perdre.

Le projet Norme-Sources-Demande

Norme

Mettez les critères d'acceptation stables, les limites, le ton et les droits de décision humaine dans les instructions du projet. Ne modifiez cette couche que lorsque la norme de travail change.

Sources

Ajoutez le pack de référence actuel approuvé comme sources du projet. Supprimez ou remplacez le matériel lorsque les faits, la politique, la propriété ou la validité changent.

Demande

Lancez un nouveau chat pour l'audience, la date limite, la portée et le résultat d'aujourd'hui. Gardez les détails ponctuels hors des instructions stables.

Décidez de ce qui va où avant de télécharger quoi que ce soit

	À placer ici	À ne pas cacher ici
Critères d’acceptation	Instructions du projet	Ancien chat ou exemple de réponse
Faits et règles actuels	Sources du projet	Instruction permanente copiée il y a plusieurs mois
Public et échéance du jour	Chat en cours	Dossier de sources partagé
Validation et escalade	Instructions visibles et processus humain	Comportement supposé du modèle
Contenu remplacé	Retirer ou archiver hors du dossier actif	Laisser à côté de la version actuelle

La séparation empêche également une forme courante de dette de contexte. Un projet s'agrandit parce que tout ce qui est utile est ajouté, mais peu est retiré. Plus de contexte semble alors être plus de capacité même lorsque l'ensemble de sources actives contient des contradictions. Un petit pack maîtrisé est plus facile à examiner qu'un projet devenu un classeur.

Exemple concret : un rapport hebdomadaire sur les risques fournisseurs

Imaginez qu'un responsable des achats produise un rapport hebdomadaire sur les risques fournisseurs. Le résultat doit tenir sur une page et étayer une décision sur les fournisseurs nécessitant un suivi. Le travail récurrent utilise une exportation de l'état actuel des fournisseurs, la politique de risque approuvée et les notes des cas ouverts.

Lire, c'est bien. Pratiquer, ça change tout.

Commencer

Les instructions du projet contiennent la norme de révision stable : séparer les faits de l'interprétation ; citer le document source et la date pour chaque signal d'alarme ; marquer les preuves manquantes ; ne jamais recommander de suspension automatique ; acheminer un cas à haut risque au propriétaire des achats désigné. Ces règles décrivent comment le résultat sera jugé, et non ce qui s'est passé cette semaine.

Les sources du projet contiennent la dernière exportation d'état, la politique actuelle et les notes de cas approuvées. Si la politique de risque change, remplacez la source de la politique et enregistrez la date d'entrée en vigueur. Si le test d'acceptation change — par exemple, chaque avertissement nécessite désormais une vérification de contre-preuve — modifiez les instructions du projet. Si le responsable ne veut qu'un rapport pour la France d'ici jeudi, mettez cela dans le nouveau chat.

Construire le projet en cinq étapes

1
Rédigez d'abord le test d'acceptation
Listez trois à cinq conditions qu'un réviseur vérifiera avant que le résultat puisse être utilisé. Incluez les preuves, l'incertitude et la propriété de la décision.
2
Transformez le test en instructions de projet
Utilisez un langage clair et observable. Indiquez ce que le brouillon doit contenir, ce qu'il ne doit pas décider et quand il doit être escaladé.
3
Créez le pack de sources actives
Ajoutez uniquement du matériel approuvé et actuel. Donnez à chaque source un propriétaire ou un indice de validité afin que les fichiers obsolètes puissent être supprimés.
4
Ouvrez un nouveau chat pour la demande
Indiquez la tâche, l'audience, la période et la forme du résultat. Référez-vous à la norme du projet plutôt que de la copier dans chaque invite.
5
Révision par couche
Lorsque le résultat est faible, demandez si la norme, le pack source ou la demande est incomplet. Modifiez uniquement la couche qui a causé le problème.

Utilisez trois déclencheurs de changement différents

Un projet reste fiable uniquement lorsque chaque couche a un déclencheur clair. Révisez la norme lorsque la décision commerciale, la tolérance au risque ou la voie d'approbation change. Révisez les sources lorsqu'un fichier expire, une politique est remplacée ou une nouvelle période de données commence. Démarrez une nouvelle demande chaque fois que l'audience, la portée ou le livrable change.

Ne considérez pas la mémoire du projet comme une preuve. Les conversations précédentes peuvent servir de contexte utile, mais une affirmation critique doit toujours reposer sur une source actuelle identifiable. De même, un résultat soigné ne prouve pas que le pack source est complet. Le réviseur doit pouvoir identifier la couche ayant fourni la règle, la preuve et la tâche immédiate.

Connecter le projet au flux de travail global

Un projet contient du contexte ; il ne remplace pas tout le processus de travail. L’exercice en contexte vierge vérifie qu’une méthode fonctionne sans soutien caché : https://bokili.com/fr/learn/formation-chatgpt-entreprise-contexte-vierge. La séparation entre brouillons et documents officiels protège la trace de référence : https://bokili.com/fr/learn/formation-ia-salaries-brouillons-documents-officiels. Un signalement reproductible aide ensuite l’équipe à corriger un échec : https://bokili.com/fr/learn/signaler-defaillance-ia-reproductible.

Les missions courtes et spécifiques aux outils de Bokili aident les employés à pratiquer ces choix sur des tâches réalistes. L'objectif n'est pas de mémoriser l'emplacement d'un paramètre, mais de développer une habitude reproductible pour le contexte, les sources et la révision.

Mettre en place un projet à trois niveaux

Choisissez une tâche récurrente et rédigez trois critères d’acceptation observables.
Placez ces critères, une condition d’arrêt et une décision humaine dans un brouillon d’instructions de projet.
Listez le plus petit dossier de sources actuelles nécessaire à la tâche.
Rédigez une nouvelle demande contenant uniquement le public, le périmètre et le format du jour.
Nommez le déclencheur de modification de chaque niveau et la personne responsable.
Retirez une ancienne instruction ou source qui n’a plus sa place.

Maintenir la stabilité de la norme, sans la rendre invisible

Les projets ChatGPT sont précieux car ils regroupent un contexte utile. Une bonne conception de projet sépare également les différents types de contexte. Donnez à la norme de révision un emplacement stable, maintenez les preuves à jour et explicitez chaque demande. Une tâche récurrente devient alors plus facile à maintenir, à transférer et à fiabiliser.