MarmicodeCharted Coding : développement assisté par IA sans dérive
2 Jours · Online
🐣 Early Bird à partir de 870 € HT
Deux jours pour passer d'un développement assisté par IA rapide mais fragile à une approche que vous pourrez tenir dans la durée.Cartographier le paysage, tracer une méthode compatible avec votre architecture, puis construire le « harness » qui garde vos agents sur la trajectoire.
🇫🇷 Formation finançable jusqu'à 100% via OPCO.
🗓️ Sessions à venir
🍱 Ce que vous apprendrez
Comparez le Vibe Coding, le Spec-Driven Development (Spec Kit, BMAD, OpenSpec, etc.) et le Charted Coding, et reliez chacun aux problèmes qu'il résout ou qu'il crée.
Choisissez un workflow assisté par IA adapté aux prototypes, fonctionnalités en production, projets greenfield, brownfield ou code legacy.
Diagnostiquez le context rot (sycophancy, context clash, confusion, instruction drift, poisoning) et corrigez-le avec des sub-agents, des handoff docs, la compaction et la progressive disclosure.
Rédigez des design documents qui fonctionnent à la fois pour les humains et les agents, sans tomber dans la sur-spécification.
Alignez votre intention sur le code produit grâce à des cycles d'itération serrés.
Gardez la propriété collective du code : codez en direct avec votre équipe et vos agents sur une branche partagée, avec de petits commits et une revue continue et peu coûteuse.
Mettez en place skills, hooks, tests, Nx boundaries et règles ESLint comme couche de vérification déterministe que l'agent ne peut pas contourner en silence.
Calez chaque vérification sur son risque et sa latence, des hooks à l'écriture aux git hooks, à la CI et aux agentic workflows, pour attraper les mauvais changements avant qu'ils ne s'accumulent.
Utilisez skill-creator pour transformer un entretien en skill réutilisable, à progressive disclosure, qui encapsule le jugement de votre équipe.
Capturez les corrections que vous répétez et promouvez-les en skills, pour que la session suivante démarre plus affûtée.
Évitez la dérive, la perte de contrôle, l'over-engineering, la fatigue de revue et la distraction du multitâche.
Le coût des tokens n'est que la partie émergée. Comparez les workflows sur le temps de revue et le coût de pilotage, pas seulement sur la facture.
🗓️ Programme
- Définir le "Vibe Coding" : quand ça fonctionne, pourquoi c'est séduisant, et les pièges classiques (dérive, dette cognitive / deskilling, décisions isolées et inconscientes, pas assez de points de contrôle).
- Spec-Driven Development : Spec Kit (GitHub), BMAD, OpenSpec et alternatives ; anatomie et fonctionnement de Spec Kit.
- Démo en direct : le même cas d'usage sous les deux approches, ce qui tient et ce qui casse.
- Analyse comparative en narratif : forces et limites selon le contexte ; quand chacune est rentable, et quand elle devient un frein.
- Boucles de feedback lentes, taxe du context switching et coût de pilotage : nommer les coûts cachés du développement assisté par IA.
- Dix minutes pour trouver les contradictions dans le dossier qui vous est attribué : un Design Doc ou un dossier Spec Kit pour la même fonctionnalité.
- Sans agent, sans aller voir l'autre dossier : une expérience directe de la fatigue de revue et des limites d'une spec statique.
- Context rot : comment la précision se dégrade bien avant que la fenêtre de contexte soit pleine.
- Les symptômes à reconnaître : sycophancy, context clash / contradiction, confusion, instruction drift, distraction, poisoning.
- Context isolation : sub-agents et handoff docs plutôt qu'une seule conversation tentaculaire.
- Context reduction : compaction, compute offloading et réduction de la verbosité des outils.
- Progressive disclosure, et arbitrages CLI vs. MCP pour les définitions d'outils.
- Anatomie d'une skill : SKILL.md, references/, scripts/, assets/, et pourquoi la progressive disclosure garde le contexte léger.
- Petit historique : CLAUDE.md, AGENTS.md, Claude Skills, Agent Skills.
- Gérer les skills comme des packages npm : `npx skills add / install / update / remove`.
- Lancer le même prompt deux fois : une fois sans skill installée, une fois avec `angular-developer` installée.
- Noter quels fichiers de référence l'agent ouvre à chaque tour : la progressive disclosure, observée directement.
- Naviguer avec une carte plutôt que dériver : piloter l'agent en gardant le contrôle de la trajectoire.
- Cartographier l'intention : co-construire un Design Doc pragmatique avec l'agent, couvrant objectifs, comportement, design et stratégie de tests.
- Tracer les waypoints : transformer l'intention en un plan de PRs ordonné et relisable (tranches fines qui ne cassent jamais la mainline).
- Piloter le cycle : Scaffold → Red → Green → Refactor, avec revue progressive après chaque tranche, pas une mega-revue en fin de course.
- Les tests comme spécification exécutable et comme boucle de feedback de l'agent IA : en quoi cela diffère du TDD classique.
- Compatibilité avec votre stack actuelle (Vitest, JUnit, pytest, etc.) : un état d'esprit "framework-agnostic".
- Coût et délai comparés, étape par étape, à un flow Spec Kit "classique".
- Installer les skills Charted Coding avec `npx skills add marmicode/skills`.
- Co-construire le Design Doc d'un planificateur de repas hebdomadaire avec `/charted-design` : le plus dur, c'est la stratégie de tests et le plan de PRs ordonné, pas la liste des fonctionnalités.
- Répondre aux questions de l'agent et éditer le doc au fur et à mesure. Pas encore d'implémentation.
- Pourquoi le pair programming dérive vers l'isolement et le mob programming vers le tunnel, et ce que les deux perdent : la propriété collective.
- Limbo : programmation partagée en direct ("how low can you go?"), de petits commits qui ne cassent jamais le build.
- Les règles : communication en direct, un chorus de 2 (3 max), co-design, et une personne libre de se concentrer sur le comportement pendant que les autres s'occupent de la structure.
- Résultat : une revue moins coûteuse parce que tout le monde a déjà vu la majeure partie du code, un développement plus rapide et une dérive détectée tôt.
- Implémenter le planificateur de repas avec `/charted-scaffold`, `/charted-red`, `/charted-green` ou `/charted-continue`.
- L'objectif est de ressentir la bonne granularité des étapes : des tranches fines, PR après PR.
- Le « harness » comme système : modèle, contexte, outils, contraintes, boucle de feedback, orchestration, mémoire (skills, ADRs) et human in the loop.
- Skills et hooks : encapsuler le jugement pour que l'agent suive le playbook de votre équipe.
- Verification gates : boucles de feedback courtes que l'agent doit passer avant d'avancer.
- Stratégie de tests comme « harness » : spécifications (réellement) exécutables qui empêchent la dérive.
- Nx module boundaries : murs architecturaux que l'agent ne peut pas franchir en silence.
- Utiliser `/skill-creator` pour transformer un entretien en skill packagée et réutilisable plutôt qu'en prompt jetable.
- Pousser l'agent à mener l'entretien avec `AskUserQuestion` plutôt qu'en conversation libre.
- Rédiger le design doc au fil de la création de la skill, pour pouvoir le relire, l'éditer et le commiter en cours de route.
- Installer `skill-creator` et construire une skill `codesign` sur mesure, de zéro, à partir de vos seules réponses.
- Essayer la nouvelle skill sur une fonctionnalité de votre choix.
- Backpressure : attraper les changements mauvais ou superflus avant qu'ils ne s'accumulent, plutôt qu'après une revue en big bang.
- La gate ladder, calée sur la latence et le risque : hooks à l'écriture et git hooks (~secondes), CI et agentic workflows (~minutes), revue humaine (~minutes à heures).
- Les hooks en pratique : UserPromptSubmit, PreToolUse / PostToolUse, Stop, et pourquoi il n'y a pas encore de "standard" (et les couches de compatibilité qui existent).
- Loop engineering : câbler une done-condition (ex. `nx affected -t lint,test` sort avec le code 0) pour que l'agent itère sans surveillance, plutôt qu'un `/goal` manuel et du polling.
- Écrire un hook `PostToolUse` ESLint, typé avec les types du SDK Claude, qui renvoie les erreurs de lint directement à l'agent.
- Comparer le même prompt avant et après le câblage du hook : le voir se corriger tout seul au lieu d'attendre la revue.
- Librairies implicites : tout `index.ts` devient un projet taggé (platform / scope / type) sans fichier `project.json` écrit à la main.
- Faire respecter les module boundaries avec des dependency constraints pour qu'un agent ne puisse pas franchir un mur architectural en silence.
- Configurer `depConstraints` pour que les modules de type `ui` ne puissent pas importer les modules de type `infra`.
- Pointer ESLint sur le graphe de dépendances et voir le même prompt respecter la frontière au lieu de simplement se la faire énoncer.
- Une correction que vous avez faite deux fois est une skill que vous n'avez pas encore écrite.
- Capturer : un hook repère la correction et la note pendant que vous êtes encore dedans.
- Promouvoir : la note devient une skill, et la session suivante démarre plus affûtée.
- Implémenter un hook `UserPromptSubmit` qui détecte le pilotage dans vos prompts et l'ajoute à un fichier de learnings.
- Implémenter un hook `Stop` qui vous rappelle de lancer `/save-learnings` dès que des learnings sont en attente.
- Intégrer la méthode dans le workflow d'une équipe existante, et les patterns de collaboration : qui écrit les tests, qui pilote l'IA, qui relit.
- Construire votre propre skill "let's cook" qui branche selon la tâche (spike, correction de bug, petit changement ou grosse fonctionnalité) et déroule un workflow différent pour le code legacy.
- Templates de Design Doc et d'ADR déterministes : markdown + cases à cocher + emojis vérifiables par un script, pas par un humain.
- Mettre en place des hooks de feedback rapide : lint à l'écriture, `nx affected` ou `vitest --changed` sur Stop.
- Cheatsheet : hooks typés, traiter les skills tierces comme des packages npm (risque supply chain et prompt injection), progressive disclosure, et capitaliser les learnings en skills relues et évaluées.
- Choisir la bonne approche pour la tâche à accomplir.
- Questions / réponses et retours des participants.
🎓 Prérequis
- À l'aise avec TypeScript ; les exercices et l'outillage (Vitest, ESLint) viennent de l'écosystème JavaScript
- Familiarité avec les tests automatisés
- Utilisation préalable d'un assistant IA pour générer du code (Claude, Cursor, Copilot, etc.) ; un usage occasionnel suffit
👨🏻🏫 Votre formateur
Younes Jaaidi
I am a Software Cook who enjoys whipping code until tests pass.
With nearly 20 years of experience in eXtreme Programming, I've coached dozens of teams and trained thousands of developers to cook robust and maintainable software — using Test-Driven Development, pragmatic testing strategies, and a healthy dose of Collective Ownership.
I'm also an Angular Google Developer Expert, an NX Champion, and a mediocre sailor.
🙋 Foire aux questions
Aux développeurs qui utilisent ou souhaitent utiliser efficacement les assistants IA ; aux lead developers et tech leads en charge de cadrer l'usage de l'IA ; aux architectes et CTOs cherchant à industrialiser le développement assisté par IA sans sacrifier la qualité ; et aux équipes confrontées à la dérive du code généré qui cherchent une approche structurée et reproductible.
Vous devez être à l'aise avec TypeScript, familier avec les tests automatisés, et avoir déjà essayé un assistant IA au moins occasionnellement.
Un ordinateur avec accès Internet, micro, webcam, navigateur à jour, droits d'installation et un assistant IA fonctionnel (Claude Code, Cursor, Copilot ou équivalent).
Oui. Après une comparaison cours + démo des principales approches, vous pratiquez le workflow Charted Coding sur un cas d'usage commun (Cartographier l'intention, Tracer les waypoints, Piloter le cycle), puis vous écrivez votre propre skill et câblez un « harness » (hooks, verification gates, Nx boundaries). Vous repartez avec une synthèse collective et un plan d'action individuel.
Non. Les principes s'appliquent à toutes les stacks et à tous les langages, et c'est bien l'intérêt : le workflow, le context engineering et le « harness » se transposent à ce que vous construisez. Les exercices sont en TypeScript, cela dit, et certains s'appuient sur l'outillage de l'écosystème JavaScript (Vitest, ESLint, Nx) — ce sont ces exemples que vous transposerez à votre propre toolchain, pas les idées derrière.
Si vous êtes en France, cette formation est éligible au financement OPCO. Contactez-moi pour un devis et les modalités administratives.
"Réserver une Place" vous inscrit à une session planifiée. "Session sur Mesure" s'adresse aux entreprises qui souhaitent une formation privée, avec la possibilité d'adapter le contenu, la durée ou les priorités.
Si la formation ne répond pas à vos attentes, contactez-moi dans les 7 jours et nous trouverons une solution ensemble.