Bon, je n'ai pas de nouvelle de ta part, mais voici la suite. J'ai plusieurs questions dans les commentaires, les réponses m'intéressent et elles appellent peut-être une reformulation de ta part.
Dans l'ensemble, je trouve que c'est un bon cours : encore une fois je ne suis pas très intéressé par le domaine et pourtant j'arrive à suivre, et les idées mises en avant par Meteor me semblent bonnes. Tu as l'air d'hésiter entre deux façons de construire ton cours : d'un côté un aspect assez pratique (on développe une application et on introduit les notions au fur et à mesure, sans chercher à être exhaustif), de l'autre une approche plus "encyclopédique" (où tu te sens plutôt obligé de traiter certains aspects avant de passer à la suite). Je pense que la première approche est plus naturelle. Encore une fois, je t'encourage à insister sur un exemple fil rouge (comme un blog, avec des utilisateurs qui peuvent se connecter pour commenter), auquel cas tu peux changer le titre de la première partie "La théorie" (par exemple en "Un blog" ou en ce que tu veux) ; de toute façon il ne s'agit pas vraiment de "théorie" ici, plutôt d'une découverte découpée en différents thèmes.
Le cours est certainement validable en l'état actuel des choses (encore que ça n'est pas à moi de le dire), encore une fois c'est clair, pratique et intéressant. Je pense juste que tu peux rajouter/reformuler des choses par-ci par-là. J'espère que tu restes motivé, bonne continuation ! 
Chapitre 6
Quand tu présentes (rapidement) MongoDB, je pense que tu devrais ajouter que c'est une base de données non-relationnelle. C'est plus important que de savoir si elle utilise SQL ou pas.
Si vous ne connaissez pas encore ce système, vous vous rendrez vite compte qu'il permet de faire des choses très intéressantes dans le traitement des données.
Cette phrase est un peu creuse, du coup. C'est peut-être le moment de parler du NoSQL ?
Attention toutefois : en l'état, notre application n'adopte pas encore ce fonctionnement. La preuve, tapez ce qui suit dans la console de votre navigateur :
Ces deux phrases devraient être à l'extérieur de la liste (elles font suite aux trois points évoqués, pas seulement au dernier).
La partie sur autopublish et insecure est très intéressante. Globalement, est-ce qu'il y a beaucoup de modules actifs par défaut qu'il faut absolument connaître quand tu développes ? Ça sera bien d'expliquer aux lecteurs comment tu contrôles cette liste, par la suite.
Dans la suite, tu vas vraisemblablement beaucoup utiliser MongoDB, et tu renvoies plusieurs fois tes lecteurs à la documentation. Le problème, c'est que je doute que beaucoup d'entre eux soient habitués à cette base de données. À mon avis tu risques de les perdre si tu n'en dis pas assez.
D'une manière générale, essayez de ne prendre que le strict minimum de la collection, quitte à faire plusieurs publications pour une seule collection !
Un peu vague. Est-ce une bonne pratique ? Une question de performances ?
Dans ce cas, la fonction anonyme qui se trouve dans la publication récupère ces arguments !
Je pense que ça mérite un exemple, sauf si tu en donnes un plus loin.
L'option waitOn permet de dire à Meteor ce qu'on veut qu'il fasse avant d'exécuter la popriété data. Hé oui, car il faut bien être sûr que la souscription soit faite avant la requête dans la collection Posts. En effet, la souscription se faisant de manière asynchrone, il y aurait des chances pour que la requête se fasse avant la souscription. Si tel est le cas, la collection locale serait encore vide au moment de la requête ! 
Là je m'interroge personnellement : pourquoi Node ne propose-t-il pas une primitive qui permettrait de faire ça dans la fonction anonyme passée à ̀data directement ? D'ailleurs, Posts.find devine tout seul que c'est le résultat de ̀Meteor.subscribe qu'il doit récupérer ? Comment ça marche si tu fais plusieurs ̀subscribe ? Et si tu as déclaré plusieurs publications sur la même chaîne ?
C'est un bon chapitre, sinon.
Chapitre 7
Hé oui, le serveur permet de lever des exceptions, ce qui se révèle très pratique en termes de sécurité, mais cela permet également de rendre facilement notre application plus user-friendly ! 11
Il faut enlever le "11" à la fin.
Je suis un peu perdu par l'ordre des arguments des différentes fonctions. Quand tu throw une exception, le code est en premier et la raison ensuite, mais dans le callback fourni à insert c'est l'inverse ?
Chapitre "Les utilisateurs"
Hé bien en l'état, il s'agit bien d'une faille
Je ne suis pas vraiment d'accord. Il n'y a rien de surprenant à ce que le package ne devine pas "magiquement" ce que l'ona en tête. Le comportement est déjà assez pratique et intéressant comme ça. En revanche, quand tu dis
et uniques pour les champs username et email
Qu'est-ce qui exprime cette contrainte ?
Je ne comprends pas vraiment la sémantique de la méthode "loginWithPassword". Elle prend un nombre variable d'arguments, dont le dernier est une fonction, et elle réussit si les arguments fournis correspondent tous à au moins une ligne dans la base de données ? Qu'est-ce qui se passe s'il y a plusieurs lignes ?
Chapitre "Formulaires et validation"
Lorsque je vous ai dit que MongoDB permettait de s'affranchir de SQL
Il serait préférable de dire "permettait de s'affranchir du modèle relationnel". SQL n'est pas l'unique représentant du modèle relationnel.
Dans la suite, tu utilises plusieurs fois le mot "champ" au pluriel par erreur (par exemple "Sinon on ne touche pas au champs").
Pour information, un upsert est une opération un peu particulière: si le document existe, il sera mis à jour, sinon il sera créé. Jusqu'à maintenant, je n'ai personnellement pas encore eu à l'utiliser, mais il vaut mieux sécuriser cette opération directement, pour éviter d'avoir des mauvaises surprises.
J'ai peut-être raté quelque chose, mais ça a l'air vachement pratique pour un blog pourtant ?.. Je ne comprends pas trop le bloc de code
if(this.isInsert){ // Uniquement sur les "inserts"…
return new Date;
}
else if(this.isUpsert){ // … ou sur les "upserts"
return {$setOnInsert: new Date};
J'ai l'impression que c'est redondant : est-ce que le second test ne sert justement pas à factoriser le cas de l'insertion ET de l'update, auquel cas ton premier test est inutile, et je ne comprends pas le "setOnInsert" ?
Avec ce package, Meteor n'a pas à rougir devant Symfony
Manque un point.
Pour commencer ajouter simplement ceci dans un template:
Manque une espace avant les ":" (ça n'est pas la seule occurrence de l'erreur).
Vous pouvez sans autre placer ces hooks du côté client
?
Rien à signaler sur le dernier chapitre. Cependant, si tu reformules la partie "Théorie" en un exemple de développement d'un blog, il faudra sans doute intégrer le contenu de ce chapitre au reste. C'est toi qui vois.
Tout n'est pas corrigé, mais celà me semble suffisant pour être validé.
Dans tous les cas merci pour vos retours. 