Guide technique
Comment utiliser GPT-6 : cinq tâches concrètes et modèles de prompts

Pour bien débuter avec GPT-6 Astra, donnez-lui un résultat précis à livrer, les éléments nécessaires et une définition claire de la réussite. Choisissez une tâche que vous maîtrisez assez pour la contrôler : note de recherche, révision de rapport, vérification de tableur, QA d'un site ou enquête sur un bug difficile.
Astra mérite un essai lorsque plusieurs sources ou étapes sont liées. Commencez par un travail modeste avant un grand projet. Notre analyse de GPT-6 explique l'accès et les points forts généraux ; ce guide se concentre sur les demandes à formuler une fois l'accès obtenu.
Sources: guide d'accès OpenAI; exemples d'accès anticipé de Claire Vo. Consultées le 7 septembre 2026. Les résultats et expériences sont attribués à leurs auteurs dans le texte.
Partir du livrable
Une demande comme « faites une recherche sur nos concurrents » laisse trop de décisions ouvertes. Un bon brief précise la décision, le public, les sources autorisées, le format final et les critères de révision. Il laisse au modèle de la latitude pour enquêter tout en gardant le résultat identifiable.
Préparez une note de décision de deux pages pour [public].
La décision à prendre est [question précise].
Utilisez [fichiers joints et sources publiques autorisées].
Comparez [options] selon [critères].
Reliez les faits à leurs sources et signalez les informations manquantes.
Terminez par une recommandation, ses compromis et l'action suivante.Choisissez l'interface qui fournit les outils nécessaires. Un modèle dans une conversation ne peut pas inspecter une application locale si l'environnement ne lui donne pas cet accès. Le guide de disponibilité distingue Chat, Work et Codex ; les commandes disponibles dépendent du produit et de l'abonnement.
Cinq premières tâches utiles
| Tâche | Éléments à fournir | Points à contrôler |
|---|---|---|
| Note de recherche | Décision, sources et période | Les affirmations correspondent aux preuves citées |
| Révision d'un rapport | Brouillon, références et public | Les changements préservent les faits |
| Contrôle d'un tableur | Classeur et définitions attendues | Formules, unités et totaux concordent |
| QA d'un site | Aperçu local et parcours clés | Les problèmes signalés sont reproductibles |
| Recherche de bug | Reproduction, journaux et code | La cause proposée explique les symptômes |
Transformer des sources en note de recherche
Demandez à Astra de comparer les preuves avant de rédiger. Une liste de faits n'est utile que si elle éclaire la décision. Faites d'abord ressortir désaccords, dates absentes et hypothèses.
Lisez ces sources et dressez un tableau des affirmations et de leurs preuves.
Repérez les divergences susceptibles de changer notre décision.
Rédigez ensuite une note comparant les deux options.
N'appuyez pas la recommandation sur une affirmation incertaine sans l'expliquer.Ouvrez vous-même plusieurs citations, surtout celles qui justifient la recommandation. Un texte bien écrit peut mal comprendre une source. Pour une méthode reproductible, vérifiez les faits produits par une IA.
Réviser un rapport sans en changer le sens
Fournissez le brouillon et désignez le lecteur visé. Séparez corrections factuelles et ajustements de style pour pouvoir les accepter indépendamment. Si une phrase n'est pas étayée, demandez un commentaire plutôt qu'un remplacement inventé.
Vérifier un tableur avant de le présenter
Précisez les feuilles et résultats importants. Demandez les incohérences de formules, doublons, valeurs manquantes et unités incompatibles. Vérifiez ensuite un échantillon avec les données originales. Le classeur nettoyé doit conserver les données brutes et expliquer les modifications.
Utiliser le navigateur pour la QA
L'épisode de Claire Vo cite la QA dans le navigateur parmi les usages concrets. Une adaptation utile consiste à donner trois parcours essentiels et à demander des constats reproductibles : état initial, actions, résultat attendu, résultat observé et preuve. Revérifiez manuellement les défauts les plus importants.
Enquêter sur un bug difficile
Demandez de reproduire le problème avant de modifier le code. Une bonne enquête livre le chemin défaillant, les preuves de la cause et la plus petite modification proposée. Notre évaluation de GPT-6 pour le code explique pourquoi la couverture des tests et le comportement réel doivent être examinés séparément.
Choisir le bon environnement de travail
Avant un brief détaillé, vérifiez ce que la session peut réellement atteindre. Peut-elle lire le classeur, ouvrir l'aperçu, rechercher sur le web et créer le fichier attendu ? Demandez d'identifier rapidement les entrées manquantes. Même un modèle puissant ne compense pas une source inaccessible ni un outil renvoyant une capture d'écran quand des données modifiables sont nécessaires.
Pour le navigateur, indiquez la page de départ et le compte ou espace à utiliser. Pour les fichiers, désignez ceux qui font référence et dites si une nouvelle version remplace l'ancienne. Pour la recherche, précisez période et marché. Ces détails évitent une réponse soignée à la mauvaise question.
Dans son guide GPT-6, OpenAI note que le modèle peut poser plus de questions et utiliser plus de mise en forme que prévu. Dites quelles décisions courantes il peut prendre et à quoi doit ressembler le résultat. C'est particulièrement utile si vous souhaitez un brouillon achevé, plutôt qu'une discussion sur les approches possibles.
Faites des choix raisonnables d'organisation et de formulation.
Demandez avant de modifier le public, le périmètre ou les hypothèses de fond.
Si un détail manque, poursuivez les parties indépendantes.
Utilisez des paragraphes courts et un tableau comparatif dans la note finale.Exemple complet : préparer le choix d'un fournisseur
Imaginez devoir choisir entre deux fournisseurs de logiciels. Vous disposez d'offres, d'une liste de besoins internes, de notes de réunion et d'un tableur d'usage prévisionnel. Cet exemple est adaptable : plusieurs sources doivent concorder pour que la recommandation soit utile.
Étape 1 : fixer les règles de comparaison
Définissez les critères avant de demander un gagnant. L'effort de mise en œuvre peut, par exemple, peser davantage qu'un petit écart de licence. Distinguez exigences impératives et préférences. Une fonction obligatoire absente ne doit pas être noyée dans une note moyenne.
Comparez les offres A et B à la liste des exigences.
Séparez les obligations des préférences.
Utilisez le tableur d'usage pour le scénario de coût.
Ne déduisez pas une fonction d'un discours marketing général.
Listez les questions ouvertes avant de recommander un fournisseur.Étape 2 : examiner le tableau de preuves
Demandez une ligne par exigence, avec document et section à l'appui. Distinguez confirmé, contredit et non trouvé. « Non trouvé » est utile : cela formule une question précise pour le fournisseur et empêche le modèle de combler le manque par une supposition.
Contrôlez en priorité les lignes qui pourraient changer le choix. Une nuance de formulation mérite rarement autant d'attention qu'une intégration mal définie, un service exclu ou une hypothèse tarifaire.
Étape 3 : produire la note et les questions de suivi
Après validation du tableau, demandez recommandation, alternatives et conditions qui modifieraient le choix. Placez les questions aux fournisseurs dans une section distincte, directement exploitable par un collègue.
Le livrable doit expliquer le choix à une personne qui n'a pas lu les sources, tout en lui permettant de retrouver facilement les preuves décisives.
Trois prompts supplémentaires pour le quotidien
Révision de rapport
Révisez ce rapport pour un directeur des opérations.
Conservez les chiffres, dates et hypothèses déclarées.
Réduisez les répétitions et rendez la recommandation plus facile à trouver.
Renvoyez le brouillon révisé et une courte liste de points factuels à résoudre.
Ne remplacez pas silencieusement une affirmation non étayée par une autre.Examinez les points signalés avant de partager le texte. Si les sources se contredisent, corrigez les documents de référence aussi bien que la rédaction. Sinon, la même incohérence réapparaîtra dans le prochain rapport.
Analyse de tableur
Vérifiez ce classeur avant ma synthèse pour la direction.
Repérez formules et unités incohérentes, valeurs absentes et doublons.
Pour chaque point, indiquez feuille, cellule ou ligne et conséquence probable.
Gardez les données originales intactes. Proposez les corrections séparément.
Ne résumez que les résultats liés à des calculs vérifiés.Demandez le calcul derrière le chiffre principal. Distinguez cellules vides et zéros, réalisé et prévisionnel. Une formule exacte peut soutenir une conclusion erronée si les entrées utilisent des périodes ou monnaies différentes.
QA de site
Testez ces parcours dans l'aperçu : [trois parcours].
Utilisez les données de test fournies.
Consignez état initial, actions, résultat attendu et résultat obtenu.
Traitez les blocages avant les défauts visuels.
Renvoyez des constats reproductibles et indiquez ce qui n'a pas pu être testé.Examinez les états vides, de chargement et d'erreur, pas seulement le succès. Si un formulaire semble envoyé, vérifiez l'enregistrement ou la confirmation. Le changement du libellé d'un bouton ne prouve pas que l'opération a réussi.
Améliorer un premier résultat décevant
Si le résultat est trop général, ajoutez la décision qu'il doit éclairer. S'il est trop long, précisez lecteur et longueur. S'il ignore une contrainte, nommez-la et demandez de chercher le même défaut ailleurs. Ces corrections aident davantage que « faites plus d'efforts ».
Conservez ce qui fonctionne lors d'une révision. Par exemple : « Gardez le tableau de preuves et modifiez seulement la recommandation, car le délai de mise en œuvre devient prioritaire. » Vous éviterez de perdre une bonne correspondance entre faits et sources lors d'une réécriture complète.
Pour un projet qui s'arrête ou perd sa direction, utilisez les exemples de jalons et de reprise du guide des tâches longues avec GPT-6. Un contexte plus grand ne dispense pas d'un objectif actuel clair.

NIGHTSHIFT, créé avec GPT-6 sous direction humaine et par itérations, présenté par CodeRabbit.
Garder la première exécution maîtrisable
Fixez un budget de temps ou d'effort et demandez un résultat partiel utile si la tâche ne peut finir. Une recherche peut rendre constats vérifiés et questions ouvertes. Une tâche de code peut fournir une reproduction et une correction proposée. Une révision de rapport peut préciser les sections contrôlées et celles qui restent.
Ne jugez pas seulement la dernière réponse. Ouvrez la sortie, examinez les parties difficiles et comptez les corrections nécessaires. Ce qui compte est le travail restant avant de pouvoir utiliser le résultat.
Un cadre de révision réutilisable
- Vérifiez que le livrable demandé existe.
- Contrôlez les faits ou comportements essentiels.
- Identifiez les hypothèses insuffisamment étayées.
- Comparez le temps de révision à votre méthode habituelle.
- Gardez le brief réussi pour une tâche similaire.
Rassemblez sources, brief et notes de révision dans Ottermind pour préparer un projet de recherche ou de documents cohérent. Partez du résultat attendu et choisissez un modèle disponible adapté à la tâche.
Questions fréquentes
Quelle tâche essayer en premier avec GPT-6 ?
Choisissez plusieurs entrées et un résultat vérifiable, comme une note sourcée ou une QA délimitée.
Faut-il un long prompt ?
Il faut un brief clair : objectif, matériaux, contraintes, sortie et critères d'acceptation. La longueur seule n'aide pas.
Faut-il activer le raisonnement maximal ?
Commencez par le réglage normal ou modéré proposé. Augmentez l'effort si les cas difficiles en bénéficient.
Puis-je réutiliser le même brief ?
Oui. Gardez sa structure, actualisez sources, dates et critères, et retirez les hypothèses de l'ancien projet.
Comment savoir si la tâche est terminée ?
Vérifiez le résultat concret selon le brief. Une déclaration de réussite assurée ne suffit pas.
