Un outil de Google, apparemment bien répandu chez les étudiants, pour aider à l'apprentissage, en évitant les hallucinations car basé sur les sources qu'on lui donne. Coudé.
L’apprentissage a profondément évolué, passant d’un modèle centré sur la transmission à des approches qui reconnaissent l’activité mentale et sociale de l’élève. Chaque courant – transmissif, béhavioriste, cognitiviste, constructiviste, socio-constructiviste – apporte des forces et des limites, et l’enjeu actuel n’est plus de choisir « le bon » modèle, mais de combiner ces apports pour concevoir des situations d’apprentissage riches, efficaces et transférables. didaquest
Pendant longtemps, l’apprentissage a été pensé comme une simple transmission de savoirs d’un enseignant vers un élève considéré comme récepteur passif. Dans cette pédagogie de la transmission, l’enseignant expose un contenu clair, l’élève écoute, comprend si possible, mémorise puis restitue le message de la manière la plus fidèle possible. La force de ce modèle réside dans sa rapidité et sa simplicité : pourquoi compliquer ce qu’un exposé, un cours magistral ou un documentaire peuvent transmettre efficacement à un grand nombre d’élèves en peu de temps ? Mais ce modèle suppose que l’apprenant dispose d’un bagage cognitif et d’outils de compréhension très proches de ceux de l’enseignant, ce qui exclut de fait de nombreux élèves qui ne partagent ni les mêmes connaissances antérieures, ni la même façon de comprendre. risu-form
Avec l’essor du béhaviorisme, le regard se déplace du discours au comportement observable. L’apprentissage est alors conçu comme une modification de comportements sous l’effet de stimuli et de renforcements, positifs ou négatifs, organisés par l’enseignant ou le formateur. Des expériences emblématiques, comme le chien de Pavlov salivant au son d’une cloche, illustrent cette idée que l’on peut « modeler » les réponses d’un organisme en contrôlant les associations entre situations et conséquences. En classe, cela se traduit par un découpage fin des tâches, une progression graduée, des exercices répétés qui développent des automatismes, et un système de renforcements qui indique à l’élève quels comportements sont attendus. Ce courant est très efficace pour la gestion de classe, l’acquisition de routines et d’apprentissages de bas niveau taxonomique (par exemple maîtriser une règle d’accord au travers d’exercices répétitifs), mais il montre ses limites dès qu’il s’agit de développer des compétences complexes comme l’analyse critique ou le jugement nuancé. beedeez
Les béhavioristes s’intéressent peu à ce qui se passe « dans la tête » de l’apprenant lorsqu’il réussit ou se trompe, considérant souvent l’erreur comme un défaut de conditionnement ou de découpage de la tâche par l’enseignant. C’est précisément ce que vont interroger les courants constructivistes, et d’abord le cognitivisme, qui prennent la construction interne des connaissances comme objet central. Les cognitivistes étudient comment l’information est traitée, encodée en mémoire à long terme, organisée puis récupérée au moment opportun. Ils modélisent la mémoire en systèmes (mémoire à court terme, mémoire à long terme, mémoire sémantique et épisodique) et montrent que l’apprentissage consiste à relier de nouvelles informations à des connaissances antérieures déjà présentes chez l’élève. Ce courant rompt avec l’idée d’une « tête vide » : les apprenants arrivent en classe avec un bagage qu’il faut identifier, organiser, enrichir, et sur lequel on peut agir, notamment à travers des outils comme les réseaux de concepts, l’enseignement stratégique ou la mise en lien entre expériences de vie et contenus scolaires. didaquest
Dans cette perspective cognitiviste, le rôle de l’enseignant est d’aider à structurer les connaissances, d’exploiter les liens entre différents types de mémoire et d’accompagner l’élève dans une démarche métacognitive où il prend conscience de sa façon d’apprendre. L’élève devient actif dans le traitement de l’information, engagé dans une organisation intentionnelle du savoir plutôt que simple récepteur. Une grande force de ce courant est de clarifier l’architecture des connaissances et de donner à l’apprenant du pouvoir sur sa propre construction mentale, notamment grâce à la métacognition. Mais si l’on se concentre trop sur les structures abstraites, sans les ancrer suffisamment dans des situations d’utilisation réelle, le transfert des apprentissages vers de nouveaux contextes risque d’échouer : l’élève sait « sur le papier », mais ne sait pas quand ni comment mobiliser ce qu’il a appris. moddou
Le constructivisme de Piaget et de ses continuateurs va alors insister sur la dimension active et située de la construction des connaissances. Le développement cognitif y est décrit comme une succession de stades liés à l’âge, qui conditionnent le niveau d’abstraction possible, du concret vers le symbolique. L’apprentissage n’est plus la réception d’un contenu tout fait, ni seulement l’organisation interne d’informations, mais une construction personnelle qui émerge de l’activité de l’élève confronté à des situations signifiantes. On ne peut pas « déposer » une compréhension toute faite dans la tête de quelqu’un ; il faut proposer des tâches qui l’obligent à manipuler des objets, des idées ou des problèmes, à expérimenter, à se tromper, puis à ajuster progressivement sa compréhension. L’erreur devient un indicateur précieux du niveau de développement cognitif de l’élève, une source d’information pour l’enseignant plutôt qu’une faute à éviter à tout prix. didaquest
Dans ce cadre constructiviste, le rôle de l’enseignant est de concevoir des situations aussi proches que possible de l’activité authentique (par exemple des démarches scientifiques réalistes pour travailler les sciences) et de guider l’élève sans lui enlever la difficulté productive de la tâche. Même en l’absence de connaissances antérieures explicites, l’action et la manipulation permettent l’émergence de constructions provisoires sur lesquelles l’enseignant pourra ensuite intervenir pour affiner, corriger et stabiliser la compréhension. L’élève est invité à accepter des déséquilibres cognitifs parfois inconfortables, qui sont le moteur de la réorganisation de ses schèmes de pensée. Les pistes d’intervention associées à ce courant incluent les situations complexes, l’accompagnement par le questionnement, et le refus de « lisser » toutes les difficultés pour laisser un espace à la recherche et au tâtonnement. didaquest
Le socio-constructivisme, notamment avec Vygotski, ajoute une dimension décisive : l’apprentissage est non seulement une construction personnelle, mais aussi et surtout un processus social médié par le langage. En travaillant avec d’autres, en confrontant ses points de vue, en négociant le sens des mots, chaque élève peut parvenir à des constructions conceptuelles plus fines que celles qu’il aurait élaborées seul. La notion de zone proximale de développement montre qu’un élève peut accéder à des formes de pensée plus élaborées s’il est accompagné par un adulte ou un pair plus avancé, plutôt que d’attendre passivement un « stade » biologique suivant. Dans ce paradigme, le langage oral et écrit est un outil central : il permet de clarifier sa pensée, de l’exposer à la critique des autres, d’intégrer des points de vue nouveaux et de restructurer ses représentations. edutechwiki.unige
L’enseignant socio-constructiviste crée donc des situations où les échanges entre élèves sont riches, planifie des débats, des mises en commun, des travaux collaboratifs, et anime ces interactions sans les fermer trop vite par une conclusion professorale. Il intervient plutôt en différé, pour aider à dépasser les malentendus, mettre en lumière les dissonances et transformer les erreurs en occasions d’apprentissage pour tout le groupe. L’erreur n’est plus seulement une information sur un individu, mais un matériau de travail partagé qui nourrit la réflexion collective. Les situations complexes assorties de temps d’échanges structurés illustrent bien cette approche où le groupe devient lui-même un système cognitif, dans lequel la pensée circule, se confronte et se transforme. sujetsrh
Au terme de ce parcours, l’intention n’est pas de dresser une chronologie exhaustive ni d’opposer les courants comme s’il fallait en choisir un une fois pour toutes. Chacun met en lumière une facette de l’apprentissage : efficacité de la transmission pour certaines informations, puissance du renforcement pour installer des automatismes, importance de l’organisation interne des connaissances, rôle de l’activité de l’élève, poids déterminant de l’interaction sociale et du langage. Se cantonner à une pédagogie purement transmissive expose à de graves problèmes de transfert, tandis que s’appuyer uniquement sur une approche constructiviste ou socio-constructiviste sans structuration ni entraînement peut laisser certains élèves démunis. L’enjeu contemporain est donc d’aller puiser de manière réfléchie dans chacun de ces courants pour concevoir des dispositifs d’apprentissage équilibrés, où l’on transmet, on entraîne, on fait construire et co-construire, afin de maximiser les possibilités de réussite pour tous les élèves. com-and-co-formation
| Courant | Vision de l’apprentissage | Rôle de l’enseignant | Rôle de l’élève | Forces principales | Limites principales |
|---|---|---|---|---|---|
| Pédagogie transmissive | Réception, mémorisation et restitution fidèle d’un savoir organisé. didaquest | Expose, explique, structure le contenu, détient l’essentiel du savoir. didaquest | Écoute, comprend, mémorise, restitue de façon plutôt passive. didaquest | Rapidité, efficacité pour diffuser un même contenu à beaucoup d’apprenants, clarté des messages. didaquest | Nécessite un bagage cognitif proche de celui de l’enseignant, faible prise en compte de la diversité, problèmes de transfert. didaquest |
| Béhaviorisme | Modification de comportements observables par conditionnement (stimuli, réponses, renforcements). beedeez | Conçoit le « design » des tâches, découpe en petites étapes, organise renforcements positifs ou négatifs. beedeez | Répond à des stimuli, répète, ajuste son comportement en fonction des conséquences. beedeez | Très efficace pour les automatismes, les routines, la gestion de classe, les apprentissages de bas niveau. beedeez | Ne traite pas ce qui se passe dans la tête de l’élève, difficile à appliquer aux compétences complexes, erreur vue comme échec de conditionnement. moddou |
| Cognitivisme | Traitement de l’information, encodage et organisation en mémoire à long terme, mobilisation contextuelle. didaquest | Aide à organiser les connaissances, active les prérequis, propose des outils comme cartes conceptuelles, stratégies d’apprentissage, métacognition. didaquest | Traite activement l’information, établit des liens avec ses connaissances antérieures, réfléchit à ses stratégies. didaquest | Clarifie l’architecture des savoirs, valorise le bagage de l’élève, développe la métacognition et le contrôle sur sa propre manière d’apprendre. didaquest | Risque d’échec de transfert si l’on reste trop sur l’abstraction sans ancrage contextuel fort. didaquest |
| Constructivisme | Construction personnelle de connaissances par l’action et la confrontation à des situations significatives. didaquest | Propose des situations complexes, proches de la réalité, guide par le questionnement, exploite l’erreur comme indicateur de développement. didaquest | Est actif, manipule (objets, idées), accepte le déséquilibre cognitif, élabore progressivement ses propres constructions. didaquest | Met l’accent sur l’activité de l’élève, valorise l’erreur comme ressource, permet l’émergence de connaissances même sans prérequis explicites. didaquest | Nécessite un accompagnement fin pour éviter la simple « errance », demande du temps, peut être difficile à articuler avec certains contenus très normés. didaquest |
| Socio-constructivisme | Construction des connaissances dans et par l’interaction sociale, médiée par le langage. didaquest | Organise des situations d’échange (débats, mises en commun, travaux de groupe), anime et régule les interactions, intervient pour lever malentendus et dissonances. edutechwiki.unige | Partage ses idées, confronte ses points de vue, négocie le sens, apprend avec et par les autres dans la zone proximale de développement. edutechwiki.unige | Exploite la puissance du langage et du collectif, favorise des conceptualisations plus fines et le développement de fonctions intellectuelles supérieures. edutechwiki.unige | Peut diluer les objectifs si les échanges sont mal cadrés, demande une gestion de groupe exigeante, certains élèves peuvent rester en retrait. edutechwiki.unige |
Cet encadré montre que chaque courant éclaire une dimension spécifique de l’apprentissage et qu’un dispositif pédagogique riche gagne à articuler ces approches plutôt qu’à les opposer. com-and-co-formation
Bienvenue dans K-leSon !
Cette application aide les enfants à apprendre les sons des lettres et des graphèmes en français.
→ Clique sur une lettre ou un graphème pour entendre son son
Les quatre piliers de l’apprentissage sont des concepts clés identifiés par Stanislas Dehaene, neuroscientifique et spécialiste en sciences cognitives. Ces piliers, ancrés dans la recherche en neurosciences, montrent comment le cerveau apprend de manière efficace et sont essentiels pour optimiser les processus d’apprentissage, en particulier à l’école. Voici un aperçu de ces quatre piliers :
Perso j'avais la version suivante:
Réflexion issue d’une discussion sur le Discord de Cuistops concernant le fait que Talos pourrait ne pas être le meilleur point de départ pour s’attaquer à cette technologie d’infrastructure qui a balayé le monde de l’orchestration de containers en une petite dizaine d’années. Pour illustrer pourquoi il n’y a pas de réponse absolue à cette question, je me suis dit que vous décrire mon parcours concernant l’univers des containers et Kubernetes en particulier (aussi bien au niveau perso que pro) serait éclairant sur certains points.
Le moins qu’on puisse dire, c’est que mon entrée dans l’univers des containers, en particulier via docker, n’était pas brillante. Je conserve avec malice le premier billet que j’ai consacré à ce sujet en 2016 pour illustrer à quel point je me trompais sur la technologie, que je n’avais jusque là pas vraiment vu, encore moins au niveau professionnel. J’ai heureusement rattrapé cette erreur depuis, aussi bien à la faveur de formations au travail (merci Thomas Perelle 
) qu’au niveau perso, où mes propres expérimentations m’ont conduit à partager ma découverte et mon utilisation de Docker Swarm. J’ai bien rattrapé le coup, hein ?
D’ailleurs, Swarm a été pour moi la découverte de la notion d’orchestration. Que j’ai pu creuser cette fois au niveau pro en 2018 après un premier tout petit pas vers l’univers Kubernetes par la porte OpenShift à la faveur d’un workshop de deux jours par un collègue qui sera réellement un mentor pour les années suivantes, Julien Francoz. Je n’ai malheureusement pas gardé grand chose de ce workshop, étant donné que je n’avais aucune plateforme de ce type dans mon pôle client, encore moins de Kubernetes. Tout juste on commençait à avoir des clients qui cherchaient à déployer leurs applis en mode container sur des serveurs classiques, avec Docker. Sans pratique, la théorie s’efface vite, d’autant qu’en 2018, les usages « domestiques » n’étaient pas légion, donc les articles de blog non plus, encore moins autour d’Openshift. C’est en 2019 que tout change.
Je vous passe le contexte de comment j’en suis arrivé à cette situation intense qui aura duré 5 mois, mais oui, j’ai découvert Kubernetes d’une façon un peu particulière : service cloud managé, sur Azure, el famoso « AKS« , à devoir migrer des applications précédemment hébergées sur des serveurs virtuels Debian dépassés, avec un cluster déployé manuellement qu’on a tenté de « terraformer » après-coup, avec toute la « qualité » de l’API d’Azure d’alors. Et je remercie encore Julien d’avoir pris autant de temps à me soutenir dans cet apprentissage express (la notion de mentor n’était pas galvaudée, clairement).
Moi pendant la migration du client sur Kubernetes
Service cloud Managé veut dire qu’on ne gère pas certains aspects importants de la vie d’un cluster : tout le control plane est masqué, vous ne voyez que les nœuds, vous ne vous occupez pas trop de certains aspects comme la rotation des certificats, les mises à jour sont automatisées (vous indiquez une version cible, le service s’occupe de la montée de version du control plane, puis des nœuds un par un), et vous bénéficiez d’intégrations avec le reste de l’infra du fournisseur, au niveau du réseau, du stockage, des capacités comme l’autoscaling (vous augmentez et réduisez automatiquement le nombre de nœuds en fonction de la charge ou des réservations de ressources des pods à déployer). L’installation se fait en trois/quatre clics via l’interface web, une ligne de commande avec l’utilitaire maison, ou un peu plus de lignes de code si on le fait via un outil d’infrastructure as code.
Bref, c’est cool, ça permet de se concentrer sur les aspects opérationnels des applications déployées, mais même comme ça, je vous avoue que AKS tel que Microsoft le proposait n’était pas toujours une sinécure. Azure lui-même était pénible, avec des VMs qui mettaient plusieurs minutes à démarrer (quand les concurrents tournaient autour de la minute). Et comme on ne gère pas le control plane, on rate tout un pan de l’architecture et de la gestion de Kubernetes et de ses composants sous-jacents. En plus à l’époque, l’image de l’OS utilisé pour les nœuds était basée sur Ubuntu, pas le plus léger et le « gaspillage » de ressources était réel, au-delà de Kubernetes lui-même.
J’aurais l’occasion de passer encore quelques années, pratiquement trois, à déployer d’autres projets AKS pour d’autres clients, ce qui m’a permis de constater, il faut savoir aussi le reconnaitre, comment Microsoft a cravaché pour amener un niveau de qualité sur le service bien plus en phase avec ce qu’on attend d’un tel fournisseur. Rotation automatique des certificats via les mises à jour (c’était pas le cas, la commande de rotation était à lancer à la main), amélioration générale d’Azure sur les temps de démarrage des nœuds, efficacité des mises à jour, intégrations avancées au niveau réseau (Calico, Istio, etc)… Ce qui n’empêche pas certains pains avec entre autres une API qui accepte certaines valeurs pourtant non supportées et qui m’ont forcé à redéployer des clusters from scratch parce que la communication entre les nœuds étaient devenue impossible (réponse du support : « on va mettre à jour la doc pour indiquer les valeurs supportées »; bravo…). Par la suite, j’ai découvert et encore plus adoré exploiter et déployer du GKE, le service équivalent de Google Cloud; il m’aura permis au passage d’apprendre comment fonctionnait ce fournisseur et tout ce qu’il fait de mieux que Microsoft (et parfois d’AWS). Au point de passer la certification « Professional Architect » au bout de 4 mois seulement de pratiques.
Cette expérience en particulier avec Azure ne m’aura pas empêché pas de tomber amoureux de la technologie, au point de remiser Docker Swarm, et de migrer sur K3S. Là aussi un choix particulier, conçu pour les machines très légères, puisque ciblant les Raspberry Pi, j’ai malgré tout fait le déploiement du flemmard, même si j’ai privilégié un déploiement semi-automatisé avec un playbook/role Ansible, et un seul nœud comme control plane (qui était le seul mode de déploiement supporté alors).
Particularité de k3s, regrouper tous les composants « core » de Kubernetes dans un seul binaire, une petite prouesse à la base de son empreinte mémoire réduite, mais pas que : un des éléments les plus critiques d’un cluster, la base de données ETCD, la « mémoire » du cluster, est remplacée par SQlite, bien plus léger, mais évidemment limité à une seul nœud, et moins enclin aux problèmes des bases de données plus complexe. Bien que le mode « multi-master » ait été implémenté par la suite, au passage à mes Raspberry Pi 4, j’ai quand même conservé le même mode de fonctionnement. J’ai eu l’occasion de détailler pas mal de choses concernant K3S sur ce blog, je ne vais donc pas m’étendre beaucoup plus.
Reste qu’à l’occasion d’une volonté de refonte, accélérée par la mort successive des cartes SD des Raspi après 4 ans de bons et loyaux services, j’ai décidé de revenir à un Kubernetes un peu moins simplifié, en partant sur un autre choix particulier, Talos Linux, qui aura fini en machine virtuelle suite à une déconvenue de matériel et de limitations électriques, que je me suis pris en pleine poire en plein live Twitch. Talos propose un déploiement Kubernetes beaucoup plus standardisé dans ses composants de base, mais dont la gestion des nœuds est très particulière : pas d’OS à proprement parler, juste le noyau et une API qui permet de pratiquer toutes les opérations sur la gestion de ces nœuds : pas de SSH, pas de CLI directe, l’utilitaire talosctl est là pour configurer les nœuds à l’envi, permettant de les ajouter/retirer d’un cluster en un clin d’œil, un aspect très important dans une gestion d’infrastructure au sens large (comprendre, en entreprise). Toute la configuration de base se fait au travers de fichiers de configuration YAML, à l’instar de Kubernetes lui-même, permettant une approche « intégration continue » et un versionnement via git.
Actuellement, je me débats avec certains paramétrages par défaut orientés sécurité entre autres qui peuvent limiter/bloquer certains usages sans attention particulière. Il est vrai que par défaut, Kubernetes est une plateforme particulièrement ouverte avec peu de gardes-fous, et c’est à chacun d’adapter cet aspect en fonction de son propre contexte, ce qui amène à devoir exploiter nombre d’extensions et contrôleurs additionnels pour y parvenir. Et comme souvent, la sécurité à un prix…
On le voit, au final je n’ai que peu choisi comment j’ai découvert et abordé la technologie et son déploiement « dans le monde réel », et j’ai démarré par certaines abstractions qui font que si je m’étais retrouvé face à un cluster « vanilla » (kubeadm, kubespray), et un problème lié au control plane, j’aurais été plus en peine que quelqu’un ayant directement attaqué « the hard way » (z’avez la ref ?). Et d’un certain côté c’est certainement encore le cas encore aujourd’hui, ce qui me vaudrait d’être recalé au recrutement chez Lucca ou Enix. Le livre à venir teasé par Denis Germain (qui ne s’appellera pas 50 Nuances de Kubernetes, ce qui aurait été bien trop cool comme titre) montre bien la diversité d’approches qui ont chacune leurs spécificités, avec la plupart des services dit « managés » abstrayant une bonne partie des composants et concepts de bas-niveau pour vous concentrer sur vos applications ou celles de vos clients.
Est-ce que l’une d’elles est meilleure qu’une autre ? Je considère toujours que la théorie est importante, jusqu’à un certain point, dans la mesure où si on n’a pas de le contrôle sur les éléments, ne pas savoir comment ils fonctionnent de manière sous-jacente n’est pas toujours une grosse tare : ce n’est pas de notre ressort que d’y mettre les mains. Imaginez une corruption de base ETCD sur un service managé. Ma seule préoccupation sera d’être capable éventuellement de restaurer tout ce que j’y ai mis au départ – mes déploiements d’applications, mes secrets, mes CRDs, etc- , là où la préoccupation du provider, sera de réparer cette corruption; dans le pire des cas, s’il n’aura pas été capable de restaurer le service avec un minimum de pertes, il s’agira de restaurer tout ça sur un nouveau cluster.
Nous vivons également dans un monde connecté à la plus grande base de connaissances du monde : Le Web. Je n’ai pas besoin de connaitre l’intégralité des arcanes du moindre bout de logiciel, quelque soit son niveau dans l’environnement où j’évolue, pour être capable de l’exploiter au quotidien, voire de le réparer. Les connaissances déjà acquises sont évidemment importantes, parce qu’elles permettent de définir un état d’esprit, un mode de réflexion, qui est la plupart du temps applicable aux autres technologies que vous rencontrerez. Mais si je rencontre un problème que je n’ai pas déjà vu par le passé, une recherche sur le web m’amène généralement soit à la solution, soit à une piste à creuser pour déterminer la cause. Dès lors, il n’y a pas de réponses simples à apporter à la question « par où démarrer », parce qu’elle peut dépendre aussi de la « fin ».
Par où on attaque ?
Faire un cluster à la mano avec tous les composants en mode « the hard way » ne sert pratiquement à rien si après on évolue dans un contexte de service managé. À l’inverse, un service managé est intéressant en ce sens qu’il permet de gérer les interactions avec d’autres services du fournisseur, et donc le mode de fonctionnement de celui-ci. Sur Kube lui-même vous manquez des choses, mais vous avez quand même pas mal de concepts à intégrer. Est-ce moins pertinent ? Pas forcément si c’est ce que vous manipulez tous les jours. Dans le même esprit, « the hard way » est probablement la pire méthode pour gérer le quotidien sur de l’infra qu’on gère, même si pour le coup on a toutes les tripes du cluster sur la table. On privilégiera donc très vite d’autres outils plus automatisés pour la gestion habituelle. N’est-ce pas tout aussi pertinent de démarrer directement avec ces solutions pour intégrer plus rapidement leurs concepts ?
Par où commencer Kubernetes ? J’ai envie de dire, par la solution qui vous rendra curieux. C’est tout le sel de l’apprentissage, comme de la recherche scientifique, où chaque réponse qu’on trouve amène d’autres questions, tout aussi passionnantes. D’autant plus que quand on démarre, on est amené à faire, défaire, refaire, à comparer. Notre univers informatique au sens large bouge tout le temps, la « galaxie » Kubernetes n’est pas en reste, il y a toujours des dizaines d’angles d’attaque possible, et à de très rares exceptions près, il n’y en a pas nécessairement une qui est plus mauvaise qu’une autre. Et d’autres apparaitront régulièrement, ce qui représente de nouvelles réponses possibles à cette question. Il ne faut pas avoir peur de se faire plaisir de différentes manières
Connexion