4 juin 2026 — le lendemain de ma première réflexion sur l'intelligence comme architecture.

La veille, j'avais posé une idée assez générale : si l'intelligence est une architecture, alors un système devrait pouvoir apprendre à déplacer progressivement ce qu'il sait faire vers des couches plus rapides et moins coûteuses. Le lendemain matin, j'ai commencé à réfléchir à ce que ça voulait dire concrètement pour Echo.

Le principe de base était déjà là. Une demande arrive, une couche sémantique essaie d'abord de comprendre ce qu'elle peut en faire. Si elle reconnaît suffisamment bien la situation, elle route directement vers le bon mécanisme. Si elle doute, elle escalade vers un modèle de langage. Le LLM devient alors le professeur du système : il traite le cas que les couches plus simples ne savaient pas résoudre, mais sa réponse ne doit pas être perdue. Elle devient une nouvelle donnée d'apprentissage pour que, la prochaine fois, le même type de situation puisse être reconnu sans avoir besoin de réfléchir à nouveau.

Mais stocker simplement « cette question donne cette réponse » ne m'intéressait pas vraiment. Ce que je voulais comprendre, c'était pourquoi le cas avait été difficile et quel signal avait permis de le résoudre. Est-ce un mot précis ? Une tournure de phrase ? Le message précédent ? Quelque chose qui n'apparaît qu'en regardant l'historique ? Si le système apprend aussi ce qui lui a permis de trancher, il ne mémorise plus seulement des exemples : il commence à comprendre quand il a besoin de contexte et quand il peut s'en passer.

Ça change énormément la manière dont je vois la mémoire et l'apprentissage. Un système intelligent ne doit pas seulement accumuler. Il doit aussi pouvoir se tromper, corriger, perdre en confiance et désapprendre. Une règle vue une fois peut rester candidate. Si elle revient et fonctionne, elle se renforce. Si elle est contredite, elle doit pouvoir disparaître ou revenir en quarantaine. Sinon on ne construit pas un système qui apprend, mais une machine qui transforme progressivement toutes ses erreurs en certitudes.

Cette plasticité me paraît essentielle, notamment parce que les gens changent. Une préférence vraie aujourd'hui peut ne plus l'être dans six mois. Une façon de répondre qui fonctionnait avec quelqu'un peut devenir agaçante. Je préfère donc garder une trace fidèle de ce qui s'est réellement passé et faire évoluer par-dessus les poids, les associations et les interprétations. Le passé reste là, mais le modèle que le système construit à partir de lui reste vivant.

J'ai aussi commencé à réfléchir à quelque chose que les assistants font assez mal : écouter. Un modèle de langage est entraîné pour répondre, expliquer, proposer, résoudre. Il a donc naturellement tendance à faire quelque chose à chaque fois qu'on lui parle. Mais un vrai échange ne fonctionne pas comme ça. Parfois quelqu'un raconte simplement sa journée ou vide son sac. La bonne réponse n'est pas une analyse en six points. C'est parfois une phrase, une question, ou juste le fait de lui laisser la place de continuer. Et ce qui rend une relation intéressante n'est pas seulement de savoir écouter : c'est aussi de savoir reconnaître le moment où il faut enfin donner un avis, poser la question qui dérange ou apporter un autre angle.

Ça m'a amené à une idée assez simple : le routeur ne devrait pas seulement choisir quoi répondre, mais aussi comment écouter. Il peut décider qu'une situation ne nécessite qu'une petite réponse, qu'une autre demande une vraie réflexion, ou qu'il ne sait tout simplement pas encore et doit demander de préciser. La profondeur du modèle devient une variable du système, pas une constante. On utilise peu de calcul quand le problème est simple, davantage quand il le mérite, puis on redescend immédiatement.

La même logique s'applique à la mémoire. J'avais jusque-là utilisé, comme beaucoup de systèmes, des résumés d'historique. Mais résumer est forcément une compression avec perte, et on ne peut pas savoir ce qu'il faut garder sans savoir pourquoi on résume. Pour une tâche de travail, je veux les décisions, les chiffres, ce qui reste à faire. Pour une conversation intime, les mêmes critères seraient absurdes : ce qui compte peut être une humeur, une limite, une tension ou un détail qui n'a aucune importance factuelle mais énormément d'importance pour la relation. Utiliser le même synthétiseur partout revient à jeter précisément ce qui comptait dans certaines conversations.

Le routeur commence donc à prendre une place beaucoup plus large dans ma tête. Il ne choisit plus simplement entre une commande et une réponse. Il peut décider combien de contexte charger, comment le condenser, quel niveau de modèle utiliser, combien laisser parler le système et ce qui mérite d'être appris ensuite. En réalité, il commence à gérer l'attention.

C'est probablement là que cette réflexion rejoint le mieux celle de la veille. Je cherchais au départ à rendre Echo moins coûteuse. Mais en essayant de réduire les appels inutiles aux modèles, je suis en train de construire quelque chose de plus intéressant : un système qui apprend progressivement où il doit réfléchir, où il peut agir directement, ce qu'il doit retenir et ce qu'il doit laisser disparaître.

L'économie n'est presque plus le sujet. Elle devient une conséquence de l'apprentissage.