Le recursive prompting améliore les réponses mais nécessite des garde-fous

Utiliser les sorties d’un modèle pour affiner les consignes peut faire progresser un texte, un bugfix ou une aide client. Mais la boucle n’assure ni l’exactitude ni la pertinence sans critères, vérifications externes et point d’arrêt. Cadres de travail, exemple de consignes et mises en garde sur les chiffres et la sécurité.

Coût, dérive et preuves limitées encadrent la pratique

Chaque itération accroît le temps et le coût de traitement, et un historique trop long peut reléguer des contraintes essentielles dans le contexte transmis au modèle. Une synthèse des règles stables peut alors mieux préserver ces exigences que la réinjection intégrale des anciennes réponses. Mal conduite, la boucle amplifie une erreur initiale et lisse la prose sans gagner en fiabilité ; les consignes peuvent même dériver jusqu’à faire disparaître une exception ou à privilégier une tâche secondaire. Des diagnostics publiés par Seth Robins recommandent de resserrer le périmètre dès que la réponse s’éloigne de l’objectif et de corriger une faiblesse précise plutôt que d’ajouter du bruit. Les niveaux de preuve doivent rester distincts : un message communautaire sur le forum Hugging Face revendique des gains chiffrés, mais il ne constitue pas une validation scientifique indépendante et ne doit pas être confondu avec un dépôt GitHub distinct. Plus largement, les études existantes portent sur des protocoles précis et ne garantissent pas qu’une simple répétition améliore chaque réponse.

Ce que la boucle est, et ce qu’elle n’est pas

Le recursive prompting n’est ni une garantie d’exactitude ni une fonctionnalité magique, et le terme recouvre des usages différents selon les praticiens. Dans des guides pratiques, « récursif » désigne souvent une simple itération, quand la récursion informatique suppose l’appel d’une procédure sur un problème réduit et la construction d’un arbre de sous-tâches. L’autocorrection par LLM reste une reformulation dans le contexte disponible : sans donnée nouvelle, une erreur peut revenir, parfois avec davantage d’assurance. La technique se distingue du prompt chaining, qui déroule des étapes prédéfinies, et n’impose pas d’agent ni d’outils spécifiques : une interface de chatbot suffit pour une approche manuelle. Elle ne se confond pas non plus avec les Recursive Language Models, qui gèrent de grands contextes via des sous-appels. Enfin, réinjecter des documents soulève des enjeux de sécurité, car une instruction malveillante peut tenter de détourner le système. Dans la pratique, l’intérêt tient à un protocole de dialogue explicite — relire, repérer une lacune, envoyer un signal nouveau, comparer — sans nécessiter de « mode récursif » dédié.

Quatre étapes vérifiables et un point d’arrêt défini

Un cadre opératoire s’articule en quatre temps. D’abord, fixer le but et des critères mesurables — par exemple vérifier une garantie, un prix annoncé et un pays de disponibilité. Ensuite, produire une version de référence et la conserver. Puis auditer le résultat en pointant des défauts assortis d’extraits précis, avant de corriger ces points et de recontrôler le texte contre les critères initiaux pour éviter qu’un ravalement stylistique cache une erreur factuelle. Le diagnostic peut être généré par l’IA, mais la vérification décisive doit s’appuyer sur un document, un calcul ou un test. Il est également nécessaire de prévoir l’arrêt de la boucle en fonction de critères clairement définis : que les objectifs soient remplis, qu’un défaut ne puisse être résolu avec les sources à disposition, ou qu’aucune amélioration ne soit constatée. Un texte plus développé ne constitue pas forcément une avancée, et il faut évaluer la version obtenue en notant aussi bien les corrections apportées que les éventuelles régressions.

Probe, Scope Tighten, Refine : une variante et sa portée

Seth Robins propose sur GitHub une méthode structurée en trois phases : d’abord examiner différentes options (Probe), ensuite restreindre le champ d’investigation (Scope Tighten), puis perfectionner la solution choisie (Refine). Il s’agit ici de prévenir une mauvaise orientation de départ plutôt que d’améliorer la première proposition. Dans un rapport, cela peut passer par trois angles proposés, la sélection de celui qui convient au lectorat, puis le retravail de son plan. Des symptômes types — réponse générique, digression, choix prématuré — sont décrits, et à chaque défaut est associée une intervention ciblée. Ce cadre reste une proposition de son auteur, non une norme universelle. Il s’appuie sur l’analyse de 441 conversations avec un seul praticien, des chiffres qui ne se généralisent pas sans essais indépendants. La méthode distingue par ailleurs des gestes de pilotage — comparaison d’hypothèses, décomposition, reformulation de contraintes — à activer selon le problème observé, sans tout enchaîner systématiquement.

Des consignes prêtes à l’emploi pour diagnostiquer puis corriger

Appliquer la boucle suppose de fournir le document à corriger, les sources et des exigences prioritaires, puis d’exiger un diagnostic séparé de la réécriture afin de conserver la trace des décisions et des points non confirmés. Un canevas possible fixe un objectif — améliorer sans inventer de faits — et des critères d’exactitude, de sources, de longueur et de lisibilité. Il demande de repérer jusqu’à cinq défauts avec extraits, de les classer par impact avec les preuves disponibles, de corriger uniquement les passages concernés et de signaler à part toute information invérifiable, avec une condition d’arrêt interdisant de relancer sans défaut nouveau. Si la documentation manque, mieux vaut la fournir plutôt que de solliciter une réflexion supplémentaire. Promptitude évoque aussi la réécriture du prompt initial par l’IA pour clarifier la demande, sans remplacer la définition des critères ni le contrôle des sources.

Rédaction, code, support : trois terrains d’application concrets

En rédaction, l’outil peut extraire des éléments d’un communiqué, confronter un brouillon à des documents officiels et amener à corriger des formulations trop catégoriques, notamment lorsque des disponibilités sont mal datées. La vérification finale reste toutefois à la charge du journaliste. En développement, fournir un message d’erreur et un test défaillant permet au modèle de proposer un correctif limité avant de relancer les tests ; un retour d’outil externe prime sur une réponse convaincante, et des tests de non-régression s’imposent pour éviter d’introduire de nouveaux bugs. Côté support, comparer une réponse à une politique de remboursement aide à rectifier un délai erroné sans inventer de conditions ni autoriser des opérations non permises. L’accès aux bons outils, à des documents à jour et aux permissions déclarées dans le contexte et le harness engineering demeure indispensable.