Le harness et le Knowledge OS sont la base. Ils ne sont pas l'état final.
Il y a deux articles, je défendais une idée : l'IA ne devient utile que dans un système. Le précédent nommait mes deux couches :
Toujours la base. Pas l'état final.
La couche suivante est claire pour moi : des modèles locaux spécialisés et fine-tunés. Pas un seul grand modèle pour tout. Pas un seul immense prompt censé tenir le système ensemble. Des modèles plus petits, des tâches étroites, de vraies contraintes matérielles, câblés comme des composants fiables.
Le prompting finit par buter contre un mur
Le prompting est le moyen le plus rapide de prototyper et d'atteindre une première utilité.
Puis la facture arrive. Trop de comportement vit dans le prompt. Les instructions s'allongent. Les cas limites s'accumulent. Le modèle infère trop, à chaque exécution.
Tu paies un modèle frontier pour relire les mêmes instructions à l'infini. Lui ne s'ennuie jamais. Ton budget, si.
Acceptable au début. Beaucoup moins quand l'objectif devient une exécution répétable. Si la même classification, extraction ou routage revient sans cesse, je ne veux pas payer le plein tarif du prompt à chaque appel. Je veux rapprocher ce comportement du modèle.
Le fine-tuning, c'est de la compression
On présente souvent le fine-tuning comme un moyen de rendre un modèle plus intelligent. Ce n'est pas l'angle qui m'intéresse.
Le fine-tuning compresse un comportement répété dans le modèle, pour que le système ait besoin de moins de scaffolding à l'exécution.
Il réduit la longueur des prompts, l'overhead d'orchestration, la latence sur les workflows étroits, et la variabilité sur les tâches répétées. Souvent, il achète plus de fiabilité qu'un paragraphe d'instructions de plus.
Petits modèles, rôles étroits
Le futur de l'IA opérationnelle n'est pas un seul modèle frontier qui fait tout. Il est distribué :
Un petit modèle bien borné n'a pas besoin d'être universellement brillant. Il doit être fiable dans une responsabilité limitée : classification, extraction structurée, application du style, routage d'outils, validation métier.
C'est une voie vers la fiabilité bien plus sérieuse que de demander à un modèle général d'improviser chaque couche.
Le raisonnement reste central
Il ne s'agit pas de remplacer le raisonnement par une automatisation fragile. L'inverse.
Le harness garde les décisions, le gating, l'escalade, le flux. Le Knowledge OS garde la mémoire et le contexte. Les modèles spécialisés prennent juste les tâches étroites dans cette boucle. Le système dépense alors du raisonnement coûteux là où il compte, pas sur des tâches à faible entropie déjà censées être stables.
La fiabilité n'a rien de magique. C'est un alignement conçu entre la tâche, les données d'entraînement, la boucle d'évaluation, et l'endroit où ça tourne vraiment. Le hardware est réel : compute, latence, confidentialité et coût sont de l'architecture, pas des détails.
La stack
| Couche | Rôle |
|---|---|
| Harness | Orchestrer l'exécution, l'itération, l'évaluation, le gating |
| Knowledge OS | Mémoire structurée, retrieval, contexte évolutif |
| Modèles locaux fine-tunés | Gérer les tâches étroites, répétées, métier |
| Modèles frontier | Synthèse large, ambiguïté, jugement complexe |
Plus proche d'un système complet que « un modèle plus un prompt ».
Le harness aide le système à faire. Le Knowledge OS l'aide à savoir. Les modèles locaux fine-tunés l'aident à stabiliser.
La prochaine étape n'est pas plus de prompting. C'est une meilleure spécialisation.