Le context engineering marketing décide ce qu'un modèle d'IA lit avant d'écrire pour votre marque, le charge par du code et vérifie le brouillon par rapport au même matériau. Comment il fonctionne, ce qu'il coûte et où il s'arrête.
Le context engineering appliqué au marketing consiste à décider quels faits, règles, exemples et limites un modèle d'IA lit avant de rédiger un contenu marketing pour une marque, à les charger par du code plutôt que par une instruction, et à vérifier chaque brouillon par rapport à ces mêmes éléments. Il fait de l'IA générative, collaboratrice imprévisible, un partenaire de création dont l'équipe contrôle les données d'entrée.
Le context engineering, ou ingénierie du contexte, est la discipline qui fait de l'IA générative, collaboratrice imprévisible, un partenaire de création dont vous contrôlez les données d'entrée. Appliqué au marketing, il décide quels faits, règles, exemples et limites un modèle lit avant de rédiger une annonce, un e-mail ou une page d'atterrissage pour votre marque, et il vérifie le brouillon par rapport à ces mêmes éléments avant toute publication. Le terme s'est répandu parmi les équipes qui construisent des agents d'IA, et les équipes marketing rencontrent aujourd'hui le même problème de l'autre côté, dans les brouillons que leurs assistants leur rendent.
Le prompt engineering travaille sur l'instruction, la phrase qui dit quoi écrire. Le context engineering travaille sur tout ce que le modèle lit à côté de cette instruction : les affirmations approuvées sur votre produit, les mots que votre marque n'utilise jamais, le prix actuel, deux exemples d'une annonce qui a fonctionné, la règle selon laquelle un nombre de clients doit être daté. Un prompt bien écrit ne peut pas fournir un fait que le modèle n'a jamais reçu, et c'est pourquoi les équipes qui perfectionnent leurs prompts passent encore leur temps de relecture à corriger les mêmes erreurs.
Un modèle écrit sur votre entreprise à partir de deux sources seulement, ce que lui donne la demande et ce qu'il a absorbé pendant son entraînement. Pour une entreprise connue, cet entraînement est large et daté, et pour une plus petite, il est presque vide. Lorsque le bon fait manque, le modèle produit quelque chose de plausible, et le cas le plus net est la preuve chiffrée : demandez une annonce avec une preuve forte et un chiffre apparaît, parce qu'un chiffre est ce à quoi ressemble une preuve forte.
Pour le mesurer, nous avons construit un exemple complet à partir des documents publics d'une société de logiciels cotée. Un premier brouillon simulé a arrondi le nombre de clients à « 300'000+ » et situé l'entreprise dans « 140 pays ». Les sources indiquaient 306'446 clients au 30 juin 2026 et plus de 135 pays. Les deux erreurs passeraient une lecture rapide, et seule une vérification par rapport au fichier de preuves les a détectées.
La même cause produit trois autres corrections que les équipes marketing font chaque semaine. Sans règles de ton écrites et sans exemples associés, chaque brouillon ressemble à la marque moyenne du modèle. Un produit renommé depuis le dernier brand book, ou un prix modifié le mois dernier, survit dans la source que le modèle a absorbée. Et les règles qui n'existent que dans la tête de quelqu'un, comme les affirmations qui exigent une relecture juridique ou la personne qui approuve une annonce payante, ne peuvent pas plus être suivies par un modèle que par un nouveau collègue.
La première solution habituelle consiste à coller le brand book dans le prompt, et elle se heurte à trois limites. La première est le coût : dans notre exemple, le contexte de marque complet représentait environ 36'000 tokens et les règles de tâches partagées 22'000 de plus, si bien que tout envoyer coûte environ 58'000 tokens par demande, alors que le paquet construit pour une seule annonce LinkedIn atteignait environ 10'100 tokens, soit environ 83 pour cent de moins, tout en contenant deux exemples d'annonces approuvées. La deuxième est l'attention, parce qu'un modèle qui lit un document de 30 pages n'a aucun moyen de savoir que la politique des affirmations prime sur un exemple de slogan en page 22. La troisième est la preuve : avec un dossier joint, personne ne peut dire ensuite quelle version d'un document le modèle a réellement lue.
Le context engineering appliqué au marketing répond à ces trois limites par quelques règles qui préviennent chacune une défaillance. Chaque fait se trouve dans un seul fichier, de sorte qu'un prix corrigé ne peut pas survivre ailleurs sous son ancienne forme. Chaque énoncé porte un statut, approuvé, référence, brouillon, hypothèse, proposé ou obsolète, et seuls les contenus approuvés et de référence peuvent étayer une affirmation dans un texte externe, ce qui permet à une équipe de commencer avec des hypothèses étiquetées sans qu'aucune n'atteigne une annonce comme un fait. Chaque affirmation cite la phrase dont elle provient, avec sa source et la date à laquelle elle a été lue.
Le chargement et la vérification s'exécutent en code plutôt que sous forme d'instructions au modèle. Une demande est classée, le code sélectionne les cinq ou dix fichiers dont la tâche a besoin, jusqu'à un seul produit et aux affirmations qui le concernent, et consigne chaque fichier avec son chemin, sa version et son empreinte SHA-256. Le brouillon est ensuite vérifié par rapport aux mêmes fichiers pour les limites de caractères, les mots interdits, l'orthographe des noms, le statut des affirmations et les chiffres, et une personne approuve tout ce qui quitte l'entreprise. Une instruction qui demande à un modèle de lire la charte de marque dépend de ce que le modèle le fasse, alors que du code qui place la charte dans le prompt et vérifie le résultat n'en dépend pas.
Le context engineering supprime les erreurs dues à une information manquante ou non étiquetée, et il s'arrête là. Il ne rend pas une offre faible convaincante, et il ne remplace pas quelqu'un qui connaît le client. Dans notre exemple, un brouillon qui avait passé toutes les vérifications du code obtenait encore 3 sur 5 en pertinence pour l'audience, parce que le persona pour lequel il était écrit avait été construit à partir de documents publics. Seuls des entretiens et des données CRM corrigent cela, et un bon système signale donc la lacune comme une question ouverte plutôt que d'écrire autour.
Vous pouvez mesurer en un après-midi la distance qui sépare votre équipe de cette pratique. Prenez les dix derniers brouillons d'IA que votre équipe a corrigés et comptez combien de corrections portaient sur des faits, des noms ou des prix que le modèle n'avait jamais reçus. Choisissez ensuite une affirmation approuvée, comme un nombre de clients, et trouvez tous les endroits où elle figure : si la réponse dépasse un fichier, les copies divergeront. Enfin, ouvrez un contenu publié et essayez de nommer la version du document que le modèle a lue au moment de le rédiger.
Si la plupart des corrections portent sur des faits manquants, la solution se trouve dans le contexte plutôt que dans le prompt ou le modèle. Le même raisonnement vaut pour toute équipe qui confie de la rédaction à un assistant, de l'aide à la vente aux réponses types du support, parce que chacune rencontre le même écart entre ce que sait le modèle et ce que l'entreprise a approuvé. Nous avons construit Torke Context pour combler cet écart dans les équipes marketing, et la page des engagements expose les règles qu'il suit.
Chaque réponse se suffit à elle-même : vous pouvez la transmettre à un collègue, et un assistant interrogé sur la même question peut la citer telle quelle.
Le prompt engineering travaille sur l'instruction qui dit quoi écrire. Le context engineering travaille sur tout ce que le modèle lit à côté, comme les affirmations approuvées, les règles de vocabulaire, les prix et les exemples, ainsi que sur le code qui charge ces éléments et vérifie le brouillon.
Cela coûte plus cher, cela ne donne au modèle aucun moyen de savoir quelle règle prime sur quelle autre, et personne ne peut prouver ensuite quelle version le modèle a lue. Dans l'exemple complet de Torke, un contexte de marque entier coûtait environ 58'000 tokens par demande, contre environ 10'100 pour un paquet construit pour une seule annonce LinkedIn.
Non. Il supprime les erreurs dues à une information manquante ou non étiquetée. Une offre faible reste faible, et un persona construit sans entretiens clients produit toujours des brouillons qui manquent leur audience.
Dites-nous ce que vend votre équipe, qui l'achète et où les affaires cessent d'avancer. Vous recevrez une réponse écrite indiquant quelle façon de travailler vous convient, ou si un Diagnostic a du sens, et si aucun des deux ne convient, la raison.