4 techniques de prompting testees sur 7 modeles : guide d'atelier

“Analyse ce projet et fais des recommandations” – un seul prompt, sept modeles, et GPT-5.4 a produit 2 231 mots de conseils vagues, tandis que Claude Sonnet a aligne 11 formules elogieuses du type “excellente structure budgetaire”. Il a suffi de reecrire la requete selon une structure en cinq elements pour que les sept modeles se cantonnent a 346–443 mots, et les compliments disparaissent. Economie de tokens : de 41 % a 79 % selon le modele.

Ce ne sont pas des theories. Ce sont des donnees issues de l’atelier “Prompt Engineering en pratique”, que j’ai anime lors de la conference IIBA. Un brief projet, quatre techniques, sept modeles, 28 executions – et 0,054 $ pour le tout. Moins cher qu’un cafe au distributeur.

Vous trouverez ci-dessous les quatre techniques avec des prompts prets a l’emploi. Chacun peut etre execute directement ici – cliquez sur le bouton, et deux modeles executeront le prompt sur le meme brief projet. Les donnees sont incluses dans chaque prompt, rien a copier.

Video et supports de l’atelier (en russe) : hackmd.io/@belyaevstanislav/S1416ngRZg

Le projet d’experimentation

Les quatre techniques ont ete appliquees au meme cas – “BonusPlus”, une application mobile de fidelite pour un reseau de 340 magasins. Budget de 18 millions de roubles, 4 mois pour le MVP, equipe externalisee. Le brief contenait volontairement 16 problemes : de la compatibilite non verifiee avec 1C a des statistiques de marche douteuses et l’absence de QA cote client.

Le texte complet du brief est inclus dans chaque prompt executable ci-dessous. Par la suite, je ferai reference a des problemes specifiques qui y figurent.

Technique 1 : Structure du prompt – 5 elements

Le principe est simple : tout prompt efficace contient cinq blocs – Role, Contexte, Tache, Contraintes, Format. Ce n’est pas de la magie, c’est un cahier des charges redige pour une machine au lieu d’un prestataire.

Le mauvais prompt (pour contraster)

Lancez-le et observez le resultat – un mur de texte sans structure :

Le prompt structure

Maintenant, lancez le meme brief, mais avec une structure. Comparez la longueur et le contenu des reponses :

Ce qui s’est passe

Le mauvais prompt a donne exactement ce qu’on pouvait attendre : un mur de texte sans structure. GPT-5.4 a ecrit 2 231 mots – cinq fois plus que necessaire pour une presentation. Claude Sonnet a distribue 11 compliments a un projet dans lequel 16 problemes avaient ete volontairement integres. DeepSeek V4 Flash a tout simplement reformule le brief, en ajoutant quelques banalites sur “la necessite d’une planification rigoureuse”.

Le prompt structure a renverse la situation. Les sept modeles – de GPT-5.4 a Gemma 4-26B – se sont tenus dans une fourchette de 346–443 mots. Les compliments sont tombes a 0–1 formule. Des risques concrets avec des probabilites sont apparus. Le format – trois sections avec des puces, comme demande.

Pourquoi ca fonctionne

La contrainte “NE complimente PAS le projet” n’est pas une demande polie, c’est une instruction qui redirige l’attention du modele. Sans elle, le modele equilibre par defaut avantages et inconvenients – parce que c’est ainsi que sont structurees les donnees sur lesquelles il a ete entraine. L’interdiction explicite supprime cet ’equilibre’ et libere des tokens pour l’analyse.

Si vous connaissez deja les 5 elements du prompt, c’est la meme idee – mais ici avec des donnees de validation sur sept modeles.

Dans notre experience Make Weak Model Great Again, le prompt structure l’emporte sur le prompt non structure dans 73–82 % des cas – sur un echantillon de plus de 1 700 executions. Ici, lors de l’atelier, les memes 28 executions ont confirme la tendance.

Technique 2 : Few-Shot – montrez ce que vous voulez obtenir

Le Few-Shot, c’est quand vous donnez au modele deux ou trois exemples du format souhaite directement dans le prompt. Vous n’expliquez pas le format avec des mots, vous montrez un modele concret.

Le prompt

Ce qui s’est passe

100 % des modeles ont produit une reponse dans le format exact a cinq elements. Les sept – y compris Gemma 4-26B et GPT-5.4 Nano, qui dans les autres techniques melangeaient la structure. Le nombre de risques identifies variait – de 5 chez Nano a 12 chez GPT-5.4 – mais le format etait identique.

C’est la technique la plus efficace pour controler le format. Si vous avez besoin d’un modele precis – rapport, registre de risques, evaluation – deux exemples fonctionnent mieux que deux paragraphes d’explications.

Pourquoi ca fonctionne

Le modele n’apprend pas de vos instructions, mais des patterns. Deux exemples creent un pattern qu’il est plus facile de suivre qu’une description textuelle. C’est particulierement critique pour les modeles faibles : ils interpretent mal les instructions verbales complexes, mais copient parfaitement une structure.

Dans les donnees de notre experience, le Few-Shot l’emporte dans 75–89 % des cas. Le pourcentage le plus eleve des quatre techniques.

Technique 3 : Balises XML – les donnees separees des instructions

Les balises XML resolvent un probleme precis : quand un prompt contient a la fois des instructions et des donnees, le modele confond les deux. Les balises creent une frontiere claire – voici ce qu’il faut faire, voici avec quoi travailler.

Le prompt

Ce qui s’est passe

Les sept modeles ont produit un format tabulaire. Mais le plus interessant est ailleurs : le role de “controleur financier” a force les modeles a calculer.

Les sept ont identifie le probleme de la mathematique marketing – un budget marketing de 4 millions pour un objectif de 500 000 installations donne un CPI de 8 roubles, ce qui est irrealiste pour le marche russe. Tous ont releve des incoherences arithmetiques dans le budget. Ce sont les memes modeles qui, dans le mauvais prompt, se contentaient de reformuler les chiffres sans les verifier.

La profondeur, en revanche, variait radicalement : GPT-5.4 a produit un tableau de 36 lignes, Gemma – de 7 lignes. Meme format, contenu different.

Pourquoi ca fonctionne

La balise <project_brief> dit au modele : ce sont des donnees, pas des instructions. Sans balises, le modele peut prendre les affirmations du brief pour des faits. Avec les balises, il les traite comme des donnees d’entree a verifier. Et le role de controleur financier definit le focus – verifie les chiffres, n’evalue pas la strategie.

Si vous voulez plus de donnees sur les balises XML – dans nos tests, le template XML l’emporte dans 74–85 % des cas.

Technique 4 : Red Teaming – le modele attaque sa propre reponse

Le Red Teaming est un second prompt envoye apres la premiere analyse. Le modele bascule dans un role de sceptique et attaque ses propres conclusions.

Le prompt (envoye APRES l’analyse structuree)

Maintenant, change de role. Tu es un investisseur sceptique avec 20 ans
d'experience, qui cherche des raisons de NE PAS investir dans ce projet.

Attaque ton analyse precedente :
1. Quels risques as-tu manques ?
2. Ou as-tu ete trop indulgent dans ton evaluation ?
3. Quelles hypotheses as-tu acceptees sans les verifier ?
4. Qu'est-ce qui s'effondrera dans les 30 premiers jours ?

Sois dur. Pas de "neanmoins, le projet a du potentiel".

Ce qui s’est passe

Chaque modele a identifie 2–3 risques supplementaires qu’il avait manques lors de la premiere passe. Une trouvaille typique – le vendor lock-in : la dependance a un unique prestataire externalise, qui detient tout le code et l’expertise. Ce risque avait ete systematiquement oublie par tous les modeles dans l’analyse initiale – et systematiquement retrouve lors du Red Teaming.

Mais le plus revelateur concerne la statistique de marche non verifiee. Le brief indique “le marche a progresse de 24 %” en citant NielsenIQ. Un seul modele sur sept (GPT-5.4) dans un seul des quatre prompts a remis en question ce chiffre. Les autres l’ont accepte comme un fait.

Pourquoi ca fonctionne

La premiere passe cree une inertie – le modele a choisi un cadrage et s’y tient. Le Red Teaming brise cette inertie en imposant un role oppose. “Cherche des raisons de NE PAS investir” – ce n’est pas simplement un autre angle, c’est une autre tache d’optimisation.

Ce que l’IA manque systematiquement

28 executions sur un seul brief contenant 16 problemes volontairement integres ont dessine un tableau que je n’ai rencontre dans aucun autre article sur le prompting. D’habitude, on ecrit “l’IA a trouve des insights interessants” – mais personne ne verifie ce qu’elle n’a pas trouve.

Bilan : le meilleur modele (GPT-5.4) a detecte 50 % des problemes integres, en cumulant les quatre prompts. Le moins performant (GPT-5.4 Nano) – 22 %. La moyenne des sept modeles se situe quelque part entre les deux. Aucun modele n’a trouve les 16.

Mais les chiffres moyens sont moins interessants que les angles morts.

Probleme #15 – “Pas de QA cote client” – etait invisible pour tous les modeles dans tous les prompts. Zero sur 28 executions. Le brief indique que le client dispose de trois personnes dans son service IT (administrateur systeme, developpeur 1C, support technique) – mais aucun modele n’a deduit que personne ne sera la pour recetter le travail du prestataire. Pour n’importe quel PM ayant de l’experience en projets reels, c’est la premiere question : qui cote client receptionnera les releases ? Qui conduira la UAT ? Pour l’IA – un probleme invisible.

Probleme #12 – “Croissance du marche de 24 % – chiffre non verifie” – a ete identifie une seule fois sur 28 tentatives. Un modele, un prompt. Le brief indique “le marche a progresse de 24 %” en citant NielsenIQ – et six modeles sur sept ont integre ce chiffre dans leur analyse comme un fait. Sans verifier la source, sans remettre en question l’actualite, sans demander sur quelle periode. La reference a NielsenIQ a fonctionne comme un ’label de qualite’ – et les modeles ne la re-verifient pas.

J’appelle cela le ‘biais d’autorite’ : si les donnees sont presentees avec une source, le modele les prend pour acquises. C’est une consequence directe du fonctionnement de l’entrainement – les donnees sourcees dans le corpus d’entrainement sont generalement plus fiables. Mais dans un brief projet reel, n’importe qui peut ecrire “selon McKinsey”.

Trois niveaux de resultats

Les donnees de l’atelier se repartissent bien en trois niveaux :

Niveau 1 – problemes evidents. Compatibilite non verifiee avec 1C, freelance design sans backup, budget insuffisant pour les imprevus. Toutes les modeles les trouvent, meme Nano. Un prompt structure suffit.

Niveau 2 – problemes calcules. CPI a 8 roubles, incompatibilite des delais MVP avec le volume de fonctionnalites, conversion irrealiste des cartes plastiques vers l’application. La plupart des modeles les trouvent, mais uniquement avec le bon role – “controleur financier” ou “risk-first PM”. Sans role, les modeles ne sortent pas la calculatrice.

Niveau 3 – problemes contextuels. Absence de QA cote client, vendor lock-in avec un unique prestataire, caractere douteux des statistiques de marche. Seuls quelques-uns les trouvent, et pas toujours. Ici, il faut l’experience humaine – la connaissance de ce qui se passe dans les vrais projets, pas dans les documents.

Voici ce que cela signifie : l’IA est une excellente premiere passe. Elle detectera les incoherences budgetaires evidentes et les risques organisationnels. Mais elle ne remplace pas l’expert qui sait ou regarder.

Hmm.

Si vous utilisez l’IA pour analyser des projets – et je pense que vous devriez – gardez en tete : ce que le modele a trouve n’equivaut pas a ce qui existe. Les angles morts ne sont pas aleatoires, ils sont systemiques. Les modeles trouvent bien ce qui est explicitement ecrit, et mal ce qui doit etre deduit du contexte.

Bilan pratique

Quatre techniques – quatre outils pour des situations differentes.

R-C-T-C-F (Role, Contexte, Tache, Contraintes, Format) – l’hygiene de base. Si vous ne retenez qu’une seule chose – retenez le mnemonique. Il fonctionne comme une checklist : avant d’envoyer un prompt, parcourez les cinq lettres et verifiez que tout est en place.

Few-Shot – quand le format est critique. Deux exemples sont plus fiables que deux paragraphes d’explications. C’est particulierement important pour les modeles faibles et pour les taches ou un template precis est necessaire : registre de risques, evaluation, rapport.

Balises XML – quand le prompt contient beaucoup de donnees. Elles separent les instructions des donnees d’entree et empechent le modele de confondre les deux.

Red Teaming – la seconde passe. Pas un remplacement de la premiere analyse, mais un complement. Ne coute rien de plus, brise l’inertie de la premiere reponse.

Les quatre techniques fonctionnent sur n’importe quel modele – GPT, Claude, Gemini, DeepSeek. Nous les avons testees sur sept modeles, dont Qwen 3.6-27B et Gemma 4-26B. Les resultats varient en profondeur, mais pas en pattern : la structure l’emporte sur le chaos quel que soit le fournisseur.

Et une derniere chose : l’ensemble de la validation a coute 0,054 $. Cinquante-quatre milliemes de dollar pour 28 executions sur sept modeles. Le prompting, ce n’est pas une question d’outils couteux. C’est une question de formulation de la tache.

Tous les supports de l’atelier, y compris le brief projet et les prompts pour la pratique autonome (en russe) : hackmd.io/@belyaevstanislav/S1416ngRZg

Articles connexes

L'IA s'est diffusée plus vite qu'Internet – mais 62 % des utilisateurs sont restés au point de départ

99 % de la qualité pour 1,4 % du prix : ce qui ne va pas sur le marché des modèles IA

Comment Microsoft a silencieusement gagné le marché de l'IA en entreprise

LLM locaux pour managers : ce que vous pouvez vraiment faire tourner chez vous