Technologie · July 21, 2026 · 9 min de lecture

Le prompt engineering pour les ingénieurs logiciels : un guide concret

Le prompt engineering pour les ingénieurs logiciels, c'est de la conception système et de la revue de code : spécifier les contraintes, inclure les tests, lire le résultat, repérer l'appel déprécié.

← Fait partie de Évaluations générées par IA : le guide complet 2026

Les ingénieurs ont été les premiers professionnels à vivre quotidiennement avec un assistant IA, et il vaut la peine d'être précis sur la compétence en jeu. Le prompt engineering pour les ingénieurs logiciels, ce n'est pas taper un prompt ingénieux et espérer le meilleur. Si vous recrutez des ingénieurs, le levier est réel — tout comme le risque : un assistant rédige désormais une part significative du code en première ébauche, et la façon dont un ingénieur dirige et interroge cette ébauche influe directement sur la qualité du code livré et la charge de revue. Les ingénieurs qui tirent une vraie valeur de l'IA abordent le prompting comme n'importe quelle interface : ils définissent le contrat, les contraintes et les cas d'échec, puis vérifient ce qui leur revient. C'est l'entrée dédiée aux ingénieurs logiciels dans notre série sur le prompt engineering par rôle, et c'est l'une des choses les plus claires que l'AI Sandbox met en évidence.

Pourquoi c'est désormais une compétence fondamentale

L'instinct qui consiste à traiter la maîtrise du code IA comme un effet de mode — ou comme quelque chose sur lequel seuls les juniors s'appuient — inverse exactement le risque. Plus un assistant rédige de code, plus le goulot d'étranglement se déplace de l'écriture vers la revue, et la revue est la compétence la plus difficile. Une équipe qui livre du code généré par IA sans ingénieur capable de le lire de façon critique n'a pas gagné du temps ; elle a déplacé le coût en aval, dans les incidents de production et la file de revue. Les ingénieurs qui valent la peine d'être recrutés sont ceux qui font de l'assistant un multiplicateur de force pour le jugement, plutôt qu'un robinet de code au rendu plausible que personne n'a vraiment lu.

Cela recadre ce que vous évaluez réellement. Non pas si quelqu'un peut produire du code avec l'IA — ce que presque tout le monde sait faire désormais —, mais si le code qu'il valide est du code que vous voudriez dans votre base de code. La différence entre ces deux ingénieurs est invisible sur un CV et invisible dans un quiz de syntaxe. Elle n'est visible que dans la façon dont ils travaillent sur une vraie tâche.

Prompter, c'est de la revue de code à l'envers

La bonne pratique qui tient la route est ennuyeuse en surface : énoncer les critères de succès et les contraintes avant de demander, fournir au modèle des entrées structurées, et spécifier exactement la sortie souhaitée. Le prompt engineering n'est pas devenu « écrire des prompts plus longs » ; il est devenu « écrire des spécifications plus claires ». C'est pourquoi il oblige les ingénieurs à penser comme des ingénieurs systèmes. Mais ce qui sépare les forts des faibles se passe après l'apparition du code : le lire de façon critique et repérer le problème subtil — un appel déprécié, un retry qui avale un 4xx qu'il aurait dû remonter, un cas limite non géré. C'est l'AI fluency appliquée au code, et c'est le même discernement qu'un bon relecteur apporte à la pull request d'un collègue.

La spécification porte le travail

Quand les ingénieurs décrivent un prompt qui « a simplement fonctionné », ils veulent généralement dire qu'ils ont bien spécifié le problème. Le modèle ne lit pas les intentions ; il lit du texte. Chaque contrainte laissée implicite est une que le modèle comble par un défaut générique — et les défauts génériques, c'est ainsi qu'entrent les bibliothèques dépréciées, les timeouts manquants et les erreurs avalées. Écrire la spécification n'est pas une surcharge que vous supportez pour utiliser l'outil. C'est le même travail de clarification que vous feriez avant d'écrire le code vous-même, rendu visible et réutilisable.

Les petites ébauches relisables l'emportent sur les grandes

Il existe une loi d'échelle dans la relecture du résultat IA que les ingénieurs expérimentés apprennent vite : plus le morceau généré est grand, moins quiconque le lit attentivement. Demandez une fonctionnalité entière et vous obtenez un mur de code plausible qui est réellement difficile à auditer — alors il est parcouru en diagonale et livré. Demandez une seule fonction avec un contrat clair et ses tests, et vous obtenez quelque chose d'assez petit pour être réellement compris. L'ingénieur solide prompte donc en unités relisables, non parce que le modèle ne peut pas produire davantage à la fois, mais parce qu'il a l'intention de lire tout ce qu'il garde. Délimiter la demande est en soi un acte de contrôle qualité (quality gate), et c'est l'un des signes les plus fiables entre un ingénieur qui dirige l'outil et un ingénieur que l'outil dirige.

Un exemple concret

Demandez à un assistant un client API asynchrone avec une logique de retry. Un prompt faible : « écris une fonction pour récupérer un utilisateur avec des retries ». Un prompt fort précise le contrat, les contraintes et, surtout, les tests que le code doit passer. L'ingénieur lit ensuite le résultat, remarque que la boucle de retry générée fait un backoff sur un 404 alors qu'elle aurait dû lever une exception, le corrige et lance 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, fournit les tests au modèle, lit le résultat, repère le code déprécié ou non sécurisé, vérifie avec une exécution rapide.
• Faible : colle « écris un fetch avec des retries », accepte la première fonction plausible et la livre avec le bug 4xx intact.

Le réflexe de relecture est la compétence rare

Si le bug 4xx est un bon test, c'est qu'il est invisible pour quiconque ne sait pas déjà comment les retries devraient se comporter. Le code généré compile, passe un test de parcours nominal, et ressemble à toutes les boucles de retry que le modèle a jamais vues — parce qu'il en est la moyenne. Le repérer exige un ingénieur qui lit en ayant une question précise en tête : que se passe-t-il sur les chemins d'erreur que personne n'a démontrés ? Ce réflexe — lire pour les cas d'échec plutôt que pour le cas de succès — est la même compétence qu'ont toujours eue les relecteurs seniors. L'IA ne l'a pas créée, mais elle l'a rendue plus rare relativement à la demande, parce que le volume de code à relire a augmenté tandis que la discipline de le lire ne l'a pas suivi. Évaluer ce réflexe est désormais plus précieux qu'évaluer la vitesse de production brute, que l'outil a largement banalisée.

Les bonnes pratiques qui changent vraiment la donne

• Structure plutôt que longueur. Séparez la demande en sections — tâche, entrées, contraintes, format de sortie — au lieu d'un long paragraphe. La qualité du raisonnement tend à se dégrader bien avant d'avoir épuisé l'espace, donc concis et clair l'emporte sur étalé.
• Fournissez vos tests au modèle. Incluez les cas que le code doit passer, pas seulement les exigences. Il écrit pour votre barre, pas pour une barre générique.
• Faites-lui exposer son raisonnement avant le code, afin qu'une hypothèse erronée soit visible avant que vous lisiez une implémentation construite dessus.
• Interdisez explicitement les cas d'échec. Nommez les bibliothèques dépréciées, les patterns interdits et la sémantique qui compte — car le modèle se rabat par défaut sur la moyenne de tout ce qu'il a vu.
• Traitez votre suite de tests comme l'évaluation. Le résultat n'est pas terminé parce qu'il a l'air correct. Il est terminé quand il passe les tests.

Les erreurs fréquentes

• Coller-et-livrer : faire confiance à du code à l'air assuré sans le lire, puis découvrir le bug en production.
• Demandes vagues : pas de contraintes, pas de format de sortie — le modèle devine, et il devine de façon générique.
• Pas d'étape de vérification : le code compile, donc il est correct — ce qui n'est pas fiable.
• Prompter pour la fonctionnalité entière d'un coup au lieu d'une ébauche relisable, si bien que rien dans le résultat n'est assez petit pour être réellement vérifié.

Chacune de ces erreurs est un échec de relecture, pas un échec de code. L'IA n'a pas introduit une nouvelle classe de bugs ; elle a rendu les anciens plus rapides à produire et plus faciles à négliger parce que le résultat a l'air si abouti. La protection est la même qui a toujours séparé les seniors des juniors : le refus de faire confiance à du code qu'on n'a pas compris — appliqué désormais au code écrit par une machine.

Ce que cela donne à travers la pile technologique

L'exemple de la boucle de retry est délibérément petit, mais la même forme se retrouve partout où un ingénieur travaille. Côté front-end, c'est le composant généré qui se re-rend à chaque frappe parce que personne n'a contraint les dépendances de l'effet. En infrastructure, c'est le bloc Terraform qui ouvre un groupe de sécurité plus largement que prévu parce que le modèle a opté pour la valeur permissive par défaut. Dans le code de couche données, c'est la requête que l'assistant a écrite sans indication d'index — parfaite sur les données de test, et une lecture complète de table en production. Aucun de ces bugs n'est exotique ; ce sont les conséquences ordinaires d'accepter une première ébauche plausible sans la lecture spécifique au domaine qui les aurait détectés. La discipline du prompt est universelle, mais la discipline de relecture est là où la profondeur réelle d'un ingénieur se révèle — parce qu'on ne peut repérer que ce qu'on comprend.

Cela mérite réflexion quand vous concevez une évaluation. Un candidat qui dirige le modèle magnifiquement mais ne remarque jamais le groupe de sécurité élargi vous dit quelque chose de précis sur la limite de sa compétence. L'outil fait la frappe ; l'ingénieur fournit le jugement sur ce qu'il est sûr de conserver. Une évaluation des candidats qui ne mesure que si du code fonctionnel est apparu passe à côté de l'entière question de savoir si l'ingénieur aurait détecté ce qui tournait mal. Cette distinction — entre résultat produit et résultat compris — est celle qui vaut la peine de construire toute l'évaluation autour d'elle.

AI Fluency est un pilier, pas un complément

Dans notre modèle des cinq piliers, AI Fluency se situe aux côtés des capacités cognitives, de domaine, de jugement situationnel et comportementales — sans en remplacer aucune. Pour un ingénieur, cet ordre compte : repérer qu'une boucle de retry gère mal un 404 exige de maîtriser d'abord la sémantique HTTP et la gestion des erreurs. AI Fluency est un discernement superposé au jugement d'ingénierie, c'est pourquoi nous la traitons comme AI fluency évaluée en tant que pilier distinct, notée en plus des compétences fondamentales, jamais comme un substitut à celles-ci. Cela actualise aussi l'ancien débat entre exercices à emporter et coding en direct : la question n'est plus de savoir si le candidat peut écrire le code seul, mais comment il travaille avec les outils qu'il utilisera réellement au quotidien.

Comment nous l'évaluons

Vous ne pouvez mesurer rien 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 vraiment et observez comment il dirige, lit et corrige — c'est exactement ce que fait une évaluation AI Sandbox. Découvrez ce que couvre une solide évaluation d'ingénieur logiciel, en quoi le rôle voisin diffère pour les analystes de données, et pourquoi c'est la façon honnête de tester le poste dans le recrutement AI-native.

Les ingénieurs les plus solides ne promptent pas pour du code. Ils promptent pour une ébauche, puis l'abordent avec le même scepticisme qu'ils apporteraient à n'importe quelle pull request — et c'est ce scepticisme qui mérite d'être recruté.