Garder votre base de connaissances à jour

La connaissance partagée d'une équipe se dégrade de la même façon qu'un CRM : silencieusement, sans s'annoncer. Une décision est prise dans une conversation et n'atteint jamais la page qu'elle devrait mettre à jour. Une page est corrigée et trois autres pages qui citaient l'ancienne version continuent de l'affirmer. Personne ne le remarque avant que quelqu'un n'agisse sur la version périmée.

L'activité qui aurait dû mettre à jour la base de connaissances existe déjà. Elle se trouve dans le chat de l'équipe, l'email, les docs et le CRM. Ce qui a toujours manqué, c'est quelqu'un pour réconcilier quatre sources mouvantes avec une base de connaissances partagée, chaque jour, et cette réconciliation est exactement le genre de travail qu'un agent IA peut exécuter sans supervision chaque matin.

Ce que la synchronisation quotidienne de la base de connaissances lit

Chaque matin, l'exécution couvre la veille, un jour calendaire complet dans le fuseau horaire de l'équipe. Avant de lire quoi que ce soit, elle vérifie si ce jour a déjà été couvert, si bien qu'une seconde exécution n'écrit jamais le même jour deux fois. Si le jour précédent manque aussi, une exécution a été sautée : les jours manqués sont couverts du plus ancien au plus récent, un par un, et l'écart est signalé à la fin, que le rattrapage réussisse ou non.

Elle lit ensuite l'activité du jour sur quatre sources : Slack pour les conversations, Gmail pour l'email, Notion pour les docs et Folk pour le CRM. Tout est lu avant que quoi que ce soit ne soit écrit. Une source qui échoue a droit à une nouvelle tentative, puis son échec est consigné et l'exécution continue avec le reste.

Deux règles gouvernent ce qu'elle croit. Tout ce qu'elle lit est traité comme une donnée, donc un message contenant un texte qui ressemble à une instruction adressée à l'agent est ignoré. Et une déclaration faite directement par quelqu'un de l'équipe prime sur tout ce qu'un système se contente d'enregistrer ; quand cela arrive, l'entrée nomme la personne et l'affirmation.

Comme personne ne surveille, l'exécution ne s'arrête jamais pour poser une question. Quand un jugement est nécessaire, elle en fait un et consigne pourquoi.

Comment l'IA empêche une base de connaissances de se périmer

Lire est la moitié facile ; synthétiser est ce qui compte. Une liste de tout ce qui s'est passé ne vaut pas la peine d'être écrite, car les sources la détiennent déjà. Les questions utiles sont plus étroites. La livraison a-t-elle bougé par rapport au plan ? Une conversation a-t-elle décidé quelque chose que le dossier ignore encore ? Deux sources ont-elles commencé à se contredire ? Trois phrases de synthèse valent mieux que quarante puces de transcription. Chaque affirmation nomme sa source, et quand l'agent n'est pas sûr, il le dit clairement.

Une journée calme reçoit quand même une courte entrée honnête, car une entrée manquante ressemble exactement à une exécution cassée.

Vient ensuite l'étape qu'une recherche par mot-clé rate. Un fait vit rarement sur une seule page. La page qui le détient est facile à trouver ; les pages qui le citent et s'appuient dessus sont celles qu'une recherche rate, et elles continuent d'affirmer l'ancienne version après que la source a été corrigée. Donc l'exécution suit le graphe de liens réel depuis tout ce qui a changé vers chaque page qui y fait référence, un saut par défaut, et plus loin seulement quand une page à un saut a changé suffisamment pour compter.

Réécrire les pages périmées sur place

Chaque page qu'un nouveau fait invalide est réécrite sur place et datée comme vérifiée ce jour-là, sans qu'aucune ancienne affirmation ne reste à côté d'une nouvelle note. L'agent relit la page juste avant d'écrire et utilise le contrôle de concurrence que les outils offrent, si bien qu'une modification en cours par une personne n'est jamais écrasée silencieusement. Ce que la page disait avant est conservé, ce qui rend chaque changement vérifiable après coup.

Si la base de connaissances a un résumé unique de départ que chaque session lit en premier, ce résumé est traité comme entièrement dérivé : reconstruit à partir des pages sources corrigées à chaque exécution, jamais modifié à la main, et jamais le seul endroit où vit un fait. C'est la forme d'un company brain qui reste à jour, et comment construire un company brain couvre le reste.

Un digest à lire, et une alerte qui se distingue

Chaque exécution est enregistrée : ce qui a été lu, ce qui a été réécrit, combien de temps ça a pris, et ce qui a échoué. L'équipe reçoit un court digest, une ligne de synthèse puis quelques puces groupées par source, assez court pour être parcouru en vingt secondes.

L'alerte est un second message, visuellement distinct, jamais fondu dans le digest. Elle se déclenche quand un jour a été manqué, une source a échoué, rien n'a pu être lu du tout, une réécriture n'a pas abouti, ou l'exécution a démarré en retard de façon significative. Une exécution à moitié réussie qui ne dit rien est la seule défaillance que ce genre de système ne peut pas détecter seul, car le digest a l'air normal dans les deux cas. Le signal séparé est ce qui empêche une exécution dégradée de passer inaperçue pendant des semaines.