Vous demandez à un outil d’IA de rédiger un devis. D’abord, vous expliquez ce que vous vendez, comment vos prix sont construits, quelles conditions s’appliquent et pourquoi ce client-là a droit à une exception. Vous obtenez un texte correct. Demain, vous recommencez. Et votre collègue, qui a exactement le même besoin, repart chaque fois de zéro.
Ce n’est pas un bug étrange du logiciel. C’est lié à la façon dont l’IA fonctionne.
L’IA sait tout, sauf comment fonctionne votre entreprise
Un modèle de langage a lu pratiquement tout Internet. Ce qui n’y figure pas, c’est votre entreprise : vos processus, vos clients, ce que vous avez décidé en mars sur la stratégie. Tout ce qu’il doit savoir de votre situation, vous devez le lui fournir à chaque fois.
Ces informations, on les appelle le contexte. S’en occuper de façon délibérée, c’est le context engineering. Il y a deux ans, on parlait surtout de prompts : comment formuler sa question le plus habilement possible. On sait maintenant que la formulation ne détermine qu’une petite partie du résultat. Ce que vous fournissez pèse plus lourd que la façon dont vous le demandez.
Quatre choses utiles à savoir
Beaucoup d’inventions sont un problème de contexte. Quand une IA ne sait pas quelque chose, elle ne s’arrête pas. Elle complète avec ce qui paraît plausible. Donnez-lui le vrai contrat, la vraie grille tarifaire, le vrai dossier, et ce trou disparaît en grande partie. « L’IA invente n’importe quoi » veut souvent dire en pratique « nous ne lui avons pas donné les faits ».
Plus de contexte n’est pas automatiquement mieux. La tentation est grande de tout envoyer : le manuel complet, toute la boîte mail, chaque document qui a un rapport de près ou de loin. Ça ne marche pas. L’attention d’un modèle est limitée et inégalement répartie. Une information placée au milieu d’un long texte reçoit moins de poids, et les passages hors sujet distraient activement. Choisir ce que vous fournissez, c’est le vrai travail.
Le savoir de votre équipe n’est aujourd’hui exploitable nulle part. Demandez dans une entreprise comment se déroule exactement un processus, et vous obtiendrez quatre réponses. C’est dans la tête de trois collègues, dans une boîte mail partagée et dans un fichier Excel que plus personne n’ose toucher. Tant que c’est le cas, il n’y a pas grand-chose à fournir.
Ce que vous consignez s’accumule. Le contexte qui n’existe que dans une conversation disparaît avec elle. Le contexte consigné quelque part améliore chaque tentative suivante. Pour vous, pour vos collègues, et pour les outils que vous utiliserez l’an prochain et que vous ne connaissez pas encore.
Pourquoi un dossier plein de documents ne règle rien
Le premier réflexe est compréhensible : alors, mettons tout par écrit. Une procédure ici, un mode d’emploi là, une page de règles dans Notion.
Le problème, c’est que ces documents divergent. Ils décrivent le même processus sous des angles différents, avec des mots différents, écrits à des moments différents. Au bout d’un an, ils se contredisent et plus personne ne sait quelle version est la bonne. Pour un humain, c’est pénible. Pour un outil d’IA, c’est inutilisable, car il ne peut pas juger laquelle des trois descriptions est la bonne.
À cela s’ajoute un point souvent oublié : le contexte détermine aussi ce que vos systèmes ont le droit de voir. Quelles données clients peuvent se retrouver dans quelle conversation ? C’est un choix de conception, pas un détail technique. Et vous ne pouvez faire ce choix qu’une fois que vous avez rendu explicite ce qui est fourni exactement.
Une seule description au lieu de cent documents
Chez Tandem, nous travaillons donc avec un modèle de contexte : une seule description durable de la façon dont fonctionne votre entreprise, au lieu de documents épars qui vieillissent.
Cette description a trois couches. Les parcours : comment un processus se déroule du début à la fin, du point de vue de la personne qui le fait. Les événements : ce qui se passe réellement en chemin, un devis envoyé, une livraison planifiée, un dossier approuvé… Et les écrans : où les gens le voient et le modifient.
Le but n’est pas d’obtenir une belle documentation, même si c’est un plus. Le but est que les outils de développement IA puissent construire directement à partir de cette description. Le modèle est le contexte : un seul endroit qui dit comment votre entreprise est organisée, d’où vient votre logiciel et sur lequel s’appuient les outils d’IA. Si le processus change, vous modifiez le modèle. Sans un tel modèle, chaque prompt réinvente la façon dont fonctionne votre entreprise, et chaque fois un peu différemment.
Ce que vous pouvez en faire
Inutile de tout consigner d’un coup. Prenez un processus où l’IA intervient déjà, ou dans lequel vous voulez l’utiliser, et écrivez comment il se déroule vraiment. Pas comment il devrait se dérouler. C’est généralement la première fois que tout le monde voit la même version, et ça, c’est déjà un résultat.
Curieux de voir à quoi ça pourrait ressembler pour votre entreprise ? Envoyez-nous un message.
