Pourquoi le Prompt Engineering ne suffit pas pour construire des systèmes avec l'IA

Dans les premières années de l’IA générative, le Prompt Engineering est apparu comme la discipline phare. L’émergence des grands modèles de langage (LLM) a ouvert la voie à une nouvelle façon d’interagir avec la technologie : il n’était plus nécessaire de programmer, il suffisait de « parler » à la machine. Des équipes du monde entier ont commencé à expérimenter avec des prompts, ajustant les instructions pour obtenir des réponses plus utiles, précises ou créatives. L’enthousiasme était palpable : pour la première fois, la barrière d’entrée à l’IA semblait basse et le retour, immédiat.

Le Prompt Engineering est devenu la solution universelle pour tout défi lié à l’IA générative. Des rôles d’« ingénieur prompt » ont émergé et les hackathons internes dédiés à la recherche du prompt parfait ont proliféré. Les organisations, avides de résultats rapides, ont investi dans la création de bibliothèques de prompts et dans la formation d’équipes spécialisées. Le message était clair : celui qui maîtriserait l’art du prompt dominerait l’IA.

Cette étape initiale a été marquée par un état d’esprit d’expérimentation et de prototypage. Les équipes pouvaient itérer rapidement, tester des variantes et partager leurs découvertes dans des canaux internes. La connaissance était tacite, tribale, et son transfert dépendait de la proximité et de la communication informelle. Le succès se mesurait en améliorations incrémentales : un meilleur prompt pouvait réduire les erreurs, accroître la pertinence des réponses ou débloquer de nouvelles capacités du modèle.

Cependant, cette approche avait une limite inhérente : l’optimisation locale. Chaque équipe, chaque projet, chaque expert développait son propre répertoire de prompts, mais la connaissance était rarement systématisée. L’organisation accumulait une « prompt debt » sans s’en rendre compte : une dette invisible de connaissance non documentée, difficile à transférer et encore plus difficile à passer à l’échelle.

Pourquoi cela a fonctionné initialement

Le Prompt Engineering a fonctionné car il résolvait un problème réel et urgent : comment traduire les besoins humains en instructions compréhensibles pour un modèle statistique. La courbe d’apprentissage était rapide, le coût d’entrée faible et les résultats, dans de nombreux cas, surprenants. Pour les prototypes, l’expérimentation et les tâches limitées, il suffisait d’itérer sur le prompt pour améliorer la sortie.

Dans les projets pilotes, des équipes ont obtenu des améliorations notables simplement en affinant la formulation des prompts. La personnalisation était immédiate et le contrôle, tangible. Dans ce scénario, l’absence de processus formels ou de documentation structurée n’était pas un obstacle : la connaissance tacite et la créativité individuelle suffisaient pour avancer.

Le Prompt Engineering offrait également un sentiment de contrôle dans un environnement très incertain. Lorsque les modèles échouaient, la solution était « d’améliorer le prompt ». Cet état d’esprit, bien qu’utile en phase exploratoire, a généré une fausse impression de progrès durable. Les organisations ont confondu l’optimisation de l’interaction avec l’optimisation du système.

Les limites du Prompt Engineering

À mesure que l’IA s’intégrait dans des systèmes plus complexes et critiques, les limites du Prompt Engineering sont devenues évidentes. Optimiser les prompts améliorait des interactions ponctuelles, mais ne résolvait pas les problèmes systémiques. Les résultats étaient incohérents d’une équipe à l’autre, difficiles à maintenir et à transférer, et dépendaient trop d’experts individuels.

Les organisations ont commencé à collectionner les prompts comme s’il s’agissait d’actifs stratégiques, mais elles ont rapidement découvert que sans contexte, sans versioning ni traçabilité, la bibliothèque de prompts devenait ingérable. Les « experts en prompts » sont devenus des goulots d’étranglement et le transfert de connaissance était lent et fragile. Les erreurs récurrentes étaient résolues en modifiant le prompt, et non en améliorant le système ou la documentation.

Ce phénomène a donné naissance à ce que nous appelons chez Archwise la Prompt Debt : l’accumulation de prompts non documentés, non versionnés et dépendants d’une connaissance tacite. Comme toute dette technique, la Prompt Debt génère des frictions, des erreurs et des reprises, et limite la capacité de l’organisation à passer à l’échelle et à soutenir ses initiatives en IA.

L’évolution vers RAG et le Context Engineering

Le saut suivant a été l’adoption du RAG (Retrieval-Augmented Generation). Les organisations, réalisant que les prompts seuls ne suffisaient pas, ont commencé à connecter les modèles à des sources de données et à des documents internes. Le RAG résolvait une partie du problème : il permettait de mettre à jour et de personnaliser les réponses, mais introduisait de nouveaux défis de qualité des données, de versioning et de contexte fragmenté.

L’attente était qu’en fournissant plus de données, les modèles seraient plus utiles et précis. Cependant, la réalité fut plus complexe. L’intégration du RAG nécessitait une architecture robuste, des processus de curation des données et des mécanismes de contrôle de version. De nombreuses organisations ont sous-estimé la difficulté de maintenir la cohérence et la qualité du contexte fourni.

Le saut conceptuel est venu avec le Context Engineering. Ici, l’accent se déplace de l’optimisation de prompts individuels vers la conception de systèmes et de processus permettant de capturer, structurer et partager un contexte explicite, tant pour les humains que pour l’IA. Le contexte cesse d’être un sous-produit et devient une infrastructure critique, au même niveau que le code ou les données.

Le Context Engineering implique d’investir dans une documentation vivante, un architecture.md, une gouvernance robuste et des processus de transfert de connaissance. Les organisations qui franchissent ce cap obtiennent des résultats plus cohérents, évolutifs et durables. L’intégration des nouveaux arrivants s’accélère, le transfert de connaissance est systématisé et la maintenabilité du système s’améliore radicalement.

La dernière étape de cette évolution est celle des systèmes augmentés par l’IA (AI-Augmented Systems). Ici, l’IA n’est pas un ajout, mais un composant natif de l’architecture d’entreprise. Le contexte est traité comme une infrastructure : il est capturé, versionné, audité et distribué de manière systématique. La gouvernance devient proactive et l’organisation peut passer à l’échelle l’adoption de l’IA sans perdre le contrôle ni la qualité.

Prompt Engineering vs Context Engineering

La différence fondamentale est une question d’échelle et d’ambition. Le Prompt Engineering optimise les interactions : il permet d’affiner la communication avec le modèle, mais ses bénéfices sont locaux et fragiles. Le Context Engineering optimise les systèmes : il transforme l’organisation, permettant à la connaissance de circuler, d’être maintenue et exploitée à grande échelle.

Intégration (Onboarding)

Avec le Prompt Engineering, l’intégration dépend de la transmission orale et la courbe d’apprentissage est abrupte. Les nouveaux membres doivent apprendre des astuces et des modèles de prompts, ce qui génère une dépendance aux experts et ralentit l’intégration. Avec le Context Engineering, l’intégration s’appuie sur une documentation vivante, un architecture.md et des systèmes de transfert de connaissance, permettant une intégration rapide et autonome.

Transfert de connaissance

Le transfert de connaissance basé sur les prompts est fragile et peu évolutif. Chaque expert développe son propre répertoire et l’organisation dépend de la mémoire collective. Avec le Context Engineering, la connaissance est capturée, structurée et partagée de manière systématique, réduisant la dépendance aux individus et facilitant la continuité opérationnelle.

Documentation et architecture.md

Dans le modèle du Prompt Engineering, la documentation est souvent réactive et fragmentaire. Les prompts sont documentés, tout au plus, dans des wikis ou des dépôts dispersés. Dans le Context Engineering, la documentation est vivante, centralisée et liée à architecture.md, qui agit comme une source de vérité pour les humains et les systèmes. Cela permet la traçabilité, le versioning et l’amélioration continue.

Gouvernance

La gouvernance des prompts a tendance à être bureaucratique et peu efficace : revues, approbations et contrôles qui ne résolvent pas le problème de fond. Dans le Context Engineering, la gouvernance est proactive et basée sur des principes : on définit des standards, on audite le contexte et on favorise l’amélioration continue.

Maintenabilité et évolutivité organisationnelle

Le Prompt Engineering est facile à démarrer mais difficile à maintenir. La dette de prompts augmente et l’organisation perd la visibilité sur ce qui fonctionne et pourquoi. Le Context Engineering nécessite un investissement initial plus important, mais permet de faire évoluer l’IA de manière durable, avec des systèmes résilients et adaptatifs.

Un tableau comparatif le résume :

Le compromis est clair : le Prompt Engineering est rapide et peu coûteux pour commencer, mais ne passe pas à l’échelle. Le Context Engineering nécessite investissement et discipline, mais multiplie la valeur et la durabilité de l’IA dans l’organisation.

Cas d’échec

Cas 1 : Bibliothèque de prompts sans contexte

Situation initiale : Une entreprise technologique crée une « bibliothèque de prompts » centralisée pour toutes ses équipes de développement, espérant accélérer l’adoption de l’IA et réduire les doublons d’efforts.
Attentes : On s’attend à ce que les équipes réutilisent les prompts existants et améliorent la qualité des solutions.
Mise en œuvre : On rassemble des centaines de prompts dans un dépôt partagé, mais sans documenter le contexte, les hypothèses ni les cas d’usage.
Problèmes rencontrés : Les équipes continuent à générer des prompts ad hoc car la bibliothèque n’inclut pas d’exemples d’utilisation ni de contexte pertinent. Les doublons et la confusion augmentent.
Conséquences : Résultats incohérents, perte de temps et frustration au sein des équipes.
Enseignements : Sans contexte ni documentation vivante, une bibliothèque de prompts n’est qu’une collection de recettes déconnectées.

Cas 2 : Les experts en prompts comme goulots d’étranglement

Situation initiale : Une organisation financière recrute des « experts en prompts » pour chaque domaine critique, espérant accélérer l’intégration de l’IA dans les processus clés.
Attentes : On attend des experts qu’ils élèvent le niveau des équipes et transfèrent les bonnes pratiques.
Mise en œuvre : Les experts développent des prompts avancés et conseillent les équipes, mais ne systématisent ni ne documentent la connaissance.
Problèmes rencontrés : Lorsqu’un expert part, l’équipe perd en capacité et les erreurs se répètent. La dépendance aux individus devient insoutenable.
Conséquences : Perte de continuité, erreurs récurrentes et ralentissement de l’innovation.
Enseignements : Le transfert de connaissance doit être systémique, pas individuel.

Cas 3 : Gouvernance bureaucratique des prompts

Situation initiale : Une entreprise multinationale met en place un processus de « gouvernance des prompts » avec des revues et des approbations formelles pour chaque nouveau prompt.
Attentes : On espère améliorer la qualité et la traçabilité des prompts.
Mise en œuvre : On établit des comités et des flux d’approbation, mais on ne s’attaque pas à la racine du problème : l’absence de contexte structuré et de documentation vivante.
Problèmes rencontrés : Le processus devient bureaucratique, lent et n’améliore pas la qualité des résultats.
Conséquences : Les équipes évitent le processus formel et reviennent à des pratiques ad hoc.
Enseignements : La gouvernance doit se concentrer sur le contexte et l’architecture, pas seulement sur le contrôle des prompts.

Cas de succès

Cas 1 : Intégration accélérée grâce à architecture.md

Situation initiale : Une entreprise de conseil technologique fait face à des coûts d’intégration élevés et à des erreurs récurrentes dans les projets d’IA.
Attentes : Réduire le temps d’intégration et améliorer la qualité des livrables.
Mise en œuvre : Adoption d’architecture.md comme document vivant, centralisant le contexte, les décisions et les apprentissages clés.
Problèmes rencontrés : Nécessite discipline et changements culturels, mais l’équipe s’adapte progressivement.
Conséquences : Le temps d’intégration est réduit de semaines à jours, et les erreurs diminuent notablement.
Enseignements : La documentation vivante et le contexte partagé sont des multiplicateurs de productivité et de qualité.

Cas 2 : Transfert de connaissance systématisé

Situation initiale : Une équipe de développement travaille sur de multiples projets d’IA avec des résultats incohérents.
Attentes : Obtenir des résultats homogènes et transférer les apprentissages entre les projets.
Mise en œuvre : Systématisation de la capture et du transfert de connaissance via des playbooks, des sessions d’intégration structurées et une documentation vivante.
Problèmes rencontrés : Initialement, résistance au changement et effort supplémentaire pour la documentation.
Conséquences : Résultats cohérents, moins de reprises et une plus grande satisfaction de l’équipe.
Enseignements : La systématisation du contexte et du transfert de connaissance est essentielle pour la capacité à passer à l’échelle.

Cas 3 : Gouvernance proactive et contexte comme infrastructure

Situation initiale : Une organisation enterprise cherche à passer à l’échelle l’adoption de l’IA sans perdre le contrôle ni la qualité.
Attentes : Maintenir la cohérence et la traçabilité dans tous les systèmes d’IA.
Mise en œuvre : Mise en place d’une gouvernance basée sur des principes, en auditant le contexte et en favorisant l’amélioration continue. Le contexte est traité comme une infrastructure critique, avec des processus de versioning et d’audit.
Problèmes rencontrés : Nécessite investissement et leadership soutenu.
Conséquences : L’organisation fait évoluer l’IA de manière durable, avec des systèmes résilients et adaptatifs.
Enseignements : Le contexte comme infrastructure est le fondement de l’IA d’entreprise durable.

Le contexte comme infrastructure (section développée)

Dans la plupart des organisations, le contexte est invisible : il vit dans la tête des experts, dans des documents dispersés ou dans des conversations informelles. Cette invisibilité est le plus grand obstacle pour faire évoluer l’IA de manière durable.

Traiter le contexte comme une infrastructure implique :

• Le capturer de manière systématique dans architecture.md et une documentation vivante.
• Le versionner et l’auditer au même titre que le code ou les données.
• L’intégrer dans les processus d’intégration, de transfert de connaissance et de gouvernance.
• Le rendre accessible à la fois aux humains et aux systèmes d’IA, via des API, des bases de connaissances et des outils collaboratifs.

Le contexte comme infrastructure permet :

• L’évolutivité : de nouvelles équipes et de nouveaux systèmes peuvent accéder à la connaissance pertinente sans dépendre d’experts individuels.
• La maintenabilité : les changements dans le contexte se propagent de manière contrôlée et auditable.
• La résilience : l’organisation ne dépend pas d’une mémoire tribale ni de héros, mais de systèmes robustes.
• L’innovation : l’IA peut exploiter le contexte explicite pour générer des solutions plus pertinentes et alignées sur les objectifs métier.

Les organisations AI-Ready traitent le contexte comme un actif stratégique, en investissant dans sa capture, sa maintenance et sa distribution. C’est la véritable frontière de l’IA d’entreprise.

Concepts propres à Archwise

Prompt Debt

La Prompt Debt est l’accumulation de prompts non documentés, non versionnés et dépendants d’une connaissance tacite. Comme la dette technique, elle limite la capacité à passer à l’échelle, génère des erreurs et des reprises, et entrave le transfert de connaissance. La seule façon de réduire la Prompt Debt est d’investir dans une documentation vivante, le versioning et des processus de révision systématique.

Optimisation locale vs optimisation système

Optimiser des prompts individuels peut améliorer les résultats locaux, mais seule l’optimisation systémique — via le contexte, l’architecture et la documentation — produit des améliorations durables et transférables. Les organisations qui restent dans l’optimisation locale finissent par se retrouver piégées dans des cycles d’ajustement sans progrès réel.

Cadre pratique : Knowledge Transfer Pipeline et modèle de maturité du Context Engineering

Archwise propose un pipeline de transfert de connaissance qui va de la capture du contexte dans architecture.md, en passant par la documentation vivante, jusqu’à l’intégration dans les systèmes d’IA. Le modèle de maturité du Context Engineering permet de diagnostiquer le niveau d’une organisation et de définir la feuille de route pour évoluer de prompts isolés vers des systèmes AI-Ready.

Conclusion

La plupart des organisations pensent avoir un problème de prompts. En réalité, elles ont un problème de contexte. Le Prompt Engineering est utile et nécessaire, mais pas suffisant pour construire des systèmes d’IA robustes et durables.

L’avenir de l’IA d’entreprise dépend du passage du Prompt Engineering au Context Engineering : optimiser les systèmes, pas seulement les interactions. Cela nécessite du leadership, des investissements et une vision systémique de l’architecture, de la documentation et du transfert de connaissance.

Questions pour le lecteur :

• Votre organisation investit-elle davantage dans l’optimisation des prompts que dans l’amélioration du contexte disponible pour les humains et l’IA ?
• Quel pourcentage des erreurs et des reprises serait résolu en améliorant la documentation et le contexte, plutôt qu’en affinant les prompts ?
• Avez-vous une stratégie pour réduire la Prompt Debt et évoluer vers le Context Engineering ?

Appel à l’action :
Évaluez la stratégie IA de votre organisation. Investissez dans le contexte, l’architecture et le transfert de connaissance. Le véritable multiplicateur de résultats réside dans l’ingénierie du contexte.