Technologie · July 21, 2026 · 8 min de lecture

L'ingénierie de prompt pour les ingénieurs logiciels : le prompting comme une revue de code inversée

Pour les ingénieurs, le prompting n'est pas une astuce de formulation — c'est de la conception de système plus de la revue de code. Spécifiez les contraintes, incluez les tests, lisez la sortie, repérez l'appel obsolète. Un guide pratique avec un exemple concret et sa méthode d'évaluation.

Les ingénieurs ont été les premiers professionnels à vivre avec un assistant IA chaque jour de travail, il vaut donc la peine d'être précis sur cette compétence. Il ne s'agit pas de taper un prompt astucieux en espérant. Les ingénieurs qui tirent un réel levier de l'IA traitent le prompting comme n'importe quelle interface : ils définissent le contrat, les contraintes et les modes de défaillance, puis vérifient ce qui revient. C'est l'article consacré à l'ingénierie logicielle dans notre série sur l'ingénierie de prompt par rôle, et c'est l'une des choses les plus claires que révèle l'AI Sandbox.

Le prompting, c'est de la revue de code inversée

La bonne pratique qui tient bon à travers chaque étude récente est ennuyeuse en surface : énoncez les critères de réussite et les contraintes avant de demander, donnez au modèle des entrées structurées, et spécifiez la sortie exacte que vous voulez. L'ingénierie de prompt n'est pas devenue « écrire des prompts plus longs » — elle est devenue « écrire des spécifications plus claires ». C'est pourquoi elle oblige les ingénieurs à penser comme des ingénieurs système. Mais ce qui distingue réellement les forts des faibles, c'est ce qui se passe après l'apparition du code : le lire de manière critique et repérer le problème subtil — un appel obsolète, une nouvelle tentative qui avale un 4xx qu'elle aurait dû faire remonter, un cas limite non géré. C'est l'aisance avec l'IA appliquée au code.

Un exemple concret

Demandez à un assistant un client d'API asynchrone avec une logique de nouvelle tentative. Un prompt faible, c'est « écris une fonction pour récupérer un utilisateur avec des tentatives ». Un prompt fort fixe le contrat, les contraintes et — c'est crucial — les tests que le code doit passer. Ensuite, l'ingénieur lit le résultat, repère que la boucle de nouvelle tentative générée temporise sur un 404 sur lequel elle aurait dû lever une exception, corrige cela, et exécute le test pour confirmer.

## TASK
Write an async fetchUser(id) client method in TypeScript.

## CONSTRAINTS
- Modern async/await fetch — no deprecated request libraries
- Retry on 5xx and network errors only, never on 4xx
- Exponential backoff with jitter, max 3 attempts, 5s per-attempt timeout

## TESTS IT MUST PASS
- Returns parsed JSON on 200
- Throws immediately on 404 (no retry)
- Gives up after 3 failed attempts

## OUTPUT
Code first, then one line on any assumption you made.

• Bon : contraint la demande, remet au modèle ses tests, lit la sortie, repère le code obsolète ou dangereux, vérifie par une exécution rapide.
• Faible : colle « écris un fetch avec des tentatives », accepte la première fonction plausible, et la livre avec le bug 4xx intact.

Les bonnes pratiques qui font vraiment la différence

• La structure plutôt que la longueur. Séparez la demande en sections — tâche, entrées, contraintes, format de sortie — au lieu d'un seul long paragraphe. La qualité du raisonnement tend à se dégrader bien avant que vous ne manquiez de place, donc concis et clair l'emporte sur tentaculaire.
• Remettez vos tests au modèle. Incluez les cas que le code doit passer, pas seulement les exigences. Il écrit selon votre exigence plutôt qu'une exigence générique.
• Faites-lui montrer son raisonnement avant le code, afin qu'une hypothèse erronée soit visible avant que vous ne lisiez une implémentation bâtie dessus.
• Traitez votre suite de tests comme l'évaluation. La sortie n'est pas terminée parce qu'elle a l'air correcte — elle est terminée quand elle passe.

Modes de défaillance courants

• Coller-et-livrer : faire confiance à du code d'apparence assurée sans le lire.
• Demandes vagues : pas de contraintes, pas de format de sortie, donc le modèle devine — et devine de manière générique.
• Aucune étape de vérification : le code compile, donc il doit être correct (il ne l'est pas, de manière fiable).

Comment nous l'évaluons

Vous ne pouvez rien mesurer de tout cela avec un quiz sur la syntaxe des prompts, et vous n'apprenez rien en interdisant l'IA lors de l'entretien. Vous placez le candidat dans une tâche d'ingénierie réaliste avec les outils qu'il utiliserait réellement et vous observez comment il dirige, lit et corrige — ce qui est exactement ce que fait une évaluation AI Sandbox, et comment l'aisance avec l'IA est notée comme un pilier. Découvrez ce que couvre par ailleurs une solide évaluation d'ingénieur logiciel, pourquoi c'est la façon honnête de tester le métier dans le recrutement AI-native, ou regardez la composition d'une évaluation ajustée au rôle.

Les meilleurs ingénieurs ne demandent pas du code. Ils demandent une ébauche, puis lui appliquent le même scepticisme qu'ils appliqueraient à n'importe quelle pull request — et ce scepticisme est ce qui vaut la peine d'être recruté.