Le prompt engineering est mort. Vive l’architecture de contexte.

Pendant deux ans, on a cherché la formule magique : le prompt parfait, ciselé mot à mot, gardé précieusement dans un fichier personnel. Ce prompt engineering artisanal a un défaut fatal : il ne passe pas à l’échelle. L’architecture de contexte le remplace — un système où le savoir de l’entreprise est chargé une fois pour toutes dans des contextes versionnés, des skills partagés et des garde-fous, au lieu d’être retapé à chaque conversation par chaque collaborateur.

La différence n’est pas cosmétique. Un prompt est une performance individuelle ; une architecture de contexte est un actif d’entreprise. L’un dépend du talent de son auteur et disparaît avec lui. L’autre fait produire de bons résultats à toute l’équipe, y compris à ceux qui n’ont jamais rien optimisé.

Pourquoi le prompt artisanal ne tient pas en entreprise

Faites l’inventaire chez vous. Les meilleurs prompts vivent dans des notes personnelles, des fils Slack, des mémoires individuelles. Trois personnes font trois versions de la même tâche avec trois niveaux de qualité. Quand l’auteur du bon prompt part, son savoir-faire part avec lui. Et quand le modèle évolue, personne ne sait quels prompts revalider.

Ce n’est pas un problème de compétence, c’est un problème de structure. Le prompt traite chaque conversation comme un début : tout réexpliquer, à chaque fois, en espérant ne rien oublier. Une entreprise ne peut pas fonctionner sur de la mémoire orale — l’IA non plus.

Le symptôme le plus coûteux est invisible : la variance. La même tâche, confiée à l’IA par deux collaborateurs, produit deux résultats de qualité incomparable — parce que tout dépend de ce que chacun a pensé à préciser. Aucun process d’entreprise ne tolère cette loterie ailleurs ; il n’y a pas de raison de la tolérer ici.

L’architecture de contexte, concrètement

L’architecture de contexte déplace l’effort : au lieu d’écrire mieux au moment de demander, on construit une fois ce que l’IA doit toujours savoir. Quatre couches, chacune répondant à une question précise :

• Les contextes métier : ce que Claude sait en permanence — vos produits, vos clients, vos conventions, votre ton. Écrits, versionnés, partagés ; plus jamais réexpliqués.
• Les skills : ce que Claude sait faire — des compétences packagées par département, avec un propriétaire, des tests et un numéro de version. Quand quelqu’un améliore un skill, toute l’équipe en profite.
• Les garde-fous : ce que Claude a le droit de faire — accès aux données, périmètres, validations obligatoires. Définis dans l’architecture, pas dans une charte.
• Le pilotage : ce que le système produit — adoption, temps gagné, qualité mesurée. Sans quoi rien ne s’améliore.

Le prompt n’a pas disparu : il a changé de propriétaire

Soyons précis : la formulation compte toujours. Mais elle a été déplacée hors des conversations quotidiennes, vers l’infrastructure. Les instructions soignées vivent désormais dans les contextes et les skills, écrites une fois par ceux qui connaissent le métier, testées, puis servies automatiquement à chaque usage.

L’utilisateur final, lui, parle normalement. « Prépare la réponse pour ce client » suffit, parce que le système sait déjà qui est le client, quel est le ton maison et ce qu’une bonne réponse contient. Le talent de formulation cesse d’être un prérequis pour chaque collaborateur ; il devient une propriété du système.

C’est le même mouvement que le développement logiciel a connu : on n’exige plus de chaque utilisateur qu’il sache coder pour profiter d’un logiciel. On n’exigera bientôt plus de chaque collaborateur qu’il sache « prompter » pour profiter de l’IA — à condition que quelqu’un ait construit le système en dessous.

Comment faire la bascule ?

Commencez par récolter : demandez à chaque équipe ses trois meilleurs prompts — ceux qui produisent réellement de la valeur aujourd’hui. C’est votre matière première. Transformez-les ensuite en actifs : le savoir permanent part dans les contextes, les procédures répétables deviennent des skills, les règles implicites deviennent des garde-fous explicites.

Puis outillez la boucle d’amélioration : chaque sortie décevante doit pouvoir corriger le contexte ou le skill concerné, pour tout le monde et définitivement. C’est cette boucle qui distingue une architecture vivante d’une bibliothèque de prompts rangée dans un wiki.

C’est précisément ce que nous construisons avec le Harness d’entreprise — la couche d’orchestration entre Claude et vos process — dans le Programme Autonomie Claude : la bascule de l’artisanat individuel au système d’entreprise, en trois semaines, avec vos équipes.