Aller au contenu
Lytos

Workflow Lytos

Lytos ne remplace pas votre processus. Il ajoute une couche technique entre le besoin produit et le code généré par l’IA. Ci-dessous, deux workflows types — en solo et en équipe — montrent où Lytos s’insère et où rien ne change.

  1. Dev
    Définit le cadre

    Manifest (identité, stack, contraintes), rules (seuils de qualité), skills (procédures pour les tâches récurrentes). Un investissement initial qui sert toutes les sessions suivantes.

  2. Dev
    Écrit une issue

    Description technique du besoin, à la place d'un prompt jeté. L'issue vit dans le repo, avec son frontmatter YAML (priorité, type, références).

  3. Dev + IA
    Exécute

    L'IA lit le cadre (manifest + rules + skills + memory) et l'issue, puis produit du code dans le style du projet — pas en mode générique.

  4. Dev
    Valide et ajuste

    Challenge la proposition, corrige les écarts, vérifie la checklist de la skill utilisée.

  5. Dev
    Capture dans memory

    Ce qui mérite de persister (décisions d'archi, patterns, bugs évités) va dans memory/. Prochaine session, le contexte est déjà là.

  6. Dev
    Commit et close

    Commit avec référence à l'issue, board mis à jour, issue déplacée en review/, puis en done après validation explicite. Pas de perte de trace.

Comment les rôles évoluent

Section intitulée « Comment les rôles évoluent »

Dev — Moins de boilerplate, plus de formalisation du besoin technique. Son artefact n’est plus seulement le code, mais aussi l’issue qui le décrit. Le métier reste celui de développeur, avec en plus une compétence de cadrage — le prompt engineering appliqué au projet.

Lead Dev — Conserve ses responsabilités d’architecture. S’y ajoute la garde du contexte partagé : manifest, rules, skills. L’équivalent d’un style guide — mais exécutable par l’IA, pas seulement lu en revue.

PO / Scrum Master — Rôle inchangé. Lytos agit à la couche technique ; le ticketing produit et la méthodologie d’équipe restent intacts.

Surface émergente — Sur des équipes avancées, une fonction transverse de curation de skills et memory peut apparaître. Elle peut être portée par le lead dev, un staff, ou un profil dédié. Rien d’obligatoire — juste une observation.

Ce que ça change pour une direction technique

Section intitulée « Ce que ça change pour une direction technique »
  • Output IA reproductible — rules + skills = cadre vérifiable. Deux devs avec la même issue produisent du code comparable.
  • Onboarding accéléré — un nouveau dev lit le manifest et connaît le projet. Plus de transfert de contexte implicite qui ne se fait jamais complètement.
  • Montée en compétence des juniors — un junior ou une nouvelle recrue produit dans le cadre du projet dès ses premières issues. Manifest, rules, skills et memory jouent le rôle d’un senior silencieux : ils cadrent le travail sans mobiliser de temps senior.
  • Traçabilité — chaque issue a un frontmatter YAML, chaque skill est explicite, chaque commit référence son issue.
  • Code IA auditable — contrairement à un chat privé avec l’IA qui ne laisse rien derrière, chaque ligne générée via Lytos s’appuie sur une issue, des rules et une skill versionnées. Le pourquoi du code est lisible à froid, dans le repo — compliance et revues d’audit facilitées.
  • Portabilité modèle — changer de fournisseur IA ne casse rien. Le contexte est dans le repo, pas dans un SaaS tiers.
  • Dette réduite — le code généré aujourd’hui ressemble à celui d’hier. Les conventions ne glissent plus entre sessions ou entre développeurs.

Ce workflow n’est pas une révolution — c’est une formalisation de ce que beaucoup d’équipes font déjà de manière implicite, rendue explicite et versionnée dans le repo. Rien ne vous empêche de commencer petit : un manifest, deux skills, quelques rules. Le reste se construit au rythme du projet.