Chargement de la page…
Ouverture de Compta-Pilot…
Chargement de la page…
La réunification des idées — d'où vient la pensée, où mène le chemin
Cette application compte aujourd'hui près de cent cinquante écrans, une soixantaine de moteurs, une dizaine de connecteurs et un agent qui parle. À ce volume, même celui qui l'a conçue peine à l'expliquer en une phrase — et un système qu'on ne sait plus expliquer est un système qu'on ne maîtrise plus. Cette page existe pour ça : réunifier les idées. Elle dit d'où vient la pensée (une question posée à la profession, des auteurs relus, une norme confrontée), ce qui a été réellement construit — preuves et compteurs à l'appui, angles morts compris —, le principe qui tient tout (chaque brique vaut seule, chaque raccordement démultiplie), et où mène le chemin : une relation client d'un niveau que ni un logiciel de production, ni une IA générique ne peuvent atteindre.
Elle se lit d'un trait ou par chapitre, chaque module cité est cliquable, et chaque affirmation sur l'app a été vérifiée dans le code ou en base avant d'être écrite. Ce qui relève du cas illustratif du mémoire est marqué comme tel — cette page ne raconte jamais du faux vécu.
D'où vient cette application — et pourquoi elle n'est pas un outil de production de plus.
Tout part d'une question déposée devant la profession le 8 mai 2026, dans la notice d'un mémoire d'expertise comptable — sujet agréé le 20 mai 2026 :
« Comment le cabinet d'expertise comptable peut-il transformer la connaissance née de la relation client en actif durable en mobilisant conjointement le knowledge management et l'intelligence artificielle ? »
Chaque mot de cette question a été pesé, et chaque mot commande un pan de l'application. La connaissance née de la relation client : pas la doctrine fiscale, pas la documentation interne — ce que le cabinet apprend en travaillant avec ses clients, et qui vit aujourd'hui dans la tête d'un collaborateur. En actif durable : quelque chose qui reste quand la personne part, qui se valorise avec le temps, qui appartient au cabinet. Conjointement : ni le knowledge management seul (la profession a essayé pendant vingt-cinq ans, le chapitre 2 raconte pourquoi elle a échoué), ni l'intelligence artificielle seule (une IA sans connaissance du cabinet produit la même réponse pour tout le monde — zéro différenciation).
La notice en donne une formulation courte, qui est devenue le principe de conception de chaque écran :
« Le collaborateur ne documente pas. Il travaille. Le système apprend. »
C'est une phrase à prendre au pied de la lettre. Elle interdit le formulaire de capitalisation, le champ « leçon apprise » à remplir le vendredi soir, la base documentaire qu'on alimente par devoir. Si une fonctionnalité de cette application demande au collaborateur un effort de documentation qui ne fait pas partie de son travail, elle trahit la question fondatrice — c'est le premier critère de toute revue de conception.
La question n'est pas née dans un livre. Elle est née d'un constat que la page Dossier vivant raconte en détail : un jour, on a demandé à notre propre application que fait ce client ? — elle tenait 64 000 écritures de lui, six exercices, sa banque, ses salariés, et elle a répondu par un champ vide. Nos outils captaient tout et ne synthétisaient rien. Chaque connecteur remplissait consciencieusement son silo ; le seul endroit où tout se recoupait était la tête du collaborateur.
Ce constat, un cabinet peut le faire sur n'importe quel outil du marché : le logiciel de production connaît les écritures, la GED connaît les documents, la messagerie connaît les échanges — et personne ne connaît le client. La donnée est là ; la connaissance n'y est pas. La différence entre les deux est exactement ce que cette application construit.
Compta-Pilot n'est pas un outil de production comptable de plus, et n'a jamais cherché à l'être. La production (saisie, rapprochement, collecte) appartient aux plateformes qui la font bien — Pennylane, Odoo — et l'application s'y connecte au lieu de les concurrencer. Ce qu'elle est : le dossier permanent vivant du cabinet — la couche d'intelligence qui agrège toute la donnée client (compta, juridique, échanges, documents, historique) et la fait monter en valeur le long d'une échelle que le chapitre 2 fondera théoriquement :
Le mémoire nomme cette plateforme « BA-Pilot » — un nom de plume, du nom du ba de Nonaka, l'espace où la connaissance se crée. La réalité derrière le nom de plume, c'est cette application : le mémoire la décrit, l'application l'incarne, et chacun des deux corrige l'autre. Quand une promesse du mémoire n'est pas tenue par le code, elle est listée au chapitre 7 — pas maquillée.
Un système qui ne s'explique pas ne se vend pas, ne se transmet pas, ne s'audite pas. Cette page est le test permanent : si un module ne trouve pas sa place dans ce récit — s'il ne sert ni le référentiel, ni la connaissance, ni la relation, ni le jugement au point d'usage — c'est le module qu'il faut interroger, pas le récit.
Ce que disent les auteurs du KM, ce que la profession a raté, ce que l'IA change.
Le knowledge management n'a pas été inventé pour ce projet. Cinq lignées d'auteurs, relues à la source pendant la préparation du mémoire, forment une chaîne qui se lit d'une traite : Polanyi établit qu'il existe un savoir tacite (le praticien agit correctement sans pouvoir énoncer la règle qu'il suit — le senior qui « sent » le dossier) ; Nonaka montre qu'on peut l'externaliser (la spirale SECI : socialisation, externalisation, combinaison, internalisation) ; Nonaka et Konno disent où (le ba, l'espace partagé où la connaissance se crée — hors de son contexte, une connaissance redevient de la simple information) ; Wenger dit par qui (la communauté de pratique et ses trois pieds : engagement mutuel, entreprise commune, répertoire partagé) ; Davenport et Prusak puis Ermine expliquent pourquoi ça vaut — la connaissance est un actif, et un actif qui obéit à une équation.
« K = I × S × C — une connaissance est de l'information qui prend une signification donnée dans un contexte donné. »
Cette équation est la loi physique de toute l'application, et il faut la lire comme une multiplication, pas comme une addition. L'information (I), tout le monde l'a : les chiffres d'une balance se copient, un article du BOFiP est public. La signification (S) et le contexte (C) — l'histoire du dossier, les décisions passées du cabinet, le profil de ce dirigeant — ne s'achètent nulle part : ils s'accumulent. Vos chiffres sont une information ; reliés à l'histoire du dossier et au secteur, ils deviennent une connaissance qui éclaire une décision. L'avantage d'un cabinet tient dans le S et le C qu'il est seul à détenir — et le chapitre 4 montrera que chaque brique de l'application existe pour faire croître l'un de ces deux facteurs.
Une dernière filiation mérite d'être nommée parce qu'elle est à double face : la méthode MASK d'Ermine et son « livre de connaissances ». L'intention est conservée — fixer la doctrine d'un domaine dans un objet transmissible : c'est exactement ce qu'est une compétence cabinet dans la Matière grise. L'outillage, lui, est le repoussoir assumé : un ingénieur des connaissances rare, des projets au long cours et des budgets que les cas documentés par Saulais & Ermine (2021) chiffrent en centaines de milliers d'euros. Le KM d'avant demandait des ontologies et des spécialistes ; le nôtre tient dans un fichier en langage naturel qu'une IA aide à écrire et qu'un sachant signe.
La profession comptable n'a pas découvert le sujet hier. Quatre mémoires d'expertise comptable se succèdent sur vingt-cinq ans — Fouillé (2000), Monnet (2008), Jacquot-Constans (2021), Ott (2023) — et leur convergence est le fait le plus lourd du dossier : le diagnostic est posé depuis l'an 2000, et il n'a jamais été résolu.
« La gestion des connaissances n'est pas un nouveau concept marketing visant à installer un intranet supplémentaire au sein de l'entreprise. […] le moteur de la gestion des connaissances est l'être humain, l'informatique ne traitant par définition que de l'information. »
Monnet durcit le propos huit ans plus tard contre l'illusion documentaire (« une approche managériale et non technologique » — la GED n'est pas le KM) et documente déjà les symptômes que tout cabinet reconnaît : le temps perdu à chercher, les erreurs répétées par ignorance, et le partage « un tant soit peu qualifié de perte de temps ». Jacquot-Constans (2021) le reprend sous l'angle des compétences et chiffre le terrain : les cabinets de moins de cinquante collaborateurs représentent 83 % des effectifs du secteur. Ott (2023) prouve sur le secteur des hôtels-cafés-restaurants qu'une veille outillée produit du chiffre d'affaires de conseil — et reste limité à la veille.
Si le diagnostic était juste depuis vingt-cinq ans, pourquoi rien n'a tenu ? Trois obstacles, cumulés :
Dès 2000, Fouillé citait une étude Arthur Andersen : 80 % des dirigeants se disaient conscients de l'importance de la gestion des connaissances. Vingt-cinq ans plus tard, le déploiement effectif reste marginal. Ce n'est pas la nouveauté du sujet qui fait obstacle — c'est qu'aucune économie du geste n'avait jamais fonctionné. Toute l'architecture de cette application découle de ce constat : si le geste de capitalisation coûte quelque chose au collaborateur, il ne sera pas fait.
En 2018, la discipline s'est donné une norme internationale : ISO 30401, « Systèmes de management des connaissances — Exigences ». Elle définit la connaissance comme « le capital, personnel ou organisationnel, permettant des décisions et une action efficace en contexte » (§ 3.25) — définition qui recoupe mot pour mot l'équation d'Ermine — et pose huit principes directeurs dont un, le principe f), est le pivot de tout ce projet :
« Les connaissances ne sont pas gérées en direct ; le management des connaissances est centré sur le management de l'environnement de travail dans lequel les connaissances sont développées et appliquées. »
Ce principe justifie l'architecture entière : Compta-Pilot n'est pas une base documentaire qu'on alimente, c'est un environnement de travail (dossiers, échanges, visios, mails, contrôles) construit pour que la connaissance s'y dépose en travaillant. La norme sert ici de grammaire de conception — chaque module sait quelle exigence il sert, et la page La norme raconte d'où elle vient — jamais de certification : l'application ne se dit pas « conforme ISO 30401 », elle se dit « construite sur ISO 30401, en trajectoire de conformité mesurée », et le chapitre 3 montre les compteurs, y compris les rouges.
Ce choix d'humilité n'est pas une posture. Il vient d'un avertissement précis du livre blanc Ourouk :
« Il existe un risque qu'une organisation, après avoir lu la norme ISO 30401, constate qu'elle fait déjà beaucoup de tout cela et qu'elle est conforme alors que son approche du KM n'est pas suffisamment exigeante. »
La parade retenue : la norme ne se lit jamais seule, elle se confronte aux usages constatés en base. Un curseur de conformité ne se déclare pas, il se prouve — et quand aucune douleur réelle ne justifie de construire pour une clause, on inscrit au registre une réponse datée (« besoin non avéré, revu au trimestre ») plutôt qu'une fonctionnalité de façade.
Un dernier point que la norme offre et que peu de lecteurs remarquent : son annexe B adosse explicitement le management des connaissances à la gestion de la relation client. Le sujet même de cette application — transformer la connaissance née de la relation client — n'est pas une lecture libre de la norme ; c'est son terrain d'application désigné. Ce pont normatif est revendiqué ici, noir sur blanc.
Entre 2023 et 2026, l'intelligence artificielle générative a atteint le niveau de fiabilité qui change l'économie du problème. La thèse du mémoire tient en deux propositions indissociables — la co-catalyse :
La gestion des connaissances rend l'intelligence artificielle utile. Faute d'une connaissance métier structurée, les modèles produisent des réponses plausibles mais peu fiables — l'étude State of AI in Business 2025 du MIT documente qu'une majorité écrasante des projets d'IA générative en entreprise n'atteignent pas leurs objectifs. La cause est cognitive, pas technologique. Le KM n'est pas un complément à l'IA : il en est la condition de fonctionnement. Un cabinet qui s'abonne à un chatbot obtient la même réponse que n'importe quel autre cabinet — zéro différenciation. Un cabinet dont l'IA lit ses positions signées, son historique de dossiers et le contexte de ses clients obtient une réponse que personne d'autre ne peut produire.
L'intelligence artificielle rend la gestion des connaissances possible. Le verrou de vingt-cinq ans — le coût de l'ingénieur des connaissances — tombe : le sachant décrit son métier dans une conversation, l'assistant structure le récit, propose la formalisation, soumet le résultat aux pairs. Ce qui exigeait six mois d'un consultant senior tient en quelques jours. La captation des savoirs cesse d'être un investissement réservé aux grandes structures pour devenir un acte ordinaire du travail quotidien.
« La discipline que la profession a eu raison d'abandonner en 2005 est la même discipline qu'elle a raison de reprendre en 2026 — parce que l'obstacle qui la rendait impraticable est tombé. »
Le diagnostic de Fouillé reste vrai en 2026 : le moteur est l'être humain. Trois activités demeurent purement humaines et deviennent même plus critiques — la gouvernance (qui valide une doctrine), l'arbitrage (quand deux seniors se contredisent, l'IA expose les divergences, elle ne tranche pas) et la responsabilité (l'expert-comptable signe ; l'agent ne signe pas — l'asymétrie est juridique, pas technique). Et l'ordre des travaux est impératif : « le pari que la technologie compenserait le manque de structuration reste une utopie » (Ourouk, 2023, p. 79). La base de connaissance bien faite d'abord ; l'IA ensuite. C'est le principe unitaire du chapitre 4.
La norme clause par clause, et la réponse vérifiée de l'app — réussites et angles morts.
Nonaka distingue quatre ba — quatre espaces où opèrent les quatre conversions de la connaissance : on socialise autour de la machine à café, on externalise en atelier, on combine en salle de documentation, on internalise au poste de travail. Quatre lieux, quatre contextes physiques séparés. La thèse d'architecture de cette application est qu'un écosystème numérique de cabinet peut les faire coexister dans un seul espace — le BA unifié :
L'audit interne du 13 juillet 2026 a mesuré cette thèse sur les données réelles, et le verdict est instructif : les deux modes techniques sont vivants, les deux modes humains sont faibles. La représentation et l'agrégation tournent (positions signées citables, anonymisation en deux temps testée) ; l'interaction humaine, elle, affichait zéro réunion de communauté de pratique et quatre contributeurs actifs sur douze membres. Ce n'est pas une faiblesse cachée — c'est la démonstration, sur pièces, que la technologie ne compense pas le collectif. La suite du module (dossiers de fond, kit de lancement de CoP) s'attaque précisément à ce maillon.
Chaque affirmation qui suit a été vérifiée en code ou en base lors de l'audit « norme intégrale en main » du 13 juillet 2026, puis revérifiée pour cette page. Les clauses citées sont cliquables — elles ouvrent le référentiel avec la lettre de la norme.
Établir le système — la seule clause verte. Le module Cabinet apprenant est la clause § 4.4.1 (« établir, mettre en œuvre, maintenir un système de management des connaissances, y compris un accompagnement du changement maîtrisé ») : Installer constate la naissance du cabinet depuis les vraies données — rien à cocher, le geste fait, le chiffre bouge —, le parcours séquence les gestes, la santé referme la boucle. L'accompagnement du changement n'est pas un document annexe : c'est l'interface elle-même.
Acquérir au point de contact client — le maillon le plus fort. Dix-huit connexions d'entrée branchées ou construites : tickets Relais avec leur demandeur identifié, visios transcrites et rattachées, mails proposés au dossier, veille qui capte et publie. Le parcours « Question client » ferme la chaîne complète : de la question posée par un client au savoir anonymisé publié dans la Matière grise, sans une seule ressaisie.
L'information documentée, forte par construction. Tout ce qui compte est signé, daté, versionné : les positions de doctrine portent leur signataire et leur dossier d'origine, la GED garde versions et corbeille, chaque partage externe passe par un lien signé et journalisé, chaque note publiée à un client vit sur une page publique tracée. Ce n'est pas une politique écrite après coup — c'est le comportement par défaut du code.
La boucle d'amélioration, différenciante. Les retours utilisateurs entrent par un bouton présent sur chaque page, suivent un vrai cycle de traitement, et le champ « capture KM » trace si l'idée est devenue compétence ou article : le ticket d'anomalie devient un enseignement. Trois boucles d'évolution du système coexistent — et cette page en est elle-même un produit.
Une métrologie de conformité graduée. Là où l'audit classique ne connaît que conforme/non conforme, le référentiel embarqué mesure chaque exigence sur un curseur 0-10, avec preuves et historique daté. Et une distinction rare y est tenue : les huit principes directeurs (§ 0.3) sont affichés comme boussole mais sortis de tout score — ce sont des fondements de pensée, pas des exigences auditables. Vingt-quatre exigences auditables, pas une de plus : le système ne s'invente pas des clauses.
Voici l'état réel, mesuré en base, au soir du 13 juillet 2026 — parce qu'un tableau sans ligne faible devrait alerter le lecteur, et que celui-ci dit où il est faible :
C'est la conclusion du registre d'audit, et elle est contre-intuitive pour un projet qui livre des modules chaque semaine : l'écart dominant n'est pas un manque d'outil, c'est un écart outil/usage. Le cycle de vie documentaire existait déjà en base — jamais utilisé. La veille refondue attend l'activation de ses chaînes — un geste humain. Le module le plus abouti ne vaut rien tant que le cabinet ne l'a pas traversé. Le chapitre 5 (le chemin) et le chapitre 7 (ce qui manque) tirent chacun les conséquences de ce constat.
Ce miroir a une réserve de méthode, assumée : l'auditeur (l'IA qui a co-construit le système) est juge et partie. Le registre le dit en toutes lettres — ceci vaut auto-diagnostic instrumenté (§ 9.1) ; l'audit impartial (§ 9.2.2) reste l'affaire d'un regard humain externe, l'audit croisé entre confrères. L'application instrumente sa propre lucidité ; elle ne remplace pas le tiers.
Une base de connaissance bien faite d'abord — puis chaque raccordement démultiplie.
Tout ce qui a été pensé dans cette application peut être réalisé de manière unitaire. C'est la thèse produit de cette page, et il faut la dire avec précision parce qu'aucun des textes du projet — ni le mémoire, ni les guides — ne l'avait posée à ce niveau : non pas « on déploie un domaine de doctrine à la fois » (ça, la gouvernance le disait déjà), mais chaque brique fonctionnelle du système tient debout seule, rend service seule, et pourrait se déployer seule dans un cabinet qui ne voudrait qu'elle.
Une base de connaissance bien faite — des positions signées, datées, avec leur source et leur péremption — vaut mieux, seule, que la plupart des intranets documentaires du marché. Un dossier client vivant — douze sections, chacune avec sa confiance et ses sources — vaut seul comme dossier permanent. Un système de tickets qui sait qui demande vaut seul comme outil de relation. Un cockpit d'analyse branché sur la comptabilité vaut seul comme outil de révision. Chacun de ces modules a été construit pour être irréprochable isolément — c'est la condition pour qu'un cabinet puisse commencer à petite échelle, par la brique qui répond à sa douleur du moment, sans acheter une cathédrale.
Mais la thèse a un second étage, et c'est lui qui fait le système : chaque raccordement démultiplie. La loi du chapitre 2 — K = I × S × C — est une multiplication : chaque brique raccordée augmente le contexte (C) et la signification (S) disponibles pour toutes les autres. La base de connaissance seule répond juste ; raccordée au dossier client, elle répond juste pour ce client ; raccordée aux tickets, elle apprend de chaque question posée ; raccordée à la comptabilité, elle confronte le discours aux écritures ; raccordée aux points d'entrée — visios, mails, veille —, elle n'a même plus besoin qu'on la nourrisse : tout y arrive sans effort de saisie, parce que c'est déjà l'espace où les collaborateurs travaillent.
« Une stratégie à effort constant et à effet cumulatif, ce qui convient parfaitement à la nature économique cumulative de la connaissance. »
Les praticiens du KM ont un nom pour cette manière de déployer : la stratégie du nénuphar. On ne draine pas l'étang pour y construire ; on pose un nénuphar, il prospère, il en porte un deuxième. Le guide du projet en avait tiré une règle de gouvernance — « pas de bascule générale, pas d'effet tunnel, une seule construction de domaine à la fois, un jalon de preuve avant chaque extension ». Le principe unitaire l'élève au rang de règle d'architecture : le produit lui-même est un étang de nénuphars, pas un progiciel intégré.
Si chaque brique vaut seule, par laquelle commencer ? La réponse n'est pas une préférence — c'est une contrainte technique documentée. L'IA sans corpus structuré hallucine : « la performance des algorithmes d'IA est directement corrélée à la qualité du corpus de données exploité » (Ourouk, 2025). Un cabinet qui branche l'IA avant la base obtient un perroquet éloquent ; un cabinet qui pose la base d'abord — même modeste : dix positions signées sur son secteur dominant — donne à chaque brique suivante un socle qui la rend immédiatement meilleure que sa version générique.
La base de connaissance bien faite, c'est trois exigences, pas une pile de documents :
C'est ce que la Matière grise construit : le fil des positions et retours d'expérience, les compétences cabinet (l'héritier moderne du « livre de connaissances » d'Ermine — même intention, coût de fabrication effondré), les arbres de décision, la veille qui empêche le tout de périmer en silence.
Chaque cabinet construit sa base : ses positions, son historique, ses clients. Plus il travaille dans le système, plus son actif grossit — et cet actif lui appartient : les compétences s'exportent en fichiers ouverts, lisibles sans la plateforme. C'est l'inverse du modèle de l'abonnement documentaire, où le cabinet loue la doctrine des autres et repart nu. La valeur d'un cabinet équipé n'est pas dans le logiciel : elle est dans le S et le C accumulés — son patrimoine, sa différenciation, et à terme un élément valorisable de son fonds.
Voici ce que chaque raccordement ajoute — non pas en fonctionnalités, mais en facteurs de l'équation :
Base × dossier client (le CRM vivant). La connaissance générale devient connaissance située. Le contexte entreprise — douze sections balisées, confiance, sources, péremption — donne à chaque réponse le C qui la rend juste pour ce client. C'est aussi le raccordement qui inverse la passation : au lieu de demander au client de tout réexpliquer, on lui envoie ce qu'on a compris et il corrige. Le critère de succès : que le client dise « c'est exactement ça ».
Base × tickets (le Relais). Chaque question client devient de la matière première. Le ticket sait qui demande (le demandeur est un contact de l'annuaire), l'agent instruit la réponse en lisant la doctrine ET la comptabilité, et la réponse validée repart — anonymisée en deux temps — enrichir la base. La boucle question → réponse → doctrine tourne sans ressaisie : c'est le parcours « Question client », livré et vérifié.
Base × comptabilité (Odoo, Pennylane, FEC). Le discours rencontre les écritures. C'est le raccordement qui a produit la leçon fondatrice du dossier vivant : un client qui se dit exonéré de TVA et qui en collecte à 20 % — aucune des deux sources, seule, ne révélait le problème ; leur contradiction l'a fait. La contradiction entre sources est le signal le plus riche du système, et il n'existe que si les sources se parlent.
Base × points d'entrée (visios, mails, canaux, veille). Le coût de captation tombe à zéro. Les 386 réunions Noota importées, les fils de mails proposés au rattachement, les canaux clients, la veille qui publie chaque jour : la connaissance entre par où elle naît — la conversation — sans qu'on demande à personne de documenter. Chaque connecteur obéit à la même constante d'architecture : le connecteur propose, l'humain dispose. Rien ne se diffuse, ne se rattache, ne se publie sans un geste humain.
Base × mesure (la santé, le PDCA). Le système se regarde. Les curseurs de conformité, les compteurs d'usage, le registre d'audit : c'est le raccordement qui transforme un outil en cabinet apprenant — un système qui sait où il est faible et qui en fait des chantiers datés.
Un principe d'architecture ne vaut que si l'on dit où il bute. Trois murs, connus et documentés :
Le mur du jeton unique. L'authentification IA du cabinet repose sur un jeton partagé : le plafond de débit est donc commun à tous les agents du cabinet — quelques exécutions simultanées utiles, pas davantage. Le sémaphore et le disjoncteur de coût rendent ce mur gérable (file d'attente, refus explicite, plafond journalier) ; ils ne le suppriment pas. Le vrai multi-utilisateur simultané supposera une facturation à paliers ou une clé par cabinet.
Le mur du collectif. La technologie prépare le collectif humain, elle ne le remplace jamais. Une communauté de pratique dont la table des séances est vide, douze rôles de référents portés par une seule personne : aucun raccordement ne compense ça. Le module outille le premier pas — il ne peut pas le faire à la place du cabinet.
Le mur de la négligence. La section la plus précieuse du dossier client — comment travailler avec ce dirigeant, ce qui l'agace, ce qui l'a blessé — est aussi celle que personne n'a envie de remplir. Si elle reste vide, la passation reste cassée. Aucun outil ne rattrape ça.
Les paliers concrets, avec les gestes qui existent déjà dans l'app.
Le principe unitaire a une conséquence directe : le déploiement n'est pas un projet, c'est une suite de paliers, et chaque palier laisse le cabinet dans un état stable où il pourrait s'arrêter en ayant déjà gagné quelque chose. Pas de bascule générale, pas d'effet tunnel : un jalon de preuve avant chaque extension — tant que le palier précédent ne sert pas dans la production réelle, le suivant n'ouvre pas.
Deux surfaces de l'application portent déjà ce chemin : Installer (la naissance — neuf étapes dont le statut est constaté depuis la base, jamais coché à la main) et le parcours en douze gestes (l'ascension). Les paliers ci-dessous en sont la lecture unifiée — du cabinet nu à la relation client qui fait la différence.
Tout commence par le facteur C de l'équation : le contexte du cabinet, saisi une fois, servi partout. Qui sont les associés, quels secteurs dominent le portefeuille, quelle méthode, quel ton. Sans lui, l'agent du cabinet est un agent générique — contraire à la promesse. L'entretien de cadrage le fait en conversation : l'IA questionne là où la connaissance est tacite, s'efface là où le constat suffit.
✓ Acquis : un contexte cabinet qui rend chaque brique suivante immédiatement personnelle.
Le socle. Dix positions signées sur le secteur qui fait mal, une première compétence forgée depuis un cas vécu, la doctrine qui cesse de vivre dans les têtes. C'est le palier qui vaut seul : même sans rien raccorder, le cabinet possède désormais un actif écrit, signé, daté, périmable.
✓ Acquis : un actif de doctrine qui appartient au cabinet — exportable, hors de toute plateforme.
Le référentiel client cesse d'être un annuaire : contexte entreprise en douze sections, confiance, sources, péremption, et le verrou de code qui garantit que la mémoire relationnelle ne sort jamais vers le client. Premier geste marquant : la passation inversée — envoyer au client ce qu'on a compris de lui, et le laisser corriger en dix minutes ce qui prenait deux heures de réunion.
✓ Acquis : chaque réponse du système devient juste POUR CE CLIENT — le facteur C au niveau du dossier.
Toute demande client, quel que soit son canal d'origine, devient un fil traité : un demandeur identifié, un statut, un responsable — « je t'ai mis un Relais ». Et chaque réponse validée peut repartir, anonymisée, enrichir la base. La boucle question → réponse → doctrine tourne désormais sans ressaisie.
✓ Acquis : plus aucune réponse construite ne meurt avec la conversation qui l'a portée.
Pennylane ou Odoo se branchent en lecture ; le FEC s'importe pour l'historique. Le cockpit d'analyses s'allume (balance, SIG, trésorerie, balance âgée, cut-off…), les contrôles confrontent le discours aux écritures, et l'agent instruit ses réponses sur les chiffres réels — en citant leur provenance. C'est le raccordement qui fait apparaître les contradictions, le signal le plus riche du système.
✓ Acquis : la connaissance confrontée aux écritures — le jugement comptable outillé.
Visios transcrites et rattachées, mails proposés au dossier, canaux clients, veille qui capte et publie chaque jour. Le coût de captation tombe à zéro : la connaissance entre par où elle naît. Chaque connecteur propose, l'humain dispose — la confiance repose sur le geste final.
✓ Acquis : le système apprend du travail quotidien sans qu'on documente jamais rien.
La communauté de pratique tient ses séances courtes, les référents se répartissent les domaines (le facteur bus passe de 1 à N), l'auto-diagnostic mesure, le registre date les décisions — y compris celles de ne pas construire. Le cabinet ne subit plus son système de connaissances : il le pilote.
✓ Acquis : un cabinet apprenant — qui sait où il est faible et en fait des chantiers datés.
Il faut être précis sur la destination, parce que c'est elle qui justifie tout le reste. Au bout de ces paliers, la relation client change de nature — sans mystère, par accumulation de facteurs :
« Le jour où un dirigeant d'entreprise change d'interlocuteur sans rien réexpliquer, le management des connaissances a atteint son but ; tout le reste n'aura été que le moyen d'y parvenir. »
Tous les modules existants, chacun situé : brique, SECI, DIKW, clauses, relation client.
Huit organes, et chaque module de l'application appartient à l'un d'eux. Chaque carte dit ce que le module fait, ce qu'il apporte à la relation client quand c'est son rôle, et — pour les plus structurants — le mode de conversion de la connaissance qu'il sert (SECI), l'étage de valeur (donnée → information → connaissance → jugement) et ses clauses ISO. Les cartes regroupent : un « module » peut couvrir plusieurs écrans (le cockpit d'analyses en compte onze). Les routes anciennes qui redirigent (l'ex-Portefeuille, l'ex-Dossier permanent, les six routes de l'ancienne veille…) ne sont pas cartographiées : ce sont des panneaux indicateurs, pas des organes. L'inventaire exhaustif, écran par écran, vit dans le registre de chantier daté du 17/07/2026.
Tout ce qui dit qui est le client et où s'accumule le contexte. C'est le socle du CRM vivant : si cette famille est pauvre, tout le reste répond générique.
Le référentiel source de vérité des dossiers clients — vue Cœur (les fiches) et vue Tâches (la production), un seul hub.
Relation client : la liste n'est plus un annuaire : chaque ligne ouvre une mémoire.
Le tableau de bord d'un client : identité, rôles, échéances, retards, modules actifs, fil récent — la première page qu'ouvre un collaborateur qui reprend le dossier.
Relation client : reprendre un dossier sans réunion de passation.
Douze sections balisées — essence, offre, modèle, gens, histoire, relation… — chacune avec confiance, sources, péremption et droit de sortie. Un verrou de code garantit que la mémoire relationnelle ne sort jamais vers le client.
Relation client : la passation inversée : « voilà ce qu'on a compris de vous, corrigez-nous ».
Le dossier permanent structuré : identité légale, associés, banques, contrats, honoraires — les faits stables du client.
Les contacts à hauteur de personne (une identité par cabinet, des rattachements par dossier) : qualification des fiches entrantes, fusion des doublons, garde absolue — un membre du cabinet n'est jamais traité comme un tiers.
Relation client : savoir qui demande, et avec qui ce contact travaille ailleurs.
La vue relation d'un dossier : échanges par canal (Relais, visios, mails, Slack), demandes ouvertes, dernier contact — le pouls de la relation.
Relation client : voir en un écran si un client est délaissé.
Les grappes du portefeuille, définies par le cabinet (pas par le code APE) : le moteur analyse et propose, l'humain crée le secteur — la cible de routage de la veille.
Documents versionnés avec corbeille, glisser-déposer d'arborescences, partage par lien signé et journalisé, import des actes Pappers.
L'avant-client : enrichissement automatique (Pappers, BODACC, INPI, INSEE), organigramme reconstruit, écarts discours/réalité détectés — la connaissance commence avant la lettre de mission.
Relation client : arriver au premier rendez-vous en connaissant déjà l'entreprise.
L'annuaire interne : qui fait quoi, sur quels dossiers — l'autre moitié de la relation.
La création autonome d'un dossier (l'import Monday est déprécié) : le référentiel ne dépend plus d'aucune source externe.
La base de connaissance bien faite du chapitre 4 — signée, datée, au point d'usage — et ce qui l'empêche de périmer.
L'unité centrale du système : un sujet, sa doctrine, ses scripts, ses connecteurs — lisible par un humain, exécutable par l'agent, versionnée, exportable. L'héritière du « livre de connaissances » d'Ermine, au coût de fabrication effondré.
Relation client : la réponse du cabinet, pas celle d'un chatbot.
Une chaîne = source(s) + motif rédigé + prompt versionné + cible + référent. Publication automatique quotidienne au fil public ; l'humain n'intervient qu'à l'escalade — et la propagation aux dossiers montre toujours la liste avant l'envoi.
Relation client : l'alerte part vers les dossiers concernés avant la question du client.
Les parcours de leçons par monde (cabinet, client) et par phase du cycle de production.
Pour chacun des 63 modules du programme : ce que le cabinet sait, surveille et produit sur le sujet — la vue transverse d'un domaine.
Huit guides d'usage écrits (Cœur, agenda, visios, veille, revue de clôture…) — l'application documentée dans l'application.
Hors écran mais dans le système : le coffre Obsidian des 63 modules experts, et le plugin qui capture les leçons des sessions de travail — les compétences remontent dans l'app par ingestion idempotente.
Par où la connaissance entre : les conversations réelles du travail réel. Constante d'architecture, sans exception : le connecteur propose, l'humain dispose — rien ne se rattache, ne se diffuse, ne se publie sans un geste humain.
La messagerie d'équipe ancrée sur les entités : un fil = un ticket avec demandeur, statut, responsable — « je t'ai mis un Relais ». Temps réel, réactions, annexe privée d'équipe, agents IA mentionnables dans le fil.
Relation client : aucune demande client ne se perd, quel que soit son canal d'origine.
La chaîne complète : le ticket sait qui demande, l'agent instruit sur la doctrine ET les écritures (provenance restituée), la note aux couleurs du cabinet part au client sur page signée, et la réponse capitalise — anonymisée en deux temps — dans la Matière grise.
Relation client : chaque question posée rend le cabinet plus intelligent pour la suivante.
386 réunions importées, transcription diarisée, suggestions de rattachement justifiées, demandes détectées → tickets après validation. Visio non rattachée = privée (verrou de code) ; rattacher = diffuser ; le média ne part jamais sans case cochée.
Relation client : ce que le client a dit en réunion ne meurt plus avec la réunion.
Le client mail du cabinet : fils importés bornés, rattachement automatique justifié et réversible, confidentialité serveur (fil non rattaché = visible du seul propriétaire), réponse dans le fil, signatures du cabinet.
Relation client : l'historique mail entre dans la mémoire du dossier.
Un canal par client, un fil = un ticket, ✅ = résolu. Construit et testé — attend le Bot Token du cabinet.
La surveillance des boîtes du cabinet en droits application — attend l'app Azure AD et le consentement admin.
Le canal des clients qui n'écrivent nulle part ailleurs — construit, écritures encadrées par liste blanche.
Le calendrier lu pour l'agenda et les visios ; la saisie des temps automatisée depuis les rendez-vous réels.
Le sas entre la matière brute et la doctrine : brouillons, idées et demandes en attente d'un arbitrage de sachant.
L'application ne fait pas la production — elle la lit, la confronte et la juge. C'est ici que la donnée comptable rencontre le contexte : le raccordement qui fait apparaître les contradictions.
Balance générale, bilan, compte de résultat en cascade SIG, flux de trésorerie, tiers, balance âgée, cut-off, comptes d'attente, volumétrie, synthèse — reconstruits du FEC ou du provider, avec drill jusqu'à l'écriture. La onzième vue, la trésorerie par partenaire, a sa carte ci-dessous.
La pastille qui confronte la balance vivante (Pennylane, Odoo) à la copie locale, au centime : la donnée sur laquelle on raisonne est certifiée fraîche — ou l'écart est dit.
Le relevé bancaire intelligent (opt-in par dossier) : partenaires normalisés par règles codées, récurrences justifiées, catégories poussées vers Pennylane, mémoire du cabinet appliquée à l'ingestion.
Relation client : parler trésorerie au dirigeant dans ses mots — par partenaire, pas par compte.
Le poste de revue actif : la balance porte ses contrôles (activer → tester → conclure sans quitter l'écran), verdicts justifiés compte par compte, préparation de la Preuve de revue en trois vues.
Les diligences du cabinet en catalogue : applicabilité par profil de dossier, cadences, exécuteur unifié avec volet IA — un contrôle né d'une erreur sur un dossier sert à tous les autres.
Templates HTML réutilisables d'un exercice à l'autre, tokens résolus depuis le dossier et les benchmarks sectoriels, moteur indifférent au logiciel comptable (Odoo comme Pennylane).
Relation client : la restitution s'ouvre sur le client, pas sur la balance.
Le registre des obligations fiscales dérivées du profil de chaque dossier — la même vérité sert le cockpit, les bulles et l'agent.
Les pipelines répétitifs harnachés : chaque automatisation appartient à un skill (jamais de script orphelin), s'exécute avec sas de validation et journal de runs.
Des cas réels industrialisés : import, lettrage, contrôles et rapport — la doctrine d'un dossier devenue procédure outillée, sas à chaque écriture.
Les arbitrages chiffrés avec rapport client — et un agent qui explique la simulation.
La réversibilité des données de production — le cabinet n'est jamais prisonnier.
Un seul agent visible — Léo — et, dessous, un harnais qui compte autant que le modèle : c'est le harnais qui transforme une IA générique en collaborateur du cabinet.
Pas un chatbot : un agent qui lit la comptabilité (Odoo, Pennylane, FEC), le référentiel, la doctrine et les dossiers via des outils métier, et qui cite ses sources. Il sait toujours d'où il est appelé (le dossier, la personne, le cabinet — injectés au runtime).
Relation client : la réponse instruite sur les données réelles du client, pas sur l'air du temps.
Lancer un agent depuis une compétence, en conversation plein écran : la doctrine du cabinet devient un geste exécutable — et l'agent peut proposer une compétence nouvelle, que le sachant valide.
Un agent = une ligne de données, un canal = une politique, un runtime = un seul code. Registre unique des outils (aucun joker : chaque outil est déclaré), politiques par canal (le même Léo se comporte différemment dans le Relais, le Studio ou le widget), session par fil.
Chaque exécution est consignée (coût, durée, tours, statut) ; un disjoncteur de budget journalier tourne AVANT chaque run ; un sémaphore borne les exécutions simultanées ; l'admin voit les runs vifs et peut couper.
Le forfait Claude du coffre du cabinet d'abord, la clé API en débordement — un seul point où se noue le jeton. C'est ici que vit le mur de scalabilité du chapitre 4, et c'est ici qu'il se lèvera.
Le système ne parle jamais directement à Odoo ou Pennylane : une interface unique, deux adaptateurs — la revue de clôture a migré sans modifier son moteur. Troisième logiciel comptable = un adaptateur, pas une réécriture.
Les agents Payplug, revue de clôture, contrôle et action — antérieurs au runtime commun, fonctionnels, leur migration est reportée sciemment (décision produit du 07/07/2026).
L'internalisation ne se décrète pas : elle passe par les écrans qu'un collaborateur ouvre chaque matin.
La page d'accueil de tous les profils : la tournée du matin en bulles — taille = charge, couleur = outil comptable, dégonflage animé au fil des traitements. L'encadrement peut recomposer la vue exacte de chaque tête.
Relation client : voir en un regard quels clients attendent quelque chose.
La vue personnelle : calendrier du jour, inbox, le triptyque à faire / à voir / à lire.
Jour, semaine, liste : les tâches posées sur le calendrier réel, avec Pomodoro — le programme de travail remplacé par un agenda vécu.
Le fil des événements du cabinet (visios à valider, relais reçus, veille) — badge temps réel, notifications navigateur, digest matinal à 8 h.
Dossiers, savoirs, visios, conversations — l'accès transverse au système entier depuis n'importe quel écran.
Ce qui fait que le système est un produit et pas un prototype : la gouvernance, les droits, le cloisonnement.
La vue de l'encadrement : urgences, charge d'équipe, alertes, veille, visios — le cabinet en un écran.
Le hub unique de configuration : organigramme, pôles et statuts, annuaire cabinet, agents IA, sessions et coûts, référents veille, signature mail, statuts d'échéances, modèles de visios, intégrations.
La matrice éditable : le cabinet règle la visibilité de chaque page et les capacités de chaque rôle — la confidentialité est un réglage, pas une promesse.
Central et testé par un banc d'assertions bilatérales relancé avant chaque commit sensible : lectures filtrées sur ~60 tables, écritures bornées, insertions marquées d'office. « Superadmin » = voit le cabinet ACTIF — voir un autre cabinet, c'est basculer, et ça se voit.
La création et la gestion des cabinets — l'embryon du SaaS multi-tenants.
OTP Supabase, secrets par cabinet au coffre, clés Vault — jamais un identifiant en clair dans le code.
Le module où vous lisez cette page. Son rôle dans le système : faire qu'un cabinet comprenne ce qu'il utilise — parce qu'un dispositif KM utilisé sans être compris redevient un intranet.
Les pages non créées, les chantiers gelés, les promesses non tenues — l'âme inclut le futur.
Un système qui ne dit que ce qu'il a construit ment par omission. Les modules ci-dessous n'existent pas encore — certains ont leur spécification écrite, d'autres ne sont qu'une ligne de backlog — mais ils font déjà partie de l'âme : le système a été pensé avec eux, et plusieurs promesses des chapitres précédents ne seront complètement tenues que par eux. Ils sont regroupés par ce qu'ils réparent, et chacun porte sa source.
L'axe le plus rentable, pour l'application comme pour la démonstration : rien ne mesure encore qu'une connaissance a servi. Or c'est la définition normative même de « l'actif durable » (§ 9.1 : démontrer la valeur pour les parties prenantes, pas la conformité). Tant que ce chantier n'est pas fait, le retour sur effort du KM reste une conviction — pas un chiffre.
Tracer chaque mobilisation d'une compétence, exposer trois cadrans (réutilisation, retours d'expérience, validation), marquer les compétences dormantes.
Afficher le délai moyen d'arbitrage sur la file de capitalisation — la promesse des 7 jours, mesurée (la veille mesure déjà sa « chaîne des 5 jours »).
La carte des domaines à une seule tête — le facteur bus rendu visible. Petit chantier (une vue, un calcul), grand effet.
Kit de lancement guidé, ordre du jour auto-nourri par la file de capitalisation, trace de sortie systématique, santé mesurée par les trois pieds de Wenger. La spec du 16/07 est complète, le code écrit — la migration attend le geste du matin.
Le module est livré de bout en bout et prouvé sur le pilote (11 dossiers réels) — mais les 8 chaînes migrées sont en pause, motif « à motiver ». L'activation est un geste humain : écrire le pourquoi, désigner le référent, activer.
Date de revue par compétence, alerte de péremption, rapport d'obsolescence : le skill non couplé à la veille continue d'affirmer l'ancien montant — c'est la thèse anti-hallucination, elle mérite mieux qu'un traitement a minima. Les colonnes existent en base ; la lecture et le rituel manquent.
Capter le verbatim d'un entretien de sachant en direct, étiqueter les unités de connaissance, marquer les zones d'ombre — l'ingénieur des connaissances outillé. Le plus proche aujourd'hui est le compte-rendu écrit après coup : l'inverse du temps réel.
L'application gère aujourd'hui le cycle de production (les travaux, les échéances) — pas encore le cycle de relation. Deux spécifications écrites attendent leur tour, et leur croisement est peut-être l'idée produit la plus forte du backlog :
Prospect, entrée-reprise, croisière, développement, transmission, sortie : chaque stade définit ce que le KM doit capter et quelles alertes armer — paramétrable par cabinet.
Prise en main → autonomie → régime établi → surcharge → passation, dérivé des constats. Croisé avec le cycle client : client en croisière × collaborateur qui part = risque maximal de perte — l'indicateur du facteur bus, affiché sur la fiche.
Le canal « coach » : annoncer le programme, relier chaque geste à son bénéfice constaté (jamais promis), micro-doses de fond sourcées, adaptation au profil du porteur. Le design est abouti ; le câblage du canal reste à faire.
« En discuter avec Léo » sur chaque clause de la santé : l'agent constate sur pièces et propose un curseur justifié, l'humain arrête. Corrige une incohérence doctrinale — tout le système professe le constaté, sauf l'auto-diagnostic, resté déclaratif. Garde-fou maintenu : Léo est juge et partie, l'impartialité reste humaine et externe.
Si cette application doit un jour se vendre, voici — sans complaisance — ce qui manque entre l'état actuel (un pilote riche, vivant, sur les données réelles d'un cabinet) et un produit qu'un cabinet tiers achète :
Dérouler TOUT sur un cabinet vierge — chaque écran à vide, chaque état initial. Les bugs vivent dans les données inattendues ; un pilote qui arrive sur un cabinet vide ne pardonnera pas.
Stripe, paliers, pricing — entièrement à faire. Le mur du jeton unique (chapitre 4) se lève ici : une clé par cabinet ou une facturation à paliers.
Le cabinet fictif Méridien, peuplé de ses cinq archétypes narratifs (données fictives assumées, jamais du vécu maquillé), pour les démonstrations et l'accès du jury — l'instance existe, elle est vide.
L'indexation vectorielle des savoirs et du vault — provisionnée en base, jamais activée. Trois listes de dettes la réclament.
L'horizon long : des compétences et contrôles partageables entre cabinets — chaque cabinet garde son patrimoine, la profession mutualise ses mécanismes.
Trois chantiers sont gelés par décision datée, pas par oubli : la migration de la première flotte d'agents vers le runtime commun (07/07), l'unification des deux systèmes de conversations frères, et le modèle Équipe (une autre session le refond). S'y ajoutent des dettes de forme qui ne bloquent pas l'usage mais grèvent la crédibilité : la documentation du repo en retard de plusieurs familles de pages sur le disque, deux surfaces de contrôle aux noms quasi identiques, la double voie d'accès aux mails à arbitrer, et l'assainissement des migrations de base. Le registre de recommandations du 17/07/2026 les reprend une à une, avec priorités.
La méthode qui a produit ce module, et ce que cette rédaction exige de chaque module.
Cette page n'échappe pas aux règles qu'elle décrit. Elle a été produite par la méthode du module — la chaîne en sept maillons cristallisée le 14/07/2026 : la clause comprise à fond, la douleur qui l'incarne, le protocole des auteurs, le geste, l'épreuve sur le pilote, le miroir. Trois de ses règles l'engagent directement :
Une doctrine écrite puis jamais revue devient plus dangereuse que l'ignorance — la règle vaut pour cette page. Elle est datée du 17 juillet 2026 : les compteurs du chapitre 3 sont ceux de l'audit du 13 juillet, la carte du chapitre 6 reflète le code de cette nuit-là, et le chapitre 7 liste des chantiers dont certains seront livrés — donc faux — dans quelques semaines. Quand un module naît, meurt ou change de nature, cette page doit bouger avec lui ; si elle ne bouge plus, elle ment. Sa revue appartient au même rituel que le reste de la doctrine : la santé du système en est le déclencheur naturel.
Écrire l'âme d'un système oblige à regarder chaque module en face, et ce regard a produit deux documents de chantier, datés du 17/07/2026, qui accompagnent cette page côté atelier : un registre de recommandations module par module (chaque brique existante ou manquante, son écart avec le récit, l'ajustement proposé, la priorité) et un plan de réorganisation — du module Cabinet apprenant d'abord, dont les strates successives ont laissé des pages en doublon et des routes orphelines, et de la navigation générale ensuite. Les décisions restent à prendre au réveil ; le texte, lui, est là.
Une dernière chose, pour finir là où tout a commencé. La question du chapitre 1 demandait comment transformer la connaissance née de la relation client en actif durable. Après huit chapitres, la réponse tient en trois lignes : en construisant l'environnement où la connaissance se dépose en travaillant ; en la signant, la datant et la confrontant ; et en la rendant au client sous forme d'un conseil qui le connaît. Le collaborateur ne documente pas. Il travaille. Le système apprend — et le client le sent.