Par Paul-Antoine TUAL — AI Transformation Leader, Croissance et Transitions — Mise à jour 19 mai 2026.
Le malentendu fondateur
Le 30 novembre 2022, OpenAI lance ChatGPT. L’interface ressemble à une messagerie. On y écrit comme on écrirait à un collègue. La machine répond avec une politesse étonnante, des nuances, parfois de l’humour. Et un mot s’installe dans le vocabulaire des entreprises : prompt. On apprend à « bien parler à l’IA ». On forme des équipes à « la requête parfaite ». On nomme un poste : prompt engineer.
Trois ans et demi plus tard, en mai 2026, ce mot a fait son temps. Pas parce que l’intelligence artificielle a déçu — elle n’a jamais été plus performante. Mais parce que l’analogie qui l’a porté — parler à l’IA comme à un humain — était une illusion d’interface, pas une vérité technique. Andrej Karpathy, ancien directeur de l’IA chez Tesla et figure tutélaire du domaine, l’a écrit publiquement dès juin 2025 sur X : il préfère désormais le terme context engineering à prompt engineering, parce que « prompt fait penser à une courte description de tâche, alors que dans toute application LLM industrielle, ce qui compte est l’art délicat de remplir la fenêtre de contexte avec exactement la bonne information pour l’étape suivante » [1]. Tobi Lütke, dirigeant de Shopify, a soutenu le même mouvement [2]. Gartner a publié à l’été 2025 une note dont le titre résume la bascule : Lead the Shift to Context Engineering as Prompt Engineering Fades [3].
Ce texte tient en une thèse simple. Un grand modèle de langage n’est pas un humain. Il n’a pas d’intuition, pas de bonne volonté, pas de mémoire de la conversation précédente sauf si on la lui réinjecte. Il fait une chose, et une seule : il calcule, à chaque pas, le prochain token le plus probable étant donné tous les tokens qui le précèdent. Lui « parler » comme à un humain est une convention culturelle utile pour le grand public ; en entreprise, c’est une erreur stratégique. La bonne manière de l’instruire, en 2026, est celle qu’on adopte avec n’importe quel ordinateur de bureau : des instructions claires, explicites, structurées. Et la forme la plus adaptée pour porter ces instructions, sur les modèles dominants du marché — Claude (Anthropic), GPT-5 (OpenAI), Gemini (Google) — est le balisage structuré : XML, JSON ou délimiteurs explicites selon le modèle et la tâche.
Ce n’est pas une opinion. C’est ce que recommandent les éditeurs eux-mêmes dans leur documentation officielle. C’est ce que mesurent les benchmarks indépendants. C’est ce que pratiquent, sans le formaliser, toutes les équipes qui mettent l’IA en production. Et c’est, pour une PME française qui veut tirer une valeur réelle de ses outils d’IA en 2026, le levier le plus mal compris du marché.
Ce qu’est vraiment un LLM, pour un dirigeant qui n’a pas le temps de lire un papier de recherche
Pour comprendre pourquoi l’analogie « parler à un humain » est trompeuse, il suffit d’ouvrir le capot. Pas de mathématiques. Trois mécanismes suffisent.
Le tokenizer. Avant qu’un modèle ne « lise » votre phrase, un programme déterministe la découpe en petits morceaux appelés tokens. Un token n’est ni un mot, ni une syllabe, ni un caractère. C’est une unité statistique apprise sur des milliards de pages de texte. Chaque token reçoit un numéro d’identifiant unique dans un vocabulaire de l’ordre de 100 000 à 200 000 entrées [4]. Quand vous écrivez « Rédige un compte rendu de réunion », la machine ne voit pas votre phrase : elle voit une suite de numéros.
Le transformer. C’est l’architecture neuronale qui s’est imposée depuis 2017. Sa caractéristique : il prend en entrée la suite des tokens, et il produit en sortie une seule chose — une distribution de probabilité sur le prochain token. Le modèle ne « comprend » pas votre question. Il calcule : étant donné cette séquence de numéros, quel est le numéro suivant le plus probable ? Puis il choisit. Puis il recommence. Mot par mot — token par token — il génère sa réponse [5].
L’attention. À chaque pas, chaque token « regarde » les autres tokens de la séquence et calcule combien il doit s’appuyer sur chacun. Quand un modèle traite le mot « avocat » dans « le client a consulté son avocat », l’attention pondère davantage les tokens « client » et « consulté » que « le ». C’est aussi pourquoi le format de l’entrée compte autant que son contenu [6, 7].
Une nuance importante mérite d’être posée ici, parce qu’elle conditionne directement la pratique : l’attention d’un modèle ne traite pas tous les emplacements de votre prompt à valeur égale. Un phénomène désormais bien documenté, parfois appelé context rot ou lost in the middle, montre que les transformeurs privilégient massivement le début de la requête (effet de primauté) et la fin du texte soumis (effet de récence). Une information cruciale enfouie au milieu d’une longue requête narrative voit sa probabilité d’être correctement prise en compte chuter de plus de 30 %, et sur des tâches analytiques complexes sollicitant le maximum de la fenêtre de contexte, jusqu’à 99 % de la fiabilité utile peut se perdre [26]. Conclusion pratique : plus le prompt est long et non balisé, plus l’attention s’égare. Le balisage explicite n’est pas une affectation typographique — c’est une carte que vous donnez au mécanisme d’attention pour qu’il ne se perde pas.
Voilà, en trois mécanismes, ce qu’est un LLM : un découpeur statistique, un prédicteur probabiliste, un orchestrateur d’attention. Aucun n’est anthropomorphe. Aucun ne « comprend » au sens humain du terme. Le débat académique sur ce point reste ouvert [8, 9]. Mais pour un dirigeant de PME qui doit décider comment former ses équipes, la conclusion pratique est nette : la machine répond mieux à ce qui ressemble à des instructions de programme qu’à ce qui ressemble à une conversation de café.
Pourquoi l’interface chat a faussé le débat
L’erreur d’analogie est née de l’interface, pas de la technologie. Avant ChatGPT, les modèles de langage étaient des API consommées par des développeurs, dans des scripts, avec des entrées formatées. En novembre 2022, OpenAI a fait deux choix de produit qui ont changé la perception collective : la fenêtre de chat, et le ton « assistant serviable ». Le premier crée l’attente d’une conversation. Le second crée l’illusion d’une intention.
La littérature en sciences cognitives décrit ce phénomène sous le terme d’anthropomorphisme. Les interfaces conversationnelles renforcent ce biais par la simulation du tour de parole, les délais de réponse artificiels, et le vocabulaire à la première personne (« je pense que… ») [10, 11]. Une revue récente parle d’« épée à double tranchant » : l’anthropomorphisme facilite l’adoption, mais il masque les différences cruciales entre humains et LLM, ce qui conduit à une sur-confiance dans les réponses et une mauvaise calibration des usages en entreprise [11].
Pour une PME, ce biais a un coût concret. Quand un dirigeant croit qu’il faut « bien parler à ChatGPT », il oriente ses formations vers la rhétorique de la requête : tournure polie, exemple d’« acte comme si tu étais un expert », promesses de récompense. Une partie de ces recettes a circulé massivement sur LinkedIn entre 2023 et 2025. Les études récentes montrent que la plupart n’apportent aucun gain mesurable de précision, et que certaines dégradent les performances [12].
Le tournant 2025-2026 : du « prompt » à l’« instruction »
Ce qui change en 2025-2026, c’est que les éditeurs eux-mêmes formalisent l’autre voie. Trois signaux convergent — et il faut les inscrire dans un cadre plus large. Le rapport DORA 2025 (Google Cloud), qui s’appuie sur près de 5 000 réponses de professionnels tech et plus de 100 heures d’entretiens qualitatifs, met en évidence une dissonance significative : alors que ~ 90 % des développeurs déclarent utiliser une forme d’assistance IA et que 80 % considèrent qu’elle augmente leur productivité individuelle, les indicateurs organisationnels de livraison restent souvent plats — gain individuel sans gain collectif systématique [27]. L’écart entre adoption et productivité réelle au niveau de l’organisation est l’indicateur le plus clair du problème de méthode.
Anthropic. La documentation officielle de Claude recommande explicitement l’usage de balises XML pour structurer les prompts. Le wording est sans équivoque : « Claude a été spécifiquement entraîné à prêter une attention particulière à votre structure » [13]. Le guide cite des cas d’usage : <instructions>, <context>, <documents> enveloppant chaque <document> indexé, <examples>, <thinking> et <answer> pour distinguer le raisonnement de la réponse.
OpenAI. Le guide GPT-5 est explicite : « GPT-5 interprète les prompts de manière littérale et exhaustive », et recommande « des spécifications XML structurées comme <[instruction]_spec> » pour améliorer le suivi d’instructions [14, 15]. Le modèle est tuné pour la précision : il fera exactement ce qui est écrit, sans interprétation libérale. Cela rend les instructions ambiguës plus coûteuses en hallucinations qu’auparavant.
Google. Le Prompting Guide officiel de Gemini fait la même recommandation : encadrer les instructions, les exemples et le contenu de référence par des balises ou des séparateurs explicites, parce que le modèle utilise ces frontières pour activer son attention sur la bonne portion du contexte [16].
Au-delà des éditeurs, la recherche académique a produit en 2024-2025 plusieurs travaux qui consolident ce constat. StructEval (arXiv 2505.20139, 2025) propose un benchmark complet de la capacité des LLM à produire des sorties structurées : les modèles de pointe atteignent en moyenne 75/100, et la qualité varie fortement selon le format demandé, ce qui implique que la spécification du format dans le prompt est un levier de performance à part entière [17]. Meaning Typed Prompting (arXiv 2410.18146, 2024) montre qu’une spécification typée et structurée des sorties améliore la fiabilité et réduit le coût d’inférence [18]. XML Prompting as Grammar-Constrained Interaction (arXiv 2509.08182, 2025) propose un cadre théorique : le balisage XML agit comme une contrainte de grammaire qui réduit l’espace des sorties possibles, et donc la variance — une démonstration formelle qu’un prompt structuré n’est pas un caprice esthétique, c’est une réduction d’entropie [19].
Côté gains chiffrés, plusieurs sources convergent — et il faut les nuancer pour éviter les sur-extrapolations. Les communications d’Anthropic et les analyses de praticiens rapportent qu’un balisage XML bien posé peut réduire les hallucinations jusqu’à 40 % sur certaines tâches [13]. Une étude publiée en 2025 dans npj Digital Medicine (PMC11039454) sur l’interprétation de guidelines hépatologiques (hépatite C) documente un saut d’exactitude de 43,0 % (GPT-4 Turbo seul) à 99,0 % avec un cadre RAG combiné à du prompt engineering structuré [20] — un résultat fort, mais propre à ce cas d’usage clinique précis ; la généralisation à toute tâche d’entreprise est à faire avec prudence. Sur la dimension sécurité, Anthropic publie fin 2025 que Claude Opus 4.5 réduit à ~1,4 % le taux d’injections de prompt réussies dans son benchmark d’agent navigateur sous nouveaux safeguards, contre ~10,8 % pour Claude Sonnet 4.5 sous anciens safeguards [21] — l’isolation par balisage entre instructions et données fait partie des défenses.
Le contre-argument honnête : quand le balisage n’est pas la réponse
Il faut le dire clairement : le balisage XML n’est pas une formule magique applicable partout. La rigueur intellectuelle impose de présenter le contre-argument tel qu’il existe dans la littérature.
Un benchmark publié en mai 2026 par Manish Ramavat a comparé, sur Claude Sonnet 4.5, des prompts d’extraction de 150 tokens en deux versions : prose plate et prose balisée XML. Résultat : la version XML coûte 31 % de tokens d’entrée en plus pour un écart d’exactitude négligeable de −1,2 point de pourcentage [22]. À 10 000 appels par jour avec ce type de prompt, l’overhead XML représente environ 515 $/an gaspillés sur Sonnet 4.5.
La conclusion du même auteur mérite d’être lue dans son entier : « Si vos prompts sont longs, complexes, multi-sections, ou traitent des entrées non fiables — utilisez XML. S’ils sont courts, clairs et templatés — passez-vous-en. » Wrapper un document de 10 000 tokens dans des balises XML coûte 4 tokens supplémentaires, mais permet à l’attention d’isoler proprement le document des instructions. Le rapport bénéfice/coût bascule donc en faveur du balisage dès que le contexte se complexifie.
Simon Willison, l’un des praticiens les plus suivis sur ces sujets, fait la même observation à un niveau plus large. Son étude récente (9 649 expériences sur 11 modèles et 4 formats — YAML, Markdown, JSON, TOON) montre qu’aucun format ne domine universellement, et que la familiarité du modèle avec le format compte autant que la structure elle-même : le format ultra-compact TOON, peu présent dans les corpus d’entraînement, fait paradoxalement perdre des tokens parce que le modèle « hésite » à le suivre [23].
La règle opérationnelle qui en sort, et qu’il faut tenir en tête, est donc nuancée : le balisage structuré s’impose dès que la tâche est complexe, le contexte étendu, les sources multiples, ou les entrées potentiellement non fiables. Sur les usages simples — résumer un courriel, reformuler un paragraphe — la prose claire suffit. Mais en entreprise, peu d’usages restent simples une fois passée la phase d’exploration.
Et si les modèles 2026 étaient devenus assez bons pour comprendre le langage naturel sans XML ?
C’est l’objection la plus légitime qu’un dirigeant peut formuler, et elle mérite une réponse directe. Oui, Claude Opus 4.7, GPT-5.5 et Gemini 3.1 Pro comprennent infiniment mieux le langage naturel que leurs prédécesseurs de 2023. Un prompt en prose libre, sur un cas simple, donnera très souvent une bonne réponse au premier essai.
Mais trois forces font que la discipline d’instruction structurée reste pertinente — et le devient même davantage avec ces modèles.
Premièrement, l’interprétation plus littérale. Les guides officiels GPT-5 et GPT-5.5 d’OpenAI le disent explicitement : ces modèles interprètent les prompts de manière « littérale et exhaustive ». Une instruction floue ne sera plus « adoucie » par le modèle ; elle sera exécutée à la lettre.
Deuxièmement, l’enjeu n’est plus une requête réussie, ce sont 10 000 requêtes reproductibles. En exploration solo, un prompt en prose libre marche neuf fois sur dix. En production, sur 10 000 appels par jour, le 10 % d’écart représente 1 000 sorties non conformes par jour — inacceptable pour un processus métier.
Troisièmement, le balisage structure aussi la pensée humaine. Une équipe qui ne sait pas formuler les quatre zones « rôle / contexte / instructions / format de sortie » ne sait pas non plus formuler clairement sa demande métier. La rigueur du format révèle la rigueur de la pensée.
Cela dit, le verdict d’ici 24 à 36 mois bougera. Si la prochaine génération de modèles internalise une compréhension native des intentions floues, la frontière se déplacera. La règle prudente : d’ici 18-24 mois, le balisage structuré est le standard ; au-delà, à rééval.
Pourquoi cela change tout pour une PME en 2026
Si la bonne pratique en 2026 n’est plus de « bien parler à l’IA » mais de la commander avec des instructions structurées, plusieurs décisions de dirigeant en découlent.
Premièrement, sur la formation des équipes. Une étude française de 2026 rapporte que moins de 12 % des salariés ont reçu une formation structurée au prompting, et que ceux qui en bénéficient produisent des résultats environ 40 % plus précis [24]. Mais la qualité de la formation compte plus que son existence. Une formation qui apprend à écrire de longues phrases polies, à promettre des récompenses, à « jouer un rôle » au modèle, sera obsolète en six mois. Une formation qui apprend à spécifier une tâche, structurer une consigne, baliser un contexte, définir un format de sortie est durable.
Deuxièmement, sur les gabarits de prompts utilisés en production. La pratique professionnelle en 2026 consiste à construire des bibliothèques de gabarits XML versionnés, partagés entre équipes, testés sur des jeux d’évaluation, audités lors des mises à jour de modèle. Cela ressemble beaucoup plus à de la gestion de code source qu’à de la rédaction.
Troisièmement, sur la gouvernance des agents autonomes. L’enjeu monte d’un cran dès que l’IA n’est plus consultée mais déléguée. Un agent autonome — qui appelle des outils, écrit des fichiers, envoie des emails — exécute un flot d’instructions composées en chaîne. Si les instructions sont conversationnelles, le moindre flou ouvre la porte à des comportements aberrants. Si elles sont structurées et balisées, l’agent reste sur ses rails [25].
Quatrièmement, sur le rapport au fournisseur. Une PME qui maîtrise la spécification structurée de ses tâches est moins captive du modèle. Un gabarit XML correctement écrit s’exécute, avec quelques ajustements, sur Claude, sur GPT-5, sur Gemini, voire sur des modèles locaux open source. La portabilité est un avantage stratégique sous-estimé.
Trois questions à poser dès cette semaine
Pour un dirigeant de PME qui lit cet article, voici les trois questions qui transforment le constat en action immédiate, à poser à votre DSI, votre référent IA ou votre prestataire :
- Avez-vous un inventaire des prompts critiques actuellement utilisés en production, et qui en est nommément responsable ? Si la réponse est « non » ou « tout le monde », il y a une dette de gouvernance prompt à ouvrir.
- À quand remonte le dernier test de non-régression sur les sorties de votre IA — c’est-à-dire la vérification, sur un jeu standardisé d’exemples, que les réponses restent conformes après une mise à jour de modèle ou de prompt ? Si la réponse est « jamais », vous êtes exposé aux dérives silencieuses.
- Si vous deviez migrer demain de Claude à GPT-5 ou inversement, combien de prompts de votre catalogue interne devriez-vous réécrire intégralement ? Si la réponse est « tous » ou « on ne sait pas », votre portabilité est faible.
Ces trois questions ne demandent ni outil ni budget. Elles révèlent le niveau de maturité IA réelle de l’organisation, indépendamment du nombre d’outils déployés.
Ce que recommande la Méthode Junyr™
La Méthode Junyr™ — méthodologie propriétaire de Croissance et Transitions, articulée autour de cinq niveaux de maturité IA — traite cette question dans le cadre de son niveau 2 (Industrialisation des cas d’usage) et son niveau 3 (Gouvernance opérationnelle). Trois pratiques sont posées comme socle.
1. Un gabarit minimum standardisé. Pour tout usage d’IA en production, on rédige le prompt en distinguant explicitement quatre zones : le rôle et la tâche, le contexte de référence, les instructions de méthode, le format de sortie attendu :
<role>Tu es un analyste senior chargé de…</role>
<contexte>
<document index="1">…</document>
<document index="2">…</document>
</contexte>
<instructions>
1. Vérifie d'abord la cohérence entre les documents
2. Identifie les points de divergence
3. Propose une synthèse en …
</instructions>
<format_sortie>
Réponse en français, structurée en trois sections,
avec citations [n] référencées aux documents.
</format_sortie>Cette structure tient en quelques dizaines de tokens supplémentaires. Sur un prompt long, elle est largement amortie. Sur un prompt court, on l’allège : c’est la règle 80/20 du balisage.
2. Une bibliothèque de gabarits versionnés. Les prompts critiques sont stockés dans un dépôt versionné, avec leurs jeux de tests, leur historique de modifications, leur responsable nommé. C’est la discipline du code applicatif. Cette bibliothèque s’organise autour d’une structure simple, parfois codifiée sous l’acronyme CARE : Contexte, Action attendue, Résultat, End-goal. Quatre processus de création coexistent en entreprise : pilotage par les experts métiers (SME-Driven) pour les usages juridiques et financiers ; participation ouverte (Crowdsourcing) pour les cas créatifs ; génération assistée par IA puis filtrage humain (AI-Generated) pour l’optimisation massive ; structuration par rôle (Role-Based) pour standardiser un département entier [28].
3. Un cadre de délégation pour les agents. Junyr Agents™, le produit phare de la suite Junyr opéré sur junyr.app, incarne cette discipline — délégation d’agents IA opérables, déclenchables et auditables par email via la couche Email Routing de Junyr Mail™. Chaque agent est défini par un gabarit d’instructions XML, ses outils sont limités à un périmètre explicite, ses sorties sont contraintes à un schéma.
Conclusion : commander, pas converser
L’industrie est en train de tourner une page. Le mot prompt survivra encore quelques années dans le vocabulaire courant. Mais en entreprise, en 2026, la pratique professionnelle s’aligne sur une discipline plus rigoureuse : on ne parle pas à l’IA, on la commande. Avec des instructions explicites, des contextes balisés, des formats de sortie spécifiés, des gabarits versionnés, et une gouvernance documentée. Le balisage structuré (XML, JSON ou délimiteurs explicites) est le standard de fait sur lequel les trois grands éditeurs convergent.
Pour une PME française qui veut tirer une valeur réelle de ses outils d’IA cette année, le levier le plus structurant n’est pas un meilleur modèle. C’est une discipline d’instruction. La fenêtre 2026 reste ouverte : 18 à 24 mois pour basculer d’une IA utilisée à une IA architecturée. Ce qui se joue n’est ni la peur ni l’urgence ; c’est la maîtrise. Et la maîtrise, comme toujours, commence par changer le bon mot — ici, remplacer parler par commander.
Questions fréquentes
Le prompt engineering est-il vraiment mort ?
Non. Le mot survit dans le vocabulaire courant et dans certaines fiches de poste. Mais la pratique professionnelle a basculé : on parle désormais d’« ingénierie du contexte » (context engineering) — englobant le balisage structuré, la gestion du contexte, la conception des gabarits et la gouvernance des prompts. Le « prompt engineering » au sens étroit cède la place à une discipline d’orchestration.
Faut-il vraiment utiliser XML partout ?
Non. La règle nuancée est : utilisez le balisage structuré (XML, JSON ou délimiteurs explicites) dès que la tâche est complexe, le contexte étendu, les sources multiples, ou les entrées potentiellement non fiables. Pour les usages simples, la prose claire suffit. Le benchmark Ramavat de mai 2026 documente que sur prompts courts (≈ 150 tokens), le balisage XML peut être un overhead inutile.
Quelle est la différence entre prompt engineering et context engineering ?
Le prompt engineering se concentre sur la formulation d’une requête donnée à un instant donné. Le context engineering englobe l’ensemble du remplissage de la fenêtre de contexte : description de tâche, exemples few-shot, résultats de récupération (RAG), données multimodales, outils disponibles, état, historique.
Mon équipe est non-tech. Faut-il les former à écrire du XML ?
Pas directement. Vous formez plutôt à spécifier une tâche, structurer une consigne, baliser un contexte, définir un format de sortie. Les gabarits XML sont ensuite portés par un référent IA, un développeur ou un consultant, et les équipes les remplissent, ne les rédigent pas à chaque fois.
Le balisage XML va-t-il vieillir avec les modèles 2027 ?
Probablement, en partie. Si les modèles internalisent davantage la compréhension des intentions floues, la frontière entre prose claire et balisage strict se déplacera. D’ici 18-24 mois, le balisage structuré est le standard ; au-delà, à rééval. Le bénéfice durable n’est pas l’XML en soi, c’est la discipline de spécification.
Le balisage XML remplace-t-il le RAG, le fine-tuning ou les system prompts ?
Non. Ils sont complémentaires. Le RAG injecte les données privées de l’entreprise dans le contexte ; le balisage XML les sépare proprement des instructions. Le fine-tuning ajuste le modèle ; le balisage structure l’instruction. Les system prompts modernes sont eux-mêmes du balisage structuré déguisé.
Pour aller plus loin
- Audit Méthode Junyr™ — Diagnostic IA Express : 90 minutes de visio pour évaluer votre niveau de maturité actuel — croissance-transitions.fr
- Junyr Agents™ : délégation d’agents IA pour PME, opérables et auditables par email — junyr.app
- Junyr Mail™ : messagerie professionnelle eIDAS — junyr-mail.com
Sources
- Andrej Karpathy, X, 25 juin 2025 — « +1 for "context engineering" over "prompt engineering" ». x.com/karpathy
- Addy Osmani, « Context Engineering: Bringing Engineering Discipline to Prompts », Substack, 2025. addyo.substack.com
- Gartner, Lead the Shift to Context Engineering as Prompt Engineering Fades (Report ID 6781234), 28 juillet 2025. gartner.com
- « LLM Fundamentals — Tokens, Attention & Transformers (2026) », MyEngineeringPath. myengineeringpath.dev
- « How LLMs Work », tutorialQ. tutorialq.com
- « What is an attention mechanism? », IBM. ibm.com
- Sebastian Raschka, « A Visual Guide to Attention Variants ». magazine.sebastianraschka.com
- arXiv 2503.08980, 2025. arxiv.org/abs/2503.08980
- Grzankowski, A., arXiv 2408.04666, 2024. arxiv.org/abs/2408.04666
- So, J. et al., « Beyond Anthropomorphism: a Spectrum of Interface Metaphors for LLMs », arXiv 2603.04613, 4 mars 2026. arxiv.org/abs/2603.04613
- « The Double-Edged Sword of Anthropomorphism in LLMs », PMC. pmc.ncbi.nlm.nih.gov
- « The $380 Million Prompt Engineering Lie », Towards AI, 2025. pub.towardsai.net
- Anthropic, « Use XML Tags to Structure Your Prompts », documentation officielle Claude. platform.claude.com
- OpenAI, GPT-5 Prompting Guide. developers.openai.com
- OpenAI, Prompt Guidance. developers.openai.com
- Google, Prompting Guide for Gemini API. ai.google.dev
- StructEval, arXiv 2505.20139, 2025. arxiv.org/abs/2505.20139
- Meaning Typed Prompting, arXiv 2410.18146, 2024. arxiv.org/abs/2410.18146
- Alpay F. & Alpay T., « XML Prompting as Grammar-Constrained Interaction », arXiv 2509.08182, 9 sept 2025. arxiv.org/abs/2509.08182
- So J. et al., « Optimization of hepatological clinical guidelines interpretation by large language models », npj Digital Medicine, 2024 (PMC11039454) — saut 43,0 % → 99,0 % avec RAG + prompt engineering structuré sur hépatite C. pmc.ncbi.nlm.nih.gov · nature.com
- Anthropic, Mitigating the risk of prompt injections in browser use, 2025 — Claude Opus 4.5 ramène à ~1,4 % le taux d’injections réussies (vs ~10,8 % Sonnet 4.5 sans nouveaux safeguards). anthropic.com · pymnts.com
- Manish Ramavat, « Benchmarking XML Delimiters in LLM Prompts », mai 2026. dev.to/manishramavat
- Simon Willison, « Structured Context Engineering for File-Native Agentic Systems », Feb 2026 — 9 649 expériences, 11 modèles, 4 formats. simonwillison.net
- Nerolia Formation, Prompt Engineering en français 2026. nerolia-formation.fr
- Simon Willison, « New prompt injection papers », 2025. simonw.substack.com
- Sur context rot / lost in the middle, cf. arXiv 2504.02732 « Why do LLMs attend to the first token? ». arxiv.org/abs/2504.02732
- DORA 2025 Report, Google Cloud — Près de 5 000 réponses, 100 h d’entretiens. cloud.google.com · faros.ai · dora.dev
- Modèle CARE et typologie SME-Driven / Crowdsourcing / AI-Generated / Role-Based — synthèse Gemini Deep Research 19 mai 2026 (rapport interne).
Paul-Antoine TUAL est AI Transformation Leader. Il dirige Croissance et Transitions (SAS) et opère la suite Junyr™ — Méthode Junyr™ (méthodologie), Junyr Agents™ (agents IA pour PME, junyr.app), Junyr Mail™ (messagerie eIDAS). Il accompagne les dirigeants d’ETI et de PME françaises dans leur transformation IA — diagnostic 90 minutes : croissance-transitions.fr.
