Coûts de l’IA en marketing : le contexte coûte davantage que les licences et les jetons. Par où commencer

Quand nous regardons nos projets des derniers mois, une constante apparaît. Que nous construisions pour un client une équipe d’agents ou un système d’exploitation d’IA. Qu’il s’agisse d’IA en marketing ou d’optimiser une fonction commerciale. De loin, la majeure partie du temps et de l’énergie va à l’ingénierie du contexte.

C’est pareil dans nos processus internes. Parmi toutes les disciplines avec lesquelles nous travaillons, l’ingénierie du contexte est celle qui détermine, au final, la qualité du résultat. Dans six de nos onze cas clients, une base de connaissances curatée est l’ossature sur laquelle s’exécutent les agents.

Quel est le vrai coût de l’IA en entreprise ?

Ce rapport de forces est désormais étayé par des chiffres. Le 14 septembre, Bitkom a présenté sa nouvelle étude sur l’IA, menée auprès de 603 entreprises. La question: où se concentrent les principaux coûts pour les utilisateurs de l’IA ? L’infrastructure est citée par 51 %. La préparation des données propres par 50 %. L’intégration aux systèmes existants par 41 %. Licences et abonnements ? Seulement 21 %. La consommation de jetons, souvent débattue, n’est un poste majeur que pour 8 %.

• 51 % – L’infrastructure comme poste de coût majeur
• 50 % – La préparation des données internes
• 41 % – L’intégration aux systèmes existants
• 21 % – Licences et abonnements

Le président de Bitkom, Ralf Wintergerst, le résume ainsi : « Acheter une licence, c’est acquérir de l’IA, mais ce n’est pas encore changer quoi que ce soit. » Et il est encore plus précis pour les agents. Un agent qui exécute des actions a besoin de « données fiables, de systèmes connectés et de règles claires sur ce qu’il peut faire ou non ».

Qu’est-ce que l’ingénierie du contexte ?

L’ingénierie du contexte consiste à fournir à une IA, pour une tâche donnée, le bon savoir, les bonnes règles et les bons liens entre informations. Un modèle ne sait rien de votre entreprise. Il ne connaît ni votre marque, ni vos cibles, ni vos circuits de validation, ni la campagne qui n’a pas fonctionné au printemps.

Dans la plupart des organisations, ce savoir est éparpillé : PDF, anciennes présentations, fils d’e-mails et surtout mémoire des équipes. Une personne sait quel document est obsolète. Un agent ne le sait pas. La structuration, le classement propre et l’effort pour garder à jour ce savoir sont rarement budgétés au moment de planifier l’IA. C’est précisément là que se concentrent les coûts identifiés par l’étude.

Ce travail peut se mener par étapes. L’erreur la plus coûteuse est de faire l’inverse : acheter d’abord une plateforme, puis se demander quoi y mettre. C’est acheter des rayonnages pour une bibliothèque qui n’existe pas encore.

Étape 1 : Commencer par une tâche et un périmètre d’usage

L’ingénierie du contexte commence par la question suivante : quelle tâche un agent doit-il prendre en charge ? Plus c’est concret, mieux c’est. En marketing, cela peut être : produire des briefs de campagne pour une ligne de produits. Ou préparer des propositions commerciales pour une offre précise.

La tâche détermine quel savoir est nécessaire. Le reste reste dehors pour l’instant. Cela transforme un projet de données sans frontières en projet circonscrit. Nous procédons ainsi même dans de grandes organisations : partir de cas d’usage concrets et en déduire la structure à rebours. Le cadre se construit ensuite.

Un test utile : pouvez-vous décrire en deux phrases ce qui doit être livré à la fin et qui le valide ? Si non, la tâche est encore trop large.

Étape 2 : Déduire un graphe de connaissances ciblé

Avant toute migration, cartographiez les éléments de la tâche et leurs liens. C’est la forme la plus simple d’un graphe de connaissances : des nœuds et des relations.

Pour un brief de campagne, les nœuds sont par exemple la marque, le produit, la persona, le point de douleur, le message, le canal, le processus de validation et les campagnes passées avec leurs résultats. Les relations transforment le tout en savoir exploitable : la persona a un point de douleur. Le produit le résout. Le message s’adresse à la persona. Le canal l’atteint.

Ce croquis tient sur un tableau blanc et prend une demi-journée. Il montre immédiatement quelles informations existent et lesquelles manquent. Souvent, il y a vingt pages de brand book, mais pas de description des personas que tout le monde partage. Le projet data devient alors un projet de clarification. Un agent a besoin d’une réponse univoque là où des personnes ont jusqu’ici répondu, avec diplomatie, de façons différentes.

Étape 3 : Migrer le contexte pas à pas

On transforme maintenant le croquis en dépôt structuré. Et voici ce qui surprend souvent : au départ, vous n’avez pas besoin d’une infrastructure complexe. Des répertoires sur un lecteur partagé et des fichiers Markdown suffisent.

La transposition est directe. Chaque type de nœud devient un dossier : Personas, Produits, Messages, Campagnes. Chaque nœud devient un fichier. Les relations sont des liens entre fichiers. Le Markdown se lit et se modifie facilement par des personnes, les modèles le comprennent sans détour, et vous n’êtes lié à aucun produit.

Trois règles se sont imposées chez nous :

• Un fait n’existe qu’à un seul endroit. La description d’une persona existe une fois ; tous les autres fichiers y renvoient.
• Chaque fichier a un responsable et une date. Sinon, dans six mois, personne ne saura si le contenu est toujours valide.
• Les sources sont distillées. Le PDF de 40 pages est condensé à ce dont la tâche a besoin.

Notre propre Company Brain a commencé exactement ainsi : des dossiers sur un lecteur partagé, des fichiers Markdown, un fichier par sujet. Il fonctionne encore aujourd’hui sur cette base.

Notre Company Brain : démarrage avec des dossiers et du Markdown

Notre propre Company Brain a commencé exactement ainsi : des dossiers sur un lecteur partagé, des fichiers Markdown, un fichier par sujet.

La transposition est directe : chaque type de nœud devient un dossier. Chaque nœud devient un fichier. Les relations sont des liens entre les fichiers.

Le Markdown se lit et se modifie facilement par des personnes, les modèles le comprennent sans détour, et vous n’êtes lié à aucun produit. Il fonctionne encore aujourd’hui sur cette base.

Étape 4 : Des agents et des processus qui enrichissent le Company Brain

Quand le contexte de la première tâche est en place, l’agent reçoit sa mission. Il lit les fichiers nécessaires et produit le brief. C’est la partie visible. La plus importante est ce qui suit.

Nous l’avons appris nous-mêmes. D’anciens dossiers de marque, maintenus à la main, ont dépéri chez nous faute de boucles de feedback et de rituels, alors que la technique fonctionnait. D’où la nécessité d’instaurer des processus dès le départ. Les nouveaux enseignements issus des réunions atterrissent dans un dossier d’entrée et sont intégrés régulièrement. Si une personne corrige un résultat de l’agent, la correction retourne dans le fichier. Et un créneau hebdomadaire dédié a un seul objectif : repérer les contradictions et décider quelle information fait foi.

Une large part de cette maintenance peut être confiée à des workflows agentiques. La décision de pertinence reste humaine. Les règles correspondantes sont formalisées dans la gouvernance de l’IA, là où chaque agent peut les lire.

Vient ensuite une deuxième tâche. Elle réutilise une partie des mêmes nœuds. Les personas existent déjà, la marque aussi. Vous n’ajoutez que ce qui est nouveau. À chaque tâche, le Brain grandit et la suivante coûte moins cher.

1. Étape 1 : Tâche et périmètre d’usage L’ingénierie du contexte commence par définir la tâche que l’agent doit prendre en charge. Plus c’est concret, mieux c’est : par exemple des briefs de campagne pour une ligne de produits ou des offres pour un paquet de services défini. La tâche détermine le savoir nécessaire ; le reste reste dehors pour l’instant.
2. Étape 2 : Graphe de connaissances Avant toute migration, on trace les nœuds et les relations de la tâche. Pour un brief de campagne : marque, produit, persona, point de douleur, message, canal, processus de validation et campagnes passées. Le croquis révèle les informations manquantes et rend visibles les contradictions.
3. Étape 3 : Migrer le contexte Le croquis devient un dépôt avec dossiers et fichiers Markdown. Un fait n’existe qu’à un endroit, chaque fichier a un responsable et une date, les sources sont distillées. Les relations sont des liens entre fichiers.
4. Étape 4 : Agents et processus L’agent lit les fichiers nécessaires et produit le brief. Des boucles de feedback et des rituels garantissent l’intégration des nouveautés et l’arbitrage des contradictions. À chaque tâche, le Brain grandit et la suivante coûte moins cher.

Quand l’infrastructure doit monter en puissance

Les dossiers et le Markdown ont des limites. Quand de nombreux agents accèdent en parallèle. Quand les droits doivent être plus fins que « ce dossier, telle équipe ». Quand des données doivent être consommées en direct depuis d’autres systèmes, c’est-à-dire quand l’intégration IA commence réellement. Ou quand un Company Brain de référence doit primer sur des notes personnelles, afin que les contradictions ne retombent pas sur l’agent.

C’est alors le moment d’introduire des index de recherche, des bases de données et des interfaces. Nous avons évalué des outils de gestion des connaissances prêts à l’emploi. Techniquement, ils offrent beaucoup. Ce qui leur manque, c’est la gouvernance, la redevabilité et une couche de contexte transverse, autrement dit exactement ce que vous avez construit dans les trois premières étapes. Le graphe reste le même ; seul le socle de stockage gagne en performance.

L’infrastructure suit le périmètre fonctionnel. Dépenser d’emblée les 51 % évoqués par Bitkom, c’est payer pour une capacité dont aucune tâche n’a encore besoin.

Questions fréquentes sur l’ingénierie du contexte

Quelle différence entre prompt engineering et ingénierie du contexte ?

Un prompt décrit une requête individuelle. L’ingénierie du contexte garantit que chaque requête s’appuie sur un savoir vérifié et commun. Le prompt raccourcit, le résultat gagne en stabilité.

Ai-je besoin d’une base de données graphe pour un graphe de connaissances ?

Au départ, des dossiers comme types de nœuds, des fichiers Markdown comme nœuds et des liens comme relations suffisent. Cela porte les premières tâches. Une base de données devient pertinente quand le volume, les accès ou des données en temps réel l’exigent.

Qui est responsable de l’ingénierie du contexte dans l’entreprise ?

Une personne désignée par domaine de connaissances, soutenue par l’IT. L’ingénierie du contexte est une responsabilité managériale, car le contexte naît des décisions et des responsabilités. C’est un pilier de l’AI Enablement.

Ce que vous pouvez faire cette semaine

Bitkom recense 59 % des utilisateurs d’IA qui estiment ne pas exploiter le potentiel. Dans les projets que nous observons, cela tient presque toujours au contexte que le modèle n’a jamais reçu.

La première étape ne coûte que du temps : choisissez une tâche. Cartographiez les nœuds et les relations dont elle a besoin. Créez un fichier pour chaque nœud.

Quelle tâche, dans votre équipe, en profiterait en premier, et qui, chez vous, décide aujourd’hui du savoir de référence nécessaire ?