Le context engineering : la compétence IA que personne n’enseigne

Tu n’as pas besoin d’une IA « plus intelligente » pour tirer un meilleur travail de l’IA. La plupart du temps, il te faut le même modèle, avec une chose qu’il ne reçoit presque jamais : le bon contexte.

Quand on me dit « l’IA, ça n’a pas marché pour moi », ça veut généralement dire : ça a marché une fois, puis elle s’est mise à deviner. Elle a écrit quelque chose qui avait l’air juste, mais inutilisable. Elle a fait gagner dix minutes, puis coûté une heure de nettoyage. Ce n’est pas un problème d’intelligence. C’est un problème de contexte.

Pourquoi les outils d’IA paraissent magiques… jusqu’à ce qu’ils déçoivent

La première fois que tu utilises un outil d’IA, tu as l’impression de tricher. Tu demandes un résumé, tu obtiens une réponse propre. Tu demandes un premier jet, tu obtiens quelque chose de cohérent. Puis tu essaies de l’utiliser pour du vrai travail, avec de vraies contraintes, et ça commence à déraper.

Elle oublie la décision que tu as prise la semaine dernière. Elle ne connaît pas le forfait réel de ton client. Elle propose une procédure qui ignore tes règles de conformité. Elle rédige un email qui casse ton ton de marque. Elle « aide » à faire le compte rendu d’une réunion mais rate la seule action qui compte vraiment.

Et le pire, c’est qu’elle échoue souvent avec assurance. Tu n’as pas de message d’erreur. Tu as un résultat plausible.

Voilà le piège : on juge l’IA sur l’intelligence qu’elle semble avoir, pas sur le peu de choses qu’on a dû corriger.

Context engineering vs prompt engineering (la distinction qui compte)

Le prompt engineering, c’est l’art d’écrire de meilleures instructions. C’est utile, et ça ne va pas disparaître. Mais ce n’est qu’une partie du vrai problème.

Le context engineering, c’est tout ce qui détermine ce que le modèle voit avant de répondre. Pas seulement le prompt, mais l’ensemble de l’entrée : règles stables, documents pertinents, état actuel, décisions passées, résultats d’outils et contraintes. C’est la différence entre donner à quelqu’un une demande d’une ligne et lui donner le dossier, la politique, le calendrier et la définition de « terminé ».

Si le prompt engineering, c’est la façon de formuler la demande, le context engineering, c’est la façon d’emballer la réalité.

Les quatre briques qui décident si l’IA t’aide ou te freine

La plupart des échecs de « productivité IA » viennent de l’absence d’une de ces quatre catégories de contexte. Tu peux avoir un modèle brillant et obtenir quand même n’importe quoi s’il en manque une.

Les instructions : les règles qui empêchent le modèle d’improviser

Les instructions, ce sont les garde-fous. Elles définissent le rôle, le ton, les contraintes et ce à quoi ressemble un bon résultat.

Si tu as déjà reçu une réponse techniquement juste mais inutile, il te manquait sans doute des instructions comme : le format voulu, le niveau de détail, ce que tu considères comme inacceptable, ou les sources sur lesquelles elle doit s’appuyer.

En langage ops : c’est là que tu encodes ta définition de « terminé ». Si l’IA ne sait pas ce que « terminé » veut dire dans ton entreprise, elle continuera de livrer de « jolis brouillons » qui créent du travail à refaire.

Les connaissances : les faits que l’IA ne doit pas avoir le droit de deviner

Les connaissances, c’est la matière première : procédures, docs internes, spécifications produit, pages de tarifs, notes stratégiques, comptes rendus de réunion, conversations clients, décisions passées.

Sans connaissances, le modèle n’a que deux options : dire « je ne sais pas » ou deviner. La plupart des outils le laissent deviner.

C’est pour ça que les assistants IA génériques sont excellents pour le travail générique et s’effondrent sur le travail propre à ton entreprise. Ton business, c’est surtout des cas limites, des exceptions et des « on fait comme ça à cause de cet incident en mars ». Ce n’est pas dans le modèle. C’est à toi de le fournir.

La mémoire et l’état : ce qui est vrai maintenant (et ce qui doit rester cohérent)

Il y a une énorme différence entre les « connaissances » et « l’état ». Les connaissances, c’est la référence. L’état, c’est la réalité du moment : le projet en cours, ce que tu as déjà décidé, ce qui bloque, ce que le client vient de dire, les priorités de la semaine.

Si tu veux qu’un assistant IA se comporte comme un assistant, il a besoin de continuité. Sinon, chaque demande repart de zéro et tu passes ton temps à te réexpliquer.

En pratique, c’est sur l’état que la plupart des gens perdent du temps. Ils génèrent un compte rendu de réunion, recopient à la main les actions dans leur gestionnaire de tâches, puis briefent de nouveau l’IA le lendemain parce qu’elle n’a pas retenu le plan.

Les outils : la différence entre « a l’air juste » et « est juste »

Les outils permettent au modèle d’aller chercher la vérité au lieu de l’inventer.

Si l’IA peut consulter la dernière fiche CRM, elle n’a pas besoin d’halluciner le statut du compte. Si elle peut lire l’agenda, elle n’a pas à deviner tes disponibilités. Si elle peut interroger ta documentation, elle n’a pas à broder sur le fonctionnement de ton onboarding. Si elle peut inspecter un repo ou un ticket, elle n’a pas à faire semblant de comprendre le code.

C’est là que l’assistant cesse d’être un générateur de texte et devient un travailleur. Pas parce qu’il est plus « agentique », mais parce qu’il a accès aux mêmes systèmes que toi pour faire le travail.

Le RAG est une chaîne d’approvisionnement en contexte, pas une case à cocher

La génération augmentée par la recherche (RAG) est l’une des idées les plus importantes de l’IA appliquée : au lieu de compter sur ce que le modèle « se rappelle » de son entraînement, tu récupères les documents pertinents et tu les injectes dans le contexte pour que le résultat soit ancré dans le réel.

Mais voici ce que beaucoup ratent : le RAG est une chaîne d’approvisionnement. Si tu fournis des entrées de mauvaise qualité, tu obtiens des sorties de mauvaise qualité, juste plus vite.

L’erreur classique, c’est de croire que plus de contexte, c’est toujours mieux. C’est faux. Entasser dix documents dans le prompt ne rend pas le modèle plus précis ; ça le rend souvent plus confus. Tu ne veux pas un déversement de contexte. Tu veux un paquet choisi et pertinent.

La qualité l’emporte sur la quantité. La clarté l’emporte sur le volume. Le but de la recherche n’est pas d’impressionner le modèle avec tout ce que tu sais. C’est de supprimer l’ambiguïté.

Exemples de fondateur : là où les trous de contexte créent du travail caché

Soyons douloureusement concrets, parce que le « contexte » peut sembler abstrait jusqu’à ce que tu le voies brûler des heures.

Procédures et workflows ops

Tu demandes à l’IA d’écrire une procédure d’onboarding client. Elle produit un joli document. Puis ton équipe doit le réécrire parce qu’il ignore les vraies étapes : la validation interne, le circuit des exceptions tarifaires, l’email de conformité, le passage de relais à l’équipe success.

Cette réécriture n’est pas un problème d’écriture. C’est un problème de connaissances manquantes. L’IA n’a jamais vu tes vraies notes d’onboarding, les trois derniers post-mortems ni la checklist actuelle.

Des comptes rendus de réunion qui ne se transforment pas en exécution

Tu résumes une réunion et tu obtiens un compte rendu correct. Mais rien ne se passe ensuite. Les tâches ne sont pas créées. Les responsables ne sont pas désignés. Les échéances ne sont pas planifiées. Le compte rendu vit dans un document et y meurt.

C’est un problème d’état et d’outils. Le modèle doit savoir à quel projet ça se rattache, quel est le plan existant, et il doit pouvoir écrire les tâches là où ton équipe travaille vraiment.

CRM et relances commerciales

Tu demandes à l’IA de rédiger un email de relance. Elle écrit quelque chose de sympathique. Elle propose aussi par erreur une fonctionnalité que tu n’as pas, utilise le mauvais nom de forfait et mentionne un « essai gratuit » que le client n’a jamais demandé.

Il manque le contexte CRM et il manque les contraintes. Tu veux un système où l’IA récupère la fiche du compte, les notes du dernier appel, le forfait et la prochaine étape exacte que tu as convenue avec lui. Ensuite seulement, elle rédige.

Le chaos de l’agenda et des rendez-vous

Tu demandes à l’IA de « trouver un créneau la semaine prochaine ». Elle propose des horaires où tu es déjà pris, oublie ton jour de déplacement et se trompe de fuseau horaire.

C’est un problème d’outils. Sans accès à l’agenda, elle fait de la fiction.

Code et travail produit

Les gens adorent l’IA pour des bouts de code. Puis ils l’essaient dans un vrai produit, et les suggestions ignorent l’architecture, les conventions, les cas limites et les contraintes qui vivent dans le repo et dans les tickets.

Encore une fois : le contexte. Un assistant de code qui ne connaît pas le repo, c’est une autocomplétion sûre d’elle. Utile parfois. Dangereuse quand le système est complexe.

L’avenir : mieux emballer le contexte, pas seulement des modèles plus gros

Les modèles vont continuer à progresser. Les fenêtres de contexte vont continuer à s’agrandir. Mais le plus gros gain de productivité ne consiste pas à attendre le prochain modèle.

Il consiste à emballer ton travail pour qu’une IA puisse vraiment opérer à l’intérieur.

Ça veut dire que tes instructions sont explicites, tes connaissances accessibles, ton état tenu à jour et tes outils connectés. Ça veut dire arrêter de traiter l’IA comme une zone de texte magique et commencer à la traiter comme un système dont les entrées se conçoivent avec le même soin que l’onboarding d’une nouvelle recrue.

Une fois que tu fais ça, quelque chose change. L’IA arrête de deviner. Le volume de corrections chute. Ton équipe arrête de « tester des prompts » et commence à livrer.

C’est ça, le context engineering. Et c’est la compétence IA que personne n’enseigne, parce que ce n’est pas une astuce. C’est de l’infrastructure.