Pourquoi votre IA ne connaît pas votre entreprise
Posez à n'importe quel agent compétent une question sur votre propre entreprise et regardez ce qui se passe. Il répond avec assurance, sur le ton de quelqu'un qui sait, et il se trompe d'une façon qui prend plus de temps à repérer qu'un simple silence gêné. Pas parce que le modèle est faible. Parce que rien de ce qu'il peut atteindre ne contient la réponse.
C'est le problème qu'un company brain existe pour résoudre, et cela vaut la peine d'être précis, parce que « l'IA ne connaît pas nos affaires » recouvre en réalité trois échecs différents sous le même manteau. Ils ont des causes différentes et des remèdes différents, et une équipe qui les traite comme une seule chose achète en général le mauvais outil.
L'écart n'est pas le modèle
Le premier réflexe est de chercher un meilleur modèle, ou un fine-tuning. Les deux répondent à une question que personne n'a posée. Un modèle de pointe en sait déjà plus sur votre secteur que la plupart de vos nouvelles recrues n'en sauront dans un an. Ce qu'il ignore, c'est que votre tarif a changé en mars, que l'offre « Enterprise » du deck s'appelle autrement dans le système de facturation, que tel compte particulier est en escalade depuis un mois, et que la personne qui vous aurait dit les trois est partie en juin.
Rien de tout cela n'est du savoir au sens du modèle. C'est de l'état. Ça change, ça a une source, ça a une date, et ça vit dans des systèmes que le modèle n'a jamais rencontrés. Améliorer le modèle ne rapproche pas d'un millimètre.
Trois échecs, pas un seul
Il repart de zéro. Chaque conversation démarre à zéro. La personne au clavier recolle le même contexte qu'elle a recollé hier, et ce qu'elle oublie de coller est exactement ce sur quoi la réponse va se tromper. Multiplié par toute l'équipe, c'est une vraie taxe quotidienne que personne n'a jamais mise dans un budget.
Il devient obsolète. Les entreprises qui ont vu venir ce problème ont tout écrit. Puis le trimestre a tourné, trois processus ont changé, et le document censé tout régler est devenu un compte-rendu assuré de la façon dont les choses fonctionnaient avant — ce qui est pire que rien, parce que les gens continuent d'y croire. C'est structurel, pas un problème de discipline : garder un compte-rendu écrit à jour est un travail permanent sans échéance, ce qui en fait toujours la quatrième priorité de quelqu'un.
Il n'a jamais quitté la tête de personne. La plus grande part n'a jamais été écrite nulle part. C'est la vraie raison pour laquelle un deal est bloqué, l'exception qui s'applique à un seul client, l'étape que tout le monde sait sauter. Ça se transmet en travaillant à côté de quelqu'un, ce qui explique que ça ne survit pas à une réorganisation et ne se colle pas dans une fenêtre de chat.
| L'échec | À quoi ça ressemble | Pourquoi plus de documentation ne le résout pas |
|---|---|---|
| Repart de zéro | Le même briefing recollé en haut de chaque chat, par chaque personne, chaque jour | Le briefing est écrit de mémoire, donc il porte tout ce dont l'auteur se souvenait ce matin-là |
| Devient obsolète | Une page qui décrit le processus du trimestre dernier avec une assurance totale | La garder à jour est un travail permanent sans échéance, ce qui en fait la quatrième priorité de tout le monde |
| Jamais écrit | La vraie raison pour laquelle un deal est bloqué ; l'exception qui s'applique à un seul compte | Ça se transmet en travaillant aux côtés de quelqu'un. Il n'y a pas de document parce que personne n'a jamais eu de raison d'en écrire un |
Ces trois-là méritent d'être lus dans cet ordre, parce que chacun est l'excuse du précédent. Le contexte repart de zéro *parce qu'*il n'a jamais été écrit ; il n'a jamais été écrit *parce qu'*écrire n'est jamais resté vrai longtemps. Le troisième porte un nom en dehors du logiciel : le savoir tacite, celui qu'on comprend sans qu'il soit énoncé, et la raison pour laquelle une passation prend des mois plutôt qu'un après-midi.
Pourquoi c'est devenu urgent
Rien de tout cela n'est nouveau. La mémoire organisationnelle est étudiée depuis des décennies, et les entreprises fonctionnent sur un savoir éparpillé et des habitudes non documentées depuis qu'il existe des entreprises. Ça marchait parce que le mécanisme pour retrouver ce savoir était une personne qui en demandait à une autre. Ce mécanisme est lent, mais il est très bon : les gens savent à qui demander, ils nuancent quand ils ne sont pas sûrs, et ils disent « ça a changé le mois dernier ».
Ce qui a changé, c'est l'arrivée d'un second type de travailleur, qui ne peut pas se lever pour aller demander. Un agent n'a pas de collègue à qui se référer, ni l'instinct que quelque chose sent l'obsolète. Il répondra à partir de ce qu'on lui a donné, en pleine confiance, à chaque fois — le mode de défaillance que le domaine appelle hallucination, et la raison pour laquelle une réponse assurée mais fausse coûte plus cher qu'une absence de réponse. Un écart qu'une entreprise pouvait porter indéfiniment tant que seuls des humains travaillaient à partir de lui devient, dès que l'IA fait le travail, ce qui décide si le résultat est utilisable.
Que faire
Les trois échecs sont un seul problème vu sous trois angles, et ils ne se règlent pas en insistant davantage sur ce qui ne marche pas déjà : ni un meilleur modèle, ni un tour de plus de documentation, ni une règle disant à tout le monde d'écrire plus. Ils se règlent en dérivant le compte-rendu des systèmes qui détiennent déjà la preuve, et en le maintenant à jour comme une propriété du système plutôt que comme la quatrième priorité de quelqu'un.
En pratique, c'est un travail qui se rejoue tout seul : les retours d'appels transformés en tickets et docs chaque nuit, ou un brief du lundi qui rassemble l'usage produit, le pipeline et les retours clients en un seul rapport avant que l'équipe ne s'installe.
C'est tout l'argument pour construire quelque chose de délibéré plutôt que continuer à recoller. Une fois la forme de la réponse claire, la question suivante est ce qu'il faut pour en construire un, ce qui est comment construire un company brain. Si vous le comparez à un outil que vous payez déjà, commencez plutôt par un company brain comparé à ce que vous avez déjà.
Common questions
- Will a better model fix this?
- No. A frontier model already knows more about your industry than a new hire will after a year. What it does not know is that your pricing changed in March or that one account has been escalating for a month, because that is state living in your systems rather than knowledge in the model. A better model reasons better about whatever it was given; it does not get given more.
- Is this what fine-tuning is for?
- Fine-tuning changes how a model writes and reasons, not what it currently knows about your business. Company facts change weekly, and retraining on each change is neither practical nor reversible. The fix is to give the model somewhere current to read from at the moment of the question.
- We wrote everything down already. Why is it still wrong?
- Because writing it down once solves the first day and none of the days after it. A document describing a process is accurate until the process changes, which nobody flags, so it becomes a confident record of how things used to work and people keep trusting it. Staleness is the second of the three failures and is structural rather than a discipline problem.