La blague fonctionne parce que les deux personnes sur l'image font le même travail : essayer d'expliquer à une machine ce qu'elles voulaient dire, puis découvrir que la machine les a prises au pied de la lettre de la pire façon possible.
L'un l'appelle du débogage. L'autre l'appelle du prompting. Les deux fixent quelque chose qui devrait fonctionner et qui ne fonctionne pas.
Après plus de douze ans à construire des sites web et en avoir livré des milliers via Seahawk Media, je ne vois pas le prompt engineering remplacer le software engineering. Je le vois devenir une partie requise du software engineering, de la même manière que le cloud deployment, l'observabilité et la sécurité sont passés de préoccupations spécialisées à une tâche quotidienne.
- Le prompt engineering est une compétence d'interface, pas un remplacement du software engineering.
- L'IA en production a besoin à la fois de tests déterministes et d'évaluations probabilistes.
- Les invites, le contexte, les outils et les paramètres de modèle appartiennent au contrôle de version aux côtés du code.
- Si vous choisissez quoi apprendre en premier, apprenez les fondamentaux du logiciel et ajoutez le prompt engineering par-dessus.
La comparaison est amusante parce que les deux côtés font du débogage.
Un ingénieur logiciel écrit du code, l'exécute, lit l'erreur, change le code et l'exécute à nouveau. Un prompt engineer écrit une instruction, lit la sortie, change l'instruction ou le contexte et réessaie. La boucle est presque identique. La surface de défaillance ne l'est pas.
Le code traditionnel échoue bruyamment plus souvent. Une fonction lève une exception, un test devient rouge, un vérificateur de type refuse la compilation. Un modèle peut échouer en gardant l'air complètement composé. Il retourne de la prose valide, du JSON valide, ou du code qui a l'air valide mais est incorrect d'une façon que le chemin heureux n'expose pas.
Cela change la méthode de débogage. Vous ne posez plus seulement la question « Quelle instruction l'ordinateur a-t-il exécutée ? ». Vous posez aussi « Quel contexte le modèle a-t-il déduit, quels outils pouvait-il voir, quelle ambiguïté ai-je laissée ouverte, et à quelle fréquence cela échoue-t-il sur un ensemble représentatif d'entrées ? »
Point clé : Les deux disciplines traduisent l'intention en comportement machine. L'ingénierie logicielle contrôle le système autour de ce comportement ; le prompt engineering contrôle une couche probabiliste à l'intérieur de celui-ci.
Ce que l'ingénierie logicielle possède toujours
L'ingénierie logiciel possède les parties qui ne peuvent pas être escamotées : les modèles de données, l'authentification, les permissions, l'état, la concurrence, les retentatives, la mise en cache, les flux de paiement, les migrations, les performances, l'accessibilité, les limites de sécurité, la surveillance et la récupération quand le système tombe en panne à 2h du matin.
Un prompt brillant ne peut pas réparer une contrainte de base de données manquante. Il ne peut pas rendre une action non autorisée sûre, empêcher deux workers de réclamer le même job, ou garantir qu'un webhook de paiement est idempotent. Il peut suggérer du code pour ces choses. Le système a toujours besoin d'un ingénieur qui sait pourquoi cela importe et comment prouver que ça fonctionne.
C'est pourquoi l'expression « le modèle a écrit l'appli » fait généralement trop de travail. Le modèle a peut-être produit la majorité du code visible. Le produit, ce sont les décisions invisibles autour : quelles données sont fiables, où la validation se fait, ce qui est enregistré, ce qui peut être réessayé, ce qui demande une approbation humaine, et ce qui se passe quand une dépendance disparaît.
C'est de l'ingénierie. Plus la génération de code s'accélère, plus le travail se déplace vers ces décisions.
Ce qu'est vraiment le prompt engineering
Le prompt engineering est souvent décrit comme trouver les bonnes paroles. C'était une description raisonnable quand toute l'interaction se résumait à une zone de texte. C'est trop étroit pour les systèmes agentic actuels.
Le vrai travail est de concevoir l'environnement de travail du modèle. L'instruction compte, mais aussi le system prompt, le contexte du dépôt, les documents récupérés, les exemples, les descriptions d'outils, les limites de permissions, le schéma de sortie, le choix du modèle, le budget de tokens, et l'ensemble d'eval utilisé pour juger le résultat.
Un bon prompt engineer ne peaufine pas des formules magiques. Il décide ce que le modèle doit savoir, ce qu'il ne doit pas supposer, quelles actions il peut entreprendre, et quelle preuve comptera comme fait.
C'est beaucoup plus proche du design d'interface et de la pensée systémique que de la rédaction. Mon workflow Claude Code en production fonctionne parce que le harness fournit le contexte, les contraintes, les outils, et la vérification. La phrase astucieuse est la partie la moins importante.
La ligne n'est pas entre le code et l'anglais
Les gens encadrent cela comme le code d'un côté et le langage naturel de l'autre. La distinction la plus utile est le comportement déterministe versus probabiliste.
Avec le code applicatif ordinaire, la même entrée et le même état devraient généralement produire la même sortie. Les tests affirment le comportement exact. Avec un modèle, une instruction sensée peut produire une distribution de résultats acceptables et inacceptables. Les tests importent toujours, mais vous avez aussi besoin d'evals : un ensemble fixe de tâches réalistes, noté à plusieurs reprises, pour pouvoir voir si un changement de prompt ou de modèle a amélioré le système globalement ou a seulement corrigé l'exemple devant vous.
C'est là que « faire du prompt engineering, c'est juste discuter avec l'IA » s'effondre. Une conversation décontractée optimise la réponse actuelle. Le prompt engineering en production optimise un comportement reproductible sur de nombreuses réponses.
Où les deux disciplines se font écho
| Couche | Ingénierie logicielle | Ingénierie des invites |
|---|---|---|
| Source de vérité | État du référentiel et de l'exécution | Instructions, contexte, outils et paramètres du modèle |
| Défaillance courante | Exception, état incorrect ou régression | Résultat plausible mais erroné, perte de contexte ou mauvaise utilisation d'outils |
| Unité de changement | Diff de code | Diff de prompt, contexte, schéma, outil ou évaluation |
| Vérification | Tests unitaires, d'intégration et de bout en bout | Ensembles d'évaluation, évaluateurs, vérifications de schéma et révision humaine |
| Reproductibilité | Dépendances épinglées et entrées connues | Modèle épinglé, contexte capturé, trace d'outil et paramètres d'échantillonnage |
| Observabilité | Logs, métriques, erreurs et traces | Prompts, complétions, appels d'outils, latence, tokens et coûts |
| Déploiement | Artefact d'application versionnée | Instructions versionnées et configuration du modèle avec possibilité de retour |
Le vocabulaire change, mais la discipline ne change pas. Rends l'entrée explicite. Garde les changements mineurs. Teste contre la réalité. Capture assez d'état pour reproduire une défaillance. Reviens en arrière quand la nouvelle version est pire.
Pourquoi « réessayer » n'est pas un workflow
L'habitude la plus dangereuse en prompt engineering est de traiter une nouvelle tentative comme une preuve. La deuxième réponse est meilleure, donc le problème semble résolu. Rien n'a été appris sur pourquoi la première réponse a échoué, si l'amélioration se reproduira, ou quelle variable a changé.
Une nouvelle tentative utile change une seule chose intentionnellement. Ajoute la contrainte manquante. Supprime le contexte hors de propos. Affine le schéma de sortie. Donne à l'outil une permission plus sûre. Ajoute le cas d'échec à l'ensemble d'évaluation. Ensuite, relance la même évaluation.
Les ingénieurs logiciels ont appris cela à travers des années de tests instables et des bugs « ça marche sur ma machine ». Les prompt engineers rencontrent la même leçon à travers « ça a marché dans le chat précédent ». Dans les deux cas, l'état non enregistré est l'ennemi.
C'est aussi pour ça que je préfère un seul modèle tenant un rôle défini plutôt que cinq modèles votant sur la même demande vague. J'ai écrit à ce sujet dans why opening more AI models can make the output worse. Plus de tentatives ne réparent pas une tâche mal spécifiée.
Le contexte est le nouveau runtime
Quand un travail généré par l'IA échoue, les gens blâment souvent le modèle en premier. Dans les sessions de codage en production, la pièce manquante est généralement le contexte.
L'agent ne connaissait pas les conventions du dépôt. Il n'a pas vu la migration de base de données. On ne lui a pas dit qu'un appel API modifie l'état externe. Il a trouvé un ancien pattern et l'a copié. Il avait le fichier pertinent dans la première moitié d'une longue session, puis a perdu ce détail à mesure que le contexte s'est rempli.
Un prompt engineer voit cela comme un problème de contexte. Un software engineer voit cela comme un problème d'environnement et de dépendances. Le builder combiné corrige le système : placer les instructions durables dans le dépôt, faire exposer par les outils l'état approprié, exiger une approbation pour les actions destructrices, et vérifier le résultat contre l'application réelle.
Le meilleur prompt n'est souvent pas un prompt plus long. C'est un meilleur outil, un contexte plus petit, ou un test que l'agent peut exécuter sans deviner.
Le workflow de production qui combine les deux
C'est la boucle en laquelle j'ai confiance pour le travail logiciel assisté par IA. Elle est délibérément moins dramatique que les démos.
- Écrivez les critères d'acceptation avant de demander la mise en œuvre. Définissez le résultat visible pour l'utilisateur, les contraintes, et ce qui doit rester inchangé.
- Inspectez le système réel. Lisez le code pertinent, le schéma, les logs et l'état actuel. Ne laissez pas le modèle concevoir contre un dépôt imaginaire.
- Donnez au modèle un contexte délimité. Incluez les fichiers et les règles qui importent, écartez le matériel non pertinent, et indiquez où il doit demander avant d'agir.
- Générez le plus petit changement cohérent. Les diffs plus petits sont plus faciles à raisonner pour les humains et les modèles.
- Exécutez des vérifications déterministes. La vérification de types, les tests, le linting, les builds, les règles de sécurité et les contraintes de base de données continuent de porter des garanties fortes.
- Exécutez des évaluations probabilistes où un modèle est en production. Testez les entrées normales, les cas limites, les entrées adversariales, les refus et les défaillances d'outils sur des échantillons répétés.
- Examinez la diff et le comportement. La revue de code détecte les erreurs d'implémentation. La revue produit détecte une modification techniquement correcte qui résout le mauvais problème.
- Versionnez la décision dans son ensemble. Commitez le code, le prompt, le contrat de l'outil, les cas d'évaluation et la configuration du modèle nécessaires pour la reproduire.
C'est la version fonctionnelle de l'ingénierie agentic. Le modèle accélère l'exécution. L'ingénieur garde la responsabilité du résultat. Si vous voulez plus de détails d'implémentation, regardez comment j'utilise vraiment Claude Code en production.
Ce que je recherche quand j'embauche un AI builder
Je n'embaucherais pas quelqu'un pour un rôle d'IA en production parce qu'il peut me montrer un long prompt. Je lui demanderais de me montrer un système qu'il a livré et de m'expliquer un échec.
Qu'est-ce que le modèle a mal fait ? Comment l'ont-ils reproduit ? La correction était-elle dans le prompt, le contexte, l'outil, le schéma ou le code environnant ? Quel test ou quelle évaluation empêche l'échec de revenir ? Que se passe-t-il quand le fournisseur de modèle fait un timeout ? Quel est le rollback ?
Ces questions révèlent si quelqu'un pilote le modèle ou conçoit un produit. Un bon candidat peut naviguer entre les deux niveaux. Il peut affiner une instruction et remarquer que la vraie correction est une clé d'idempotence. Il peut ajouter une évaluation et reconnaître que la sortie n'aurait jamais dû être fiable sans validation déterministe.
C'est la distinction que je fais sur ma page d'embauche d'ingénieur IA. Le rôle n'est pas du copier-coller de prompts. C'est de l'ingénierie logicielle avec le comportement du modèle, l'utilisation d'outils, les évaluations et le coût ajoutés au système.
Où le prompting pur est suffisant
Toute tâche n'exige pas un dispositif de production. Inviter le modèle seul fonctionne très bien quand le travail est peu risqué, réversible, et examiné avant d'avoir de l'importance.
- Explorer le positionnement, les noms, les plans et les approches alternatives.
- Résumer du matériel que vous pouvez comparer avec la source.
- Rédiger des documents internes qu'un humain corrigera.
- Créer des prototypes jetables pour tester si une idée mérite du temps d'ingénierie.
Dans ces cas, l'invite est une interface de réflexion. Si la réponse est mauvaise, vous la rejetez. Il n'y a pas d'état client à corrompre, pas d'argent à déplacer, et pas d'automatisation silencieuse qui continue après avoir fermé l'onglet.
Là où l'ingénierie logicielle est non-négociable
Le seuil change au moment où le résultat affecte une autre personne ou continue sans supervision directe.
- Authentification, permissions, paiements, données clients, et toute action irréversible.
- Agents avec des outils qui peuvent écrire dans des bases de données, des dépôts, des boîtes de réception, ou des services externes.
- Des fonctionnalités IA qui doivent respecter des objectifs de latence, de fiabilité, d'accessibilité ou de coût.
- Des workflows où une réponse plausiblement erronée peut causer des dommages juridiques, financiers, de sécurité ou de réputation.
À ce stade, le prompting devient un composant dans un système d'ingénierie. Vous avez besoin de limites, de validation, de monitoring, de solutions de secours, et d'un processus d'approbation humaine proportionnel au risque.
L'ingénierie des prompts est une compétence, pas un titre final.
Je m'attends à ce que le titre d'ingénieur en prompts autonome importe moins que la capacité. La compétence est réelle. La limite qui l'entoure n'est pas stable assez pour rester isolée.
Les designers l'utiliseront pour créer et critiquer. Les marketeurs l'utiliseront pour rechercher et produire. Les opérateurs l'utiliseront pour automatiser les processus. Les ingénieurs logiciels l'utiliseront pour planifier, coder, tester et maintenir des systèmes. Les personnes valables ne seront pas celles qui gardent un sac de phrases secrètes. Ce seront celles qui connaissent leur domaine assez profondément pour fournir au modèle un contexte utile et juger le résultat.
Pour les builders, cela signifie devenir bilingue. Vous avez besoin de la précision pour dire à un ordinateur exactement ce qui doit être vrai et du jugement d'ingénierie pour savoir quelles vérités ne peuvent pas être déléguées à un modèle de langage.
L'avenir n'est pas ingénieur logiciel contre ingénieur en prompts. C'est des ingénieurs logiciels qui peuvent faire du prompting, des spécialistes en prompts qui apprennent à faire de l'ingénierie, et un écart qui se réduit entre les deux.
FAQ
L'ingénierie des prompts est-elle un vrai métier?
Oui, mais c'est une capacité plus forte intégrée à l'ingénierie de l'IA, au produit, au design, à la recherche ou aux opérations que comme titre de poste isolé. Le travail de prompt en production inclut la conception de contexte, les contrats d'outils, les évaluations, les schémas de sortie, les limites de sécurité, l'observabilité et le versioning. Écrire des instructions intelligentes n'en est qu'une partie.
Les ingénieurs prompt vont-ils remplacer les ingénieurs logiciels ?
Non. Le prompting peut accélérer la génération de code et rendre la création logicielle accessible à plus de personnes, mais les systèmes en production ont toujours besoin d'architecture, de sécurité, de gestion d'état, de tests, de déploiement, de monitoring et de récupération. Ces responsabilités deviennent plus importantes quand on ajoute un modèle probabiliste.
Les ingénieurs logiciels ont-ils besoin d'apprendre le prompt engineering ?
Oui. Les ingénieurs travaillant avec des agents de codage ou déployant des fonctionnalités d'IA doivent spécifier les tâches clairement, contrôler le contexte, concevoir les permissions des outils et évaluer une sortie non-déterministe. Le prompting devient partie intégrante de l'interface d'ingénierie, comme écrire un bon issue, un contrat API ou un plan de test.
Que dois-je apprendre en premier : la programmation ou le prompt engineering ?
Apprenez d'abord les fondamentaux du logiciel si votre objectif est de construire un logiciel en production. La programmation, les structures de données, les bases de données, HTTP, Git, les tests et la sécurité vous donnent le modèle mental nécessaire pour juger le code généré. Ajoutez le prompt engineering et la conception de contexte comme couche d'accélération, pas comme substitut à la compréhension du système.
Quelle est la différence entre un ingénieur prompt et un ingénieur IA ?
Un ingénieur prompt se concentre sur les instructions du modèle, le contexte, les outils et la qualité de sortie. Un ingénieur IA possède l'ensemble du système en production autour du modèle, incluant le code applicatif, les données, la récupération, les permissions, les évaluations, le monitoring, la latence, le coût et le déploiement. Dans les petites équipes, une seule personne fait souvent les deux.
Devenez la personne qui peut faire les deux
L'image a raison sur la chute. Les deux rôles passent une grande partie de la journée à comprendre pourquoi quelque chose qui devrait fonctionner ne fonctionne pas. L'avantage va à celui qui peut déboguer les deux couches.
Apprenez à rédiger des instructions précises. Apprenez à structurer le contexte. Apprenez quand utiliser les outils et quand les retirer. Puis conservez les habitudes d'ingénierie qui ont rendu les logiciels fiables avant l'arrivée des modèles : les petits changements, les contrats explicites, les tests reproductibles, les journaux utiles, les permissions rigoureuses et la responsabilité après le déploiement.
De meilleures instructions produisent de meilleures versions préliminaires. Une meilleure ingénierie transforme ces versions préliminaires en produits en lesquels les gens peuvent avoir confiance.
Si vous avez besoin de cette discipline combinée sur un projet en direct, consultez le service d'ingénierie agentique ou embauchez un développeur Claude Code.