Philosophie

Lytos existe parce que la façon dominante de travailler avec les assistants IA — « donnez-leur un rôle, laissez-les jouer » — ne passe pas à l’échelle sur de vrais projets logiciels. Cette section explique les trade-offs qui façonnent la méthode, le problème duquel on est partis, et le type de collaboration qu’on vise.

Les quatre pièces

Manifeste	Les sept principes fondateurs, et pourquoi on part de « cadre de projet » plutôt que de « persona d’agent ».
Souveraineté	Pourquoi la connaissance du projet — manifest, skills, rules, memory — doit vivre dans des fichiers que vous possédez, versionnez et pouvez migrer. Pas dans un vendor.
Les métiers du dev à l’ère de l’IA	Développeur, lead, formateur — ce qui change, ce qui ne change pas, et comment les équipes se réorganisent réellement autour du travail assisté par IA.
Kit formateur	Pour celles et ceux qui enseignent Lytos à des équipes ou à des clients — le parcours d’apprentissage, les modes d’échec, les questions qui valent la peine d’être posées.

Le trade-off central

La plupart des frameworks d’agents laissent l’IA s’imaginer comme développeur, reviewer ou architecte. Lytos pose la question inverse : à quoi un projet devrait-il ressembler pour que n’importe quelle IA — ou n’importe quel nouveau membre d’équipe — y soit immédiatement efficace ?

Ce changement a des conséquences. On arrête d’ajuster des prompts et on commence à écrire un manifest. On arrête d’inventer des personas et on commence à écrire des skills. On arrête d’espérer que l’agent se souvienne et on commence à écrire un fichier de mémoire qu’il relira à chaque session.

C’est moins glamour. C’est aussi beaucoup plus durable.

Où lire ensuite

• Si vous voulez la philosophie en trois minutes, le Manifeste est le point de départ.
• Si vous êtes convaincu et voulez construire, la section Méthode montre à quoi ça ressemble en pratique.
• Si vous voulez voir la méthode tourner sur un vrai projet, chaque dossier .lytos/ dans les dépôts Lytos est réel — pas un template.