01 / 41Reconnect · Romain, Ashad et Nils · 15 septembre 2026
Commencez par votre besoin du jour.
Théorie
Cette journée prolonge les landing pages et le projet React, Vite et TypeScript commencés ensemble. Les horaires sont des objectifs pédagogiques proposés pour le 15 septembre, pas des délais garantis d’exécution des agents. La matinée alterne exercices courts, production déléguée, cours et recette. Le support reste consultable ensuite, même sans réseau.
02 / 41Ouverture
Ouvrez une fiche « Théorie », puis refermez-la.
Théorie
Le titre donne l’idée principale de chaque écran. Les zones courtes permettent de suivre la projection sans lire un document entier. Le panneau Théorie apporte le raisonnement et les limites utiles en situation de travail. Les skills du kit sont fournis comme fichiers : ils deviennent disponibles après copie dans le projet et ouverture de Claude Code.
03 / 41La méthode
Exercice · 2 min : repérez la prochaine preuve de votre ticket.
Théorie
Le modèle propose des actions ; le logiciel agent lui donne accès à des outils et lui renvoie leurs résultats. Cette boucle permet de travailler sur un dépôt réel, au-delà d’une réponse textuelle. Elle ne garantit ni une bonne compréhension initiale ni la justesse du résultat final. Votre rôle consiste à fournir l’objectif, les limites et une preuve observable de réussite.
04 / 41La méthode
Exercice · 2 min : classez modèle, agent, Firecrawl et MCP.
Théorie
Un modèle n’accède pas spontanément au contenu de votre dépôt. L’agent lui présente les fichiers ou résultats obtenus par ses outils. MCP est un protocole permettant de connecter de nouveaux outils ; ce n’est ni un modèle ni une base de connaissances en soi. Dans Reconnect, Firecrawl peut être un outil de collecte accessible par MCP, tandis que le modèle résume le texte obtenu.
SourcesClaude Code · consulté le 14/09/2026MCP Claude Code · consulté le 14/09/2026
05 / 41La méthode
Exercice · 2 min : décrivez votre ticket en une phrase.
Théorie
Un skill décrit comment mener une catégorie de tâches et se charge lorsque cette compétence est utile. Un sous-agent reçoit une mission et travaille dans un contexte distinct, puis rend un résultat. Un workflow coordonne ces compétences, les exécutants et les moments de contrôle. Le ticket reste le contrat de travail commun à l’humain et à l’agent.
SourcesSkills Claude Code · consulté le 14/09/2026Sous-agents Claude Code · consulté le 14/09/2026
06 / 41La méthode
Exercice · 3 min : gardez cinq faits utiles pour votre ticket.
Théorie
Le contexte contient les instructions, échanges et résultats d’outils disponibles pour la prochaine réponse. Ajouter davantage de texte peut augmenter le coût et diluer l’information utile. Une synthèse durable conserve les décisions, les chemins et les validations à refaire ; elle ne remplace pas les sources. /clear démarre une conversation vierge et /usage aide à inspecter la consommation (/cost en est un alias) : les détails affichés dépendent du mode d’accès.
07 / 41La méthode
Choisissez l’étape qui manque aujourd’hui à votre pratique.
Théorie
Les étapes constituent une routine commune, indépendante du modèle choisi. Un ticket mal cadré augmente les reprises même avec un outil performant. La reformulation permet de détecter un malentendu avant l’implémentation. Les contrôles portent sur des décisions et des résultats : le plan, le lot terminé et le comportement après intégration.
08 / 41La méthode
Exercice · 5 min : rendez votre ticket Ready.
Théorie
SMART oblige à nommer le changement attendu et une échéance de travail. Ready décrit les conditions nécessaires avant le départ ; Done décrit ce qu’un relecteur pourra constater à l’arrivée. Une commande réussie est une preuve technique, mais ne remplace pas le parcours utilisateur. Les quantités et horaires du kit sont des cibles proposées, à confirmer avec le PO avant de démarrer.
09 / 41La méthode
Exercice · 3 min : montrez les fichiers autorisés de votre lot.
Théorie
Le contexte utile se trouve surtout dans le dépôt : commandes réelles, conventions, types et exemples. Un CLAUDE.md court fournit les règles durables ; le ticket ajoute la mission du moment. Les lots s’appuient sur le même contrat pour développer en parallèle. Une modification du contrat doit être annoncée à l’intégration avant d’être appliquée, car elle peut casser plusieurs lots.
10 / 41La méthode
Exercice · 5 min : utilisez /prompt-5 sur votre ticket.
Théorie
Le skill local claude-5-prompt organise une demande en [RÔLE], [CONTEXTE], [TÂCHE], [CONTRAINTES] et [EXEMPLES]. Le kit en reprend cette structure sans ses anciennes références de modèles ni son code API. Le but est de retirer l’ambiguïté, pas d’allonger le prompt. Comparez « fais un bel annuaire » au prompt ci-dessous : la source des données, les fichiers et le cas de contact absent deviennent explicites.
11 / 41La méthode
Exercice · 3 min : lancez un seul lot prêt.
Théorie
Un sous-agent peut explorer ou implémenter une mission bornée dans son propre contexte. Le parallélisme aide lorsque les fichiers et les dépendances sont séparés ; il crée des conflits si plusieurs agents réécrivent le même point d’intégration. Dans Claude Code, le mode Plan permet de préparer l’approche avant l’exécution, et les sous-agents personnalisés peuvent être configurés dans .claude/agents/. La durée réelle dépend du modèle, du réseau et de la difficulté : prévoyez un point de situation.
12 / 41La méthode
Exercice · 5 min : produisez une preuve de votre Done.
Théorie
Un build valide les types et la production du bundle, selon les scripts du dépôt. Le lint détecte certaines erreurs de code ; aucun des deux ne garantit que le parcours convient à l’utilisateur. Une recette vérifie le comportement observable et ses cas limites, puis le relecteur conserve les commandes et résultats. Le wiki garde ce qui sera utile au prochain ticket : une décision ou une recette, avec son contexte et sa source.
13 / 41La méthode
Exercice · 2 min : nommez le skill et l’agent de votre lot.
Théorie
La distinction donnée en formation reste pratique : une compétence, un exécutant, un enchaînement de bout en bout. Un workflow peut appeler plusieurs skills et déléguer une partie du travail. Un skill peut également contenir une procédure courte sans orchestrer toute une équipe. Dans le kit, /lancer-workflow porte le parcours de cinq étapes et réutilise la structure de /prompt-5.
SourcesSkills Claude Code · consulté le 14/09/2026Sous-agents Claude Code · consulté le 14/09/2026
14 / 41La méthode
Exercice · 5 min : testez jusqu’à l’affichage du plan.
Théorie
Le skill /lancer-workflow est fourni dans le kit, pas installé automatiquement sur les postes. Il lit le ticket, cherche les fichiers utiles et affiche une reformulation avant les modifications. Cette pause pédagogique vérifie que le périmètre est partagé. Après votre accord explicite, il délègue les lots indépendants, lance les validations disponibles et distingue une réussite prouvée d’une vérification bloquée.
15 / 41Les outils
Exercice · 3 min : retrouvez /prompt-5 dans le bon projet.
Théorie
La documentation distingue les sessions locales du Desktop des autres modes d’exécution. Les sessions locales CLI et Desktop lisent la configuration Claude Code, dont les skills projet et personnels ; l’onglet Chat et ses connecteurs relèvent d’une configuration distincte. La disponibilité dépend de l’installation, du compte et du mode de connexion du poste. L’usage Desktop n’a pas été essayé lors de la recherche : la procédure est documentaire, à contrôler au premier exercice.
SourcesDesktop Claude Code · consulté le 14/09/2026Skills Claude Code · consulté le 14/09/2026
16 / 41Les outils
Exercice · 5 min : copiez le skill prompt-5 du kit.
Théorie
Un skill regroupe une compétence réutilisable sous un nom découvrable. Le fichier SKILL.md commence par un frontmatter qui indique notamment name et description ; son corps porte les instructions. .claude/skills/ concerne le projet, tandis que ~/.claude/skills/ concerne l’utilisateur. L’exemple ci-dessous décrit une compétence locale de reformulation : le modèle reste nécessaire pour l’exécuter, même si le fichier lui-même est stocké sur le disque.
17 / 41Les outils
Exercice · 3 min : trouvez le serveur et son état.
Théorie
La portée local, project ou user détermine où la connexion est configurée et partagée. Une configuration projet peut être versionnée dans .mcp.json, en conservant les secrets hors du dépôt. Un serveur affiché ne prouve pas qu’une requête aboutira : authentification, réseau ou quota peuvent encore bloquer. Utilisez /mcp dans Claude Code pour inspecter les connexions ; le kit fournit les commandes documentées pour les services de cette formation.
18 / 41Les outils
Exercice · 3 min : vérifiez une API React utilisée dans le lot.
Théorie
Context7 fournit de la documentation de bibliothèques via MCP ou la CLI ctx7. Les outils MCP résolvent d’abord l’identifiant avec resolve-library-id, puis interrogent les extraits avec query-docs. L’assistant de configuration est documenté ; les accès et fichiers effectivement créés restent à contrôler sur chaque poste. Le service a besoin du réseau, y compris lorsqu’un connecteur local relaie les appels ; gardez une copie datée de la documentation utile pour la séance.
SourcesContext7 · consulté le 14/09/2026Dépôt Context7 · consulté le 14/09/2026
19 / 41Les outils
Exercice · 5 min : extrayez et relisez une page de la liste.
Théorie
Firecrawl propose la recherche, l’extraction de pages et des sorties structurées. Le serveur MCP hébergé dispose d’un mode sans clé avec des limites ; un compte ou une clé peut être utilisé selon le besoin. Une réponse de recherche n’est pas le contenu complet d’une page et ne valide pas ses coordonnées. Pour le lot de Romain, chaque fiche conserve la page source et la date de consultation ; sans réseau, utilisez seulement les copies déjà disponibles et n’annoncez pas une vérification récente.
SourcesFirecrawl MCP · consulté le 14/09/2026Mode sans clé · consulté le 14/09/2026
20 / 41Les outils
Exercice · 5 min : expliquez le schéma sans lire le code.
Théorie
Archify est un skill accompagné de scripts qui produit des diagrammes en HTML autonome. Le résultat local peut être consulté sans connexion une fois généré ; la génération par un agent distant reste dépendante de son accès. Le skill v2.16 a été identifié sur le poste formateur, ce qui ne prouve pas son installation chez les apprenants. Commencez par /archify si le skill est disponible et demandez un schéma fidèle au dépôt, en signalant les fichiers seulement prévus.
21 / 41Les outils
Découverte · 3 min : comparez le rôle de AGENTS.md.
Théorie
OpenCode est un agent de code ouvert, utilisable avec plusieurs fournisseurs de modèles. Le fournisseur, le coût, les données transmises et la disponibilité se vérifient avant un exercice. Ne supposez pas qu’un abonnement d’une autre application donne automatiquement accès à ses modèles dans OpenCode. La méthode de travail reste transposable : contrat clair, petit lot, lecture du diff et recette ; les apprenants peuvent garder Claude Code pour le MVP.
22 / 41Les outils
Découverte · 2 min : formulez une question utile au canal.
Théorie
Les recherches récupérées identifient Buzz et le dépôt public block/buzz comme un espace de collaboration où humains et agents peuvent participer. Aucune installation ni utilisation réelle n’a été effectuée dans la préparation du support. L’accès, les libellés de l’interface, la connexion des modèles et le coût restent à vérifier dans l’application et sa documentation actuelle. Présentez le scénario de canal comme une expérience à mener, sans en faire un prérequis pour terminer le MVP.
SourcesBuzz · recherche récupérée, accès non testé · consulté le 14/09/2026Code public Buzz · consulté le 14/09/2026
23 / 41Les outils
Exercice · 5 min : proposez une page à partir d’une source locale.
Théorie
LLM Wiki est un patron de travail présenté dans un gist de Karpathy, pas un logiciel à installer. L’agent transforme des sources brutes en pages Markdown persistantes que l’humain peut également lire et modifier. Un index aide à retrouver les pages, un journal garde les changements et des règles définissent la structure attendue. Le kit adapte cette idée avec wiki/raw/ pour les originaux et wiki/pages/ pour la synthèse ; cette organisation conserve le savoir, sans garantir l’exactitude des sources ni rendre un modèle distant disponible hors ligne.
24 / 41Le MVP
À 9h00 : validez le parcours et ce que vous reportez.
Théorie
Reconnect Assist est le fil rouge issu des échanges : aider à s’orienter vers des structures sociales, avec une interface accessible à des personnes peu technophiles. La formation reste dans le projet web commencé, même si les apprenants développent habituellement en PHP. Ville, langues et catégories sont des décisions à confirmer, pas des faits déjà validés. Une démonstration avec textes préparés est acceptable si le mode sans IA est annoncé ; elle ne prouve pas une intégration LLM. Le PO choisit un mode connecté seulement si un endpoint serveur est déjà prêt et validé ; les secrets restent côté serveur et les réponses indiquent leurs sources.
25 / 41Le MVP
Avant de lancer : pointez le dossier de votre lot.
Théorie
Cette organisation reste à confirmer avec l’équipe : Cédric est proposé pour l’intégration en plus de son rôle de PO. Les responsabilités prolongent la répartition demandée : collecte et base de connaissances, dialogue multilingue, puis contacts et carte. Les trois lots ne modifient pas directement les fichiers d’assemblage ni les types partagés. Les noms de dossiers sont proposés par le cadrage ; l’intégration les crée ou les confirme avant le départ. Chacun reste responsable de la relecture du code qu’il présente, même lorsque l’agent l’a généré.
26 / 41Le MVP
À 9h55 : relisez les signatures avant de lancer les lots.
Théorie
Le contrat complet est fourni dans kit/CONTRAT-DONNEES.md comme proposition à valider avec l’équipe. Les fonctions searchKnowledge, findOrganisations et explain renvoient des promesses, même si la démo utilise des données locales ; une future source distante pourra conserver l’interface. Les fixtures TypeScript sont un choix proposé pour faire contrôler leur forme par les types du projet. Une feature utilise le contrat et les exports publics, sans aller chercher les fichiers internes d’une autre feature.
27 / 41Le MVP
Ouvrez TICKETS-DEMAIN.md et confirmez Ready.
Théorie
Objectif proposé : À 10h45, proposer huit fiches issues des sources validées, searchKnowledge(query) et KnowledgeList, avec source et repli de langue ; lint et build réussissent. Ready : Contrat src/types/orientation.ts partagé et lu. Catégories, langues et huit sources ou fiches cibles validées par le PO. Copies de pages disponibles ou collecte testée ; branche à jour et lot attribué. Done : Huit KnowledgeItem typés : titre, résumé, catégorie, mots-clés, source et date réelle de consultation ; traductions validées ou explicitement signalées. Recherche par catégorie testée et résultat vide traité ; langue absente : repli en français. KnowledgeList montre le lien source ; aucune information absente n’est inventée ; lint et build réussissent, diff relu. Dépendances : INT-01 phase 1 : contrat et façade stub prêts avant lancement. Le ticket complet du kit porte les mêmes critères. Les quantités sont des objectifs pédagogiques à valider ; réduire le périmètre si les sources ne sont pas disponibles, sans inventer les données.
28 / 41Le MVP
Ouvrez TICKETS-DEMAIN.md et confirmez Ready.
Théorie
Objectif proposé : À 10h45, fournir un parcours langue → besoin → ville qui émet OrientationQuery et affiche une réponse sourcée dans la langue choisie : mode LLM si l’endpoint serveur est prêt et validé, sinon repli annoncé sans IA ; lint et build réussissent. Ready : Contrat et façade stub disponibles pour travailler sans les autres lots. Langues de démonstration et libellés français validés par le PO. PO : choisir avant lancement le mode connecté si un endpoint serveur est prêt et validé (clé côté serveur, sources renvoyées), sinon le repli avec textes préparés. La construction d’un backend supplémentaire exige un périmètre séparé. Done : Même jeu de libellés pour les langues retenues, avec repli français si une traduction manque. Choisir un besoin produit une OrientationQuery valide ; les états chargement, aucun résultat et erreur sont affichés. La recette indique le mode réellement testé : réponse LLM sourcée via endpoint validé, ou réponse préparée marquée sans IA. Parcours utilisable au clavier et sur écran étroit, boutons d’au moins 44 px ; lint et build réussissent, diff et capture relus. Dépendances : INT-01 phase 1 : contrat et façade stub. Le mode montré doit être annoncé ; une réponse préparée ne prouve pas une intégration LLM.
29 / 41Le MVP
Ouvrez TICKETS-DEMAIN.md et confirmez Ready.
Théorie
Objectif proposé : À 10h45, proposer six structures de la ville choisie, findOrganisations(query) et OrganisationList avec des coordonnées sourcées et un lien carte si l’adresse est disponible ; lint et build réussissent. Ready : Contrat partagé et ville de démonstration fixés. Six structures cibles et sources disponibles validées avec le PO. Lien carte externe retenu pour la matinée ; branche à jour et lot attribué. Done : Six Organisation typées, avec source et ville ; téléphone, e-mail, horaires ou adresse inconnus restent absents. Filtre par ville et catégorie vérifié ; ville inconnue : résultat vide ; aucun bouton de contact sans valeur sourcée. Carte liée seulement si l’adresse est disponible ; le fonctionnement du site externe est distingué de l’URL construite ; lint et build réussissent, diff relu. Dépendances : INT-01 phase 1 : contrat partagé. Le ticket complet du kit porte les mêmes critères. Les quantités sont des objectifs pédagogiques à valider ; réduire le périmètre si les sources ne sont pas disponibles, sans inventer les données.
30 / 41Le MVP
Ouvrez TICKETS-DEMAIN.md et confirmez Ready.
Théorie
Objectif proposé : À 9h55, partager un contrat et une façade stub ; à 12h00, intégrer les trois lots avec lint et build réussis, puis présenter à 12h15 un parcours complet et ses limites. Ready : PO : ville, catégories, langues, données et mode sans IA confirmés. Périmètres attribués et conventions relues ; l’état réel des tickets GitHub est contrôlé. Squelette ouvrable et ordre d’intégration annoncé à l’équipe. Done : src/types/orientation.ts et src/services/orientation.ts donnent les mêmes signatures aux trois lots ; les modifications du contrat sont annoncées. Assemblage dans src/app/ ; les lots exposent leurs fonctions et composants via index.ts sans import interne entre features. Lint et build réussissent après intégration ; recette besoin → réponse → organisme → contact disponible, plus cas vide et mode sans IA ; limites consignées. Dépendances : Phase 1 avant les lots ; phase 2 après leur relecture. Ordre proposé : KB-01 → ANNU-01 → ASSIST-01. Le ticket complet du kit porte les mêmes critères. Les quantités sont des objectifs pédagogiques à valider ; réduire le périmètre si les sources ne sont pas disponibles, sans inventer les données.
31 / 41Le MVP
À chaque point : signalez terminé, bloqué ou à réduire.
Théorie
Le cadrage réserve d’abord un temps de décision et de prise en main. Le contrat commun est une dépendance réelle : le lancer avant sa validation peut créer du travail incompatible entre les trois lots. Pendant la théorie, un point de situation court distingue attente réseau, information manquante et difficulté d’implémentation. À partir de la recette, corrigez les défauts qui empêchent le parcours ; consignez les améliorations pour après la démo.
32 / 41Le MVP
Exercice · 3 min : annoncez la limite de votre plan B.
Théorie
Un fichier HTML autonome se consulte sans réseau ; un projet Vite nécessite aussi ses dépendances déjà installées. Une copie de source garde sa date d’origine : elle ne devient pas une vérification du jour. Si les données manquent, réduisez la démonstration ou utilisez un cas d’école signalé comme fictif, sans inventer de contacts réels. Un modèle local n’est une solution que s’il est déjà installé, configuré et testé ; ce support n’en suppose aucun.
33 / 41Le MVP
À 11h45 : jouez le scénario depuis un écran neuf.
Théorie
La recette suit le parcours attendu plutôt qu’une visite de tous les fichiers. Testez un cas nominal et plusieurs limites : une ville inconnue, une traduction absente et un téléphone manquant. Vérifiez que le contenu ne transforme pas une information générale en une promesse personnalisée et que les sources restent accessibles. Une validation sur navigateur local, sur écran étroit et sur téléphone sont des preuves différentes : consignez seulement celles réellement effectuées.
34 / 41Vos questions
Repère · 1 min : ces quatre écrans répondent aux questions posées en réunion.
35 / 41Vos questions
Exercice · 10 min : lancez la boucle sur votre lot, puis lisez le rapport.
Théorie
Ce qui sépare une boucle d’un simple prompt tient en deux lignes : un critère d’arrêt vérifiable et un rapport final. Sans critère, la boucle s’arrête quand le modèle estime avoir fini, ce qui n’est pas la même chose que le travail fini. Les sous-agents deviennent utiles quand les recherches sont indépendantes : chacun travaille dans son propre contexte, rend un résultat court, et l’agent principal ne garde que la synthèse au lieu de tout accumuler. Le coût se paie en contexte, pas en temps.
36 / 41Vos questions
À faire · 2 min : posez la question avant la première ligne de code.
Théorie
La stack n’est pas une préférence, c’est une contrainte de livraison. « Projet App Web » est déjà en React 19, Vite et TypeScript : le build se vérifie en une commande et se publie sans serveur. Demander deux options chiffrées évite les deux échecs classiques : l’agent qui impose sa stack préférée, et l’équipe qui débat sans livrer. Laisser l’IA choisir reste légitime, à condition de lui donner la contrainte de temps : sans elle, elle optimise la propreté, pas votre matinée.
37 / 41Vos questions
À faire · 3 min : vérifiez que .env est ignoré avant votre première clé.
Théorie
Un point à corriger de la réunion : le mode commande, ouvert par un point d’exclamation en début de ligne, exécute une commande sans la faire reformuler par le modèle, mais la commande et sa sortie restent dans la session. Ce n’est pas un coffre-fort. La seule méthode fiable reste le fichier hors dépôt, plus une règle deny qui interdit sa lecture ; /permissions affiche les règles en place. Une clé passée une fois dans une conversation doit être considérée comme compromise et révoquée : elle est sortie de votre poste. Même règle pour les données des utilisateurs : ce qui entre dans un prompt quitte votre périmètre, donc on anonymise ou on n’envoie pas.
38 / 41Vos questions
Exercice · jusqu’à 12h15 : une feature livrée vaut mieux que trois commencées.
Théorie
Le dépôt contient la documentation nécessaire : tickets, contrat de données, conventions, notices d’outils et plan B sans réseau. Travaillez sur votre branche, pas sur main, et gardez le périmètre du ticket : c’est ce qui permet à quatre lots d’avancer en parallèle sans se marcher dessus. Ce qui est appris se note dans le wiki au fil de l’eau, pas à la fin.
39 / 41Garder
Conservez FICHE-5-ETAPES.md près de vos tickets.
Théorie
La routine évite de reconstruire votre manière de travailler à chaque session. Les cinq prompts restent adaptables au besoin : ils n’obligent pas à déployer plusieurs agents pour une petite modification. Ce qui reste constant est le lien entre objectif, périmètre, résultat et preuve. La fiche Markdown du kit peut être imprimée ou placée dans les favoris du projet.
40 / 41Garder
Copiez les trois dossiers de skills, puis ouvrez /prompt-5.
Théorie
Le README du kit indique quels fichiers copier à la racine de Projet App Web. Si .claude/ ou CLAUDE.md existe déjà, ajoutez les nouveaux skills et fusionnez les règles utiles au lieu de remplacer la configuration. Les documents de tickets et de contrat sont des propositions à confirmer avant le MVP. Les notices distinguent commandes vues dans les sources, essais réalisés et accès restant à tester sur les postes.
41 / 41Reconnect · Romain, Ashad et Nils · 15 septembre 2026
Lancez /ticket-ready sur votre prochain besoin.
Théorie
Commencez par un seul ticket et vérifiez qu’un autre participant comprend ce qui doit changer. Les fichiers manquants et les décisions ouvertes apparaissent avant le lancement, pas à la fin de l’implémentation. Le prochain geste consiste à reformuler le besoin et obtenir un plan dont vous pouvez expliquer les choix. Retrouvez ensuite 4 Lancer et 5 Vérifier et garder pour aller jusqu’à une livraison contrôlée.