Le prompting est une compétence de délégation sous un nom technique

Tout le monde a accès aux mêmes modèles. Même interface, même fenêtre de contexte, mêmes poids. Et pourtant, deux personnes s’installent devant le même outil : l’une repart avec une fonctionnalité qui marche, l’autre repart convaincue que tout cela est surestimé.

L’explication habituelle, c’est que la seconde ne connaît pas « les astuces ». Faux. Il n’existe aucune liste secrète. L’écart n’est pas technique, et c’est précisément pour cela qu’il est difficile à combler.

Le nom est le premier problème

Parler de « prompt engineering » pousse les gens à chercher la mauvaise chose. « Ingénierie » suppose une syntaxe, des paramètres, un manuel. Alors on part à la chasse aux formules magiques : « agis comme un développeur senior », « réfléchis étape par étape », « tu es un expert en… ». On collectionne des incantations.

Puis on applique ces incantations à une demande floue et on obtient une réponse floue, habillée d’un ton assuré. Les formules n’ont jamais été le sujet. Ceux qui prompt bien ne lancent pas des sorts : ils spécifient un travail.

La plupart des gens ne savent pas ce qu’ils veulent

C’est le vrai goulot d’étranglement, et il est inconfortable à admettre.

Un bon prompt vous force à définir le résultat avant de le voir. Format, contraintes, périmètre, ce qu’il faut exclure, ce à quoi ressemble « terminé ». La plupart des gens partent d’une intention vague en espérant que le modèle l’affinera pour eux.

Il ne le fera pas. Il produira quelque chose qui a la forme d’une réponse, ce qui est pire que de ne rien produire : vous avez maintenant quelque chose à quoi réagir au lieu de quelque chose à penser.

Si vous avez déjà reçu un ticket disant « améliore le tableau de bord », vous connaissez déjà ce mode de défaillance. Le modèle est ce développeur-là, sauf qu’il ne conteste jamais et ne demande jamais ce que vous vouliez dire.

On ne peut pas juger un résultat qu’on ne comprend pas

Voici le piège qui bloque les débutants. La sortie d’un modèle est fluide. Et la fluidité se lit comme de la compétence.

Si vous ne connaissez pas le domaine, une réponse générique ressemble à une bonne réponse. Vous n’avez aucun moyen de distinguer « c’est l’approche standard » de « c’est la moyenne de tout ce qui a été écrit sur le sujet, donc ça ne convient à personne ». Alors vous l’acceptez, vous la livrez, et vous n’apprenez jamais à quoi une meilleure version aurait ressemblé.

L’expertise n’est pas ce qui vous permet d’écrire le premier prompt. C’est ce qui vous permet de regarder la réponse et de dire : c’est du remplissage, va plus loin, tu as raté la contrainte qui compte vraiment ici.

Ce qui produit une boucle injuste. Ceux qui ont le moins besoin d’aide sont ceux qui en tirent le plus de valeur.

Deux modèles mentaux cassés

Presque tous ceux qui galèrent tournent avec l’un des deux :

Le modèle moteur de recherche. Des mots-clés, aucun contexte, aucun objectif. « Gestion d’état React. » Vous obtenez un article d’encyclopédie. Vous vouliez une décision pour votre application précise.

Le modèle télépathe. L’échec inverse. On parle au modèle comme à un collègue qui était à la réunion d’hier, qui connaît le code, qui se souvient de ce que le client a refusé la semaine dernière. « Corrige le bug dans le tunnel de commande. » Quel bug. Quel tunnel. Quel projet.

Ce n’est ni l’un ni l’autre. Il sait ce qui est devant lui à cet instant, et rien de plus. Tout ce que vous omettez, il l’invente.

Ils demandent une seule fois

Bien prompter n’est presque jamais un coup unique. C’est trois à cinq tours de resserrage : demander, lire, corriger, contraindre, redemander.

La plupart des gens demandent une fois, obtiennent soixante pour cent de qualité, et s’arrêtent. Puis ils concluent que l’outil est faible. L’outil allait bien. C’est la conversation qui s’est arrêtée trop tôt.

L’itération ressemble à un échec pour qui attend d’une machine qu’elle ait raison du premier coup. Ce n’est pas un échec, c’est la méthode elle-même. Personne n’espère écrire une fonctionnalité en un seul commit.

C’est un savoir tacite : personne ne peut vous le transmettre

On n’y arrive pas par la lecture. On se calibre au volume, exactement comme on a construit son intuition de débogage.

Au bout de centaines d’échanges, vous commencez à sentir quelles formulations s’effondrent en remplissage et lesquelles forcent un engagement sur des détails précis. Vous apprenez que « écris-moi une landing page » vous donne un gabarit, alors qu’une page avec une audience explicite, une action explicite, une référence de design et une liste d’exclusions ferme vous donne quelque chose d’utilisable. Personne ne vous l’a enseigné. Vous l’avez remarqué.

C’est pour cela que les guides déçoivent. Ils ne peuvent vous donner que le vocabulaire. Le jugement, lui, se gagne.

Le vrai prédicteur

S’il fallait devinir à l’avance qui sera bon à cet exercice, je ne poserais pas de question sur le parcours technique. J’en poserais une seule : savez-vous déléguer à des humains ?

Savez-vous écrire une tâche qu’un développeur prend en main et termine sans revenir vous voir cinq fois ? Précisez-vous les contraintes, les cas limites, la définition de « terminé » ? Ou vos passations finissent-elles par « tu vois ce que je veux dire » ?

Parce que prompter, c’est déléguer sans filet. Un collègue humain vous protège de votre propre brief flou. Il pose la question de clarification. Il remarque que ce que vous demandez n’a pas de sens et vérifie avant de brûler une journée.

Le modèle, non. Il comble vos trous en silence et vous rend quelque chose d’assuré et de faux. Les managers vagues obtiennent de mauvais résultats de l’IA pour la même raison qu’ils en obtiennent de mauvais de leurs équipes. L’outil a simplement retiré le tampon qui masquait cela.

Ce qu’il faut faire concrètement

Version concrète, si vous voulez progresser dès cette semaine :

• Écrivez les critères d’acceptation avant la demande. Si vous ne savez pas décrire à quoi ressemble une bonne réponse, vous n’êtes pas prêt à demander.
• Énoncez les contraintes, pas seulement l’objectif. Stack, audience, longueur, ton, ce qu’il faut éviter. Les exclusions travaillent plus que les instructions.
• Donnez un exemple de « bon ». Une référence, un échantillon, un fichier existant. Un exemple vaut mieux qu’un paragraphe d’adjectifs.
• Traitez la première réponse comme un brouillon, toujours. C’est dans votre deuxième message que se trouve la valeur.
• Dites ce qui n’allait pas, précisément. « Trop générique » n’est pas un retour. « Tu m’as donné cinq options, il m’en faut une seule avec le compromis énoncé » en est un.
• Réutilisez ce qui a marché. Quand un prompt produit quelque chose de bon, gardez-le. Constituez une bibliothèque, pas un souvenir.

Rien de tout cela n’est une astuce. C’est simplement la discipline d’écrire un brief clair — ce qui a toujours été la partie difficile, bien avant que tout ceci n’existe.

Oui, cet article a été prompté. C’est l’argument, pas un aveu. Le prompt derrière portait une thèse, un ton, une liste de choses à exclure et une fin précise à atteindre. N’importe qui peut taper « écris un article sur le prompt engineering » et obtenir huit cents mots de vide. La compétence n’a jamais été dans la frappe. Elle était dans le fait de savoir quoi demander.