Ma critique ne porte pas tant sur le fond en tant que tel, mais sur l'organisation générale de votre cours. Et elle se décompose en deux points.
L'intro
Tout d'abord, votre chapitre introductif « Le C++, qu'est-ce que c'est ? » est vraiment lourd. Pas à cause de sa rédaction, mais parce que son contenu est une énième répétition de l'intro classique d'un big-tuto sur un langage.
Votre explication sur les qualités d'un bon programmeur se trouve dans le cours de C et aussi, même si vous ne pouvez pas encore le voir, dans le cours de Swift qui devrait arriver en bêta d'ici quelques semaines. Et comble de malheur, vous parvenez à avoir trois explications différentes dans trois tutos ! Bonjour la cohérence…
Quant à votre explication sur ce que sont un programme et la programmation, le fait que vous repreniez in extenso le texte du tuto de C ne fait que mettre en évidence à quel point il s'agit là d'une redite du tuto sur Swift, de celui sur Ada, ou encore de celui sur Ruby.
J'en avais déjà parlé dans le sujet préparatoire à ce tuto, nous sommes en cours de rédaction d'un cours sur les notions de base de chaque paradigme. Mais celui-ci n'abordera pas les bases des bases, à savoir précisément, ce que sont un programme, la programmation de manière générale et l'algorithmique. Il me paraîtrait donc judicieux qu'on s'y mette à plusieurs pour écrire un mini-tuto qui présente ces notions de base et puisse servir d'introduction à tous les tutos sur un langage donné. Cela permettrait d'alléger le vôtre et de ne pas relire quinze fois les mêmes explications, mais avec des approximations différentes.
Le plan
Ensuite, le plan tombe dans le même travers que le cours de C, celui sur Swift, celui sur Rust, celui sur Ruby, celui sur Java, celui sur Ada ou celui sur COBOL : ce n'est tout simplement pas un cours !
Votre présentation du langage est structurée de manière à ce qu'un programmeur confirmé y retrouve ses petits, pas selon une logique d'apprentissage progressif et d'acquisition de compétences : vous documentez le langage, vous ne l'enseignez pas !
Vous découpez le langage en classes d'outils, en partant de la vue d'ensemble que vous en avez, et vous présentez chacune de ces classes d'outils de manière à peu près exhaustive à la suite. Ce faisant, vous encombrez l'esprit de l'apprenant de toutes sortes de notions qui ne lui seront pas utiles avant un long moment, rendant ainsi l'apprentissage plus compliqué. Par exemple, dans le chapitre sur les variables.
- Quelle est l'utilité des suffixes de littérale à un moment de l'apprentissage où votre lecteur ne sait même pas modifier la valeur d'une variable ? Sérieusement, que va-t-il en faire ?
- De même, vous n'aborderez pas les fonctions avant encore trois chapitres : quel besoin aura donc votre lecteur de connaître les références ? Même quand il connaîtra les fonctions, vu qu'il ne connaît pas encore les structures de données composites, aura-t-il réellement besoin de références ou peut-il s'en passer encore pendant un moment ? Surtout les subtilités sur la constance d'une référence à une non constante…
- L'inférence de type est sûrement très intéressante, mais elle n'a clairement pas sa place aussi tôt dans le cours. D'ailleurs, vous êtes obligés de laisser de côté la moitié de vos explications, parce que vous sentez bien que votre lecteur n'a pas le niveau. En outre, l'inférence de type utilisée à tort et à travers est une mauvaise pratique, mais vous ne pouvez certainement pas expliquer pourquoi à quelqu'un qui sait à peine manipuler des variables : il serait plus sage d'attendre d'être plus avancé dans le cours pour parler de cette notion à double tranchant.
Une bonne logique d'apprentissage consiste à vous demander ce que vous voulez que votre lecteur soit capable de réaliser (en termes pompeux, les compétences que vous voulez qu'il acquière), par exemple des programmes de plus en plus complexes que vous voulez qu'il soit capable de programmer par ses propres moyens. Et ensuite, de lui enseigner les outils dont il a besoin pour réaliser cette tâche, et guère plus que cela. C'est uniquement ainsi que vous parviendrez à mettre en place une progression qui ait du sens du point de vue de l'apprenant et non de votre point de vue d'experts.
Ainsi, votre chapitre sur la POO part déjà dans le mur. Vous vous dites « ouais, quand même, serait peut-être temps de parler de la POO, allez, on la met là ! » au lieu de vous demander « quels types de problèmes mon lecteur sera-t-il incapable de résoudre correctement sans POO ? » et de choisir le moment de l'aborder et l'approche en fonction de ce besoin de l'apprenant, et non, encore une fois, selon vos envies d'experts.
Et il en va de même pour la STL. Elle est là pour proposer un ensemble d'outils répondant à des besoins, il est donc plus judicieux de présenter ces outils lorsque votre apprenant en aura besoin que d'en faire un catalogue plus ou moins exhaustif lorsqu'il maîtrise à peine les bases, catalogue qui ne lui donnera aucune idée de l'utilité pratique de tous ces outils.
C'est comme si après vous avoir enseigné les bases de la cuisine (éplucher les patates, cuire un œuf, etc.) on vous faisait un inventaire détaillé de tous les ustensiles et ingrédients d'une cuisine sur-équipée, ainsi que des fonctions des différents robots de cuisine : vous auriez la tête surchargée d'informations diverses, mais vous seriez toujours aussi incapables de réaliser un risotto ou un tiramisu. 
Quelques points plus spécifiques
En plus de ces deux gros points, j'ai relevé quelques « détails » supplémentaires.
Il est multi-paradigme : il n'impose pas une façon unique de concevoir et découper ses programmes mais laisse le développeur libre de ces choix. Nous verrons dans ce tutoriel plusieurs de ces paradigmes.
C'est faux. Je sais que c'est un argument marketing pour vendre un langage de dire qu'il est multi-paradigme, mais faut arrêter de le mettre à toutes les sauces. Le C++ est un langage objet : toute la STL utilise des objets, les versions récentes s'efforcent d'enterrer les scories impératives du C (tableaux simples, pointeurs, etc.) pour les remplacer par des équivalents objets et une programmation trop procédurale est considérée comme une mauvaise pratique.
Et ce ne sont pas les tentatives faiblardes d'intégrer quelques outils de la programmation fonctionnelle (sérieusement, les tuples du C++ sont juste abominablement compliqués par rapport à ceux d'un langage fonctionnel… 
) dans les versions récentes du langage qui suffisent à en faire un langage multi-paradigme. Rust est multi-paradigme, Scala est multi-paradigme, Scheme est multi-paradigme, Mercury est multi-paradigme, mais pas C++.
entierRef2 = entier2; //erreur ! une référence doit toujours désigner la même variable !
Pourquoi erreur ? Quelques lignes plus haut, vous avez modifié la valeur d'une variable par le biais de sa référence en lui affectant une littérale : pourquoi ne serait-il pas possible de modifier la valeur d'une variable par le biais de sa référence en lui affectant la valeur d'une autre variable ?
IV - Les outils nécessaires pour créer de vrais projets
Toute cette section me paraît superflue. Le fonctionnement de la compilation, les outils de base du développeur et l'intérêt d'un IDE, ou encore la bonne gestion d'un projet, ce sont des notions transversales à tous les langages, et elles devraient faire l'objet de cours à part, généralistes. Par exemple, gdb s'utilise de la même manière quel que soit le langage dans lequel on a programmé, et son utilisation fine mérite un cours complet. Vos explications seront au mieux incomplètes et redondantes.
Les conteneurs
J'ose espérer que ce chapitre n'est qu'une ébauche qui sera retravaillée…
