Définition canonique. StudentOps est le dispositif transversal de Frequencies qui accompagne des jeunes, des étudiants et des équipes pédagogiques du premier contact jusqu'à la livraison d'un ou plusieurs résultats concrets, puis leur retour d'expérience et leur valorisation. Il ne se réduit ni à un événement, ni à deux projets TBS, ni aux seuls stages : il sert tous les types de collaborations étudiantes et leurs productions, quels que soient le campus, la promotion ou le métier mobilisé. Parcours de bout en bout : relation avec l'établissement et identification de l'occasion → brief et objectifs → constitution de l'équipe, accueil et cadre administratif → exploration et acquisition de compétences → planification et rôles → accompagnement, arbitrages et résolution des obstacles → réalisation/itérations et preuve de travail → recette, livraison, présentation et passation → REX, valorisation et suivi de la continuité. L'accompagnement peut déboucher sur un ou plusieurs livrables : événement, court-métrage, œuvre sonore, contenu audiovisuel, application, prototype, étude, campagne, ressource pédagogique ou tout autre objet utile. Une méthode commune, des trajectoires différentes. Le programme suit les personnes, les équipes/cohortes, les missions, les objectifs d'apprentissage et les livrables réellement attendus ; il ne préjuge pas de ce que les jeunes doivent créer et n'impose pas à tous un modèle de festival ou de campagne MICI. Un parcours peut commencer sans solution prédéfinie et évoluer selon le projet et le calendrier pédagogique. Une mission peut produire plusieurs livrables, et chaque livrable exige une définition de réussite et une preuve de livraison adaptées. Frontière d'autorité : StudentOps / PROJ-ETU coordonne l'expérience de collaboration, la pédagogie, les engagements, la progression, les preuves transverses et la capitalisation N+1. Le projet métier propriétaire conserve les décisions de création et d'exécution, les contrats, partenaires, finances, risques, validation du résultat final et son patrimoine. Il n'y a qu'une autorité par donnée : Notion = doctrine/parcours ; Monday = tâches & responsables ; Airtable = registres typés ; Drive = productions/preuves ; Worker = capacité technique, non nouveau PMO. Portfolio existant : TBS/MOSAÏC (Clap’itole, Violette–MICI) illustre deux cas ; le programme inclut aussi les autres écoles, formations, stages, productions, défis, mémoires, commissions et partenariats selon leurs cadres respectifs. Les huit modules internes StudentOps existants sont des capacités, non huit silos autonomes à reproduire. Statut : correction de définition et de navigation, pas nouvelle tâche, base, projet, Worker ni publication. Aucun accès étudiant généralisé ; le pilote Notion 2.0 reste subordonné aux ACL.
Périmètre : PROJ-ETU-000 / Frequencies StudentOps, transversal à tous les établissements, projets tutorés, stages, YDAYS, mémoires, créations et challenges. Les projets TBS Violette–MICI et Clap’itole ne sont que deux applications du programme, pas ses frontières. Ce relevé ne remplace pas les registres métier, ni les parcours individuels du sous-système CAMP-STUDENTOPS-000.
opportunité / école / jeune → brief et résultats attendus → accueil / équipe / conventions → plan pédagogique → tâches et accompagnement → production / versions / preuves → recette pédagogique et validation métier distinctes → un ou plusieurs livrables identifiables → passation / diffusion autorisée → REX / valorisation / suivi.
Un brief, une intention, un dossier, une fiche ou un code Worker ne sont pas, à eux seuls, un livrable terminé. Chaque livrable réel doit avoir au moins une référence stable, un propriétaire métier, un ou plusieurs critères d'acceptation, une preuve source consultable, une décision de revue (accepté / à reprendre / refusé), les limites de droits/réutilisation et une destination après livraison. StudentOps conserve le résultat pédagogique et la traçabilité, pas une copie autonome de la production du métier.
5101393093 : 33 items = 24 Terminé / 8 Validation / 1 Bloqué. Avancement strict 24÷33 = 72,73 %. L'ancien 24/31 = 77,42 % est un instantané historique et ne doit plus être affiché comme résultat courant. Les 33 lignes incluent les sous-branches spécifiques, pas 33 livrables jeunes.CAMPUS-001 / appukD6bZnROfAISk : Mémoire & productions étudiantes = 46 objets, tous Extrait (analyse faite, pas 46 livrables livrés). Mémoire — notions 001 = 223 (171 Routé, 52 Fusionné à l'existant) ; pas de reliquat de routage dans cette table.30/30 couverts mesure un état de preuve renseigné, pas l'existence de 30 livrables exploitables.Prêt pour YDAYS, 51 missions inventoriées, 0 enregistrement dans la table spécialisée StudentOps YDAYS — Livrables & revues. Prêt pour YDAYS signifie prêt à présenter/cadrer, pas projet attribué, mis en production, accepté ou livré. Ne pas remplir artificiellement la table pour améliorer un pourcentage.3131126887 SHOWCASE-002 (Validation) : attendre les autorisations / droits image-voix-données-œuvres, la classification de diffusion et le test effectif avant toute vitrine publique.3264052115 TBS R1/P9 (Validation) : R1 s'est tenue le 13 octobre mais impressions, supports physiques et sorties R1 ne sont pas tous prouvés ; clôture humaine sur pièces, pas sur le conducteur préparatoire.3160343013 YDAYS Équipe BACK (Validation) : dossier/pitch existants ; attendre canal Ynov, réponse, règles de plateforme, affectation réelle et cadrage commanditaire. Aucun dépôt présumé.3164388393 YNOV Rennes (Validation, déjà en sommeil de branche) : preuve du statut podcast / réponse Ynov / éventuels appels étudiants ; pas de sollicitation nouvelle automatique.3164448205 Slack demande de stage (Validation, pilote privé) : attendre une vraie demande pour tester le workflow et sa confidentialité ; ne pas créer de faux stagiaire.3164485820 Tutorat–mécénat (Validation) : convention, rôle et engagement réels à valider avec Partenariats ; ne pas inventer un mécénat acquis.