Le plafond du prompt engineering : les règles critiques se codent, elles ne se promptent pas

Un plafond invisible tant qu'on ne le cherche pas

Aucun projet IA ne démarre avec l'intention de construire un prompt système de trente règles, ce résultat s'accumule progressivement, une correction à la fois, sur plusieurs mois. C'est précisément cette progressivité qui rend le plafond difficile à repérer de l'intérieur. Chaque ajout individuel semble raisonnable et proportionné au problème qu'il corrige. C'est seulement en prenant du recul sur l'ensemble du prompt, plusieurs mois après le lancement, que l'accumulation devient visible et que sa fragilité collective apparaît clairement.

Le réflexe du prompt qui grossit

Face à un comportement d'IA jugé incorrect, le réflexe le plus courant consiste à ajouter une règle de plus dans le prompt système. L'IA a oublié de vérifier une condition, on l'ajoute. Elle a mal géré un cas particulier, on précise le cas. Après quelques semaines d'ajustements successifs, le prompt système atteint vingt, trente, parfois trente-cinq règles empilées les unes derrière les autres, chacune ajoutée pour corriger un incident précis.

Ce processus semble rationnel étape par étape, et produit un résultat fragile dans son ensemble. Plus le nombre de règles simultanées augmente, plus la probabilité qu'elles entrent en tension entre elles augmente aussi, une règle générale et une règle spécifique qui se contredisent partiellement, une priorité implicite que personne n'a formalisée entre deux instructions. Le modèle doit arbitrer, et cet arbitrage reste probabiliste, pas déterministe.

Pourquoi empiler des règles ne les rend pas plus fiables

« Empiler des règles dans un prompt crée des conflits, des règles sur-appliquées ou sous-appliquées, c'est intrinsèquement probabiliste. »

Une règle promptée n'est jamais garantie, elle est seulement probable. Sur cent exécutions, elle peut être respectée quatre-vingt-dix-huit fois, ce qui semble excellent jusqu'à ce qu'on réalise que ces deux exceptions surviennent sur des cas réels, avec un client réel et une conséquence réelle. Une règle codée, elle, se comporte de façon identique à chaque exécution. Ce n'est pas une nuance théorique, c'est la différence entre un système qu'on peut auditer et un système qu'on peut seulement espérer.

Codé, pas prompté : où tracer la limite

Chez Leando, nous appelons ce principe codé, pas prompté, la logique métier critique doit être encodée dans des fonctions ou des règles de code documentées, jamais laissée à l'interprétation d'un prompt. Le principe exclut d'empiler des règles critiques dans un prompt système en espérant qu'elles soient toutes respectées, ce n'est pas une garantie, c'est un pari répété à chaque exécution.

La limite ne se trace pas sur le nombre de règles, elle se trace sur leur conséquence. Une règle de ton, de style de réponse, ou de format d'affichage peut rester dans le prompt sans grand risque, une erreur s'y corrige d'un coup d'œil. Une règle qui détermine un montant facturé, une éligibilité, ou une action irréversible sur une donnée doit passer côté code, là où son comportement peut être testé une fois et garanti pour toujours, plutôt que reformulé sans fin dans l'espoir qu'elle tienne mieux.

Pourquoi les équipes préfèrent quand même le prompt, même quand elles savent

Modifier un prompt ne demande ni cycle de développement, ni déploiement, ni revue de code, un simple changement de texte suffit et produit un effet immédiat. Coder une règle exige de mobiliser un développeur, d'écrire des tests, de déployer une nouvelle version. Face à un incident urgent, la tentation de corriger par le prompt l'emporte presque toujours sur la discipline de migrer la règle vers le code, parce que la première option résout le symptôme en quelques minutes quand la seconde en prend quelques heures ou quelques jours.

Cette facilité immédiate est précisément ce qui rend le plafond du prompt engineering difficile à respecter dans la durée. Chaque correction rapide semble raisonnable prise isolément, personne ne décide consciemment de construire un système fragile. Le prompt système grossit par une succession de décisions individuellement défendables, jusqu'à ce que sa fragilité collective devienne visible dans les statistiques d'erreurs, bien après que chaque règle ait semblé être la bonne réponse au bon moment.

Un signal simple pour savoir si une règle a dépassé le plafond

Le signal le plus fiable n'est pas le nombre total de règles dans le prompt, c'est la fréquence à laquelle vous devez le retoucher pour corriger un comportement. Chaque retouche corrective est un aveu implicite que la règle précédente n'a pas tenu. Trois retouches sur la même zone du prompt signalent que cette zone entière devrait migrer vers du code, pas recevoir une quatrième formulation plus précise.

Tenir un simple journal des modifications du prompt système, avec la date et la raison de chaque changement, rend ce signal visible sans effort supplémentaire. La plupart des équipes ne gardent aucune trace de l'historique de leur prompt, ce qui rend chaque nouvelle règle isolée, sans lien apparent avec les précédentes. Un historique, même sommaire, révèle immédiatement les zones qui reviennent le plus souvent et qui méritent, à ce titre, une conversation sur leur passage au code plutôt qu'une énième reformulation.

Une bonne pratique consiste à distinguer, dès la conception du projet, deux catégories de règles plutôt que de les laisser toutes s'accumuler au même endroit. Les règles qui déterminent le format, l'ordre, ou le ton d'une réponse peuvent rester dans le prompt sans risque particulier. Les règles qui déterminent une décision engageante, éligibilité, montant, action irréversible, devraient être identifiées comme candidates au code dès le premier jour, plutôt qu'après le troisième incident qui révèle leur fragilité.

Ce que le prompt engineering fait encore très bien

Cette distinction entre les deux catégories de règles mérite d'être documentée explicitement dans le cadrage du projet, pas laissée à l'appréciation ponctuelle de chaque développeur au moment où il écrit une nouvelle instruction. Un tableau simple, avec d'un côté les règles jugées critiques et codées, de l'autre les règles de confort laissées au prompt, donne à toute l'équipe une référence commune plutôt qu'un jugement individuel réévalué à chaque nouvelle demande.

Codé, pas prompté ne disqualifie pas le prompt engineering dans son ensemble. Le ton d'une réponse, l'ordre de présentation d'une information, la manière de reformuler une demande client, ces éléments tolèrent une variabilité qui ne coûte rien de sérieux si elle dérape occasionnellement. Le principe s'applique spécifiquement aux règles dont le non-respect a une conséquence métier mesurable, pas à la totalité de ce qu'on demande à un modèle.

Cette même distinction explique pourquoi une IA branchée directement sur une base de données pose un problème plus large que le seul prompt, l'article sur le function calling comme architecture de garde-fou détaille comment structurer cette frontière au niveau du code plutôt qu'au niveau du texte envoyé au modèle. Et sur la manière de faire remonter les règles métier qui n'ont jamais été écrites nulle part, l'article sur les règles métier implicites en PME donne la méthode pour les extraire avant de décider où elles doivent vivre.

Fixer cette distinction dès le cadrage d'un projet évite l'essentiel des mauvaises surprises qui surviennent six mois après le lancement. Un prestataire qui accepte de lister, avant même d'écrire le premier prompt, quelles décisions engageront une donnée critique et devront donc être codées, construit un système dont la fiabilité ne dépendra pas d'une succession de rustines découvertes au fil des incidents. C'est un travail de quelques heures en amont, qui évite des semaines de corrections dispersées en aval.

Avant votre prochaine correction de prompt, posez-vous une question simple, est-ce la première fois que cette règle pose problème, ou la troisième. Si c'est la troisième, la réponse n'est pas une meilleure formulation, c'est une ligne de code.