Guide complet des prompts Grok 4.7 : 5 scénarios à copier directement

TL;DR : 5 scénarios, tous exécutés réellement avec grok-4.7 dans l'environnement de production HiAPI, sorties retranscrites telles quelles. Coût par requête : 0,007–0,021 $ ; environ 0,06 $ pour les 5. Le lien sous chaque prompt remplit automatiquement le même prompt dans la page du modèle : il suffit d'envoyer pour reproduire. Grok 4.7 est déjà disponible sur HiAPI, ouvrez la page du modèle pour l'essayer directement ; les nouveaux utilisateurs reçoivent 200 crédits à l'inscription.

Scénario 1 : diagnostiquer un blocage en concurrence

La cause racine est que l'objet réponse n'est jamais libéré, si bien que la connexion occupe en permanence un emplacement du pool du connector.

Le ClientResponse renvoyé par session.get() ne rend la connexion au TCPConnector qu'au moment de release() / close() (ou à la sortie du gestionnaire de contexte asynchrone). Le code actuel n'utilise ni async with, ni release() explicite. Lire le body ne restitue pas la connexion ; il existe en outre une référence circulaire entre la réponse et la connexion, qui ne sera libérée qu'au __del__ du GC cyclique.

Par défaut, la limite de connexions par ClientSession est de 100. 20 workers possèdent chacun une session et envoient des requêtes en série, chaque worker traitant environ 250 URL. Quand les connexions ne sont pas restituées :

1. Les connexions occupées sont RST par le serveur (timeout d'inactivité ou limite de connexions), aiohttp émet alors ConnectionResetError au niveau du protocole (pas forcément levée depuis votre await, donc except ne l'intercepte pas et ne nettoie rien).
2. Les emplacements restent occupés. Une fois 100 atteints, le session.get() suivant bloque sur connector.acquire(), et cette attente n'est généralement pas soumise au timeout.
3. Tous les workers se retrouvent bloqués dans acquire, ils ne font plus queue.get() ni task_done(). La boucle d'événements n'alloue plus rien, le GC cyclique ne s'exécute plus, __del__ ne peut pas récupérer les connexions : interblocage. queue.join() n'aboutit jamais non plus.

except Exception: pass ne fait qu'avaler les exceptions dans la coroutine utilisateur, sans libérer la connexion ; « l'erreur » et « le blocage » apparaissent donc ensemble.

Modification minimale :

async def fetch(url, session):
    async with session.get(url) as r:
        return await r.json()

async with passe par __aexit__ → release() sur les deux chemins, retour normal et exception :

• La connexion retourne immédiatement dans le pool, les emplacements ne s'accumulent pas jusqu'à 100, session.get() ne bloque plus définitivement sur acquire, les workers continuent de consommer la file. Cela règle le blocage.
• La connexion n'occupe plus durablement un emplacement en attendant le RST du serveur, et le ConnectionResetError du protocole disparaît aussi ; même si une déconnexion survient pendant la lecture du body, le gestionnaire de contexte restitue ou ferme quand même cette connexion, un échec isolé ne bloque pas le pool. Cela règle l'erreur et garantit que la file continue d'avancer après l'erreur.

Prompt complet :

Le code Python ci-dessous produit aléatoirement des ConnectionResetError lorsque la concurrence augmente un peu, puis tout le worker se bloque et ne consomme plus la file. Trouve la cause racine, propose un correctif minimal et explique pourquoi ton correctif règle à la fois le problème d'« erreur » et celui de « blocage ».

```python
import asyncio, aiohttp

async def fetch(url, session):
    r = await session.get(url)
    return await r.json()

async def worker(queue):
    session = aiohttp.ClientSession()
    while True:
        url = await queue.get()
        try:
            data = await fetch(url, session)
            print(data)
        except Exception:
            pass
        queue.task_done()

async def main():
    queue = asyncio.Queue()
    for i in range(5000):
        queue.put_nowait(f"https://api.example.com/item/{i}")
    workers = [asyncio.create_task(worker(queue)) for _ in range(20)]
    await queue.join()

asyncio.run(main())
```

Générer avec ce prompt →

grok-4.7, niveau de raisonnement high par défaut, max_tokens plafonné à 6000, exécution réelle 107,7 s, entrée 3 572 / sortie 7 301 tokens, environ 0,021 $.

En fournissant d'un coup le symptôme, le code et la contrainte « expliquer les deux problèmes à la fois », le modèle descend jusqu'à la cause racine du pool de connexions au lieu de s'arrêter à un try-catch superficiel.

Scénario 2 : revue de code en JSON

{"issues":[{"severity":"high","line":8,"problem":"La vérification du solde et le débit sont séparés, il existe une course TOCTOU : des requêtes concurrentes peuvent toutes passer la vérification du solde puis débiter plusieurs fois, entraînant un découvert ou une double dépense","fix":"Passer à une mise à jour conditionnelle unique (par exemple $inc seulement si balance>=amount) ou réaliser atomiquement vérification et débit dans une transaction avec verrou de ligne/verrou optimiste"},{"severity":"high","line":9,"problem":"Le débit et le crédit sont deux écritures indépendantes, sans transaction ; si la première réussit et la seconde échoue, les fonds disparaissent du compte from sans possibilité de rollback","fix":"Placer les deux mises à jour dans la même transaction base de données, tout rollback en cas d'échec, et vérifier l'existence du compte to avant de valider"}

,"summary":"Cette API de transfert manque de transactions atomiques, d'authentification et de validation des entrées ; en concurrence elle provoque une double dépense ou une perte d'argent, et les chemins d'erreur bloquent la requête."}

(Extrait : la sortie originale est un JSON sur une ligne, seuls les deux premiers problèmes high et le summary sont conservés, le reste est omis)

Prompt complet :

Merci de relire le code de route Node.js ci-dessous et d'identifier tous les problèmes susceptibles de provoquer un incident en production (sécurité, concurrence, fuites de ressources incluses), classés par gravité. Utilise strictement une sortie JSON, format : {"issues": [{"severity": "high|medium|low", "line": numéro de ligne, "problem": "problème", "fix": "correctif"}], "summary": "résumé en une phrase"}.

```js
const express = require('express');
const db = require('./db');
const router = express.Router();

router.post('/transfer', async (req, res) => {
  const { from, to, amount } = req.body;
  const fromAccount = await db.findOne({ id: from });
  if (fromAccount.balance >= amount) {
    await db.update({ id: from }, { $inc: { balance: -amount } });
    await db.update({ id: to }, { $inc: { balance: amount } });
    res.json({ ok: true });
  } else {
    res.status(400).json({ ok: false });
  }
});

module.exports = router;
```

Générer avec ce prompt →

grok-4.7, niveau de raisonnement high par défaut, max_tokens plafonné à 4000, exécution réelle 40,1 s, entrée 3 576 / sortie 2 734 tokens, environ 0,010 $.

En écrivant directement dans le prompt le squelette JSON souhaité (noms de champs, règles de tri), grok-4.7 respecte strictement le format et la sortie peut entrer directement dans votre pipeline.

Scénario 3 : comparaison de solutions techniques

Je recommande « heartbeat d'activité + Redis TTL + polling court à la demande », plutôt que WebSocket/SSE pour une diffusion de présence à grande échelle. Le passage au gris après 5 minutes n'exige pas une diffusion à la seconde ; avec 100k DAU, le polling tient largement, et c'est aussi plus adapté à Next.js.

Comparaison des solutions

	Polling	SSE	WebSocket
Direction	Pull côté client	Push unidirectionnel serveur	Bidirectionnel
Adéquation avec « gris après 5 min sans activité »	Élevée. Un rafraîchissement toutes les 30–60 s suffit pour le point vert	Moyenne. Le push est plus rapide, mais le passage au gris par timeout reste à calculer soi-même	Faible à moyenne. Connexion active ≠ utilisateur actif
Compatibilité Next.js	Meilleure. Route Handler classique	Mauvaise. Les connexions longues sont peu adaptées à Serverless/multi-instances	La pire. Nécessite un processus WS dédié, des sessions collantes ou un tiers
Coût des connexions	Aucune connexion longue	1 par utilisateur en ligne	1 par utilisateur en ligne, plus heartbeat de maintien
Scalabilité	Sans état, scale horizontal simple	Gestion des déconnexions, reconnexions, fan-out multi-instances	Idem, en plus lourd
Mode de défaillance	Une requête échoue, la suivante reprend	Après déconnexion l'état cesse d'être mis à jour, rattrapage nécessaire	Idem, passerelle complexe
Vaut-il le coup à 100k DAU	Oui, comme solution par défaut	Seulement si un canal de push existe déjà	Seulement si une passerelle chat/collaboration existe déjà

Estimation brute du pic : 100 000 actifs par jour, 5 %–15 % en ligne simultanément, soit environ 5 000–15 000. Un heartbeat toutes les 45 s représente environ 100–300 écritures/s ; chaque utilisateur récupère toutes les 30 s l'état des utilisateurs visibles, la lecture reste dans la zone de confort de Redis. Le goulot d'étranglement ne sera pas sur le « point vert ».

Recommandation et justifications

Utiliser Redis comme source de vérité de la présence en ligne, PostgreSQL uniquement pour le last_seen froid, et faire en sorte que le client ne pollise que les utilisateurs affichés à l'écran.

1. La sémantique produit est « 5 minutes sans activité », pas « TCP encore connecté ». Une page laissée sans interaction doit passer au gris, donc même avec WS il faut un heartbeat d'activité séparé. La connexion seule ne répond pas au besoin.
2. Le point vert tolère une erreur de quelques dizaines de secondes. Un intervalle de polling de 30–60 s est suffisant par rapport à la fenêtre de 5 minutes.
3. Next.js (surtout Vercel / Serverless) n'est pas adapté aux connexions longues. WS/SSE vous entraîne vers un service temps réel dédié, du routage collant et de la compensation de déconnexion, pour un gain minime.
4. Qui doit voir l'état de qui est généralement local (amis, liste de conversations, avatars de la page courante), pas une diffusion site-wide. Interroger Redis par lots d'id est d'un ordre de grandeur plus simple que maintenir des abonnements.
5. L'expiration naturelle des clés Redis exprime le « hors ligne par timeout », sans dépendre des keyspace notifications ni d'un scan complet de table.

Présence au niveau utilisateur = en ligne (solution principale recommandée) :

```text
presence:u:{userId}   STRING  valeur = unix millisecondes côté serveur
                      TTL = 300 secondes
                      heartbeat avec SET key value EX 300
                      en ligne = clé existante
```

Ne pas utiliser l'heure client. Un TTL légèrement supérieur à 2–3 fois l'intervalle de heartbeat n'est pas nécessaire ; ici heartbeat 45–60 s et TTL 300 s, la perte de deux ou trois heartbeats reste considérée en ligne, conforme à « 5 minutes sans activité ».

(Extrait : conclusion recommandée et 5 premières justifications, solution principale au niveau utilisateur dans la conception des clés Redis)

Prompt complet :

Je veux ajouter une fonctionnalité « statut en ligne en temps réel » à une application web de 100 000 DAU (point vert à côté de l'avatar, gris après 5 minutes sans activité). Stack : Next.js + PostgreSQL + Redis. Donne d'abord une comparaison des solutions (WebSocket / SSE / polling), indique laquelle tu recommandes et pourquoi, puis liste les étapes d'implémentation et la conception des clés Redis. Ne pas écrire le code complet, les extraits clés peuvent être inclus.

Générer avec ce prompt →

grok-4.7, niveau de raisonnement high par défaut, max_tokens plafonné à 6000, exécution réelle 69,8 s, entrée 3 429 / sortie 4 247 tokens, environ 0,014 $.

En limitant d'abord la stack et le volume métier, puis en demandant « comparer d'abord, recommander ensuite », la sortie devient une solution présentable en revue technique, pas une vulgarisation neutre.

Scénario 4 : explication de concept

Commençons par poser le scénario. Supposez que vous traitez une commande : il faut écrire la commande en base de données et aussi déposer un message dans la file de messages pour que le stock, les points et les notifications en aval travaillent. Ces deux actions ne sont pas dans la même « transaction » ; si l'une échoue au milieu, le système présente une fissure « d'un côté ça a réussi, de l'autre ce n'est jamais arrivé ».

Pourquoi écrire d'abord en base puis envoyer le message peut perdre le message

Le commit en base a réussi, la commande est persistée. Juste après, le processus doit envoyer le message, et à ce moment-là il peut :

• avoir un hoquet réseau et ne pas pouvoir envoyer ;
• la file de messages être temporairement indisponible ;
• plus fréquent encore, le processus planter juste après le commit et avant l'envoi (redémarrage machine, OOM, déploiement progressif).

La commande est en base, mais le message n'est jamais parti. L'aval ignore totalement cette commande, le stock n'est pas décrémenté, la notification n'est pas envoyée. Réessayer après coup ne sert à rien : le processus qui a planté n'existe plus ; sauf compensation fiable mise en place par ailleurs, ce message est perdu. Pour quelqu'un qui n'a connu que le monolithique, c'est comme : vous inscrivez d'abord « encaissé » dans le registre, puis vous allez au bureau de poste envoyer la lettre de notification, la lettre se perd en route, mais le registre est déjà modifié : les deux ne concordent plus.

(Extrait : mécanisme de perte de message dans « écrire d'abord en base puis envoyer le message » et métaphore centrale)

Prompt complet :

Avec des mots compréhensibles pour un ingénieur backend ayant 3 ans d'expérience mais n'ayant jamais touché aux systèmes distribués, explique pourquoi « écrire d'abord en base de données puis envoyer dans la file de messages » peut entraîner une perte de message, et pourquoi « envoyer d'abord dans la file puis écrire en base » ne fonctionne pas non plus. Indique les deux approches correctes courantes de l'industrie (table de messages locale / messages transactionnels) et les scénarios auxquels chacune convient.

Générer avec ce prompt →

grok-4.7, niveau de raisonnement high par défaut, max_tokens plafonné à 4000, exécution réelle 41,3 s, entrée 3 410 / sortie 2 478 tokens, environ 0,009 $.

Remplacer « explique bien » par « explique à un profil précis » amène le modèle à choisir le bon niveau de granularité : la métaphore du registre et du bureau de poste vient de là.

Scénario 5 : script d'analyse de données

```python
import pandas as pd
import numpy as np

# Données d'exemple (remplaçables par votre vrai df)
np.random.seed(42)
n = 500
df = pd.DataFrame({
    "order_id": range(1, n + 1),
    "user_id": np.random.randint(1, 80, n),
    "amount": np.round(np.random.uniform(20, 500, n), 2),
    "created_at": pd.date_range("2023-01-01", periods=n, freq="D").astype(str),  # dates simulées en chaîne
    "status": np.random.choice(["paid", "paid", "paid", "cancelled"], n),
})

# ---------- 0. Traitement des dates : chaîne vers datetime ----------
df["created_at"] = pd.to_datetime(df["created_at"], errors="coerce")
df = df.dropna(subset=["created_at", "amount", "user_id"])

# Optionnel : ne compter que les commandes valides (adapter status au métier réel)
df_valid = df[df["status"] == "paid"].copy()

# ---------- 1. GMV et nombre de commandes par mois ----------
df_valid["month"] = df_valid["created_at"].dt.to_period("M")
monthly = (
    df_valid.groupby("month", as_index=False)
    .agg(GMV=("amount", "sum"), order_count=("order_id", "count"))
    .sort_values("month")
)
monthly["month"] = monthly["month"].astype(str)
print("=== GMV et nombre de commandes par mois ===")
print(monthly)
```

(Extrait : première moitié du code (traitement des dates + GMV mensuel), la seconde moitié avec le classement utilisateurs et la tendance de la première commande est omise)

Prompt complet :

J'analyse avec pandas un jeu de données de commandes e-commerce ; le dataframe df contient les colonnes : order_id, user_id, amount, created_at, status. Donne-moi un code Python complet et exécutable qui calcule : 1) le GMV et le nombre de commandes par mois ; 2) le classement des utilisateurs par dépense cumulée (seulement le top 20) ; 3) la tendance mensuelle du montant moyen de la première commande des nouveaux utilisateurs. Exige de gérer le cas où created_at est une chaîne, et commente les étapes clés.

Générer avec ce prompt →

grok-4.7, niveau de raisonnement high par défaut, max_tokens plafonné à 5000, exécution réelle 18,5 s, entrée 3 440 / sortie 1 427 tokens, environ 0,007 $.

En listant une par une les colonnes, les indicateurs à calculer et les cas limites (created_at est une chaîne), le code généré s'exécute directement, sans reprise.

Comment rédiger ses prompts

1. Collez le vrai code, les vrais noms de colonnes ; n'écrivez pas « il y a un bout de code », collez-le directement.
2. Indiquez le format de sortie dans le prompt : pour du JSON, donnez le squelette JSON ; pour du code, dites « complet et exécutable ».
3. Plus les contraintes sont précises, mieux c'est : règles de tri, seulement le top 20, pas de code complet mais seulement les extraits clés.

Questions fréquentes

Ces prompts sont-ils directement utilisables ? Oui. Les 5 sont des prompts originaux que nous avons exécutés sur HiAPI, et les sorties sont les résultats réels. Cliquez sur « Générer avec ce prompt » sous chacun, la page du modèle se préremplit automatiquement ; remplacez par votre propre code ou vos données pour l'utiliser directement.

Quelle est la capacité de grok-4.7 à écrire du code ? xAI le positionne sur le codage et le travail de connaissance ; selon les chiffres officiels, Terminal-Bench 4.0 passe de 20,3 % avec grok-4.6 à 38,0 % (source officielle). La localisation de la cause racine du scénario 1 et la liste de revue du scénario 2 sont des résultats que nous avons obtenus en exécution réelle, à vous de juger.

Combien coûte environ un appel ? Au tarif de la plateforme HiAPI (entrée 0,84 $ / sortie 2,52 $ par 1M tokens), ces 5 prompts coûtent environ 0,06 $ au total. Le moins cher, le scénario 5, coûte environ 0,007 $ ; le plus cher, le scénario 1, environ 0,021 $.

À quoi sert le contexte de 500K ? Vous pouvez coller les fichiers d'un dépôt de taille moyenne ou des centaines de pages de logs dans une seule requête pour une revue, un dépannage ou une refonte, sans découpage manuel. Les prompts courts du quotidien ne le remplissent pas et ne coûtent pas plus cher : la facturation se fait sur les tokens réels.

Pour aller plus loin

• Combien coûte l'API Grok 4.7 ? — trois niveaux de raisonnement, tarification des documents longs et matrice de budget mensuel
• Grok 4.7 vs Grok 4.6 — même prix, quand utiliser l'un ou l'autre
• Guide d'intégration de l'API Grok 4.7 — réussir sa première requête en 5 minutes
• Page du modèle Grok 4.6 — utilisation complète du flagship précédent
• Page du modèle Grok 4.7 — essai en ligne, paramètres et tarifs en temps réel