Comment écrire de meilleurs prompts IA pour coder ?

Résumer ce contenu avec :

Perplexity ChatGPT Claude Grok Mistral

Je les écris comme un brief critique, pas comme une commande magique. Les bons prompts IA obligent le modèle à challenger, clarifier, tester et nettoyer. C’est là que ça devient utile pour coder sans empiler du code fragile.

Pourquoi l’IA doit elle vous contredire ?

Je veux que l’IA me contredise parce qu’elle devient vraiment utile quand elle joue le rôle d’un second avis critique, pas quand elle valide poliment mon idée. Si je lui demande juste “écris le code”, elle va souvent le faire. Même si mon besoin est flou. Même si mon architecture ne tient pas. Même si je vais le payer trois jours plus tard.

Le fil conducteur, c’est simple : Je transforme le modèle en partenaire adversarial. Adversarial veut dire “qui challenge”. Pas pour bloquer. Pour améliorer. Je veux une IA sceptique, orientée qualité, qui me dit “là, il manque une règle”, “ce cas limite va casser”, “ce test ne protège rien”.

AI

Comment créer un agent IA local en streaming ?

août 30, 2026

Beaucoup de prompts de développement échouent parce qu’ils demandent du code trop vite. Le modèle produit quelque chose de plausible, propre en apparence, mais il ne sait pas si le besoin est clair, si les tests couvrent les bons risques, ou si le code embarque déjà des restes inutiles. Le bon réflexe, c’est de ralentir au début pour gagner du temps ensuite.

Je vais garder un projet fil rouge : Une API REST de gestion de tâches. REST, ici, c’est une API HTTP organisée autour de ressources, par exemple /tasks. On veut créer une tâche, la modifier, gérer son statut, ajouter une date d’échéance, puis plus tard gérer des tâches récurrentes. Ça paraît simple. Et pourtant, ça cache vite des pièges : Les fuseaux horaires, les règles de répétition, les tâches en retard, les statuts incohérents, les tests oubliés.

Je l’ai souvent vu avec des équipes data, tracking ou automatisation. Elles demandaient à l’IA de générer directement une solution complète. Résultat, elles passaient plus de temps à corriger les angles morts qu’à construire proprement. Ce n’est pas l’IA le problème. C’est le contrat qu’on lui donne au départ.

AI

Comment utiliser LanceDB pour une base vectorielle IA ?

août 30, 2026

Voici le mauvais réflexe :

Code une API REST en Node.js pour gérer des tâches avec création, modification, statut et date d’échéance.

Et voici un prompt beaucoup plus utile :

Joue le rôle d’un reviewer backend senior.
Analyse mon besoin avant d’écrire du code.
Identifie les ambiguïtés, les risques techniques, les cas limites et les tests indispensables.
Pose-moi les questions nécessaires.
Refuse d’écrire le code tant que la spécification n’est pas assez claire.
Le projet est une API REST de gestion de tâches avec création, modification, statut, dates d’échéance, puis plus tard tâches récurrentes.

Comment spécifier avant de coder ?

Avant de demander à l’IA de coder, je lui demande de jouer un architecte principal sceptique, avec une règle simple : interdiction d’écrire du code. Son job, c’est de ralentir juste assez pour sortir une vraie spécification avant l’implémentation.

AI

Comment réussir l'observabilité IA des agents en production ?

août 30, 2026

C’est une technique que j’associe à Maja Bilić. Le modèle ne part pas bille en tête. Il examine le besoin, les risques, le modèle de données, l’expérience développeur, l’expérience produit, puis il pose des questions ciblées. Pas cinquante questions molles. Dix maximum, utiles. Le but, c’est d’éviter deux pièges que je vois souvent chez les clients : sur-engineering, donc une usine à gaz, ou sous-engineering, donc un truc rapide qui explose au premier cas réel.

Sur une API REST de tâches, si on ajoute des tâches récurrentes, le prompt doit forcer les sujets qui fâchent.

• RRULE : C’est le format standard pour décrire une récurrence, par exemple tous les lundis à 9h.
• Fuseaux horaires : Une tâche à 9h doit rester à 9h dans l’heure locale de l’utilisateur.
• Changement d’heure : Il faut décider quoi faire si une occurrence tombe dans une heure inexistante ou doublée.
• Stockage : On stocke la règle, les occurrences générées, ou les deux.
• Modification : On doit distinguer une seule occurrence et toute la série.
• Suppression : Même logique, occurrence isolée ou série complète.
• Idempotence : Regénérer les occurrences ne doit pas créer de doublons.

Tu es un architecte principal sceptique.
Tu n’as pas le droit d’écrire du code.
Commence par les risques techniques et produit.
Pose au maximum 10 questions vraiment utiles.
Ensuite, propose une spécification claire, un modèle de données et un plan d’implémentation.
Le contexte est une API REST simple de gestion de tâches.
La nouvelle fonctionnalité est l’ajout de tâches récurrentes.
Clarifie RRULE, fuseaux horaires, heure locale utilisateur, stockage des règles, génération des occurrences, modification d’une occurrence ou de toute la série, suppression, idempotence, et comportement pendant les changements d’heure.
La solution doit rester simple, sans architecture énorme.

Une sortie attendue pourrait ressembler à ça, sans partir dans une architecture de calendrier Google.

AI

Comment créer un workflow Hermes Agent IA LLM à faible coût?

août 30, 2026

Risques principaux : Mauvaise gestion des fuseaux horaires, doublons d’occurrences, ambiguïté entre série et occurrence, comportement flou pendant les changements d’heure.

Endpoints envisagés : POST /tasks pour créer une tâche simple ou récurrente.

Endpoints envisagés : GET /tasks?from=2026-01-01&to=2026-01-31 pour lister les occurrences visibles.

Endpoints envisagés : PATCH /tasks/{id} pour modifier la série.

Endpoints envisagés : PATCH /task-occurrences/{id} pour modifier une seule occurrence.

Endpoints envisagés : DELETE /tasks/{id} ou DELETE /task-occurrences/{id} selon le périmètre.

Champs de données : title, status, recurrenceRule, timezone, nextRunAt, recurrenceId, originalDate, isException.

Pseudo structure JSON : { « title »: « Faire le reporting », « recurrenceRule »: « FREQ=WEEKLY;BYDAY=MO », « timezone »: « Europe/Paris », « nextRunAt »: « 2026-02-02T08:00:00Z », « status »: « active » }

Ce n’est pas encore le code final. C’est une base de discussion pour vérifier les décisions avant de les figer dans l’API.

Cette étape évite de confondre vitesse et précipitation. Une fois la spec plus solide, je vérifie si le code sera testable avant même de demander des tests.

Comment rendre les tests non négociables ?

Je ne demande pas à l’IA de générer des tests tout de suite. Je lui demande d’abord d’auditer ce qui manque et de vérifier si le code est testable. C’est une nuance énorme. Si je demande “écris-moi les tests”, j’obtiens souvent les tests les plus faciles. Pas ceux qui couvrent les vrais risques.

La technique attribuée à Andrew Brogdon, c’est ça : avant de produire du code de test, le modèle doit lire la base de code, repérer les zones non couvertes, vérifier si les dépendances sont injectables, si le domaine est découplé des routes HTTP, puis proposer un plan de tests priorisé. Sur une API REST de tâches avec des tâches récurrentes, je veux qu’il audite la génération des prochaines occurrences, les fuseaux horaires, les erreurs RRULE, les modifications de série, la suppression, les appels concurrents, la persistance et les retours HTTP.

Tu es auditeur qualité sur une API REST Node.js/Express de gestion de tâches.

Lis la structure du projet avant de proposer des tests.
Identifie les fichiers critiques : routes, services, modèles, persistance, validation, logique de récurrence.
Produit une matrice de risques avec impact, probabilité et priorité.
Liste les tests existants et ce qu’ils couvrent réellement.
Liste les tests manquants, surtout sur les tâches récurrentes, RRULE, fuseaux horaires, modifications de série, suppression, concurrence, persistance et codes HTTP.
Indique quels changements de conception rendraient le code plus testable : injection de dépendances, fonctions pures, découplage domaine/routes HTTP.
Ne génère pas une masse de tests maintenant.
Attends ma validation du plan de test avant d’écrire le moindre fichier Jest.

Le vrai sujet, ce n’est pas Jest, Mocha ou Vitest. Le vrai sujet, c’est de séparer la logique métier des routes HTTP. Une route Express doit recevoir une requête et retourner une réponse. Les règles, elles, doivent vivre ailleurs, dans des fonctions ou services testables sans lancer toute l’application.

// Fonction pure : pas de base de données, pas d'API, pas d'état caché.
function generateNextOccurrence(task, fromDate) {
  const date = new Date(fromDate);

  if (task.recurrence === "DAILY") {
    date.setUTCDate(date.getUTCDate() + 1);
    return date.toISOString();
  }

  throw new Error("Unsupported recurrence");
}

module.exports = { generateNextOccurrence };

// Injection de dépendance : le service reçoit son repository.
function createTaskService({ taskRepository, clock }) {
  return {
    async completeTask(taskId) {
      const task = await taskRepository.findById(taskId);
      const now = clock.now();

      task.completedAt = now;
      return taskRepository.save(task);
    }
  };
}

module.exports = { createTaskService };

// Test ciblé Jest sur une récurrence en UTC.
const { generateNextOccurrence } = require("./recurrence");

test("génère la prochaine occurrence quotidienne sans dérive timezone", () => {
  const task = { recurrence: "DAILY" };
  const result = generateNextOccurrence(task, "2025-03-29T23:00:00.000Z");

  expect(result).toBe("2025-03-30T23:00:00.000Z");
});

J’ai vu ce problème chez un client : 80 tests verts, mais aucune couverture sur les changements de série récurrente. Le bug était là. Pas dans le CRUD classique.

Comment nettoyer sans tout mélanger ?

Quand je nettoie avec une IA, je ne mets pas tout dans le même sac. Je fais deux conversations fraîches. Une pour la robustesse fonctionnelle, donc cas limites, comportements ambigus, conditions de concurrence. Une autre pour l’hygiène du code, donc code mort, résidus, commentaires faux. Sinon le modèle part vite dans une revue floue, j’ai vu ça chez un client sur une API de planning, il mélangeait bugs métier et renommage de variables.

La technique, souvent attribuée à Aja Hammerly, est simple. On force le modèle à regarder un seul type de problème à la fois. Les conversations séparées réduisent le risque de mélange. D’un côté, est-ce que le produit tient debout sous pression. De l’autre, est-ce que le code est propre à maintenir.

Prompt 1 — Audit robustesse

Analyse cette API REST de tâches.
Commence par lire ou exécuter mentalement les tests existants.
Concentre-toi uniquement sur les cas limites manquants, les comportements ambigus et les conditions de concurrence.

Vérifie en priorité :
- Les appels concurrents sur une même tâche
- Les transitions de statut
- Les tâches récurrentes
- La régénération automatique
- Les fuseaux horaires
- Les erreurs déjà couvertes ou non par les tests

Donne-moi une liste priorisée d’anomalies possibles.
Pour chaque anomalie, ajoute :
- Le risque
- Un scénario de reproduction
- Le test recommandé
- La raison pour laquelle le test actuel ne suffit pas

Prompt 2 — Nettoyage code mort

Nouvelle conversation.
Cherche uniquement les éléments inutiles ou trompeurs.
Ne fais pas d’audit fonctionnel.

Repère :
- Le code inutilisé
- Les imports morts
- Les commentaires qui mentent
- Les TODOs sans propriétaire
- Les console.log
- Les branches debug
- Les noms trompeurs
- Les fichiers qui n’ont plus de rôle clair

Propose des suppressions prudentes.
Signale clairement les zones où une vérification humaine reste nécessaire.

Petit exemple volontairement sale. L’objectif n’est pas d’embellir pour embellir. C’est de réduire le bruit avant qu’il devienne de la dette.

// Vérifie que la tâche est supprimée, commentaire obsolète.
function updateTask(task) {
  console.log("Debug task", task);

  // TODO: Gérer mieux plus tard.
  if (task.status === "done") {
    return { ...task, completedAt: new Date() };
  }

  return task;
}

function oldFormatTask(task) {
  return task.title.toUpperCase();
}

function updateTask(task, now = new Date()) {
  if (task.status === "done") {
    return { ...task, completedAt: now };
  }

  return task;
}

Ces prompts marchent mieux dans cet ordre. Spécification, audit de test, tests ciblés, puis nettoyage séparé. Là, l’IA garde le cap, et vous aussi au moment de relire.

Et si vos prompts devenaient une vraie revue qualité ?

Je retiens une chose simple. Un bon prompt IA pour coder ne sert pas juste à produire plus vite. Il sert à mieux réfléchir avant, pendant et après le code. Je commence par une spécification sans code, je force l’IA à poser les bonnes questions, je rends les tests non négociables, puis je nettoie avec deux passes séparées. C’est moins spectaculaire qu’un prompt miracle, mais beaucoup plus utile dans un vrai projet. Vous gagnez en clarté, en robustesse et en temps de relecture, avec un code plus simple à maintenir.

FAQ

• Qu’est ce qu’un bon prompt IA pour coder ?
  Un bon prompt IA pour coder donne un rôle clair au modèle, précise le contexte, impose des limites et demande d’abord une analyse critique. Je préfère demander au modèle de challenger l’architecture, les risques et les tests avant de lui laisser écrire du code.
• Pourquoi interdire à l’IA d’écrire du code au début ?
  Parce que le code arrive souvent trop tôt. Si le besoin est flou, l’IA va quand même produire quelque chose de crédible. Le problème, c’est que les angles morts restent cachés. Une phase de spécification force le modèle à clarifier les exigences avant d’implémenter.
• Faut il demander directement des tests à l’IA ?
  Je préfère éviter. Demander directement des tests pousse souvent le modèle à écrire les tests les plus évidents. Le meilleur réflexe consiste à lui demander d’abord un audit de couverture, de testabilité et de risques, puis seulement après un plan de tests ciblé.
• Pourquoi séparer les prompts de nettoyage ?
  Parce qu’un prompt trop large donne une revue trop vague. Les cas limites et les conditions de concurrence ne demandent pas la même attention que les imports morts, les TODOs ou les commentaires obsolètes. Deux conversations séparées donnent une analyse plus nette.
• Ces méthodes marchent elles hors développement logiciel ?
  Oui, l’idée reste valable dès qu’on utilise l’IA sur un sujet complexe. On peut lui demander de jouer le rôle d’un auditeur critique, de poser les questions manquantes, de tester les hypothèses et de nettoyer les incohérences. En data, automatisation ou tracking, c’est souvent ce qui fait la différence.

A propos de l’auteur

Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No Low Code avec n8n, intégration de l’IA en entreprise et SEO GEO. J’accompagne des équipes qui veulent utiliser l’IA sans perdre le contrôle sur la qualité, la donnée et les process. J’ai travaillé avec des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. Si vous voulez structurer vos usages IA ou automatiser vos workflows business, contactez-moi.

Franck Scandolera

⭐ Data Analyst, Analytics Engineer et expert dans l’automatisation IA  ⭐

Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…

Mon terrain de jeu :

Data Analyst & Analytics engineering : tracking propre RGPD, entrepôt de données (GTM server, BigQuery…), modèles (dbt/Dataform), dashboards décisionnels (Looker, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, Make, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.